How MTO and MTS Behave Differently with Multi-Level Production Orders in Business Central

 Introduction

Most articles explain MTO and MTS in the context of a single finished product. But real manufacturing operations rarely have a single BOM level. If you produce sub-assemblies that feed into other sub-assemblies that feed into finished goods — which is extremely common in discrete manufacturing — the behavior of MTO vs MTS becomes significantly more complex, and the implications for your production planning process are substantial.

This post focuses exclusively on that one topic: how MTO and MTS behave differently when you have a multi-level production BOM in Business Central. No discussion of reordering policies, no planning worksheet theory — just the production order behavior at each BOM level, and what it means for your team.

---

The scenario

Let us set up a clear example that we will use throughout this post.

You manufacture a Finished Good (FG). To produce it, you need Semi-Finished Good 1 (SFG1) as a BOM component. To produce SFG1, you need Semi-Finished Good 2 (SFG2) as a BOM component. SFG2 is made from raw materials.

So your BOM structure looks like this:

FG  (Level 0 — Finished Good)

 └── SFG1  (Level 1 — Semi-Finished Good)

      └── SFG2  (Level 2 — Semi-Finished Good)

           └── Raw Materials  (Level 3 — Purchased)

This is a three-level production BOM — a structure that is very common in industries like automotive components, industrial equipment, packaging machinery, electronics assembly, and engineered products.

Now — what happens when a sales order is created for the FG, and you trigger production planning? The answer depends entirely on whether your items are configured as MTO or MTS. And the difference is dramatic.

---

Scenario A — All items configured as MTO (Order policy)

When all three items — FG, SFG1, and SFG2 — are configured with the Order reordering policy (Make-to-Order), Business Central's behaviour is as follows:

One production order is created for the FG. But this is not a simple single-level production order. Because SFG1 is also an MTO item, BC does not treat it as a component to be picked from inventory. Instead, it recognises that SFG1 must itself be produced — and it creates the SFG1 production requirement as a line within the same production order.

Similarly, because SFG2 is also an MTO item, its production requirement is added as another line within the same production order.

The result: one production order with three production lines — one for FG, one for SFG1, and one for SFG2 — all contained within a single production order document.

The reservation chain works level by level — not directly to the sales order at every level. Specifically:

• SFG2 is reserved against SFG1 (SFG2 output feeds SFG1 as a component)
• SFG1 is reserved against FG (SFG1 output feeds FG as a component)
• FG is reserved against the Sales Order — but only if the production order was created directly from the sales order, or if a manual reservation was made between the FG production order and the sales order

What this means operationally:

• Your production planner sees one production order to manage — not three
• Each BOM level is reserved against its parent level — the chain is intact but works level by level
• There is no risk of SFG1 or SFG2 being consumed by another order, as long as the reservation chain is properly established
• Shop floor supervisors see all three production steps within one document
• Costing flows cleanly from SFG2 → SFG1 → FG within the single order

This is the key insight for MTO: the multi-level BOM is collapsed into a single production order with multiple lines. The sub-assembly items are not treated as inventory items to be picked — they are treated as production steps within the parent order.

---

Scenario B — All items configured as MTS (Non-Order policy)

Now let us take the exact same three-level BOM structure, but this time all items — FG, SFG1, and SFG2 — are configured as Make-to-Stock.

When a sales order is created for the FG and you trigger production planning, BC's behaviour is fundamentally different:

One production order is created for the FG only. The BOM component is SFG1, but because SFG1 is an MTS item, BC treats it as an inventory item. The production order for FG simply calls for SFG1 as a component — it does not automatically create a production order for SFG1.

Similarly, the production order for SFG1 (when it is eventually created) calls for SFG2 as a component — but does not automatically create a production order for SFG2.

The result: three separate, independent production orders — one per BOM level.

And here is the critical point that most documentation misses: BC does not automatically create the production orders for SFG1 and SFG2. Those sub-assembly production orders must be created separately.

You have two ways to create them:

Option 1 — Manual creation. The production planner recognises that SFG1 is short and manually creates a production order for it. Then recognises SFG2 is short and manually creates a production order for that too. This works, but it requires planner awareness and discipline — the system does not prompt you automatically.

Option 2 — Replan function. From the FG production order, you can use the Replan function. This tells BC to look at the components of the FG production order, identify which ones are produced items with insufficient stock, and create production orders for them.

What this means operationally:

• Three separate production orders exist — one per BOM level
• Each order is independent — there is no system-enforced link between them
• SFG1 and SFG2 inventory can be consumed by any other demand, not just this FG order
• The production planner must actively manage the relationship between the three orders
• If SFG2 is delayed, the FG production order has no automatic visibility of that delay
• Costing flows separately through each production order

---

Side by side — the critical differences

Aspect	MTO — All levels Order policy	MTS — All levels non-Order policy
Number of production orders created	1 (with multiple lines)	3 (one per level)
Sub-assembly orders — how created	Automatically, within parent order	Manually or via Replan function
Reservation	SFG2 reserved with SFG1, SFG1 reserved with FG, FG reserved with Sales Order (if linked)	No automatic reservation across levels
Order tracking	Full visibility across all levels	No cross-level link
Risk of sub-assembly consumed by another order	None — fully reserved	Yes — SFG1/SFG2 available to any demand
Planner workload	Lower — one order to manage	Higher — three orders to coordinate
Visibility of sub-level delays	Immediate — within same order	Not automatic — requires manual monitoring
Suitable for	Custom/unique products, regulated industries	Standard products with independent sub-assembly stock

---

Which setup is right for your operation?

The honest answer is: it depends on whether your sub-assemblies are shared across multiple finished goods or unique to one.

Use full MTO (Order policy at all levels) when:

• Your sub-assemblies are unique to each finished good and would never be used for any other product
• Full customer-to-production traceability is required (regulated industries, serialised products)
• You want zero risk of a sub-assembly being consumed by a different order

Use MTS at sub-assembly level when:

• The same SFG1 or SFG2 is used across multiple different finished goods
• You want to build sub-assemblies in economic batch quantities regardless of which FG they will ultimately feed into
• Your sub-assembly production cycle time is long enough that you need to start it before the FG sales order is confirmed

---

Final thought

The multi-level production order behavior in BC is one of those topics that only becomes visible once you are running a real manufacturing environment. In a demo or a single-level BOM test, MTO and MTS look similar enough. Add two or three BOM levels and the operational difference becomes significant — one production order vs three separate ones that you have to manually coordinate.

Understanding this before go-live lets you make an informed decision about your policy setup. Understanding it after go-live — when your planners are manually creating sub-assembly orders that the system should be handling — is a more expensive lesson.