What Three-Way Matching Actually Is

Three-way matching is the practice of checking a vendor’s invoice against two things you already hold: the purchase order, and the goods receipt.

It sounds like paperwork. It is actually the only control in accounts payable that catches the errors that cost real money.

What each document proves

The purchase order proves what you agreed to buy, and at what price. It is a statement of intent, made before anything happened, by someone with authority to commit the money.

The goods receipt proves what actually arrived. It is a statement of fact, made by whoever stood at the loading dock and counted. Crucially, it is made by a different person from the one who raised the order, and made before the invoice arrived to influence it.

The invoice proves nothing at all. It is the vendor’s claim about what you owe them. It may be right. It is not evidence.

That asymmetry is the whole point. Two of the three documents are yours, produced independently, at different times, by different people. The third is the counterparty’s assertion.

What each pairing catches

Order against invoice — a “two-way match” — catches the vendor billing you a price you did not agree, or for something you did not order.

What it does not catch: being billed for goods that never arrived. If the order says 100 units at £5 and the vendor invoices 100 units at £5, the invoice matches the order perfectly. Whether 100 units ever appeared on your dock is a question the order cannot answer.

Receipt against invoice catches being billed for more than arrived.

What it does not catch: a price change. If 60 units arrived and the vendor bills 60 units, the quantity is fine — even if the unit price on the invoice is nothing like the one you negotiated.

All three catches both, and in doing so catches the two most common real problems: short delivery, full invoice and agreed price, invoiced price.

The failure that only three-way matching catches

The scenario worth internalising:

• Order: 100 units at £5.00 = £500.
• Received: 60 units. The rest are backordered.
• Invoice: 100 units at £5.00 = £500.

A two-way match against the order passes. Every number agrees. The price is right, the quantity is right, the total is right. Nothing about that invoice looks wrong.

You have just paid £200 for goods that are not in your building. Whether you ever get them depends on somebody remembering, and on the vendor’s records, and on nobody treating the account as settled.

The only thing that catches it is the receipt.

Why it is so often not done properly

Not because anyone doubts it works. Because doing it properly, by hand, is genuinely expensive.

For each invoice, somebody opens a PDF, finds the order, finds the receipt, and compares three sets of line items across two or three screens. On a twenty-line invoice that is real, sustained attention — the kind that degrades after the fourth invoice of the morning.

So what happens in practice is a partial version. Totals are checked and lines are not. Or the first few lines are checked carefully and the rest are skimmed. Or the check is done thoroughly for invoices over some threshold and waved through below it — which is exactly the behaviour a vendor with a systematic billing error benefits from most.

The control is not usually absent. It is usually degraded, in a way nobody can see from a report.

The two ways to make it cheap

Make it stop being manual. If software compares the three documents line by line and only involves a person where they actually disagree, the cost of the check stops scaling with invoice volume. That is the whole design case for automating accounts payable.

Build the invoice from the truth rather than checking it afterwards. This is the stronger version and it is available in Business Central natively: instead of transcribing the vendor’s invoice and then comparing, create the invoice from the posted receipt lines. Quantity comes from the receipt, price comes from the order.

Under that approach, a three-way match is not a check you perform. It is a property of how the document was constructed. There is no path by which a quantity the vendor invented reaches the ledger, because no quantity from the invoice is ever used.

You still want the comparison — you need to know the vendor claimed 100 when 60 arrived, so you can do something about it. But the comparison becomes an alert, not a gate. The gate is structural.

The line worth remembering

The vendor’s invoice is a claim. Your order and your receipt are the truth. The job of accounts payable is not to enter the claim; it is to check the claim against the truth and pay the truth.

Everything else in invoice automation is a detail of how cheaply you can do that.