AI can do the bookkeeping. It cannot be your evidence.

Two years ago, getting a computer to look at a photograph of a lunch receipt and return restaurant meal, 13,5 %, deductible was a product. Today it is an API call that costs a fraction of a cent, and every bookkeeping tool in Europe has one. When a capability gets that cheap, it stops being the thing you are selling. It becomes the floor.

Which raises an awkward question for everyone in this market, us included: if the classification is commodity, what exactly is the product?

The answer we have landed on, after building one of these engines and then spending considerably longer making it defensible than making it accurate, is this. The classification is not the deliverable. The record of why is the deliverable. And those two things are built very differently.

What an inspector actually asks

A tax inspection is not a quiz. Nobody arrives and asks your software what a receipt is. They arrive with a list of entries they have already formed an opinion about, and they ask a different question: why did you treat it that way, and show me.

That question has a shape. It wants a rule, a date, an amount, and a document. It wants the four of them to agree. And it wants the answer to be the same answer you would have given eighteen months ago, because the entry was made eighteen months ago and the inspector can read the timestamp.

It is worth being concrete about the shape of that meeting, because most descriptions of it are written by people selling insurance against it. An inspector does not audit a year. They pull a period — a quarter, a month, a fortnight — and inside it they pull perhaps thirty entries, chosen because something about them looked irregular against everything else you filed. Round numbers. A supplier that appears once. A category that jumped. Then they ask about those thirty, one at a time, and the meeting goes well or badly depending on how many of the thirty you can answer without leaving the room.

Notice what is being tested there. Not whether your software is clever. Whether a specific decision, made on a specific Tuesday, can be re-explained by someone who was not there.

Here is the uncomfortable part. On a screen, a confident guess and a defensible record look exactly alike. Both render as a tidy green row saying 13,5 % · deductible. The difference does not surface in your dashboard. It surfaces in the one meeting where it is expensive.

Three properties of a record that survives

We hold our own engine to three tests. None of them is about accuracy, and that is the point.

Why the model cannot be the engine

Read those four again with a language model in mind and the problem is immediate.

A model asked the same question twice can answer twice. That is not a defect; it is how the thing works, and the same property that makes it good at reading a crumpled receipt makes it unfit to be the rule. You can lower the temperature and pin a version and it is still a probability distribution wearing a tie.

The deeper problem is time. The model you are using in March 2026 will not be running in 2032. It will have been deprecated, replaced, and its weights will not be available to anybody, including the company that trained it. You cannot re-derive a six-year-old classification from an artefact that no longer exists. Any design where the model is the rule has a shelf life shorter than the legal one.

The engine decides. The model narrates. When those two swap places, you have a very fluent system that cannot testify.

So the work goes the other way round. A deterministic engine — ordinary code, with the rules written down and tested — produces the classification and the reasons. The model's job is narrower and genuinely useful: read the messy input, and afterwards explain the engine's conclusion in a sentence a human will actually read. If the model went away tomorrow, every past entry would still be re-derivable. That is the test.

This is a worse trade than it sounds, and it is worth saying so plainly. Writing the rules by hand is slow. A model will cover a long tail of odd cases in an afternoon that will take you months to encode, and for the first few weeks the hand-written engine looks embarrassing next to it. You give up a demo to buy a property nobody can see.

What you get back is that the system can be wrong in a way you can find. A rule that misclassifies does it consistently, for a reason you can read, across every entry it touched — so when you fix it you can say exactly which past entries were affected and re-derive them. A model that misclassifies does it occasionally, for no reason you can recover, and the blast radius is unknowable. The first is a bug. The second is a liability with no edges.

Six years, and ten

Finnish law puts numbers on the shelf life. Under the Accounting Act, vouchers — receipts, invoices, bank statements — must be kept for six years from the end of the financial year. Financial statements, the annual report and the accounting books themselves must be kept for ten.²

Put that against a receipt scanned in January 2026. It has to be explainable until the end of 2032. The statements it rolls up into have to stand until 2036. Ten years is two or three complete generations of machine learning. It is longer than several of the companies currently selling AI bookkeeping have existed.

This is not a reason to avoid using models. We use one. It is a reason to be precise about what job you give it, because the retention period is a hard constraint and it does not care how good the demo was.

The practical consequence shows up in what you store. It is tempting to keep the answer — 13,5 %, deductible — and a note saying which model produced it, as though the model name were a citation. It is not. In 2032 that note names something nobody can run. What has to be stored is the derivation: the rule that fired, the values it read, the document it read them from, and the version of the ruleset in force on that date. Stored that way, the entry explains itself with no running software at all. Somebody can check it on paper. That is a low bar and it is the right one, because six years is long enough that paper is a realistic fallback.

