The root cause of a SKU discrepancy is almost always one specific event that went untracked or got recorded wrong, and you find it by reading the movement history for that SKU rather than re-counting the shelf. Shipider gives every SKU a full movement log, so instead of guessing, you walk backward through what actually happened until the numbers line up again.
Re-counting the shelf is the wrong first move
When a physical count does not match the system, the instinct is to count again. Sometimes that catches a simple counting error, and if a second careful count agrees with the system, you are done. But most of the time the second count confirms what you already suspected: the shelf and the record genuinely disagree. Counting a third time does not tell you why. It only tells you the gap is real.
A discrepancy is not a mystery about how many units are on the shelf. It is a question about which event changed the quantity without the record keeping up. A unit does not vanish. It was received and never booked, moved and never logged, picked for an order that was never confirmed, or edited by hand with no note explaining why. Each of those is a moment in time with a cause behind it. The count tells you a gap exists. The history tells you where it came from.
Read the journey, not just the number
The reliable way to find a root cause is to open the SKU movement log and read it backward. In Shipider, every SKU carries a running record of what happened to it: received on which order, transferred between which pallets, adjusted by how much, and by whom, with a remaining quantity that updates after each event. That remaining quantity is the thread you follow.
Start at the present. The system says you should have a certain quantity on hand, but the shelf says something else. Now walk up the log one event at a time and ask a single question at each step: after this event, did remaining quantity still match what was physically true? For a while it will. Then you reach an event where the record and reality part ways. That is your root cause. Everything above it is noise, and everything below it inherited the same gap.
This is why a good movement log is worth more than a good counting routine. Counting tells you the current state. The log tells you the sequence of states and the decision behind each transition. When you can see that a pallet-to-pallet transfer moved forty units on the record but the receiving pallet only ever showed thirty, you are not theorizing anymore. You are looking at the exact event, the timestamp, and the person attached to it.
What a clean log lets you rule out
Reading the journey also lets you eliminate causes quickly. If the log shows every inbound receipt was verified against its order, you can stop suspecting receiving. If every transfer between pallets is present and balanced, transfers are clean. If every outbound pick was confirmed by a checker, picking is clean. You narrow the field until one category is left, and that category is almost always where the untracked event lives. Pallet-level traceability matters here, because a discrepancy that looks like it belongs to a SKU across the whole warehouse often belongs to one pallet that was mishandled.
The usual culprits
Over time you start to recognize the shape of a discrepancy from its symptom. A count that is high at receiving behaves differently from a count that drifts slowly over weeks, which behaves differently from a count that drops all at once. The pattern points you at the likely event before you even open the log, which makes the read faster. Use the table below as a starting map, then confirm the specific event in the history.
| Symptom | Likely root cause | Fix |
|---|---|---|
| Count high at receiving | Inbound was recorded, but an overage against the order was never reconciled | Verify the received quantity against the order right at the door, before it is put away |
| Count drifts slowly over time | Untracked transfers between pallets, where stock physically moved but the record did not follow | Record every move as a tracked transfer so the log stays balanced pallet to pallet |
| Sudden drop in on-hand quantity | A mis-pick on an outbound order sent the wrong SKU or the wrong count out the door | Confirm picks in the checker queue so a second person catches the error before shipment |
| Unexplained adjustment | A manual edit changed the quantity with no audit note explaining the reason | Require adjustments to run through a checker, so every change carries a reason and an approver |
Notice that three of the four fixes are not about counting more carefully. They are about making sure the event that changes a quantity gets captured at the moment it happens, by the right process. That is the real lesson buried inside every discrepancy: the count was never the problem. The missing record was.
Prevention is a workflow, not a spreadsheet
A spreadsheet can hold a quantity, but it cannot tell you who changed it, when, or why. Anyone can overwrite a cell, and the previous value is gone with no trace. That is exactly the condition that breeds discrepancies you cannot solve. If the record has no memory, every gap becomes a guess. Warehouses that grew up on Excel know this feeling well: the numbers were right last month, they are wrong this month, and there is no way to reconstruct what happened in between.
The way out is to stop treating inventory changes as edits and start treating them as events that pass through a process. Two habits carry most of the weight.
Route moves and adjustments through maker-checker
The first habit is to send anything that changes a quantity through a maker-checker workflow. A processor prepares the move, the transfer, or the adjustment. A checker confirms or approves it. The action lands on a timestamped audit trail with both names attached. This does two things at once. It catches the error before it becomes a discrepancy, because a second person looks at the change while it is still reversible. And it guarantees that if a gap ever does appear, the log already contains the event and the reason, so the root-cause read is short instead of endless.
This is especially important for adjustments, which are the most dangerous kind of change because they alter quantity without any corresponding physical movement. An adjustment with no note is the classic unexplained gap. When adjustments must be approved by a checker and carry a reason, that whole category of untraceable discrepancy stops existing. The discrepancy report becomes something you can actually work, with a checked and unchecked filter that lets you separate the gaps someone has already investigated from the ones still waiting for a look.
Run continuous cycle counts
The second habit is to catch drift early with continuous cycle counts. A once-a-year full count finds discrepancies long after the event that caused them, when the trail has gone cold and the person who made the move has forgotten the day. Counting a small slice of the warehouse continuously means you find a gap while it is days old, not months old. A fresh gap is a solvable gap. The movement log still has recent events at the top, the timestamps are close, and the person involved can often remember the exact carton.
Cycle counting and the movement log work together. The count surfaces the gap. The log explains it. And because both feed the same audit trail, every discrepancy you resolve makes the next one easier, because you have already tightened the process step that produced it. Browser camera barcode scanning keeps the counting itself honest without any special hardware, so the person doing the count is confirming the actual SKU on the shelf, not typing a number they half-remember.
Turning a discrepancy into a fixed process
The goal is not just to close today's gap. It is to make the same gap unlikely tomorrow. Once you find the root-cause event, ask which process step let it through. If a transfer went untracked, transfers need to be mandatory events, not optional ones. If an adjustment slipped by with no note, adjustments need a checker. Each root cause you find is a signpost pointing at a workflow rule that needs tightening. Over a few cycles, the discrepancies that keep recurring are the ones that teach you the most, because they reveal the one door you left open.
This is the difference between a WMS and a spreadsheet with more columns. Shipider is a WMS, built to hold the sequence of events, not just the final number. When every receipt, transfer, pick, and adjustment lands on a shared log with a name and a timestamp, a discrepancy stops being a crisis and becomes a short read.
FAQ
Why not just recount and correct the number?
Recounting fixes today's number but leaves the cause in place, so the same gap comes back. Correcting the quantity without recording why also creates exactly the kind of unexplained adjustment that is hardest to trace later. It is better to find the event that caused the gap, fix the quantity through a tracked adjustment with a note, and tighten the process step that let it happen.
How far back should I read the movement log?
Read backward from the present until the remaining quantity stops matching what was physically true, then stop. The first event where the record and reality diverge is your root cause. You do not need the whole history, only the stretch between now and that break point, which is why a continuous cycle count that finds gaps early keeps the read short.
What if two different events both look suspicious?
Follow the running remaining quantity. Only one event actually broke the match between record and reality, and the log will show which one, because after the true culprit the numbers never line up again while before it they always did. If both events carry a timestamp and an approver, you can confirm the exact one instead of choosing between guesses.
Do I need barcode hardware to keep counts accurate?
No. Shipider uses browser camera barcode scanning, so the person counting can confirm the exact SKU on the shelf using a device they already have. That removes one of the quietest sources of discrepancy, which is a correct count entered against the wrong product.
How does maker-checker actually reduce discrepancies?
It puts a second set of eyes on every change while it is still reversible, so mistakes are caught before they become gaps. It also forces each change onto a timestamped audit trail with a reason and an approver, so if a gap does appear, the event that caused it is already recorded. Prevention and traceability come from the same workflow.
If your counts keep drifting and you cannot tell why, give every SKU a movement log that remembers. Start with Shipider and turn your next discrepancy into a short read instead of a long guess.
Related reading: Warehouse Audit Trail Software: The Cornerstone Guide to Who Did What and When