Reducing Food Waste with AI: Forecasting and Markdown

Write-offs and markdowns quietly eat into margin, while the shelf empties by evening. We build turnkey demand forecasting systems: the model predicts sales for each SKU and suggests the markdown timing. Food waste reduction is achieved through accurate ordering and timely markdowns.
Frequently Asked Questions

Reducing food waste: where the current forecast breaks

Write-offs of perishable goods grow not where they are sought. Logistics is usually fine — goods arrive on time and in the right volume.

What breaks is the retail demand forecast: it calculates average sales for the product as a whole and does not account for the fact that batches on the shelf have different shelf-life dates.

For the accounting system, stock is one number per SKU. How many units will survive until the end of the week, and how many will go to markdown in two days, is not visible from it, and the purchase order is built from the total number.

A forecast that does not distinguish batches by dates physically cannot decide what to sell first and in what order — part of the shelf is guaranteed not to sell before expiry.

A separate layer is promo and local demand spikes. A promotion at one store lifts sales, the average forecast does not anticipate it and orders with a buffer; at another store a spike sweeps the shelf in a day, and the truck with goods is already en route. Stock built "just in case" settles in the warehouse and on the shelf.

Then the chain kicks in: goods approach expiry, they are marked down before expiration to recover at least part of the value, and what was not bought even at markdown goes to write-off. An empty shelf at the moment of demand loses revenue that cannot be recovered. Let's break down how this is closed.

Forecast effect: less markdown, fewer write-offs, full shelf

We calculate metrics at the same granularity — day, store, SKU, batch — otherwise a before/after comparison proves anything.

We verify item master data and shelf-life dates against the GS1 marking standard, pull stock from the accounting system, and take promo and supplies from the promo calendar. Without batch binding, the forecast cannot be distinguished from average shelf consumption.

Metric How we calculate What we consider a working result
Demand forecast accuracy weighted error by category, horizon 1-7 days for perishables, error stays within 15-20%
Category write-off share written-off volume to delivered volume, by store reduction by 1.5-2x per season
Lost sales share of hours with zero stock amid live demand zero for top SKUs, decline for the rest
Inventory turnover turnover to average stock by category growth without growth in write-offs — otherwise it is not a result
Markdown of perishables share of goods that went to markdown shift of markdown to the first hours of shelf life

Forecast accuracy is easily "improved" by averaging — and then the write-off share falls not because purchasing became more accurate, but because the goods simply were not delivered.

Therefore we read metrics only in pairs: forecast error plus lost sales on the downside and markdown on the upside. If write-offs fell and zero stock grew, the model did not learn to forecast demand — it learned to save shelf space.

Turnover is an aggregate indicator: it grows both when stock was reduced reasonably and when the shelf was emptied.

Hence the order of review: first we check markdown for perishables, then turnover by categories with the largest write-off share, and only then look at forecast accuracy. This shows where the effect came from demand forecasting and where from a change in display rules.

Comparison of approaches: shelf-life rules, statistics, machine learning

Expert rules, statistics and machine learning solve one task — understand how many units of goods will sell before expiry — but they transfer error differently.

Rules are predictable and easily verified, statistics catches seasonality and promo, a trained model accounts for dozens of weak signals. The choice is determined not by "progressiveness" but by the volume of history and the cost of error in the category.

Approach When appropriate Limitations
Expert shelf-life rules Narrow assortment, smooth demand, short shelf life Does not see seasonality and promo; markdown thresholds are edited manually when the assortment changes
Time series forecasting Regular sales, two or more seasons of history, category demand Breaks on promotions and assortment changes; separate model per SKU
Machine learning Thousands of SKUs, sparse demand, many signals Needs clean data and regular retraining; error is not visible without monitoring
Hybrid forecasting approach Assortment grows, rules no longer cope More expensive to launch: need to separate where rules override the model

The demand forecast model gives expected stock on a date, and automatic markdown rules keep the threshold and discount step deterministic — the decision remains explainable for the category manager.

