BOM Levels Explained: Indenture, Parents, Children and How Deep to Go

What BOM levels actually mean

A level is a depth, not a rank. Level 0 sits at the top of the tree and every number below it counts how many steps away from the finished product an item is.

• Level 0 — the finished good you sell. One item, one part number, one set of instructions for how to build it.
• Level 1 — everything consumed directly to make that finished good: sub-assemblies you build yourself, and purchased parts that go straight in.
• Level 2 — everything consumed to make the level 1 sub-assemblies.
• Level 3 and below — the same logic, repeated, until you reach an item that is bought rather than built.

The point where numbering stops is the point where you stop making something. A part you buy in, put on a shelf and issue to a job has nothing beneath it in your structure, even if the supplier’s own factory has eleven levels behind it. Their indenture is their problem.

Wikipedia’s definition of the display form is exact about the visual convention: an indented BOM “displays the highest-level item closest to the left margin and the components used in that item indented more to the right” (Bill of materials). One step of indent equals one level of depth. That is the whole notation.

If the underlying concept is still fuzzy, start with what a bill of materials is and come back. If you are trying to decide whether you need depth at all, that comparison is settled separately in single vs multi-level BOM — this piece assumes you have depth and need to structure it.

How to read an indented BOM without misreading the quantities

The mistake that costs real money is reading every quantity column as “per finished unit”. It is not. On a properly built indented BOM, quantity is per parent, not per top-level item.

So a level 2 line reading “4” means four of those per one of its level 1 parent. If that level 1 parent appears twice in the level 0 product, the true requirement per finished unit is eight. That multiplied-down figure is the extended quantity, and it is the only number purchasing should ever be handed.

Two habits stop this going wrong:

1. Print the indent, not just the list. Any system worth using lets you choose how far to expand. Oracle’s Bills of Material guide describes the standard control plainly — when viewing an indented bill you “enter the revision, the revision date, and the number of levels to explode for this bill” (Oracle Bills of Material User’s Guide). Expanding one level at a time while you check quantities is slower and correct.
2. Keep a separate extended view for buying. Same data, flattened, quantities multiplied through, grouped by part. Nobody should be doing that arithmetic by hand on a Friday afternoon.

The reverse query matters just as much. Wikipedia puts the pair neatly: an implosion “links component pieces to a major assembly”, while an explosion “breaks apart each assembly or sub-assembly into its component parts”. When a supplier discontinues a connector, that where-used view is the difference between knowing in ten seconds and finding out in six weeks.

Parents, children and the vocabulary that trips people up

The terminology is small and worth getting right, because half the confusion in BOM conversations is two people using the same word for different things.

An item can be a parent in one BOM and a child in another. A powder-coated bracket is a parent to steel and paint, and a child to the frame it bolts into. That is why “level” is a property of a relationship, not of a part — which matters the moment the same part appears at two different depths.

A worked example: four levels of a battery pack

Take a modest product — an e-bike battery pack, built in batches of 200. Here it is as an indented BOM, with quantity per parent and the make-or-buy call that decides whether the branch continues.

Four levels, sixteen lines. Note where the tree deliberately stops: the populated PCB is bought as a single part number. It has hundreds of components behind it, and every one of them is the contract manufacturer’s business. Adding level 4 for resistors would add hundreds of rows and change not one purchasing decision.

Now flatten it. Cells sit at level 2 under a module that appears twice, so the extended quantity per pack is 20 × 2 = 40. Connectors sit at level 3 under a loom that appears once, under a board assembly that appears once, so the extended quantity is 2 × 1 × 1 = 2. For a batch of 200 packs, with illustrative unit costs:

The cells are roughly 78% of that sample cost and they sit at level 2, reached only by multiplying through a module that appears twice. Take that level 2 quantity of 20 as if it were per finished pack and you would have bought 4,000 cells for a 200-pack run instead of 8,000, and stopped the line halfway through. That is the practical argument for indenture: the depth is where the money is, and a single missed multiplication is the whole shortage.

