Invoices arrive by email. AI reads them, code checks them against the purchase order, the goods receipt and the vendor master, and each one is either booked in QuickBooks or sent to a person with the reason attached.
| Industrial solvent, 20L drum | 436.44 |
| Epoxy resin kit, 5 gal | 281.96 |
| Corrosion inhibitor concentrate, 55 gal | 101.24 |
| Protective coating, 1 gal | 128.82 |
| + 4 more lines | |
| Total USD | $1,832.86 |
OCR has been around for decades, yet most AP teams still touch two out of three invoices by hand. The work sits in the exceptions: a price that drifted, a short shipment, a vendor name that doesn't match, a bill that arrives twice.
Source: Ardent Partners, State of ePayables 2025. Average AP team vs best-in-class.
The opportunity: automate the clean majority safely, and give the AP team every exception with the reason already written.
Before building anything I wrote the AP policy as six testable rules. Every decision the agent makes, and every test score, traces back to this page.
The name must match the vendor master or a registered alias, ignoring case and punctuation.
No PO, or a PO that doesn't exist, goes to a person.
Pay only if the difference is at most 1% and at most a dollar limit that scales with the PO.
Billed quantity must match what the warehouse received. Partial shipments are billed pro rata.
Same vendor, amount and PO as an earlier invoice is a duplicate. Only the first one is paid.
If the amount or date can't be read with confidence, a person reads it.
The model reads documents. It never does arithmetic and never decides whether money moves. Click a step to see what it does and why it is built that way.
Polls the AP mailbox every 5 minutes. Every attachment is logged, including zips, empty emails and non-PDFs, so nothing is lost.
Logging every email before processing is what turned 69 silent drops into 0.
Seven real invoices from the blind tests, run through the same checks the agent uses, step by step, ending with the decision and the reason a reviewer would see.
PDF attached, logged
15 units, $1,832.86
Exact vendor match, QuickBooks ID 92
PO-71463 on file, 15 received
$0.00 difference
15 billed, 15 received
No earlier twin
Real invoice from the blind tests (synthetic company data). The steps show what the system computed and decided.
Every change had to pass a regression gate before it went live. Nothing was tuned on the blind tests.
197 labelled invoices. A change ships only if:
Intake, extraction, three-way match, vendor master with 265 aliases, QuickBooks bills, Slack escalations, resolution form.
Up from 95.4% on the first clean run, with zero false payments throughout.
No payment the policy said to review, but 69 invoices silently ignored and one double bill. Scored once, then frozen.
Never drop silently, code sums line items, longer outputs, check QuickBooks before billing, ignore logo text.
No payment the policy said to review, zero ignored. Answer key hashed before the run and scored once.
Both tests used invoices the system had never seen, built by a separate process from a written scenario list, with the answer key locked before any invoice was sent.
Industry figures: Ardent Partners 2025, real AP teams. Agent figures: synthetic blind test sets. Directional, not like for like.
| Measure | Blind test 1 v1.0.1 | Blind test 2 v1.1 |
|---|---|---|
| Invoices scored | 300 | 92 |
| Paid when policy said review | 0 | 0 |
| Silently ignored | 69 | 0 |
| Paid with no human | 33.7% | 65.2% |
| Matches written policy | 51.0% | 80.4% |
| Unnecessary escalations | 81 | 18 |
| Cost per invoice | $0.010 | $0.010 |
The first blind test found real failures. None of them paid an invoice the written policy said to review, and each one changed the design.
One more finding, and it is a gap in the policy rather than a failure of it: in blind test 1, 3 invoices with changed bank details were paid, because the written policy has no bank-detail check. The fix is on the v2 list below (remittance change hold).