September 2, 2026
The 500-year-old bug in accounting: every month we delete the why behind the numbers
The most important document in the company lives in a spreadsheet
In many companies the document that really explains the month’s numbers is not the financial statement. It is a spreadsheet that three people know about.
It has hundreds of rows, one for every fact of the month: the invoice issued with the discount agreed by phone, the customer who paid in two instalments, the supplier who re-invoiced a part, the credit note for the goods that came back. Every row carries a story: what the salesperson negotiated, which exception the owner approved.
Whoever builds it spends days gathering the data and more days doing the sums. What ends up in the accounting system is a handful of summary entries: “Revenue for the month, total.” Everything else, the hundreds of stories, stops existing.
| What happened | What stays in the books |
|---|---|
| Customer moved to the annual contract mid-month, fee pro-rated | gone |
| One-off 15% discount for a late delivery in October | gone |
| Supplier paid a deposit, balance the month after | gone |
| New customer from a referral, dedicated discount | gone |
| … hundreds more rows | “Revenue: 830,000 €” |
It is called “closing the books” and it has been the practice for more than five centuries. But it could be called “industrial-scale destruction of business context”. Because when the owner asks why revenue fell last month, the books contain none of the information needed to answer.
A ledger that stores numbers and forgets the why
The general ledger has an important name, but it is essentially an archive of numbers. It keeps the totals and lets the work of computing them happen elsewhere: in other systems, in spreadsheets, in people’s heads. And since the work happens elsewhere, the ledger knows nothing about the numbers it holds. It is like doing your maths homework on the blackboard, wiping it, and handing in only the result. A trapdoor with no way back.
That trapdoor creates enormous problems when you need to trace things back. The owner wants to understand how a product is doing, the accountant asks why costs went up, the bank wants an explanation for a quarter: every time someone has to go back to the original sources. It is archaeology done by hand, and often wrong. The accounting system says one number, the admin’s spreadsheet says another, and nobody can make the two agree.
Sales have the CRM. HR has its own system. Finance has a ledger designed in the fifteenth century that has not changed in substance since. Every function of the company has a living system that keeps the context; administration has a shared folder full of spreadsheets.
Why it is hard
There is a reason this work is done by hand: so far it has been impossible to beat the flexibility of a spreadsheet, and recording everything that happens in a company takes a lot of flexibility.
No two companies have the same shape. And even when the model looks standard, there are always exceptions: the customer who reimburses part of the costs, the commission to the partner who brings in the contracts, the new line that starts with an advance and then moves to actuals. Software made of fixed rules cannot express all these cases.
On top of that, the context is scattered everywhere: in contracts in PDF, in certified emails, in the tax mailbox, in WhatsApp messages with the accountant, in the memory of whoever was there. Connecting the programs’ APIs is not enough. No system has ever managed to get deep enough into the company to gather everything needed to do the sums. So everyone builds it by hand.
What changes with AI, and what is not enough
Language models unlock three things. They can read documents written by people: contracts, invoices, receipts, the email with the agreement. They can move through systems that have no interface for machines. And they can handle the exception on the fly, the case a rule of “if this then that” had not foreseen.
But there is a condition. A model resolves exceptions only if it works on top of solid foundations: clear financial building blocks, with guardrails, safely composable, and transparent in the work they do. People who run administration need defensible calculations, not self-assured answers. And those building blocks have to live inside a system that also holds the rest of the context, otherwise the model does not have enough information to decide well. Pointing an AI at an isolated tool produces confident, wrong answers.
How we do it
Ditta starts from the bottom, from the least glamorous work: gathering and organising the data. Invoices from the tax mailbox, transactions from the banks, documents from email, the accounting system the company already uses. All in one place, connected.
Then it keeps the why attached to every number. A bank transaction is not an amount: it is that transaction, matched to that invoice, with that document attached, categorised for that reason. When you ask “why did the margin drop in July?”, the answer is not a reconstruction: it is the real invoices and transactions, which you can open and check.
The month-end close thus stops being a lossy compression. The books become a view on the context, not its destruction. The hundreds of rows no longer disappear: they stay there, useful, for the next question.
This article takes up and adapts, in our own words and for Italian companies, a piece by Helen Hastings, founder of Quanta, titled “The 500-Year-Old Bug in Finance”.
Image: portrait of Luca Pacioli attributed to Jacopo de’ Barbari, 1495, public domain.