It also shows why level 3 earns its place. Eighty metres of cable and four hundred connectors are small money, but they are the parts nobody notices missing until a loom cannot be finished. Keeping the loom as a real sub-assembly means the shortage appears in planning rather than at the bench.

Low-level codes: the number your system uses instead of the indent

Here is where most explanations stop and most real systems begin. The indent you see on a printed BOM is a display artefact. The number planning actually runs on is the low-level code: the deepest level at which a part appears anywhere across all your products.

Suppose the same JST connector is a level 3 item inside the battery loom and a level 1 item on a simple charger cable you also sell. Its low-level code is 3, because that is the deepest it goes. Planning has to process every level 1 and level 2 requirement before it nets the connector, or it will calculate a requirement, place an order, and then discover more demand one level further down.

Oracle’s JD Edwards documentation states the mechanism directly: “the system uses the low-level code to determine parent and component relationships” and “the system explodes parent demand to the components” (Low-Level Code). The same page notes the stopping rule that mirrors the make-or-buy call above: “the system does not explode demand to levels below a purchased item, even if that item has a bill of material.”

Two things follow for anyone building or buying a system:

• Low-level codes should be calculated, never typed. They change whenever a BOM changes, and a stale code silently breaks netting.
• A part appearing at two depths is normal and fine. A part appearing inside its own tree is not — that is a circular BOM, and it will either loop forever or fail loudly. Any structure you build needs a cycle check before it saves.

When a sub-assembly earns its own BOM

Not every grouping deserves to be a level. The useful way to decide is to ask what the level would give you that you do not already have, and the answer is always one of four things: a stock figure, a planning signal, a cost, or a part number someone outside the building can order. If a grouping is never counted, never batched ahead, never costed on its own and never sold or subcontracted, it produces none of the four and the level is decoration. Applying that test product by product is the first job in the setup walkthrough linked at the end; depth has to be earned by an output, not by the drawing looking tidier with it.

Microsoft’s Dynamics 365 documentation frames the underlying data model in one line: “a single BOM describes a single level that is identified by a unique ID. Components might have their own BOMs that are referenced by BOM versions” (Bills of materials and formulas). Depth is nothing more than BOMs referencing BOMs. Every reference you add is a real object someone has to version, approve and keep current.

If the level produces none of the four outputs, the grouping is a convenience for the person reading the drawing. Which is a legitimate thing to want — it just should not become a stocked item with a life of its own. That is what phantoms are for.

When a level should be a phantom instead

A phantom is a level that exists in the structure but never exists in the warehouse. It is built and consumed within the same operation, so planning collapses it on the way through.

The Dynamics 365 phantom documentation walks a two-level example where an electrical unit and a packaging group are marked phantom, and describes the result as one in which “there’s no notion of parts F and G” any more — their materials simply move up to the next BOM level. The design view keeps its tidy grouping; the production order sees a flat list of the things actually picked.

That is usually the right answer for a grouping that buys you none of the four outputs. In the battery example, if the loom were always built at the bench during pack assembly and never stocked, making it a phantom would keep the three cable lines organised without inventing an item nobody can count.

Microsoft’s main BOM article, cited above, is blunt about overusing them: “Extensive use of phantom BOMs in many levels has an effect on performance, especially in highly repetitive manufacturing scenarios. To improve performance, you should avoid deep hierarchies of phantoms.” Phantoms are a labelling device, not a way to have unlimited depth for free. The distinction between the various flavours of BOM this creates is covered in types of bill of materials.

How deep to nest before it costs more than it saves

Every level you add has a running cost, and it is rarely counted:

• A part number to create, describe and maintain a unit of measure for
• A BOM to version, approve and date
• Transactions somebody has to post when the sub-assembly is made and consumed
• A stock balance that can now be wrong, and a count line to reconcile it
• An extra hop in every engineering change, every cost roll and every where-used query

Against that, a level buys you visibility: a stock figure, a standard cost, a planning signal, a spare part you can sell. The test is simply whether the visibility is worth the admin. Practical stopping rules:

