AI invoice processing: extraction, coding, and three-way match

Why template OCR failed and what replaced it

Traditional invoice OCR worked by template: for each vendor, someone defined where the invoice number sat, where the total appeared, and how to find the line-item table. It worked accurately for configured vendors and not at all for anyone else. With a vendor base of any size, the configuration backlog became the bottleneck — and every vendor redesign silently broke its template.

Vision-language models removed the templates. A modern extraction model reads an invoice the way a person does, locating fields by their semantic role and visual context rather than coordinates. A vendor you have never billed with works on the first invoice, and a layout change does not break anything. That is the real shift, and it is why the long tail of low-volume vendors — historically the most expensive invoices to process — is now automatable.

The four-stage pipeline

• 1. Classification — Is this an invoice, a credit memo, a statement, a receipt, or a remittance advice? Misrouting at this stage produces confusing downstream failures that get misdiagnosed as extraction errors.
• 2. Extraction — Header fields — vendor, invoice number, dates, currency, tax, totals — plus the line-item table. Every field carries a confidence score, and the score is what drives routing, so a pipeline that returns values without confidence is not production-ready.
• 3. GL coding prediction — Predicting cost center, GL account, and department from vendor, line-item text, and your historical postings. Accuracy is bounded by the consistency of that history rather than by the model.
• 4. Matching — Two-way against the PO, three-way including goods receipt. The straightforward cases are trivial; the value is entirely in the exceptions — partial deliveries, unit-of-measure mismatches, price tolerances, and consolidated invoices spanning several POs.

Where accuracy actually goes wrong

Aggregate accuracy figures hide the failure modes that matter operationally. In production, errors concentrate in a small number of predictable places, and knowing them lets you route defensively rather than chase a percentage point.

GL coding: the part bounded by your own data

GL coding prediction is the capability clients most often expect to be a model problem and which is almost always a data problem. The model learns from your posting history, so it inherits whatever that history contains. If three clerks coded the same vendor to three different accounts over four years, the model reproduces the ambiguity faithfully and confidently.

Before training, audit coding consistency per vendor. Where a vendor maps to one account 95% of the time, expect strong prediction. Where a vendor splits across five accounts by criteria that live in someone's head, the model cannot recover the rule — that vendor either needs the criterion made explicit as a feature, or it belongs permanently in the review queue. Being honest about that split up front is the difference between a system your controller trusts and one they override.

Designing the review queue first

The review interface, not the model, determines whether an AP team adopts the system. It should open on the flagged field with the document rendered alongside and the uncertain value highlighted in place — not present a form beside a PDF viewer and leave the reviewer hunting. Keyboard-first correction, single-keystroke accept, and immediate advance to the next item are what make review fast enough to be sustainable.

Every correction is also a training label. A pipeline that does not feed reviewer corrections back into evaluation and retraining plateaus at its launch accuracy and stays there, which is the most common reason a system that looked good in month one looks mediocre in month twelve.

How NextGen builds invoice pipelines

We measure before we build. Send a representative sample of your invoice volume and we produce a field-level accuracy baseline on your actual documents, broken out by input type and by field, along with a projected straight-through processing rate at several confidence thresholds. That baseline tells you what the system will really do — and sometimes tells you an off-the-shelf platform already clears your bar, which we will say plainly.

Builds ship with the evaluation harness, calibrated per-field thresholds, the keyboard-first review interface, drift monitoring on extraction accuracy and coding distribution, and full audit logging. A first production pipeline against one ERP typically runs 10–16 weeks and $150K–$300K, delivered by senior US-based engineers.