AI for Demand Forecasting: Test Before Automating Reorders

AI for demand forecasting uses models to estimate future demand from historical patterns and, where useful, other information such as promotions, prices, or weather. For a distributor or importer, its value is a better planning decision—not a more impressive forecast chart.

My recommendation: compare a candidate with your existing forecast and a simple baseline before it drives replenishment. First check what the historical numbers actually measure. When inventory limits sales, an accurate prediction of fulfilled sales is not necessarily an accurate prediction of demand.

Here is a small example showing why that distinction can reverse which forecast appears better.

The same sales can tell two different demand stories

Suppose you sell one SKU at one location. Each morning, six units are available. Across four days, the recorded sales are:

All numbers are illustrative. Neither forecast came from an AI model. Assume no replenishment during a day, backorders, substitutions, returns, or demand carried into another day. In this deliberately simple model, units sold equal the smaller of demand and available units.

Score the forecasts against recorded sales using weighted absolute percentage error:

WAPE = sum of absolute forecast errors ÷ sum of actual target units × 100

The denominator must be positive, and you must say what the “actual target” represents.

Forecast A has no error against sales: 0 ÷ 24 = 0%. Forecast B misses by four units every day: 16 ÷ 24 = 66.7%. On that score, A wins easily.

But consider two possible demand histories:

In the second history, A misses 16 of 40 demanded units, giving 40% WAPE. B matches demand exactly. The preferred forecast reverses, although the observed sales and selling capacity have not changed.

This does not prove that demand was ten. Selling the last unit does not reveal how many additional units customers wanted; there may have been none. Sales and availability alone cannot distinguish these two histories.

That is the useful question for a forecasting demo: “Are we evaluating fulfilled sales, recorded customer requests, or an estimate of demand that inventory prevented us from observing?” If the answer changes between slides, the comparison is not yet usable.

AWS’s documentation on missing values makes a related data distinction: zero sales while an item is available differs from zero sales while it is unavailable. The documentation supports treating availability carefully; it does not tell you how much hidden demand to invent.

What AI adds—and what it cannot recover automatically

An AI demand forecasting system can fit relationships across many products, consider relevant external variables, or help automate model selection. Those are reasons to test a candidate, not evidence that it will outperform your current method.

Do not treat “traditional” and “AI” as a clean split between models that never update and models that continuously learn. Updating, retraining, feature selection, and forecast approval are implementation choices. A simpler statistical method can also be rerun regularly.

Nor is a conversational explanation a forecasting model. An assistant may summarize a forecast or let a planner ask questions about it. That does not establish how the numbers were generated or whether the model was evaluated properly.

For a small operator, I would start with the capability already available in the ERP or planning system. An existing forecast that can be exported, compared, and corrected is a stronger starting point than a separate tool whose results cannot be reconciled with your item and location records. The native-first implementation guide explains when that choice stops being sufficient.

The recommendation changes if a properly evaluated candidate produces a useful improvement at the required horizon, with manageable data and operating costs. The label on the model should not decide the purchase.

Build a comparison that answers your purchasing question

1. Name the target, unit, and horizon

Write down one precise forecast request. For example:

Every Monday, forecast requested units of SKU P17 at warehouse W1 for each of the next six weeks, using information available by Sunday night.

Requested units need a definition: initial customer orders, accepted orders, or orders remaining after cancellations? Pick one consistent with the decision. Fulfilled units and revenue are different targets.

Match the horizon to the replenishment decision. A good next-day forecast is not enough evidence for a supplier order with a six-week lead time. Also define the unit: cases and individual pieces cannot share an unlabeled quantity column.

2. Preserve availability alongside sales

For the chosen items, collect sales or order history with item, location, unit, and time. Add what you can reliably establish about availability: stockout intervals, sellable stock, blocked channels, or other constraints relevant to the target.

Keep these situations separate:

• The item was available, but nobody bought it.
• The item was unavailable, so purchases could not occur.
• The source failed to record the period.
• Customer requests were recorded but fulfilled later or canceled.

