A few months after go-live, the same conversation turns up at most sites. A picker walks to a bin the system says holds forty cartons and finds none. Someone raises a count, the count posts a difference, the number is right again, and everyone gets on with the shift. Nobody asks how the stock came to be missing in the first place. That question is the heart of the SAP EWM health check and optimisation work, because a count that quietly repairs the record also hides the fault that broke it.
Stock variances are not random. In a live EWM warehouse they come from a short list of causes, and each leaves a recognisable mark on the floor. It is the same drift we describe in system versus reality, seen through the inventory record instead of the scanner.
The usual causes, and the floor tell for each.
None of these is exotic. Most sites have several running at once, which is why a single fix rarely moves the number.
Tasks confirmed without the move, or moved without confirming.
EWM changes the stock record when a warehouse task is confirmed. If an operator confirms a task before the pallet has gone anywhere, to clear the queue or because the scanner is slow, the system holds stock in a place it is not. If a pallet is moved and the task is never confirmed, the system still shows it at the source. The tell: tasks confirmed in bursts, a cluster of identical timestamps, or open tasks for work everyone remembers finishing.
Put-away to a bin other than the proposed one.
The system proposes a bin. The aisle is blocked or the bin is occupied, so the operator puts the pallet in the next one along. When the bin verification field is not checked at the destination, the system never learns the pallet went somewhere else. The tell: a bin that looks full on the screen and empty on the rack, and a nearby bin holding stock nobody can explain.
The wrong batch or handling unit.
A picker takes the pallet in front of them, not the one the task named, because the labels look alike or the right one is behind three others. If the scan accepts it, the record moves a pallet that is still on the rack and leaves the other one missing. The tell: a pick face with two pallets of the same product and different batches, and a count difference that nets to nothing at product level but not at batch level.
Handling units packed or nested differently from the system.
Handling units are central to EWM. When a pallet is rebuilt, a layer is split off, or cartons are decanted without the handling unit being updated, the physical pallet and the one in the system have stopped matching. The tell: pallets with labels that no longer describe what is on them, and half pallets carrying a full pallet's label.
Returns and damages parked outside the process.
A returned pallet sits by the dock while someone decides what to do with it. A damaged carton goes to a corner. Neither is on a system bin, and neither is in the right status. The tell: a damaged goods cage nobody counts, and floor space holding stock that has no location in the system.
Stock moved to make room.
At peak, a forklift driver clears a staging area by moving pallets to wherever there is space. It is a sensible local call, and it leaves the record behind the floor. The tell: pallets in aisles that are not storage, and stock standing in a bin type it was never meant for.
Wrong units of measure or packaging data.
If the system believes a carton holds twelve and it holds ten, every receipt and every pick is wrong by a small amount that compounds. This is master data rather than behaviour, and it is the cause most often blamed on operators. Our note on master data covers where those records come from. The tell: the same product shows a variance every time it is counted, always in the same direction.
Posting timing misunderstood at month end.
EWM holds the warehouse stock. Inventory management holds the financial stock. They are linked by postings, and depending on how the process is designed, a physical move and the posting that updates the financial record can happen at different moments. Stock that has left the warehouse can still be sitting in a posting that has not completed when the month closes. The tell: a variance that appears on the last day of the period and clears itself in the first days of the next.
What counting does, and what it does not.
EWM has several physical inventory procedures: ad hoc counts, cycle counting, a low stock check, and put-away inventory, where a bin is counted at the moment it is about to receive a pallet. They are good tools. Used as a measurement, they tell you where the record and the floor disagree, how often, and in which areas.
Used as a cleaning tool, they do the opposite. The count finds a difference, the difference is posted, the record is correct for the moment, and the cause carries on. The next count finds the same thing again. A site can run cycle counting for years, post differences every week, and be no closer to knowing why the stock keeps going missing.
The same applies to the step after the count. In EWM a difference can be analysed before it is posted, and when it is posted it flows through to inventory management. If that step is a rubber stamp, the write-off goes through without a reason against it. The difference analyser exists so that someone can look at a variance and ask what happened. It is only useful if someone does.
Two views of the same variance.
Finance sees an inventory write-off. It appears on a report, it has a value, and it is dealt with at month end. The floor sees something different: operators walking to bins that are empty, searching for stock that is somewhere else, and taking pallets down to check what is underneath. The write-off is the small, visible cost. The extra walking and the lost trust in the record are the large, invisible one.
Neither side has the full picture, which is why the problem persists. Finance cannot see the cause on a ledger, and the floor cannot see the value in a pallet of aisle time. Putting both in one conversation, with a variance in front of them, is often the first useful thing that happens.
A count that fixes the number without finding the cause is a recurring cost with a tidy report on top.
What a stock accuracy fix looks like.
It starts with not changing anything. For a few weeks, every variance gets classified by cause, using the list above as a starting set. Someone who knows the floor looks at each difference the count produces and asks which of the causes it matches, and the answer goes into a simple log with the area, the shift and the product beside it.
After a few weeks the log shows a pattern. It might be that most variances come from one aisle, or one shift, or one product family, or one step in one process. That is the thing to fix, and the fix is usually small: a verification step reinstated at one destination, a packaging specification corrected, a returns bin created and enforced, a rule about moving stock at peak. Fixing the cause once removes the variance at its source, where counting it again and again never does.
Resist the urge to change counting frequency, add another count type or tighten tolerances before the classification is done. Those move the cost around without telling you what is wrong. If the classification points at exceptions the floor avoids using, our note on the exceptions the floor avoids is the next step, and if scanning itself is failing, when the floor cannot scan comes first.
How Luminar approaches stock accuracy.
We are independent and we do not sell the build, so the answer is whatever the floor shows. A senior consultant spends a day on your site, walks the put-away, pick and returns points where variances start, and sits with your inventory controller and finance lead over the difference history. You get a plain-language memo in five working days that sorts your variances by cause and names the first fixes. No proposal attached. If you want to start from the floor, that is the Floor Audit.