Three way matching is the core control in accounts payable: the invoice from the supplier is matched against the purchase order that authorized the spend and the goods receipt that confirms delivery. When the three documents agree within tolerance, the invoice is approved for payment. When they do not, an exception routes for review.
The model assumes a clean one to one to one relationship: one PO, one receipt, one invoice. Blanket POs break that assumption. A single blanket might have dozens of releases, each with its own receipts and invoices, all consuming a single limit.
Configuring three way matching to work correctly on blanket releases is one of the more technical and overlooked parts of blanket PO governance. Done wrong, it produces systematic exceptions that desensitize the AP team to real issues. Done right, it preserves the control benefit at scale.
How Three Way Matching Normally Works
On a standard PO, the three way match compares:
- PO: supplier, items, quantity ordered, unit price, total value, delivery terms
- Receipt: supplier, items received, quantity received, date received
- Invoice: supplier, items invoiced, quantity invoiced, unit price, total value, payment terms
The matching engine checks that the three documents agree on supplier, items, quantities (with tolerances for under or over delivery), and prices (with tolerances for minor variances). When agreement is within tolerance, the invoice clears for payment. When the variance exceeds tolerance, an exception routes for manual review.
This works because the PO is a single transaction with a single expected outcome.
Why Blankets Complicate the Match
Blankets introduce four complications that the standard match logic does not handle without configuration.
Multiple receipts per PO
A blanket release for $50K of inventory may be delivered in three shipments over six weeks. Each shipment generates a goods receipt. The invoice may come per shipment, in batches, or as a single invoice at the end. The match needs to handle multiple receipts against a single release.
Multiple invoices per release
Even for a single release, the supplier may invoice in installments. Service blankets are particularly prone to this: a release for $30K of professional services might generate weekly invoices over a month. Each invoice needs to match against the release and accumulate appropriately.
Aggregated invoices across releases
Some suppliers invoice multiple releases on a single consolidated invoice. The invoice references several release numbers, with subtotals for each. The matching engine has to disaggregate the invoice and match each portion to its corresponding release.
Blanket level versus release level matching
The question of what the invoice matches against. Should the invoice be matched at the release level (this invoice line equals this release line)? Or at the blanket level (cumulative invoiced does not exceed cumulative committed against the blanket)? The right answer is usually both, but most ERPs default to one or the other and require configuration to do both.
Common Failure Modes
Five failure patterns show up regularly when blanket matching is not configured well.
Over receipt against a release
Receiving accepts more goods than the release authorized, either because the supplier shipped over or because the receiving team did not verify against the release quantity. The invoice arrives for the over received amount, the match fails, and the AP team has to decide whether to pay the higher amount or push back to the supplier.
Partial delivery treated as final
A release is delivered in multiple shipments, but the first shipment gets marked as fully received in the system. When the second shipment arrives, there is no remaining quantity to receive against. The match fails on the second shipment, and either the receipt has to be unwound or the second shipment goes through as an unmatched invoice.
Invoice references the blanket but not the release
The supplier sends an invoice that references the blanket PO number but not the specific release. AP has to figure out which release this invoice is meant to match against, often by looking at the items and dates. When invoices arrive for multiple releases this way, the disambiguation work becomes substantial.
Cumulative invoicing exceeds blanket limit
Individual releases all matched fine, individual invoices all looked correct, but in aggregate the invoices have exceeded the blanket limit. The control was operating at the release level but not at the blanket level.
Pricing variance because the blanket price list updated
The blanket references a price list that was updated mid period. Releases issued under the old prices have invoices that arrive under the new prices, or vice versa. The match flags price variances that are technically correct but inconsistent with the release.
How to Configure Matching Correctly
Five configuration choices, made deliberately, prevent most of these failures.
- Set the matching to operate at both the release level and the blanket level. Each invoice matches to its release, and cumulative consumption is tracked against the blanket limit independently.
- Define tolerances for quantity, price, and total value at the release level. Tolerances should be tighter for high value releases and looser for low value releases.
- Require release numbers on every invoice. Communicate this requirement to suppliers as part of the blanket setup. Without release numbers, the matching engine has no anchor for the comparison.
- Configure partial receipts to handle multiple shipments cleanly. Each receipt should consume only the quantity actually received, leaving the remainder open for subsequent receipts.
- Lock the price list referenced by the blanket as of the release date. Releases issued under the old prices match against the old prices, even if the price list updates during the validity period.
What Still Requires Manual Review
Configuration handles the typical patterns. Some situations still need human judgment.
- Aggregated invoices that cover multiple releases need to be disaggregated for matching, which is rarely fully automated
- Cancelled releases with partial deliveries already received require manual reconciliation of what was delivered, what was invoiced, and what should be paid
- Disputes about quality or delivery that result in invoices being held for credit notes need manual coordination between receiving, AP, and the supplier
- Blanket amendments mid period (limit changes, scope changes, price changes) require manual review of releases issued under the prior terms to confirm correct treatment
The objective is not zero manual review. It is to make the manual review focused on legitimate judgment calls rather than on routine pattern mismatches that the system should be handling.
What Exception Rates Tell You
The exception rate on blanket release matching is a useful metric for diagnosing where the issues are concentrated.
A healthy exception rate on blanket matching is typically 5% to 15% of invoices. Above that range, the cause is usually one of three things: blanket configuration is not handling the supplier's invoicing pattern correctly, releases are being processed informally without proper documentation, or the supplier itself has billing accuracy issues that should be addressed at the relationship level.
Tracking exception rates by blanket and by supplier surfaces the patterns. Concentrated exception sources usually need specific intervention rather than across the board changes.
Start Here
Pull the last quarter of matching exceptions on your blanket POs. Categorize them by failure type: over receipt, partial delivery, missing release number, cumulative limit exceeded, pricing variance, or other.
The distribution shows you where to focus. If 60% of exceptions are missing release numbers, the fix is supplier communication. If 40% are cumulative limit issues, the matching configuration needs the blanket level layer added.
