PO Matching Exceptions: The Six Failures, Which Tolerance Absorbs Them, and Who Resolves Each One

Quick Answer: A three-way match can fail in six ways: quantity variance, price variance, missing receipt, partial delivery, unit-of-measure mismatch, and untracked freight or ancillary charges. Four of the six should usually be absorbed by a tolerance rather than raised as exceptions at all. The two that should always surface — unit-of-measure mismatch and untracked charges — are waiting on a fact from outside AP, not on a signature from inside it. If your exception queue is large, the first thing to examine is your tolerance configuration, not your vendors.

The queue is usually a configuration problem

Turn on three-way matching and the exception queue fills immediately. The instinctive reading is that suppliers are invoicing badly. Usually they are not.

Watch what actually happens to the queue. An AP clerk opens an exception, sees the invoice is $4.20 over the purchase order on a $3,000 line, and approves it. Then does it again. Then again. If the same person approves the same shape of variance every time without investigating, that variance was never a decision — it was a tolerance that had not been set.

This matters because it disguises the exceptions that are decisions. A queue of 400 items where 380 are rubber-stamped teaches everyone to rubber-stamp, and the twenty that needed thought get the same three seconds as the rest.

So the useful question is not "how do we process exceptions faster." It is which of these six failures should have been absorbed before a human ever saw it, and for the rest, who holds the fact that resolves it.

The distinction that organises everything

An exception is waiting on one of two things.

A signature. Everything needed to decide is already on the screen. Someone with the authority to accept the variance needs to accept it. These can be automated away with a tolerance, or routed by authority matrix — they do not need investigation.

A fact. Something outside AP is unknown. Did the warehouse actually receive 48 or 50? Was the price renegotiated? Is that freight charge contractual? No amount of approval authority resolves these, because the person approving does not have the information. Routing these to a finance approver produces a guess with a signature on it.

Sorting your queue into those two piles is a twenty-minute exercise and it changes what you build. The signature pile becomes tolerance configuration. The fact pile becomes routing to the person who holds the fact — which is often not in finance at all.

The six failures

1. Quantity variance

The invoice bills for a different quantity than the receipt records. Ordered 100, received 98, invoiced 100.

Waiting on: a fact, usually. Did two units not arrive, or did receiving miscount, or did they arrive on a second truck logged separately?

Tolerance: absorb small variances only where the unit value is low and the item is measured rather than counted — bulk material, liquids, anything weighed. A 2% tolerance on sand is sensible; a 2% tolerance on laptops is a hole. Set the tolerance per item category, never globally.

Owner: receiving, not AP. AP cannot know whether the truck was short. The question goes to the person who signed for it, and the answer is a corrected goods receipt, not an approved invoice.

Evidence produced: amended receipt with the reason and who amended it.

2. Price variance

Invoice unit price differs from the purchase order price. Ordered at $12.00, invoiced at $12.40.

Waiting on: a fact — was a new price agreed? — that lives with procurement, not AP.

Tolerance: a small percentage with an absolute cap is the standard shape, because a 2% tolerance on a $200,000 line is $4,000. Use both: absorb if the variance is under 2% and under a fixed currency amount. Most systems support only one and teams pick the percentage, which is the wrong one to pick alone.

Owner: procurement. If the price genuinely changed, the purchase order should be amended so the next invoice matches; approving the invoice without amending the PO guarantees the same exception next month. This is the single most common cause of recurring exceptions.

Evidence produced: amended PO, or a rejection back to the supplier citing the agreed price.

3. Missing receipt

The invoice arrives before anything has been received, or before receiving has entered it.

Waiting on: time, mostly. This is not a variance at all — it is a sequencing artefact.

Tolerance: not a tolerance. Use a waiting period instead. Hold the invoice for a defined window — commonly a few days beyond expected delivery — before it becomes an exception. An invoice that has been waiting two days for a receipt is normal; one waiting fifteen is a real problem, and only the second should occupy anyone.

Owner: nobody, until the window expires. Then receiving.

Evidence produced: the ageing clock itself, which is what tells you whether receiving is behind or the goods never came.

4. Partial delivery

Received 60 of 100 ordered; supplier invoices for the 60 delivered.

Waiting on: a signature, and often not even that.

Tolerance: this should not be an exception in a correctly configured system. Partial receipt against an open PO with matching partial invoicing is normal commercial behaviour. If your system raises it, the configuration is treating the PO as a single all-or-nothing commitment rather than as a running balance.

Owner: AP can close it, if the system shows the remaining balance clearly.

Evidence produced: the PO balance after the match.

The reason to name it explicitly is that partial deliveries generate a large share of exception volume in teams whose matching is configured strictly, and it is pure noise.

5. Unit-of-measure mismatch

The PO says 10 boxes. The invoice says 120 units. Both may be correct and describe the same delivery — or the supplier may have shipped 120 boxes.

Waiting on: a fact, and a genuinely dangerous one.

