Three-Way Match Failure Reasons and AR Resolution Steps

Three-way match is the check every AP team runs before money leaves the building. It confirms that the purchase order, the goods receipt, and the vendor invoice all say the same thing. When they don't agree, the invoice gets stuck, and the reasons it gets stuck fall into a short, predictable list. This piece walks through each one, and what AP actually needs to do about it if the goal is getting paid without torching the relationship on the other end.

Quick definitions first, because the vocabulary matters here. The purchase order says what was ordered and at what price. The goods receipt note (sometimes called a receiving report) says what actually showed up. The invoice says what the supplier wants paid. Three-way match compares all three across multiple levels, from header identifiers down to line-item detail and calculated totals. A mismatch at any level puts a hold on the invoice. No release, no payment, full stop.

Worth separating this from ledger reconciliation, since people mix the two up constantly, and shouldn't. Three-way match happens before money moves. Reconciliation, comparing the ledger to the bank statement, happens after. One prevents bad payments. The other catches bad bookkeeping. Treating them as interchangeable is how errors slip through both nets at once.

A few variants exist depending on what's being bought, and picking the wrong one for the purchase type is its own quiet failure mode. Two-way match (PO plus invoice only) works fine for services and recurring payments, anything where nobody's checking a loading dock for a delivery. Four-way match adds a quality inspection report, useful when the condition of the goods, not just the quantity, decides whether payment goes out. Additional match variants stretch further into contract terms and other conditions. More checkpoints, but the same basic logic drives them.

How widespread match failures are in practice

Ardent Partners' AP Metrics That Matter in 2025 puts the average invoice exception rate at 22%, while best-in-class teams hold theirs to 9%. Roughly one in five invoices gets flagged at average shops, versus fewer than one in ten at the teams that have their act together. That's a substantial deviation. That's a different operating model, full stop, and any team still at 22% should stop calling it "normal" and start calling it a backlog.

The gap shows up as cash sitting still. Exception handling stretches payment cycles from a clean 15 days out to 25 or 30, and any early-payment discount on the table quietly evaporates while someone tracks down a signature.

The stakes run past slow processing, too. Per the AFP 2025 Payments Fraud and Control Survey, 79% of organizations experienced payment fraud in 2024, with average losses topping $130,000 per incident. Three-way match exists partly to catch exactly this kind of thing, so a broken match process is a real cost, not just an inconvenience. It's a hole in the fence.

The dollar exposure adds up fast even inside a single company. Settle's research found that 47% of purchase orders had inconsistencies against their matching invoices, adding up to more than $12 million in discrepancies. That's nearly half the POs, not some fringe case anyone gets to shrug off.

None of this is random noise. The distance between a 22% exception rate and a 9% one maps to a handful of specific, repeatable failure types. That's the rest of this piece.

Quantity discrepancies: partial shipments and backorder gaps

The mechanics are simple enough. A PO asks for a certain quantity, the supplier ships something else, the goods receipt logs what actually landed, and if the invoice still reflects the original PO number instead of what showed up, the match fails at the line-item level.

Picture a vendor shipping 480 units against an order for 500, with 20 on backorder. The invoice arrives billing all 500. The goods receipt says 480. Three documents, three different stories, one very stuck invoice.

Manufacturing buyers see a variation on this constantly. Large orders get fulfilled across multiple shipments, each one generating its own receiving entry, but invoices don't always arrive on the same schedule as the goods. Receipts and invoices end up referencing different slices of the same order, and the matching engine has no way of knowing they're related.

Resolution follows a set order, and skipping steps is how invoices bounce back into the queue a second time. Flag and hold the invoice first, no payment moves until it's sorted, then pull the goods receipt and check it line by line against the invoice. Call the supplier and pin down the real number: did they ship 480 or 500? If it's a confirmed short-ship, ask for a revised invoice covering the 480 delivered, or a credit memo for the missing 20. Decide whether to pay the partial invoice now and hold the balance until the backorder ships, or wait for one corrected invoice covering everything, then update the PO and receipt records before releasing payment, so the fix actually sticks.

