Bill of Materials (BOM): A Complete Guide for Manufacturers

What is a bill of materials?

Take a simple manufactured product: a 1,000 mL bottle of cleaning solution. Its BOM might look like this, stated per one finished unit:

That last line is a real detail worth noticing: a case holds 12 bottles, so each individual bottle consumes 0.0833 of a case. Producing one unit causes each of these quantities to become a requirement for one unit. Producing 1,000 finished units causes each quantity to scale directly:

The 83.3 cases is a theoretical requirement; actual purchasing would round up to 84 whole cases, since a case can't be ordered or shipped as a fraction. Whether that rounding happens on the BOM itself, at the unit-of-measure level, or through a separate ordering rule varies by system, and none of this yet accounts for scrap, yield, or what's already in inventory, both covered later in this guide. The point to take from this table now: a BOM isn't a static description of a product, it's structured data that other calculations run directly on top of.

This same structure shows up under different names depending on the manufacturing model. A process manufacturer scaling ingredient proportions to a batch, rather than fixed components to a unit, is solving a related problem with a different shape, covered in BOM vs. formula vs. recipe and in the process manufacturing guide.

What information is stored in a BOM?

A BOM is more than a two-column list of components and quantities. Most real implementations carry additional fields, though which ones are used, and how strictly, varies by manufacturer and by system.

• Parent item. The item this BOM belongs to, the thing being built.
• Component item. Each individual material, part, or subassembly consumed.
• Quantity per. How much of the component is required per unit of the parent.
• Unit of measure. The unit the quantity per is expressed in, which doesn't always match how the component is purchased or stocked.
• BOM level. Where this component sits in the product structure relative to the top-level parent.
• Revision or version. Which version of the structure this record belongs to.
• Effective dates. The date range during which this version of the BOM is valid for production.
• Scrap or yield assumptions. An adjustment factor applied to account for expected material loss during production.
• Alternate or substitute components. Other items that can satisfy the same requirement, where applicable.

Not every manufacturer populates every field, and not every system supports every field the same way. A make-to-order fabricator with a handful of products might track little beyond components and quantities. A regulated manufacturer producing to a validated formulation may treat revision control and effective dates as mandatory. The fields above are what's commonly available, not a checklist every BOM has to satisfy.

Parent items, components, and subassemblies

Every BOM relationship is a parent-child relationship: a parent item requires some quantity of a component. That component can be a raw material or purchased part, something with no BOM of its own, or it can be a subassembly, something that's manufactured and has its own BOM underneath it.

Finished Good
├── Subassembly A
│   ├── Component 1
│   └── Component 2
└── Component 3

This structure matters because it determines how a requirement flows downward. A change to how many units of Subassembly A the Finished Good needs affects the requirement for Component 1 and Component 2 as well, since their demand is derived through Subassembly A, not set independently. Getting the hierarchy right, not just the quantities, is what makes the rest of this guide's calculations work correctly.

Single-level vs. multi-level BOMs

A single-level BOM lists only the components consumed directly by one parent, with no further structure underneath any of them. The cleaning solution example earlier in this guide is single-level: base chemical, active ingredient, bottle, cap, label, and case are all raw materials or purchased parts, not manufactured subassemblies.

A multi-level BOM appears the moment any component is itself an assembled item with its own bill of materials. A finished good might require a subassembly, and that subassembly might require its own components:

Multi-level structures exist because manufacturing itself is multi-level: a subassembly that's built once and used in several different finished goods is more efficient to plan, stock, and cost as its own item than to redundantly define the same components inside every finished good that uses it. Any product built from pre-assembled modules, rather than purely from raw materials, needs a multi-level BOM to represent it accurately.

What is BOM explosion?

Take a multi-level structure: 1 Finished Good requires 2 units of Subassembly A and 1 unit of Component B. Each unit of Subassembly A itself requires 3 units of Component C and 2 units of Component D.

Exploding a requirement for 100 Finished Goods means multiplying down through each level in turn:

