A stock count is a correction, not a replacement.
When you open a count session, Mossery writes down what it believes each product holds. That figure is frozen into the session. When the count is posted, the app works out the difference between what you typed and that frozen figure, and posts the difference as a movement.
This matters, because it means a count can be typed perfectly and still land on the wrong answer — if the frozen figure was measuring something other than the shelf you were standing at.
- Check 1: is the session for the location you counted
- Check 2: were some lines left blank
- Check 3: how old is the session
- Check 4: is anything in transit
- Check 5: does this product live in bins
Work through them in that order. The first two explain most cases.
Check 1: is the session for the location you counted
Every counted line belongs to exactly one location, and posts only there.
Stock is held per location. A count session opened for your main warehouse compares against your main warehouse and adjusts your main warehouse — even if the person holding the phone was standing at a retail counter. Nothing warns you, because typing a number is not evidence of where you were.
The tell is a variance that looks like a swap: one location suddenly gains roughly what another lost, and the sum across both is unchanged.
Fix it
- Open the count in Stock counts and read the location on the header, and on the line itself.
- If it is the wrong location, do not edit the posted count. Counts are never deleted once posted — that is what makes the history trustworthy.
- Post a fresh count at the correct location with the true figures. Then post one at the location that was wrongly adjusted, putting it back.
Two corrections, both visible in the history, beats one silent edit.
Check 2: were some lines left blank
A line with no number typed into it is not counted as zero. It is not counted at all.
A session can be posted while some lines are still empty. Those lines keep the figure the app already held, no movement is written for them, and the app tells you how many it left alone. This is deliberate — it is what makes it safe to count half a shelf before lunch.
The failure is quiet: someone counts 40 of the 200 lines in a session, posts it, and reads the result as "the whole shelf is now correct". It is not. Only those 40 products were touched.
Open the count and look for products where the counted column is empty. If the one you are arguing about is empty, the app never had an opinion on it.
Check 3: how old is the session
The figure the count compares against was captured when the session opened, not when you posted it.
Say the app believed 100 on Monday, when the session was opened. On Tuesday, 30 units sell. On Wednesday, you count the shelf, find 70, and post. The app compares 70 against the Monday figure of 100, posts a correction of minus 30 — and the level drops to 40. The 30 that sold have now been taken off twice.
This is the single most damaging way a count goes wrong, and it looks like the count "did not take". It did take. It corrected against a stale belief.
Fix it
- Count and post in the same session, ideally the same shift.
- If a session has been sitting open across days of trading, discard it and open a fresh one rather than posting what you already typed.
- If you have already posted a stale one, do not adjust it by hand. Open a new count at that location, count the shelf again, and post — a second count against fresh figures lands on the truth.
Check 4: is anything in transit
Stock moving between two locations stays on the books at the place it left until someone confirms it arrived.
A transfer records the movement only at the receiving end. Between dispatch and confirmation, the units are physically gone from the source shelf but still counted there, and not yet counted at the destination. Both ends will disagree with the app, in opposite directions, and both are behaving as designed.
| Where | On the shelf | In the app | Why |
|---|---|---|---|
| Source | Gone | Still counted | Not confirmed as arrived yet |
| Destination | Arrived | Not counted yet | Waiting for someone to confirm it in |
Counting either end mid-transit and posting the result bakes the error in permanently. Confirm the transfer in first, then count.
Check 5: does this product live in bins
If a product is assigned to bins at that location, the figure on an unbinned line is the leftover, not the whole shelf.
Bins split a location's stock into named places. The app then treats an unbinned count line as everything at that location that is not in a counted bin. Count the entire shelf into that one line and you have added the binned units a second time.
There is also a warning sign worth knowing. If the bins claim more units than the location holds, that leftover figure goes negative. A negative there always means the bin records and the ledger have drifted apart, and it needs sorting out before another count on top will help.
One case is safe from that drift. A count that lists the bins and states the loose stock describes the whole location, so it sets the total outright and never reads the leftover figure. The trade is that any bin you leave out of such a count is taken to be empty — which is deliberate, and is how a bin that no longer exists gets cleared, but it will surprise you if you meant to count only part of the shelf.
Still wrong after all five?
Go to the ledger, which is the only record that cannot be talked out of.
Open the product and read its movement history at that location. Every count that ever posted is in there, with its size and its date. Read the entries from the last date you trusted the number to now, and the story is usually obvious — a double correction, a movement to a location nobody expected, or a long quiet gap where the shelf drifted without anyone counting it.
If the ledger reads correctly and the shelf still does not match, the count is not your problem. Something is leaving the building without being recorded, and that is worth raising as a process question rather than fixing with another count.
And if the count screen itself refuses to post — most often because a line has no location on it — capture the count reference, the location, and the exact message, and pass those on. That message means the session was built wrong, not that you counted wrong.
Explore
Running a count properly. The order of operations that avoids most of the problems on this page. Learn more →
Why the ledger is the answer. Counts adjust the ledger; they never overwrite it. This explains why that choice was made. Learn more →
Moving stock between locations. Including what "in transit" means for the numbers at both ends. Learn more →