What do you like best about Stok.ly – Inventory-Centric Cloud ERP?
“We have gone from a pen and paper warehouse to a completely digital system that has streamlined our business immensely. The customer support has been superb since the day we onboarded with Stok.ly and we continue to build a great relationship with the team.We use Stok.ly daily in our warehouse and have found a number of features to now be invaluable. The ease of integration is incredible and has streamlined tasks within our business ten fold.”
Stok.ly “stock transfer management”, controls the full lifecycle of stock movement between warehouses, stores and operational locations. It covers transfer request, authorisation, warehouse pick and dispatch, in-transit state, receipt confirmation, variance capture and availability updates — connected to live inventory, orders, warehouse execution and fulfilment in one operational control layer.
It is not a transfer log or a spreadsheet tracker. It is the operational mechanism that keeps inventory truth accurate as stock moves between locations — so every team, every channel and every purchasing decision reflects where stock actually is, not where it was before it moved.
Transfers should be simple. A location needs stock. Another location has stock. The stock moves, the system updates and everyone trusts the result. In practice, transfers become one of the primary reasons inventory stops being trusted as businesses grow.
Stok.ly transfer management answers the transfer questions that determine whether multi-location inventory can be trusted:
Stock transfers are one of the most common root causes of inventory inaccuracy in multi-location businesses — and one of the most consistently underestimated. The individual transfer seems simple. The cumulative effect of poorly controlled transfers, across hundreds of movements per month, is an inventory picture that nobody trusts.
Stock leaves one warehouse and seems to disappear. A store is waiting for replenishment but does not know whether the stock was sent. A warehouse believes the stock has been dispatched. Customer service does not know whether it can be promised. Shopify may still show it as available at the source location. The purchasing team considers buying more because the available position looks low at every location.
At that point, transfer management is no longer an admin task. It is the thing preventing the business from trusting its own stock.
Root cause: When stock movement between locations is not clearly tracked through every stage — dispatched, in transit, received — purchasing decisions are made against an inventory picture that does not reflect what the business actually owns. Stock that is in transit, unconfirmed at a destination, or recorded at the wrong location appears to be missing. The purchasing team buys to fill a gap that does not exist.
What Stok.ly does: Every transfer is tracked through dispatch, in-transit and receipt states in real time. Purchasing sees the true available position across all locations — including what is in transit — before raising any purchase order.
Transfer requests and authorisation — controlled from the point of initiation
Transfers in Stok.ly start with a controlled request. Teams in stores or warehouses submit transfer requests through the platform — specifying what is needed, from which location, and in what quantity. Requests with permission-controlled authorisation workflows can be configured so that transfers require approval before the source location begins picking. No verbal requests, no emails, no informal messages that bypass the system.
Every request is visible to the locations involved from the moment it is submitted. The source location sees what needs to be picked and dispatched. The receiving location sees what is coming and when to expect it.
Warehouse pick and dispatch — transfer execution connected to stock truth
Once authorised, a transfer pick list is created at the source location. Via the Stok.ly Android WMS app, warehouse operatives pick the transfer using barcode scanning — confirming each item and quantity against the transfer request. Discrepancies are captured at the point of pick. When dispatch is confirmed, stock immediately moves to in-transit state in the inventory layer.
The source location’s available stock reduces the moment the transfer is dispatched — not when someone manually updates a spreadsheet. Channel availability on all connected platforms updates in real time.
→ Explore Stok.ly Warehouse Management
In-transit state — stock that moves without disappearing
In-transit is a distinct, controlled inventory state in Stok.ly. Stock in transit is not available at the source — it has left. It is not yet available at the destination — it has not arrived. It is tracked as in-transit, with full visibility of what is moving, from where, to where, and what quantity is expected.
Channel availability rules can include OR exclude in-transit stock from available-to-sell figures on Shopify, ecommerce channels, B2B channels and ePOS. If set to exclude, customers cannot buy stock that is physically between locations. Purchasing teams can see the in-transit position before deciding whether to raise a purchase order.
Root cause: When transfer tracking lives in spreadsheets rather than in the system, every team maintains their own version of what has moved, what has arrived and what is outstanding. Versions diverge. Updates lag. The business ends up with multiple conflicting pictures of where stock is — all of which someone believes is correct.
What Stok.ly does: Transfer visibility — dispatched, in transit, received, variance — lives in one place. Every team with access to the platform sees the same real-time picture. There is no spreadsheet to update and no version to reconcile.
Receipt confirmation and variance capture
When stock arrives at the receiving location, the team confirms receipt via barcode scanning on the Android WMS app or through the back office. Stok.ly compares received quantities against the dispatched transfer and captures any variance immediately. Stock moves from in-transit to available at the destination — and all connected channels update.
If the transfer is short, overshipped, or contains incorrect items, the variance is recorded at the point of receipt with the user, date and time stamp. Management can investigate the discrepancy with a full audit trail showing what was requested, what was dispatched and what was received — at every stage, by every person involved.
Automated transfers for replenishment — min/max rules that trigger without manual intervention
Stok.ly’s rules engine automates stock transfers based on min/max inventory thresholds and location-level replenishment rules. When stock at a store or warehouse location falls below a defined threshold, a transfer request is automatically generated, a pick list is created at the source location and the transfer workflow begins — without anyone manually identifying the need, sending a message or updating a spreadsheet.
Automated replenishment transfers are particularly valuable for retail businesses managing regular store replenishment cycles from a central warehouse. The system monitors each store’s stock position, triggers the transfer at the right moment and executes it through the same warehouse pick and dispatch workflow as manual transfers.
Why transfer management needs inventory and order control
Transfers do not happen in isolation. Stock moves because a location needs it — to fulfil a customer order, to replenish a store, to balance availability across a distribution network, or to ensure purchasing decisions reflect what the business actually owns.
A standalone transfer log or spreadsheet tracker records the movement. It does not connect that movement to the order that depends on it, the channel that should stop showing the stock as available, the purchasing decision it affects, or the customer service query it should resolve.
Stok.ly connects transfer management to the full operational layer. The warehouse picks against the transfer. The inventory layer reflects the in-transit state immediately. Orders waiting for the stock see when it will arrive. Channels show accurate availability throughout the movement. Purchasing decisions are made against a complete picture that includes what is in transit. Customer service can answer questions without chasing the warehouse.
→ See how Stok.ly connects transfers to the full operational control layer
→ Explore Stok.ly multi-location inventory management
| Capability | What it controls | Why it matters |
| Transfer request and authorisation | Permission-controlled transfer requests submitted through the platform by any authorised location — with approval workflows before source location picks | Transfers are initiated through a controlled process rather than via emails, messages or verbal instructions that bypass the system and leave no audit trail |
| Full transfer lifecycle management | Transfer states across the full movement: requested, picking, part-dispatched, dispatched, in-transit, part-received, received | Every team sees exactly where each transfer is at any point — no ambiguity about whether stock has left, where it is now, or when it will be available at the destination |
| In-transit stock state | Distinct inventory state for stock between dispatch and receipt — excluded from available-to-sell at source and destination until confirmed received | Channels never show in-transit stock as available to sell — preventing oversells on stock that is physically between locations and giving purchasing teams the full inventory picture |
| Barcode-scanned warehouse execution | Transfer pick and dispatch via Android WMS app barcode scanning at the source — receipt confirmation via scanning at the destination | Physical transfer actions connect to the system in real time — stock availability updates the moment stock is dispatched or received, not when someone manually updates a record |
| Variance capture and investigation | Comparison of dispatched versus received quantities at the point of receipt — variance flagging, investigation trail and resolution recording | Short, overshipped or incorrect transfers are identified and recorded at the point of receipt — management can investigate with a full audit trail rather than discovering discrepancies during a stock take weeks later |
| Automated transfers via rules engine | Min/max threshold rules and sell-through rate logic that automatically trigger transfer requests and pick list creation at the source location | Regular replenishment transfers — particularly store replenishment from a central warehouse — run automatically without manual identification, request or coordination |
| Multi-location stock visibility | Stock on hand, on order, in transit and available across all warehouses, stores and operational locations from one dashboard | Purchasing, sales and customer service teams see the complete multi-location inventory picture — including what is in transit — before making any decision that depends on stock availability |
| Channel availability control for in-transit stock | Automatic exclusion of in-transit stock from available-to-sell figures on Shopify, ecommerce channels and ePOS systems | Ecommerce and retail channels show accurate available inventory throughout a transfer movement — buyers cannot purchase stock that is between locations |
| Full audit trail by user, date and time | Every transfer action — request, authorisation, pick, dispatch, receipt, variance resolution — recorded with user identity, timestamp and quantity | Management has complete visibility of what happened at every stage of every transfer — accountability is built into the process rather than reconstructed after a discrepancy is discovered |
| Location-level stock reporting | Stock balances by warehouse, store or operational location — including in-transit quantities — from live operational data | Multi-location reporting reflects the true stock position rather than the pre-transfer position — fulfilment planning, purchasing and operational decisions are based on accurate location data |
| Current approach | What tends to break | Stok.ly |
| Manual transfer requests via email, message or verbal instruction | Requests are missed, duplicated or actioned incorrectly. There is no record of what was requested, no confirmation that it was received, and no audit trail when the transfer does not match what was expected. | Transfer requests are submitted through the platform with permission-controlled authorisation. Every request is visible to both locations from the moment it is submitted — with a full audit trail from request to receipt. |
| Simple stock adjustments to record transfers | Quantity changes at dispatch and receipt locations but the movement is not controlled. There is no in-transit state, no confirmation of what actually moved, no variance capture and no warehouse execution connection. | Every transfer passes through dispatch, in-transit and receipt states with barcode-scanned warehouse execution at both ends. Stock accuracy is based on what was physically confirmed, not on what was adjusted. |
| Spreadsheet transfer tracking | Transfer truth lives outside the system. Updates lag, versions diverge, data entry errors accumulate and the spreadsheet is always slightly behind reality. Different teams hold different versions of where stock is. | Transfer visibility lives in the platform — dispatched, in transit, received, variance — in real time. Every team with platform access sees the same picture. No spreadsheet to update, no version to reconcile. |
| Ecommerce platform managing multi-location inventory | Ecommerce platforms are not designed to control transfer workflows. In-transit stock appears available to sell. Receiving locations do not get confirmation. Variances are not captured. The transfer appears to work but inventory accuracy degrades with every movement. | Transfers are managed in the operational control layer — connected to the ecommerce channel but not controlled by it. In-transit stock is automatically excluded from channel availability. Channels update in real time on dispatch and receipt. |
| Warehouse memory and local knowledge for transfers | Transfer knowledge — what was sent, when, by whom, what was received — lives with experienced staff. When those people are absent, transfers cannot be traced. Discrepancies are unresolvable without someone who was present. | Every transfer action is user, date and time stamped. Management can trace any transfer at any point — what was requested, who approved it, what was dispatched, what was received and what any variance was — without relying on anyone’s memory. |
| Disconnected warehouse and store stock systems | Locations disagree about what was sent, received or currently available. Reconciliation is manual, dependent on file uploads or manual syncs, and always behind real-time reality. One location’s system says one thing; the other says something different. | All locations operate from one inventory layer in Stok.ly. Stock dispatched from one location and received at another updates the same data in real time — there is no separate system at each location that needs to be reconciled. |
| Manual replenishment transfers triggered by stock checks | Someone has to check stock levels at each location, identify what needs replenishing, submit a request, coordinate the pick and track the movement. The process depends on the right person doing the right check at the right time — which does not always happen before a location runs out. | Min/max replenishment rules in the Stok.ly rules engine monitor location stock levels continuously and trigger transfer requests automatically when thresholds are reached — before the location runs out rather than after. |
“We have gone from a pen and paper warehouse to a completely digital system that has streamlined our business immensely. The customer support has been superb since the day we onboarded with Stok.ly and we continue to build a great relationship with the team. We use Stok.ly daily in our warehouse and have found a number of features to now be invaluable. The ease of integration is incredible and has streamlined tasks within our business ten fold.”
Verified G2 review — 5 stars. Read on G2 →
Stok.ly transfer management is designed for growing businesses where stock movement between locations affects fulfilment, availability, reporting and stock trust.
Stok.ly transfer management is not designed for businesses that rarely move stock between locations or only need occasional manual stock adjustments. If transfer volume is low and the movements are simple, a basic adjustment feature may be sufficient.
Stok.ly transfer management is designed for businesses where transfer volume, transfer complexity or the operational consequences of inaccurate transfers make controlled lifecycle management essential.
What is Stok.ly stock transfer management?
Stok.ly stock transfer management controls the full lifecycle of stock movement between warehouses, stores and operational locations: transfer request, authorisation, warehouse pick and dispatch, in-transit state, receipt confirmation, variance capture and availability update. It is part of the Stok.ly order management-led, inventory-centric ERP platform — connected to live inventory, orders, warehouse execution and fulfilment rather than operating as a standalone transfer tool.
Why do stock transfers create inventory accuracy problems?
Transfers create inventory accuracy problems when the system cannot show where stock is between dispatch and receipt. Stock leaves one location and becomes uncertain — it is no longer at the source but not yet confirmed at the destination. Channels may still show it as available at the origin. The receiving location may not know it is coming. If the transfer is short or delayed, nobody knows until someone physically checks. The result is stock that the business knows exists but cannot trust — which is one of the most common causes of purchasing errors, oversells and fulfilment failures in multi-location businesses.
How does Stok.ly control in-transit stock?
Stok.ly tracks stock through every stage of the transfer lifecycle with a distinct in-transit state. When stock is dispatched from a location, it immediately moves to in-transit status — no longer available at the source and not yet available at the destination. Channel availability on all connected platforms reflects the in-transit position accurately rather than showing the pre-transfer gross count. When the receiving location confirms receipt via barcode scanning, stock moves from in-transit to available at the destination and all channels update in real time.
Can Stok.ly automate stock transfers between locations?
Yes. Stok.ly’s rules engine automates stock transfers based on min/max inventory thresholds, sell-through rates and location-level replenishment rules. When stock at a store or warehouse location falls below a defined threshold, a transfer request is automatically generated, a pick list is created at the source location and the transfer workflow is initiated without manual intervention. This is particularly valuable for retail businesses replenishing store stock from a central warehouse on a regular cycle.
How does Stok.ly handle transfer variances?
When the quantity received at the destination does not match the quantity dispatched from the source, Stok.ly captures the variance at the point of receipt scanning. Variances are flagged for management investigation with a full audit trail — what was requested, what was dispatched, what was received, who handled each stage, and when each action occurred. Stock accuracy is maintained based on what was physically confirmed received, not based on what was expected.
Does Stok.ly transfer management connect to ecommerce channel availability?
Yes. In-transit stock is excluded from available-to-sell inventory on all connected ecommerce channels, marketplaces and ePOS systems automatically. When a transfer is dispatched, Shopify and other connected channels update to reflect the reduced available position at the source. When the transfer is received and confirmed, availability updates at the destination. Channels never show in-transit stock as available — preventing oversells on stock that is physically between locations.
Can better transfer management reduce unnecessary purchasing?
Yes. One of the most common causes of unnecessary purchasing is stock that exists in the business but cannot be trusted — because it is in transit, unconfirmed at a destination, or recorded incorrectly due to an uncontrolled transfer. When transfer management gives teams a clear, trusted view of stock across all locations at all stages of movement, purchasing decisions are based on what the business actually owns rather than on what the most recently updated location record shows.
Does Stok.ly support warehouse-to-store stock transfers?
Yes. Stok.ly manages warehouse-to-store, store-to-warehouse, warehouse-to-warehouse and any other multi-location stock movement with the same full transfer lifecycle control. Transfer requests can originate from any location. Automated replenishment rules manage recurring store replenishment cycles from a central warehouse. Every movement carries a full audit trail regardless of direction or locations involved.
Ready to transfer stock with confidence?
Talk to the Stok.ly team about your multi-location transfer challenges. We will show you how Stok.ly controls the full transfer lifecycle — and whether it is the right fit for where your operation is going.
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.