Inventory Discrepancy: Causes and How to Trace One

What an inventory discrepancy actually is

An inventory discrepancy is any difference between what a system records and what is physically present. That sounds obvious, and it is exactly where most investigations go wrong — because the word covers at least three different problems that need different evidence.

Quantity discrepancy: The item is in the right place, but the count is wrong. 480 eaches on the shelf, 960 in the system. This is the type that transaction replay solves, because a quantity in a system got there by arithmetic and the arithmetic can be re-run.
Location discrepancy: The total is right, the placement is wrong. The site holds what it should; location A-01-02 shows 240 and holds nothing, while A-03-07 holds 240 and shows nothing. Site-level accuracy reports will call this perfect. Every pick against it will short.
Status or value discrepancy: The quantity and place are right but the record describes it wrongly — available stock that is physically damaged, quarantined stock shown as sellable, or a quantity that is correct in the WMS and different in the ERP. Nothing is missing. The record is still not usable.

The important property they share: a discrepancy is evidence, not a diagnosis. It tells you that at some point the record and the world diverged. It does not tell you when, and it does not tell you why. Adjusting the number closes the observation and destroys the evidence, which is why sites that adjust quickly tend to keep finding the same discrepancy.

A WMS is a ledger. Every on-hand balance it shows is the sum of transactions posted against that item and location since the last reset. If the balance is wrong, then one of three things is true: a transaction posted a quantity that did not happen, a transaction that did happen never posted, or a transaction posted correctly but against the wrong key — wrong item, wrong location, wrong unit of measure. There is no fourth option, and that constraint is what makes the problem tractable.

A worked example: the receipt that posted twice

An inbound trailer delivers 30 cases of an item with a case pack of 24 eaches. The vendor sent an ASN, so the receipt posts automatically when the LPNs are scanned: 30 CS × 24 EA = 720 EA. Later the same day, a receiver working from the paper packing slip — because the ASN had not shown up in their queue view — keys the same delivery in manually against the same PO line.

Both receipts are individually correct. The system now believes it has 1,440 eaches and the rack holds 720.

PO 44871 · line 2 · reconciliation Illustrative arithmetic

Expected versus observed values for a duplicated purchase order receipt
Field	Expected	Observed	What it means
PO line quantity	30 CS	30 CS	The order itself is not the problem.
Item master case pack	24 EA / CS	24 EA / CS	Conversion is correct, so this is not a UOM failure.
Receipts against the line	1	2	The whole finding is in this row.
Eaches posted	720 EA	1,440 EA	30 × 24, counted twice.
Counted on hand	720 EA	720 EA	The floor was right the whole time.
Variance	0 EA	+720 EA	Exactly one receipt's worth. The number names its own cause.

Overstatement 720 EA · at a standard cost of $3.10/EA → $2,232 · on one line of one PO

Substitute your own standard cost; the point is the shape, not the dollar figure. Two things are worth noticing.

First, the variance is a clean multiple of the receipt quantity. A discrepancy of exactly 720 on an item whose case pack is 24 and whose delivery was 30 cases is not a counting error — 720 is 30 × 24, and nobody miscounts by precisely one delivery. Variances that land on a case pack, a pallet quantity or a full receipt are pointing directly at a transaction.

Second, a cycle count will not fix it. The count posts an adjustment of −720, the balance is briefly correct, and the next duplicated receipt recreates it. The adjustment reason code will say COUNT VAR, which is true and useless. Nothing in that record tells the next person that the ASN queue view is dropping receipts for this vendor.

Symptoms, and what each one narrows down

Discrepancy symptoms are diagnostic if you read them as a pattern rather than a list. Each of these narrows the search before you open a single transaction log.

Variance that is a clean multiple of case pack, pallet TI×HI or a full receipt. Points at a transaction-level event — a duplicate, a missed post, or a UOM conversion — not at counting.
Variance concentrated on a small set of items while most of the building counts clean. Points at item master or at a specific vendor, not at the process generally.
Negative on-hand after an ordinary pick. The system allowed more to be consumed than it recorded receiving. Almost always a missing or mis-keyed inbound leg upstream.
Picks shorting at locations the system shows as stocked. Either the stock is somewhere else (location discrepancy) or it never existed (see phantom inventory).
Replenishment tasks generated for locations that are physically full. The forward location's recorded quantity is below its minimum while its actual quantity is not — a decrement posted without a matching physical event.
The same item adjusted repeatedly in the same direction. The strongest single signal that you are looking at a process defect. One-off errors do not recur on a schedule.
Equal and opposite adjustments on two locations, days apart. A move that posted one leg. Net effect on site inventory is zero, which is why aggregate reporting never surfaces it.
WMS and ERP disagreeing on the same item at the same site, and staying disagreed. A timing difference closes on the next interface run. One that does not close is a dropped message.

