You have a SKU that runs out two or three times a year. Every time, you top it up, tell yourself the next batch will hold, and move on. It never does. The gaps get a little closer together. The order quantities your system suggests get a little smaller, which feels wrong, but you trust the math.
The math is the problem. The formula is fine. The data you're feeding it is wrong.
Your reorder point and your forecast both run on one number: average daily demand. On any SKU that has ever been out of stock, that number is too low. Not by a rounding error either. It's low enough to keep the SKU running out, and to make your system recommend you order less each time it happens.
This is from an Australian operator with an 800-SKU Cin7 Core business. We watched this loop run for the better part of a year before we understood it. Once you see it, you can't unsee it.
Sales are not demand
Almost every reorder calculation buries one assumption: that the units you sold are the units customers wanted.
They aren't. You can only ever sell what was on the shelf. The day a SKU hits zero, demand doesn't stop. Customers still arrive and still try to buy, and they can't. That demand never lands in your sales history. It's gone, uncounted.
Statisticians call this censored demand. The plain version: your sales data is capped by your own availability. Sales are always less than or equal to true demand, and the gap is exactly the part you most need to see, the demand during the periods you ran out.
Now follow what your forecast does with it. A SKU sells 30 units a month. One month it runs out on day 20 and stays out for the last 10 days. It sells 20 units that month instead of 30. Next time the forecast recalculates average daily demand, it divides those 20 units across all 30 days of the month: 0.67 units per day. The real rate, across the 20 days the SKU was actually on the shelf, was 1.0 unit per day.
The forecast just learned that this SKU is a third weaker than it is. So it lowers the three-month forward forecast. The reorder point drops with it, and so does the suggested order quantity. You order less. You carry less cover. The next ordinary demand week tips it into stockout sooner, and that stockout teaches the system to order less again.
That's the loop. Each stockout makes the next one more likely, and the math does it quietly, while looking entirely reasonable.
Why this hits your best SKUs hardest
You'd expect this to bite the slow movers. It's the opposite.
Your fastest SKUs are the ones that actually run out. High velocity, tight cover, first to go when a supplier slips or a promotion lands. So they're the ones accumulating censored months. The dead stock at the bottom of your range never stocks out, so its demand signal stays clean. The bestseller that pays your rent is the one your forecast is steadily underestimating.
It compounds with seasonality, too. A SKU that runs out in its December peak doesn't just lose those December sales. If the censored month feeds your seasonal profile, December starts to look like a weaker month than it is, so next year's reorder timing under-prepares for the exact peak that caused the problem. The system learns the wrong shape of the year from the one month it most needed to get right.
None of this shows up as an error. Cin7 Core recorded every sale faithfully. The forecast did its arithmetic correctly. The fault is in the unstated assumption that 20 units sold means 20 units wanted.
Every reorder formula assumes sales equal demand. That assumption only breaks when you're out of stock, which is exactly when it matters, because that's when the formula quietly teaches itself to order less.
The fix: divide by the days you were actually selling
The correction is not complicated. Stop dividing by calendar days. Divide by available days.
Take the same SKU: 20 units sold, out of stock for 10 of the 30 days. Don't divide 20 by 30 and call it 0.67 a day. Divide 20 by the 20 days the SKU was genuinely available to sell. That's 1.0 a day, your real demand rate. Then project it across the full period for forecasting and reorder math.
demand rate = units sold ÷ days actually in stock 20 ÷ 20 = 1.0 unit/day correct 20 ÷ 30 = 0.67 unit/day what the system sees
The inputs you need are already in your system, or close to it:
- Units sold per SKU per month. Straight from sales history.
- Days out of stock per SKU per month. This is the one most operators don't track. You need a record of when each SKU dropped to (or below) its buffer and when it recovered.
With those two numbers, every censored month can be uncensored: replace the calendar divisor with the available-days divisor, and the demand rate snaps back to the truth. Do it at the monthly level and feed the corrected figures into both the forward forecast and the seasonal profile, so a stocked-out December stops dragging down next December.
This is the part of the engine we care most about, and it's why we built out-of-stock tracking before we built anything clever on top of it. Stocura stamps an out-of-stock-since date the moment a SKU crosses below its buffer. It keeps a rolling 90-day count of days out of stock per SKU, and subtracts those days from the divisor in both the reorder math and the seasonal indices. The reorder engine and the forecast both run on demand, not on censored sales. It's the single biggest reason our numbers diverge from what the inventory system suggests on its own, and on a fast SKU that's stocked out a few times, the gap is routinely 20 to 40 percent.
What you can do this week, without new tooling
You can test whether this loop is running in your own data in about an hour.
Step one: find the tell. Pick five SKUs that stocked out in the last 90 days. For each, look at the suggested order quantity or reorder point your system shows now, versus before the stockout. If it went down after the SKU ran out, the censoring is biting. A SKU shouldn't earn a smaller reorder point by failing to be available.
Step two: recompute one by hand. Take one of those SKUs. Pull its units sold for each of the last three months, and your best estimate of how many days it was out of stock in each. Recompute average daily demand using available days instead of calendar days. Compare to the figure your system is using. The corrected number is almost always higher, often by a third or more on a SKU that ran out mid-month.
Step three: start logging out-of-stock days. Even a simple column is enough: the date each SKU drops to zero (or to buffer) and the date it recovers. You can't uncensor demand you didn't record. Once you have a few months of out-of-stock dates, the correction above becomes routine instead of archaeological.
If you do nothing else, do step one. It takes ten minutes and it tells you whether your reorder math has been quietly teaching itself to under-order your best products.
Where this leaves you
A stockout isn't a one-off event you recover from. Left uncorrected, it's the wrong lesson your forecast learns, and it acts on that lesson the next time it recommends a quantity. The SKU that keeps running out isn't unlucky. It's caught in a loop where running out makes the system order less, which makes it run out sooner.
Break the loop in one place. Count demand over the days you could actually sell, not the days on the calendar. The forecast, the reorder point and the seasonal shape all get more honest the moment you do.
Stop reordering on gut feel.
Stocura calculates reorder points for every SKU based on your lead times, demand, and seasonality — and corrects for the days you were out of stock, so a stockout never quietly lowers your numbers. Free during beta.
Request beta access