Use case · Updated August 26, 2026
Inventory across stores: why the same product is overstocked and out of stock at the same time
In a multi-store chain, the sale you lost today often has its fix sitting in another store. This use case explains why your total inventory count can't show you that, the four traps that make a transfer recommendation go wrong, and what has to be in place before you can trust one.
This is a real-world use case, and it's not the only thing we do. It comes from a system we built inside a real company, and it runs in production today. We chose this process because the cash it leaves sitting idle is easy to measure, but the method is the same for payments, purchasing, invoicing, or any other process that leaves data behind: find where the money is leaking out, then automate the control.
The total is the least useful number
Almost every ERP answers "how many units of this product do I have?" just fine. The problem is that's not the question that moves money.
A product with twenty units across the chain can be losing sales every day: if all twenty are in the store where nobody asks for it, and the store where it sells has zero, the total says you're well stocked while the register says otherwise. The question that matters isn't how much you have, but where what you have sits relative to where it sells.
In a chain, inventory isn't a quantity. It's a distribution, and a bad distribution looks identical to a good one if all you look at is the total.
The four traps
1. Looking at the product instead of the variant
Inventory rolled up by product hides the most common problem in apparel. Ten units of a garment sounds like plenty, but if they're ten of the size that sells least and zero of the one that sells, the store is effectively out of stock, and no dashboard will show it.
The control has to work at the level where the sale actually happens, which is product, color, and size. It's more data work, and it's the difference between catching something and catching nothing.
2. Confusing "I don't have it" with "I'm short"
Having zero units of something isn't a problem in itself. A store may not carry a product simply because it doesn't sell there, and shipping it inventory would mean moving money from a place where it's working to a place where it just sits.
A real stockout needs both halves: no inventory and proven demand at that store. Without the second half, a stockout detector spits out a list so long nobody looks at it twice, and that's how these systems die.
3. Trusting inventory history without asking where it came from
This one is the hardest to see, and that's what makes it the most dangerous. Many ERPs keep current inventory and keep overwriting it, without saving a daily snapshot. When someone needs the history, it gets rebuilt backward: take today's inventory, add back sales and subtract receipts to infer what each previous day looked like.
That rebuilt history looks like data but it's a calculation, and it has a serious consequence: rebuilt inventory drops on the days there were sales, because it was derived from the sales. If you use it to confirm that a sale happened, you're not verifying anything. You're looking at the same information twice.
Before drawing conclusions from an inventory series, ask whether it's a snapshot saved that day or a calculation done afterward. If it's the second, it's fine for estimating trends, not for proving facts.
4. Recommending a transfer without counting what it costs
Moving inventory between stores has a cost: freight, staff to prep it, days in transit, and the risk that the item arrives after the season is over. A recommendation that ignores that will propose shipping two units 300 kilometers (about 190 miles) to capture a sale that may never happen.
For the list to be credible, every recommendation has to be able to say how much you can expect to recover by acting on it. And the ones that don't clear a reasonable bar are better left off entirely: a short list of moves that are worth it gets done, a long list of questionable ones gets ignored in its entirety.
What has to be in place
Saved inventory snapshots, not rebuilt ones. A daily record by store and variant, even if it only starts the day the system is connected. Without it, everything said about the past is inference.
Demand measured by store, not a chain average. The same product behaves differently at each location, and deciding on the chain average hides exactly what you're looking for.
A value threshold for each recommendation. The system proposes what moves money and stays quiet about the rest.
The recommendation goes to the person who decides. A dashboard you have to go open gets opened for the first two weeks. The recommendation has to arrive on its own, to someone who can say yes, with the answer one tap away.
A "no" is information too
When the decision-maker turns down a recommendation, there's usually a reason the system couldn't have known: that store is about to close for a remodel, the item was held back for a campaign, freight to that area costs a fortune.
If that reason gets lost, the system recommends the same thing the following week and the person stops responding. If it gets captured, the next list is better than the last one. The difference between a system that's still in use after six months and one that's abandoned after a month is usually right here, not in the quality of the algorithm.
Want to see how much cash you have sitting idle?
On a 20-minute call, we look at how your inventory is organized, whether your system keeps the daily snapshots this requires, and what can be measured with what already exists. Free, and no sales pitch.
And if this isn't your problem, the call is still worth it: we do the same work on payments, purchasing, invoicing, or any process that leaves data behind.
The measured results of this work, from a real case in production, are on the home page.