Likely root causes

Ordered roughly by how often they turn out to be the explanation when the transaction history is actually replayed, rather than by how often they get blamed.

Unit-of-measure and case-pack conversion: A receipt entered in cases and posted in eaches, or converted with a case pack that no longer matches what the vendor ships — see unit-of-measure errors. This single category produces the largest absolute variances, because the error is multiplied by the pack quantity on every receipt until someone changes the item master.
Duplicate receipts: ASN plus manual entry, a re-scanned LPN, or an interface that replays a message after a timeout. One of several receiving error modes. Signature: variance equal to a whole receipt, and two receipt records against one PO line with timestamps minutes or hours apart.
Unpaired transaction legs: A move, replenishment or putaway where the decrement committed and the increment did not — a dropped RF session, a cancelled task confirmed halfway, an interrupted interleaving. Signature: two locations wrong by the same quantity in opposite directions.
Confirmation against the wrong key: The picker took stock from the bin next to the one the system decremented; the putaway went to a neighbouring slot and was confirmed by keying the task's destination rather than scanning the actual one. The quantity is right, the location is wrong, and site totals hide it completely.
Adjustments used instead of investigation: Not a cause of the first discrepancy, but the reason the second one is invisible. Read the other way round, the adjustment log is evidence. Each adjustment overwrites the evidence that would have identified the pattern. A site with a high adjustment rate and a generic reason-code distribution has usually been erasing its own audit trail for years.
Retroactive item-master edits: A case pack corrected today does not correct the receipts posted under the old value. Depending on the WMS, on-hand may be restated, left alone, or restated for some transaction types and not others. Any of the three can produce a discrepancy that has no matching transaction at all — which is why the item master change log belongs in the replay.
Integration timing and dropped messages: WMS and ERP run on different batch boundaries. A receipt posted after the last interface run of a period sits in different periods in the two systems, and then reconciles. A message that errored and was never requeued does not. Both look identical in a single period-end snapshot.
Counting against a stale snapshot: A count captured at 06:00 and posted at 14:00 in a location that moved stock at 09:00 will post a variance that never existed — and will create a real one. This is a manufactured discrepancy, and it is common enough that the gap between count time and post time is worth checking before anything else — see cycle count discrepancies.

How to trace one, step by step

This is transaction replay. It is arithmetic, it does not require access to a production system, and it works on an export. The discipline is in step one.

Step 01

Freeze, do not adjust

Put the location on hold if the WMS allows it. Record the item, location, LPN, system quantity, counted quantity and the timestamp of both. The moment you post an adjustment, the balance history stops being a record of what happened and starts being a record of what someone decided.

Step 02

Establish two endpoints you trust

You need a starting balance that was verified and an ending balance that was just counted. The best start point is usually the last cycle count that posted zero variance, or a receipt into an empty location. Without a trusted start, replay tells you the balance is wrong but not where it went wrong.

Step 03

Pull every transaction between them

Every type, in posting-timestamp order: receipts, putaways, moves, replenishments, picks, packs, shorts, returns, cycle counts, adjustments, status changes. The single most common mistake is filtering to the types that seem relevant, which excludes the type that caused it.

Step 04

Recompute the running balance yourself

Start at the trusted balance and apply each transaction's quantity in base UOM. Keep your own running total in a column beside the system's recorded balance. Do the conversion yourself rather than reading the posted each-quantity — a UOM error is invisible if you accept the system's own arithmetic.

Step 05

Find the first divergence

Scan down until your total and the system's part company. That row, or the one immediately before it, is the event. Everything after it inherits the error, which is why the final variance tells you the size of the problem but nothing about its origin.

Step 06

Classify the event

