Bill of Materials: Single-Level vs Multi-Level
What a BOM records, how single-level and multi-level structures differ, where quantities multiply, and the details — scrap, effectivity, phantoms — that cause most BOM errors.
What a BOM is
A bill of materials is the recipe for a manufactured item: the components required to make one unit, and how many of each. Everything downstream depends on it. Material requirements planning explodes it to decide what to buy. Costing rolls it up to decide what the product costs. Production uses it to pick and issue parts.
Because so much is derived from it, a BOM error does not stay a BOM error. It becomes a purchasing error, then a costing error, then a margin that was never real.
Single-level
A single-level BOM lists only the immediate children of one parent — one step down, nothing further. For a desk lamp:
| Component | Qty | Type |
|---|---|---|
| Base assembly | 1 | Sub-assembly |
| Arm assembly | 1 | Sub-assembly |
| Shade assembly | 1 | Sub-assembly |
| Packaging set | 1 | Purchased |
It does not tell you what is in the base assembly. That is a separate single-level BOM belonging to the base assembly, which in turn names its own children.
This is how BOMs are actually stored, and the reason is reuse. If the arm assembly appears in six products, its structure is defined once. Change the screw in that assembly and all six inherit the change, because none of them held a copy.
Multi-level
A multi-level BOM is what you get by following every child down to purchased parts. Same lamp, expanded:
| Level | Component | Qty per parent |
|---|---|---|
| 1 | Base assembly | 1 |
| 2 | — Steel base plate | 1 |
| 2 | — Weight disc | 2 |
| 2 | — Felt pad | 4 |
| 1 | Arm assembly | 1 |
| 2 | — Arm tube | 2 |
| 2 | — Pivot joint | 2 |
| 3 | —— Pivot screw | 3 |
| 1 | Shade assembly | 1 |
| 2 | — Shade shell | 1 |
| 2 | — Socket | 1 |
Usually a view rather than a stored structure: the system walks the single-level records and renders the tree. An indented BOM is the same thing printed with indentation to show depth.
Where quantities multiply
The one piece of arithmetic that causes the most confusion. Quantity on a BOM line is always per one unit of its immediate parent — never per unit of the finished product.
Follow the pivot screw. Each pivot joint takes 3 screws. Each arm assembly takes 2 pivot joints. Each lamp takes 1 arm assembly. So one lamp needs 1 × 2 × 3 = 6 screws.
For 500 lamps, 3,000 screws. Read the line as 3 per lamp rather than 3 per joint and you buy 1,500 — half of what you need, discovered on the line when production stops.
Scrap and yield
Real processes waste material. Three metres of cable yields 2.9 metres of usable harness; one panel in forty fails inspection. A BOM that ignores this under-orders every time.
Two mechanisms, and they are not the same:
- Component scrap, on a BOM line: a percentage of this component is lost when consumed. 2% scrap on a 100-unit requirement means issuing 102.
- Assembly yield, on the parent: a percentage of finished assemblies fail. 95% yield means starting 105 to finish 100 — and that inflates every component beneath it.
Confusing them compounds badly through a deep BOM, because yield losses multiply at every level. Three levels at 95% each is 0.857, not 0.95: you need to start 117 to finish 100, not 105.
Effectivity and revisions
BOMs change — a component is superseded, a supplier discontinues a part, a design is revised. The naive approach is to edit the BOM. It destroys your ability to explain history: last month's production order was costed against a structure that no longer exists, and the variance is unexplainable.
Effectivity dates solve it. A line carries valid-from and valid-to dates, so the BOM is a function of the date you ask about. Orders released in September explode against September's structure; October's use October's. Both remain available.
The alternative is revision-controlled BOMs, where each revision is a distinct version and an order pins the revision it was released against. Either works. Editing in place does not.
Phantom assemblies
A phantom is a sub-assembly that exists in the BOM for structural clarity but is never stocked — it is built and consumed within the same operation, never hitting a stock location.
A wiring harness assembled at the bench and fitted immediately is a good example. You want it grouped in the BOM so the structure is readable, but you do not want a stock record, a location, or a work order for it.
Flagged as a phantom, planning passes straight through it to its children, and the harness never generates its own order or stock movement. Omit the flag and you get work orders for an item nobody builds separately, and an on-hand balance that never moves.
Costing: rolling the structure up
The same structure that explodes downward for planning rolls upward for cost. Standard cost is computed from the bottom: purchased parts carry a price, each assembly sums its children plus its own labour and overhead, and the total arrives at the top.
| Level | Item | Material | Labour | Rolled cost |
|---|---|---|---|---|
| 3 | Pivot screw (×3) | 0.12 | — | 0.36 |
| 2 | Pivot joint | 0.36 | 0.80 | 1.16 |
| 1 | Arm assembly (2 joints + 2 tubes) | 6.72 | 2.40 | 9.12 |
| 0 | Desk lamp | 21.40 | 4.60 | 26.00 |
Two consequences people miss. A price change on a component at the bottom changes the standard cost of every parent above it — which is why a roll-up is a deliberate, dated operation rather than something that happens continuously. And a BOM quantity error does not merely cause a shortage; it also makes the product cost wrong, so the margin you have been reporting was never real.
This is the mechanism behind purchase price variance too. The standard says 0.12 a screw; the invoice says 0.14; the difference posts to variance rather than disturbing the standard mid-period. Variance accumulating steadily in one direction is the signal that the standard needs rerolling.
Where-used: reading the structure backwards
A BOM answers what goes into this product. A where-used query answers the reverse: what products contain this component? Same data, walked upward, and it is the query that gets used in an emergency.
- A supplier discontinues a part. What can you still build, and what stops?
- A batch is found defective. Which finished goods contain it, and which of those have shipped?
- A price rises 30%. Which products lose margin, and by how much?
- An engineering change is proposed. What else does it touch?
Single-level where-used gives immediate parents; multi-level walks all the way to finished goods. The recall case needs the multi-level answer, joined to lot tracking, and the gap between those two queries is usually the difference between a contained recall and a broad one.
The errors worth checking for
- Quantity read as per-product rather than per-parent — the single most expensive BOM error.
- Unit of measure mismatches: cable priced per metre, consumed per centimetre, ordered in reels.
- Circular references, where an assembly ends up containing itself through a chain of children. A good system refuses this; check that yours does.
- Obsolete components still on active BOMs, found only when purchasing cannot source them.
- Scrap applied at the wrong level, so loss is understated at depth.