Warehouse Receiving Errors: PO, ASN and Receipts

What counts as a receiving error

Receiving is where inventory enters the record, which makes it the single highest-leverage point in the building for data integrity. Everything downstream — putaway, replenishment, allocation, picking, counting, valuation — inherits whatever receiving posted. An error introduced here is not one error; it is the starting balance for every subsequent transaction on that stock.

The useful framing is that a delivery produces four separate quantities, and most sites only ever compare two of them.

1 · Ordered: What the purchase order line says, in the ordering unit of measure. A commercial commitment, not an observation.
2 · Advised: What the ASN says the vendor actually shipped, usually with pack detail and licence plates. Also not an observation — it is the vendor's claim, generated at their end, and it can be wrong or stale.
3 · Delivered: What physically came off the trailer. The only genuine observation in the set, and the one most likely to be missing from the data entirely, because where receiving is driven by ASN scanning, nobody records an independent count.
4 · Posted: What the WMS wrote to a balance, in base units, after conversion. This is the number every downstream process believes.

Three gaps sit between those four numbers, and each gap names a different class of problem with a different owner. Ordered against advised is a supply question. Advised against delivered is a vendor accuracy question. Delivered against posted is the receiving error — the only one of the three the warehouse fully controls, and the one most often skipped because it requires an independent count that ASN-driven receiving is specifically designed to avoid.

A worked example: the short delivery that posted in full

A purchase order line calls for 60 cases of an item with a case pack of 18 eaches. The vendor sends an ASN for 60 cases. The trailer arrives with 54 cases — six short, for an ordinary reason the vendor never notified.

Receiving is ASN-driven. The receiver scans the licence plates, the system matches the ASN, the PO line is within its over/under tolerance, and the line auto-closes at the advised quantity.

PO 51204 · line 1 · four-quantity reconciliation Illustrative arithmetic

Ordered, advised, delivered and posted quantities for one purchase order line
Quantity	Cases	Eaches	Source	Gap it reveals
Ordered	60 CS	1,080	PO line	—
Advised	60 CS	1,080	ASN	Ordered = advised. No short-ship notice was sent.
Delivered	54 CS	972	Physical count	Advised − delivered = 6 CS. A vendor accuracy issue.
Posted	60 CS	1,080	WMS receipt	Delivered − posted = 6 CS. This is the receiving error.
Phantom created	—	+108	—	6 CS × 18 EA, on the books from the moment of receipt.

Two separate faults on one line vendor short-ships 6 CS · and receiving posts them anyway → 108 EA phantom · only the second is the warehouse's to fix

Two independent things went wrong and they need to be counted separately. The vendor shipped short without advising — a supplier performance matter, resolved commercially. Receiving posted 60 cases when 54 arrived — a control failure inside the four walls, and the only one that put 108 phantom eaches into the balance.

Note how little there is to see. The receipt record looks entirely normal: correct PO, correct item, correct unit, quantity matching the ASN, within tolerance, auto-closed. Nothing is flagged, no exception is raised, and no one is asked a question. The fault is visible only as the absence of a fourth number — an independent delivered count that was never captured, because the process was designed on the assumption that the ASN is true.

How it surfaces weeks later, somewhere else

This is the part that makes receiving errors so persistently mis-attributed. Follow the 108 phantom eaches forward.

The stock is put away into reserve. The system believes reserve holds 1,080 EA — two pallets of 540 (30 CS × 18 each). Physically, reserve holds 972 EA: one full pallet of 540 and one partial of 432.

The forward pick location runs between a minimum of 200 and a maximum of 900 eaches, replenished a pallet at a time. The first replenishment task requests 540 from reserve, finds 540, and completes normally. Weeks later the second task requests 540 and finds 432.

At that point one of two things happens, and neither of them names receiving.

The operator confirms the task short. The exception is logged against replenishment, on a date five weeks after the receipt, in a different zone, by a different person. The variance is 108 EA — which nobody connects to a PO line closed over a month ago.
The operator confirms the task in full because the system said 540 and confirming by exception is slower. The phantom simply moves from reserve to the forward location, and re-emerges later still as a short pick — now attributed to picking.

Either way the error is recorded against the process that found it rather than the process that made it. This is the general rule for receiving defects: they surface far from the dock, late, and under someone else's name. A site that analyses exceptions by the process that reported them will conclude it has a replenishment problem and a picking problem, and will invest in both, and neither will improve — because the generator is a receiving control that was never exercised.

