Phantom Inventory in a WMS: Causes and Diagnosis

What phantom inventory is

Phantom inventory — also called ghost inventory — is a recorded quantity with no physical counterpart. The system shows it, planning trusts it, allocation commits it to orders, and there is nothing on the shelf behind it.

The word people reach for instead is missing, and it sends the investigation in the wrong direction. Missing implies the stock was there and left. Phantom stock never arrived in the quantity recorded. That single distinction changes what you look for: not a gap in physical security, but a transaction that posted a number the building never received.

It also explains the most frustrating property of phantom stock, which is that it survives counting. A cycle count corrects the balance today. If the mechanism that created it is a case pack in the item master that does not match what the vendor ships, the next receipt recreates it — same item, same direction, same approximate size. Sites in this position often conclude their counters are unreliable. The counters are usually the only part of the system telling the truth.

Phantom stock does not stay still

The second thing worth understanding is that phantom quantity is not a static error sitting in one bin. It is consumed like real stock. If a location shows 960 and holds 480, the first 480 eaches pick normally. The system then shows 480 remaining, which is above the replenishment minimum, so no replenishment triggers. The next picker arrives at an empty location and reports a short. The phantom has migrated from an overstatement into a service failure, and the two events look unrelated in the reports that record them.

A worked example: the case pack that changed

An item is set up with a case pack of 24 eaches per case. At some point the vendor re-packs the line — a common consequence of a packaging change, a private-label switch, or a plant transfer — and now ships 12 eaches per case. The purchase order, the ASN and the item master all still say 24.

A delivery of 40 cases arrives. The receiver scans 40 CS, which is exactly right. The WMS converts using the item master.

Receipt conversion · 40 CS Illustrative arithmetic

Item master case pack compared with the quantity actually delivered
Field	Item master says	Vendor actually shipped	What it means
Case pack	24 EA / CS	12 EA / CS	The only wrong field in the entire transaction.
Cases received	40 CS	40 CS	The receiver did nothing wrong.
Eaches posted	960 EA	—	40 × 24, computed from master data.
Eaches on the pallet	—	480 EA	40 × 12, the physical truth.
Phantom quantity	0 EA	+480 EA	Exactly half. The error is the ratio of the two pack values.

Phantom per delivery 480 EA · over 6 deliveries before anyone counts → 2,880 EA · from one unmaintained field

Three properties of this example are worth carrying into any real investigation.

The error scales with volume. Nothing about it is self-limiting. Every subsequent receipt of that item adds another 480, and a fast-moving line can accumulate a five-figure each-quantity before a count catches it.

The ratio is the fingerprint. Posted quantity is exactly double physical quantity, because 24 ÷ 12 = 2. When a variance is exactly 2×, 0.5×, 12× or 1/12 of what it should be, you are looking at a conversion, not a count. Whole-number ratios between system and physical are the single most reliable tell that phantom stock has a master-data origin.

Every individual actor behaved correctly. The vendor shipped what they said. The receiver scanned what arrived. The WMS applied its configured conversion faithfully. There is no one to retrain, which is precisely why phantom inventory survives so many accuracy initiatives aimed at people.

How it shows up on the floor

Phantom stock is almost never reported as phantom stock. It arrives as one of these, usually from a different department.

Repeated short picks at locations the system shows as stocked. The defining symptom. A one-off short is an event; the same location shorting monthly is a phantom being regenerated.
Negative on-hand after a normal pick. The consumption caught up with the overstatement and passed it. A negative balance is not a WMS glitch — it is proof that more was picked than was ever genuinely recorded as received.
Locations that never trigger replenishment and are always empty. The recorded balance stays above the minimum because part of it is fictional, so the replenishment rule never fires.
Available-to-promise consistently higher than what ships. Order promising is working from the same overstated balance that picking is about to fail against.
Cycle count variance for a given vendor or item class that is almost always negative. Directional bias in variance is a master-data signature. Random counting error is symmetrical; conversion error is not.
Back orders on items with healthy system on-hand. Two systems disagreeing about the same stock, one of which is right.
An item corrected down, then corrected down again weeks later by a similar amount. The adjustment treated the balance; the mechanism is still running.
Variances that are clean multiples or simple fractions of a pack quantity. 480 on a pack of 12, 960 on a pack of 24, half or double the expected figure.

