Glossary
BOM (bill of materials)
A bill of materials (BOM) is a structured list of all the components, materials, subassemblies, and quantities required to build a product. More than a parts list, it is the shared definition of the product that engineering, manufacturing, and procurement all work from — the document where design intent meets manufacturing reality.
In one sentence
Nearly every function in a hardware company reads the BOM and almost none of them read it the same way — so a BOM error doesn’t stay a BOM error. It becomes a wrong purchase order, a line stoppage, or a field failure.
How it works in practice
Most hardware BOMs are multi-level: a hierarchy from the top-level finished assembly down through subassemblies to individual components. Example: a sensor module’s BOM has three levels. Level 0 is the finished module. Level 1 holds the PCB assembly, the enclosure, and the cable harness. Level 2 under the PCB assembly lists every resistor, capacitor, IC, and connector with quantities and reference designators — R14, C22, U3. When the EE swaps a microcontroller, one line changes at level 2, and everyone downstream sees the same change.
Common failure modes
The BOM and the design drift apart. The schematic changes; the spreadsheet BOM doesn’t. Or the BOM is updated and the CAD isn’t. Each is maintained by hand in a different tool, so they diverge silently — and the factory builds from whichever document it was given last. This is the reconciliation tax in its purest form.
Flat BOMs hide relationships. A single-level BOM lists parts with no structure. When a failure occurs, there’s no way to trace which subassembly a failed component belongs to, or which other assemblies share the same part.
Small fields, big consequences. A wrong unit of measure, a misplaced decimal in a quantity, an MPN copied from the wrong column — BOM errors are rarely dramatic and almost always expensive.
Shadow BOMs. When the official BOM lives in a PLM system nobody enjoys using, teams keep their own: the buyer’s spreadsheet, the CM’s portal upload, the engineer’s desktop copy. Three versions of the truth, none of them authoritative.
The exported BOM lies. On the Autodesk Fusion forum, one poster reported their generated electronics BOM was missing manufacturer and MPN fields even though the library attributes contained them — blocking a fabrication quote. On the Acumatica forum, a user reported a BOM export writing the wrong Material ID and UOM on the first line of every assembly across more than 9,000 assemblies. The data existed; the export corrupted it.
How ProductFlo handles it
ProductFlo treats the BOM as a live view over the product graph, not a document someone maintains. BOM management runs on multi-level structures with revision comparison and component lifecycle tracking, and automated BOM validation checks the BOM against the design files it claims to describe: a BOM change is diffed against the ECAD source, so a part on the BOM that’s missing from the schematic — or a quantity that doesn’t match the layout — gets flagged before it ships. The findings arrive as reviewable diffs routed to the right owner; a human approves. Agents propose diffs. Humans approve. The BOM stops being a spreadsheet that drifts and becomes a live view that’s checked against the design it describes.
Questions about BOMs
What does a BOM line contain?+
What is a multi-level BOM?+
What is the difference between a BOM, an EBOM, and an MBOM?+
How does ProductFlo keep BOMs accurate?+
Related concept
EBOM vs MBOM →
The two primary BOM views: as designed vs as built — and where most BOM errors are born.
Related concept
ECO →
BOM lines are what ECOs most often change — the vehicle that creates new revisions.
Eight definitions, zero marketing. Browse the full glossary.
All glossary terms →Stop building from a drifting BOM.
A 30-day pilot on one active product. Fixed $8k. Live on your own BOM in week one.
Book a demo →