D365 demand forecasting genuinely runs on machine learning, not a rules-of-thumb spreadsheet formula dressed up as intelligence. It also runs on an Azure service that is being retired, which makes this a worse time than usual to assume the built-in setup is still configured the way it was five years ago.
This guide will explore how D365 demand forecasting actually builds a baseline forecast, the specific statistical models behind it, and where built-in forecast accuracy still needs more than what the platform reports on its own.
What D365 demand forecasting actually does, start to finish
The process runs in four stages, and none of them are optional shortcuts; skipping one just means a worse forecast further down the line.
- Gather historical data: a summary of historical transactions, plus optionally imported external historical demand to supplement what D365 already has on file.
- Generate the baseline: a statistical forecast is built through Azure Machine Learning, and the model is tested for Mean Absolute Percentage Error (MAPE) before anyone trusts the output.
- Review and adjust: the forecast is visualized in D365, and a planner can update recommended values before anything gets used downstream.
- Approve and publish: once authorized, the forecast becomes available to master planning and the rest of the supply chain process.
Skipping the review stage is the shortcut that causes the most damage later. A statistically sound model can still recommend a number that ignores context the system has no way to know, a planned plant shutdown, a new competitor, a contract that just ended, and the review step exists specifically to catch exactly that kind of gap between the math and reality.
The built-in models: ARIMA, ETS, and two different Azure ML paths
D365 demand forecasting supports genuine time series models, not a single generic algorithm applied to every item the same way.
- ARIMA, AutoRegressive Integrated Moving Average, captures complex patterns in time series data and works well across finance, economics, and operations forecasting generally.
- ETS, Error, Trend, Seasonal, is built specifically to handle seasonality directly in the model rather than requiring a separate adjustment layered on top.
- STL, Seasonal and Trend decomposition using Loess, is a third option available for isolating seasonal patterns from the underlying trend.
None of these three models is universally correct. An item with a strong, predictable seasonal cycle usually favors ETS, since seasonality is built into the model rather than bolted on afterward, while a longer, noisier history with less obvious seasonal structure may respond better to ARIMA. The right choice is rarely obvious from looking at raw historical demand alone, which is exactly why testing MAPE across models matters more than picking one and assuming it fits every item in the catalog.
The Azure connection behind these models is where currency actually matters. Azure Machine Learning Studio (classic) is deprecated and being removed from Azure entirely. Microsoft’s own guidance is direct: if setting up D365 demand forecasting for the first time, use Azure Machine Learning Service, and if still running on the classic studio, plan the switch as soon as possible.
A forecast model still pointed at a deprecating Azure service is a problem that shows up quietly, right up until it stops working entirely. A Metrixs consulting review can confirm which path a deployment is actually running on.
Historical demand: what actually feeds the forecast
Historical demand is the raw material every model above depends on, and D365 demand forecasting distinguishes between independent demand from sales orders and dependent demand generated at decoupling points for customer orders.
- Importing external historical demand matters most for a new product line or a recent acquisition, where D365’s own transaction history is too short to build a trustworthy baseline on its own.
- Demand forecast reduction rules handle mass customization scenarios, reducing the forecast as actual customer orders consume it rather than double-counting demand that has already been fulfilled.
The independent-versus-dependent distinction is worth keeping straight, since the two behave differently once a forecast is published. Independent demand from sales orders drives the forecast directly. Dependent demand, generated at a decoupling point further down a bill of materials, is calculated from what the independent forecast implies, so an error in the parent forecast propagates automatically into every dependent item beneath it.
Forecast dimensions and item-level overrides
Not every item should forecast the same way. Item allocation keys let a specific item, or group of items, override the default forecast generation method rather than being forced through whatever model the rest of the catalog uses.
- Forecast dimensions, product, site, and customer among them, are what let the same underlying historical demand produce a meaningfully different forecast depending on which slice of the business is actually being planned for.
- A single global model tuned for the highest-volume items in a catalog is rarely the right fit for a long tail of low-volume, high-variability items, which is exactly the case allocation key overrides exist to handle.
Site and customer dimensions matter most for organizations with genuinely different demand patterns across locations. A product that sells steadily in one region and only during a short seasonal window in another needs different treatment in each place, and forecasting it as one blended number for the whole business would flatten exactly the pattern a planner most needs to see.
Forecast dimensions that were configured once at go-live rarely get revisited as a product catalog evolves. The Metrixs analytics suite is what makes that drift visible again.
Forecast accuracy: how D365 measures it, and where it stops
D365 tests every generated model for MAPE and surfaces key performance indicators directly in the platform, so a planner is not approving a forecast blind.
- What gets shown is accuracy for the current model run, not a trend of how that accuracy has moved across the last several forecast cycles.
- Comparing ARIMA against ETS against STL for the same item over time, to see which model actually performs best long term, usually means exporting results from separate runs and comparing them manually.
| What you need | Built-in D365 F&O tools | A dedicated layer such as Metrixs |
|---|---|---|
| Accuracy trend across cycles | Reported per model run, not historized | Configurable history in one saved view |
| Model comparison over time | Exported and compared manually | Consolidated automatically |
| Accuracy across entities | Assembled entity by entity | One reporting layer across all of them |
| Refresh | As current as the last forecast run | 15 to 30 minutes via Synapse Link |
How Metrixs extends D365 demand forecasting reporting
Metrixs reads forecast models, MAPE results, historical demand, and actual sales through Azure Synapse Link into the same dedicated Azure Data Lake used for the rest of D365 F&O, built across more than 6,000 backend tables.
- Accuracy held as configurable history, so a trend across months of forecast cycles is a saved report, not a rebuilt export after every run.
- Model comparison across ARIMA, ETS, and STL results consolidated in one place, surfacing which model actually performs best for a given item or category over time.
- Results consolidated across a multi-entity or multi-ERP environment, not limited to one legal entity at a time.
- Refresh every 15 to 30 minutes, inside the same 12-module, 100+ report, 1,000+ metric suite; most deployments live in under 6 weeks; client ROI 290% to 450%.
D365 demand forecasting still generates a genuinely capable baseline forecast on its own. Metrixs is where that forecast’s actual track record finally becomes visible across cycles, well beyond the one currently on screen.
By model, by item, by cycle, trended over a full year instead of reviewed one run at a time. See it in the D365 F&O finance and accounting analytics use case.
Frequently asked questions
What machine learning models does D365 demand forecasting use?
D365 demand forecasting supports ARIMA, ETS, and STL time series models, each suited to different data patterns. ETS is built specifically to handle seasonality within the model itself, while ARIMA and STL offer alternative approaches to capturing trend and pattern in historical demand.
Is Azure Machine Learning Studio classic still supported for D365 demand forecasting?
No. Azure Machine Learning Studio Classic is deprecated and being removed from Azure. Microsoft recommends Azure Machine Learning Service for any new demand forecasting setup, and advises existing users of the classic studio to migrate as soon as possible.
How is forecast accuracy measured in D365 F&O?
Forecast accuracy is measured using Mean Absolute Percentage Error (MAPE, tested for each generated model before it is trusted for planning. D365 surfaces key performance indicators directly in the platform once a baseline forecast is generated.
What is historical demand, and can external data be added to it?
Historical demand is the summary of past transactions D365 demand forecasting uses to build a baseline model. External historical demand can be imported to supplement this data, which matters most for new product lines or recent acquisitions with limited transaction history inside D365 itself.
What are forecast dimensions in D365 F&O?
Forecast dimensions, including product, site, and customer, let the same historical demand produce different forecasts depending on which slice of the business is being planned. Item allocation keys let specific items override the default forecast generation method rather than following a single global model.
Can D365 F&O compare forecast accuracy across models over time?
Not as a single native view. Accuracy is reported per model run rather than trended across cycles, so comparing ARIMA, ETS, and STL performance for the same item over several forecast periods usually means exporting results and assembling the comparison manually.
The verdict
D365 demand forecasting genuinely earns the built-in half of its name: real-time series models, a documented four-stage process, and MAPE-tested accuracy reported the moment a forecast generates. The Azure Machine Learning connection behind it does need active attention, given the classic studio’s retirement.
Where it stops is the external half: accuracy trended across cycles, models compared over time, results held across entities. Metrixs closes that gap, reading the same forecast models and historical demand, refreshing every 15 to 30 minutes, and shipping it as part of the same suite that already covers general ledger, budgeting, and master planning.
Ready to see your own forecast accuracy as one connected trend? Book a Metrixs reporting assessment, and we will map your forecast models and historical demand against what the reporting layer already covers.
Related reading: Procurement and sourcing in D365 F&O: from purchase requisition to spend analysis
