Accounts payable teams in mid-sized companies still spend a large share of their week keying invoice data into an ERP. Supplier name, invoice number, dates, line items, tax, totals, PO reference. It's dull, it's error-prone, and it's one of the clearest cases for AI automation you'll find, because the inputs are bounded and the output has to land in a structured system anyway.
It's also where a lot of projects stall at around 70% automation and never get further. The extraction works on most invoices. What's missing is everything around it: knowing when the model is wrong, routing those cases to a person, posting cleanly into the ERP, and proving to the finance controller that it's safe to switch on. This guide covers that part.
OCR, vision LLMs, or both
The traditional stack is OCR to get text and coordinates, followed by templates or a trained extraction model per field. It's cheap per page, fast, and very predictable on suppliers you've seen before. It struggles with new layouts, which means someone maintains templates forever.
Vision-capable LLMs read the page image directly and can return structured JSON for a layout they have never seen. That is a real shift for long-tail suppliers who send one invoice a quarter. The trade-offs are higher cost per page, more latency, and a different failure style: instead of returning garbled text, a model may return a confident, plausible number that isn't on the page.
| OCR + templates/ML | Vision LLM | Hybrid | |
|---|---|---|---|
| New layouts | Weak without new template | Strong | Strong |
| Cost per page | Low | Higher | Medium |
| Failure style | Missing or garbled text | Plausible but wrong values | Cross-checked |
| Bounding boxes for review UI | Native | Limited or approximate | From OCR layer |
| Best fit | High-volume repeat suppliers | Long tail, messy scans | Most AP teams |
We usually end up with the hybrid. Run OCR to get text with positions, give both the image and the OCR text to the LLM, and ask it to return each field with the exact source text it used. You can then verify that the value actually appears on the page and highlight it in the review screen. Values the model produced that can't be found in the OCR text get flagged automatically.
Field extraction and validation
Define a strict schema and enforce it with structured output or JSON schema validation. Header fields are the easy part. Line items are where accuracy drops, because tables wrap across pages, merge cells and mix discounts into rows.
Then validate everything you can with plain code, because arithmetic and lookups catch more errors than any model confidence score:
- Line items sum to the subtotal, and subtotal plus tax equals the total, within a rounding tolerance.
- Tax rates match valid rates for the supplier's country (VAT in the UK and EU, GST in Australia, sales tax rules in the US).
- The supplier matches a vendor master record by tax ID or bank details, not just by name.
- The invoice number hasn't been posted before for this supplier, catching duplicates.
- Dates are plausible and the PO number exists and is open.
- Bank details match the vendor master. A change here should always go to a human, since it's a classic fraud signal.
For PO-backed invoices, add two-way or three-way matching against the purchase order and goods receipt. If quantities and prices match within tolerance, that's strong evidence the extraction is right.
Confidence thresholds and human review
Every invoice should end up in one of three lanes: post automatically, send to review with fields pre-filled, or reject as unreadable or not an invoice. The routing rule is what makes or breaks the project.
LLMs don't give calibrated confidence scores out of the box, so build a composite signal. Combine whether each value was found verbatim in the OCR text, whether the validation checks passed, whether two independent extraction passes agreed, and whether the supplier has a clean history. An invoice that passes every check auto-posts. A single failed check sends only that field to a reviewer.
Set thresholds per field, based on the cost of being wrong. A wrong delivery address on a PDF is an annoyance. A wrong bank account or total is a payment error. Start conservative, measure field-level accuracy on reviewed invoices, and loosen thresholds only where the data shows the model is right.
Design the review screen for speed: the page image on one side, extracted fields on the other, the problem field highlighted on the image, and keyboard shortcuts to confirm. Every correction a reviewer makes is labeled data. Store it, and use it to build your evaluation set and to spot suppliers that need special handling.
ERP integration
Extraction is half the job. The invoice still has to become a correct document in SAP, Oracle NetSuite, Microsoft Dynamics 365, Xero or whatever you run, with the right vendor, GL codes, cost centers and tax codes.
Use the ERP's official APIs rather than screen automation wherever they exist. Post invoices as drafts or parked documents at first, so finance keeps final approval while trust builds. GL coding is a good candidate for suggestion rather than automation: predict it from the supplier's posting history and let the reviewer accept or change it. Make posting idempotent with a unique key per invoice, because retries after a timeout will otherwise create duplicates. Keep a full audit trail of the original file, the extracted values, who changed what, and when it was posted. Your auditors will ask.
If you operate in markets moving to mandatory e-invoicing, such as Germany for B2B, a growing share of invoices will arrive as structured data rather than PDFs. Build the pipeline so structured invoices skip extraction and go straight to validation and matching.
Measuring straight-through rate
The headline metric is straight-through processing (STP) rate: the share of invoices posted with no human touch. Track it next to two others, or it will mislead you. First, accuracy of auto-posted invoices, measured by auditing a random sample each week. A high STP rate with errors in it is worse than a lower one without. Second, handling time for invoices that do go to review, since pre-filled fields should cut that sharply even when STP is modest.
Break all three down by supplier. In most AP ledgers a small number of suppliers account for a large share of volume, and getting those right moves the numbers more than any model change.
Roll out in shadow mode
Don't switch the pipeline on for real on day one. Run it in shadow mode for two to six weeks: every invoice is processed by the AI and by the existing team as usual, and the outputs are compared field by field. Nothing the system produces is posted.
Shadow mode gives you real accuracy numbers on your own invoices, shows exactly which fields and suppliers fail, and lets you set thresholds from evidence. It also gives the finance controller something concrete to sign off on. After that, enable auto-posting for the top suppliers with the best track record, keep everything else in review with pre-filled fields, and widen the lane month by month. It's slower than a big-bang launch. It's also how you avoid the meeting where someone explains why a supplier was paid twice.
Questions we get asked
- What straight-through rate is realistic for invoice automation?
- It depends heavily on your supplier mix, PO coverage and scan quality. Measure it on your own invoices during shadow mode rather than trusting a vendor's headline number.
- Are vision LLMs better than OCR for invoices?
- They handle new and messy layouts far better, but cost more per page and can produce plausible wrong values. A hybrid that cross-checks LLM output against OCR text is the safer default.
- Which ERPs can AI invoice processing integrate with?
- Any ERP with a usable API, including SAP, Oracle NetSuite, Dynamics 365 and Xero. Post as drafts first and make posting idempotent to avoid duplicates.
- How long should shadow mode run?
- Typically two to six weeks, or until you have enough invoices per major supplier to set field-level thresholds with confidence.