The plant manager runs the Monday morning production meeting and the available-to-produce number for the flagship product looks healthy. Three thousand units, comfortably above the weekly target. Raw material inventory looks fine. The schedule holds. By Wednesday, the line is down, waiting for a pre-mix that nobody ordered because nobody realized the pre-mix had run out. The pre-mix is a sub-assembly. It has its own BOM. Its components were on the stock report but nobody was tracking whether the pre-mix itself was ready to run. When it finally gets built, the sub-assembly takes four hours and consumes a solvent that is now short because it was never reserved. Two more days get lost. By Friday, the week is a writeoff and somebody in the operations meeting says what everybody already knew: the BOM we are planning against is a simplification. It treats the pre-mix as if it were a purchased input, but we make the pre-mix ourselves, and that little fact is what breaks the plan every few weeks. This is the single-level planning failure that multi-level BOMs exist to solve, and it is more common than most manufacturers admit.
The Seductive Simplicity of Flat BOMs
Flat BOMs are easier to build, easier to read, and easier to explain. They list every material that goes into a finished product, often one level deep, and treat everything else as atomic. They are perfectly adequate for products that are genuinely single-level: pure assembly operations where every input is purchased and no internal transformation happens. The problem is that almost nothing in modern manufacturing is actually single-level. Food and beverage products use pre-mixes and concentrates. Personal care products use pre-blended bases. Mechanical assemblies use sub-assemblies that are built from components. Electronics use printed circuit boards that are themselves built from a BOM of surface-mount components. In all of these cases, the flat BOM is a convenient fiction that hides the real material dependencies.
The fiction has a cost. When planning runs against a flat BOM, the planner sees what the finished good needs but not what the sub-assemblies need. They see the surface of the material tree, not the branches. Reservations happen only at the surface level. Availability checks happen only at the surface level. If a sub-assembly is in stock, everything looks fine. If a sub-assembly is not in stock but its components are, the flat BOM cannot tell the planner that the sub-assembly itself needs to be built, and that building it will consume its own set of materials that also need to be reserved.
This is why multi-level BOM manufacturing is not a nice-to-have. It is the difference between a plan that reflects what it takes to actually build the product and a plan that reflects a convenient summary of what the product contains. The two are not the same, and the gap between them is where production schedules go to die.
What BOM Explosion Actually Does
BOM explosion is the process of recursively expanding every component in a BOM to its full set of primitive inputs. If a product's BOM contains a sub-assembly, the sub-assembly's BOM is expanded. If that sub-assembly contains another sub-assembly, it too is expanded. The process continues until every component is an item, not a product, and the full material tree is flattened into a complete picture of what it takes to build the finished good from purchased inputs alone.
Exploded BOMs are what planning systems actually consume. Reservation logic operates on the exploded tree. Availability checks operate on the exploded tree. Cost rollups operate on the exploded tree. If the explosion is missing or incomplete, every downstream calculation is wrong in a way that is hard to detect and harder to correct. A product might have a beautifully clean top-level BOM and still be unplannable because one of its sub-assemblies has an incomplete BOM of its own.
Three things have to be right for explosion to work correctly. Every product in the tree has to have an active BOM, not just the finished good. The BOM tree has to be acyclic, meaning no product can eventually contain itself as a descendant. And the explosion has to be triggered consistently, whenever availability is checked or reservations are made, so that planning stays in sync with the current state of the tree. FalOrb enforces all three: every product can carry a BOM, circular references are detected with explicit error reporting before they become runtime failures, and the explosion runs every time ATP is calculated, materials are reserved, or a production order is confirmed. This is what it means to treat multi-level BOMs as a first-class primitive rather than as a flattened approximation.
The ATP Bottleneck at Depth
Available-to-produce calculations become much more interesting when they operate on an exploded BOM. The ATP of a finished good is constrained by the material with the lowest relative availability across the entire exploded tree, not just the top level. If a sub-assembly is short, the finished good ATP drops. If a component of a sub-assembly is short, even if the sub-assembly itself is in stock, the ATP drops too once the sub-assembly stock is consumed. The planning system that does not understand this will report inflated ATP numbers until the moment reality catches up, usually mid-production.
The atp bottleneck is the specific material that is constraining the ATP at any given moment. Identifying it requires walking the exploded tree and comparing each material's availability against what the BOM requires. In a flat BOM world, the bottleneck is always a direct input. In a multi-level world, the bottleneck can be four levels deep, inside a sub-assembly of a sub-assembly, and the planner needs to know exactly which material it is so they can act on it. FalOrb identifies the specific bottleneck material when ATP drops below configured thresholds, which turns a vague "we cannot produce this" into a specific "we need 200 kilograms of this particular raw material, which is used inside this specific sub-assembly." That specificity is what makes the data actionable for procurement or inter-location transfer.
The piece at /blog/available-to-promise-metric-factory-floor covers the mechanics of ATP in more detail. Multi-level explosion is what keeps ATP honest when the BOM tree has any real depth. Without it, the ATP number is a lie that happens to be true when every sub-assembly is in stock.
Reservations That Net Through Sub-Assemblies
The other place multi-level matters is in reservation logic. When a production order for a finished good is confirmed, the system needs to reserve the materials required to build it. In a flat BOM world, those reservations are always on items, and the logic is simple: total required quantity for each item is summed and reserved. In a multi-level world, the reservation logic has to ask a more subtle question for every sub-assembly: do we have enough of this sub-assembly in stock to satisfy the requirement, or do we need to build more, and if we need to build more, what items does that require?
This is where make-to-stock subassemblies differ from build-on-demand subassemblies. If a sub-assembly is make-to-stock, the system can draw from existing sub-assembly inventory and only recurse into its BOM when the sub-assembly stock runs out. If a sub-assembly is always built-on-demand, the system recurses immediately and reserves the raw materials for the sub-assembly along with the finished good. Both modes are legitimate, but they produce very different reservation patterns, and the planning system needs to represent the choice explicitly.
FalOrb handles this with a per-product flag that controls whether the explosion uses stock sub-assemblies or always recurses to raw materials. The flag ties directly into ATP and reservation logic, so the same product can be modeled either way depending on the operational reality. This is important because many manufacturers run hybrid strategies: some sub-assemblies are kept in stock because they are used across many finished goods, while others are always built-to-order because they are product-specific.
Phantom BOMs and the Limits of the Model
Not every multi-level BOM is made of real, stockable sub-assemblies. Some are phantom BOMs: organizational conveniences that group related materials into a logical cluster without ever physically existing as a distinct item. A phantom sub-assembly might represent a solution of several solvents that is mixed on the line and immediately consumed. It never exists as a stockable item, never has its own inventory record, and never gets reserved independently. Treating a phantom BOM as a real sub-assembly creates friction. The system keeps asking where the sub-assembly is stocked. Operators keep having to create zero-quantity adjustments to make the reservation logic work.
The fix is to either model the phantom BOM explicitly with semantics that let the system treat it as a pass-through for explosion purposes, or to flatten the phantom into its parent BOM and accept the duplication. FalOrb's sub-assembly configuration flag covers this use case naturally: setting a sub-assembly to not use stock means the explosion always recurses to raw materials, which is exactly what a phantom BOM needs. The parent BOM stays clean, the sub-assembly grouping stays logical, and the reservation logic does the right thing.
Knowing when a sub-assembly should be a real stockable item, a make-to-stock sub-assembly with its own inventory, or a phantom BOM is a modeling decision that depends on operational reality. The question to ask is whether the sub-assembly ever exists as a discrete, countable thing that can be stored, moved, or counted independently of its parent product. If yes, it is a real sub-assembly. If no, it is a phantom BOM or it should be flattened.
When Flat BOMs Are Actually Fine
There are cases where flat BOMs are genuinely sufficient. Pure assembly operations with no internal transformation. Products where every input is purchased. Manufacturing environments where sub-assemblies are always supplied by external vendors rather than built in-house. In these cases, multi-level modeling adds complexity without adding information, and a flat BOM is the right choice. The trap is assuming your operation fits this profile when it actually does not. The quick test is to look at your BOM and ask: are any of these line items things we build ourselves? If the answer is yes, even for a small number of components, you have a multi-level BOM whether you model it or not. The difference is whether your planning system knows about it.
For background on how a spreadsheet-based approach to BOM and inventory data breaks down at scale, the piece at /blog/why-spreadsheet-inventory-fails-at-scale walks through the specific failure modes. Multi-level BOM modeling is one of the capabilities spreadsheets cannot realistically support because the recursion, the reservation logic, and the explosion all require real computation that a spreadsheet cannot do reliably.
The payoff of doing multi-level planning correctly is not that you produce more. It is that the plan you make is the plan you can actually execute. ATP numbers reflect real buildable capacity. Reservations cover real material needs. Shortages surface before they become shop floor surprises. That is the real value of multi-level bom manufacturing: not complexity for its own sake, but a plan that does not silently lie to you about what you can make.
FalOrb helps manufacturers plan with multi-level BOMs that reflect operational reality through full BOM explosion, bottleneck material identification in ATP, reservations that net through sub-assemblies, and circular reference detection. Book a 30-minute walkthrough or email us at [email protected] to see how it applies to your operation. Learn more at falorb.com.