A bill of materials (BOM) is a structured list of every component, in the right quantity, in the right unit, that goes into making one of something. Get it right and it runs your purchasing, your production plan, your costing, and your traceability. Get it wrong and every other system in your operation inherits the wrongness.
This guide is a practical walkthrough, the decisions that matter, in the order they come up. It assumes you are making physical goods in a small-to-medium operation and you have outgrown the spreadsheet version.
Step 1 · Pick the output SKU and the batch size
A BOM is always expressed against a specific output. Decide whether you are building the BOM for one unit (one lipstick, one jar, one bottle) or for one production batch (500 units, 10 litres, one pallet).
Per-unit BOMs are easier to reason about and cost. Per-batch BOMs match what the shop floor actually does. Pick one convention and stick to it across all BOMs, mixing them is the single biggest source of the “something is off” feeling weeks later.
Step 2 · List components in consumption order
For each component, capture:
- SKU or internal code, the identifier you use in stock records.
- Description, the human-readable name, matched to purchasing.
- Quantity, a number.
- Unit of measure (UOM), grams, millilitres, pieces, metres. Be specific.
- Yield / loss percentage, see step 5.
- Alternate components, approved substitutes with conversion factors.
Order the list the way the operator will consume the components. A BOM that lists ingredients in alphabetical order is a BOM built for the office, not the floor.
Step 3 · Decide the UOM conversions up front
Purchasing buys pigment in 20kg drums. Production measures it in grams. Stock records track it in kilograms. Three units of measure, one material. Every BOM item needs a clean path between the purchasing UOM, the inventory UOM, and the consumption UOM.
Step 4 · Model sub-assemblies as multi-level BOMs
If a component is itself manufactured, a pigment dispersion, a base formulation, a sub-assembly, it gets its own BOM. The parent BOM references the sub-assembly as a line item, and the software resolves the full tree when it plans production.
This matters because you will one day ask: “to make 500 lipsticks, how much carnauba wax do I actually need?” A multi-level BOM answers that by multiplying through the tree. A flat BOM makes you re-derive it every time. See multi-level vs single-level BOMs for when each is appropriate.
Step 5 · Record yield and loss honestly
The BOM you inherit from R&D is written for a perfect world. The one you run production against needs to reflect losses: evaporation, transfer losses, rejects, setup waste. Two common patterns:
- Per-line yield, a component is entered at its theoretical quantity with a yield percentage. 100g required at 95% yield becomes 105.3g issued to the run.
- Per-BOM scrap factor, one number at the end of the BOM that inflates everything proportionally. Simpler, but hides where the loss is actually happening.
Per-line is more work up front and gives you cost-to-improve signal forever after.
Step 6 · Version control, and who owns it
A BOM changes. Suppliers substitute. Formulations improve. Regulations shift. Record every change with:
- A version number and an effective date.
- The reason for the change (cost, availability, quality, reformulation).
- The person who approved it.
Production runs reference a specific BOM version. That is the single connection that lets you audit, months later, why a batch from March has a different component list than a batch from July.
Step 7 · Validate against a real production run
Before a BOM goes live, run a pilot batch against it. Compare planned consumption to actual consumption, line by line. Adjust yield numbers. Fix UOM mismatches. A BOM that has been validated against at least one real run is the only kind worth running MRP against.
What not to do
- Don't capture packaging in a separate system. Cartons, labels, leaflets, sleeves, they are all BOM lines. If they live in purchasing but not production, you will run out of boxes on a Friday.
- Don't collapse batch and unit quantities.A BOM that says “1 lipstick” with component quantities scaled to a per-batch run is a BOM that will mislead somebody.
- Don't hide phantoms inside comments.If a component is a grouping for convenience that never actually gets manufactured (a “phantom BOM”), it needs to be flagged as such so MRP skips over it. See phantom BOMs explained.
How Stokka handles BOMs
Stokka supports multi-level BOMs, phantom assemblies, yield rates per line, and alternate components with conversion factors. Every production run references a specific BOM version, and the assembled batch records actual-vs-planned consumption for every component batch. The BOM you build is the BOM your shop floor sees and the BOM your traceability searches resolve against.
Further reading
If you are deciding how deep to go, read multi-level vs single-level BOMs. If your components themselves come from a range of batches, see our guide to batch tracking for small manufacturers. And if BOM quantities are the missing input blocking your production plan, start with what MRP actually is.