A concrete case: the rate that moved

On 1 January 2026 Finland's reduced VAT rate went from 14 % to 13,5 %. It covers food, restaurant and catering services, books, medicine, accommodation, passenger transport, and cultural and sporting events.¹

Ask a language model trained before that change what VAT a Finnish restaurant meal carries and it will tell you 14 %, fluently, with no hedging, forever. We know this because we test for it: the single most reliable thing a model invents about Finland is a VAT rate that no longer exists.

But notice that knowing about the change is not enough either. A receipt from December 2025 must still be treated at 14 % — not because 14 is wrong or right today, but because 14 is what was charged, and the record has to reprint at the rate it was sold under. A VAT rate is not a fact about the present. It is a fact about a date.

Which means the engine has to hold abolished rates deliberately, keep them tested, and pick by the date on the document rather than the date on the calendar. That is about forty lines of unglamorous code and a table nobody will ever compliment you on. It is also the difference between a system you can hand an inspector and one you have to apologise for.

A rule we got wrong, and what it taught us

It would be dishonest to argue all this without showing you one of ours.

Finnish deductibility rules treat alcohol differently from other purchases, so the engine looks at what a receipt actually says. Among the words it watches for is olut — Finnish for beer. Straightforward, correct about the law, and tested against a pile of real receipts where it did exactly the right thing.

Then a customer's telephone bill came back flagged as alcohol.

The bill carried an English line describing a service package. Somewhere in it was the word solution. And olut sits inside s·olut·ion, letter for letter. The rule was not matching words; it was matching letters that happened to be adjacent. Every test had passed because no test receipt had ever contained an ordinary English business noun.

The fix is four characters — a word boundary — and takes a minute. That is not the interesting part.

The interesting part is what happened next, and it is the argument of this entire piece in miniature. Because the rule was deterministic, we could ask the database exactly one question — which entries did this rule decide, ever — and get a finite, named list back. Every affected entry was re-derived under the corrected rule. The customers whose numbers moved could be told which entries changed and why, in a sentence, with the old value still visible beside the new one.

Now imagine the same mistake inside a model. There is no rule to grep for, no list of entries it touched, no way to distinguish the ones it got wrong from the ones it got right for the wrong reason. You would fix it by retraining or by rewriting a prompt, and then you would have a system that behaves better from Tuesday onward and a past you cannot speak about. The bug would not be smaller. It would be invisible, which is worse.

We wrote the word-boundary lesson down in the codebase next to the rule, which is where lessons belong. The version in this article is the public one.

ViDA raises the stake

The EU adopted the VAT in the Digital Age package on 11 March 2025; it entered into force on 14 April 2025 and rolls out in stages through to 2035. The part that matters here: from July 2030, intra-Community supplies of goods and services come under digital reporting requirements and structured e-invoicing.³

Today, a classification you cannot explain is an awkward conversation with your accountant, usually in March, usually resolved by somebody remembering something. After 2030 it is an unexplainable filing — structured, submitted close to real time, and sitting in a system that can compare it against what your counterparty reported about the same transaction.

The direction is one-way. Every year, the gap between a confident guess and a defensible record gets more expensive, and it gets more expensive faster than models get better. That asymmetry is the whole bet.

Six questions worth asking any vendor

Including us. These are the questions we would want asked, because they are the ones that separate the two kinds of system, and none of them can be answered with a screenshot.

• Show me the rule behind this classification, by name.Not a summary of the law — the provision, and a link that opens it.
• Does the same document classify the same way twice?Ask them to run it twice in front of you. This takes eleven seconds and is remarkably clarifying.
• When the system is unsure, does it say so, or does it pick?A tool with no “I don’t know” state has one, it just isn’t showing you.
• What happens to last year's entries when you change model?If the answer involves re-running anything, ask what the old answers were.
• Can I export the reasoning, not just the number?The number is what you filed. The reasoning is what you defend.
• Who can change a past entry, and does the change leave a mark?“Only admins” is not an answer. “It can’t be changed, only superseded” is.

The boring answer

The interesting engineering in this field is no longer getting the model right more often. That curve is flattening and everyone is on it.

The interesting engineering is making sure that when the system is wrong you find out, and when it is right you can prove it — six years later, to somebody who was not in the room, using software that has been rewritten twice since.

Accuracy is a claim you make about your software. Auditability is a claim your software can make about itself. Only one of those is worth anything on the day it is tested.