Replenishment planning that survives contact

What replenishment planning is

Replenishment planning is the work of deciding what to order, when to order it, and how much, for every item at every location, on a repeating cycle. It sits downstream of forecasting and upstream of purchasing: the forecast says what will sell, replenishment planning says what to do about it, and the purchase order is the artifact that leaves the building.

It is the least glamorous link in the retail supply chain and the one that absorbs the errors made everywhere else. A forecast that is 15% high does not announce itself as a forecast problem. It announces itself six weeks later as overstock in eleven stores, and by then it looks like a replenishment problem to everyone looking at it.

This page is about the arithmetic, the four inputs that reliably break it, and how to tell which one broke without guessing.

The core arithmetic

Every replenishment method in commercial use is a variation on one calculation. Strip the vendor language away and you get:

Order quantity = target position - current position

Where the target position is what you want on hand and inbound when the next delivery lands, and the current position is what you already have and have already ordered. Both halves are where it goes wrong.

The target position is usually built as:

And the current position is:

On hand + on order - committed

The single most common defect in a replenishment process is dropping the "on order" term. A system that compares on-hand against target, without subtracting what is already inbound, will recommend an order that has already been placed. It does this quietly, every cycle, and the resulting over-ordering looks like poor forecasting rather than a missing term in an equation. This is covered in more depth in how to prevent over-ordering in retail, and it is worth checking before anything else on this list.

A worked cycle

Take one item at Sunrise Market, an illustrative operator, on a weekly delivery with a four-day lead time. All figures below are constructed to show the mechanics.

Target position covers the cycle plus the lead time plus safety stock:

• Cycle demand: 40 units
• Lead-time demand: 40 times 4/7, about 23 units
• Safety stock: 14 units
• Target position: 77 units

Current position is 22 on hand plus 24 on order, so 46 units.

Order quantity: 77 minus 46, so 31 units.

Now drop the on-order term, which is the defect described above. Current position reads as 22, and the system asks for 55 units instead of 31. Twenty four extra units arrive, roughly a further six-tenths of a week of cover on an item selling 40 a week. Repeat that across a few hundred items and the result is a store that is over-covered without a single person having made a visible mistake.

The four inputs that break it

In practice, replenishment planning fails for one of four reasons, and they have different fixes. Diagnosing which one is running is most of the work.

1. The forecast is wrong

The obvious one, and usually not the binding constraint. A forecast is wrong by some amount always; the question is whether it is wrong in a biased direction. A 20% error that alternates high and low is absorbed by safety stock. A 6% error that is high every single week builds inventory relentlessly and never triggers an exception, because no individual week looks bad.

This is why bias belongs next to accuracy in every forecast review, and why measuring forecast accuracy with a single error metric is not enough to protect a replenishment process.

2. The on-hand number is wrong

Perpetual inventory drifts, and it drifts unevenly. Theft, damage, receiving errors, unscanned sales and mis-keyed adjustments all push the recorded balance away from the physical one, and the error concentrates by store and by cause rather than spreading evenly.

The consequence for replenishment is direct: the current position term is wrong, so the order quantity is wrong, and no improvement in forecasting touches it. Worse, the failure is self-sustaining. An item recorded as having stock it does not have will not be reordered, will sell nothing, and will therefore look like an item with no demand.

Three signatures find most of it without a physical count:

• Negative on hand, which is unambiguous and always an error
• Zero on hand with continued sales, which means the balance is understated
• Stock on hand with no movement against that item's own normal cadence at that store

Each produces a worklist rather than an accuracy percentage, which matters because a worklist can be actioned today. This is the substance of store-level inventory visibility.

3. Lead time is treated as a constant

Lead time is entered once at setup and then treated as fact for years. In reality it varies by supplier, by season, by day of week, and by whether the item is on allocation. A supplier whose stated lead time is four days but whose actual delivery lands between four and nine days is not a four-day supplier for planning purposes, because safety stock has to cover the spread rather than the average.

