12 Receiving Discrepancies Your AI Agent Must Flag

A pallet lands on your dock with 240 units listed on the packing slip. Your receiving clerk scans the carton, counts 234, and moves on because the truck behind it is already backing into the bay. The barcode read clean. The SKU matched.

Nobody catches the six missing units until a stockout three weeks later traces back to this one receipt.

That gap between “the scan worked” and “the data was right” is where most receiving discrepancies live. This piece breaks down the 12 receiving discrepancies we see most often, the exact validation rule that catches each one, and how to design the tolerance logic an AI receiving agent needs to run before a pallet ever reaches a shelf. We built ThickDot’s receiving agent after watching this same six-unit gap repeat across dozens of docks, so what follows comes from receipts we’ve actually reconciled, not a theoretical framework.

Why Barcode Scans Alone Don’t Catch Receiving Discrepancies

A barcode scan proves one thing: something passed under a reader. It doesn’t prove the label was printed correctly, that the item inside the box matches what the label claims, or that the quantity on the packing slip is the quantity that actually arrived. Scanning is necessary. It isn’t sufficient, and treating it as a complete accuracy solution is exactly where discrepancies slip through:

• A carton can carry a technically valid, scannable barcode that encodes the wrong SKU, because the supplier’s pack station mislabeled it, not because the scanner failed.
• A handwritten delivery note or a carbon-copy packing slip has no barcode to scan at all, so the entire “verification” step becomes a person eyeballing numbers under time pressure.
• A faded thermal-printed label that won’t scan gets manually keyed in by a rushed associate, which reintroduces the exact data-entry risk scanning was supposed to eliminate.

Manual counts and manual data entry are still responsible for the overwhelming majority of receiving errors. Hopstack’s warehouse receiving research puts that figure north of 70 percent, and that number holds because the moment a scan fails or a document has no barcode, the process reverts straight back to manual entry with none of the guardrails. Compare a scanner-based receiving process against an agent-based one and the real difference isn’t the hardware. It’s what happens to the data after the scan: whether anything actually checks it against the purchase order, or whether it just gets typed into a field and trusted.

The fix isn’t a better scanner. It’s a validation layer that runs on the data a scan or a photo capture produces, checking it against the documents that define what should have arrived, before that receipt is allowed to count as inventory.

What “Catching It Before Putaway” Actually Means

Putaway is the point of no return. Once a unit gets scanned into a storage location, most systems treat it as available-to-promise inventory: pickers can allocate it, replenishment can stop chasing it, and finance can start expecting the invoice to match. Unwinding a bad receipt after that point means a cycle count, a mis-pick investigation, or a customer order that can’t ship, weeks after the actual mistake happened at the dock.

A validation gate stops that by refusing to let inventory move past receiving until it clears a defined set of checks, or until someone explicitly resolves an exception and signs off on it. In practice, that means structuring receiving as a short sequence instead of one bulk step:

1. Capture the supplier’s paperwork, whatever form it arrives in (photo, PDF, email attachment, handwritten slip).
2. Extract structured line-item data: SKU, quantity, unit price, lot or batch, PO reference.
3. Match that data against the open PO and the ASN, line by line.
4. Check each variance against its tolerance rule.
5. Release matched lines to putaway automatically, and hold anything outside tolerance in an exception queue with the original document attached as proof.

That last step matters as much as the matching itself. Our own agent runs roughly a 92 percent auto-match rate across live receipts: most lines clear the gate on their own, and only genuine exceptions land in front of a person, routed the same way you’d route any other approval. The goal isn’t zero exceptions. It’s making sure the exceptions that do surface are the ones that actually deserve someone’s attention.

The Three Data Sources Every Validation Rule Should Cross-Check

Every check in this piece compares the same three sources, plus a fourth that most teams skip:

