There is no S&OP module in Dynamics 365

There is no S&OP module in Dynamics 365 — so what do you build?

Manufacturers ask for an S&OP module (sales and operations planning — the recurring cross-functional cycle that reconciles a demand plan, a supply plan and a financial plan into one agreed number) and are told about demand planning. That is not evasion. Dynamics 365 Supply Chain Management supplies the demand engine, the supply engine and the capacity check. What it does not supply is the agreement.

State the evidence class before the argument, because this is an argument from absence. Microsoft does not publish a statement saying there is no S&OP module, and we are not putting words in its mouth. What we did is search the product documentation and both current release plans on 31 July 2026 for a feature area, module or planned feature named for sales and operations planning, and find none. An absence in documentation is weaker evidence than a presence, and it is the right kind of evidence for this question.

What we looked at

**[Welcome to Dynamics 365 Supply Chain Management](https://learn.microsoft.com/en-us/dynamics365/supply-chain/supply-chain-management-welcome)** — What it enumerates: The "Core concepts and tasks" feature-area list — asset management, cost accounting, cost management, inventory management, Sensor Data Intelligence (preview), master planning, demand planning, unified pricing management, procurement and sourcing, product information management, engineering change management, production control, rebate management, sales and marketing, service management, transportation management, landed cost, warehouse management · Anything named for S&OP: None
**[Supply Chain Management documentation hub](https://learn.microsoft.com/en-us/dynamics365/supply-chain/) — What it enumerates: The "Use" section's functional groupings, including a Master planning** grouping linking the master planning home page, DDMRP, the demand planning home page, master plans and planned orders · Anything named for S&OP: None
**[Master planning home page](https://learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/master-planning-home-page)** — What it enumerates: "The three main planning processes" — master planning, forecast planning, intercompany master planning · Anything named for S&OP: None
**[Demand planning home page](https://learn.microsoft.com/en-us/dynamics365/supply-chain/demand-planning/demand-planning-home-page)** — What it enumerates: The five-step demand planning process — import data, create transformation, create forecasts, review and adjust forecast, export data · Anything named for S&OP: None
**Release plans, both current waves** — What it enumerates: 2026 release wave 1 (April 2026 through September 2026) and 2025 release wave 2 (October 2025 through March 2026) · Anything named for S&OP: None

Eighteen named feature areas, three named planning processes, five demand-planning steps, two waves of planned features. Nothing called sales and operations planning, and nothing described as consensus.

The map: every S&OP step to the asset that serves it

**Demand review** — The Dynamics 365 asset: Demand planning — import, transformation, forecast profiles including your own Azure Machine Learning model, review and adjust, with "version history" and "restorable versions of forecast values throughout the planning process" · Status: [GA]
**Handoff of the agreed demand number — The Dynamics 365 asset: A demand planning export profile**, which targets "the target company (legal entity) and forecast model ID to export the data to" · Status: [GA]
**Supply review** — The Dynamics 365 asset: Master plans. "you can set up as many plans as you like and run them as often as needed to fit your business requirements" — the scenario mechanism on the supply side is a second plan · Status: [GA]
**Long-horizon materials and capacity view** — The Dynamics 365 asset: Forecast planning, which "calculates gross requirements… and enables you to conduct long-term planning of materials and capacity" · Status: [GA]
**Cross-entity balancing** — The Dynamics 365 asset: Intercompany master planning, which "calculates net requirements across legal entities" · Status: [GA], with the orchestration caveat below
**Constraint check** — The Dynamics 365 asset: The capacity time fence on the master plan, plus finite capacity on the resources that matter · Status: [GA]
**Financial reconciliation — The Dynamics 365 asset: Finance's Generate budget plan from demand forecast** periodic process — see below · Status: [GA]
**Consensus, scenario comparison and sign-off** — The Dynamics 365 asset: No documented object · Status: —

The orchestration caveat is worth carrying into the design conversation, because it changes who runs the monthly cycle. Microsoft's Planning Optimization fit analysis lists intercompany planning execution under Planning Optimization as "This scenario isn't yet supported", adding that "It is possible to run the cross legal entity planning execution manually or by setting up sequentially scheduled batch jobs for each legal entity planning execution."

So a multi-entity supply review is a set of batch jobs somebody built and somebody maintains. That is a real cost line in an S&OP cycle and it is invisible on a capability matrix.

The gap, named precisely

Everything in the table above produces numbers. Nothing in it produces an agreement.

Three specific things are missing, and naming them precisely is the difference between a build and a wish list.

A scenario that spans demand and supply. Demand planning versions forecast values. Master planning lets you hold several plans. Neither gives you one object that says this demand version, run against this master plan, is the September case, so a scenario comparison is currently a human holding two screens.

A sign-off state. There is no documented status a demand number passes through on its way from proposed to agreed, and no record of who agreed to it. The forecast model your master plan names will happily accept an export that nobody approved.

A cross-functional workflow. Sales, operations and finance each have a place to put their view. There is no documented place to put the reconciliation between them.

None of that is a criticism of the product. An ERP is a system of record; consensus is a process, and processes vary more between two mid-market manufacturers than their bills of materials do. Shipping an opinionated consensus module would be the wrong call, and the absence is defensible.

The second gap: the financial leg

S&OP has three legs and only two of them are in the product. Microsoft's demand planning export page documents exactly two destinations: a Supply Chain Management instance, or a CSV file. Its own words for the second one are that a CSV "might be more useful for importing data into other systems."

We looked for a documented native path from an agreed demand plan into a finance budget and did not find one on the pages we opened. That is a gap in our verification as much as in the product, and we would rather say so than assert an absence we have not established as firmly as the module one. What we will say confidently: if your S&OP cycle reconciles units to revenue, that reconciliation is something you build or something you do in a spreadsheet.

What we build for the gap

This is a capability statement — how we architect it — and it is deliberately small, because the smallest thing that closes this gap is a consensus layer, not a planning system.

**Scenario record** — What it does: Binds one demand planning version, one named master plan and one cycle into a single object with an owner and a date · Where it runs: Dataverse
**Sign-off state model** — What it does: Proposed, in review, agreed, superseded — with the approver recorded against the transition, not against a comment · Where it runs: Dataverse, with the approvals surfaced in Teams
**Variance view** — What it does: The agreed scenario against the current demand planning output and the current plan, so the meeting argues about the delta rather than rebuilding the numbers · Where it runs: Power Platform, reading through the documented integration surfaces
**Controlled handoff** — What it does: The agreed number reaches the ERP through the demand planning export profile that already exists — target company, target forecast model — behind the approval step · Where it runs: Microsoft's own export path

The last row is the design principle. We do not touch the ERP core. The demand engine stays Microsoft's, the planning engine stays Microsoft's, the write path stays the documented one, and what we add is the state machine and the agreement that the product does not model. Dynamics remains the system of record; the consensus layer is the system of intelligence around it.

The counter-argument

"Buy a planning suite and get the consensus layer with it." Sometimes that is right, and three signals say so: genuine cross-plant sourcing choices where the plan has to decide which site makes it, a re-planning cadence faster than weekly, and an existing planning team that already works in scenarios and will use them on day one. Where those hold, a suite earns its licence.

Below that line, a planning suite is a second system of record, and the reconciliation between it and your ERP becomes a permanent job. The honest comparison is not suite-versus-nothing. It is suite-versus-a-scenario-object-and-an-approval-state, which is a much smaller thing than the suite sales cycle implies.

What to do this week

Open the Supply Chain Management welcome page and read the feature-area list yourself. Nothing in this article should be taken on trust when the check takes a minute.
Confirm which forecast model your live master plan names, and confirm that your demand planning export profile targets that model and that legal entity. A mismatch here means your consensus meeting is agreeing a number the plan never sees.
Count the working days your current reconciliation takes, across all the people in it. That count is the business case, and it is usually larger than anyone has written down.
Ask who signs off the demand number, and where that signature is recorded today. If the answer is a meeting and an email, you have found the object to build.

Where we would draw the line

We would not rebuild forecasting on Power Platform. The demand planning app already carries the algorithms, the versioning and the documented export path, and replacing it would be a large project to arrive back where you started. We would not put the consensus layer inside the ERP as custom tables, because a process that changes every eighteen months does not belong in the object that has to survive upgrades. And we would not start any of this before the demand baseline is trusted — a consensus process built over a forecast nobody believes is a meeting with better formatting.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

If you are scoping an S&OP cycle on Dynamics and want the consensus layer designed rather than described, book a call and we will walk the scenario object and the sign-off model with you. https://cognilium.ai

There is no S&OP module in Dynamics 365 — so what do you build?