AI invoice processing: the pipeline that survives real invoices, from PDF to posted entry

Every vendor demo of AI invoice processing looks the same. A clean PDF goes in, a neat table of supplier, date, line items and total comes out, and everyone in the room nods. The demo is honest as far as it goes. It is also the least important part of the system.

An accounts payable team's month is spent on what happens after extraction: does this invoice match a purchase order, was the goods receipt booked, is the price inside tolerance, has this invoice been submitted before under a different number, is this a credit note or a debit note, who approves it and when. A pipeline that automates extraction and leaves the rest to people saves roughly the ten minutes a month the team spent typing. A pipeline that automates the matching and the routing, and gives people only the genuine exceptions, is the one that reaches the 70 to 90 per cent straight-through rate we quote on the use-case page.

Here is what that pipeline looks like, stage by stage, with the failure at each stage that you should plan for.

Stage one: intake, and the supplier who faxes

Invoices arrive by email, supplier portal, EDI, scanner, and in one client's case a fax machine that a long-standing supplier refused to give up. The intake stage has one job, which is to get every document into one queue with a source, a timestamp and a unique ID, regardless of how it arrived.

The failure here is silent loss. An email with three attachments where one is the invoice, one is a delivery note and one is a supplier's marketing PDF. A portal that batches invoices into one file. A scan that came through upside down. Classification at intake, separating invoices from everything else and splitting multi-invoice files, is dull work for a model and it removes the most embarrassing category of error, which is the invoice nobody ever saw.

Stage two: extraction, where the demo lives

A current vision-language model reads a scanned invoice about as well as a person does, including handwritten annotations, stamps and the second page where the totals are. Line items, tax breakdown, supplier identifiers, PO references, bank details, payment terms. In India the same document carries a GST identification number, an invoice reference number from the e-invoicing system, and up to three tax components that must reconcile to the total.

The failure at this stage is confidence without correctness. A model will read a total wrongly and report it with the same fluency as a right answer. The fix is arithmetic, which is stage three, and it is the reason extraction should never post anything on its own.

Stage three: validation, or the maths the model cannot be trusted to do

Every extracted invoice goes through deterministic checks before a model is asked anything else. Do the line items sum to the subtotal. Does the tax compute at the stated rate. Does the total equal subtotal plus tax less any discount. Is the supplier's identifier one you have on file, and do the bank details match the ones on file for that supplier. Has an invoice with this number, or this amount and date, from this supplier been seen in the last twelve months.

The duplicate check is the one finance directors care about most, because a duplicate payment is real money out of the door. The bank-detail check is the one the security team cares about, because a changed bank account on an otherwise valid invoice is the most common form of invoice fraud, and a model that "reads" the new details and passes them through is worse than a clerk who would have phoned the supplier.

Anything that fails validation goes to a person with the specific failure highlighted. Nothing that fails validation goes any further.

Stage four: matching, which is where the rules turn out not to exist

Two-way matching compares the invoice to the purchase order. Three-way matching adds the goods receipt. The logic is simple to describe and painful to implement, because the tolerance rules that decide whether a mismatch matters were never written down.

Is a price 2 per cent over the PO acceptable, or 5 per cent, or does it depend on the supplier. Is a partial delivery matched against the partial receipt or held until the order completes. What happens when the invoice quantity is in boxes and the PO is in units. Every AP team has answers to these questions, held in the heads of two people who have been there for years. The first fortnight of any invoice project is spent writing those answers down as rules, and it is common to find that the two people disagree.

This is the stage that decides your straight-through rate. With tolerance bands agreed and encoded, most invoices from established suppliers match cleanly. Without them, the system will either hold everything, which the team hates, or wave everything through, which the auditors hate.

Stage five: routing and approval

Matched invoices inside tolerance post directly. Everything else is routed, and the routing rules are usually already documented in the delegation-of-authority policy: by amount, cost centre, supplier category and sometimes by project. The agent's job is to apply the policy, assemble the context the approver needs (the invoice, the PO, the receipt, the specific mismatch, the supplier's recent history), and chase.

Chasing is underrated. A large share of AP delay is an approver who did not open the email. A system that sends a reminder on day three, escalates on day seven and reports the ageing to the finance lead weekly removes more days from the cycle than any amount of extraction accuracy.

Stage six: posting, and the audit log

The final step writes to the ERP through its API, with the extracted fields, the matching result, the approval chain and a link back to the source document. Every decision, every override and every approver is recorded. When an auditor asks why an invoice was paid, the answer is a single page.

The failure here is integration, and it is the reason the time to value on this use case is six to ten weeks rather than two. ERPs have opinions about how a supplier is identified, how a cost centre is coded and what a partial match looks like, and those opinions have to be respected field by field.

What it costs and what it returns

The model cost is small. An invoice averaging 40,000 input tokens and 3,000 output tokens on a mid-tier model works out at roughly 16 to 20 cents once retries are included, which at 5,000 invoices a month is under a thousand dollars. The build cost is the integration and the rules, and it is why the estimator puts the annual saving for a mid-size team at $100,000 to $300,000 rather than something larger: the saving is the exception handling and the cycle time, and that is worth having, but it is not magic.

The number to watch is the straight-through rate by supplier. It starts around 50 per cent in the first two weeks, while the rules are being argued over, and climbs as tolerance bands are agreed. Suppliers who never match need a procurement conversation rather than a better model.

Frequently asked

What does an AI invoice processing pipeline do? It takes invoices from every intake channel into one queue, classifies and splits them, extracts line items, tax and supplier details, validates the arithmetic, bank details and duplicates deterministically, matches each invoice against the purchase order and goods receipt inside agreed tolerance bands, routes exceptions by your delegation-of-authority policy, posts matched invoices to the ERP, and keeps an audit log of every decision.

What straight-through rate can AI invoice processing reach? Seventy to ninety per cent for established suppliers once tolerance rules are agreed and encoded. The first two weeks typically run nearer 50 per cent, because the matching rules were never written down and have to be. The remaining exceptions are usually supplier data quality problems rather than model errors.

How long does it take to implement AI invoice processing? Six to ten weeks for a mid-size accounts payable team, most of it spent on ERP integration and on agreeing tolerance and approval rules. Prerequisites are a digital intake channel, API access to the finance system, three to six months of historical invoices, and a finance lead willing to sign off the rules.

Related reading

• What production AI actually costs
• What you can hand to an AI agent in 2026
• Invoice processing use case

If a vendor shows you extraction and calls it invoice automation, ask to see the tolerance rules and the duplicate check. The team that built those has done this before. This is the workflow automation work we do most often, and the fax machine is still plugged in.