Accountants and tax advisors on our platform process close to a million documents every month. From coffee receipts to multi-page invoices with 60+ line items, scanned PDFs, documents that bundle a purchase order, payment terms and the invoice itself, foreign invoices with special VAT treatment.
After two months of testing with ~100 beta customers, we're now rolling out a line extraction and accounting coding agent that transforms what accountants can expect from automated bookings. An agent that knows your GL accounts, understands local VAT regulations, and actually reasons over every line of each invoice.
Our metrics show 90+% accuracy per field (not per invoice, but per field on each line) across a real mixture of document complexities, all from day one for customers with no history and no rules. That accuracy climbs with our brand-new learning mechanism. The distinction between predicting accounting attributes at the invoice level vs the line level matters: effectively every tool we've compared head-to-head doesn't just fall short on line-level coding. They don't support the proper notion of lines at all.
Where accounting automation falls short today
In January we wrote about our ML-based Coding Agent, the per-organisation system that learns from every accountant correction and predicts accounting codes automatically. Nearly 100,000 customer-specific ML models make 2+ million predictions a month. That system is strong and outperforms, accuracy-wise, the manual rules set by users themselves. Plus it keeps improving.
But there are problems that ML models and rules alone can't solve. Documents are complicated and surface common problems. Line items span pages, discount rows modify the items above them, VAT summaries on the last page reference rates that don't appear next to the individual lines.
Getting the lines out of a document reliably is hard enough. Identifying what each line represents, what VAT treatment applies, and which expense account it maps to requires reasoning that pattern-matching and rule engines weren't designed for. Zero-shot predictions, i.e. coding an invoice from a supplier you've never seen, are essentially non-existent with these approaches. You need history or you need rules, and neither is available on day one.
But we changed that.
Why line-level matters
A hotel bill bundles accommodation, meals, parking, and minibar charges, each taxed at a different VAT rate under European rules, and each belonging to a different expense account. A facilities management invoice mixes cleaning supplies, equipment rental, and consulting hours across three pages. These aren't unusual documents. They're what accountants process every day.
And the same line can require entirely different treatment depending on the business. A restaurant buying food codes it as cost of goods sold. An IT company buying the same food for a team event codes it as hospitality, with a different expense account and different VAT treatment. The agent needs to understand the customer's industry, their chart of accounts, and country-specific VAT rules and exemptions, not just read what's on the page.
When your tools only support invoice-level predictions, whether through rules or ML models, you get one prediction for the entire document. The accountant still has to open it, read every line, create separate expense lines, group them by shared attributes like VAT code, and manually code each expense account. That's the job and that's what takes time.
What we built
We've supported line extraction previously, but have completely rebuilt the capabilities and incorporated proper line-level reasoning over how each line should be coded. There are two stages, each solving a distinct problem:
Line Extraction. The agent reads the full document and extracts every individual line item with its description, quantity, unit prices, amounts, and VAT information. The challenge lies in handling the complexities of real documents — combined files, line items spanning page breaks, discount rows, summary tables that aggregate differently than the detail sections, VAT breakdowns referencing rates that don't appear next to the line items.
Accounting Classification. For each extracted line, a second agent predicts the full accounting treatment. It navigates the customer's own chart of accounts and country-specific VAT rules, including reverse charge scenarios (where the buyer, not the seller, accounts for VAT), reduced rates, and non-reclaimable VAT. Because we know the customer's industry and registration country, the agent applies the right rules to the right business.
We learned early that the user experience of surfacing results is as important as the quality of the predictions themselves. We built a confidence-tiering system that shows accountants where to put their attention: high-confidence predictions are applied automatically, low-confidence fields are flagged with the most likely alternatives. This drives the level of automation for each expense. Some invoices need no human input at all, while others surface a handful of fields for review.
Even on the first invoice from an unknown supplier, the agent produces a highly qualified prediction. By the second or third occurrence of a similar document, predictions sharpen and more fields auto-apply. This isn't just the case with the same supplier, but also the same type of document. This is because the agent recognises that an Uber receipt, a Bolt receipt, and a local taxi invoice are all taxi expenses.
Architecture: splitting the problem
An accountant reviewing a complex invoice follows a natural sequence. First, understand the document's structure, including how many pages, what's a line item, what's a summary. Then extract the individual items. Then code each one. We follow the same logic, but the reason we split it into explicit stages goes beyond mimicking human behaviour. We need to see the output of each step, measure its quality independently, and iterate on one stage without destabilising the others.
Where to draw the boundaries is a trade-off we iterated on extensively. Too few stages and a single change can have unpredictable ripple effects. Too many and you add latency, cost, and complexity without improving results.
Document structure analysis. Before extracting anything, the agent maps the document: which pages carry line items, where the VAT summary lives, which pages contain purchase orders or payment terms rather than billable items, whether there are discount or adjustment rows, what the column layout looks like.
Page-level extraction with built-in review. The target pages are then processed in parallel. Each extraction is reviewed for mathematical consistency (does quantity × unit price = line total?), completeness (are there visible lines that weren't extracted?), and coherence with the broader document structure. When something doesn't add up, the extraction reruns with targeted feedback.
Cross-document reconciliation. After all pages are processed, extracted totals are checked against the document's own summary. Tight tolerances apply here and a discrepancy of more than a fraction of a percent is flagged.
Per-organisation classification trees. For the accounting step, we build decision trees from each customer's chart of accounts and VAT configuration. The agent navigates these trees for each line item. When an organisation adds a new expense account or restructures their cost centres, the tree regenerates.
This staged approach makes errors traceable. When a line is miscoded, we know where it went wrong: extraction, document structure, or classification. In accounting, that traceability isn't optional because a miscoded VAT rate is a compliance issue.
Evaluating an agent that must be right
We evaluate on two key dimensions.
Accuracy. We maintain golden datasets, with accountant-labelled invoices spanning the hardest cases we encounter in production: reverse charge scenarios, mixed VAT rates across jurisdictions, discount structures, credit notes. Every extracted field is compared against the labelled truth. We continuously expand this dataset with production cases, biased toward complexity. If the agent handles a 50-line invoice with contradicting VAT summaries, the straightforward cases take care of themselves.
Reproducibility. Same input should produce the same output. Accountants expect deterministic systems. We run each test case multiple times, measure consistency across runs, and consider variance a bug. Improving reproducibility was a harder problem than we anticipated. To tackle it we iterated on everything from adjusting prompts to using different models per stage to breaking down tasks into separate sub-steps.
Both dimensions are tested in CI. Every prompt change, every architectural modification, every model swap runs through the pipeline before reaching production. We evaluate model releases across providers continuously, not just for accuracy, but for the accuracy-reproducibility-latency trade-off that determines whether a change actually gets shipped.
What the agent gets wrong
In production we trace every correction accountants make to extracted data and agent-predicted codings for every field on every line.
For fields read directly from the document (amounts, quantities, descriptions, VAT rates) tolerance for error is very low, and extraction accuracy reflects that. The remaining errors fall into patterns:
Expense accounts that require business context. The agent knows the customer's industry and chart of accounts, and handles industry-level distinctions well. Where it gets harder is when an organisation has six expense accounts that could all reasonably apply, and the right answer depends on internal conventions the agent hasn't yet learned. After a few corrections, it converges. This is where our learning mechanism, combining RAG retrieval of similar previous line bookings with ML models trained on historical corrections, closes the gap. These two systems are equally important: the LLM provides the reasoning, the learning mechanism provides the customer-specific context.
VAT treatment that depends on circumstances. European VAT rules are country-specific, full of exemptions, and context-dependent. A catering invoice showing 7% VAT (German reduced rate for food) might be recoded to 0% by the accountant because VAT on food for internal consumption isn't reclaimable. The document doesn't say the food was for internal use. Either additional notes need to accompany the expense, or the accountant makes a judgement call based on context the invoice simply doesn't contain. Over time, correction patterns make the agent better at these calls for each specific customer.
The pattern that has resonated strongly with our beta customers: the agent's initial prediction must be consistently in the right neighbourhood. Corrections and qualitative input from the user then refine it toward each organisation's specific conventions. Every correction is traced and fed back into the learning mechanism.
Benchmarking
We've run head-to-head comparisons against emerging AI accounting platforms on genuinely difficult invoices.
On line-level extraction, which is a surprisingly hard task in its own right, most tools barely consider the notion of individual lines. At best, you get highly aggregated results. The majority collapse entirely when they encounter real-world complexity: summary pages, lines that span multiple pages, discount structures that modify other rows. Our agent extracts and codes each line individually on documents where other tools return summary-level groupings at best.
On first-shot prediction of accounting attributes (expense accounts, VAT codes, cost centres) per line and per field, we see no comparable platform operating at this level of granularity and accuracy. Other tools can't produce line-level field predictions because they don't do line-level extraction. Our learning infrastructure then pushes per-field accuracy into the very high 90s for customers with correction history. We believe this combination of strong zero-shot reasoning with a per-organisation learning mechanism is unmatched.
What's next
Confidence. Calibrating confidence is genuinely hard, and LLMs are inherently bad at it. We're experimenting with multiple approaches, including supplier-based confidence, expense-type-based confidence, weighing historical precedence against pure reasoning. Getting this right determines how much of the accountant's attention we can save. Too cautious and every field is flagged; too aggressive and errors slip through. There isn't one solution. At least, we haven't found one yet.
Better reasoning, not just better recall. The learning mechanism today draws heavily on similarity to past transactions and historical corrections. That works well for recurring patterns. But some of the hardest accounting decisions require understanding company-specific conventions that aren't captured well by "what did we do last time". This includes internal policies, evolving cost allocation strategies, and exceptions that depend on context outside the document. We think there are substantially better ways to consume and reason over these kinds of inputs than pure similarity matching, and that's where we're investing next.
What are the main learnings?
Line-level is the job. Any tool that claims to automate accounting but operates at the invoice level is solving a fraction of the problem. The work is in the individual expense lines.
Reproducibility before accuracy. A system that gives different answers on different days can't be trusted for accounting. Consistency is not negotiable.
The learning mechanism is the moat. Strong zero-shot reasoning gets you a good first prediction. Per-organisation learning from every correction gets you to 98%+. That's not something you replicate by switching to a better base model.
UX is half the product. Line-level extraction creates a new problem: accountants now see 30, 50, 90 individual line items where they used to see one summary. Without the right tools — automatic grouping, bulk edits, merging, inline corrections, confidence indicators — that detail becomes overhead instead of value. Building the review and manipulation layer is as important as building the extraction model.
