Three-way matching is the accounts payable control most CFOs assume catches invoice errors before payment. In SAP, the system compares the purchase order, goods receipt, and vendor invoice. If quantities or prices don’t align within configured tolerances, the invoice blocks for payment.
But blocked invoices still get paid. And overpayments still happen.
How Three-Way Matching Is Supposed to Work
When you enable three-way matching in SAP, the system performs automatic checks. It compares invoice line items against the corresponding purchase order and goods receipt document. The logic verifies quantity received matches quantity invoiced. It checks that the invoice price matches the PO price.
If discrepancies fall within tolerance, the invoice posts and queues for payment. If discrepancies exceed tolerance, SAP sets a payment block. Someone must investigate and either correct the data or manually release the block.
The control depends on three preconditions. First, every purchase must have a PO. Second, goods receipts must be recorded accurately when materials arrive. Third, tolerances must be set narrow enough to catch meaningful variances.
Any gap in these preconditions creates leakage.
Where Tolerances Create Exposure
SAP allows you to configure matching tolerances at multiple levels. You can set percentage and absolute value variances for price differences. You can define quantity over-delivery limits. You can establish blanket tolerances by company code, vendor, or material group.
Wide tolerances reduce AP workload. They also create overpayment exposure.
A five percent price variance sounds reasonable until you apply it to a million-dollar PO. That tolerance allows a fifty-thousand-dollar overpayment to clear automatically. Quantity tolerances work the same way. A ten percent over-delivery allowance lets vendors ship and invoice for goods you didn’t order or receive.
Most organisations configure tolerances based on what volume of exceptions AP can handle, not what variance represents actual business risk. The result is a control calibrated to operational convenience rather than financial exposure.
The Goods Receipt Accuracy Problem
Three-way matching only works if goods receipts are accurate. In practice, they frequently aren’t.
Receiving staff record goods receipts based on packing slips or delivery notes, not actual counts. They batch-post receipts at shift end rather than at the moment goods arrive. They copy PO quantities into the goods receipt rather than verifying what actually showed up.
When the goods receipt is wrong, three-way matching validates the invoice against incorrect data. The system sees a match. The invoice pays. The overcharge or short-delivery goes undetected.
This problem intensifies in service procurement and indirect spend categories. Many services have no formal receiving process. The goods receipt is a formality posted by AP or procurement after the invoice arrives, specifically to clear the three-way match. At that point the control becomes a data entry step with no verification value.
User Overrides and Month-End Pressure
SAP provides mechanisms to release payment blocks. The MRBR transaction lets AP staff review blocked invoices and release them manually. This override exists because legitimate variances occur — price changes, partial deliveries, shipping charges not on the PO.
But override authority is rarely restricted by dollar threshold or monitored for patterns. At month-end, when invoice volumes spike and suppliers call about payment, AP teams release blocks to clear the queue. The investigation that’s supposed to happen before the override often doesn’t.
Some organisations discover that a small number of AP users account for the majority of manual releases. Those users are either processing the most complex transactions or they’ve learned that releasing blocks is faster than investigating them.
What Three-Way Matching Doesn’t Catch
Even when three-way matching works as designed, it doesn’t catch several common overpayment scenarios.
Duplicate invoices from the same vendor with different invoice numbers clear matching if they reference a valid PO and goods receipt. The system doesn’t inherently look for duplicate payments of the same underlying transaction.
Pricing errors against contract terms aren’t visible to the matching logic if the PO was created at the wrong price. Three-way matching validates invoice against PO, not PO against master agreement or last price paid.
Charges for goods never received can pass matching if someone posts a goods receipt — whether that receipt reflects physical delivery or just clears a workflow step.
Tightening Controls Without Creating Gridlock
The fix isn’t eliminating tolerances or blocking every variance. That creates an AP queue that never clears and vendors who stop answering your calls.
Start with tolerance analysis by spend category. Set tighter thresholds on high-value POs and high-risk vendor groups. Leave wider tolerances on low-dollar, low-risk transactions. Monitor the volume of exceptions that result and adjust.
Implement receiving accuracy audits. Cycle-count goods receipts against physical inventory. Compare receiving logs to posted goods receipt documents. Measure accuracy by receiver and by warehouse.
Restrict override authority by dollar threshold and require supervisor approval above certain amounts. Report on release activity by user to identify where retraining or process correction is needed.
Segregate duties so the same person doesn’t create the PO, post the goods receipt, and release payment blocks. This basic segregation exists in most organisations’ policy documents but breaks down in practice when workload concentrates on a small AP team.
Three-way matching reduces certain types of payment error. It doesn’t eliminate overpayments. Organisations that treat it as a complete control rather than one element of a broader compliance framework will continue to find that blocked invoices still get paid and variance tolerances still let overcharges through.
If you’re running SAP across a $50M+ AP spend and haven’t looked at what’s cleared three-way matching in the past 36 months, a recovery audit will likely find money. Fintralis runs those audits on contingency — we only get paid on documented recoveries. No cost to audit, and you’ll know exactly where configuration and process gaps are creating exposure.
Frequently asked questions
What is three-way matching in SAP?
Three-way matching in SAP compares the purchase order, goods receipt, and invoice before payment. The system checks that quantities and prices align across all three documents. If discrepancies exceed configured tolerances, the invoice is blocked for payment until someone resolves the mismatch manually.
Why do overpayments still occur with three-way matching enabled?
Overpayments occur when tolerances are set too wide, when users force-release blocked invoices without investigation, when goods receipts are recorded incorrectly, or when configuration doesn’t cover price changes, shipping charges, and other edge cases. The control exists, but execution gaps remain.
What tolerance settings in SAP cause the most overpayment leakage?
Price and quantity variance tolerances set above two percent create the largest exposure. Many organisations configure five or ten percent tolerances to reduce manual reviews, but this allows significant dollar leakage on high-value purchase orders. Blanket tolerances applied across all vendor or material groups compound the problem.
How do AP teams bypass three-way match controls in SAP?
AP staff use the MRBR transaction to release blocked invoices, record backdated goods receipts to clear payment blocks, or post invoices to different account assignments that skip matching logic. These workarounds usually happen under month-end pressure when invoice volumes spike and payment deadlines loom.
Can accounts payable recovery services find overpayments that passed three-way matching?
Yes. Recovery audits examine paid invoices for duplicates, pricing errors against contracted rates, and payment of non-existent charges regardless of whether three-way matching was applied. The audit looks at the entire payment population, not just exceptions the system flagged during processing.
Should we tighten SAP matching tolerances to prevent overpayments?
Tighter tolerances reduce leakage but increase manual workload. The right approach balances risk exposure against operational capacity. Set tighter tolerances on high-spend categories and vendors, wider tolerances on low-risk purchases. Monitor override frequency by user and buyer to identify where process training is needed rather than blanket system restrictions.
