Skip to content
opsveraopsvera
Workflow breakdown
2026-08-04 · 4 min read

Three-way invoice matching, broken down step by step

What AP teams check by eye, what an agent can check reliably, and the 5% that should always stop.

Three-way matching is one of those processes everyone in finance can describe in a sentence and nobody can automate in a week. The sentence is: check the invoice against the purchase order and the goods receipt, and only pay if all three agree.

The difficulty is entirely in the word agree.

The three documents, and what each one is for

The purchase order is what you said you would buy. It is your intent, agreed before anything shipped.

The goods receipt is what actually arrived, recorded by whoever opened the boxes. It is the only document written by someone who physically saw the goods.

The invoice is what the supplier says you owe. It is a claim, not a fact.

Matching exists because those three can disagree in ways that cost real money, and because the supplier's document is the one you should trust least — not out of suspicion, but because it was produced furthest from the event.

What a person actually does

Watch an AP clerk do this and the work splits into three very different activities.

The first is finding. Which PO does this invoice belong to? Often the invoice quotes the PO number, and often it quotes it wrongly, or quotes the delivery note number, or quotes nothing at all and you match on supplier plus approximate value plus date.

The second is comparing. Line by line: does the quantity billed match the quantity received, does the unit price match the price agreed, do the extended totals add up, is the tax treatment right.

The third is judging. The line is off by two units. Is that a short shipment, a partial delivery with the rest to follow, or an error? Nothing in the three documents tells you. It depends on the supplier, the product, and whether this happens every month.

An agent can do the first two extremely well. The third is where it should stop — and the design question is not how to automate judgement, but how to route it cleanly.

Step by step

The matching sequence

  1. 01Read the invoice, whatever form it arrives in
  2. 02Resolve it to a purchase order
  3. 03Pull the goods receipt for that order
  4. 04Compare header values: supplier, currency, total, tax
  5. 05Compare line by line: quantity, unit price, extended amount
  6. 06Classify every discrepancy against your tolerance rules
  7. 07Post the clean lines, hold the rest with both values shown

Step two is where most implementations quietly fail. Resolution is not a lookup; it is a small search problem. A robust version tries the quoted reference, then the supplier's own order number if you store it, then supplier plus value plus date window — and when more than one candidate survives, it stops rather than guessing. A wrong match is far more expensive than an unmatched invoice, because an unmatched invoice sits visibly in a queue and a wrong match pays the wrong supplier.

Step six is where your business actually lives. "Tolerance" sounds like one number and never is. Most operations end up with something like: price variance under half a percent posts silently, quantity variance of any size stops, short shipments route to the warehouse lead rather than AP, and anything from a supplier onboarded in the last ninety days holds regardless.

Those rules are not clever. They are simply yours, and no generic product ships with them.

The 5% that should always stop

Across most AP workflows the great majority of invoices match cleanly. The value of automating is not that it handles the hard ones — it is that it makes the easy ones disappear so a person only ever looks at the hard ones.

Which means the agent's most important output is not the posted invoice. It is the exception, presented well.

A held invoice is only useful if the person opening it can decide in seconds. That means both numbers, the source document, and the rule that stopped it — on one screen.

What makes an exception cheap to clear: the invoice line and the receipt line side by side with the difference calculated, the original PDF one click away, the named rule that triggered the hold, and who owns it. What makes it expensive: a notification saying "invoice requires review" and a link to a queue.

What this looks like when it runs

The realistic end state is not an empty AP inbox. It is an inbox that contains only the invoices that genuinely needed a human, each one arriving with the comparison already done.

The clerk stops being a comparison engine and starts being a decision-maker, which is the part of the job that needed a person all along. That is a smaller change than "AI does accounts payable", and a much more durable one.

Where to start if you are scoping this

Pull last month's invoices and sort them into three piles: matched cleanly, matched after a bit of digging, and genuinely disputed. The first pile is what you automate first. The second pile tells you what your resolution logic has to handle. The third pile is the work that stays with your team, and it should stay with them.

If the first pile is not the biggest by a wide margin, the problem is upstream in purchasing, and automating the matching will not fix it.