MTO vs ETO in D365 F&SCM: choosing the right production principle

The symptom: dates promised on routes that do not exist

The classic signal looks like this: sales confirms a system-calculated delivery date, then the engineering phase pushes everything back by weeks. The customer calls, production defends itself, and the system takes the blame. But the system got nothing wrong: it calculated a date from the data you gave it, meaning a BOM and route declared final when they were anything but.

Every delivery promise in D365 rests on BOM and route data. If that data is provisional, or worse, does not exist yet, the resulting date is fiction with decimal places. The choice between MTO and ETO is not a configuration detail: it decides which data exists at the moment the promise is made.

MTO in D365: the sales order triggers production, not design

In make-to-order, the BOM and route already exist, approved and released, before the order lands. The sales order generates the requirement, planning creates the production order, and the product is built on stable engineering data. This is the flow Microsoft describes among D365's manufacturing principles: the sale triggers production, not design.

D365 also supports this flow in automated form: make-to-order supply automation creates and links planned production orders directly from sales lines. It works well for standard products with limited variation, when the lead time your customer accepts covers production and procurement. It does not need to cover development, because there is none.

ETO in D365: design first, then production

Engineer-to-order runs the opposite way. You start from a project, not from a catalog item. The BOM and route are created during the engineering phase, and only once that phase produces released engineering data can production orders exist. Microsoft's business process glossary is explicit about this sequence: in ETO, design is part of order fulfillment.

The operational consequences are concrete: project-based management, BOM versions that evolve during the work, costs tracked against the project, and delivery dates you can defend only after engineering has consolidated the BOM and route. Treating an ETO product with MTO logic skips this phase on paper, never in reality: the design time does not disappear, it just becomes invisible to the system.

The framework: four questions before you configure

The criterion that matters is not product complexity. A highly complex product can be MTO if its BOM is known and stable; a simple product can be ETO if every job redesigns it. Before choosing a production principle in D365, I answer four questions:

• How much of the BOM do you know before the order lands? If the answer is "almost all of it", you are in MTO territory. If it is "depends on the project", you are not.
• Does the lead time your customer accepts cover only production and procurement, or must it cover design as well? If engineering eats the lead time, you are in ETO.
• Does the production route already exist when sales promises the date? If the date is promised before the route, the system cannot defend it.
• Do the answers above change from one order to the next? If so, you are not picking a setting: you have two business models in the same catalog.

When MTO is perfectly fine, and when the system is not the problem

Not everything that looks custom is ETO. If product variants are known combinations of predefined options, you are in configure-to-order territory: the BOM is generated from configuration rules, not from an engineering phase. Setting up an ETO flow there adds project bureaucracy without adding control.

The honest reverse also holds: ETO has a cost. It demands project discipline, BOM version management, and integration between engineering and production. If genuinely engineered jobs are only a handful per year, it is often better to handle them as controlled exceptions than to reshape the operating model of the whole catalog.

And one limit survives any configuration: if your sales process promises dates before engineering is done, no production principle in D365 will make those dates reliable. The system reflects the business model; it does not fix it.

Where to start

The starting point is not configuration, it is the catalog. For each item family, measure how much of the BOM is known before the order and compare the real engineering time against the lead time customers accept. From there the classification emerges on its own: true MTO, true ETO, and the hybrid band, which is where the problems hide.

For the hybrids, the decision has to be made case by case, but it has to be made: an item sold as MTO that behaves as ETO will keep producing missed dates until someone decides which of the two it is. Only after this classification does it make sense to open D365 and configure production principles. Doing it earlier means choosing the most familiar setting, not the right one.