If you recognise the above issues, your locations are operating without the accurate stock visibility they need to make accurate purchasing, fulfilment and planning decisions.
Root cause: The stock has a physical existence between locations but no operational representation in the system. The source record decremented when the transfer was despatched. The destination record will not update until someone confirms receipt. The gap between those two events is a period during which neither location has an accurate picture. Decisions made in that gap — purchasing more, committing to sales orders, planning warehouse capacity — are made on incomplete information.
Stok.ly creates an in-transit record from the moment a transfer is despatched. Source stock decrements. The destination sees an inbound quantity from the moment despatch is confirmed. Both locations see the live status — requested, picked, despatched, in transit, received — in the same operational system throughout the transfer.
When receipt is confirmed by barcode scan, the in-transit clears and destination on-hand increments.
In Stok.ly, every transfer has a status that is updated in real time at each stage of its lifecycle.
The source team can see that the transfer has been received without contacting the destination.
The destination team can see that the transfer was despatched yesterday and is expected today without contacting the source. Operations managers see all active transfers across all locations in a single consolidated view.
Variances are captured and stock adjustments are quick to investigate and correct.
The question “where is that transfer?” has an answer in the system, available to anyone with access, without a phone call, an email or a spreadsheet check.
One of the operational costs of in-transit invisibility is the inability of the destination to plan against expected inbound stock. A transfer was despatched Monday. It should arrive Tuesday. The destination warehouse team plans their receiving capacity, staffing and available storage for Tuesday — but without a confirmed inbound, that planning is guesswork.
If the transfer arrives unexpectedly, the warehouse is not ready.
If it does not arrive, the production plan that depended on it is disrupted.
In Stok.ly, the destination sees the transfer quantity as an expected inbound from the moment the transfer is created and the despatch is confirmed. The receiving team plans against a confirmed figure, not a phone call from the source. Warehouse capacity, staffing and put-away planning is based on accurate expected arrivals.
Operations team, scaling ecommerce business, furniture sector
The most operationally costly consequence of in-transit invisibility is the duplicate purchase order raised at the destination for stock that is already on its way. Without visibility of the in-transit quantity, the destination’s purchasing team sees a stock need, raises a PO, and then receives both the transfer and the PO delivery within days of each other.
The destination now holds twice the stock it needed. The excess must be stored, managed and either used slowly or transferred elsewhere.
Stok.ly shows in-transit quantities from active transfers in the destination’s stock view alongside on-hand and committed quantities. The purchasing decision is made knowing that the transfer is on its way. See also: Transfers Are Creating Stock Mistrust.
| Capability | What it controls | Why it matters |
|---|---|---|
| Live transfer status | Requested, picked, despatched, in transit and received status visible to all locations in real time | Transfer status visible without a phone call, email or manual check at any stage of the lifecycle |
| Source to destination visibility | In-transit quantity visible at both source and destination throughout the transfer | Neither location makes decisions without knowing about the in-transit stock |
| Destination inbound planning | Destination sees expected inbound quantity from moment transfer is despatched | Warehouse capacity, staffing and purchasing planned from confirmed inbound data, not guesswork |
| In-transit ATS accounting | In-transit stock excluded from source ATS; shown as inbound in destination view | Available figures at both locations reflect in-transit reality throughout the transfer |
| Barcode-confirmed receipt | Destination confirms receipt by scan; in-transit clears on confirmed count | Stock received by confirmed count; discrepancies flagged at receipt with full audit trail |
| Consolidated transfer view | All active transfers across all locations visible in one operational record | No need to check each location individually; all in-transit stock visible from one view |
| Current approach | What tends to break | Stok.ly |
|---|---|---|
| Transfer status tracked by phone or spreadsheet | Neither location has reliable status without a manual check; status information is always delayed | Live transfer status in the operational record from request through to confirmed receipt |
| Destination not visible to source after despatch | Source cannot confirm receipt without contacting destination; no audit trail | Both locations see the same transfer record and receipt status simultaneously |
| In-transit stock not accounted for in ATS at either location | Source may oversell despatched stock; destination may order stock already on its way | In-transit excluded from source ATS; shown as inbound in destination view from despatch confirmation |
| Destination raises PO for stock already in transit from source | Transfer and PO both arrive; duplicate stock sits in destination; has to be managed or moved again | Destination sees in-transit inbound; purchasing decisions account for expected transfer arrival |
| Transfer discrepancies discovered at end-of-month count | In-transit stock unaccountable for weeks; adjustment cannot be traced to specific transfer event | Barcode receipt confirms count at destination; discrepancies flagged and traceable at point of receipt |
| No single view of all transfers across the business | Each location must be checked individually; no consolidated in-transit picture | All active transfers across all locations visible in one consolidated operational view |
“I like that the program is very fast. When we sell something on eBay or Amazon, the stock updates everywhere straight away. The stock app is easy to use in the warehouse, and it makes our work much quicker.”
Verified G2 review, 5 stars — Read on G2
Single-location businesses with no inter-location stock transfers. Businesses where all stock moves between locations are immediate — same-day handoffs between adjacent sites where in-transit invisibility is a matter of minutes rather than days. Stok.ly’s transfer management adds the most value where transfer duration, frequency and the number of locations involved create meaningful operational risk from in-transit invisibility.
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.”
Most inventory systems record two transfer events: stock leaving one location and stock arriving at another. There is no operational state between these two events. Stock that has been despatched but not yet received exists in a physical reality the system has no record of. It has left the source record. It has not entered the destination record. For however long it is in transit, it is operationally invisible to both locations.
In-transit stock is the quantity committed to a transfer that has been despatched from the source but not yet confirmed received at the destination. Stok.ly tracks in-transit as a named stock state with a specific quantity, source, destination and lifecycle stage. It is visible to both locations from the moment of despatch and appears in purchasing views as expected inbound. It does not disappear from the operational record until receipt is confirmed by barcode scan at the destination.
Every transfer in Stok.ly has a status updated at each stage of its lifecycle: requested, picked, despatched, in transit and received. Both the source and destination location see the same status in the same operational system. The source can see that the transfer has been received. The destination can see that the transfer has been despatched. Neither location needs to contact the other to find out the status.
In Stok.ly, source ATS decrements the moment the transfer request is raised — not at pick, not at despatch. The committed transfer quantity is removed from available stock immediately on request creation. This prevents the source from selling or committing stock already allocated to a transfer, even before it has been physically picked or despatched.
The in-transit quantity from a confirmed despatch is visible in the destination’s incoming stock view. When purchasing decisions are made at the destination, the expected inbound from active transfers is part of the available picture. A purchasing manager can see that units are in transit from the primary warehouse and does not need to raise a PO to cover the same demand.
The destination team opens the transfer on the warehouse handheld app and scans each unit received. Each scan confirms a unit against the expected transfer quantity. When the scan count matches the despatched quantity, the transfer closes, the in-transit state clears and destination on-hand increments by the confirmed count. If the count falls short, the discrepancy is flagged immediately on the device.
Stok.ly holds a single inventory record across all locations regardless of number. Every transfer between any two locations is tracked in the same operational record with the same lifecycle states. A consolidated view shows all active transfers across all locations simultaneously. There is no need to check each location individually or aggregate data from separate records.
Brightpearl handles multi-location inventory management adequately for mid-market businesses with straightforward inter-location transfer needs but has depth limitations in WMS capability and transfer lifecycle granularity for businesses with high transfer frequency or complex multi-location operations. Stok.ly tracks every transfer through a fully-staged lifecycle with source ATS decrement at request, destination inbound at despatch, and barcode-confirmed receipt — providing the operational accuracy that prevents in-transit discrepancies from accumulating.
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.