AI invoice processing reads a supplier invoice — from the email body and its attachments — extracts the fields into a strict schema, then hands the result to deterministic finance controls that match it against the purchase order and goods receipt, check price tolerances, reconcile VAT and screen for duplicates, before deciding to post it or hold it as a query with an explicit reason code. The AI does the reading. Fixed rules do the deciding. That division is the whole point, and it is what earlier "OCR plus RPA" systems never got right.
This piece walks the pipeline end to end, explains why the previous generation fell short, sets out which controls must stay deterministic and where bounded AI judgement genuinely helps, covers the UK audit-trail requirements that constrain the design, and gives accounts payable teams the questions to put to a vendor.
Key takeaways
- Modern AI invoice processing extracts from both the email body and attachments into a schema-constrained output, so the finance system receives structured data, not free text.
- The finance controls — purchase-order and goods-receipt matching, price tolerance, VAT reconciliation, duplicate detection — must stay deterministic. AI reads; fixed rules decide whether to post.
- "OCR plus RPA" struggled because template-bound extraction broke on layout variety and brittle scripts could not handle exceptions, so the hard cases fell back to people anyway.
- UK VAT law requires most businesses to keep VAT records for at least six years and to hold a valid VAT invoice as evidence to reclaim input tax — the audit trail is a legal requirement, not a nicety.
- The main implementation risks are double-posting and weak test/production separation; both are design problems you must ask a vendor to prove they have solved.
The pipeline, end to end
A well-built system moves an invoice through distinct stages, and the boundary between "AI" and "rules" sits in the middle of that chain, deliberately.
Ingest. Invoices arrive by email, portal or scan. The system captures the message and everything attached to it, and records where each item came from. This matters because a single email may carry the real invoice as a PDF while the body contains a summary, a different total, or nothing useful at all.
Multi-source extraction. The AI reads across the email body and the attachments, because suppliers are inconsistent about where they put the numbers. It pulls supplier identity, invoice number, dates, line items, net, VAT and gross, along with any PO reference. Crucially, the output is schema-constrained: the model must return the fields in a fixed structure with the right types, rather than a paragraph a downstream system then has to parse. Constrained output is what makes the next stage deterministic.
Deterministic finance controls. Now fixed rules take over. The extracted invoice is matched against the purchase order and the goods-receipt record; the price is checked against tolerance; the VAT is reconciled; and the invoice is screened against history for duplicates. None of this is left to a model's judgement, because these are exactly the checks a finance team must be able to reproduce and defend.
Post-or-query decision, with reason codes. The system posts the invoice only when the controls are satisfied. When they are not, it does not guess — it holds the invoice as a query and attaches an explicit reason code: no matching PO, price over tolerance, VAT mismatch, suspected duplicate, missing goods receipt. In our own build the design rule is simple: clean invoices post untouched, and exceptions arrive with a reason code, so the person who picks them up already knows why the invoice stopped. This is the same confidence-floor and reason-code pattern we apply across our finance work.
Why "OCR plus RPA" fell short
The previous generation paired optical character recognition with robotic process automation: OCR read the document, RPA scripts pushed the data into the finance system. It worked in the brochure and struggled in the post room.
Template-based OCR was the first weakness. It depended on knowing roughly where each field sat on the page, so it coped with a handful of known layouts and broke on the long tail of supplier formats. Every new template was a change request.
RPA was the second. Scripted automation is deterministic in the wrong way — it follows a fixed sequence and has no capacity for an exception. The moment an invoice did not fit the happy path, the script either failed or, worse, pushed something incorrect. Because the hard cases are precisely the exceptions, the difficult invoices ended up back with people, which was the work the system was bought to remove.
Modern extraction models handle layout variety without per-template configuration, which is a genuine step change. But that only shifts the risk: a model that can read anything can also confidently misread something. That is why the deciding must not be left to the model.
What must stay deterministic, and where AI helps
The design principle is a clean split. Let bounded AI judgement do the reading and interpretation; keep the money decisions in fixed rules.
Keep deterministic: whether an invoice matches its PO and goods receipt; whether a price is within tolerance; whether VAT reconciles; whether an invoice is a duplicate; and the final post-or-query decision. These are the controls an auditor, an HMRC officer or your own finance director will expect you to reproduce exactly, every time, for every invoice. A probabilistic answer here is a liability.
Let bounded AI help: reading fields from messy documents; associating a line on the invoice with a line on the PO when the wording differs; classifying an invoice type; and drafting the explanation that accompanies a query. In each case the AI proposes and a deterministic rule — or a person — disposes. The judgement is bounded because the model's output is constrained and its conclusions are checked, never trusted blind.
A useful test: if you cannot explain a decision to your auditor without saying "the model decided", it is on the wrong side of the line.
The audit trail is a legal requirement
In the UK the record-keeping is not optional. HMRC requires businesses to keep VAT records for at least six years, as set out in Record keeping (VAT Notice 700/21), and to hold and keep the VAT records and invoices that evidence the tax. A valid VAT invoice is the evidence that supports reclaiming input VAT; without it, the reclaim is exposed.
For an automated system, that has concrete consequences. Every posted invoice needs a durable record of what was extracted, which controls ran, what they returned, the reason code where the invoice was queried, and who — person or rule — made the final decision. The right artefact is an append-only decision ledger: a record that cannot be quietly edited after the fact, because a record that can be changed is not evidence. If your automation posts VAT to the ledger but cannot show, six years later, why a given invoice was posted, the efficiency you bought has created a compliance gap.
Questions AP teams should ask a vendor
- Where does extraction read from? Confirm it reads the email body and attachments, not just the first PDF it finds.
- Is the extraction output schema-constrained? You want structured fields with types, not free text the finance system has to re-parse.
- Which decisions are deterministic? PO/goods-receipt matching, tolerance, VAT reconciliation and duplicate detection should all be fixed rules, not model calls.
- How are exceptions surfaced? Every held invoice should carry an explicit reason code, so your team knows why it stopped without investigating from scratch.
- How do you prevent double-posting? Ask for the specific mechanism — idempotency keys, duplicate screening, a post-once guarantee — not a reassurance.
- How is test separated from production? You do not want a test run posting real invoices to the live ledger.
- What audit record survives? Confirm an append-only trail that meets the six-year VAT retention requirement and reconstructs any single decision.
Implementation risks to design out
Two risks dominate. The first is double-posting: an invoice that is processed twice and posted twice, from a retry, a resend or a race condition. The defence is a hard, deterministic duplicate guarantee, not a hopeful check. The second is test and production bleeding together: automation that cannot tell a dry run from the real thing will eventually post something it should not have. Both are solvable, and both are exactly the questions a serious vendor will have crisp answers to.
Where to start
If your accounts payable team is keying invoices by hand, chasing PO mismatches and re-checking VAT, the work is well suited to automation — provided the finance controls stay deterministic and the audit trail is built to survive HMRC's six-year retention rule. That is precisely how we designed InvoiceIQ: multi-source extraction into a strict schema, deterministic matching and VAT controls, reason-coded exceptions, and an append-only record of every posting. Clean invoices post untouched; the exceptions arrive with a reason.
Last reviewed: 10 July 2026.
Sources: Record keeping (VAT Notice 700/21) — GOV.UK · Charge, reclaim and record VAT: keeping VAT records — GOV.UK
