← Back to blog

Demand Planning Software Won't Fix Bad Velocity Data

cpg demand planning softwaredemand forecastingvelocity dataout of stockconstrained demandforecast accuracycpg

The forecast said 1,650 units a week, and by its own scorecard it was accurate. The shelf would have sold 1,800. The missing 150 never scanned, because the product was out of stock when the shopper reached for it, and Cinderhaven Provisions' demand planning software filed the empty shelf as slack demand. Across the eight SKUs that chronically run short, that reflex forfeits $240,000 in sales a year, one corner of a $410,000 hole no new planning tool would close.

Cinderhaven Provisions is a fictional company and its figures are a synthetic dataset built to show a cost that is entirely real: a forecast that reads an empty shelf as weak demand.

A forecast is a claim about demand, but the data under it is a record of sales, and the two diverge exactly where the shelf was empty. Constrained demand is what you can sell given real limits; unconstrained demand is what customers would buy on a full shelf. The correction for lost sales is a step models routinely skip, so forecasts systematically understate opportunity. Software does not add that step for you. It forecasts what it is fed, and what it is fed is the shortage.

The software forecasts sales, not demand

A demand planning system turns a SKU's sales history into a forward forecast, week by week, and it does that far better than a spreadsheet. Everything then depends on what that history actually records. Sales are what left the shelf; demand is what customers wanted to buy. The two match only when the shelf was full.

Every week a SKU stocks out, its scan line drops, and the model reads the drop as a demand signal rather than the supply failure it was. Feed it a year of those weeks and it learns that the SKU sells less than it does, which is the opposite of what forecasting is supposed to do for a small brand's cash.

The model is not wrong about the sales. It is wrong about the demand, and it cannot tell that it is.

A stockout teaches the forecast to order less

That is where the loop closes. The forecast underforecasts the SKU, the plan orders less of it, the SKU stocks out again, and the next forecast reads even lower. NielsenIQ put CPG retailers' 2021 stockout losses at 7.4 percent of sales, $82 billion of missed revenue; run that rate against true demand on Cinderhaven's eight chronically short SKUs and it stops being a rounding error.

| Cinderhaven's 8 chronic-stockout SKUs | Annual | |---|---| | Unconstrained demand (a full shelf) | $3.24M | | Lost to stockouts (modeled at NielsenIQ's 7.4%) | $240,000 | | Constrained scans the software trains on | $3.00M |

The $240,000 is demand that existed and did not transact. It never registers as a forecast error, because the forecast predicted the constrained number, actual sales, correctly, and was wrong only about the demand behind it. It registers instead as a SKU that looks like a slow mover, the same signal a retailer reads right before it uses velocity to delist the item. The forecast that undercounted the demand and the scorecard that drops the SKU are reading the same suppressed line.

Not every suppressed scan is a replenishment miss. Some come from authorization voids, stores where the item is authorized but not selling, whether it was never set or went dark after a shelf reset. Those sit outside the on-shelf availability numbers entirely, and they write the same misleading zero into the history. Whatever puts the zero there, the software reads it as a sale that never happened.

A clean accuracy score can hide an expensive bias

The dashboard shows none of it, because it measures the wrong thing well. A forecast accuracy score tells you how far each prediction landed from actual sales. It says nothing about direction. A model can be low-error and still lean the same way every week, and one that leans low on the SKUs that stock out and high on the ones that overstock posts a respectable number while it bleeds from both ends.

The high side has its own bill. Where the model over-corrects, or leaves last quarter's promotional lift sitting in the baseline, Cinderhaven builds inventory it then discounts to clear: about $110,000 a year in markdowns on SKUs the forecast overstates. The short side pays when a real spike arrives against a plan built too lean: roughly $60,000 in expedited freight to cover the demand the forecast swore would not come. Add the $240,000 in suppressed demand and the forecast's true cost is $410,000, none of it printed on the accuracy report.

An accurate forecast of the wrong demand is still an expensive forecast.

Correct the history before the software reads it

The fix lives in the history the model trains on, not in the tool that reads it. Mark the weeks a SKU stocked out, reconstruct what it would have sold on a full shelf, and replace the suppressed zeros before the model ever sees them. Void Finder does the distribution-gap half of that work, ranking the stores where an item is authorized and not selling so the lost demand can be counted instead of guessed. Feed the corrected series in, and the same software that underforecast starts forecasting the demand that was there the whole time.

No software knows what a shelf would have sold if it had been full. That number has to be reconstructed and written back into the history by someone who went looking for it. The tool forecasts what it is given; the job is making sure what it is given is true.

Hand me your ten worst stockouts

Hand me the ten SKUs that stock out most often, with a year of their scans and their forecasts. I rebuild what each one would have sold on a full shelf and set it against what the software predicted, and the distance between the two is the demand your planning tool has been trained to ignore. It is usually wider than the forecast error the tool reports. See the demand the shelf hid.