In Mossery, stock arrives on the books the moment you submit the delivery. There is no second approval that releases it, and no overnight job that catches up. If you submitted it, the units are already counted.
That makes "I recorded it and nothing changed" almost always a question of where you are looking, not whether it worked.
- Check 1: are you looking at the location it was delivered to
- Check 2: does the receiving say Received or Awaiting post
- Check 3: are you waiting for costing
- Check 4: did the line have a quantity on it
- Check 5: did it come from a production run
Work through them in that order. The first one explains most cases.
Check 1: are you looking at the location it was delivered to
A delivery lands at the location the purchase order names. Nowhere else.
Stock is always held per location, never as one company-wide pile. When you submit a receiving, every unit is booked to the delivery address on the purchase order — a warehouse, a retail counter, or a production partner. It is never booked to whichever location your screen happens to be showing.
This bites hardest on a phone. The mobile receive screen used to book every delivery into the default warehouse regardless of the order, so people learned to expect their main warehouse to go up. It now follows the order, which is correct and which changed what you see.
Fix it
- Open the receiving and read the Location on the header.
- Open Stock levels and filter to that same location.
- If the number is right there, nothing is broken. The stock is where the delivery went.
If the goods physically sit somewhere else, that is a move, not a receiving error — transfer them to the right location rather than editing the receiving.
Check 2: does the receiving say Received or Awaiting post
The status pill on the receiving tells you whether stock moved.
| Status | What it means | Has stock moved |
|---|---|---|
| Awaiting post | Submitted, but the posting step did not finish | No |
| Received | Quantities are on the books | Yes |
| Costed | Quantities on the books, unit cost finalised | Yes |
| Rejected | Voided before anything posted | No |
Awaiting post is the one to act on. It means the record was saved but the step that writes the stock did not complete — usually a connection dropping mid-submit on a phone. Nothing was lost and nothing was double-counted; the delivery is just waiting to be finished.
Open the receiving on a desktop and complete it there. The quantities you keyed are still on it.
Check 3: are you waiting for costing
Costing changes money. It never changes quantity.
The two halves of a delivery were deliberately split. Quantity is a physical fact the person unpacking the box observed, so it posts straight away. Cost is a finance judgement — which unit cost to keep, how to spread freight and duty — and it needs someone with costing rights, who may be days behind.
So a receiving sitting at Received and waiting to be costed is completely normal, and its units are already sellable. If you are watching for the stock level to jump when someone finally costs it, it will not: it jumped when the delivery was submitted.
Check 4: did the line have a quantity on it
Lines with nothing received are skipped, silently and correctly.
A line recorded as 0 writes no stock. So does a line for a service — a print run, a courier charge, a setup fee — because a service holds no inventory by definition. If a purchase order is entirely services, there is nothing to receive at all and the app says so rather than creating an empty record.
Open the receiving and read the received quantity on the line for SKU-001
itself. A blank or a zero there is the whole answer.
Check 5: did it come from a production run
Goods back from a production partner are booked against the run, not a supplier delivery, and they have their own counter.
Booking a batch in writes the stock exactly like a supplier delivery does. What sits next to it is a separate figure — "booked in so far" against the run's target — and that figure is derived from the receipts, not typed.
There was a real bug here: the stock posted correctly, but the run kept showing 0 booked in, and the screen offered to book the full run quantity again. It is fixed. But the shape of it is worth remembering, because it is the reverse of what you might assume:
The counter on a screen can be wrong while the stock is right.
If a run shows less booked in than you know you booked, do not tap it again. Confirm against the stock level first. Booking twice is far more expensive to unpick than a stale counter.
Still wrong after all five?
Now separate "wrong place" from "genuinely missing". There is one test.
Every stock movement writes a permanent line to the ledger, and the ledger is the record everything else is derived from. Open the product and look at its stock movement history:
- There is a receive entry for the delivery. The stock moved. You are reading a different location, a different product code, or a cached page — go back to Check 1.
- There is no entry at all. The stock genuinely never posted. Note the purchase order number, the receiving reference, the location on the header and the status pill, and pass those four things on. That set is enough for someone to finish the post without guessing.
One thing not to do: do not re-submit the delivery to force it through. The app blocks an obvious repeat, but a second record keyed hours later will post a second time and leave you counting the same box twice.
Explore
Recording a delivery. The full path from a purchase order to stock on the books, including what happens on a phone. Learn more →
Why the ledger is the answer. Every number in the app is derived from the movement history, which is why it settles arguments. Learn more →
Costing a delivery. The second half — unit cost, freight, and why it is a separate job. Learn more →