The Problem
Basic rebalancing is manageable by hand. Move some of this from the location with too much to the location with too little. Most teams can do that from a stock report without much difficulty.
Real transfer decisions rarely stay that simple. A product with ten sizes, across three stores, with two seasons of stock still in the building, needing a specific combined target per size, sourced from one particular warehouse, depleting the older season first.
Working that out by hand means building a spreadsheet, and once built it is rarely revisited, because rebuilding it is slower than living with a stale version.
The commercial cost is not the admin time. It is that the transfer either does not happen, or happens on the wrong basis. Sending this season’s stock while last season’s sits behind it or hitting a target per SKU when the customer actually experiences availability per size.
How It Works
Everyday rebalancing, handled without a complex instruction
The AI classifies each product as fast or slow-moving per location, compares stockout risk and days of cover across locations simultaneously, and identifies where the imbalance sits. Where the answer is straightforward it can recommend or create the transfer. The question it answers is not which location is lowest, but where this stock is most likely to sell and where it is currently doing nothing.
The instruction that is its own proof
See video below: replenish all child items of a parent product so that each size holds 300 combined units across three stores, sourcing from the central warehouse, depleting the oldest season before the next and the next before the newest, grouping by size rather than treating each seasonal SKU independently, and showing full analysis before creating any transfer.
Nothing about that instruction is unusual for a fashion or footwear operator.
Everything about it is difficult to execute by hand.
What the AI did with it
Stok.ly AI identified the parent-child relationships across the range.
It grouped every variant by size across the seasons present.
It calculated current combined stock per size per store against the 300-unit target.
It determined the quantity required per size per store.
It sourced from the oldest season first and cascaded to the next only once the older was exhausted.
It enforced the single-warehouse source constraint throughout.
Then it produced a complete pre-approval table; current stock by season, combined total, quantity required, available source stock by season, proposed transfer by season, projected combined position after receipt and any shortfall, for every size at every store.
One approval created every transfer.
Why grouping by size rather than by SKU is the hard part
A customer looking for a size does not care which season’s version of it they get. The commercially correct target is therefore a combined figure per size, not a figure per seasonal SKU. Almost every system will happily replenish per SKU, because that is how the data is structured. Reasoning across the hierarchy to a combined target per size, while respecting a season waterfall, is the part that ordinarily requires a person and a spreadsheet.
The season waterfall, and why it matters commercially
Depleting older stock first is not tidiness. Older season stock is the stock most at risk of ending up as markdown, and its GMROII is usually already deteriorating. A transfer that moves the newest season while the oldest sits in the warehouse actively increases the eventual markdown exposure. Encoding the waterfall into the instruction means the commercially correct sequence happens by default rather than depending on whoever built the spreadsheet remembering it.
Workings before commitment, every time
Nothing is created until the workings have been shown and approved. This matters more on complex transfers than simple ones, precisely because the arithmetic is hard to verify mentally; the pre-approval table is what makes the recommendation auditable rather than a black box that moves stock.
Trust your stock. Transfer with confidence. Control orders. Fulfill every day like clockwork.
G2 Customer Reviews
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.”
Order management and inventory ERP software for growing retail, wholesale and distribution businesses.
The Numbers, and How They Are Calculated
| Element | What the AI reads or produces | Why it matters |
|---|---|---|
| Product hierarchy | Parent and child variant relationships across the range | Allows reasoning at range level rather than SKU by SKU |
| Size grouping | Variants grouped by size across all seasons present | Matches how availability is actually experienced by a customer |
| Current combined stock | Stock per size per location, summed across seasons | Establishes the real starting position against the target |
| Season priority | Ordered waterfall from oldest to newest | Reduces eventual markdown exposure on ageing stock |
| Source constraint | The specific location stock may be drawn from | Prevents the AI solving the problem from a location you did not authorise |
| Quantity required | Target minus current combined stock, per size per location | The actual ask, before source availability is considered |
| Proposed transfer by season | How much comes from each season to meet the requirement | Makes the waterfall visible and auditable |
| Projected position | Combined stock per size per location after receipt | Confirms the instruction has actually been satisfied |
| Shortfall | Any requirement that source stock cannot meet | Surfaces where a purchase order is needed instead |
What Actually Changes
| Manual planning in a spreadsheet | Stok.ly AI transfers | |
|---|---|---|
| Time to produce a complex plan | Hours, and only when someone has time | One instruction and an approval |
| Basis of the target | Usually per SKU, because that is how data exports | Combined per size, because that is how availability is experienced |
| Season sequencing | Depends on whoever built the sheet remembering | Enforced as an explicit waterfall |
| Auditability | The formula is in a cell somebody may have edited | Full pre-approval workings table |
| Frequency of revision | Rarely, because rebuilding is slow | On demand, because the calculation is not the bottleneck |
| Shortfall handling | Often discovered during picking | Surfaced before approval |
| Relationship to purchasing | Separate exercise entirely | Transfer considered before spend is committed |
Questions the AI Answers From Pre-Calculated Data
- Rebalance this product across my locations, moving stock from where it is not selling to where it is.
- Replenish every size of this range to a combined target across these stores from the central warehouse, oldest season first.
- Where am I overstocked relative to demand, and where should that stock go instead?
- Show me the workings before you create anything.
- Which locations are short of my highest-GMROII sizes in this range?
- Is there a transfer that solves this, or do I need to raise a purchase order?
How This Compares to Cin7, Brightpearl, Orderwise and Linnworks
Positions below reflect vendor-documented capability as at 27 July 2026.
- Cin7. Stock transfer creation and multi-location inventory are supported. Natural-language complex instruction handling across a product hierarchy, with a season waterfall and a pre-approval workings table, is not documented.
- Brightpearl. Multi-location transfers are supported and Inventory Planner can push approved purchase orders. Complex variant-level combined-target reasoning from a plain-language instruction is not documented.
- Orderwise. Multi-location stock control and transfers with automated purchase planning. No documented natural-language hierarchy reasoning.
- Linnworks. Multi-location inventory sync rather than transfer decision intelligence of this kind.
How to Test This in a Demo, Including Ours
Use the same anonymised data set and the same questions with every vendor, and insist on a live workflow rather than slides.
- Give the vendor a genuinely complex instruction in plain language — a combined target per size, across several locations, from one source, oldest season first — and see whether it can be executed at all.
- Ask to see the full workings before anything is created, and check whether the source availability per season is shown.
- Ask what happens when source stock cannot satisfy the requirement, and whether the shortfall is surfaced before approval.
- Ask whether the target can be set per size across seasons rather than per individual SKU.
- Ask whether the system will check for a transfer opportunity before recommending a purchase.
- Count the clicks and the elapsed time from instruction to created transfers.
- Change the source location constraint and confirm the plan is recalculated rather than adjusted by hand.
Score on time taken, number of clicks, whether the answer is traceable to source records, and whether the insight becomes an editable draft without rekeying.
Frequently Asked Questions
Can Stok.ly replenish complex size or variant ranges to a combined target automatically?
Yes. Describe the outcome in plain language — a combined target per size, across named locations, from a named source, depleting the oldest season first — and the AI traverses the product hierarchy, calculates the full plan and shows complete workings before creating anything.
Can the AI move stock between locations for simple rebalancing without a complex instruction?
Yes. It classifies products as fast or slow-moving per location, identifies where stock is overstocked relative to demand and where it is short, and can recommend or directly create the rebalancing transfer.
Does the AI show its workings before creating a transfer?
Yes. A pre-approval table is produced showing current stock by season, combined total, quantity required, available source stock, proposed transfer by season, projected position after receipt and any shortfall, for every size at every location.
Why does grouping by size matter rather than by SKU?
Because a customer looking for a size does not care which season’s version they receive. The commercially correct target is a combined figure per size. Most systems replenish per SKU because that is how the data is structured, which produces the wrong availability outcome.
Why deplete the oldest season first?
Older stock is the stock most at risk of ending as markdown, and its GMROII is usually already deteriorating. Moving newer stock while older sits in the warehouse increases eventual markdown exposure, so the waterfall is a commercial decision rather than a tidiness one.
What happens if the source location does not have enough stock?
The shortfall is calculated and surfaced before approval, so the gap is visible as a purchasing requirement rather than discovered during picking.
Can I restrict which location stock is drawn from?
Yes. Source constraints are enforced throughout the calculation, so the AI will not solve the problem by drawing from a location you did not authorise.
Is anything created without approval?
No. The plan is presented in full and nothing is committed until it is approved.
Contact Information
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.