The forecast isn't wrong because the model is weak.
It's wrong because nobody trusts the number underneath.
Demand Forecasting in Power BI & Microsoft Fabric
Accuracy plateaus at 65% because the leak is not the model — it is the override pipeline on top and the master data underneath. We fix the foundation, generate the forecast in Fabric, and surface it in Power BI where planning can finally see whether the overrides help.
The Problem
Where forecast accuracy actually leaks
Three leaks, none of them the model — and one of them is usually costing you far more than the other two.
You bought a better tool and accuracy plateaued anyway.
A statistical engine, then a machine-learning add-on, then an AI demand planning platform. Accuracy moves a point or two and stalls somewhere around 60–72% at SKU-DC level. The problem is not hard. It is misdiagnosed — the model is rarely the bottleneck.
The override pipeline destroys more value than it adds.
The statistical baseline is overwritten by hand — by sales, by key-account managers, by the planner protecting service. Some overrides add value. Most destroy it. Until you measure forecast value-add, you are flying blind on the single biggest lever you have.
The master data poisons the history.
A SKU that changed pack size, a customer that got re-coded, a promotion that was never flagged as a promotion — each one corrupts the signal the model learns from. You cannot forecast a clean number out of a dirty master.
The scorecard rewards the wrong forecast.
Planners are frequently measured on service level, not forecast accuracy — so they rationally over-forecast to protect availability, and cover shows up as excess stock. The number is not wrong by accident. It is wrong on purpose. No model fixes an incentive problem.
What we build
What we build
Foundation first, then a forecast S&OP commits to — measured on value-add, not just accuracy.
A governed demand foundation on Microsoft Fabric
Replaces
The forecast built on a SKU and customer master that does not agree with itself.
- ERP (SAP ByDesign, S/4HANA, Dynamics 365, NetSuite), distributor and retailer sell-out feeds, and promotional calendars connected via Azure Data Factory
- A SKU and customer master that finally reconciles across sources
- Promotions flagged as promotions so the baseline learns clean history
- One governed layer in OneLake feeding every downstream model
The model learns from a clean signal — the unglamorous work that moves accuracy more than any engine change.
A statistical forecast built for the demand pattern
Replaces
One engine forced across every SKU regardless of how it actually sells.
- The right method per demand pattern — fast movers, intermittent demand and new products are different problems
- Models built in Fabric notebooks, the native PREDICT() function, or Azure ML where the use case earns it
- Statistical baseline generated where the governed history lives — no separate sandbox
- New-product and intermittent SKUs handled with tolerance and policy, not a heroic model
A baseline fit to how each SKU actually behaves — not a single average forced across the range.
A Power BI planning view that measures forecast value-add
Replaces
The forecast that lives in a data-science sandbox nobody in planning can see or trust.
- Baseline, overrides and forecast value-add in one Direct Lake Power BI model
- Accuracy tracked at the level you plan — SKU-DC, category, region — against the cycle you run
- Every override attributed, so the planner sees whether their adjustments help or hurt
- The number S&OP commits to, instead of three numbers from three functions
The planner sees, for the first time, whether their overrides add value — and by how much.
Demand sensing where speed changes a decision
Replaces
A weekly forecast cycle that is always a few days behind the signal.
- Short-horizon signal pulled from live sell-out via Fabric Real-Time Intelligence
- Near-term forecast moved 48–72 hours ahead of the weekly cycle
- Applied only to the SKUs where that speed changes a replenishment decision
- Feeds automated replenishment where the signal is strong enough to act on
The near-term number is current, not a week stale — for the SKUs where it actually matters.
Who this is for
Who this is for
Demand forecasting stops being a data-science project the moment the planner, the S&OP head, finance and sales all read the same number. Here is what changes for each of them.
Demand / Supply Planner
The problem
The baseline comes out of a statistical engine, then gets overwritten by hand — yours, sales, key accounts — and nobody can say whether those overrides helped. You are measured on service, so you over-forecast to be safe, and the cover shows up as excess stock somewhere else.
What we build
A statistical forecast built for each demand pattern in Microsoft Fabric, surfaced in a Direct Lake Power BI model where every override is attributed. You see forecast value-add — baseline accuracy versus post-override accuracy, by who touched the number.
+15–25% forecast accuracy once the override pipeline is measured and the master data is clean
Supply Chain / S&OP Head
The problem
Sales, supply and finance walk into the S&OP meeting with three different numbers, and the cycle is always a few days behind the signal. Stockouts and overstock both persist because there is no single forecast anyone commits to.
What we build
One governed demand foundation on OneLake feeding a single S&OP planning model in Power BI — the number sales and supply commit to, with demand sensing from live sell-out on the SKUs where 48–72 hours changes a replenishment decision.
Hollandia Dairy: 20–40% fewer stockouts on a governed forecast built the same way
CFO / Finance Lead
The problem
You carry the cost of a forecast you cannot see the accuracy of — working capital tied up in cover, write-offs on spoilage, and no line of sight into whether the planning investment is paying back.
What we build
Accuracy and forecast value-add tracked at the level the business plans — SKU-DC, category, region — so the working-capital and spoilage cost of the forecast is visible, not inferred, in Power BI.
Hollandia Dairy: 10–30% less spoilage as the forecast the business trusts tightens cover
Sales / Commercial Lead
The problem
Your promotions and account commitments never reach the planning number cleanly, so availability suffers on the lines you have pushed — and planning blames your overrides while you blame their model.
What we build
Promotions flagged as promotions in the governed layer so the baseline learns clean history, and one forecast where your commercial signal and the statistical baseline meet — instead of two functions arguing over two numbers.
Hollandia Dairy: 5–15% sales uplift as availability improves on the lines that matter
How we work
First working output in 6 weeks
We find the biggest of the three leaks first. A better model on a dirty master and an undisciplined override pipeline just gives two functions a better weapon to argue with.
01
Discover — where the accuracy actually leaks
Two weeks. Assess how the forecast is generated and overridden today, whether the master data can support the accuracy you want, and whether planners are measured on the thing you need. Name the biggest of the three leaks.
02
Prototype — baseline plus value-add measurement
Three to five weeks. Clean the SKU and customer master, build a statistical baseline for the top SKUs, and deploy the forecast value-add view. Validate against historical actuals. The first S&OP cycle using it is the real test.
03
Deploy — full range, demand sensing, S&OP integration
The full range and channels, demand sensing on the SKUs that warrant it, and integration into the S&OP cycle so sales and supply commit to one number.
Technology stack
Lakehouse
Forecast & ML
Visualisation
Integration
ERP & Sell-out
Real-Time
Common questions
What buyers ask us
Can Power BI do demand forecasting?
Power BI is where the forecast is consumed, measured and argued about — by the demand planner, the S&OP lead and the commercial team. The forecast itself is generated upstream: statistical models in Microsoft Fabric notebooks, the native PREDICT() function against a trained model, or Azure Machine Learning where the use case earns it. Building it in Fabric and surfacing it in Power BI in Direct Lake mode stops the model being a black box the planner works around.
How do you measure forecast accuracy?
At the level you plan (SKU-DC, category, region) against the cycle you run — and, crucially, we measure forecast value-add: baseline accuracy versus post-override accuracy, by who touched it. Most operations never measure whether their manual overrides help or hurt, which is the single biggest lever they have. It is often uncomfortable reading and always the fastest win.
Why does forecast accuracy plateau at around 65%?
The model is rarely the bottleneck. Accuracy leaks in three places: the override pipeline (hand adjustments that mostly destroy value), the master data (a SKU that changed pack size or a promotion never flagged as one poisons the history), and the incentive structure (planners measured on service, not accuracy, rationally over-forecast). No new engine fixes an incentive or master-data problem.
How long until a demand forecast is live?
First working output in 6 weeks — a governed demand foundation and a baseline forecast surfaced in Power BI. A full production platform including forecast value-add measurement and demand sensing typically takes 12–18 weeks depending on ERP complexity and master-data readiness.
Ready to move
Book a 30-minute forecasting diagnostic
30 minutes with Amit. No slides. No pitch deck. No obligation to proceed. Most operations leaders leave this call knowing which of the three leaks — overrides, master data, or incentives — is costing them the most.