Not All BOMs Are the Same, and That Distinction Cost Us a Redesign
A Bill of Materials is not one object, it is a family of structures, and picking the wrong one is an architecture mistake, not a data entry preference. EBOM vs MBOM, single vs multi level, phantom and planning BOMs, and the provincial-SKU redesign that taught me the difference.
Most people who touch supply chain data treat "the BOM" as a single, self-evident thing: a list of what goes into a product. In practice, a Bill of Materials is not one object. It is a family of structures, each built to answer a different question, and each with its own rules for how it should be maintained in an ERP system. Confusing one type for another does not just create messy documentation. It creates rework, duplicated maintenance, and in some cases a redesign of how a company models its own product line.
Engineering BOM vs. Manufacturing BOM
The Engineering BOM (EBOM) reflects how a product is designed. It is organized by function, grouped the way an engineer or formulator thinks about the product's composition. The Manufacturing BOM (MBOM) reflects how the product is actually built on the floor: the sequence components are consumed in, the packaging steps, the labels, the intermediate outputs. In most ERP systems, including Dynamics 365 Business Central, the structure that drives production orders and MRP is functionally an MBOM, even when nobody in the company uses that label. The gap between the two matters most when engineering releases a change and nobody translates it into how the floor actually consumes the update.
Single-Level vs. Multi-Level BOM
A single-level BOM lists only the direct components of a parent item, one layer down. A multi-level BOM explodes the full structure: sub-assemblies, their own components, down to raw materials. Single-level views are enough for a quick check of what a work order needs. Multi-level structures are what MRP actually runs on, and what standard cost roll-ups depend on. A system that only maintains single-level BOMs accurately will misprice anything with more than one layer of sub-assembly, because the cost of the sub-assembly never properly rolls up into the parent.
Phantom BOM
This is the type that causes the most confusion, and the one worth spending time on. A phantom BOM describes a sub-assembly that exists in the BOM structure for planning and costing purposes, but is never actually stocked, purchased, or produced as a standalone item. It gets consumed instantly into its parent during production. The classic use case is a shared component that feeds multiple finished products: model it once as a phantom, and every product that uses it inherits the same cost and component structure without duplicating the recipe everywhere it appears.
I ran into this directly while working on master data for a cannabis producer. The company sold the same core product across multiple Canadian provinces, and because provincial packaging and labelling requirements differ, each province required its own Item Card, its own SKU, and its own GTIN. My first instinct was to use BOM Versions to manage the shared recipe across those variants from a single base structure. It does not work that way. BOM Versions only apply within a single Item Card. They cannot be shared across separate Item Cards, no matter how identical the underlying formulation is.
The actual fix was recognizing that the common base product, before province-specific labelling and packaging, needed to be modeled as a shared sub-assembly, structured as a phantom BOM feeding into each provincial finished good. That centralized the core formulation in one place. Change the recipe once, and every provincial variant inherits it, instead of someone having to remember to update the same recipe in a dozen different Item Cards every time it changes. The lesson was not really about BOM Versions or phantom BOMs as features. It was that the type of BOM structure you choose is an architecture decision, not a data entry preference, and getting it wrong scales your maintenance burden with every SKU variant you add.
Planning BOM (Percentage or Configurable BOM)
This type is less about production and more about forecasting. A planning BOM models a product family using percentage splits or optional components, useful when a company sells a base product with predictable variation in how customers configure it. It is not meant to drive a production order directly. It exists to give demand planning a way to forecast at the family level and then break the forecast down into its likely component mix, without needing exact certainty on the final configuration ahead of time.
The point of knowing the difference
None of this is academic. Every one of these BOM types exists to support a specific decision: costing accuracy, MRP explosion, production execution, or demand forecasting. Picking the wrong type for the decision you actually need to support is how companies end up with BOM structures that technically work but require constant manual patching to stay accurate. The real skill in master data work is not memorizing the taxonomy. It is recognizing, before you build anything, which question the structure in front of you is actually supposed to answer, and rebuilding it the moment the business outgrows the answer it was designed for.