The fix is unglamorous: measure realised lead time from your own receiving records rather than trusting the master data field, and set safety stock against the observed variability.

4. Supplier minimums exceed the rate of sale

This is the one that is not a mistake at all, and it is regularly recorded as one. When a supplier's minimum order quantity exceeds what a store sells in a reasonable cover window, that item cannot be ordered correctly by anyone. The system will recommend the minimum, the store will be over-covered, and an exception report will flag the store.

An item selling three units a week with a case pack of twenty four is eight weeks of cover on a single order. That is a purchasing-terms problem to take into a supplier negotiation, and labelling it a store execution failure generates noise that trains teams to dismiss the whole list. Identifying these items separately is one of the highest-return things a replenishment review can do, because the count is usually larger than anyone expects.

Items with no history

Every replenishment method above assumes a demand history to plan against. New items have none, and they are simultaneously the items where being wrong is most visible: a launch that goes out of stock in week two loses the distribution it was granted, and a launch that over-ships fills the backroom with product nobody has decided they want yet.

There is no way to forecast a new item accurately, and pretending otherwise is where most launch plans go wrong. What works instead is planning for a short first cycle and a fast correction:

• Seed on an analogue, chosen deliberately. The nearest existing item by pack size, price point and shelf position beats an average of the category, and beats a number supplied by the brand team.
• Order the minimum viable presentation for the first cycle rather than a confident quantity. Being under is recoverable in one delivery. Being over takes a season.
• Compress the review. A new item deserves a look after one week, not after the four weeks a settled item gets, because the first real read is the only information anyone has.
• Set the switchover point in advance: the week at which the item stops being planned on its analogue and starts being planned on its own history. Eight to twelve weeks is common, and leaving it undefined means it never happens.

The same logic covers items returning from a long gap, seasonal sets, and any item whose distribution changed enough that its own history no longer describes its current situation.

How often to replan

Cycle frequency is a real decision and is usually inherited rather than chosen. Replanning more often is not free: each cycle consumes review attention, and a process that regenerates every parameter weekly produces recommendations that churn for reasons nobody can trace.

A workable split separates what changes fast from what changes slowly:

Recomputing safety stock every week against the last few weeks of variability is a common and self-defeating configuration: it raises safety stock right after a volatile period, which is usually just after the volatility has passed.

Push, pull, and who is actually deciding

Two structures dominate, and a great many arguments about replenishment are really arguments about which one is in force.

Most chains run a hybrid without describing it as one: pull for established items, push for launches, promotions and seasonal sets. Problems concentrate at the seam. An item that has just come off a promotional push and reverts to pull carries an inflated recent history, and the pull logic reads promotional volume as baseline demand. The first reorder after a promotion is consequently one of the most reliably wrong orders in the entire cycle.

Where Scout fits

Scout is the analytics layer over this process, not the system that runs it. It reads your POS, receiving and on-order data at store and item grain and tells you which of the four failures above is actually operating: whether the tail of the weeks-of-supply distribution is being driven by forecast bias, by drifting on-hand balances, by lead-time variability, or by minimum-bound items that were never orderable at the right quantity.

The boundary is worth stating plainly, and it moved. Scout can hold the inventory balance and execute a transfer. What it does not do is raise or transmit a purchase order, hold an order guide, or carry supplier EDI: your purchasing system keeps doing that. Scout is what tells you it is doing the wrong thing, and which of the four reasons is why.

The short version

• Replenishment planning is target position minus current position, applied per item per location on a cycle. Everything else is a variation on that.
• Dropping the on-order term is the most common structural defect, and it over-orders quietly rather than visibly.
• Four inputs break it: forecast bias, drifting on-hand, lead time treated as constant, and supplier minimums above the rate of sale.
• Bias matters more than error size, because a small consistent bias never trips an exception and compounds every cycle.
• Minimum-bound items are a purchasing-terms problem, not a store failure, and mislabelling them discredits the whole exception report.
• The first reorder after a promotion is structurally the most likely to be wrong, because promotional volume enters the baseline.