A backorder that later ships must not become two demand events. Similarly, a lost-sale note and a replacement order may describe the same customer request. More rows are not automatically better evidence.

Do not silently replace every unavailable period with zero, drop every difficult period, or apply an arbitrary uplift. Each choice changes the target or the sample. If lost demand must be estimated, state the method and uncertainty; do not present that estimate as directly observed truth.

When inventory records themselves are unreliable, start with inventory management automation. A forecasting project cannot repair a missing receipt by fitting a more complex model.

3. Compare forecasts made without future information

Reserve later periods for evaluation. At each historical forecast date, use only the information that would have been available then—including the version of promotions or weather information known at that point.

Hyndman and Athanasopoulos describe this as evaluation on a rolling forecasting origin: move the forecast date forward, use earlier observations, and assess the subsequent outcomes. Use multi-step evaluation when that matches the actual planning horizon.

Compare the candidate with your current method and an appropriate simple benchmark. A seasonal-naïve benchmark, for example, repeats the corresponding previous season’s value. It is not appropriate for every series, but it prevents an elaborate model from receiving credit merely for recognizing an obvious repeating pattern.

Use a development period to choose settings, then a later untouched test period for the final comparison. Repeatedly tuning against the final test turns it into development data.

4. Explain the score before accepting the winner

For each method, retain the forecast as originally issued, its target period, the actual target, and availability status. Show both overall results and meaningful groups: fast movers, intermittent items, new products, or high-value stock.

Report constrained periods separately. Accuracy on consistently available items is useful, but it does not establish accuracy on items selected out by shortages. Equally, failure to observe demand does not excuse every overforecast.

WAPE summarizes absolute error relative to total target units; it is not a service level or a profit measure. High-volume items can dominate an aggregate. Also inspect the direction of errors: underforecasting an important item and overforecasting a slow mover can have different consequences even when their absolute errors match.

Keep the simple method if the candidate’s advantage disappears across later test windows, matters only in irrelevant groups, or costs more to operate than the improvement is worth. The AI automation ROI guide helps distinguish a better technical result from a fundable investment.

Take one forecast into a reorder proposal

A demand forecast is not a purchase quantity. Consider a separate, simplified illustration:

• Forecast demand over the lead-time window: 42 units.
• Current usable, uncommitted stock: 20 units.
• Confirmed usable inbound supply before it is needed: 10 units.
• Assumed buffer: 5 units.

The period-total calculation suggests 42 + 5 − 20 − 10 = 17 additional units. If purchases must be in packs of six, rounding up gives 18 units.

That is a proposal, not an optimized inventory policy. The five-unit buffer is an assumption, not statistically calculated safety stock. Supplier minimums, budget, shelf life, forecast uncertainty, and delivery timing still matter. Ten inbound units arriving after a shortage cannot cover that earlier shortage, even if the window total balances.

Before releasing an order, a buyer should be able to inspect the forecast version, stock position, usable inbound dates, unit conversions, and any override. Use a designed human review step for decisions that still need that judgment. Copying the forecast directly into a purchase order skips the purchasing calculation.

A first pilot worth running

Choose one coherent product group, one location, and one planning decision. Keep normal purchasing authority in place while the candidate produces recommendations alongside the existing process.

Before starting, agree what would justify switching: relevant out-of-sample improvement, acceptable planning effort, and a replenishment outcome that matters to the business. If the available history cannot represent the necessary seasonality or shortage conditions, say so; four good weeks do not settle an annual planning question.

The example above establishes a limit on what sales data can tell you. It does not demonstrate an AI model, recover real lost sales, or promise fewer stockouts. Its purpose is to help you ask a more consequential question before buying: what evidence would make this forecast good enough for this decision?

If that question is getting lost between your ERP, spreadsheets, and purchasing process, KelenAI’s workflow automation services can help define the operating workflow. Submit your workflow context with the forecast target, available data, and decision you want to improve. We will review it and follow up; submitting does not commit you to a call.