They usually start with one reference category: measure the write-off share and forecast accuracy, and only then transfer the logic to the rest of the assortment.

Step-by-step implementation: from data audit to handover of regulations

The order of work is structured so that each next stage relies on the verified previous one: first we make sure that sales and supply history is suitable for calculation, and only then do we calculate anything.

Otherwise the model trains on patchy data and produces beautiful numbers that do not match the shelf in the store.

  1. Audit of sales and supply data. We check history for each store: we find gaps in write-offs, discrepancies between receiving and sales, duplicates, double-counted promotions. We determine the period over which data is sufficient for training and record which features are missing.

  2. Designing the calculation scheme. We choose the forecast horizon, the level of granularity — store, SKU, day — and thresholds after which stock goes to markdown. At this step the customer sees the logic before it becomes code.

  3. Training the demand forecast model. The model accounts for seasonality, promo, holidays and local demand of a specific store. We calculate perishables and long-shelf-life goods separately — they have a different cost of error.

  4. Backtesting the model on past periods. We run it on closed weeks and compare with actuals, separately analyze promo and anomaly days. A model that does not beat the current write-off rule does not go into production.

  5. Pilot in several stores. We place control and experimental stores of different formats side by side to separate the model effect from seasonal fluctuations. During the pilot we also calibrate markdown thresholds to actual customer behavior.

  6. Regulation for working with stock. We describe who and when confirms markdown, what to do when actual deviates from the forecast, and how to feed feedback back into the model. Shift staff receive a short instruction, not a fifty-page document.

  7. Handover and support of the first cycles. For the first weeks after launch engineers stay in touch: they monitor discrepancies, adjust settings and hand over an analysis of typical situations to the customer's team.

Project artifacts: data schemes, markdown rules, regulations

A project is considered delivered not at the moment of dashboard demonstration, but when stock decisions can be made without our participation.

Therefore the customer's environment receives not a "model in a container" but a kit that a new engineer or category manager can use to understand the calculation logic and change it without rewriting the entire system.

  • Data flow scheme — where sales, warehouse stock, shelf-life dates and supplies come from, at what frequency, in what dimensions, and what happens to an SKU if the export does not arrive on time.
  • Demand forecast model documentation — which features are used, over what horizon demand is calculated, which categories the model understands worse and why, how retraining is launched on new data.
  • Markdown trigger rules — thresholds by stock and remaining shelf life, discount step, priority between similar SKUs, conditions under which the system does not reduce the price but hands the decision to a human.
  • Stock handling regulation — who and at what time of day confirms markdown, how to act when forecast and actual diverge, where a disputed case is escalated on weekends.
  • Forecast quality monitoring — share of SKUs with error above the allowable level, forecast bias by category, alerts when accuracy drops or demand behavior changes.
  • Instructions for category managers — short scenarios for each type of situation and an analysis of typical errors during manual adjustment.
  • Rollback plan — how to return to the previous version of rules in one step or switch a category to manual mode.

Case study: how a retail chain reduced perishable write-offs

Before implementation

Perishable categories were ordered by average sales from previous weeks, and stock was checked manually: a merchandiser walked the store and marked down anything that looked not fresh.

Neither the weekday profile, nor weather, nor the promo calendar participated in the calculation — some batches went to markdown on the first day, and during the evening peak the shelf emptied.

Write-offs were considered inevitable, although half of them resulted not from demand but from rough order rounding.

What was changed and what resulted

The forecast was built at the "SKU — store — day" level with a horizon equal to batch shelf life: batch data and planograms were taken from Blue Yonder, sales — from POS data.

The markdown rule became probabilistic: if the sales forecast until expiry is below stock with a given probability, the system triggers markdown in advance, not on the last day, and simultaneously blocks reorder.

Safety stock is recalculated every night from actual forecast error, not from a fixed number of days of cover.

