Reading invoices is one of the most obvious jobs to hand to AI. It's repetitive, high volume and the information is right there on the page. It's also a job where a single wrong digit costs real money, and AI models make mistakes with total confidence.
When I built an accounts payable portal for a property group's payables team, the design question wasn't "can AI read an invoice?" It clearly can, most of the time. The question was: how do you know which times it got it wrong?
The answer we landed on is simple. Read every invoice three times, and only trust it when all three agree.
How the consensus read works
When a vendor uploads a PDF invoice, it's scanned and then read by three AI readers in parallel. Each one works independently and extracts the same fields: invoice number, date, vendor, subtotal, GST, total and line items.
Then a consensus step compares the three results field by field.
- Every money field must match to the cent. Subtotal, tax and total all have to be identical across all three reads.
- A majority isn't enough. Two out of three agreeing doesn't pass. If one reader disagrees, the invoice is flagged.
- Formatting differences don't count. "INV-20418" and "INV 20418" are the same invoice number. Punctuation is ignored where it carries no meaning; money is never treated that loosely.
If everything agrees, the extracted data is trusted and moves on to approval. If anything disagrees, the invoice goes to a person.
Why unanimous, not majority
It's tempting to take the majority answer. If two readers say the GST is $209.00 and one says $290.00, surely it's $209.00?
Usually, yes. But "usually" isn't the standard for paying vendors. A disagreement means something about that document is ambiguous: a smudged scan, an unusual layout, a handwritten correction, two tax lines. Those are exactly the invoices a person should look at. Requiring unanimous agreement turns the AI's uncertainty into a clear signal instead of hiding it.
What the person sees
When an invoice is flagged, the approver doesn't start from scratch. They see the three reads side by side, with the fields that disagree highlighted. In the GST example, they'd see three matching subtotals, three matching totals and one GST line that doesn't match. A glance at the original document settles it.
That's the real time saving. People stop reading every invoice in full and start resolving specific, highlighted questions.
Built to fail loudly
A few other design choices matter as much as the triple read.
Different readers behind one adapter. The system can use OpenAI models, Claude and Azure Document Intelligence, swapped through a single adapter. Using different engines makes it less likely that all three make the same mistake on the same document.
No silent fallbacks. If a reader is misconfigured or unavailable, the system stops and says so. It never fills in made-up data to keep things moving. A stalled invoice is a nuisance; an invented one is a serious problem.
Approvals and audit. Once the data is trusted, invoices go through sequential approvals, with thresholds that send larger amounts to more senior approvers and escalation when something sits too long. Every status change writes a permanent audit record that can't be edited afterward.
Does it cost three times as much?
In AI usage, roughly, yes. But the AI cost of reading an invoice is small compared to the cost of a person keying it in, and tiny compared to the cost of paying a wrong amount and chasing it back. Three reads is cheap insurance.
The idea travels well
The same pattern works anywhere a document has fields with right answers: purchase orders, delivery slips, timesheets, lease terms, insurance certificates, expense receipts.
- Define the fields that matter and what "matching" means for each.
- Read each document more than once, independently.
- Trust only what agrees; route everything else to a person with the differences shown.
- Never let the system invent data to fill a gap.
- Keep a record of who approved what.
AI doesn't have to be right every time to be useful. It has to tell you when it might be wrong. Building that in is most of the work, and it's what makes the rest trustworthy.