Notice that Component C and Component D's requirements are calculated from Subassembly A's exploded requirement of 200, not from the original 100 Finished Goods directly. That's the mechanism that has to repeat correctly at every level: each level's result becomes the next level's starting point, all the way down to raw materials.

This is also exactly the mechanism Material Requirements Planning (MRP) runs on. MRP takes BOM explosion a step further by netting each exploded requirement against on-hand inventory and scheduled receipts, then offsetting by lead time to determine when an order actually has to be placed, not just how much is needed in total. The explosion math above is the foundation that calculation depends on.

What is a BOM roll-up?

Take three components consumed by one parent item, each with its own unit cost and quantity per:

Each component's extended cost, unit cost times quantity per, sums into a $20 material cost for the parent item. In a multi-level structure, this works the same way one level further down: a subassembly's rolled-up material cost becomes one line item in its own parent's cost roll-up, the same way a component's cost does here.

Engineering BOM vs. manufacturing BOM

An engineering BOM (EBOM) represents a product from a design and functional perspective, organized the way an engineer thinks about the product's specification. A manufacturing BOM (MBOM) represents the product the way it will actually be built and purchased on the shop floor.

The two often diverge in practical ways. An EBOM for an electronic device might simply specify a populated circuit board as a functional block. The corresponding MBOM might show that board as a purchased subassembly bought complete from a contract manufacturer, and add lines the EBOM never had reason to include: the shipping carton, a foam insert, a printed warranty card, an anti-static bag. None of those affect how the product functions, but all of them are real material consumed in production and real cost that has to be accounted for.

Not every manufacturer maintains two fully separate structures. A simple product with a short path from design to production might use one BOM for both purposes without meaningful conflict. The distinction becomes worth maintaining separately once the design structure and the as-built structure genuinely diverge enough that collapsing them into one BOM would misrepresent either engineering intent or the actual production process.

BOM revisions and effectivity

BOMs change, for reasons that have nothing to do with data hygiene: a supplier stops offering a part, an engineering change improves a design, a cost-reduction initiative swaps a component, a packaging update rolls out, a regulatory or quality requirement forces a substitution. Change itself isn't the problem. Losing track of which version was in effect when is.

Revision control assigns each meaningfully different version of a BOM its own identifier, Revision A, Revision B, and so on, rather than silently overwriting the previous structure. Effective dates then attach a validity window to each revision:

The useful question is rarely just "what is the current BOM?" It's "which BOM was valid for this production date or order?" A quality investigation into a batch produced in August needs the BOM in effect that August, Revision A, even if Revision B has been current for months by the time anyone asks. Without effectivity control, that historical answer isn't reliably recoverable.

Scrap, yield, and BOM quantities

A BOM's quantity per is often theoretical: the amount required with zero material loss. Real processes rarely hit that number, which is why scrap or yield gets modeled as a separate input, though the two conventions aren't interchangeable and can produce different answers for what looks like the same loss rate.

• Theoretical quantity. What's required with no loss: 10 kg of good output, for example.
• Expected consumption, scrap-factor convention. Some systems apply scrap as a multiplicative add-on: at a 5% scrap factor, 10 kg × 1.05 = 10.5 kg of input.
• Expected consumption, yield convention. Others define yield as the share of input that survives as good output, and divide instead: at 95% yield, 10 ÷ 0.95 = 10.526 kg of input.
• Actual consumption. What a specific run actually used, recorded after the fact: say 10.8 kg.

10.5 kg and 10.526 kg aren't the same number, even though 5% scrap and 95% yield sound like complements. One convention multiplies the theoretical quantity, the other divides it, and the gap between them widens as the loss rate grows. Which convention a given system or process uses is an implementation choice, not something with one correct answer across manufacturers.

The gap between actual and whichever expected figure applies, 10.8 kg against an expected 10.5 kg here, is a 0.3 kg quantity difference, not by itself a financial figure. Turning it into a material usage variance means valuing that 0.3 kg at an applicable standard or expected price, a step covered later in this guide.

