This is a retail & fmcg problem we approach through our Data to Data service line.
The problem
Reordering in most multi-site food and retail businesses is a person, a clipboard and a memory. The Friday order is last Friday’s order, adjusted by whatever the manager remembers about the weekend. New staff order badly for months because the knowledge is in someone’s head, and that someone is on leave.
The two failure modes look like opposites. A stock-out is an empty shelf, a missed sale and a customer who found it somewhere else. Over-ordering is stock that sits, ties up cash, and — for anything with a date on it — ends in the bin. Operationally they get owned by different people and argued about in different meetings.
They are the same problem. Both are a gap between what was ordered and what actually sells, and the record of what actually sells has been sitting in the point of sale the whole time, unread.
Why it’s hard
The signal is per SKU, per site, per day — and most reporting isn’t. A weekly sales total says nothing about the mid-week gap that cost you the weekend trade. Averaging across sites hides that one store sells through a line in two days while another bins half of it. Reordering decisions live at a granularity most retail reporting was never built to reach.
Stock-outs poison the sales history that forecasting depends on. A day of zero sales because the shelf was empty looks identical, in the data, to a day of zero demand. Forecast naively from that history and the model learns to under-order the lines you already under-order — the system confirms the mistake that produced its training data. Correcting for censored demand is the part of this problem that separates a forecast from a moving average.
Wastage is usually not data. What was thrown away, when, and why — spoiled, damaged, prepped and unsold — is the other half of the reorder equation, and in most operations it exists as a monthly shrinkage variance, not as records. You cannot balance over-ordering against stock-outs if only one side of the scale is measured.
Lead times and shelf life turn a forecast into a constraint problem. Knowing tomorrow’s demand is not the decision. The decision is how much to order today given the supplier’s lead time, the case size, the shelf life remaining when it lands, and what is already in transit. A forecast without those constraints attached recommends quantities nobody can act on.
How we approach it
Ingest daily, at transaction level. POS transactions, goods received and wastage flow in daily. Where the point of sale is AmshPOS — our own platform, built to track orders through to fulfilment and to capture wastage at the till — that capture is native. Where it is someone else’s POS, this is a data engineering job first: extract, normalise across sites, and make the feed reliable enough to make decisions on. We treat the pipeline as the product, because a forecast on a flaky feed is a liability with decimal places.
Forecast sales velocity per SKU, with censoring handled. Each line’s velocity is modelled from its own history — day-of-week shape, seasonality, promotion effects — with stock-out days treated as censored demand rather than zero demand. This is the same discipline as the perishable-goods pricing platform we built, where input cost and price forecasts ran at better than 90% accuracy against outcome across a catalogue of more than 100 SKUs.
Recommend reorders, with the reasoning attached. The output is a quantity per SKU per order cycle, derived from forecast velocity, stock on hand, stock in transit, lead time and shelf life — shown with those inputs visible, so the person committing the order can see why. A recommendation someone can interrogate gets used; a black box gets ignored by week three.
What we do not do. We do not auto-commit orders to suppliers by default, and we do not forecast lines with no history — a new product gets a stated assumption from its nearest analogue, flagged as such, not a fabricated confidence. And we would not start with the model: if wastage is not being recorded, the first weeks of the engagement are about capture, because tuning a forecast against half the data is decoration.
What it takes
Transaction-level POS data, extractable daily. From AmshPOS this is built in. From an incumbent POS it means an export or API per site, and discovering which sites’ data is trustworthy is usually the first finding of the project.
Wastage capture where the waste happens. At the till, in the kitchen, at receiving. This is a workflow change before it is a data feed, and it needs a manager who cares, because staff record what someone checks.
Supplier facts written down. Lead times, order cycles, case sizes, minimum orders. This inventory usually exists in heads and email threads; the model needs it as data.
A few order cycles of patience. Recommendations run alongside the current process first, and the comparison — recommended versus ordered versus sold versus binned — is what earns the switch. That parallel period is the evidence, not a delay.
Where this has been done
Two references stand behind this page, and they are different kinds. The forecasting layer is delivered work: the perishable-goods pricing and forecasting platform in the linked case study ingested daily sales, inventory and wastage data and ran input cost and price forecasts at better than 90% accuracy across 100+ SKUs, for a manufacturer we do not name. The capture layer is our own product: AmshPOS, our cloud point of sale, is built to track orders and log wastage at source — named here because it is ours. What we have not done is deploy the two together for a named retail estate, and this page does not claim that.