Three-way matching AI: PO, receipt and invoice without the manual chase

Three-way matching confirms that a supplier invoice agrees with the purchase order that authorised the spend and the goods receipt that proves delivery, before anyone pays it. The clean case is easy. The work sits in the tail: partial shipments, one PO billed across three invoices, mismatched units, free-text lines with no key. AI belongs there, matching lines and routing exceptions, while tolerance policy stays with the controller.

Where the strict match breaks

An ERP three-way match runs on an exact join: PO number, line, part number, quantity, price. When all three documents carry the same keys and the numbers fall inside tolerance, straight-through processing works and nobody thinks about it. AP still runs a chase queue because a large share of real invoices never present that clean join.

The recurring breakers we see:

• Partial and over-deliveries. A PO line for 1,000 units ships as 600 then 400, generating two goods receipts and often two invoices against one PO line. The naive per-line quantity check fails on both.
• Split and consolidated invoices. One supplier bills a single PO across several invoices; another consolidates ten POs into one document. Matching now spans a many-to-many relationship, not a row.
• Unit-of-measure mismatches. The PO is in cases, the receipt in eaches, the invoice in kilograms. Without a conversion table the quantities look wrong even when the delivery was correct.
• Free-text and service lines. Services, freight and one-off lines carry descriptions rather than catalogue part numbers, so there is nothing to join on.
• Price and tax drift. Contracted price versus invoiced price, rebates applied at the wrong level, tax computed on a different base.

None of these are extraction problems. The document was read correctly and the match still fails, because the relationship between the three documents is not one row to one row.

The matching logic we build

We treat this as line-item entity resolution over three sources rather than a single ERP flag. The pipeline normalises first, then scores, then decides.

Normalisation is the unglamorous part that does most of the work. Units are converted to a common base using a supplier-and-item conversion table. Descriptions are cleaned and, where a catalogue exists, resolved to internal item IDs. Prices are put on a comparable footing, net of tax and known rebates, with currency and date handled explicitly so a two-week-old FX rate does not manufacture a variance.

Then we score candidate links. For each invoice line we retrieve plausible PO lines and receipt lines and rank them on supplier part number, quantity remaining against the PO, unit price after normalisation, and text similarity for the free-text cases. Quantity matching runs against the open balance on the PO line, not its original amount, so partial deliveries accumulate correctly across multiple receipts. This is where split and consolidated invoices get resolved into a defensible many-to-many allocation instead of a forced one-to-one guess.

The decision layer stays deliberately separate from the scoring. Auto-match happens only above a confidence threshold calibrated on a labelled eval set of historical matches, and only when the resulting variance sits inside the tolerance band the controller has set. Tolerance is policy. The model proposes a match; the policy decides whether that match may pay without a human. Keeping those two things apart is what lets you tighten the false-positive budget without retraining anything.

Two constraints we hold to:

• Point-in-time correctness. The match uses the PO revision, price and open balance as they stood when the invoice arrived, not today’s state. Retro price changes and later receipts must not rewrite a decision that was already made, or the audit trail stops meaning anything.
• Full lineage. Every auto-matched line records which PO line, which receipt, which conversion factor and which threshold produced the decision, so a matched invoice can be reconstructed months later at quarter-end without re-deriving it by hand.

Exception routing that actually clears

Matching is half the system. The other half is what happens to everything the model would not auto-clear, because that queue is where AP time actually goes.

We route by exception type rather than dropping everything into one generic hold, because the person and the fix differ. A quantity shortfall goes to the receiving location that logged the goods receipt. A price variance beyond tolerance goes to the buyer who owns the contract. A tax or coding error goes to AP. A no-PO invoice goes to whoever can raise or confirm the authorising document. Each route carries the model’s top candidate matches and the specific reason the line held, so the reviewer starts from a ranked shortlist rather than a blank search.

Raw match rate is the wrong headline. The number worth watching is the exception rate weighted by how long each type takes to clear, tracked over time so drift shows up. When a supplier changes its invoice layout or starts consolidating POs, the exception mix shifts before the totals do, and that shift is the early signal that a conversion table or a threshold needs attention.

Aim for this: the clean tail clears untouched, ambiguous cases arrive pre-sorted with candidates attached, and the only invoices a human opens cold are the ones where the documents genuinely disagree. That last set never reaches zero, nor should it. Those are the cases where a control is doing its job.