Three-way matching: the documents, and the fields the join runs on

Three-way matching compares three documents that each assert something different: the purchase order says you committed to a quantity at a price, the goods receipt says a quantity arrived, and the invoice says money is owed. A match means all three agree, line by line, on the same key.

Calling it a comparison undersells it. This is a join, and a join needs a key all three carry, spelled the same way, at the same granularity. Most of what an AP team experiences as a matching problem is that key missing on one side, ambiguous on another, or held at a different level on the third.

Only one of the three is written outside your control, and it is the one carrying the money.

The 8 fields the key is built from

• PO number. The only field linking an invoice to a commitment, and one the supplier copies by hand. Without it the join has no left-hand side, which is where a non-PO invoice leaves you.
• PO line. Decides whether the match is line-level or header-level. Suppliers quote the number far more often than the line, so engines fall back to comparing totals.
• Item code. Yours, theirs, or free text. Resolving a supplier part number is an alias lookup living in the vendor master record.
• Unit of measure. Ordered in cases, billed in each: both quantities correct, neither comparable. That is unit-of-measure drift.
• Quantity. Compared cumulatively against prior receipts and prior billings, so 3 deliveries and 2 invoices need running totals on both sides.
• Unit price. Compared within an allowed variance, itself a rule object — see what an engine may wave through.
• Currency. A number without a currency is not a price. EUR on the invoice against GBP on the PO is a different quantity, not a variance.
• Tax treatment. Tax is calculated, not matched. Compare net and evaluate tax separately, or a reverse-charge line fails against a gross-billed one.

One line, joined: where the tuples stop lining up

PO 4501182, line 20: 40 cases of item ITM-4471, 12 units to a case, at 18.40 the case. The warehouse receives 40 cases. The supplier bills 480 units at 1.55. Every number is right; the join fails anyway.

Four failures, none of them anybody's mistake. The supplier billed in the unit it ships in, rounded to the precision its system holds, and quoted the reference a human typed. Each needs a rule.

A matching engine does not fail because someone was careless. It fails because two companies described the same delivery in their own vocabularies, and nothing in between translated.

Dropping the receipt, or adding an inspection

• Two-way match. PO against invoice, no receipt in the join. Right where nothing physical arrives — a consultancy day, a licence renewal — so the only assertions are the commitment and the claim.
• Four-way match. Adds an inspection or acceptance record, so the join proves goods arrived and were accepted. Right where those are separate events: a certificate of analysis, an engineer's sign-off.

These are not tiers of rigour. Each drops or adds an assertion, and the right one depends on which assertions exist in your process. A three-way match where nobody posts receipts produces a permanent exception queue, not a stronger control.

The supplier never agreed to your key

A matched invoice is not a paid one either. Matching establishes the obligation; the payment clock runs from a date chosen separately, as invoice date, received date or approval date argues. That gap between a recognised obligation and money that has moved reappears as ledger balance against available balance.

Matching is therefore a data-modelling problem before a model problem, which is how we scope AI agents and automation in finance: an agent acting on a key nobody validated is the failure in putting AI agents into production. The rest of invoice to pay: capture, matching and approvals covers either side of the join, and our finance operations work is mostly making the join possible before making it automatic.

• accounts payable
• invoice matching
• purchase orders
• AP automation