Multi-Level BOM Explained for Small Manufacturers

A multi-level bill of materials (BOM) is a parts list that includes sub-assemblies -- components that are themselves built from other components -- so the product is defined as a tree of parts within parts, not a single flat list. If you build anything more complex than a one-step product, you are already working with a multi-level BOM, whether or not your software calls it that.

Here is why it matters in practice. Say you make a desk lamp. The lamp is not just a pile of raw parts you assemble in one motion -- it contains a wired socket assembly and a weighted base assembly, each built first, then combined. A single-level BOM pretends that structure does not exist. A multi-level BOM captures it, and that captured structure is what lets your software order the right materials, cost the product accurately, and tell an operator what to build in what order. This guide explains single-level versus multi-level BOMs, walks through a worked example, and shows how nesting changes purchasing, costing, and production for a small shop.

A bill of materials is the recipe for a product: the complete list of components, quantities, and units of measure needed to build one unit of the finished good. If a product were a cake, the BOM is the ingredient list -- two cups of flour, three eggs, a stick of butter -- scaled to one cake.

A basic BOM has three columns that do most of the work: the component (what it is, often a part number), the quantity per unit of the parent, and the unit of measure (each, grams, meters, liters). Good BOMs add more -- a reference designator, a scrap or yield allowance, a supplier, a cost -- but component, quantity, and unit are the irreducible core.

The BOM is the backbone of manufacturing software because almost everything else references it. Purchasing uses it to know what to buy. Costing uses it to know what a product costs. Production uses it to know what to consume and in what quantity. Inventory uses it to know what to deduct when a build completes. Get the BOM right and the rest of the system has something true to stand on. Get it wrong and every downstream number inherits the error.

A single-level BOM lists only the direct components of one parent, one layer deep. For the desk lamp, a single-level BOM might read: one base assembly, one socket assembly, one lamp shade, four screws. It tells you what the lamp is directly made of, but it treats the base assembly and socket assembly as if they were purchased parts that appear by magic.

A multi-level BOM keeps going. It expands each sub-assembly into its own components, and those into theirs, until every branch ends in a raw material or purchased part. The base assembly explodes into a metal base plate, a weight, and two rubber feet. The socket assembly explodes into a socket, a switch, and a length of wire. Now the BOM reflects how the product is really built: in stages, from the bottom up.

The number of layers is the BOM's depth, or number of levels. A finished good is level 0. Its direct components are level 1. Their components are level 2, and so on. Most small-manufacturer products live at two or three levels. Complex machinery can run to a dozen. The moment your product has even one sub-assembly, you have crossed from single-level into multi-level territory -- and your software needs to handle it.

Let us make the desk lamp concrete. The finished product is one desk lamp (level 0). To build it, an operator combines two sub-assemblies and a few direct parts, and each sub-assembly is built first from its own components. As you read the tree below, watch its shape: two level-1 items are sub-assemblies you manufacture (the Base Assembly and the Socket Assembly), and two are parts you buy and drop straight into the finished lamp (the shade and the screws). Everything indented beneath a sub-assembly at level 2 is a purchased component that rolls up into the sub-assembly above it. The level number tells you how deep in the product each part sits, and every quantity is stated per one finished lamp -- so when you scale to a production run, the software multiplies down the tree from here. That small distinction between what you build and what you buy is exactly what a single-level BOM cannot express, and it is what makes the next three sections -- purchasing, costing, and production -- work:

When you plan to build 100 desk lamps, your software has to translate that into a shopping list -- and this is where multi-level structure earns its keep.

A single-level BOM would tell you to buy 100 base assemblies and 100 socket assemblies. But you do not buy those; you build them. So the system has to explode the BOM: walk down every branch, multiply quantities level by level, and total the raw materials at the bottom. One hundred lamps needs 100 base plates, 100 steel weights, 200 rubber feet (two per lamp), 100 sockets, 100 switches, 50 meters of wire (0.5 m each), 100 shades, and 400 screws.

