What Is a Multi-Level BOM and How Do You Manage One?

Ask someone to describe a Bill of Materials and they'll usually describe a spreadsheet: a list of parts, quantities, and supplier info. For simple products, that's accurate enough. But for most electronics hardware — anything with more than a handful of functional blocks — that model breaks down quickly.

Real products are built from sub-assemblies. Sub-assemblies are built from other sub-assemblies and raw components. This hierarchy is what makes a multi-level BOM, and managing it properly is one of the defining challenges of electronics manufacturing.

What Is a Sub-Assembly?

A sub-assembly is a group of components that are built, tested, and stocked as a distinct unit before being incorporated into a higher-level assembly. In electronics, this is extremely common:

• A custom power supply board used across multiple product variants
• A sensor module that ships as a standalone unit and as part of a larger system
• A display assembly that's built, tested, and packaged separately from the main PCB

Each sub-assembly has its own BOM. That BOM might itself contain other sub-assemblies. The result is a tree — not a flat list.

Single-Level vs. Multi-Level: Why It Matters

A single-level BOM lists only the direct children of an assembly. If your product contains a power module sub-assembly, the single-level BOM shows "Power Module × 1" — it doesn't tell you what's inside the power module.

A multi-level BOM expands the entire tree. It shows the power module and all of its components, recursively, down to the raw part level. This is what you need for procurement, since you can only buy raw components — not sub-assemblies — from a supplier.

The Shared Parts Problem

Here's where multi-level BOM management gets genuinely difficult: sub-assemblies often share components.

Imagine a product with three sub-assemblies. Each one uses the same 100nF 0402 capacitor — say, 10 per board. Across the three sub-assemblies you need 30 of that capacitor to build one finished unit. If you're building 500 units, you need 15,000 of that capacitor.

Now imagine that number appearing in three separate BOMs, and someone needs to calculate the total procurement requirement. Manually, this means:

1. Explode each sub-assembly BOM to its raw components
2. Sum identical components across all sub-assemblies
3. Multiply by build quantity
4. Repeat for every component in every sub-assembly

For a product with 5 sub-assemblies and 200 unique components, this is hours of spreadsheet work — and one formula error means ordering the wrong quantity of a part you might not be able to get for 12 weeks.

BOM Explosion: Letting the System Do the Work

BOM explosion is the process of traversing a multi-level BOM and calculating the total raw component requirements for a given build quantity. A system that handles this properly:

• Recursively expands all sub-assemblies to their leaf components
• Aggregates quantities for components that appear in multiple sub-assemblies
• Accounts for yield loss and scrap factors per assembly level
• Produces a single consolidated procurement list

Managing Revisions Across Sub-Assemblies

Multi-level BOMs introduce a revision management challenge: a change to a sub-assembly affects every parent assembly that uses it. If you swap a component in your power module, every product that includes that power module is affected.

This means you need to track:

• Which revision of each sub-assembly was used to build a given unit
• Which products are affected when a sub-assembly changes
• Whether older revisions of a sub-assembly are still in stock and usable

Without clear revision control at every level of the hierarchy, traceability breaks down. You lose the ability to answer the question that matters most when something goes wrong in the field: exactly which components were in this specific unit?

A Practical Approach

Managing multi-level BOMs well comes down to three things:

1. Model the hierarchy accurately — don't flatten sub-assemblies into the top-level BOM for convenience. The structure matters.
2. Explode to components for procurement — never buy based on sub-assembly quantities alone.
3. Lock revisions before production — a released BOM at any level should be immutable for a given production run.

BOMIST handles multi-level BOMs natively, including full BOM explosion, shared component aggregation, and revision tracking across every level of your assembly hierarchy.