At Queli, we spend a lot of time inside industries where getting things wrong has consequences. Not “the dashboard looks bad” consequences. More like “Porezna sends an inspector and your client gets fined” consequences.
That changes how you think about AI architecture. Completely.
The problem with “just use AI”
Many AI products in accounting, tax, customs, payroll and compliance follow the same playbook: take a messy manual process, point a language model at it and hope the output is right. Sometimes it works. Sometimes it invents a tax rate. Sometimes it sums 14 invoices and gets 13. Sometimes it classifies a restaurant dinner as a standard business expense when Croatian VAT rules treat business entertainment differently.
In regulated work, “mostly right” can be worse than obviously wrong. An obvious error gets caught. A plausible classification can sail through review and become a liability.
We kept running into this when we started working on tax and reporting workflows for Croatian businesses. AI was useful for some parts and the wrong tool for others. So we stopped trying to make it do everything and asked a different question: what should AI actually be responsible for?
The architecture we landed on
We call it the sandwich internally, because the AI sits between two layers of deterministic software.
The bottom layer handles things with one verifiable answer: parsing structured files, validating identification numbers, checking EU VAT registrations, testing whether invoice arithmetic reconciles within the permitted rounding tolerance and finding gaps in sequential numbering.
There is no reason to make a language model authoritative for any of this. Conventional software is faster, cheaper and repeatable.
The middle layer is where AI is useful. It receives the validated source data, the company’s business context, prior records and corrections from earlier cycles. It can then propose classifications and explain why something deserves attention. Is this transaction domestic, intra-EU or third-country? Does this supplier line resemble a known product class? What might explain a mismatch between source documents and the accounting record?
These questions depend on context. A fuel invoice means something different for a logistics company with a commercial fleet than it does for a consulting firm. A model that sees the relevant company, supplier, transaction and correction history can prepare a better recommendation than one looking at a single invoice in isolation.
But the model does not become the ledger. In our design, it does not supply the authoritative sum, generate the final XML or calculate the tax liability. It proposes a classification and explains the context it used.
The top layer then applies deterministic rules to the reviewed classification. It aggregates approved records, maps them to the required fields, generates files that conform to the target schema and runs reconciliation checks.
Then a person reviews the exceptions: uncertain classifications, unusual transactions, missing evidence or results that differ from the expected baseline. The review surface is a queue of decisions, not another data-entry form.
Why this split matters
Language models can work across messy context, but exact arithmetic should not become true merely because a model returned it. Code is dependable when the rule has one correct answer, but brittle when meaning depends on the client, transaction and prior decisions.
We think many regulated AI systems blur that boundary. They ask the model to do both jobs, then add guardrails around the inevitable failures.
Our preference is simpler. If a result can be calculated, validate it with code. If a classification depends on context, let AI prepare the recommendation. If the decision has financial, legal or operational consequences, keep the responsible person in the loop.
This split also limits how much data and model work a process needs. The AI touches the part that benefits from interpretation. Parsing, validation, calculations, schema generation and reconciliation stay outside the model call. That makes the workflow easier to test and easier to explain when someone asks where a number came from.
What this looks like in a real workflow
One of our public case studies follows a European automotive parts company that receives multilingual supplier invoices with supplier-specific rules. Before Queli, an employee re-entered every header and line item into the ERP. At month-end, the same team translated product descriptions, looked for the appropriate CN codes and estimated net mass to prepare Intrastat.
Makra now extracts the invoice, applies the relevant supplier rules and prepares the ERP record for review. The Intrastat workflow uses the reviewed invoice data, prior classifications and the company’s own knowledge base to suggest Croatian descriptions, CN codes and net mass. The person responsible sees the source and confirms the exceptions.
The invoice process went from four to five minutes of manual entry to about five seconds of preparation. Intrastat preparation went from roughly two weeks to about two to three minutes. Those are results from one client workflow, not a promise that every company will see the same numbers. The part that generalises is the architecture: source evidence first, deterministic checks, contextual preparation, human review and a verifiable output.
Read the invoice-processing case study and the Intrastat case study.
The pattern repeats across regulated work
The same boundary appears in other processes.
In payroll, rate lookups and calculations are deterministic. Classifying an unusual payment or deciding whether an exemption applies can require context and review.
In customs, tariff tables, document completeness and value calculations can be checked mechanically. Product classification and origin questions can be ambiguous, particularly when similar descriptions lead to different codes or treatment.
In environmental reporting, formulas, factors and thresholds belong in tested code. Mapping a real business activity to a reporting category can require evidence and specialist judgment.
The point is not that one architecture solves every regulated industry. It is that each workflow should separate what can be proven mechanically from what must be interpreted—and separate both from the decision a qualified person remains responsible for.
What changes when the system remembers corrections
This architecture has another useful property: normal review creates structured memory for the next cycle.
If a specialist changes a suggested classification, the system can retain that correction with its source and reason. When the same supplier, product or exception appears next month, Makra can bring the earlier decision back into context. The person is not training a model as a separate task. They are reviewing the work they were already responsible for, while the process stops forgetting what they decided.
That memory must remain governed. A correction from one company should not silently become a rule for another. The useful asset is the client’s own decision history: which facts mattered, which exception was accepted and who approved the final treatment.
Operational software becomes more valuable over time when fewer people have to rediscover the same answer in old emails, spreadsheets and monthly working files—not when it makes itself autonomous.
The regulatory shift that makes this urgent
Croatia’s 2025 Fiscalization Act brought the central e-invoice and e-invoice fiscalization provisions into force on 1 January 2026. For domestic transactions covered by the law, the invoice is structured, exchanged through defined access points and accompanied by detailed fiscalization data.
That changes where the hard work sits. Less value comes from repeatedly retyping information that already exists in structured form. More value moves to validating the source, resolving mismatches, applying the company’s actual business context and recording why an exception was treated a certain way.
The direction is not limited to Croatia. The European Union adopted the VAT in the Digital Age package in March 2025. Its measures are being phased in through 2035, with digital reporting requirements for cross-border B2B transactions scheduled from July 2030.
Electronic reporting does not remove judgment. It makes weak judgment easier to see. The tools should be built for that reality: deterministic where the answer must be exact, contextual where the evidence needs interpretation and explicit about the person who owns the final decision.
Queli builds AI systems for recurring business work across documents, messages and existing software. If a regulated process still depends on retyping, chasing context and rebuilding the same report, tell us where it gets stuck.