How phantom inventory gets created

Every mechanism below produces a recorded increase that no physical stock corresponds to, or prevents a recorded decrease that physically happened.

Case pack and UOM conversion errors: The largest single source, and the one in the example above. Includes stale case packs, missing intermediate UOMs (an inner pack that the system does not model), and items where the ordering UOM and the stocking UOM were set up by different people at different times. Covered in depth in unit-of-measure errors.
Over-receipt against short shipments: A PO line for 40 cases where only 34 arrive, received in full because the receipt defaults to the ordered quantity and the tolerance permits it. Six cases of phantom, created at the moment of receipt, with a perfectly ordinary-looking receipt record — one of the receiving error modes.
Unpaired move legs: A replenishment or putaway where the increment posted and the decrement did not, or the task was confirmed to its planned destination while the stock went somewhere else. Creates phantom at one location and, usually, unrecorded stock at another.
Returns posted to sellable stock without putaway: An RMA is received into inventory at the point the credit is raised, but the physical unit sits on a returns bench for three weeks — or is damaged and never enters stock at all. The balance is available, allocatable and fictional for the whole period.
Production or kitting backflush: Where component consumption is derived from a finished-goods declaration rather than recorded directly, any difference between the bill of materials and what was physically consumed becomes a component balance error. Scrap not recorded at the line is phantom component stock by definition.
Replayed interface messages: A receipt message that times out, is retried, and posts twice. Distinguishable from a human duplicate by the timestamps — interface replays usually sit seconds or minutes apart and carry the same source message reference.
Adjustments that treat the number, not the mechanism: The reason phantom inventory is chronic rather than acute. Each correction resets the balance and leaves the generator running, so the site experiences a permanent low-grade accuracy problem rather than a single diagnosable fault.

How to prove it

The goal is not to correct a balance. It is to demonstrate that a specific transaction created stock that never existed, and then to show how many times that has happened.

Step 01

Count blind, and count now

Pick a location the system says holds stock and have it counted without the system quantity visible. A counter who can see the expected number is not producing independent evidence. Record location, LPN, item, system quantity, counted quantity and both timestamps.

Step 02

Check the ratio before anything else

Divide system quantity by counted quantity. If the result is a clean 2, 0.5, 12, 1/12, 24 or 1/24 — any number that looks like a pack relationship — go straight to the item master and the receipt history. You can usually confirm a conversion fault in under ten minutes and skip the full replay entirely.

Step 03

Compare three numbers, not two

For the receipt that filled this location: the quantity on the vendor packing slip, the quantity entered by the receiver, and the base quantity the system posted. Two comparisons. If slip and entry agree but the posted base quantity does not follow from them, the conversion is wrong. If slip and entry disagree, the receipt is wrong.

Step 04

Look for unpaired legs

If the receipt is clean, sort every transaction touching that LPN and location by timestamp and look for increments without matching decrements. A move is two rows. One row is a finding.

Step 05

Read the item master change log

Find out when the case pack, UOM conversion or base UOM last changed and who changed it. A conversion error that began on a specific date has an obvious boundary: receipts before it reconcile, receipts after it do not. That boundary is the strongest evidence you will get.

Step 06

Widen to the population

Take the signature — vendor, item class, UOM, receiving door, receiver, date range — and run it across every item that shares it. One item with a stale case pack is a correction. Forty items from the same vendor with stale case packs is a vendor master-data process that has not run since a catalogue change.

Step 07

Quantify both halves of the cost

