Three-way matching is a data problem before it is a finance problem

Every accounts payable automation pitch shows the same diagram: purchase order, goods receipt, invoice, three arrows meeting at a tick. The logic is a handful of comparisons — quantity, price, line total — and it is genuinely that simple.

So why does the straight-through rate stall in the sixties?

Because the comparison assumes three documents that describe the same thing in the same way, and in a real estate they almost never do.

The four disagreements

Line granularity. The PO has one line for "office chairs, qty 40". The invoice has four lines, because the vendor shipped in four batches across two weeks. Nothing is wrong. Nothing matches.

Unit of measure. Ordered in cartons, received in cartons, invoiced in units. A matcher comparing quantities finds 12 against 144 and escalates a perfectly correct invoice.

Identity. The vendor on the PO is a legal entity; the vendor on the invoice is a trading name belonging to a subsidiary that was acquired last year. A human recognises them instantly. A string comparison does not.

Tax treatment. The PO is net of tax, the invoice is gross, the receipt has no tax concept at all. The line totals will never agree, and the tolerance band that makes them agree is wide enough to swallow real errors.

Tolerance bands are not the fix

The reflex is to widen the tolerance until the exception queue is manageable. This works, in the sense that the queue gets shorter, and it is exactly the wrong move: a two percent tolerance on a large invoice is a large number, and duplicate-invoice fraud lives comfortably inside it.

You have not automated matching. You have automated approval.

Normalise, then match

The order of operations matters more than the matching engine:

extract   →  every document to a common line-item shape
resolve   →  vendor identity, UOM, tax basis, currency
reconcile →  match on the normalised shape
escalate  →  only genuine disagreements reach a person

The third step is the one everybody builds first, and it is the least interesting of the four. Steps one and two are where the straight-through rate actually comes from, and they are data engineering problems: entity resolution, unit conversion, schema normalisation, document extraction that survives a scanned fax.

What this means for the exception queue

Once normalisation is real, the exceptions that survive are worth a human's attention. A queue full of unit-of-measure noise trains reviewers to click approve; a queue of genuine price variances and unrecognised vendors trains them to look. The queue's composition is the metric that matters, not its length.

That is also the honest answer to "what is your straight-through rate". It depends entirely on how much of the mess above was cleaned up first, which is why a number quoted without that context tells you nothing about your own estate.

See how the reconciliation and document intelligence models handle the first two steps, or read the AP automation solution end to end.