Every system we implement follows one rule: AI reads, classifies, and proposes, while deterministic code handles critical decisions and every calculation. Wherever money is involved — taxes, contributions, valuations, balances — that’s the only responsible division of roles we know.
What AI actually does, and what code does
Language models excel at tasks where understanding context matters: reading an invoice in an unusual format, figuring out what a customer means in a message written in plain, informal language, spotting information in a document that a human would notice instantly but a rigid parser would miss. These are tasks where “mostly right” is a reasonable starting point, one you can keep improving iteratively.
Tax calculations, social security contributions, balance computations, or decisions with direct financial or legal consequences follow a different logic entirely. There’s no room for “mostly right” here — a result is either correct or it isn’t, and even if a model gets it right in the vast majority of cases, a single mistake in a system that touches money is real harm to a real customer.
That’s why, in our implementations, we draw this line explicitly: AI is responsible for reading, classifying, and proposing — code is responsible for calculating and deciding. These two roles never blend together in a single step of the system.
Why this matters specifically in finance
Language models can get things wrong — that’s not a flaw specific to one vendor or one model version, it’s a property of the technology itself. In applications where a mistake means a wrongly issued invoice or an incorrectly calculated tax, that risk simply can’t be accepted without a safeguard.
Deterministic code has a different property: given the same input, it always returns the same output, that output can be tested, traced, and — just as important — explained during an audit or a compliance check. A language model doesn’t have that property by definition. That’s why, in places where repeatability and accountability for a result matter, code handles it, not the model.
This isn’t a limit we impose out of process-driven caution — it’s a condition an AI implementation in the financial domain shouldn’t go into production without.
An example from our own product
This principle shows up most clearly in Qkwit, our AI-powered accounting product for sole proprietors. Claude reads accounting documents — invoices, receipts, confirmations — and extracts the data from them: amounts, dates, categories, counterparties. This is a task that fits a language model’s strengths perfectly: documents vary widely, scans are often low quality, and a model handles that variability far better than a rigid parser ever could.
The actual calculation of tax and social security contributions from that data, however, is handled by a deterministic engine, not the model. We wrote more about how AI accounting compresses bookkeeping time for sole proprietors — all the time savings come from AI removing the tedious reading and data entry from a person’s plate, not from the model “calculating taxes” in place of an accountant or a computation engine.
The same pattern shows up in Brokik, our rental management platform running in 25 countries. AI adapts documents and pricing to a specific rental case, but what a lease agreement in a given market must actually contain follows from that country’s local rental law and its assigned templates — not from whatever the model considers appropriate at the moment. The model proposes the content, while the document’s final shape follows rules set in advance, not rules generated by AI from scratch.
We apply the same pattern anywhere automation touches decisions with real consequences for a customer — with a clearly defined point where the system escalates to a human once a situation goes beyond what it can safely resolve on its own.
What happens when that boundary isn’t clear
When a system’s design doesn’t draw a clear line between the model’s suggestion and the code’s decision, a language model will sooner or later start informally “deciding” things — not because anyone designed it that way, but because nobody designed it otherwise. In practice, this means that when an error shows up, it’s hard to trace: you can’t tell whether it came from the model misreading a document, a flawed rule in the code, or no rule at all. The same problem applies to accountability — during an audit or a complaint, it’s hard to explain a result that emerged somewhere between a suggestion and a decision without a clear split between the two stages. Separating these two layers from the very start of the design eliminates this problem before it ever appears.
What this means for an implementation in your company
If you’re planning an AI implementation in an area that touches money — invoicing, settlements, valuations, credit limits — it’s worth answering three questions right at the design stage: exactly what should the model read and propose, exactly what should code calculate and decide, and where does a human get visibility and the ability to correct something. If you can’t draw those boundaries clearly on paper, that’s a sign the system design needs more work before it goes into production.
Good architecture for this kind of system almost always logs both layers separately: what the model proposed and why, and what decision the code ultimately made. That way, if something goes wrong, you can pinpoint exactly where — instead of searching for the cause inside a black box.
FAQ
Should AI never touch numbers at all? It can read them, extract them from documents, and organize them — but it shouldn’t independently perform calculations that have direct financial consequences. Those are handled by deterministic code, working from the data the model prepared.
Doesn’t this kind of separation slow down implementation? In practice, it’s the opposite — clearly separated roles make each one easier to test on its own and shorten the time needed to find and fix a bug once one shows up.
How do you tell if a vendor actually applies this separation, rather than just talking about it? It’s worth asking directly where in the system the model’s suggestion ends and the code’s decision begins — and asking them to show that boundary with an actual example from logs, not a slide.
Does this principle apply only to accounting, or to finance more broadly? It applies to any system where a mistake means a concrete financial loss or a legal consequence — accounting, banking, valuations, settlements. The same logic holds everywhere.
Can a model take part in making a decision at all, or only in preparing it? A model can prepare a recommendation and a justification, but the final decision with financial consequences should sit in the deterministic code layer, with the ability to escalate to a human wherever a situation is ambiguous.
Should this separation be documented at the design stage, or can it be added later? It’s much better to do it upfront. Drawing the line between suggestion and decision after the fact, once both roles are already tangled together in a single step of the system, is far harder and more costly than designing it in from the start.
If you’re wondering how to design this kind of role separation for a specific process in your company, get in touch — we’re happy to walk you through what it looks like in practice, using our own products as the example.