• Stop where a supplier takes over. If you buy it complete, it is a leaf. Their internal structure is not yours to model.
• Stop where you stop transacting. If nobody will ever post a receipt or issue against it, it does not need to be an item.
• Stop where the cost stops mattering. If a level’s total contribution is rounding error and it never causes a shortage, flattening it loses nothing.
• Keep the level if it is a bottleneck. Anything made ahead, in batches, on constrained equipment is worth its own visibility regardless of value.
• Keep the level if it is traceable. Lot or serial control at a sub-assembly is a hard reason to keep it real.

Applied honestly, those rules tend to leave a genuinely assembled product at three to five levels. Deeper than that is usually one of two things: an engineering structure that was imported wholesale and never converted for production, or a set of groupings that should have been phantoms. Neither is fixed by adding more discipline to the spreadsheet.

What breaks when the levels are wrong

Too shallow. Real sub-assemblies are flattened into level 1 lines, so everything a level exists to give you — a stock figure, a module cost, a spare part number, a work-in-progress balance — is simply absent. Whether you need depth at all is settled in the single vs multi-level comparison linked above; this is what it looks like when the answer was yes and the structure never caught up.

Too deep. Hundreds of part numbers that are never counted, BOMs nobody has approved since 2023, a cost roll that takes an afternoon, and engineering changes that require touching nine records to change one part. Staff route around it, which means the structure and reality drift apart quietly.

Inconsistently deep. The worst case, and the most common. Product A is nested three levels because the engineer who set it up liked structure; product B is flat because someone was in a hurry. Reports cannot be compared, and nobody trusts the numbers because they know the structures were built to different rules.

Right-sizing the structure without buying a full ERP

You do not need a PLM suite bolted to a two-year ERP programme to hold four levels of indenture properly. What the structure actually requires is short:

• A parts table with unit of measure, issue unit, and a make-or-buy flag that decides whether a branch continues
• A parent-child table with quantity per parent — the whole indenture is one self-referencing relationship
• Calculated low-level codes, recomputed whenever a BOM changes, with a cycle check that refuses circular structures
• An indented view for engineering, expandable a level at a time
• An extended, flattened view for purchasing, with quantities multiplied through
• A where-used query in both directions
• A phantom flag, so groupings can exist without becoming stocked items
• Version and effectivity dates, so you can tell which structure a job was built against

That is a small, well-understood piece of an owned operations system — the sort of thing that fits a business too messy for spreadsheets and not ready for a full ERP. The step-by-step build is covered in how to set up a multi-level BOM; this piece is about deciding what shape you are building before you build it.

FAQ

How many levels should a BOM have?

As many as you have places where something is stocked, batched, costed, traced or sold separately — and no more. Applied strictly, that usually leaves an assembled product at three to five. Depth is not a sign of sophistication; a structure with nine levels and no stock balances below level 2 is seven levels of admin doing nothing.

What is level 0 in a BOM?

Level 0 is the finished item at the top of the structure — the thing you sell, with its own part number. Everything indented beneath it is consumed to produce it. If a product is also sold as a component of something bigger, it will be level 0 in its own BOM and a level 1 child in the other, because level describes a position in a specific tree rather than a property of the part.

Does every sub-assembly need its own BOM?

No. It needs its own BOM when it is stocked, made ahead of the parent, sold or serviced separately, costed on its own, or made by someone else. If none of those apply, mark it as a phantom so the grouping stays visible in the structure without creating an item nobody can count.

What is the difference between a BOM level and a low-level code?

The BOM level is where an item sits in one particular product tree — it changes from product to product. The low-level code is the deepest level that item reaches across every BOM you have, and planning uses it to work out the order in which requirements must be netted. Your system should calculate low-level codes automatically; if anyone is typing them in, expect netting errors.

Sources

• Bill of materials — Wikipedia
• Bills of materials and formulas — Microsoft Dynamics 365 Supply Chain Management documentation
• Phantom items — Microsoft Dynamics 365 Supply Chain Management documentation
• Low-Level Code — Oracle JD Edwards EnterpriseOne Supply Chain Manufacturing documentation
• Oracle Bills of Material User’s Guide — indented bills of material