Turning a stack of invoice PDFs into a three-way match a clerk still signs off on

The situation

Supplier invoices arrived as native PDFs, scanned images, and the occasional email body, in whatever layout that supplier's own system produced. The accounts payable team kept up by keying each one into the ERP by hand and matching it against the purchase order and goods-received note themselves. It worked, and it also meant payment cycles were paced by data entry rather than by terms, so early-payment discounts were routinely missed and month-end was always a scramble.

The constraint

This was never going to be a single-template extraction problem — forty-plus suppliers meant forty-plus layouts, and no two used the same field names or line-item structure. More importantly, a wrong extraction here has a direct financial consequence: an overpaid invoice, a duplicate payment, a misread tax figure. The team could not accept a system that produced a plausible-looking number with no way to tell how confident it was, and the ERP itself was not up for replacement — whatever we built had to sit in front of it, not instead of it.

What we built

Extraction with a confidence score attached to every field

Invoice number, date, line items, tax breakdown and totals are extracted against a fixed schema, and each field carries a confidence score and, where possible, a pointer back to where on the page it came from. Nothing posts to the ERP on a low-confidence field without a human looking at it first.

Matching that expects the master data to be messy

Fuzzy matching against purchase orders, goods-received notes and the vendor master, with a configurable tolerance band for price and quantity variance. A mismatch is reported as a specific discrepancy — this line is 4% over the PO price — rather than a generic match-failed flag an AP clerk has to re-investigate from scratch.

A review queue built for volume, not for edge cases only

Every invoice below the confidence threshold, and every match exception, lands in a queue an AP clerk works from, correcting fields inline. Corrections are logged and reviewed periodically to see which suppliers or fields are driving the most manual touches, which turned out to be a small, fixable list.

Posting as the last step, not the first

Only invoices that clear both extraction confidence and the match tolerance post to the ERP automatically. Everything else waits for a person, by design — the goal was fewer manual touches, not fewer human decisions on the ones that actually need one.

What changed

Processing time per invoice fell from days to hours, and a clear majority now move through untouched by a keyboard. The bigger shift was qualitative: the team could finally see, invoice by invoice, why something was flagged, instead of re-deriving it from scratch each time.

What we would do differently

We underestimated how much of the early match failures were not extraction errors at all — the same supplier was entered three different ways in the vendor master, so nothing matched cleanly no matter how accurate the extraction was. A vendor master-data cleanup should have run before the matching logic was tuned, not after the team started, reasonably, blaming the new system for old data problems.

Outcomes

Invoice processing time

days → hours

Touchless invoices, no manual keying

zero → a clear majority

Three-way match exceptions correctly flagged

a marked improvement

Client identity withheld under a mutual NDA. Figures are illustrative — rounded and directional, meant to show the shape of the change rather than an audited result. We will walk through the real numbers, and how they were measured, under NDA on a call.