The purchase order
What was agreed. Items, quantities, and unit prices, written down by the buyer before anything ships. The PO is the only one of the three that carries the agreed price.
Resources · AP fundamentals
A purchase order, a goods receipt, and an invoice each tell a version of the same purchase. 3-way matching is the discipline of making the three agree, line by line, before anything gets paid. Here is what the check actually compares — and when a lighter check is the honest choice.
The setup
The reason 3-way matching works has less to do with software than with authorship. Each document is written by a different person, at a different time, for a different reason. An error — or a padded invoice — has to survive all three records to get paid.
What was agreed. Items, quantities, and unit prices, written down by the buyer before anything ships. The PO is the only one of the three that carries the agreed price.
What actually arrived. Counted at the dock or checked off on delivery, it records quantities and condition — no prices, because the person receiving boxes is not the person who negotiated them.
What the vendor wants to be paid. The only document written outside the company — which is exactly why it is the one being checked rather than trusted.
The comparison
3-way matching is often described as comparing three documents, which makes it sound like one comparison. In practice it is a series of small ones. For every line on the invoice, the match asks three questions:
Notice that the questions pull from different documents. Price comes from the PO, because that is where the agreement lives. Quantity comes from the goods receipt, because that is where the counting happened. The receipt has nothing to say about money, and the PO has nothing to say about what showed up — each document answers only the question it is qualified to answer. And none of it means much if the invoice was read wrong in the first place: a mis-read quantity fails an honest match and passes a dishonest one, which is why invoice capture and OCR quality comes before matching, not after.
When lines disagree
When a line fails, the failure lands in one of three families — and each family points at a different kind of problem.
The invoice charges a different unit price than the PO agreed. The causes run from clerical — an old quote, a price update that never reached the PO, a case price billed as a unit price — to a vendor quietly raising prices and hoping nobody compares. One small break is a correction; the same small break on every invoice from the same vendor is a conversation.
The invoice bills for more than was received. The innocent version is the partial shipment: 60 of 100 units arrive, and the invoice bills all 100. Less innocent: goods rejected at the dock but billed anyway, or an over-delivery billed with no order to cover it.
A line on the invoice with no counterpart on the PO. Freight added at billing time, a surcharge, a substituted item under a different part number — or something nobody ordered. This family is the hardest to clear automatically, because there is nothing on the other side to compare against. A person has to decide what the line is.
The escape valve
If matching demanded exact equality, nearly every invoice would fail, and it would fail for boring reasons: currency rounding, tax spread unevenly across lines, unit-of-measure conversions, a price list carried to four decimals where the invoice prints two. A control that flags everything protects nothing, because reviewers learn to wave the whole queue through.
A tolerance is a band the company chooses — this much variance on a unit price, this much on a quantity, this much on the line amount — inside which a difference is accepted and recorded, and outside which the invoice stops for review. The point is not to forgive small errors. The point is to spend reviewer attention where a decision actually changes the outcome, and to make the size of “small” a written policy instead of each clerk's mood. Tolerances can also be one-sided: many teams stop an invoice that bills more than was received but let one pass that bills less, because being under-charged is not a risk worth halting payment over.
The lighter check
2-way matching drops the goods receipt and compares the invoice against the purchase order alone. It is sometimes framed as the weaker control, but that misses the point: it is the correct control whenever no honest receipt can exist.
Services are the obvious case. Nothing arrives at a dock for a monthly retainer, a software subscription, or a utility bill — there is nothing to count. Forcing a 3-way match there produces one of two outcomes: invoices that can never clear, or receipts clicked out of habit to unblock them. A receipt confirmed without looking is worse than no receipt, because it dresses noise up as verification.
A workable rule of thumb: if someone can honestly count what arrived, use 3-way. If not, use 2-way and put the weight on the approval instead — the person closest to the work confirms the service actually happened, through approval workflows built for exactly that.
The outcome
A mismatch is not the process breaking; it is the process doing the only thing it exists to do. The invoice stops, the difference is shown plainly — which line, which document, which number — and a person decides: fix the PO, wait for the rest of the shipment, dispute the line with the vendor, or accept the difference with a written reason. Whatever the decision, it should be recorded along with who made it, because months later the question is never whether the invoice was paid. It is why.
This is where Onivo AP sits. It reads the invoice, matches every line against the purchase order and goods receipt — 2-way or 3-way, with price, quantity, and amount tolerances you set — catches duplicate and reissued invoices before they are paid twice, routes exceptions by amount, cost center, and project, and keeps a tamper-evident record of every decision along the way. Approved invoices sync into your ERP as bills, with a check before creation so nothing posts twice. The mechanics are on the 3-way invoice matching page, and there is more like this article in the resources library.
FAQ
It compares three documents line by line — the vendor's invoice, your purchase order, and the goods receipt — checking that price, quantity, and amount agree within the tolerances you set before an invoice can move toward payment.
Exact equality would fail nearly every invoice for boring reasons — currency rounding, tax spread unevenly, unit-of-measure conversions. A tolerance is a written band inside which a difference is accepted and recorded, so reviewer attention goes where a decision actually changes the outcome. Tolerances can be one-sided: stop an invoice that bills more than was received, let one pass that bills less.
Whenever no honest goods receipt can exist — services, retainers, subscriptions, utilities. Nothing arrives at a dock, so there is nothing to count; compare the invoice against the purchase order alone and put the weight on approval by the person closest to the work.
The invoice stops and the difference is shown plainly — which line, which document, which number. A person then decides: fix the PO, wait for the rest of the shipment, dispute the line, or accept the difference with a written reason, and the decision is recorded with who made it.
Bring a recent invoice with its PO and receipt. We will run the match in front of you and show exactly where each line lands.