Lead with facts when contacting the supplier, not accusations. "Our receiving record shows 480 units delivered" gets a faster, calmer answer than "you shorted us." Half the time the supplier's shipping department hasn't even clocked the gap yet, since it's the carrier that dropped the ball, not them.

Price misalignments: why the agreed price and the billed price diverge

Prices drift for a handful of reasons, and not all of them point at the supplier. Stop assuming bad faith before checking your own records; most of the time, the fault sits inside the buyer's own system. Sometimes the supplier raised prices after the PO went out and nobody updated the PO, so every invoice against it trips an exception forever. Sometimes a volume discount got negotiated but never made it onto the PO or the invoice. Sometimes a contract amendment lives in a separate contract system while the ERP's PO record still shows the old terms.

Currency adds its own wrinkle. A PO priced in one currency, an invoice in another, and an exchange rate that doesn't match whatever fixing mechanism the contract actually specifies can pull the total in three different directions at once. And for anything tied to commodity pricing (steel, copper, resins, solvents), the PO reflects the standard cost at order time, but by the time the invoice lands, the market has moved. That's an intentional outcome. That's a legitimate variance AP has to weigh against a tolerance threshold, not reject on sight.

Resolution starts with checking whether the variance falls inside or outside the tolerance band most teams already have set, then checking for a contract amendment or price agreement the PO simply hasn't caught up to yet. If the price hike is unauthorized, go back to the supplier with the PO price and ask for a revised invoice or credit memo. If the change is legitimate, send it to procurement to update the PO before paying; never pay against a stale PO just because it's faster. For currency mismatches, confirm the contractual rate mechanism with procurement and the supplier, then request a corrected invoice if the applied rate is off. Once it's fixed, update the PO master data so the same exception doesn't fire again on the supplier's next invoice.

A price discrepancy is usually an internal filing failure, not a supplier trying anything shady. Blaming the vendor before checking your own PO records is a fast way to sour a relationship over a mistake your own team made.

Unit-of-measure mismatches: when the same quantity isn't the same quantity

The simple version: PO says kilograms, invoice says pounds. Same physical quantity, but the matching system has no conversion logic built in, so it flags a mismatch anyway.

The sneakier version is worse. An invoice bills per kilogram while the contract prices per tonne. Quantities look aligned at the unit level, but the unit price implies a multiplier that only produces the right total if the error happens to cancel itself out. That can mask a real overcharge that a quick glance won't catch, which is exactly why "it looks close enough" should never be the standard anyone signs off on.

High-volume orders bring their own flavor of chaos: a PO for "1,000 cartons" at 12 units each, a goods receipt logging "12,000 pieces," and an invoice billing "1,000 boxes" of 12 pieces apiece. Same underlying quantity, three different labels, and the matching system reads all three as conflicting.

Don't assume the quantities are wrong; check first whether it's a labeling problem or an actual count problem. Convert everything to one common unit and compare. If they land on the same number, the transaction is fine, and the fix is procedural: work with procurement to standardize the unit language between the PO template and the supplier's invoice format. If the numbers genuinely don't match once converted, stop treating it as a UOM issue and route it as a quantity discrepancy instead. Either way, ask the supplier to reissue future invoices using the PO's unit of measure, so the next one clears on its own.

Most UOM mismatches trace back to supplier onboarding, where nobody aligned the vendor's billing system with the buyer's PO format from day one. Fix it at the relationship level. Re-litigating the same conversion error every single invoice cycle is a symptom of a broken process. It's a habit, and a bad one.

Missing or delayed goods receipt notes and what they do to the match queue

Three-way match needs all three documents, no exceptions. A missing or unsigned goods receipt note stalls the invoice even when the invoice itself is flawless.

The lag usually happens because goods arrive, the warehouse team processes the physical delivery, and then the GRN doesn't get entered into the ERP for days. AP ends up holding an invoice it can't match against a receipt that exists in the real world but not yet in the system.

