Eight causes of stock discrepancies.

1. Put away without scan confirmation

What it looks like: a pallet physically sitting one bay, one aisle, or one zone away from the location the WMS holds for it. In the data, this surfaces as found pallet in wrong location, the most common single discrepancy type on most sites. What fixes it: enforcing scan confirmation at the point of put away closes the gap at source, though it slows the exact moment most sites are trying to move fastest. Where enforcement is not realistic on every put away, frequent counting catches the drift within days rather than months, which is what continuous cycle counting is for.

2. Returns re-shelved outside the normal process

What it looks like: stock that re-entered the building through a different door, physically and procedurally, to the stock that left it. A returned pallet parked wherever there is space, rather than put away through the normal receiving flow, produces the same found pallet in wrong location pattern as cause one, but concentrated around returns processing rather than spread evenly. What fixes it: routing returns through the same put away discipline as inbound stock, or at minimum flagging returns zones for more frequent counting, since they generate a disproportionate share of location drift for their size.

3. Receiving booked at aggregate level, not pallet level

What it looks like: real, physical stock sitting on a shelf that the WMS has no record of at all, because it was booked in as an order quantity rather than as individual pallets against individual locations. This is found pallet not present in WMS, and it is a receiving process gap, not a counting error. What fixes it: pallet level scanning at goods-in, so every unit that physically enters the building gets its own location record rather than being absorbed into a single order line.

4. Cross-docked or transferred stock arriving ahead of its paperwork

What it looks like: a pallet transferred between sites, or moved through a cross-dock, that physically arrives before the transaction confirming it has caught up. Until the paperwork lands, the receiving site's system does not know the pallet exists, which is another route to found pallet not present in WMS. What fixes it: tightening the sequence so the system transaction is triggered by the physical movement rather than following it, and in the meantime, a count that registers what is actually on the shelf regardless of transaction status catches it without waiting for the paperwork to arrive.

5. Picking or shipment transaction lag

What it looks like: the system still holds a pallet against a location that has physically been cleared, because the pick or shipment transaction was recorded ahead of, or without, the physical removal actually completing as expected. A count run against that location finds nothing there, reported as empty location where pallet expected. What fixes it: confirming shipment at the point stock actually leaves the building rather than at the point it is scheduled to, and counting the zones with the fastest stock turnover most often, since transaction lag compounds fastest where movement is heaviest.

6. Damage and shrinkage handled informally

What it looks like: stock removed from the shelf for a real reason, damage, spoilage or loss, without a matching system adjustment. The system keeps expecting a pallet that is simply gone, which also shows up as empty location where pallet expected, but for a different underlying reason to cause five. What fixes it: a hard rule that any physical removal, whatever the reason, gets a system adjustment at the same time, not logged later from memory. Frequent counting also matters here, because it is the mechanism that actually surfaces informally removed stock in the first place.

7. Phantom pallets created by receiving errors

What it looks like: a system record for a pallet that was never physically put away at the location the record names, usually from a duplicate scan, a data entry error, or a receiving quantity booked twice. No count will ever find this pallet, because it does not exist where the system thinks it does, which is expected pallet missing in recording. What fixes it: this cause is rarely caught by counting alone, because the pallet genuinely is not anywhere to be found. What resolves it is investigating the receiving transaction that created the record and correcting it at source, which is a job the recording behind a discrepancy line makes easier, since you can at least confirm the location genuinely never held it.

8. Master data and location code errors

What it looks like: a location code that is duplicated, merged, or still live in the WMS after being decommissioned in the racking. Stock gets logically assigned to a location that cannot physically hold it, which produces a persistent expected pallet missing in recording line that no amount of searching will ever resolve, because the fault is in the data model, not the warehouse. What fixes it: a location code audit, comparing the racking as it physically exists against every code the WMS still considers active. This is cheap relative to the accuracy gain it produces, though it is a one-off correction rather than an ongoing control, so it needs repeating whenever the racking itself changes.

Most sites carry a mix of all eight at once, which is why a single stocktake usually finds more discrepancies than anyone expects on the first pass. The procedure for running that first count properly, including how to zone it and where to set recount tolerance, is in how to run a warehouse stocktake. How often should you cycle count covers frequency, the inventory accuracy guide covers how accuracy is measured against the four discrepancy types, and the six jobs one pass answers covers the automated count itself.