--- title: You recorded a delivery and the stock level did not move summary: > Recording a delivery posts the stock immediately, so a level that has not moved almost always means you are looking at a different location: a delivery lands where the purchase order said it would, not at your default warehouse. Next most likely, the receiving is still Awaiting post and never posted, or you are waiting on costing, which never changes quantity. type: troubleshooting group: receive step: 2 permission: pos.receive prerequisites: - /help/receive/receive-a-delivery related: - /help/store/the-stock-ledger - /help/receive/cost-a-receiving last_updated: 2026-08-07 --- **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-1-are-you-looking-at-the-location-it-was-delivered-to) - [Check 2: does the receiving say Received or Awaiting post](#check-2-does-the-receiving-say-received-or-awaiting-post) - [Check 3: are you waiting for costing](#check-3-are-you-waiting-for-costing) - [Check 4: did the line have a quantity on it](#check-4-did-the-line-have-a-quantity-on-it) - [Check 5: did it come from a production run](#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 1. Open the receiving and read the **Location** on the header. 2. Open [Stock levels](/inventory/stock-levels) and filter to that same location. 3. 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 →](/help/receive/receive-a-delivery) **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 →](/help/store/the-stock-ledger) **Costing a delivery.** The second half — unit cost, freight, and why it is a separate job. [Learn more →](/help/receive/cost-a-receiving)