The knock-on effects pile up fast. The supplier starts chasing a payment AP legally can't release yet, which creates friction over a delay that was entirely internal to begin with. Early-payment discounts lapse while the GRN sits in someone's inbox. Month-end accrual gets murky, since AP can't decide whether to accrue the liability without receiving evidence to point to. And a GRN entered in a rush under deadline pressure often carries its own errors, feeding bad data straight into the matching engine.

Confirm it's a timing issue, not a genuine document discrepancy, before escalating anything to the supplier. Contact the receiving team directly with the delivery date and PO number, and ask for the GRN to go in now. Never push receiving to log a GRN without actual physical confirmation: a fabricated receipt to force a payment through defeats the entire point of the control and opens the door to fraud. Once the GRN is in and lines up with the invoice, release the hold. If it turns up a real problem when it's finally entered (short quantity, damaged goods), route it as that specific exception type instead of forcing it back through this one. Tell the supplier what's happening before they have to ask. "Invoice received, receiving confirmation pending, expect resolution by [date]" heads off a lot of unnecessary phone calls.

Maverick spend and missing purchase orders

Maverick spend is anything bought outside the formal PO process. Goods show up, an invoice follows, and AP has nothing to match it against because no PO was ever cut.

This usually isn't malicious. The person who actually places the order, often someone outside finance entirely, doesn't know, or forgets, that a PO needs to exist before the order goes in. By the time the invoice lands on AP's desk, the goods are already sitting in the warehouse and the supplier is expecting a check.

That forces AP into retroactive approval: tracking down a manager willing to sign off on a purchase that already happened. It's slow, it's awkward, and it leaves an audit trail nobody wants to explain later. Add in the classic emergency, a supplier threatening to cut off delivery unless they get paid now, and the pressure to skip the matching process entirely gets very real, very fast.

Flag it immediately as a no-PO exception, then confirm the goods or services were actually received by checking with whoever placed the order. Route it for retroactive PO creation or manager sign-off, documenting who approved it and when, and hold payment until that approval trail exists on paper. Paying against nothing is the exact scenario three-way match was built to stop. Tell the supplier what's going on (invoice received, internal paperwork catching up, realistic payment date attached), and once it's resolved, flag the department that skipped the PO step for a refresher. The fix belongs upstream, not in AP.

If the same department or supplier keeps showing up in this queue, that's not an isolated slip. That's a governance gap, and it's worth a conversation about setting up a standing PO or blanket order to cover whatever they keep buying on the fly.

Data-entry errors, OCR failures, and vendor master mismatches

Sometimes the invoice is completely correct and the PO is the problem. A mistyped unit price or quantity at PO creation follows that document into every match attempt against it, so the invoice looks wrong when really the PO was wrong from the start.

Mistyped PO numbers cause a different failure: the invoice can't be matched at all, not because anything's inaccurate, but because the system literally can't find the document it's supposed to check against.

Scanning paper invoices introduces its own mess. Bad scan quality turns a "1" into an "l," drops a decimal point, or garbles a handwritten note, corrupting the data before it ever reaches the matching engine. Manual matching at high volume runs a 5 to 10% error rate, per Klearstack's analysis, so a meaningful chunk of invoices carry some kind of typo baked in before a human even looks at them.

Vendor master records cause quieter trouble. "Acme Corp," "Acme Corp.," "Acme Corporation LLC," and "Acme Inc" might all be the same supplier, but to a matching system doing string comparison, they're four different vendors. Stale or incomplete vendor records in the ERP make this worse over time. Line-item descriptions carry the same flaw: "Professional Services – Phase 1" and "Consulting Services – Initial Phase" mean the same thing to a person reading both invoices side by side, and mean nothing alike to a system checking for an exact string match.

Fixing this starts with figuring out where the error actually lives: at PO entry, at OCR intake, or in the vendor master. The resolution path differs for each one, and treating a vendor-naming problem like a quantity dispute wastes everyone's time chasing the wrong fix.