Every accounting package that promises automation has a screen full of rules somewhere. If the supplier is Proximus, book it to 613400. If the description contains "fuel", book it to 612100. In a file that has been running for a few years, that screen holds hundreds of lines. Nobody remembers exactly why that one rule from 2021 is there. Nobody dares delete it.

And still, every month, there is manual work in that same file.

Not because the rules were written badly. Because a rules engine breaks down precisely at the point where bookkeeping gets interesting.

Why rule-based automation hits a ceiling

Rules are excellent at the frequent and useless at the exceptional. You can automate the bulk of a file in an afternoon: the regular suppliers, the recurring costs, the subscription that posts the same amount to the same account every month.

The remainder is the problem. It isn't one pattern you haven't captured yet. It's a thousand one-off cases that would each need their own rule. The supplier who invoices once a year. The invoice with three types of cost mixed together. The contract that runs across two financial years. To catch those, you'd have to write a rule you will never use again.

There's a second, quieter cost. Rules are brittle. A supplier changes their invoice layout or their wording, and the rule simply stops firing. It doesn't throw an error. It does nothing. You find out when someone reviews the balance sheet.

The deeper reason is that a rule doesn't know what an invoice means. It only knows what it literally says. It can match, not understand. And every exception you bolt on makes the whole thing harder to maintain, until maintaining the rules costs as much time as the work they save.

What actually changed

A model that reads an invoice does something other than matching. It sees the invoice itself: the document, not just the extracted fields. On top of that it gets the context an experienced bookkeeper would have. The complete chart of accounts for this file, what this file has historically done with this supplier and with line items like these, the VAT regime, and the accounting standard of the country being booked in, whether that is the Belgian MAR, the Dutch RGS or a UK chart of accounts.

And it works line by line, not invoice by invoice. An invoice with software, hardware and shipping on three lines gets booked to three accounts, without anyone having written a rule for it.

The second difference is less visible but weighs more: this isn't only about the GL account. In practice a rules engine could do one thing properly, which was mapping an account to a supplier. A booking is far more than that. The VAT code, the journal, the payment terms, the payment method, the analytical distribution across possibly several plans, the booking period, the accruals for contracts that cross the year end, and the booking description. Those are the fields where the time actually goes, and precisely the fields almost nobody ever wrote rules for, because it couldn't be done.

The last 10%: from mechanics to policy

So are rules gone? No. There is a remainder no model can derive from an invoice, for the simple reason that it isn't in there: your agreements.

That all cloud software goes to one account at your company, even when the supplier bills hardware alongside it. That with this one supplier you want Recupel split out. That a particular cost type always goes to a specific analytical plan. That isn't accounting truth, that's house style.

And that remainder turns out to be measurable with some precision. Across the ten most active files on our platform, 89% of incoming invoices went through booking without any human intervention. What's left over isn't twenty or thirty percent of manual work. It's roughly one invoice in ten.

But the shape of those rules has fundamentally changed, and that is the point of this whole story.

A rule used to be mechanics: a condition and a consequence, which you had to express in the system's language. If field X contains value Y, then set field Z.

A rule is now policy, written in plain language. One sentence, at the level of the organisation or of one specific supplier. That sentence travels along as context when the invoice is booked.

The difference isn't cosmetic. A rule that doesn't match exactly does nothing. An instruction that doesn't fit exactly gets interpreted. Write "we book software to 613500" and it also covers the licence the supplier calls a "subscription fee". With a rules engine you'd have had to anticipate that second wording yourself.

The result is that the number of rules collapses. Not hundreds of conditions, but a handful of sentences that together describe your accounting policy, and that a new colleague can simply read.

What is not left to AI

For an accounting audience this is the question that matters, so let's answer it directly: the model is allowed to interpret, but it is not allowed to do just anything.

It can only choose accounts that exist in that file. An invented account number never makes it into a booking. Accounts you exclude are hard-blocked, and are ignored even when they show up in the history. VAT code and GL account are checked against each other; when they contradict, the proposal goes back through instead of passing.

And every proposed field carries its reasoning: why this account, why this VAT code, why this analytical plan. That may be the biggest break with the rules engine. A rules engine could never tell you why something was booked the way it was. It could only show which rule had fired, and that is not the same as a reason.

What you're left with is a booking that's ready, with a justification attached, waiting to be approved.

What this does to the work

The role shifts from data entry to oversight. You no longer review every invoice, you review the exceptions. The question put to the bookkeeper changes from "where do I book this?" to "is what's in front of me correct?", and that second question is the one people hire a bookkeeper for.

A whole category of work disappears too, one nobody ever billed for: maintaining the rules file. No more writing a rule for every new supplier. No more archaeology on that one mapping from 2021.

There is one more advantage hidden in that difference, and it only shows when somebody leaves. With a rules engine the knowledge sits in the head of whoever wrote the rules, and the file itself is unreadable to everyone else. With policy in plain language, the agreement is literally written down, and the rest sits in the file's own history. That knowledge doesn't walk out the door when someone leaves the company, and it doesn't stall when someone is on holiday for two weeks.

The cost nobody invoices

There is one cost that rarely makes it into the comparison. A rules engine isn't free just because no licence is attached to it. It costs maintenance. Somebody writes the rules, somebody tests them, somebody works out why that one from 2021 is there. That work appears on no invoice, but it does appear in the payroll.

Put the numbers beside it. Research firm Ardent Partners measures every year what a purchase invoice actually costs, wages and systems included. For largely manual processing that is €11.85 per invoice, and for the best automated teams €2.56. In Belgium the gap weighs heavier still: at an average labour cost of €48.20 an hour, the time that goes into rekeying and correcting is among the most expensive in Europe.

And then the figure that puts it all in proportion. On average, 32.6% of invoices are processed touchless, just under half for the front runners. For us that number is 89%.

Let's stay honest about the limits: this is not "the AI does everything". There is spread behind that 89% average. Some files sit at 100%, dozens of invoices in a row fully automatic, and others sit lower. Differences like that are rarely about the software and almost always about how pronounced a file's house rules are, and whether they're written down anywhere.

Because that's the other side of it: an agreement recorded nowhere cannot be guessed by any system. You turn that into a sentence yourself. And a file that's just starting has no history to fall back on, so it needs a moment to warm up.

In closing

The shift fits in one sentence. You used to have to explain to your software how to think. Now you tell it what the agreement is at your company, and it does the rest.

The rules didn't disappear. They finally changed jobs.

The full calculation, broken down by invoice volume, is in our guide "The hidden cost of manual invoice processing".

— We spent years trying to make bookkeeping automatic by describing every case in advance. What has changed is not that the rules are gone, but that the only thing still worth writing down is what is genuinely specific to your own company. The rest the model works out from the file itself. - CTO, Jonathan Callewaert.