Forecast accuracy: how to measure MAPE and forecast bias

Forecasting has two dimensions, not one

When a team grades its own forecast, it almost always collapses the question into a single feeling: were we close or not? That instinct hides the only distinction that matters. A forecast can fail two different ways, and they call for completely different fixes.

The first dimension is accuracy — the average size of your misses. A forecast that lands 3% off every month is more accurate than one that swings 20% in either direction, regardless of which way the swings go. Accuracy is about noise: how much you can trust any single number the forecast hands you.

The second dimension is bias — the average direction of your misses. A forecast can be inaccurate but unbiased (it's noisy, but it's just as likely to be high as low) or it can be biased (it leans the same way, month after month). Bias is about systematic error: a pattern you can predict, which means a pattern you can correct.

Here's why conflating them is expensive. Two teams can post the exact same accuracy number while having opposite problems. One overshoots and undershoots at random — that's a modeling and data problem. The other is high every month by roughly the same amount — that's a process and incentive problem. The single "how close were we" number treats these as identical. They are not, and the fix for one does nothing for the other.

How to measure accuracy: MAPE, worked

The standard accuracy metric is MAPE — mean absolute percentage error. It answers "in a typical period, how far off are we, as a percentage?" The calculation is deliberately simple so that everyone in the weekly review can reproduce it:

For each period, compute the absolute percentage error: take forecast minus actual, divide by actual, and drop the sign. Then average those across your periods. The "absolute" part matters — you strip the sign on each one before averaging, so that a +10% month and a −10% month don't cancel out and flatter you into thinking you were perfect.

A worked example. Say the last three months looked like this:

• Month 1 — forecast $120k, actual $108k → error 11.1%
• Month 2 — forecast $130k, actual $141k → error 7.8%
• Month 3 — forecast $125k, actual $119k → error 5.0%

Average those three absolute errors and you get a MAPE of about 8%. That single number is the honest headline for how noisy your planning is: a typical month lands roughly 8% away from the forecast. It's the figure you should be reporting instead of "we were pretty close," because it's reproducible, comparable month to month, and directly usable downstream.

The absolute value is the whole point. The moment you let an over-month and an under-month cancel, you've built a metric that rewards a team for being wrong in both directions.

How to measure bias: the signed miss

Bias uses almost the same arithmetic as MAPE with one change: you keep the sign. Compute each period's percentage error with its direction intact (forecast above actual is positive, below is negative), then average. Because you don't strip the sign, opposite-direction errors cancel — and that cancellation is exactly the signal you want.

If bias comes out near zero, your misses are genuinely balanced: noisy, but not leaning. If bias comes out clearly positive, you systematically forecast above what happens — optimism that leaves you overstocked, over-committed on spend, and explaining shortfalls. If it comes out clearly negative, you systematically forecast below actuals — sandbagging that starves inventory, caps your ad budget, and quietly throttles growth because every plan is built on a number you already know is low.

The most useful read is bias relative to MAPE. If your bias is small compared to your average error, most of your miss is random noise — a data and modeling problem. If your bias is a large share of your MAPE, most of your error points the same way, which means it's systematic and, crucially, fixable without a better model at all. You don't need machine learning to stop adding 12% to every number out of habit.

What good looks like

Benchmarks vary by business, season, and how granular you forecast — SKU-level forecasts are always noisier than a monthly company total — but as rough goalposts for monthly ecommerce revenue:

• Under 10% MAPE — tight. You can plan inventory and spend against this with real confidence.
• 10–20% MAPE — typical and workable, but the error is costing you in over- and under-stock and in reactive budgeting.
• 20–30% MAPE — noisy. The forecast is shaky as a basis for inventory or ad-spend commitments.
• Over 30% MAPE — the forecast can't safely drive stock or spend decisions, and you're effectively planning blind.

On bias, the target is simple: as close to zero as you can get. Any persistent lean — even a small one — compounds, because you make the same directional bet twelve times a year on inventory buys and budget commitments.

Where bias actually comes from

Systematic bias is almost never a math error. It's an organizational one, and it usually traces to a single root cause: the team is reporting a target dressed up as a forecast. A forecast is your honest expected case — the number you'd bet on. A target is what you're reaching for. When the two get merged into one figure, the aspiration leaks into the forecast and you get persistent positive bias: the plan is always a little better than reality because it was never really a prediction.

The mirror image is sandbagging. When a team is measured on "hitting forecast," the safest move is to forecast low and beat it — which manufactures persistent negative bias and the chronic understocking that comes with it. Both pathologies are invisible if you only track MAPE, and both are obvious the moment you look at the signed average.

The fix is structural, not analytical: separate the aspirational target from the expected-case forecast and report them as two different numbers with two different owners. Forecast accuracy is also only as good as the inputs behind it — a forecast built on the wrong drivers will stay biased no matter how you grade it, which is why this pairs directly with driver-based forecasting instead of trend-line guessing.

Turn your error into a planning range

A point forecast pretends to a precision you don't have. Once you know your MAPE, you can do something far more useful than arguing about a single number: convert it into an honest range. If your forecast is $500k and your MAPE is 12%, you're really planning for roughly $440k–$560k, and that band is what you should staff, stock, and budget against — not the false-precision midpoint.

This is where forecast quality stops being a reporting exercise and starts touching the P&L. The width of your range determines how much safety stock you carry, how aggressively you can pre-commit ad spend, and how exposed you are to a miss. A tighter forecast literally frees up working capital, because you can hold less buffer. That's the direct line between forecast accuracy and the hidden P&L cost of getting inventory wrong — the overstock and stockout costs that a noisy or biased forecast generates on autopilot.

A diagnostic order of operations

Pulling it together, the sequence that turns "we were pretty close" into a forecast you can actually plan against:

• Measure MAPE first. Get the honest average size of your miss, and report it instead of a feeling.
• Then measure bias. Keep the sign, average it, and see which way you lean.
• Compare bias to MAPE. A large bias share means the problem is systematic and fixable without a better model.
• Trace systematic bias to its source — almost always a target masquerading as a forecast, or a sandbagging incentive.
• Convert MAPE into a planning range and use the band, not the point, to drive inventory and spend.

Done in this order, forecasting stops being a monthly post-mortem about who was right and becomes what it's supposed to be: a tool for sizing risk and committing capital with your eyes open.

Score your own forecast

Most teams discover, the first time they actually compute it, that their forecast isn't just noisy — it's noisy and leaning the same way every month. The noise is a modeling problem; the lean is a process problem; and you can't fix either until you've separated them.