The pilot ran in forty stores of one region, rollout went in waves by clusters — comparison was held with a control group.

  • Write-offs of perishable goods — minus 31% in comparable stores.
  • Lost sales due to an empty shelf — halved.
  • Average forecast error over a one-to-three-day horizon — from 34% to 17%.
  • Share of marked-down goods sold before expiry — from 68% to 91%.

Recalculation runs at night, so the morning order is refined by actual sales of the previous day.

How does a neural network forecast differ from shelf-life rules?

Stock rotation rules answer one question: what to display and write off first. The logic "first out is what expires earliest" brings order to the shelf, but says nothing about whether the remaining stock will sell in time.

Thresholds like "a few days before expiration — markdown" hold the situation while demand is smooth and repeats by calendar.

A neural network demand forecast calculates not order but probability: how many units of a specific batch will sell by the expiry date. Input includes sales broken down by store, weekday and hour, promo calendar, weather, shelf-life and stock data for each batch.

The model builds local demand by store: a store near the metro and a store in a residential area differ both in customer profile and peak hours.

The difference shows where rules stop matching actuals. With a long shelf life and smooth sales, thresholds are enough — they are transparent and easily verified.

Short shelf life, promotions, heat or rain and different demand by store break averages: what looks normal for the chain turns into expired goods or an empty shelf at an individual store.

The practical effect is the reaction window. The rule triggers after the fact, when only a few days remain until expiry, and the choice comes down to markdown.

The forecast gives lead time to redistribute a batch between stores and early markdown, so the write-off share decreases without increasing shelf shortages.

Common technical questions about demand forecasting

Demand forecasting breaks not on the model but on data and at the interface with inventory accounting. Below are questions the customer's technical team asks before the start, and short substantive answers.

Where does data come from if accounting is inconsistent?

We pull sales history and stock from the accounting system — often 1C with an industry-specific configuration — and reconcile by warehouses and stores.

We sort out write-offs, returns and mix-ups before the start: if markdown is not separated from sales, the model learns on a distorted picture, and underforecasting later cannot be distinguished from a real demand drop. We close gaps at export, not inside the forecast.

How often is the forecast recalculated?

The base cycle is daily, before store opening: by that time previous day's sales and current stock are pulled. For perishables we add intraday recalculation based on first-half-of-day actual sales.

Horizon is from one day to two weeks: beyond that accuracy falls faster than the procurement benefit grows.

What about new items without history and how often to retrain the model?

A new item relies not on its own series but on similar SKUs: category, brand, price segment, seasonality. After 4-6 weeks of actual sales it switches to its own history.

Retraining runs on schedule — once every one to two weeks, plus an off-cycle launch when assortment or promo calendar changes. Each launch is run on a holdout period: if quality drops, the previous model version remains.

Let's discuss the task: where to start forecasting in your chain

Demand forecasting rests not on the model but on data: sales history by SKU, stock, shelf-life dates, promo and supply calendar.

Therefore we start with an assessment of the customer's data — we look at what already accumulates in the accounting system, at what frequency, and whether the history is enough for the forecast to be stable rather than random.

To discuss a forecasting task, it is enough to answer a few questions — this will be enough to estimate the scope of work and assemble a pilot forecasting project on real data, not on a demo dataset.

  • Export of sales and stock by day, stores and SKUs — at least for one category over several seasons.
  • Data on batches and shelf-life dates: they determine when the forecast turns into markdown rather than write-off.
  • Calendar of promos, holidays and supply schedule — without it the model explains past demand, not future.
  • Current markdown rules and warehouse constraints: what cannot be changed in processes, which thresholds already apply.
  • Your success criteria — share of written-off stock, forecast accuracy by category, markdown depth.

After the conversation we will come back with a forecast work plan: stages, pilot scope, list of data exports, acceptance criteria and procedure for returning to the current markdown rule if the result is not confirmed. Describe the task — we will come back with an estimate and plan.

AI Development Areas

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1394
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1368
  • B2B Advance company logo design
    B2B Advance company logo design
    815
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1139
  • AIDER company logo development
    AIDER company logo development
    1057
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1152