• The purchase order states what you agreed to buy: item, quantity, unit price, and delivery terms. It’s the authorization baseline.
• The packing slip or ASN (advance shipping notice) states what the supplier claims they shipped. It’s a claim, not a fact, and the two don’t always match even when the supplier is acting in good faith.
• The physical receipt, the count and inspection at your dock, is ground truth. It’s the only one of the three that reflects what’s actually sitting on the pallet.
• Vendor history provides context for whether a variance is routine or new, something none of the other three sources can tell you on their own.

A three-way match compares the purchase order, the packing slip or goods receipt, and the physical count of what arrived, confirming that what you agreed to buy, what the supplier says they shipped, and what your dock actually received all describe the same transaction before that receipt gets trusted. Most accounts payable teams already run this check before releasing payment. The problem is that by the time AP runs it, the goods have usually already been put away, which means the match catches billing errors well after the inventory error already happened. Moving the same comparison earlier, to the receiving dock instead of the AP desk, is what actually prevents the discrepancy instead of just documenting it afterward.

The 12 Most Common Receiving Discrepancies (and the Check That Catches Each One)

These 12 fall into four broad buckets, and it helps to know which one you’re dealing with before you look at the specific check:

• Quantity mismatches: short shipment, overage, duplicate receipt.
• Identity and label mismatches: wrong item, mislabeled cartons, unit of measure errors, lot or expiration mismatches, mixed-SKU pallets.
• Physical condition issues: visible damage, concealed damage.
• Commercial and documentation issues: price variance, missing PO reference.

Here’s the summary table, then the detail on the ones that need more nuance than a single row can hold.

1. Short Shipment (Under-Shipment)

The physical count comes in under both the ASN and the PO quantity. The check compares the counted quantity, captured at the line level, against the ASN’s stated quantity and the PO’s ordered quantity. A short-ship on a $2 fastener and a short-ship on a $600 line item shouldn’t trigger the same response: one is noise, the other is real dollar exposure even at a small unit count. Size the tolerance to the line’s dollar value, not just the percentage variance.

2. Overage (Over-Shipment)

More units arrive than the ASN or PO called for. Accepting an overage without a change order creates unplanned liability the moment invoice matching runs, and it can also mean a pallet meant for a different customer landed on your dock by mistake. The check compares received quantity against the greater of the ASN or PO quantity, and anything past a small tolerance should hold rather than get silently absorbed into stock.

3. Wrong Item or SKU Substitution

The item that physically arrived isn’t the item that was ordered, even though the paperwork looks plausible. This happens when a supplier’s pick error puts the wrong part in a labeled box. The check has to compare captured description or spec data, not just the SKU code, against the PO’s item master record, because a swapped item can carry a barcode that scans as technically valid from the supplier’s own system.

4. Mislabeled Cartons or Pallets

The label itself carries the wrong SKU, PO number, or quantity, or is missing a required field like lot or expiration date. This is distinct from a wrong item: the physical goods might be correct, but the label lies about them, or vice versa. Label content errors are consistently among the top causes of shipment rejections and compliance chargebacks in retail and 3PL receiving.

The check validates label field content against the ASN and PO before acceptance, not just whether the barcode scans, since a barcode can scan cleanly while encoding the wrong data entirely. This one should always route to a human, because it usually signals a process problem at the supplier’s pack station that will repeat on the next shipment.

5. Visible Transit Damage

Damage evident on inspection, crushed corners, torn shrink wrap, wet cartons, needs a photo requirement, not just a data field. The rule: any line marked damaged requires a timestamped photo attached before it can be accepted, and the exception ties back to a bill-of-lading notation. Skipping this step at the dock forfeits most carriers’ claim windows, which are time-boxed and require documentation at the point of delivery.

6. Concealed or Latent Damage

Damage discovered only after unboxing, sometimes after the unit is already in a storage location. No document comparison catches this one on its own. The rule that does is procedural: a concealed-damage report should trigger a lookback across the same lot or pallet ID, holding any other units from that same source for inspection instead of assuming the rest are fine. Cross-reference by lot and pallet, not just SKU.

