To use AI for retail demand forecasting, start by putting sales, stock availability, prices, and promotions on the same timeline. Without that context, a model learns from numbers that seem to represent demand but may only reflect what was available to sell.
This applies to physical stores, ecommerce, and businesses that combine both channels. The aim is to estimate how much of each product customers may want in each location and period, then use that estimate to support purchasing, replenishment, and distribution. A forecast informs a decision; it does not replace business rules or remove uncertainty.
Recorded sales are not the same as demand
Imagine two stores selling the same item. One sold 20 units in a week; the other sold only two. If the second store ran out after the first day, those two sales do not indicate weak demand. They indicate that demand stopped being observable.
A model trained only on sales can repeat this mistake and recommend even less stock for the store that experienced a stockout. Promotions also change the signal. A spike during a discount should not become the default expectation for later weeks.
Before forecasting, distinguish at least three cases: available and sold, available and unsold, and unavailable. Returns, cancellations, and transfers between stores need separate definitions. Treating them as new sales changes what the model learns.
What data do you need for retail demand forecasting?
The first dataset can be small if each field has a consistent meaning:
| Data | Why it matters |
|---|---|
| Product and location | Let you compare the same SKU across stores, distribution centers, and digital channels. |
| Sale date and net units | Show history after cancellations and returns have been handled. |
| Available stock and stockouts | Identify periods when sales were limited by lack of inventory. |
| Price and promotion | Explain some changes caused by discounts or campaigns. |
| Calendar | Holidays and seasonality help you compare equivalent periods. |
| Replenishment lead time | Connect the forecast to purchasing and supply decisions. |
Choose the level of detail before joining sources: for example, one row per product, store, and day. An ERP may record sales by line item, an online store may record orders by cart, and inventory may update with each movement. Data engineering must turn these events into a consistent view. It must also preserve history: today's stock balance cannot tell you whether an item was unavailable last week.
The data engineering work before the model
A useful first version of the dataset can follow these steps:
- Choose authoritative sources. Identify where orders, completed sales, returns, prices, and inventory movements originate. Document which system takes precedence when figures disagree.
- Unify identifiers. The same product needs a recognizable key across the ERP, stores, and ecommerce. Code changes, bundles, and variants need explicit matching rules.
- Reconstruct history. Produce records by product, location, and period, including days with no sales and a flag for stockouts. Keep track of the rules used to transform the data.
- Test data quality. Look for duplicates, out-of-order dates, invalid prices, unexplained negative stock, and products missing from one source. Monitor how often each source updates.
- Deliver a reusable dataset. The same reliable layer can support stockout reports, inventory turnover metrics, and forecasting experiments. It creates value before a model goes into production.
You can begin without replacing the transactional system. An integration can extract the data needed for analysis into a separate layer while current operations continue. This follows the same principle as incremental modernization of legacy systems: add analytical capability without interrupting the business.
How to test whether AI improves the decision
Start with one category and one decision, such as weekly replenishment by store. Before using a complex model, establish a simple baseline, such as sales in comparable weeks adjusted for known stockouts. If a new approach does not beat that baseline on later periods, there is no reason to automate purchasing yet.
Evaluate in time order: train on older data and test on weeks the model has not seen. Compare forecast error, but also operational outcomes: stockout days, excess inventory, and how often people override the suggestion. Record when a promotion, price change, or integration failure affects a result.
At first, show the forecast alongside the team's usual recommendation. Buyers and managers can identify exceptions the dataset does not yet capture while data engineers fix the causes. Moving to automated decisions should depend on measured performance and limits for each product type.
Where AI helps and where a rule is enough
A forecasting model helps when there is history, relevant variables, and a recurring decision whose quality can be measured. For a newly launched product with little history, similar items and commercial judgment may be more useful. For a fixed rule, such as preventing an order above a contractual limit, ordinary code is more predictable.
A language model does not need to sit in every step. Generative AI might help explain a variation or organize a buyer's notes, but numerical forecasts and inventory constraints need to be judged on their own results. The architecture should make each recommendation reviewable: which data went in, when it was updated, and what decision followed.
Where to start
Pick a product group with frequent sales and a clear cost of stockouts or overstock. Check whether you can reconstruct sales, availability, price, and promotion for each day. Then choose a forecasting method and agree on a success measure with the replenishment team.
Reference documentation shows why the data foundation matters: Google Cloud describes the product and purchase events used by retail AI applications and how catalog and event data can be prepared for sales forecasts. These are implementation examples, not requirements to use a particular platform.
If your sales, stock, and catalog data live in separate systems, talk to Korvantis. We can map the sources and define a first data deliverable before expanding the AI project.