Retail chains: move stock to the store that will sell it before you buy more.
For chains with several physical stores, with or without a central warehouse. The system forecasts each store separately, sees where the same product is piling up and where it is running out, and proposes the transfer first and the purchase second. Each store manager sees their own store and head office approves the whole.
Book a 30-minute demoHow it works
Read-only connection · Tested on your own data first · Data hosted in the EU · Demos in English or Spanish
The short answer
Stock allocation for retail chains starts from a forecast of each store, not of the chain as a whole. It shows where a product is surplus and where it is short, proposes the store-to-store transfer that pays for itself before any new purchase, and then splits incoming deliveries by expected store demand, keeping a reserve at the central warehouse if there is one. Store managers review their own proposals and head office approves the combined list.
By Manuel Gómez González, founder of Arume · Reviewed on
What it does
Each store's stock, against that store's forecast
The high-street shop sells on Saturday what the shopping-centre store sells across the week, and the seaside store sells in August what others sell in half a year. The system learns each store separately and counts, for each product, how many days of sales are left there, not across the chain.
Transfers before purchases
If one store holds eight units that will take four months to sell at its pace and another runs out on Thursday, the first move is not a supplier order. The system proposes the transfer when it pays: how many units, from which store to which, using a trip that already exists.
Splitting what arrives
When a big delivery or a new collection comes in, someone decides how much each store gets. Equal shares or shares by shop size leave gaps in some and excess in others from day one. The system splits by each store's forecast and keeps part of the delivery at the warehouse for stores that sell faster than expected.
What fits in each store
A sixty-square-metre store cannot hold what a large one can. Capacity is recorded by product family and the system does not propose sending what does not fit: a tight store gets smaller, more frequent deliveries.
The store that sells less than it should
Some stores sell below comparable stores. The system separates the causes visible in the data: stock-outs of key items or sizes, stock sitting in the back room, or simply a weaker location. Each cause calls for a different decision.
A new store with data from day one
A store that has just opened has no history. The system starts it from the most similar stores (size, area, type of street) and gives more weight to its own sales week by week, so the first allocation starts from data and not from a hunch.
Why does total stock mislead a multi-store retailer?
When a chain looks at stock in its ERP, it tends to look at the total: thirty units of this product, we are fine. But those thirty can be twenty in a store that sells one a month and ten spread over four stores that run out this week. The total says do not buy; customers in four stores say otherwise.
Multi-store inventory control starts by looking at each store at its own pace. What matters is not how many units there are, but how many days of sales they cover there. Ten units are plenty in a neighbourhood shop and one Saturday morning in a city-centre one.
Once that is done, three kinds of product appear in every store: those that will run out before the next replenishment, those with months of cover, and those that are fine. Decisions come from crossing the first group in one store with the second group in another.
How do you forecast each store?
Every store has its own calendar. A high-street store sells mostly on Saturday, a shopping-centre store spreads sales over the week and peaks on December evenings, a seaside store lives on July and August. Forecasting the chain as one store and then splitting by fixed percentages erases those differences.
A single store sells few units of each product, so its history is patchy. The seasonal pattern is therefore learned from all similar stores together, and each store's level is adjusted with its own sales. What happened in the last two weeks corrects what comes next.
Days when a store did not have a product are marked separately. If not, the store that always runs out would look like a store that does not sell it, would receive less, and would run out even sooner. The same method is described in more detail on the demand forecasting page.
When does a store-to-store transfer pay?
A transfer is the cheapest purchase there is: the stock is already paid for and only needs moving. Even so, making them by eye has two risks. One is taking units from a store that needed them next week. The other is spending more on moving three units of a cheap product than they will ever earn.
For each product that is about to run out in a store, the system searches the others for units that, at their pace, will not sell before their next replenishment, and checks whether moving them pays with the trip cost you have entered. If a van already runs between those stores, the transfer is added to that trip. Only when there is nothing to transfer does a supplier order appear.
- The sending store keeps what it needs until its next replenishment, plus safety stock.
- The receiving store has a real risk of running out before its next delivery.
- The extra sales at the destination exceed the cost of moving the product.
- Existing routes and trips between stores are used first.
How should a delivery be split between stores?
The moment a chain most often gets it wrong is the split of what arrives: the new collection, a large order, a launch. With no history for those items, stock is split equally or by shop size, and three weeks later the phone calls between stores start to correct it.
The system splits with each store's forecast for similar products in the same season, and does not send everything out. It keeps a reserve at the central warehouse for stores that sell faster than expected. That reserve replaces many store-to-store transfers, because correcting from the warehouse is simpler than moving stock sideways.
Without a central warehouse the logic changes: the supplier delivers to each store, the split is fixed in the order, and the only later correction is a transfer. The system is more cautious with the first split and proposes transfers earlier, as soon as it sees which stores pull harder.
Why does one store sell less than its peers?
Almost every chain has a store that sells below comparable stores. Before deciding it is a worse store, look at stock: it often sells less because it is out of the central sizes or the best sellers, and the customer leaves without buying. In the FMI, GMA and CIES study (2002), when a product was missing, 31 percent of shoppers bought it at another store and 9 percent bought nothing.
The system compares each store with similar ones and separates what the data shows. More days without best sellers means a replenishment problem, fixed by sending more often. Stock that is there but not selling may be in the back room or badly placed, which the store manager sees on a walk round. If it is in stock, visible and still slow, it is the store, and it should be sent less to avoid idle stock.
Who decides, and what does it connect to?
Store managers keep deciding. They know the school opposite starts a week early or that the street is dug up. That is not in the data. What changes is the starting point: the manager receives a proposal calculated from the store's sales, reviews it and, if they change anything, writes the reason. Head office sees all proposals and changes, and approves transfers and purchases.
The system reads stock by store from your ERP or point-of-sale system (Odoo, Microsoft Dynamics 365 Business Central, Sage, Holded, SAP Business One, Shopify or an Excel per store) with a read-only user. The approved list returns as transfer orders. See the AI assistant for ERP for how questions about stock are answered.
What data is needed, and when is it not a fit?
Sales by product and store with date, current stock of each store, and movements: receipts, transfers and stock adjustments. If each store keeps its own spreadsheet, we unify them in the first review. With that, stock of each store is rebuilt day by day and your last months are replayed: what the system would have allocated and transferred against what you did. This is the simulation with your data.
It is not a fit for two shops on the same street that call each other across the road, or for chains whose stores carry different catalogues that cannot be transferred. Nor without recorded sales per store: then the first job is to start recording them.
Frequently asked questions
How does it choose between a transfer and a supplier order?
It compares both in money. A transfer costs the trip and the time to pack in the sending store, and only makes sense if that store will not miss the units before its next replenishment. A supplier order costs the purchase and the lead time. If a route already passes both stores, the transfer almost always wins.
We have no central warehouse. Does it still work?
Yes. The system prepares a proposal per store and groups them by supplier to reach minimum order values or freight thresholds. Transfers matter more in this case, because they are the only way to correct a split without waiting for the supplier.
Stock in my ERP does not match what is in the store. Is that a problem?
It is normal, and one of the first things the review shows. With sales, receipts and counts you can see in which stores and products the gap builds up. The manager then gets a short list of products worth counting, and each count corrects stock and improves the forecast.
How do you split a new collection that has no sales history?
With the sales of similar products in earlier seasons in each store: same family, same price range. Part of the delivery is kept at the warehouse. After two or three weeks, when it is clear which stores sell faster, the reserve goes to them instead of triggering transfers.
Our stores are in different cities. Can transfers still be proposed?
Yes, provided there is a way to move the product and its cost is entered. The system only suggests a transfer when the gain at the destination exceeds that cost. Within a city transfers usually pay off easily; between cities, only for higher-value items or when a stock-out is imminent.
From how many stores does it make sense?
With three stores sharing a catalogue there are already transfers nobody sees. It pays most when there is seasonality, sizes or formats, and someone spends hours each week allocating stock or phoning stores. With two stores on the same street it probably does not, and we will say so.