Quantity and receipt mismatches: what an agent checks first

Quantity and receipt mismatches are invoices that fail the quantity leg of three-way matching: the quantity billed disagrees with the quantity recorded on the goods receipt, the ERP document that confirms what physically arrived. The invoice stops in a hold queue until someone establishes how many units actually landed. Alongside price variance exceptions, quantity mismatches account for the bulk of match failures, and most of them trace back to how and when the receipt was recorded rather than to anything wrong on the invoice.

This wiki describes source-to-pay concepts the way they look once AI agents carry the operational work – posting matches, reading delivery documents, clearing holds – while people keep the calls that need judgment. A conventional glossary files the quantity mismatch under tasks waiting for an AP clerk; this page treats it as a case an agent investigates, which changes which facts about the goods receipt matter most.

The goods receipt is the least reliable document in the match

Of the three documents the match compares, two are authored carefully. The purchase order is written by a buyer at a desk, inside the ERP, with the agreed units and prices in front of them. The invoice comes out of the supplier's billing system, which has its own controls because the supplier wants to be paid. The goods receipt is different in kind: it is a data entry describing a physical event at a loading dock, usually keyed by someone whose primary job is moving freight, often hours or days after the event it describes. The mechanics of the comparison itself are covered in how three-way matching works; what matters here is the asymmetry. When an agent picks up a quantity mismatch, its first working assumption is that the PO and the invoice are probably both sound and the open question is what the receipt actually captured.

What happens at the dock and what posts in the ERP are two different events

Most quantity and receipt mismatches open in the gap between a delivery and its system record, which makes them one of the most common families of invoice exceptions. Take a normal receiving morning. A truck arrives at 7:40 with three pallets of packaging film. The receiver counts pallets, signs the driver's delivery note, and stages the goods. The system posting – in SAP, a goods movement keyed against the PO line – happens later: at the end of the shift if the dock is busy, the next day if the receiver works from a stack of paper notes, or never, if a note goes missing. Four things routinely go wrong inside that gap:

• Late postings. Many suppliers invoice the moment goods ship, so the invoice can arrive and hit the match before the receipt exists in the system. The match reads zero received against a full billed quantity and flags a correct invoice.
• Partial deliveries. A PO for 1,200 units ships as three 400-unit loads. If the supplier bills the full order after the first truck, the match compares 1,200 billed against 400 received. The invoice is early; the goods are on the road.
• Unit-of-measure slips. The dock counts cases while the PO was written in eaches, or the reverse. The raw numbers disagree even though the physical quantities agree once converted.
• Receipt reversals. A mis-keyed receipt gets reversed – in SAP, a movement type 102 cancelling the original 101 – and re-entered later. An invoice matched inside that window sees nothing received at all.

In all four, the goods are fine and the invoice may well be accurate. The exception records a bookkeeping lag on the receiving side.

An agent works a quantity and receipt mismatch in a set order

Because the receipt is the weak document, an agent checks the receipt's story first and questions the invoice last. The order runs from the record most likely to explain the gap to the one least likely to:

1. Goods receipt history on the PO line. Every movement, including reversals, with timestamps and the user who posted each one. A 101 followed by a 102 nine minutes later says a keying error was corrected; a line with no movements two weeks after the promised delivery date says the posting never happened.
2. Packing slips and ASNs. An advance shipping notice (ASN) is the supplier's electronic notice of what shipped, when, and in what units. Together with the signed packing slip, it is evidence of the physical event that does not depend on the dock's data entry.
3. The supplier's partial-shipment pattern. Delivery history answers whether this supplier habitually splits POs across loads and bills per shipment. If the last six orders each arrived in three trucks, a 400-of-1,200 receipt with a full invoice predicts two loads in transit rather than a short shipment.
4. Over-delivery tolerances. Receiving policy usually permits some overage, say 5% on bulk materials, before a receipt needs buyer approval. The match tolerances and thresholds page covers how those bands are set; the agent checks whether the variance already sits inside one.

In practice the checks compound. Take an invoice from a packaging supplier billing 4,800 rolls of stretch film at $1.15 each, $5,520 in total. The PO line was written for 400 cases at $13.80 a case – also $5,520 – and the warehouse posted a receipt for 400 in the PO's unit. The match compares 4,800 billed against 400 received and flags a 4,400-unit over-billing on a delivery where every roll arrived. The agent reads the packing slip, finds "400 CS @ 12 EA/CS", converts the invoice line, confirms the extended values agree to the cent, and posts the match with the conversion documented in the resolution note. The same case in a manual queue tends to wait days for someone to phone the warehouse.

The cases that reach a person are those where the physical evidence genuinely conflicts: a supplier insisting a full load shipped while the ASN, the receipt history, and the signed delivery note all show 400 units. The agent's job then is to hand over the file with the receipt movements and delivery documents already assembled, so the dispute starts from evidence instead of from an empty hold code.

A service receipt is a sign-off on work nobody can count

For services there is no dock and nothing to put on a scale. The "receipt" is a service entry sheet in SAP, a timesheet, or a milestone acceptance signed by a project owner. The reliability problem gets sharper here, because the record now depends on a busy manager's attention: milestone sign-offs sit unactioned in an inbox for weeks, timesheets get approved in month-end batches, and a consulting invoice billed on completion routinely lands before anyone has confirmed the work. A quantity mismatch in this world means hours billed above hours approved, or a milestone invoiced before its acceptance was recorded. The agent's checking order keeps the same shape with different documents: entry-sheet and approval history first, then the statement of work for what the milestone requires, then the supplier's billing pattern on prior phases. The scarce ingredient shifts from a forklift driver's count to a project manager's signature, and chasing that signature with the evidence attached is most of the resolution.

Fragment builds AI agents that work quantity and receipt mismatches in this order – receipt history first, delivery documents second, supplier patterns third – inside the SAP or Ariba environment a company already runs, escalating only the genuine disputes. See how the workflows run or request a demo.