Invoices that process themselves, up to the point a person's judgement is needed
Invoice processing automation moves a supplier invoice from arrival to payment without anyone rekeying the figures. It is accounts payable automation aimed at one job: getting a bill into your accounts package correctly, without paying it twice. Most of the pipeline is deterministic rules, AI reads only the fuzzy part (the invoice itself), and a person checks the exceptions before any money moves.
The manual version is familiar: PDFs arrive by email, someone retypes each one into the accounts software, and month-end brings duplicate payments and missing bills. Automated invoice processing removes the retyping and catches the duplicates first.
What invoice processing automation actually does
Underneath, this is a pipeline, not a black box. Each stage does one job and hands the invoice on, and only two of them need anything cleverer than a rule.
In one line: Invoice processing automation is a pipeline that captures a supplier invoice, reads its data, matches it against your records, routes exceptions for approval, and posts it for payment.
The stages run in a fixed order:
Receive is where the capture routes live: an email inbox with PDF attachments, supplier portals, and PEPPOL e-invoices. Email parsing and tools like Dext do their work at this step only. When every stage clears without a flag, the invoice reaches payment untouched by hand: that is straight-through processing. Outbound billing and the wider invoicing and cash-flow picture sit on our financial operations page, while this one owns the inbound accounts payable pipeline. Most of that pipeline is rules, one part is reading, and one part is human judgement.
Which steps are rules, and which need a person
The reason automated invoice processing earns trust is that most of it is not intelligent at all. Naming which step runs on a fixed rule and which one genuinely needs a person turns the system from something that feels like magic into something you can audit line by line. Here is the map.
| Step | Deterministic rule | Where judgement enters |
|---|---|---|
| Receive | Watch the inbox, file the PDF | None |
| Extract | AI reads the document | Low-confidence reads go to a person |
| Match | Compare against the purchase order within tolerance | Mismatches go to a person |
| Route for approval | Delegation-of-authority bands | The approver's decision itself |
| Post | Write the bill to the accounts package | None |
| Pay | Build the payment run | A person releases it |
Approval routeing sits entirely in the rules column. Invoices over a set amount go to a named approver by cost centre or supplier, following your delegation of authority bands. None of that needs AI, and those bands belong in one place, where those approval rules should live, rather than scattered through code that only a developer can read.
Four things stay human before money moves.
One rule underpins the rest: segregation of duties means the person who approves an invoice is never the person who releases the payment.
Reading the invoice, and designing the review queue
Two steps in that map need more than a rule: reading the invoice, and deciding what happens when the read is uncertain. This is where accounts payable automation either earns trust or loses it, and it is the part most tools gloss over.
Reading the invoice
Extraction is the one genuinely AI-shaped step in the pipeline. Invoice OCR handles tidy, consistent layouts well, because the same supplier's invoice tends to look the same every month. The messy remainder is where a large language model (LLM) and intelligent document processing (IDP) earn their place: scanned pages, odd layouts, photographed receipts, and the unfamiliar template of a supplier you have never billed before. Header fields such as supplier name, invoice number, total and VAT extract more reliably than line items, and line items are where reads tend to go wrong.
By design: extraction is never perfectly accurate, and the pipeline assumes it will sometimes be wrong. That assumption is the whole point of the review step. Every extracted field carries a confidence score, and anything below the threshold goes to a person instead of into the ledger.
The review queue
The pipeline earns its keep on the handful of invoices that arrive wrong, duplicated, or without a purchase order. That small fraction swallows most of the manual effort in accounts payable, so it is the part worth designing for. Everything lands in one review queue rather than scattered across inboxes. Each item shows the invoice image beside the extracted fields, with the doubtful field highlighted, so a person can confirm or correct it in seconds. Four things always land here:
The system keeps an audit trail of every item: what the model read, the confidence it carried, what a person changed, and who approved it. A corrected field also feeds back into the next extraction, so the queue grows quieter over time. This is the applied case of the human-in-the-loop pattern, and the matching and fraud checks in the next two sections feed this same queue.
Two-way and three-way matching, and when three-way is overkill
Two-way matching compares the invoice against the purchase order: right supplier, right items, right price. Three-way matching adds the goods received note, so you only pay for what actually arrived. This is why an invoice with no purchase order cannot be cleared by a rule: with nothing to match it against, the amount is unverified, so it waits for a person.
Which of the two you need depends on whether anything physical turns up at your door.
| Approach | What it checks | When it fits | When it is overkill |
|---|---|---|---|
| Two-way | Invoice against purchase order | Firms that raise POs for most spend | Rarely: it is the sensible default wherever POs exist |
| Three-way | Invoice against PO and goods received note | Firms taking physical deliveries of stock or materials, such as wholesale, construction, or manufacturing | Service businesses with nothing physically delivered and no goods received note |
Matching runs within an agreed tolerance: a small percentage or fixed amount of variance passes, and anything above it routes to the review queue rather than paying quietly. A partial delivery matches the received quantity, not the ordered quantity, so the system part-pays or holds the balance instead of flagging the whole invoice. A service business with no goods received note does not need three-way matching, and forcing it just creates exceptions for a document that will never exist.
Stopping duplicate payments and redirection fraud
These two failures cost real money because each individual invoice looks entirely legitimate. A duplicate quietly pays the same bill twice, usually when a supplier resends a PDF or a number gets re-keyed. Redirection fraud pays a genuine bill to the wrong account. Both slip through busy manual processes precisely because nothing on the face of the invoice looks wrong.
A short set of automated checks catches these before payment is released.
Invoice redirection works like this: a fraudster impersonates a supplier, often through a compromised or lookalike email account (the pattern known as business email compromise), and asks you to update the bank details on file. The invoice that follows is genuine in every respect except the account it pays into. Because those details live in your supplier records, a change there is treated as an event to verify, not a note to file. These flags feed the same review queue as everything else.
The one rule that matters most: verify any changed bank detail with a call-back. Phone the supplier on a number you already hold, never one printed on the invoice or given in the email that requested the change.
Pushing clean data into Xero, QuickBooks and Sage
Your accounts package stays the source of truth for the ledger. Xero, QuickBooks or Sage still owns the books; the pipeline's job is to hand each one clean, approved data. If a person is still retyping approved invoices into Xero, the automation has not finished its job.
The principle: Push clean, approved data into the accounts package through its API, and never rekey. Every field arrives already validated, matched and approved.
Handing over clean data means three things must be right before the invoice reaches the ledger. They run in parallel, each one keeping the books tidy in a different way.
Nominal coding
Each line lands on the right nominal code, learned from history and correctable in the review queue, so month-end reporting holds together.
VAT and Making Tax Digital
VAT is captured per line at the right rate, so the return draws on clean digital records, as Making Tax Digital expects.
Supplier master data
Supplier names, references and bank details stay synchronised between the pipeline and the package, so there is one record per supplier, not two competing ones.
Payment follows the same discipline: the approved payment run reaches the bank as a BACS file or through open banking, released by a person. As e-invoicing spreads, PEPPOL invoices arrive as structured data, skipping extraction entirely. How the accounting package integration is built and kept reliable sits on its own page.
What to measure, and whether to build or buy
A pipeline that feels quicker is not the same as one that works. Three or four numbers tell you whether it is actually moving invoices through, and where it still leaks time or money. Watch these, and the weak stages show up on their own.
- Touchless rateThe share of invoices that reach posted from arrival without a person touching them: straight-through processing, actually measured.
- Exception rateThe share landing in the review queue, and the reason each one lands there. This is where the remaining cost hides.
- Time to approveHow long an invoice waits for a person, from arrival to approval.
- Cost per invoiceWhat processing a single invoice costs once the retyping is gone.
Once those numbers are visible, the build-or-buy question tends to answer itself. A dedicated accounts payable tool fits standard flows: common document types, simple approval chains, one accounts package. A custom build fits the awkward cases: odd document types, unusual approval chains, or when accounts payable is one part of a wider operations system rather than a standalone problem.
The calm version is quiet. Invoices process themselves until judgement is genuinely needed, and month-end stops being a scramble to catch up.
See where automation fits your accounts payable
We will map your current invoice flow and show which steps are safe to automate and which stay with a person.
Map your invoice flow →