Then it nets against stock. If you already have 60 rubber feet on the shelf, the purchase suggestion is 140, not 200. A multi-level BOM plus current inventory is exactly what material requirements planning (MRP) does -- it turns a production target into a net purchasing plan automatically. Do this by hand across a few dozen components and several sub-assemblies and you will make arithmetic errors, order the wrong quantities, and discover the shortage on the day you planned to build. The nesting is not academic. It is the difference between a purchase order that is right and one that stops the line.

Cost flows the opposite direction from purchasing -- it rolls up from the bottom of the tree to the top.

To cost the desk lamp, the system first costs each sub-assembly from its own components, then adds those sub-assembly costs (plus any direct parts and labor) into the finished good. The base assembly costs the sum of its base plate, weight, and two feet, plus the labor to assemble it. The socket assembly costs its socket, switch, and wire, plus its labor. The finished lamp costs both sub-assemblies, plus the shade, the four screws, and the final assembly labor.

This is called cost roll-up, and a single-level BOM cannot do it correctly, because it does not know what the sub-assemblies are made of. It would need you to hand-enter a cost for each sub-assembly and keep those numbers current every time a component price changes -- which nobody does reliably.

With a multi-level BOM, a price change at level 2 automatically ripples up to the finished-good cost. When the price of copper wire jumps, your lamp's cost updates without anyone touching a spreadsheet. In Deelo, that rolled-up cost also feeds actual-versus-standard variance and posts to the ledger in Accounting, so your quoted margin and your booked margin come from the same source.

Production reads the tree as a sequence. You cannot assemble the lamp before the sub-assemblies exist, so a multi-level BOM implies an order of operations: build the base assembly, build the socket assembly, then combine them into the finished lamp.

Good manufacturing software turns this into work orders that respect the hierarchy. Depending on how you run the shop, the sub-assemblies can be separate work orders (useful if you batch them, stock them, or send them to a subcontractor) or steps within the parent work order (simpler if you build straight through). Either way, the system knows the socket assembly consumes a socket, a switch, and wire, and it deducts exactly those from Inventory when that step completes -- not before.

This is why inventory stays honest. Each level consumes its own components at its own moment, so work-in-progress is tracked accurately rather than lurching from raw materials straight to finished goods. For a shop tracing quality or lot numbers, the multi-level structure also tells you which sub-assembly and which lot a defect came from, instead of just somewhere in the lamp. The tree is not just documentation; it is the map production actually follows.

There is one more reason multi-level structure matters, and it runs backward through the tree. A where-used lookup answers the reverse question: given a component, which products and sub-assemblies contain it?

Say your supplier discontinues the specific rocker switch in the socket assembly. Which of your products are affected? If you only sell desk lamps, that is easy. If you sell 40 products and that switch appears in nine of them, across several different sub-assemblies, a where-used lookup is the only fast way to know your exposure. Without it, you are searching through spreadsheets hoping you caught every one.

Where-used is also how you scope engineering changes, price-increase impacts, and recalls. Change a sub-assembly, and where-used shows every finished good that inherits the change. It is the single feature that separates a real BOM system from a folder of parts lists, and it only works if the software actually stores the nested structure rather than flattened snapshots.

Every serious MRP tool supports multi-level BOMs -- it is the price of entry. The differences show up in the surrounding features: version control so you can track engineering changes over time, a where-used lookup for supplier and recall exposure, one-click component explosion for purchasing, and whether the rolled-up cost actually reaches your accounting or stops at the edge of the MRP. Those four things separate a real BOM system from a glorified parts list, so they are what to test when you trial a tool. Here is how the common small-manufacturer options compare, with Deelo first.

Deelo Manufacturing handles nested BOMs with sub-assemblies, one-click component explosion, where-used lookup, and version control, and -- because Inventory and Accounting are native apps on the same platform -- the exploded materials drive real purchasing suggestions and the rolled-up cost posts straight to the ledger. The others below all handle multi-level BOMs competently; they differ mainly in how much of the back office comes with them, which is the column most people forget to check.