Quantity, unit of measure, location, duplication, timing, or absence. Each points at a different fix. A UOM error is item master. A duplicate is process or interface. An unpaired leg is transaction design or RF reliability. An absence means the work happened and the system was never told.

Step 07

Test whether it repeats

This is the step that converts a correction into a fix. Take the signature of the event and query the whole dataset for it. Same vendor? Same receiver? Same item class, UOM, zone, shift, RF device, interface? A defect that has happened once will happen again; a defect that has happened forty times is a process, and it is worth more than the variance that led you to it.

Step 08

Adjust last, and record the cause

Now post the correction, with a reason code that names the mechanism rather than the observation. DUP RECEIPT — PO 44871 is a record a future investigator can use. COUNT VAR is not.

The data and fields to inspect

Everything below is normally available as a flat export. If your WMS can produce these for a date range and an item list, a discrepancy can be traced without anyone touching the live system.

Item master — base UOM, UOM conversion table (EA/IN/CS/PL), case pack, TI and HI, catch-weight flag, lot and serial control, item status, and the change log with effective dates. The change log is the field most often missing from an export request and most often decisive.
PO and ASN lines — ordered UOM, ordered quantity, expected pack, ASN quantity, ASN receipt flag, vendor ID, and whether the line permits over-receipt.
Receipt transactions — transaction type, PO and line reference, quantity as entered, UOM as entered, converted base quantity, to-location, LPN, receiver ID, device ID, posting timestamp.
Transaction history — type, item, quantity, from-location, to-location, from-LPN, to-LPN, user, device, reference document, and both the transaction timestamp and the posting timestamp. When those two differ, the difference is often the finding.
Location inventory snapshot — location, item, LPN, quantity, UOM, status (available, hold, damaged, quarantine), allocated quantity, last count date, last movement date.
Location master — location type, pick or reserve, capacity, whether item mixing is permitted, whether LPN tracking is enforced.
Adjustment history — quantity, direction, reason code, free-text note, user, approver, timestamp. Pull the full reason-code distribution as well as the individual rows.
Cycle count history — count date, post date, counted quantity, system quantity at the moment of counting, blind-count flag, recount flag, tolerance applied, counter ID.
Interface and error logs — message ID, direction, document type, status, error text, retry count, and the batch window boundaries for the period.

Inventory discrepancy vs. shrink

These get used interchangeably in operations meetings, and the substitution is expensive.

A discrepancy is an observation: the record and the count disagree. Shrink is a conclusion: physical stock left the building without a corresponding transaction — theft, unrecorded damage, spoilage, mis-shipment. Every instance of shrink produces a discrepancy. Most discrepancies are not shrink.

The difference matters because the two have opposite remedies. Shrink is addressed with physical controls: cameras, cage stock, seal programmes, dock discipline, exit procedures. Data-origin discrepancies are addressed by fixing master data, transaction design and confirmation processes — and are completely immune to every physical control you could buy.

When a site books discrepancies to shrink by default, two things happen. The write-off absorbs a data problem into a loss account, where it stops being anyone's operational responsibility. And the underlying defect keeps running, so the shrink number stays stable and gets treated as a cost of doing business rather than a symptom. The test is simple and cheap: if a variance is a clean multiple of a pack quantity, or if the same item and quantity recur on a schedule, it is far more likely to be arithmetic than theft. Thieves do not steal in exact case-pack multiples on a six-week cycle.

The same caution applies in the other direction. Genuine physical loss classified as a data error sends investigators into transaction logs that are perfectly correct. Both mistakes come from skipping the replay — it is the replay that distinguishes them, because a real physical loss leaves a transaction history that reconciles all the way to the count.

The operational takeaway

A WMS balance is the sum of its transactions. That makes a discrepancy a solvable arithmetic problem rather than a mystery, and it means the useful output of an investigation is never the corrected number — it is the name of the transaction that broke, and the count of how many times it has broken before.

Two habits do most of the work. Adjust last, not first, because the adjustment destroys the evidence. And record the mechanism in the reason code, because a reason-code distribution is the cheapest diagnostic instrument in the building: if 80% of your adjustments say COUNT VAR, you do not have an inventory problem, you have no data about your inventory problem.

From here: phantom inventory covers the specific case where the stock never existed, inventory root cause analysis covers the method for proving a pattern rather than an instance, and WMS inventory accuracy covers how to measure whether any of it is improving.