Three-way matching is the check performed before a supplier invoice is paid. It compares three documents that should all describe the same transaction:
- The purchase order, which says what you agreed to buy
- The delivery record, which says what actually arrived
- The supplier invoice, which says what you are being asked to pay
If all three agree, the invoice is approved. If any one disagrees with the others, it stops until somebody explains why.
Everything above is standard, and every guide on the subject says roughly that. What they skip is that this is a control designed for organisations with a procurement department, and you probably do not have one. So the question is which parts of it earn their cost at your size.
What it actually catches
Three specific failures. Being precise about them matters, because the value of the control is exactly the value of these.
Paying for what never arrived. The invoice says ten licences, the delivery record says eight. Without the second document, you pay for ten.
Paying more than you agreed. The PO says 4,000, the invoice says 4,600. Somebody changed the price after the order, or made an error, or is testing whether you check.
Paying the same invoice twice. The most common and least dramatic. A supplier resends an invoice, somebody pays it again, and it surfaces months later if at all.
The third one is the reason the control survives in organisations that find it tedious. Duplicate payments are quiet, and they are almost never returned unprompted.
Two-way, three-way, four-way
The naming is just a count of documents compared.
Two-way matching compares the purchase order and the invoice. No delivery record. Normal for services, where there is nothing to physically receive, and where the agreement itself is usually a statement of work rather than an order for goods.
Three-way matching adds the delivery record, and is the standard for goods.
Four-way matching adds an inspection or quality record. Manufacturing and construction, mostly.
For a service business, two-way is usually the honest answer. You have an agreement and an invoice. What replaces the delivery note is your own knowledge of whether the work happened, which is a judgement, not a document.
Where the tolerance goes
Real matching is not exact. Systems allow a tolerance, because small variances are normal and stopping everything for a two-pound difference costs more than the difference.
Typical tolerances sit at a small percentage or a fixed low amount, whichever is lower. Inside the tolerance, the invoice passes automatically. Outside it, a human looks.
Setting that number is the whole art. Too tight and everything queues; too loose and the control does nothing. The pattern is the same one that governs aged receivables buckets on the other side of the ledger: the threshold is a policy decision, not a technical one.
Where the process breaks in real life
The control is simple. What makes it fail is almost never the comparison itself.
The delivery record does not exist. For services, nobody produces one. The person who would know whether the work happened is not the person paying the invoice, and asking them costs an email nobody sends.
The purchase order was never raised. Somebody ordered by email because it was faster. Now there is nothing to match against, and the invoice is approved on trust or held for a week while the story is reconstructed. What the missing document should have contained is in what a purchase order is.
The invoice arrives before the delivery record. Common with staged work. The invoice sits waiting, ages, and the supplier chases you for something that is not actually disputed.
Descriptions do not agree. The PO says one thing, the supplier’s invoice says another, and both are correct in their own vocabulary. A human resolves it in seconds; a matching rule cannot resolve it at all.
The pattern across all four: the control is only as good as the documents feeding it, and the missing document is usually the one nobody is responsible for producing.
The version a small firm can actually run
You do not need a procurement module. You need the three questions the control asks, applied by whoever pays the bills.
Was this agreed, and at this price? Compare against the purchase order if you raised one, or against the contract or the quote if you did not.
Did we get it? For services, ask the person who would know before paying, not after.
Have we already paid this? Check the supplier reference against what you have recorded. This is where a proper expense record does the work: a receipt attached to the supplier and the payment makes a duplicate visible instead of invisible. The distinction between the two documents is in invoice vs receipt.
Three questions, a minute each, on invoices above whatever threshold you set. That is the small-firm version, and it catches most of what the enterprise control catches.
What Enlivy does and does not do here
This article sits on the buying side of the ledger and Enlivy is built for the selling side, so it should be said plainly.
Enlivy has no purchase order module. No requisitions, no goods received notes, no automated matching engine. If you need procurement workflow with approval routing and tolerance rules, that is a different category of product.
What it does hold is the expense side as records rather than paperwork: receipts for what you have been billed, bank transactions for what actually left the account, and the link between them. That covers the duplicate-payment question and most of the price question, which is where the money is for a firm of ten or thirty people.
Proving those balances against their evidence at month end is the same discipline as account reconciliation, and the bank half of it is bank reconciliation.
Why it matters from the other side too
You are also the supplier in somebody else’s three-way match, and that is where this becomes useful to you commercially.
When your invoice reaches a client who runs this control, it is being compared against their PO and their record of delivery. Anything that fails to line up puts your invoice into an exceptions queue that is measured in weeks. That is the argument in purchase order vs invoice, and it is why the PO number belongs in a field rather than a note.
The practical consequences for your own cash: a held invoice inflates your days sales outstanding without anyone disputing anything, and when the payment finally comes through covering several invoices at once, the note explaining which is a remittance advice.
If a matching failure turns out to be your error, the correction is a credit note or a debit note against the original, not a reissued invoice. The rules for that are in invoice numbering.