Why demand forecasting fails on real data
Demand forecasting breaks more often not on the algorithm but on the data.
A model trained on a clean history sees something different in a real export: days with zero stock, renamed items, duplicated positions after warehouse consolidation, broken series when the accounting system changes.
Forecast error grows even though the method has not changed—there is simply nothing to reconstruct demand from in such a history.
A separate class is irregular sales. A product sells several times a month: the median is zero with a large spread, and any averaging model produces either zeros or a flat "average" shelf that matches no single day.
Seasonality adds complexity: the annual cycle is reliably visible only across two or three full periods, and holiday peaks shift every year, so they cannot be tied to a calendar date.
Promotions, markdowns, new locations, and new items are events without history. The model mistakes a promotion spike for demand growth and transfers it into the baseline, after which the forecast remains inflated for several more weeks.
A new location has neither a seasonal profile nor local customer habits—here only transferring the profile from similar objects works.
The most invisible source of discrepancies is manual plan edits.
A planner adjusts the number based on market knowledge, but the edits are not saved as a separate layer, the model does not learn from them, and quality is measured against the already adjusted plan: the metric shows an accuracy that does not exist in reality. We explain how this is closed.
What the model delivers: effects in inventory and planning
The model forecasts not a single number for the entire network but a hierarchy: SKU—warehouse—week, with separate seasonal profiles for each group.
The point forecast is supplemented by quantile bounds, so the purchasing plan is built not from the "average" but from the service level you set yourself.
On the backtest period, average error stays in the range of 12–18% versus 30–40% for planning "from last month."
Hence the first measurable effect—inventory turnover. Warehouse excess appears where the planner over-insured: the model accounts for the contribution of promotions, holidays, and seasonality but does not inflate stock for items with stable demand. Safety stock is calculated from demand volatility and lead time, not "by eye."
On the other side, lost sales are closed: stockouts on fast-moving items are visible 2–4 weeks before the peak and enter the order before the shelf runs empty.
An ensemble of models on tabular features, such as LightGBM, is retrained on a schedule—demand shifts are picked up without rewriting rules manually.
The planning cycle compresses: instead of a week-long collection of data by department, the forecast and order recommendation are ready for the morning review.
Along with manual planning, a whole class of errors goes away—forgotten promotions, duplicate orders, different file versions among adjacent departments.
We verify forecast accuracy before launch: a backtest shows how the model would have performed in past seasons, and it enters the planning loop only after that.
Approaches to demand forecasting: statistics and machine learning
The choice between a statistical model and machine learning is not a question of "newer means better." It is determined by the planning horizon, the length of sales history, and how many external factors actually drive demand.
Open tools such as Prophet provide a baseline through trend and seasonality decomposition—it is calculated before making the model more complex.
| Option | When it fits | Limitations |
|---|---|---|
| Statistical model (seasonal smoothing, ARIMA) | Smooth series, stable seasonality, short and medium horizon, little item history | Promotions, promos, weather, and opening a neighboring location are not included in the model—external shifts break the forecast |
| Machine learning on features | Thousands of SKUs, there is a history of prices, promotions, calendar, and supply | Requires prepared features and leakage control; on sparse series the model overfits |
| Hierarchical forecasting | Forecast is needed at once by item, category, and warehouse | Levels need to be reconciled, otherwise totals do not add up and the purchasing plan diverges from actuals |
| Model ensemble | Series are heterogeneous: some smooth, some intermittent | More expensive to maintain, requires monitoring each model's contribution and reassembly when the assortment changes |
Then the planning horizon decides. For one to two weeks, statistics often matches machine learning, while for a quarter and beyond, without external features the forecast becomes inertial.
That is why we compare several options on your history and keep the one that maintains accuracy at the required horizon—not the one that is more complex.
Implementation stages: from data audit to model handover
The order of stages here matters more than speed: in demand forecasting, data quality affects the result more than the choice of algorithm. Therefore, we start with an audit of sources and end with handing the model over to the client's team, not the other way around.
- Data audit. We reconcile sales from POS and accounting systems with stock and supply, and find periods where zero sales mean no product on the shelf rather than no demand. Separately, we collect the promo calendar, prices, shipment schedule, and holidays—without them, the model explains a spike as randomness.
- Data schema. We fix the granularity (item × location × day), aggregation rules, and handling of returns, cancellations, and supply lags. The output is a data mart from which a feature is rebuilt by the same procedure during training and during operation in the live loop.
- Model building and tuning. We calculate a baseline from comparable weeks as a reference point, then add seasonality, regression, and feature selection. We validate quality with a rolling time window, not a random sample split.
- Validation on a holdout period. We keep the last weeks out of training and calculate error for each product group. Where the forecast is worse than the baseline, we return to the data rather than tweaking coefficients.
- Check in the workflow. The forecast goes into purchasing and production planning and is reconciled with the category manager's decision—this shows where the discrepancy is caused by data and where by a change in the market itself.
- Model handover and team training. We provide feature documentation, retraining regulations, scheduled runs, and monitoring of forecast deviations from actuals. The client's engineers then run the model independently.
Let's discuss your task—we will come back with an estimate and a stage-by-stage plan.
Project artifacts: data schema, model, update regulations
A demand forecasting project is valuable not for the model itself but for what remains in the client's loop after delivery.
We hand over not only forecasts but a complete set: where the data comes from, how to reproduce the calculation, and what to do when demand behavior changes. Below is the minimum set of artifacts without which the model turns into a black box within a month.
- Calculation configurations: forecast horizon, granularity (item, warehouse, day), seasonality parameters, rules for handling promotions and stockout periods—with an explanation of why each parameter was chosen.
- Data flow diagrams: sources, export schedules, input quality control points, and a transformation map from raw transactions to features.
- Access policies: roles by product groups and warehouses, separation of "sees raw data" and "sees only the forecast," and logging of access to exports.
- Model documentation: which features affect the result, on which period it was validated, where the applicability boundaries are, and what counts as going beyond them.
- Retraining regulations: trigger conditions (demand shift, accumulation of new sales, season), frequency, who initiates it, and how the result is validated before publication.
- Quality monitoring: daily error metrics by product group, forecast bias control, and alerts when thresholds are exceeded.
- Maintenance guide: typical failures, rollback procedure to the previous model version, areas of responsibility, and engineer contacts.
Such a set allows your team to change parameters and rerun the calculation independently, and to involve us only in development—not in monthly "life support."
Case study: stock and lost sales before and after implementation
A network of 180 stores and about 12 thousand active SKUs. The forecast was built from average sales of past periods: it did not react to promotions, weather, or local spikes, so planners corrected the numbers manually.
Orders went into the accounting system 1C:ERP already with "by eye" adjustments, and the discrepancy with actuals was analyzed after the fact.
What the measurement showed
| Metric | Before | After |
|---|---|---|
| Share of manual forecast adjustments | 34% of SKUs | 9% |
| Accuracy at a 7-day horizon | 71% | 88% |
| Accuracy at a 30-day horizon | 62% | 79% |
| Inventory level, days of cover | 48 | 33 |
| Lost sales, share of demand | 7.4% | 2.6% |
What was changed: the forecast was split by levels—network, store, product group, individual item—and features for promotions, prices, holidays, and on-shelf availability were added.
Hypotheses were tested with a backtest over two seasons; only the one that improved accuracy at both horizons went into production.
Manual adjustments were not removed but made the exception: the system highlights items where the forecast diverges from actuals, and the planner's edit is saved as a rule for similar cases.
Stock stopped being insurance against forecast error—it was cut by a third, and lost sales fell almost threefold without an increase in expiry write-offs.
What to do if data is scattered across several systems?
The forecast is built on a single time axis, so scattered sources are first brought to a common grain—day and warehouse.
Data consolidation almost always reveals discrepancies: somewhere sales are recorded by shipment, somewhere by payment, and for an online store, stock lives separately from the warehouse.
Until these definitions are reconciled, the model learns from contradictory series and produces fluctuations instead of seasonality.
The key to everything is a unified product master. We build a mapping table: internal code, supplier SKU, barcode, name in each system, and category hierarchy.
Duplicates, renames, and packaging changes are closed by rules, not manual edits—otherwise the item's history breaks into several short series.
Next is export quality. We check completeness by dates and points of sale, catch missing days, negative stock, duplicate documents, and backdated edits.
Every load passes a reconciliation check: the sum of shipments reconciles with warehouse movement, and discrepancies go into a separate report, not into the model.
We store historical data in immutable form: even after rebuilding the master data, past periods remain in their original labeling. Seasonal categories need a depth of two to three full cycles—then the model distinguishes growth from a seasonal peak. If there is little history, we restore it from archives and introduce a period adjustment.
The output is a data mart with an as-of date and master data version. This allows rebuilding the forecast for any date and comparing the result; without such a foundation, any model produces beautiful but incorrect numbers.
Technical concerns: data, quality, integration
Concerns before starting usually relate not to the model but to data, access to the accounting system, and what will happen to the forecast in six months. Below are answers to the questions most often asked by technical leaders.
How much sales history is needed for a stable forecast?
For seasonal groups—two full cycles: the model has time to learn the annual profile and holiday spikes. If there is less history, we start on aggregated groups and a short horizon, and connect individual items as data accumulates. We restore gaps from shipments, stock, and analogs.
How is the forecast integrated into the accounting system?
Through a separate read loop: exports to an intermediate storage or connection to a replica. The production database is not loaded, and rights are read-only. Master data mapping lives in a separate layer, so renaming an item does not break the calculation.
How is data protected?
The calculation runs in your environment or an isolated one; access is role-based and logged. Personal attributes are anonymized where they are not needed for the calculation, and access keys are stored in a secure vault, not in code.
Who maintains the model after launch?
Without maintenance, the forecast degrades: assortment, promotions, and suppliers change. Therefore, the loop includes monitoring of forecast vs. actuals and automatic reassembly when thresholds are exceeded. Planner adjustments are returned to the model as a feature.
Let's discuss your task and come back with a plan
A substantive conversation about demand forecasting rests on two things: sales history and how the solution will fit into the current planning process.
The more precisely you describe the data composition and forecast horizon, the fewer assumptions there are in the project estimate. Below is what is useful to prepare for the task discussion.
- Shipment and sales history — an export for a sufficient period by item and location, with marks for returns, write-offs, and zeroed stock. This is the basis for the project estimate: it immediately shows whether there is enough data for seasonality and sparse items.
- Promo and external event calendar — promotions, holidays, price changes, supply, and disruptions. Without them, the model attributes spikes to demand rather than a discount decision.
- Product and location hierarchy — product categories, warehouses, stores, or production lines. It determines at what level to build the forecast and how to aggregate the result.
- Forecast horizon and step — how many days or weeks ahead and how often to recalculate. This determines both the data composition and the implementation timeline.
- Current planning process — who makes the purchasing or production decision and at what point, and where the forecast should appear: in the accounting system, in reporting, or in a separate interface.
- Target accuracy and cost of error — how the discrepancy is calculated and what error is acceptable for different categories. Requirements differ for fast-moving items and for the long tail.
- Data and access constraints — what cannot be exported outside the perimeter, which systems will need to be connected, and who on your team confirms access.
Describe the task—we will come back with a project estimate and work plan that fixes what data is needed at the start, what can be added later, and how we verify the result.