Units of measure

A BOM's quantity per is only meaningful alongside a unit of measure, and that unit doesn't always match the unit inventory is tracked in or the unit a material is purchased in. Reconciling between them is a routine, and routinely underestimated, source of error.

To produce 1,000 units: 12 oz × 1,000 = 12,000 oz. Converting to pounds (16 oz per pound): 12,000 ÷ 16 = 750 lb. Converting to bags (50 lb per bag): 750 ÷ 50 = 15 bags. Every step in that chain has to convert correctly for the final purchasing number, 15 bags, to be right.

An error anywhere in that conversion chain doesn't stay contained to one number. A wrong ounces-to-pounds factor corrupts the material plan (ordering the wrong quantity), inventory balances (on-hand pounds no longer matching what's physically there), production consumption (the wrong amount getting relieved from inventory when a unit is built), and product cost (material cost calculated against the wrong quantity). Unit of measure conversion looks like a minor data-entry detail. It behaves like a foundational one.

Alternate and substitute components

Some requirements can legitimately be satisfied by more than one item. It's worth distinguishing two versions of this, since they carry different levels of control.

An engineered alternate is a component formally approved, often by engineering or quality, as an equivalent substitute for a given position in the BOM, sometimes ranked by preference. An operational substitution is a more ad hoc decision, made on the production floor or in purchasing, to use a different item than the BOM specifies because the primary component isn't available.

The reason this needs a formal control rather than simply allowing any similar inventory item to be consumed is straightforward: not every item that seems interchangeable actually is. A different supplier's version of a component might have a different tolerance, a different regulatory approval status, or a different cost, any of which can matter even when the parts look functionally identical on the shop floor. Alternate and substitute rules exist to make sure a swap is a deliberate, approved decision rather than an invisible one that surfaces later as a quality issue or a costing discrepancy nobody can explain.

Phantom BOMs and phantom assemblies

A phantom assembly is typically used as a logical grouping within a product structure, organizing the BOM clearly without being separately planned, stocked, or produced as its own inventory item the way a normal subassembly is. In systems that support the concept, a parent's requirement exploding down through a phantom generally passes straight through to its own components, as though the parent's BOM had listed those components directly, though the exact mechanics, and whether the term is supported at all, vary by system.

The underlying reason is the same across implementations: some groupings, this set of parts conceptually belongs together, are useful for engineering or production documentation without corresponding to anything independently stocked, purchased, or built as a standalone step. Treating every such grouping as a fully planned subassembly would generate work orders and inventory records for things that don't exist as separate physical items in the warehouse.

BOM vs. routing

A routing typically describes the sequence of operations required to build an item: which work centers are involved, in what order, along with setup time, run time, and the labor or machine resources each operation consumes. Where a BOM answers "what components does this need," a routing answers "what has to happen, in what order, to turn those components into the finished item."

The two are complementary, not competing. Production planning needs both: the BOM to know what materials to have on hand, the routing to know what capacity, time, and labor the build actually requires. Costing needs both too, material cost from the BOM's roll-up, conversion cost, labor and overhead applied through the operations, from the routing.

How BOMs connect to MRP

The relationship follows a consistent chain: demand for a finished good gets exploded through its BOM into component requirements, those requirements get netted against current inventory, and whatever's left becomes a planned purchase or production order.

Demand for finished goods
        ↓
   BOM explosion
        ↓
Component requirements
        ↓
  Inventory netting
        ↓
Planned purchases / production

This guide has covered the explosion half of that chain in detail: how a quantity for a parent item becomes a quantity for its components, level by level. The netting, lead-time offsetting, and time-phasing that turn those exploded requirements into a dated purchasing and production plan are covered in full, with a worked example, in the dedicated MRP guide. The short version worth carrying forward here: MRP doesn't work without a BOM. The BOM supplies the structure; MRP supplies the timing and quantity logic that runs on top of it.

How BOMs affect inventory

