Feed an invoice to a modern multimodal model and ask for structured JSON. It works. Usually on the first attempt, with no configuration, on a document type that used to require a template.
That result is genuinely new, and it explains why so many teams now believe invoice extraction is finished. It is also the reason a lot of them are about to rediscover the parts of the job that were never about reading.
The distinction worth holding onto is this: a model that reads an invoice correctly 95% of the time has not automated accounts payable, it has automated the first of five steps. The other four are where the operational cost lives, and none of them is a reading task.
What the model actually solved
Give the model its due first, because the change is real and worth being precise about.
Template-free extraction is the thing that broke. Rule-based and template-based systems required per-vendor configuration, which meant that a stream of two hundred senders needed two hundred configurations, and every layout change required a person. A capable multimodal model reads a layout it has never seen and returns something sensible, which removes an entire category of work.
It also handles a lot of the messiness that used to defeat OCR pipelines: rotated pages, moderate scan quality, mixed fonts, tables with irregular borders. Reading characters was solved a while ago. Reading a document that was never designed for machines is what changed recently, and it changed substantially.
So the reading step is largely handled. What follows is not.
Step two is validation. Do the line items sum to the subtotal, does the subtotal plus tax equal the total, is the currency consistent, does the date fall within a plausible window? An LLM will happily return a document where the arithmetic does not hold, because it is reporting what it saw rather than checking it.
Step three is matching. The vendor on the invoice has to resolve to a vendor in your system, and the purchase order reference has to resolve to a real purchase order. This is entity resolution, and it fails on abbreviations, legal entity variants, acquired subsidiaries and the fact that your own vendor master was entered by hand over ten years.
Step four is policy. Approval thresholds, tax treatment, cost centre allocation, duplicate detection across the whole history rather than within one document.
Step five is the exception path. What happens to the 5%, who touches it, and whether their correction improves anything.
Expert Insight: The most reliable way to see this distinction in practice is to score a model on documents rather than on fields. A model at 97% field accuracy across roughly thirty fields per invoice will produce a fully clean document a minority of the time, and every document with one bad field still requires a human. Straight-through processing rate is the number that determines staffing, and it is consistently far below the accuracy figure that gets quoted.
Three failure modes that are structural
Beyond the missing steps, three properties of current models make unassisted extraction difficult in a way that is not obviously improving with scale.
Silent confidence. When a rule-based extractor cannot find a field, it returns nothing, which is a signal. When a model cannot find a field, it frequently returns a plausible value, which is not a signal. Self-reported confidence scores correlate weakly with correctness in our experience, and a wrong total delivered with the same fluency as a right one is the specific failure that makes finance teams distrust automation. The same dynamic applies across document types, and it is the property worth testing first when you are comparing invoice extraction tools, because none of them advertises it.
Table and line-item drift. Single-value fields are the easy case. Line items are where invoices actually get complicated: rows that wrap, quantities in one unit and prices in another, discounts applied per line or per invoice, continuation across a page break where the header does not repeat. Models lose rows, merge them, and occasionally invent a plausible one. The failure is quiet, it is per-row rather than per-document, and aggregate accuracy metrics hide it entirely.
Non-determinism. The same invoice submitted twice can produce two different outputs. For a system with a financial audit obligation this is a governance question, not a quality one, and it is answered with a deterministic post-processing and validation layer rather than with a better prompt.
Expert Insight: Before adopting any of this, run a stability test. Submit the same fifty invoices three times each and count how many produce identical output across all three runs. It costs an hour, and the result changes the design conversation, because whatever that number is, it sets an upper bound on how much of the process can run without review.
The shape that does work
None of this argues for going back to templates. The architecture that holds up uses the model for what it is good at and puts deterministic machinery around it.
Model for reading, code for checking. Extraction from the model, then arithmetic validation, format normalisation, currency and date parsing, and duplicate detection in ordinary code. Deterministic checks are cheap, auditable, and they catch the confident-wrong case that the model cannot catch about itself.
Resolution against your own masters, not against the document. Vendor and purchase order matching runs against your systems with explicit fuzzy-match thresholds and a review queue for anything below them. Never let the model assert an identity it cannot verify.
Confidence at the field level, thresholds per field. A misread invoice number and a misread line-item description have different costs. Route on field-specific thresholds rather than on a document-level score.
A review path that produces training data. Every correction a reviewer makes is a labelled example. Treating human review as part of the architecture rather than as a fallback is what separates a system that improves from one that plateaus at whatever the model gave you on day one.
This is roughly the architecture we run at Forage AI across a large document volume, with a 3x QA team sitting on the exception path, because the last few points of document-level accuracy have never been a model property. They are an operating property, and that has not changed with any model release so far.
The next generation will read better. It will still not know whether the vendor on this invoice is the same legal entity as the one in your master file, and that has always been the harder half of invoice automation.
About the author: This piece was written by the data team at Forage AI, which runs intelligent document processing across 10M+ documents with a 3x QA team on every delivery. Learn more about Forage AI's work in intelligent document processing at forage.ai.
