The first five to ten working days of the month belong to the close.
The close starts on the first working day, and for the following week accounting does little else. Accounts are reconciled by hand: subledger against general ledger, bank statement against open items, in spreadsheets somebody built years ago who left the company long since.
The bigger time sink is not the reconciling, it is the chasing. A difference shows up, and nobody knows whether an incoming invoice is missing, a payment landed on the wrong account, or a goods receipt was booked without an invoice. So emails go out to purchasing, to the site manager, to the colleague who approved the order. The answers take days. Accruals come from memory or get copied from last month.
On top of it all sits a close checklist in Excel that nobody keeps current. It gets filled in at the end, as documentation. The consequence is predictable: reporting to management arrives late, and by the time the numbers are on the table, the month they describe is two weeks gone.
We sit through a real close before we build anything.
A close has dozens of items, and automating all of them at once is the reliable way to sink such a project. So we start where the pain is measurable. And the team’s conditions became the specification: every posting stays with a human, every number shows its source, and accounting maintains the reconciliation rules itself. “In the close, my signature is under it” was the first sentence in the conversation, and it determined the architecture.
- Sit through a real close: We sit with the team during an actual close and record which account is reconciled how, where the waiting time goes, and which questions go out to whom.
- Choose the first accounts deliberately: Usually bank and clearing accounts plus payables and receivables against their subledgers. Small scope, fast feedback loop.
- Move reconciliation into the month: The AI employee runs daily, not only at month end. Differences surface on the day they arise, while the context is still fresh.
- Go-live only after the team’s okay: The system went live once accounting said: the checklist in the system is more useful than our spreadsheet.
80 percent is done by the AI employee. The human decides at two points.
The AI employee has read access to the systems where the numbers live: the accounting system, banking, and wherever the documents are stored. Every day it pulls the current balances, matches subledgers against the general ledger and bank statements against open items, and assigns what belongs together.
What it cannot assign becomes a documented difference instead of a red cell in a spreadsheet. Every difference carries an amount, the two sides it sits between, and a probable cause. If a document is missing, it asks the person who holds it, with the order or contract reference attached. Accounting decides what a difference means and releases the postings. Without that release, nothing reaches the books.
The payables subledger shows 18,400 euros more open items than the corresponding general ledger account.
One field is flagged for review: whether to accrue or wait for the invoice depends on delivery terms and materiality. Exactly this decision stays with accounting.
That was before, this is today.
This is how the close ran before, and this is how it runs today with the AI employee. Conservatively calculated, it is finished 2 to 3 working days earlier, because reconciliation happens during the month instead of after it.
| Before | Today | |
|---|---|---|
| Reconciliation rhythm | Starts after month end, all at once | Runs daily, during the month |
| Finding a difference | Manual matching in spreadsheets | Flagged with amount, both sides, and cause |
| Missing documents | Email chains over several days | Requested on the day it arises, with reference |
| Accruals | From memory or copied from last month | Drafted from contract and prior period |
| Close checklist | Excel, filled in afterwards | Live status per item, blockers named |
| Reporting to management | Arrives late, the month is two weeks gone | Arrives 2 to 3 days earlier |
* Savings conservatively calculated: the close took 5 to 10 working days before. Because reconciliation happens daily instead of at month end, the searching and chasing time largely disappears, which in our project experience makes up more than half of the close. We deliberately count only 2 to 3 days of earlier close, so 24 to 36 working days per year. At 60,000 to 85,000 euros of employer cost for a qualified accountant and about 220 working days, that is roughly 275 to 385 euros per day, together around 7,000 to 14,000 euros per year.
How do you build an AI employee like this, technically?
The knowledge from this scenario to take away, whether you build with us or on your own:
Daily balance reconciliation over the existing interfaces
The AI employee pulls balances through the DATEV interfaces and through the banking access, and from SAP in larger organizations. The matching itself is not AI but a fixed rule: subledger against general ledger, statement against open items, with a tolerance per account type. Where numbers are computed, logic decides, not a model.
Difference causes and document matching with language models
GPT from OpenAI or Claude from Anthropic read the surrounding data and derive the probable cause: a goods receipt without an invoice, a payment on the wrong account, a shift across the period cut-off. The same models match documents from the DMS or SharePoint to the right posting. If they are unsure, they say so and hand the item over.
The close checklist as a living artifact
Instead of an Excel file filled in at the end as documentation, the AI employee maintains a status per item: done, waiting, blocked, and blocked on whom. Three items waiting on the same missing invoice are a finding on day two and an excuse on day eight.
GoBD: every number carries its source
For every value it records which system it came from, at which cut-off date, and which document supports it. For every proposal, who accepted, changed, or discarded it and when. Nothing is overwritten, a correction is recorded as a correction. That is exactly what the German GoBD principles require in terms of traceability and immutability.
UX: the interface decides adoption
A checklist board shows every close item with status and blocker at a glance. Every difference appears with its context beside it: amount, both sides, document, person asked. And posting proposals are always drafts a human can change or discard. These three things turned skepticism into approval.
What does it cost in comparison?
Superkind charges per use case. The price grows with the number of entities and accounts, not with headcount. Here is the honest comparison:
| Qualified accountant | Close software | Superkind AI employee | |
|---|---|---|---|
| Cost | 60,000 to 85,000 € per year | Often 1,000 € or more per month in license | Price per use case, a fraction of a full-time position |
| What is included | The whole close, by hand | Checklist structure and matching rules | Daily reconciliation, cause, document requests, checklist status |
| Scales with | More staff | Seats and modules | Entities and accounts, without new positions |
| Exceptions | Human researches everything | Left sitting as a red row | Flagged with evidence and sent to a human |
| Rollout | Recruiting and onboarding | A project over several months | 2 to 3 weeks to the first productive version |
The honest comparison is the full cost of today’s close: a week of senior capacity every month, late reporting, and the risk that a difference gets explained from memory instead of from a document.
What we learned about automating the close.
The close is the process finance teams are most skeptical about, and rightly so. Only the skepticism usually aims at the wrong thing. Nobody in accounting needs a model that decides how a difference gets posted. What is needed is that the days of searching, chasing, and waiting before that decision disappear. Once you separate preparation from judgment, the objection nearly dissolves.
The second lesson is about timing. Almost every close project tries to make month end faster. But the leverage is not at month end, it is in the three weeks before it. A difference is cheap to resolve on the day it arises and expensive four weeks later. Moving reconciliation into the month is the change that shortens the close. Everything else is optimization around the edges.
What it is not suited for: If your close already stands after two to three days, the bottleneck is somewhere else. If accounts are posted inconsistently across entities, the chart of accounts should be cleaned up first. And if the expectation is a system that posts on its own and closes the month unsupervised, we are the wrong provider.
