If three or more of these are true, in-transit stock invisibility is creating operational decisions — purchasing, fulfilment, sales commitments — that are based on incomplete information.
Root cause: Transfers are managed as a two-event process: stock leaves one location, stock arrives at another. There is no operational state between these two events. The stock is physically somewhere. Operationally, it is nowhere. Both locations are making decisions without knowing a transfer is in progress. The source oversells stock already despatched. The destination purchases stock already on its way.
Stok.ly creates an in-transit stock state the moment a transfer is despatched. The source location’s ATS decrements immediately. The destination sees an inbound quantity from the moment despatch is confirmed. When the stock arrives and receipt is confirmed by barcode scan, the in-transit clears and the destination’s on-hand increments.
At every stage, both locations are working from the same operational record.
Choose to show in-transit stock on websites or hide in-transit stock from ecommerce until received.
In Stok.ly, in-transit is not an absence of data. It is a named, tracked state with a quantity, a source, a destination and a lifecycle. The moment a transfer is despatched, the in-transit quantity exists in the operational record. It is visible to both the source and destination location. It is visible to the purchasing function. It is visible in stock valuation reporting. It is not a gap between two events — it is a state that stock occupies between those events, with all the operational visibility that any other stock state has.
Stok.ly tracks transfers through five stages: requested, picked, despatched, in transit and received. At each stage, the operational record updates. When the pick is completed and the transfer is despatched, the stock transfer table view updates. When receipt is confirmed by barcode scan, the in-transit clears and destination on-hand increments. Each step visible on the transfer table in real time.
The destination location does not need to call the source to find out if the transfer has left. The source does not need to call the destination to find out if it has arrived. Both locations see the same transfer record in the same operational system, at every stage of the lifecycle.
Operations director, multi-country retail and wholesale operator
A common consequence of in-transit invisibility is not the stock count discrepancy — it is the purchase order raised at the destination for stock already travelling from the source. The destination’s purchasing team looks at available stock, sees a need, raises a PO. The transfer arrives two days later. The PO arrives a week after that. The destination now has twice the stock it needed.
In Stok.ly, the in-transit quantity is visible in the purchasing view. When the destination’s team reviews purchasing demand, the expected inbound from transfers is part of the available picture. The decision not to raise a new PO is made on accurate information, not a phone call. See also: We Don’t Know Where Stock Is Between Warehouses and Stores.
| Capability | What it controls | Why it matters |
|---|---|---|
| In-transit stock state | Tracks stock from transfer request through despatch to confirmed receipt | Stock is never invisible between locations; both sites see the same in-transit quantity |
| Transfer request workflow | Raises request, allocates stock at source, guides warehouse pick and despatch | Source stock is committed to the transfer from the moment the request is created |
| Destination inbound visibility | Destination sees inbound quantity from moment transfer is confirmed for despatch | Destination plans warehouse capacity and purchasing against confirmed inbound data |
| Barcode-confirmed receipt | Destination confirms receipt by scan; in-transit clears and on-hand increments at confirmed count | Receipt is confirmed by actual count, not assumed; discrepancies flagged at point of receipt |
| Source ATS at time of request | Source available-to-sell decrements when transfer is raised, not when stock physically leaves | Source ATS is never overstated by quantities already committed to a transfer |
| Multi-location transfer view | All active transfers across all locations visible in one operational record | Purchasing and fulfilment decisions made with complete visibility of all stock, wherever it is |
| Current approach | What tends to break | Stok.ly |
|---|---|---|
| Transfer raised as an instruction with no in-transit state | Stock invisible between despatch and receipt; neither location accounts for it | In-transit state from transfer request through despatch to confirmed receipt at both locations |
| Transfer status tracked by phone, email or spreadsheet | Neither location has reliable status without a manual check | Transfer lifecycle tracked in the operational record from request to confirmed receipt |
| Destination not notified until stock physically arrives | Destination cannot plan warehouse or purchasing from expected inbound | Destination sees inbound quantity from moment transfer is confirmed for despatch |
| Source ATS not decremented until stock physically leaves | Source oversells stock already committed to and despatched on a transfer | Source ATS decrements when transfer is raised; committed quantity removed immediately |
| Purchase orders raised at destination for stock already in transit | Transfer and PO both arrive; duplicate stock sits in destination warehouse | In-transit quantities visible in purchasing view; demand already met by transfer not re-ordered |
| End-of-month adjustments for in-transit discrepancies at stock count | In-transit stock unaccountable for weeks; adjustment cannot be traced to a specific transfer | Barcode receipt confirmation at destination; discrepancies flagged and traceable at point of receipt |
“We have gone from a pen and paper warehouse to a completely digital system that has streamlined our business immensely.”
Verified G2 review, 5 stars — Read on G2
Single-location businesses with no stock transfers between sites. Stok.ly’s transfer management adds the most value where transfer frequency, volume and the number of locations involved make manual status-tracking unreliable.
What do you like best about Stok.ly – Inventory-Centric Cloud ERP?
“we have been a user for the last 4 years and we cannot think of life without it for our retail business. it makes listing to shopify and other marketplaces easy, keeps inventory accurate online and the POS is easy to use. accurate inventory across all sales channels is the big win for us.”
Stock transfers create an operational gap between the moment stock leaves one location and the moment it is confirmed received at another. During that gap, the stock has left the source but has not arrived at the destination. Most inventory systems have no operational state to represent this in-transit period. The stock is physically present somewhere; operationally, it exists nowhere. Both locations make decisions without knowing a transfer is in progress.
An in-transit stock state is an operational record of stock that has been committed to a transfer from a source location but not yet confirmed received at the destination. Without this state, stock moving between locations is invisible to both sites. The source may oversell units already despatched. The destination may purchase stock already on its way. In-transit visibility closes this gap: both locations see the same quantity throughout the transfer.
Stok.ly tracks transfers through a lifecycle of distinct states: requested, picked, despatched, in transit and received. When a transfer is requested, source ATS decrements immediately. When despatch is confirmed, the in-transit state is active and visible to both locations. When the destination confirms receipt by barcode scan, the in-transit clears and destination on-hand increments. At no point is the stock in a state that neither location can see.
At the source location, ATS decrements the moment the transfer request is raised — not at pick, not at despatch. At the destination, an inbound quantity appears from the moment despatch is confirmed. Both locations have accurate available figures throughout. The source never oversells stock committed to a transfer. The destination never purchases stock already on its way.
The destination team opens the transfer on the warehouse handheld app and scans each unit received. Each scan confirms a unit against the transfer quantity. When the scan count matches the despatched quantity, the transfer closes, the in-transit clears and destination on-hand increments by the confirmed count. If the count falls short, the discrepancy is flagged immediately for investigation.
In-transit quantities are visible in the purchasing view alongside on-hand and committed stock. When a purchasing decision is made, the available-to-sell figure already accounts for in-transit inbound quantities at the destination. Stock travelling from location A to location B is visible to the purchasing function at B as expected inbound. The decision not to raise a new PO is based on live data, not a phone call.
Brightpearl has reasonable multi-location inventory management but limited WMS depth and transfer lifecycle granularity for businesses with high transfer frequency. Cin7’s transfer management is adequate for simple inter-location moves but lacks the in-transit state visibility and barcode-confirmed receipt that prevent the discrepancies accumulating in businesses with regular, multi-SKU transfers. Stok.ly tracks every transfer as a fully-staged lifecycle with barcode confirmation at receipt.
At the source location, ATS decrements the moment the transfer request is raised. At the destination location, the in-transit inbound quantity appears the moment despatch is confirmed. Both locations have accurate available figures throughout the transfer process, from request to confirmed receipt.
All our sales, support and development team are located in Hereford and Cheltenham in the U.K. Please submit the contact form and we will contact you within the same business day.