Tolerance: none, ever. This is the exception that must always surface. A UOM mismatch does not present as a small variance; it presents as an order-of-magnitude difference that a percentage tolerance will never absorb — but it also frequently presents as a match when a conversion factor is set up wrongly, in which case nothing surfaces at all and you pay twelve times over.

Owner: procurement and item master. The durable fix is a conversion factor on the item record, not a decision on this invoice.

Evidence produced: the item master conversion factor, dated, with who set it.

This is the failure that justifies the whole matching control. See three-way matching for how the control is meant to work, and two-way vs three-way matching for when the receipt leg is worth the effort.

6. Untracked freight and ancillary charges

The invoice total exceeds the PO because of freight, handling, fuel surcharge, or packaging that was never on the purchase order.

Waiting on: a fact — is this charge contractual?

Tolerance: do not absorb these with a value tolerance, because a value tolerance cannot distinguish a legitimate freight line from an inflated unit price. Handle them structurally instead: either the PO carries an expected charges line, or the supplier agreement names which ancillary charges are permitted and at what rate.

Owner: procurement, once. After that it is a matching rule, not an exception.

Evidence produced: the contract clause permitting the charge.

The configuration table

Failure	Waiting on	Tolerance	Owner of the rest	Should it ever auto-approve
Quantity variance	Fact	Per category, measured goods only	Receiving	Low-value measured items only
Price variance	Fact	Percentage and absolute cap	Procurement	Yes, within both limits
Missing receipt	Time	Waiting period, not a tolerance	Receiving after window	Not applicable
Partial delivery	Signature	Should not raise at all	AP	Yes
UOM mismatch	Fact	Never	Procurement / item master	Never
Untracked charges	Fact	Structural, not value-based	Procurement	Only once contracted

Setting tolerances from your own data

Do not adopt a benchmark. Derive them:

1. Export 90 days of closed exceptions with type, variance amount, variance percentage, and the resolution.
2. Find the ones that were approved without change. These are your rubber-stamp population — the variance was accepted exactly as invoiced.
3. Look at the distribution of that population. If 90% of accepted price variances are under 1.5% and under $75, those two numbers are your tolerance, and you have just removed 90% of that exception type from the queue.
4. Check what the remaining 10% cost you. If nothing in the tail turned out to be recoverable, widen. If the tail contains real recoveries, narrow and accept the volume.
5. Re-run quarterly, because supplier behaviour and your own price agreements move.

The output is not a single tolerance. It is a tolerance per exception type, per item category, with an absolute cap alongside every percentage.

What to measure afterwards

Three numbers tell you whether the configuration is working:

• Share of exceptions closed without a change to any document. If this is high, your tolerances are too tight — those were signatures, not decisions.
• Recurrence by supplier and by item. The same exception recurring monthly means the underlying record was never corrected. Price variance is the usual culprit, because approving the invoice is faster than amending the PO.
• Age at close, split by waiting-on-a-fact versus waiting-on-a-signature. Fact exceptions legitimately take longer. Mixing them into one average hides whether your signature queue is slow.

Where Ken fits

Ken holds the invoice against the match result and routes each exception type to the owner who can resolve it, rather than to whoever is next in an approval chain. Tolerances are configured per type and per category rather than as one global percentage, and every override records who accepted the variance and against which values.

What Ken does not do: it cannot correct a goods receipt or amend a purchase order for you. Those live in your ERP and with receiving and procurement, and the honest description of the product is that it gets the exception to the right person quickly with the right evidence attached — not that it resolves facts it does not hold.

For the wider queue design beyond matching specifically, see invoice exception handling, which covers the full eight-type taxonomy and per-type SLAs.

FAQ

What are the most common PO matching exceptions?

Six types account for nearly all of them: quantity variance, price variance, missing receipt, partial delivery, unit-of-measure mismatch, and untracked freight or ancillary charges. Partial deliveries and small price variances usually make up the bulk of raw volume, and both are largely configuration artefacts rather than genuine problems.

What tolerance should I set for three-way matching?

Derive it rather than adopt a benchmark. Export 90 days of closed exceptions, isolate those approved without any document change, and set the tolerance at the point that covers most of that population — using a percentage and an absolute cap together, per item category. A percentage alone allows an unacceptably large absolute variance on high-value lines.

Who should resolve PO matching exceptions?

The person holding the missing fact. Quantity variances go to receiving, price variances and ancillary charges to procurement, and unit-of-measure mismatches to whoever owns the item master. Routing a fact-based exception to a finance approver produces an approved guess, because the approver does not have the information the exception is waiting on.

Why do the same exceptions keep recurring every month?

Because the invoice was approved and the underlying record was not corrected. Approving a price variance without amending the purchase order guarantees the identical exception on the next invoice from that supplier. Recurrence by supplier and item is the metric that exposes this.

Should unit-of-measure mismatches ever be auto-approved?

No. A UOM mismatch is the one failure that must always surface, and it is also the one most likely to pass silently when a conversion factor is configured incorrectly — in which case there is no exception at all and the overpayment is invisible. Fix it on the item master rather than on the invoice.