The practical consequence for investigation: when a replenishment or pick exception is a clean pack multiple, check the receipt history of that item before accepting the department it was logged against. The same reasoning applies in reverse to phantom stock, which is very often receiving-origin, and it is why signature testing across the population matters more than investigating the instance in front of you.

Symptoms and signals

Variances that are clean case or pallet multiples on items received recently. The strongest single indicator of receiving origin.
Adjustments clustered within a few weeks of a receipt date on the item concerned. Time-to-surface is short for fast movers and long for slow ones, which is itself diagnostic.
PO lines auto-closing at exactly the ordered quantity, consistently. Real deliveries vary. A receipt history in which posted always equals ordered describes a control that is not measuring anything.
Two receipt records against one PO line, minutes or hours apart. Duplicate — ASN plus manual, or an interface retry.
Receipts posted long after the delivery timestamp. The gap between physical arrival and posting is where duplicates, omissions and period-end misallocation live.
Replenishment or pick exceptions concentrated on one vendor. Vendors do not touch your forward locations; if their items short more than others, the common factor is how their deliveries are received.
Putaway to fewer or more locations than the delivery physically needed. The system sized the work from a quantity that does not match the trailer.
Receiving exceptions that fall to zero when a particular ASN path is used. Fewer exceptions is not always better; it can mean the check has been bypassed rather than passed.
Negative on-hand on recently received items. Consumption has already overtaken an overstated receipt.

The error modes

Each of these has a distinct signature in the data, which is what makes a receipt population sortable rather than anecdotal.

Over-receipt: Posted exceeds delivered. Usually a tolerance setting permitting auto-close at the ordered or advised quantity. Signature: posted equals ordered exactly, on a line where the physical count differs; creates phantom immediately.
Short receipt: Posted is less than delivered — stock is in the building and not on the books. Signature: favourable count variances weeks later, on a pack multiple, and unrecorded stock found in reserve. Quieter than over-receipt and therefore longer-lived.
Duplicate receipt: The same delivery posted twice — ASN plus manual entry, a re-scanned licence plate, or an interface message replayed after a timeout. Signature: two receipt records against one PO line with close timestamps; variance equal to a whole receipt. Interface replays share a source message reference; human duplicates do not.
Wrong unit of measure: Quantity right, unit wrong — cases keyed as eaches or the reverse. Signature: the variance is a clean factor rather than an amount. Distinguishing this from a master-data fault is the subject of unit-of-measure errors, and the two are routinely confused.
Wrong item: Received against the wrong line of a multi-line PO, or against a similar item number. Signature: two items wrong by the same quantity in opposite directions, usually adjacent in the item file or on the same PO. Net site inventory is unaffected, so aggregate reporting never shows it.
Wrong location or licence plate: Quantity and item right, destination wrong. Signature: stock physically present in a location the system shows as empty, and vice versa. Site totals are correct; every pick against the affected location fails.
Timing and cut-off: Receipt posted after an interface batch boundary or a period close, landing in different periods in the WMS and the ERP. Signature: a difference that closes on the next interface run. Genuinely not an error — distinguishing it from one that never closes is the core of inventory reconciliation.
Blind trust in the ASN: Not an error mode so much as the condition that permits several of the above. Where receiving is fully ASN-driven with no independent count, the delivered quantity is never observed, and the delivered-against-posted gap is structurally unmeasurable.

How to diagnose it

Step 01

Rebuild all four quantities for the line

Ordered, advised, delivered, posted — in both the entered unit and base units. Where the delivered figure does not exist, record that as the finding rather than substituting the ASN for it. An absent independent count is the most common single reason a receiving error was possible.

Step 02

Locate the gap, then name the class

Ordered versus advised is supply. Advised versus delivered is vendor accuracy. Delivered versus posted is yours. Naming which of the three you are in before investigating prevents the most common wasted effort — a warehouse team investigating a vendor's shipping error.

Step 03

Test amount against factor

Divide posted by delivered. A clean ratio means a unit-of-measure fault; an arbitrary difference means a counting or entry fault. This single division routes the investigation down two entirely different paths and takes seconds.

Step 04

Count the receipts against the line

More than one is a duplicate until proven otherwise. Compare the source message references: identical references mean an interface replay, different references mean two separate human entries. The remedies are completely different.