A BOM establishes the expected material consumption every time a finished good is produced. When a production order for a given quantity is completed, the components listed on that item's BOM, multiplied by the quantity produced, are the amounts expected to be relieved from component inventory and recorded as consumed.

That expectation is what makes inventory accuracy checkable at all. Comparing expected consumption against what was actually relieved from inventory is how a quantity variance, or a data problem, gets caught, though scrap makes the comparison less exact, since some loss above the planned factor is normal. Without an accurate BOM, there's no reliable expectation to check actual inventory movement against, and accuracy degrades quietly rather than obviously.

How BOMs affect manufacturing accounting

The BOM doesn't create accounting entries, and it doesn't determine which costing method a business uses. What it supplies is expected quantities, and under a standard-cost approach, material cost inputs, that manufacturing accounting processes then apply according to the company's own costing method and system configuration.

• Material cost inputs. Under standard costing, a BOM cost roll-up feeds the material component of an item's standard cost. Under actual or average costing, the BOM mainly establishes expected consumption rather than a cost figure used directly in valuation.
• Expected production consumption. Regardless of costing method, the BOM's quantities are the baseline actual component usage gets compared against.
• WIP and finished-goods valuation. How component consumption moves into WIP and then into finished-goods value depends on the costing method and system in use; the BOM supplies the expected quantity side of that movement, not the valuation logic itself.
• Material usage variance. Comparing actual consumption to the BOM-based expectation identifies a quantity variance; turning it into a financial variance requires a costing method that values that quantity difference at a standard or expected price.
• Cost of goods sold (COGS). Where a BOM-derived material cost feeds an item's standard cost, that cost flows through to COGS on sale; under other costing methods, COGS is derived differently.

A BOM error doesn't generate a wrong journal entry by itself. It generates a wrong quantity or cost input, and that error flows through whichever accounting process, standard costing, variance analysis, valuation, actually touches it, in a way that depends on the specific method and system in use.

What happens when a BOM is wrong

A wrong BOM quantity doesn't stay contained to the BOM. It propagates through every calculation downstream of it, in a fairly predictable chain:

Wrong BOM quantity
        ↓
Wrong material requirement
        ↓
Wrong purchasing recommendation
        ↓
Potential shortage or excess inventory
        ↓
Incorrect expected production consumption
        ↓
Potential costing errors
        ↓
Production variance

If a BOM understates a component's quantity per, every exploded requirement calculated from it is understated too, purchasing orders less than production will actually need, and a shortage shows up mid-run. If it overstates a quantity, excess material gets purchased and carried, and where that quantity also feeds a cost calculation, the item's material cost is wrong in the same direction, surfacing later as a variance that has nothing to do with how efficiently the item was actually built.

Common BOM mistakes

• Incorrect quantity-per values. Understates or overstates every exploded requirement and every rolled-up cost calculated from that line.
• Wrong units of measure. Corrupts material planning, inventory balances, and cost the moment a conversion is applied incorrectly, as covered above.
• Duplicate components. Inflates requirements and cost by double-counting the same material under two different item records.
• Missing components. Understates requirements and cost, and can leave production short of something nobody planned to order.
• Obsolete components remaining active. Risks a planning or purchasing system generating demand for something that's no longer actually used or available.
• Incorrect revision in use. Production builds to a structure that isn't the one actually intended for that date, undermining traceability.
• Incorrect effective dates. A new revision goes live too early or too late relative to when it was actually approved for production.
• Incorrect parent-child relationships. Breaks the explosion logic itself, since requirements flow through the hierarchy, not just through flat quantities.
• Missing subassemblies. A multi-level structure modeled as single-level hides real production steps and real intermediate inventory.
• Uncontrolled substitutions. Introduces components that were never formally approved as equivalent, with unpredictable quality or cost consequences.
• Stale scrap or yield assumptions. A factor set years ago and never revisited stops reflecting how the process actually performs today, skewing both planning and any cost calculation built on it.

BOM terminology

Frequently asked questions