When a three-way match fails, teams often assume fraud or commercial disputes, but the reality is far more mundane: most exceptions stem from formatting errors, unit mismatches, and ambiguous partial deliveries. The purchase order and the receipt frequently describe the exact same shipment using different conventions, forcing accounts payable to spend hours manually reconciling avoidable mistakes. To achieve a seamless three-way match, procurement leaders must treat receipt and Advance Shipping Notice (ASN) fields as contractual data specifications rather than informal operational notes. In this guide, we break down the six essential receipt fields, ASN best practices, and contracting clauses required to eliminate match exceptions at the source.
TL;DR
- Match exceptions are mostly formatting rather than disputes: unit mismatches, ambiguous partials, and identifiers that do not correspond.
- Require six receipt fields, and state the unit explicitly even where it looks redundant.
- An ASN buys time by surfacing discrepancies at dispatch. The receipt should govern where the two disagree.
- Put the requirement in the supplier agreement, not a purchase order note, and specify what happens when data does not conform.
- See how Merlin Intake handles procurement requests. Request a demo.
Three-way match fails on formatting far more often than on fraud. The purchase order says one thing, the receipt says another, and both are correct descriptions of the same delivery expressed differently.
Most match exceptions are not disputes. They are unit mismatches, partial deliveries recorded ambiguously, and identifiers that do not correspond. Every one of those is preventable by specifying what receipt and advance shipping notice data must contain before the first order is placed, rather than reconciling afterward.
This is written for procurement teams specifying supplier data requirements, working out what to ask for and where to put the requirement.
The framing matters because it determines who fixes it. Treated as a finance problem, match exceptions get handled by adding reconciliation capacity. Treated as a specification problem, they get handled by writing a requirement once and applying it to every supplier that follows.
What actually causes match exceptions?
Four things, sized in Figure 1, in roughly descending order.
Unit mismatch. The order is in cases, the receipt is in units, and the quantities disagree by the pack factor. This is the largest single cause and the most mechanical to prevent.
Partial delivery ambiguity. A shipment arrives incomplete and the receipt does not distinguish between short-shipped and back-ordered, so the match cannot tell whether to expect more.
Identifier mismatch. The supplier references their own order number rather than yours, or the line reference does not correspond to the purchase order line.
Timing. The invoice arrives before the receipt is recorded, which is a process problem rather than a data problem but presents identically in the exception queue.
Only the fourth is about your internal process. The other three are specification failures, and specifications are written by procurement.
There is a fifth cause that sits underneath the other four: nobody agreed what good looked like before the first order. Specification failures are not usually disagreements about the specification. They are the absence of one, discovered transaction by transaction.
Figure 1: Four causes, and how much of the queue each accounts for.
APQC measured transaction processing cost rather than match exceptions. The connection drawn here is that an exception requiring manual reconciliation adds that cost again to a transaction already paid for, which is what makes prevention cheaper than resolution.
What should you require in receipt data?
Six fields, and each maps to a failure above.
Your purchase order number and your line number, not the supplier’s reference. Quantity and the unit that quantity is expressed in, stated explicitly rather than assumed. An explicit completion status for the line, distinguishing complete, partial with more expected, and partial with the balance canceled. Delivery date. And an item identifier that matches what the order used.
The two that get omitted are the explicit unit and the completion status. Both are omitted because they seem obvious, and both cause the two largest categories of exception precisely because everyone assumed the other party understood.
State the unit even where it seems redundant. Redundancy is cheap and the alternative is an afternoon of reconciliation per occurrence.
There is an ordering point worth making. Specifying receipt data is worth doing even if you never implement ASNs, and specifying ASNs without first fixing receipt data achieves very little. The receipt is the record that matching depends on. The ASN is an early warning about it.
The identifier question deserves its own attention because it is the cheapest to fix and the most often left alone. Agreeing at onboarding which reference appears on the receipt removes an entire exception category, and it costs one conversation.
What does an advance shipping notice add?
Time, mostly, and the chance to fail earlier, as Figure 2 shows.
An ASN tells you what is coming before it arrives. Its value in match terms is that it lets a discrepancy surface at dispatch rather than at receipt, when it can still be corrected without a credit note.
The fields worth requiring are the same as the receipt set plus expected delivery date and, where relevant, tracking or consignment reference. What an ASN should not do is become a second source of truth. If the ASN and the receipt disagree, the receipt governs, and that precedence should be written down rather than discovered during a dispute.
ASNs are worth requiring for high-volume suppliers and rarely worth the integration effort for long-tail ones. The threshold is usually volume rather than value.
Partial deliveries deserve particular attention because they are the case where an ambiguous record costs the most. A line recorded as partial with no indication of intent leaves the match unable to decide whether it is waiting or complete, so the exception sits open until someone contacts the supplier. Making completion status an explicit field removes an entire class of enquiry.
Figure 2: The later a discrepancy surfaces, the more it costs.
WorldCC measured how contracting functions allocate responsibility rather than receipt data. Its bearing here is that if negotiation dominates contracting capacity, a data specification agreed during it costs almost nothing extra, while raising it afterward requires reopening a settled agreement.
Where should the requirement live?
In the contract or supplier onboarding pack, not in a purchase order note.
Figure 3 makes the point. A data requirement in a purchase order note is a request. In the supplier agreement it is an obligation, and it survives changes of account manager on both sides. This is the single most consequential point here and it is routinely the one missed, because data format feels operational rather than contractual.
The requirement should specify the fields, the unit convention, the identifier your system expects, and what happens when data does not conform. That last clause matters. Without it, non-conforming data is accepted and reconciled manually forever, which is exactly the outcome the specification existed to prevent.
Merlin Intake passes structured requests to downstream systems in coded form, which means the order side of the match starts clean. The supplier side is a specification and contracting question, and no platform resolves it on your behalf.
Figure 3: A note is a request. A clause is an obligation.
How do you check whether this is working?
Count exceptions by cause rather than by volume.
An exception queue reported as a single number tells you there is a problem. The same queue split into unit mismatch, partial ambiguity, identifier mismatch, and timing tells you which specification clause to fix, and typically shows the exceptions concentrating in a small number of suppliers.
That concentration is the useful finding. Match exceptions feel like a systemic problem and are usually a handful of supplier feeds, which makes them addressable by conversation rather than by project.
Hackett studied the procurement agenda rather than match exceptions. It matters because manual reconciliation of exceptions is precisely the work a team with declining headcount cannot absorb, which turns a data specification into a capacity decision.
Solving three-way match friction does not require expanding reconciliation teams or running complex system overhauls, it requires clear supplier data governance. By enforcing explicit unit definitions, completion statuses, and line-item references directly within supplier contracts, you address the root causes of invoice holds before orders are dispatched. Categorize your exception queue by cause, fix non-conforming supplier feeds, and turn receipt data into an automated driver of purchasing efficiency.
Ready to start your purchase orders clean and keep downstream matching automated? Request a demo to see how Zycus Merlin Intake captures structured, fully coded request data from day one.
Frequently asked questions
Q1. What causes three-way match exceptions?
Unit mismatches between order and receipt, ambiguous partial deliveries, identifiers that do not correspond between supplier and buyer systems, and invoices arriving before receipts are recorded. The first three are specification failures rather than disputes, and they are preventable by defining data requirements before ordering.
Q2. What data should a supplier receipt include?
Your purchase order and line number, quantity with the unit explicitly stated, a completion status distinguishing complete from partial, delivery date, and an item identifier matching the order. The explicit unit and the completion status are the two most often omitted and the two that cause the most exceptions.
Q3. What is an advance shipping notice?
An ASN is a message sent by a supplier before delivery stating what is being shipped, in what quantity, and when it is expected. Its value for matching is that discrepancies surface at dispatch rather than at receipt, while they can still be corrected without a credit note.
Q4. Should you require ASNs from all suppliers?
No. ASNs justify the integration effort for high-volume suppliers and rarely for long-tail ones. The threshold is usually transaction volume rather than spend value, since the benefit is per-transaction reconciliation avoided rather than proportional to the amount.
Q5. Where should supplier data requirements be documented?
In the supplier agreement or onboarding pack rather than in purchase order notes. A requirement in a purchase order is a request. In the contract it is an obligation, and it survives changes of personnel on both sides. This distinction is routinely missed because data format feels operational rather than contractual.
Q6. What happens if the ASN and the receipt disagree?
The receipt should govern, and that precedence needs stating in the agreement rather than being decided during a dispute. An ASN describes intent and a receipt describes what arrived, so treating the ASN as a second source of truth creates a reconciliation problem instead of preventing one.
Q7. How do you reduce match exceptions?
Categorize them by cause rather than counting them, since the split between unit mismatch, partial ambiguity, identifier mismatch, and timing points at different fixes. Exceptions typically concentrate in a few supplier feeds, which makes them addressable through conversation rather than a systems project.
Q8. Does intake software prevent match exceptions?
It ensures the order side of the match is complete and coded, which removes the exceptions caused by incomplete or free-text requests. It cannot control what a supplier sends back, so the receipt and ASN side remains a specification and contracting matter regardless of platform.
