Forecast Accuracy — WAPE & MAPE

Forecast accuracy is forecast error, restated so that bigger is better. The error is the honest object: how far the forecast sat from what actually happened, measured at a declared grain, at a declared lag, under a declared weighting. Accuracy is then usually reported as one minus that error, floored at zero so it cannot go negative in front of an executive audience.

There is no standard here, and the gap between conventions is not small. WAPE weights every unit equally — it is absolute error summed over actuals summed. MAPE weights every row equally, which sounds fairer and is not: a slow-moving item that sold two units against a forecast of ten contributes a 400% error to the mean, and a hundred such items can drown out the entire high-volume portfolio. The two routinely differ by tens of points on identical data.

So the number is only meaningful with its settings attached. An accuracy of 78% means nothing until it says which error metric, at which lag, at which grain. Change any one of those and the same forecasts produce a different headline — which is why accuracy figures from two systems, or two years, should be assumed non-comparable until the three settings are shown to match.

Also answers to WAPE · wMAPE · MAPE · MAD/Mean · Forecast Error

Three switches decide what your accuracy number is. State all three on the chart, because two accuracy figures with different settings are not a comparison.

• Averaging per-SKU MAPEs — Intermittent-demand items produce percentage errors in the hundreds, and an unweighted mean lets them swamp the portfolio. If a headline number moves when you add slow movers that barely ship, it is measuring the tail, not the business.
• Division by zero — MAPE is undefined wherever actuals are zero, so implementations quietly drop those rows or substitute a value — both of which change the number. WAPE has no such hole, because the denominator is a sum.
• Comparing across lags or grains — A lag-1 national accuracy against a lag-3 item-DC accuracy is not a comparison, and the first will always look better. Fix the lag and the grain before anyone draws a trend line.
• Accuracy floors — One minus WAPE goes negative as soon as absolute error exceeds demand, which happens routinely at item grain. Decide whether to floor it at zero, and say so — an undeclared floor makes bad items look merely mediocre.
• A “MAPE” that is really a WAPE — Numbers arrive labelled MAPE from planning teams and vendor tools that actually compute summed absolute error over summed actuals — which is WAPE (the same formula this library elsewhere writes as WMAPE). The label does not settle the arithmetic, and the two constructions differ by tens of points on identical data, so ask for the formula before comparing any two accuracy figures.
• Intermittent demand and the flat-zero trap — Absolute-error measures of the MAE and MASE (scaled absolute error against a naive baseline) family are minimized by the conditional median, which for an item that sells nothing in most periods is zero — so ranking methods on one of them can crown a permanent forecast of zero on the intermittent tail. Score slow movers instead on a quantile (pinball) loss at the stocking quantile over the lead-time bucket, and separate the slow-moving tail from the fast movers before scoring: never one league table.

These carry the actuals side — ordered, delivered, and billed quantity. The forecast side lives in the planning application, so the accuracy fact is built where the landed forecast meets these actuals in the lakehouse, not inside the ERP.

F3460 is the forecast file: forecast types by item, branch, and period, which is why the forecast type belongs in the join key. Actuals come from the sales lines and their history file, with Julian dates converted on the way in.

ForecastSales carries demand forecast lines per forecast model, so the model belongs in the key alongside item and period. Actuals come from sales lines and invoiced transactions, with the company pinned.

Forecast rows appear as order categories inside the time-phased plan, so the category filter is what separates plan from demand. CONO pinning and numeric YYYYMMDD date handling apply as everywhere else in M3.

Forecast sets and their date buckets are the plan side; the designator is the identity of a forecast, so it belongs in the join. Order lines carry the actuals, under the usual operating-unit striping.

Fulfillment lines carry the demand actuals, and nothing else here does. Plans live in Supply Planning and reach the lakehouse through BICC extracts rather than through this table, so the accuracy fact is assembled downstream from two different extract paths.