Step 05

Read the two timestamps

Delivery time and posting time. A large gap is where duplicates and omissions are created, and it decides whether a period-end difference is a timing artefact or a real loss. Batch window boundaries for the period belong in the same view.

Step 06

Check the tolerance configuration

Over-receipt percentage, under-receipt tolerance, auto-close rules, and whether a short delivery requires a confirmation. A tolerance wide enough to swallow a pallet is a configuration decision that will keep producing this defect regardless of who is on the dock.

Step 07

Follow it forward, not just backward

Trace the received stock through putaway, replenishment and picking, and look for the exception that the error eventually produced. This is what connects a dock control to a pick-face symptom, and it is usually the evidence that makes the finding credible to the people who have been absorbing the consequences.

Step 08

Group the whole period by gap type

Run the four-quantity comparison across every line received in the period, classify each gap, and count by vendor, receiver, device, door, shift and receiving path. One over-receipt is an event. Two hundred over-receipts sharing a tolerance setting is a configuration finding with a number attached.

Data and fields to inspect

PO header and lines — vendor, ordered quantity, ordering UOM, expected pack, line status, over/under tolerance, auto-close rule, expected delivery date.
ASN header and detail — advised quantity, pack structure, licence plates, lot and serial where carried, ASN receipt timestamp, and whether the ASN auto-receives.
Independent delivered count — where it exists. Its absence is a finding in itself and should be reported as one.
Receipt transactions — quantity as entered, UOM as entered and converted base quantity as three separate fields, PO line reference, ASN reference, source message ID, to-location, LPN, receiver ID, device ID, delivery timestamp and posting timestamp.
Item master — base UOM, full conversion chain, case pack, inner pack, TI and HI, and the change log with effective dates.
Putaway transactions — planned destination against confirmed destination, LPN, timestamps.
Receiving exception log — short-ship flags, over-receipt overrides, forced confirmations, supervisor approvals, and who applied them.
Vendor master — to group findings by supplier and separate vendor performance from receiving control.
Interface and error logs — message ID, direction, status, error text, retry count, batch window boundaries. Duplicates and replays are indistinguishable without these.
Downstream transactions for received LPNs — putaway, replenishment, picks and adjustments, so the error can be followed forward to the exception it eventually caused.

Receiving error vs. vendor error

The worked example contains one of each, and almost every site reports both as "a vendor issue".

A vendor error is a difference between what was advised and what arrived. The supplier shipped 54 cases against an ASN for 60 and did not notify. That is a commercial matter: supplier scorecards, claims, chargebacks, corrective action with the vendor. The warehouse cannot prevent it.

A receiving error is a difference between what arrived and what was recorded. The dock posted 60 when 54 were physically present. That is entirely within the four walls, it is what created the 108 phantom eaches, and it would have occurred identically had the vendor short-shipped for the most legitimate reason in the world.

The distinction matters because the two have unrelated remedies and only one of them is actionable this week. Booking the whole thing to the vendor produces a supplier conversation and leaves the receiving control exactly as it was — so the next short delivery from any supplier, for any reason, will post in full again. Meanwhile the phantom stock has already been attributed to replenishment, three zones away, five weeks later.

There is a clean test. Ask whether the error would still have happened if the vendor had done everything correctly. A tolerance that auto-closes a line at the advised quantity will post a phantom the first time any delivery is short, regardless of cause. That makes it a receiving control finding, and the vendor's conduct is a separate row in a separate report.

Both are worth measuring. The failure is collapsing them into one number, because the resulting figure cannot tell you whether to call the supplier or change a configuration setting.

The operational takeaway

Receiving is the highest-leverage data integrity control in a warehouse, and the four-quantity comparison is the cheapest way to exercise it. Ordered, advised, delivered, posted. Most sites hold three of those and never capture the fourth, which is precisely why the gap they most need to see is the one they cannot measure.

Two rules pay for themselves. Divide before you investigate — posted over delivered, a clean factor or an arbitrary amount — because that single division sends you to the item master or to the dock, and they are different investigations. And never accept the department an exception was logged against when the quantity is a pack multiple: receiving errors surface late, far away, and under another process's name.

From here: unit-of-measure errors covers the factor case, phantom inventory covers what over-receipts become, and the general discrepancy method covers replaying a specific balance from a trusted starting point.