7. Price Variance vs. PO

The unit price implied by the packing slip or invoice differs from the PO’s agreed price. This is the classic three-way match check, and most organizations set the tolerance around 2 percent to let rounding and minor freight allocation pass without a human touching every line. That number should tighten for contracted, strategic spend and loosen for one-off, low-value purchases.

8. Missing or Invalid PO Reference

The shipment arrives with no PO number, or references a PO that’s already closed or doesn’t exist in the ERP. Nothing downstream can match correctly until this resolves, so the check has to run before line-level matching even starts: confirm the PO reference points to a genuinely open PO. Letting staff free-text a placeholder just to keep the shipment moving is exactly how ghost inventory gets created.

9. Unit of Measure Mismatch

The PO is written in cases, the packing slip lists eaches, and “40” means two very different quantities depending on which document you trust. The check normalizes UOM before comparing quantities at all, and flags any mismatch between the ASN’s UOM and the PO’s UOM rather than letting a conversion happen silently. Counting at the wrong level (case vs. each vs. pallet) is one of the easiest receiving mistakes to make and one of the hardest to spot after the fact.

10. Lot, Batch, or Expiration Date Mismatch

The lot number or expiration date on the physical item doesn’t match what the ASN declared. This matters most in food, pharmaceutical, and other regulated goods, where GS1 application identifiers carry batch and expiry data specifically so it can be checked at the point of receipt. Any mismatch here should hold without exception, given what’s at stake for recall traceability if it turns out to be wrong.

11. Mixed-SKU or Commingled Pallet

A pallet contains more than one SKU without proper segregation, something that often isn’t caught until a putaway scan flags an unexpected item count. The check flags any pallet where the physical item count doesn’t match a single-SKU expectation set by the ASN. Commingled pallets slow putaway, complicate cycle counts later, and are a common source of retailer non-compliance chargebacks.

12. Duplicate Shipment or Duplicate Receipt

The same PO gets receipted twice, whether from a system glitch, a second truck carrying a split shipment, or someone re-scanning an already-processed pallet. The check compares the new receipt against the cumulative quantity already received against that PO or ASN reference, and flags anything that would push the total past the PO’s ordered quantity as a possible duplicate rather than a fresh overage.

How to Set Tolerance Thresholds That Don’t Cry Wolf

A single blanket tolerance percentage, applied to everything, fails in both directions. Set it too tight and your team drowns in flags for penny-level rounding differences on cheap commodity items. Set it too loose and a real shortage on a high-value line slides through because it happened to fall under the percentage cutoff.

Well-designed exception rules matter more than most teams assume: top-performing accounts payable teams run exception rates around 9 percent, while less disciplined ones sit closer to 22 percent, according to Ardent Partners’ 2025 procurement benchmarks. That gap is a rules-design problem, not a staffing problem, and the same logic applies to receiving.

A tolerance framework needs three tiers, sized by risk rather than one flat number:

• Auto-clear: variance is small and the item is low-risk (commodity value, non-regulated, single-unit swings don’t move the needle). Clears automatically, no human touches it.
• Soft flag: variance sits outside tolerance, but dollar exposure or compliance risk is limited. Routes to a review queue, but doesn’t block putaway of the unaffected lines on the same receipt.
• Hard hold: any documentation-type error (wrong PO reference, label mismatch, lot or expiry mismatch) or any variance on a high-value or regulated item, regardless of the percentage. Always blocks, every time.

What decides which tier a given line falls into isn’t the variance percentage alone. It’s a combination of unit cost, regulatory classification, whether the vendor is single-sourced, and how much a chargeback or a stockout on that specific item would actually cost you. A 2 percent price variance on a strategic contract deserves more scrutiny than the same 2 percent on a one-off spot buy, even though the number looks identical on a report.

Teaching the Agent What “Normal” Looks Like Per Vendor

