Ask a distribution business how it decides what to reorder and you will get several answers, because different parts of the catalogue genuinely work differently. Fast movers with steady demand need one rule. Items ordered against confirmed customer demand need another. A seasonal or trending line needs a third.
Software that offers one replenishment algorithm forces all of that into a single shape, and the usual outcome is that buyers override it constantly — at which point it is a suggestion engine nobody uses.
We ship three, plus templates, and they share one property that matters more than any of them: every line they produce carries its own arithmetic.
The three engines
Minimum stock level. The simplest useful rule: when the position falls below a threshold, propose bringing it back up. Insensitive to trend, robust to noisy data, and correct for the long tail of items where sophistication would be false precision.
Replenish. Order against what is actually committed — back orders and demand already recorded — rather than against a projection. Suited to items you do not want to speculate on.
Forecasting. Min/max replenishment with full pipeline netting: project the position forward using average consumption and lead time, subtract everything already inbound and everything already committed, and propose the difference. This is the engine for items where cover matters and where getting it wrong is expensive in both directions.
Templates sit alongside — a saved configuration that spawns a fresh dated run, which is what makes scheduled generation practical.
Netting is where implementations succeed or fail
Every engine reads the same position, and the position is not "stock on hand". It is:
- stock on hand
- plus in-transit shipments
- plus quantities on pending purchase orders
- minus open requisitions
- minus unfulfilled sales orders
Omit the incoming terms and the system over-orders systematically — it cannot see the stock already on its way. Omit the committed terms and it under-orders, because it counts stock that is already spoken for. Most disappointing replenishment projects are one of those two omissions, repeated a few hundred times a month.
Classification decides which items an engine touches
A run can include or exclude items by ABC class and by fast, slow or non-moving status. That sounds like a filter; it is really the policy layer.
It lets a business say: forecast the A-class fast movers weekly, run minimum-stock on the C-class tail monthly, and never auto-propose anything for non-moving items — because for those the question is liquidation, not replenishment. Without classification-aware runs, you either apply the sophisticated engine to items that do not deserve it, or the crude one to items that do.
The part we would build first if we started again
Every suggested line is written with its own inputs attached: projected quantity, quantity available, pending shipment quantity, pending purchase-order quantity, pending requisition quantity, pending sales-order quantity, lead time and average consumption.
This is not logging. It is the feature that makes the rest usable, for three reasons.
A buyer can accept in bulk. Reviewing 200 suggested lines is only possible if spotting the wrong one is fast. With inputs visible, an experienced buyer scans for the implausible assumption — a lead time that is stale, a consumption rate distorted by a promotion — instead of re-deriving each number.
Disagreement becomes diagnosis. When a buyer overrides a suggestion, the visible inputs turn "the system is wrong" into "the lead time says 14 days and it has been 21 since March". One of those is a complaint; the other is a fix.
It survives the handover. Six months later, nobody remembers why an order was for 240 units. The line still says.
The limitation to plan around
The netting is exact; the parameters these three engines read are not. Average consumption, lead time and ABC/FSN class are held as item attributes, and everything the rules-based engines compute inherits their quality.
Stated plainly, that means a scheduled parameter review is part of running these engines well — and it is also why the inputs are printed on the line rather than hidden. An engine working from supplied parameters should at least make it obvious which one is wrong.
Where demand is worth modelling rather than assuming, that is a different tool: statistical and machine-learning demand forecasting derive demand from historical sales, inventory movement patterns and seasonal variation, instead of reading a maintained average. The three engines here remain the right answer for the long tail, where the arithmetic is transparent and the sophistication would be false precision.
What we would tell another team
Do not ship one replenishment algorithm and a settings page. Ship the two or three rules your customers actually use, let classification decide which applies where, and spend the remaining effort on making every suggested number explain itself.
The measure of success is not suggestion accuracy in a backtest. It is whether a buyer will accept a screen of them without checking each one by hand — and that is a trust problem solved by transparency, not by a better forecast.
Related: How suggested order quantity works · Reorder point · xMatix Procurement