Most “AI invoice processing” pitches sell the easy case: a clean PDF, a consistent layout, a confident model. Nobody demos the scanned photo of a handwritten purchase order that’s been forwarded through three email chains — because that’s the case that breaks the demo. It’s also the case that actually shows up in the inbox every week. If the system’s answer to “what happens when it’s not sure” is make its best guess and file it away, you haven’t removed the data entry problem. You’ve just moved the error further downstream, past the point where anyone will catch it.
We built an ingestion layer that stops and asks instead of guessing and filing.
The point of improvement
Invoices, purchase orders, and supplier forms arrive in whatever format the sender feels like sending — a clean PDF, a scanned image, a photo of a paper form, a forwarded chain with the actual attachment three replies deep. Someone opens each one, finds the total, the PO number, the line items, and retypes them into the ERP or a spreadsheet. It’s slow, and it’s the kind of task where a transposed digit doesn’t announce itself — it just sits there until reconciliation catches it, if reconciliation catches it.
The cost that never gets measured isn’t the retyping time. It’s the corrections that happen a full accounting cycle later, once someone finally notices a total doesn’t match.
What we built instead
Three things had to hold at once for this to be safe to automate, not just fast:
- Structured extraction, not OCR-and-hope. The system doesn’t dump raw OCR text into a field for someone to re-parse by eye. Extraction is mapped directly against the record’s schema — the PO number goes in the PO number field, line items get parsed into line item rows.
- Confidence scoring on every field, not just the document. Each extracted value carries its own score. A supplier name read at 98% confidence and a smudged handwritten total read at 61% confidence get treated differently — the low-confidence field routes to a human reviewer, the high-confidence ones don’t wait on anyone.
- Human review as a queue, not a rubber stamp. Anything under the confidence threshold lands in a review queue with the source document and the extracted value shown side by side, so the reviewer is correcting one specific field, not re-keying the whole document. This is what “human-reviewable” means in practice: the human’s role shrinks from primary data entry to exception handling.
Where the risk actually lives
OCR accuracy has been a solved problem for years — that was never the hard part. The hard part is the edge of confidence: the field the model is almost sure about. A system that silently accepts everything above some threshold, with no visible trail, is the one that quietly corrupts records for months before an audit finds it. The confidence scoring and review queue exist specifically so that edge case has a defensible, visible path — not a single accuracy percentage on a sales deck that nobody can interrogate.
Most businesses haven’t automated invoice processing because the exceptions felt too messy to trust to a model. That’s a reasonable read of the tools they evaluated — most of them really do just guess past the messy cases. Build the review queue as a first-class part of the system instead of an afterthought, and the messy cases stop being the reason to avoid automating in the first place.