A static tolerance table treats every vendor the same, and that’s a mistake. Some suppliers reliably ship 2 to 3 percent under on high-friction-count items like fasteners, for reasons that have nothing to do with fraud or negligence (packaging conventions, counting methods at their end). Flagging that same vendor every single time for a pattern you already know about wastes review time on noise.

The fix is a rolling baseline, built per vendor and per vendor-SKU pair, not a single fixed number:

• Log every resolved exception with its outcome: confirmed shortage, paperwork error, wrong carrier count, or something else.
• Track the discrepancy rate over time for each vendor-SKU combination, not just the vendor overall.
• Recompute the baseline periodically (monthly, or after a set number of receipts) so the tolerance band drifts with reality instead of sitting on a number someone typed into a spreadsheet a year ago.
• Flag deviation from that vendor’s own baseline, not just deviation from the PO, so a supplier who normally runs 3 percent short and suddenly ships 15 percent short gets caught, even though a static 10 percent tolerance would have missed it.

This is the same principle behind supplier scorecards and anomaly detection in procurement more broadly: a number that looks fine against a fixed threshold can still be a real warning sign against that specific supplier’s own history. The difference at the receiving dock is that this baseline gets built from physical count data, not just invoice and delivery-date data, which makes it a more direct signal of what’s actually happening at the point of entry.

Where This Logic Belongs: AI Extraction vs. Deterministic Rules

The obvious objection: why not just hardcode all of this into the WMS or ERP’s existing three-way match settings? Most ERPs already support tolerance percentages and purchase order matching rules. Bolting an AI agent on top can look like solving a problem you already had a tool for.

The gap is upstream of the matching logic. An ERP’s matching engine assumes it already has clean, structured data to compare: a quantity field, a price field, a PO number. It has no way to read a photo of a handwritten delivery note, a supplier’s inconsistently formatted PDF packing slip, or an email attachment and turn that into the structured fields a matching engine needs.

That extraction step, going from messy paperwork to structured data, is where document understanding earns its place. The matching and tolerance decision that happens after extraction should stay deterministic and auditable: fixed rules a compliance team can point to and explain, not a model’s best guess with no clear reasoning trail.

Our own agent splits the work exactly this way: a vision layer reads whatever paperwork shows up (photo, scan, PDF, handwritten note), a rules-based matching layer checks it against the PO, ASN, tax, and totals, and a writeback layer posts the result into your ERP with the original document and a full audit trail attached. That structure holds up because every “why did this clear” question has a traceable answer.

One honest limit worth naming: an agent’s match quality is capped by how good your PO data already is. If purchase orders get entered late, with vague item descriptions, or without complete line-item detail, no amount of AI on the receiving side produces a clean match, because there’s nothing accurate to match against. This works alongside decent PO discipline upstream. It doesn’t replace it.

Frequently Asked Questions

Catch It at the Dock, Not at the Cycle Count

Every one of these 12 receiving discrepancies is catchable at the point of receipt, before stock moves anywhere, if the validation rules actually cross-check the PO, the packing slip, and the vendor’s own history instead of treating a scan as proof. A fulfillment error that isn’t caught here typically costs somewhere between $35 and $50 to unwind once it reaches picking or a customer order, and that’s before you count the time your team spends investigating what went wrong three weeks after the fact, on top of what manual receiving already costs your production line day to day.

Three places to start:

1. Pull your last 90 days of receiving discrepancies and bucket them against these 12 types to see where your actual exposure sits. Most warehouses find it’s concentrated in three or four of them, not spread evenly.
2. Build a three-tier tolerance table (auto-clear, soft flag, hard hold) sized to item risk instead of one blanket percentage.
3. Put a real gate between receiving and putaway so nothing reaches a pickable location until it clears validation or someone resolves and logs the exception.

Curious how many of these 12 are already slipping through your dock this month? Run a real packing slip through ThickDot and see which lines clear automatically and which ones it holds.