Phantom eaches × standard cost gives the balance-sheet overstatement. The operational cost is separate and usually larger: short picks, emergency replenishments, expedited freight, back orders and the order lines that did not ship complete. Count both, and keep them clearly separated.

Step 08

Fix the generator, then the balance

Correct the master data or the process first. Adjust the quantity last, with a reason code naming the mechanism. Adjusting first guarantees you will be back — and it removes the evidence that would have let the next person recognise the pattern.

The data and fields to inspect

For phantom stock specifically, the conversion chain matters more than anything else. These are the fields that carry it.

Item master UOM structure — base UOM, every defined conversion (EA, inner, CS, PL), case pack, TI, HI, and whether the ordering UOM differs from the stocking UOM.
Item master change log — field changed, old value, new value, effective date, user. The date boundary is the evidence.
Receipt lines — quantity as entered, UOM as entered, converted base quantity, PO line, ASN reference, source message ID, receiver, device, timestamp. You need the entered quantity and the posted quantity as separate fields; a single "received quantity" column hides the entire class of fault.
ASN detail vs. packing slip — expected pack quantity, expected eaches, and what the paperwork physically said. Where the ASN is auto-received, the slip is often the only independent record.
PO receipt tolerance configuration — over-receipt percentage, auto-close rules, and whether short shipments require confirmation.
LPN and pallet history — every transaction against the licence plate, in order, so unpaired legs are visible as single rows.
Location inventory — location, item, LPN, quantity, status, allocated quantity, last count date, last movement date. A large recorded balance with an old last-movement date is a strong phantom candidate.
Short-pick and exception log — location, item, expected quantity, found quantity, picker, timestamp. This is the fastest route to a candidate list, and it is frequently never exported.
Adjustment history with reason codes — to establish whether this balance has been corrected before, and how often.
Return and RMA receipts — receipt timestamp, putaway timestamp, disposition. The gap between the first two is phantom availability.

Phantom inventory vs. shrink, and vs. negative inventory

Shrink is stock that existed and left without a transaction. Phantom inventory is stock that never existed and was recorded anyway. Both end with system quantity above physical quantity, which is why they are constantly confused — and they have nothing else in common.

Shrink responds to physical control: access restriction, cage stock, seal programmes, dock and exit discipline, cameras. Phantom stock is immune to all of it, because no physical event occurred. Conversely, phantom stock responds to master-data governance and transaction design, which do nothing whatsoever about theft. Classifying one as the other means spending the budget in the wrong building.

There is a practical test. Phantom stock created by conversion error is directional and proportional — variances cluster on one side, correlate with a vendor or item class, and sit in whole-number ratios to the expected quantity. Shrink is sporadic and value-weighted — it concentrates on small, portable, high-value items and does not respect pack quantities. A variance of exactly 480 on a pack of 12 is arithmetic. A variance of 3 on a high-value item is worth a different conversation.

Negative inventory is the symptom, not a third category

A negative on-hand balance is usually phantom inventory at the end of its life. The recorded overstatement was consumed by ordinary picking, consumption continued past zero, and the balance went below it. That makes negative balances valuable: they are a free, automatic, self-generating list of locations where something upstream posted a quantity that never arrived. A site that suppresses negative balances — by blocking them at transaction level or auto-adjusting them to zero overnight — has turned off its best phantom detector. The general discrepancy method applies from there.

The operational takeaway

Phantom inventory is a master-data and transaction-design problem wearing the costume of a counting problem. It is created by specific, identifiable events, it scales with receipt volume rather than with time, and it is completely invisible to the physical controls most sites reach for first.

The cheapest diagnostic in the building is the ratio test: divide the system quantity by the counted quantity and see whether the answer looks like a pack relationship. It costs nothing, takes seconds, and separates arithmetic from everything else before anyone opens a transaction log.

The second cheapest is the negative-balance report, provided nobody has turned it off. Everything after that is root cause analysis — proving the pattern, not the instance — and honest accuracy measurement to confirm it actually stopped.