Glossary

EBOM vs MBOM: as designed vs as built

The engineering BOM (EBOM) describes the product as designed: organized by function, owned by engineering, generated from CAD and ECAD tools. The manufacturing BOM (MBOM) describes the product as built: the same product reorganized around processes and build sequence, owned by manufacturing. Two views of one product, and the transformation between them is where most BOM errors are born.

In one sentence

Engineering and manufacturing need different answers from the same product — so the industry keeps two BOMs, and then pays a permanent tax keeping them synchronized.

How it works in practice

The EBOM comes first, typically generated from the design tools: the CAD assembly tree and the ECAD schematic produce a functionally organized parts list. The MBOM is derived from it, restructured for production — adding build sequence, process steps, tooling and fixtures, consumables (solder paste, adhesives), packaging materials, and phantom assemblies: groupings that exist only to organize the build, like kitting a set of fasteners installed at one station.

Example: a controller’s EBOM lists the main PCB assembly as a single line item with 200 components beneath it. The MBOM explodes that line into the SMT sequence, adds the solder paste and the test fixture as consumables, groups the enclosure screws into a kitting phantom for the final-assembly station, and appends the box, the label, and the quick-start guide. Same product, different structure, different owner.

Common failure modes

The translation is manual. Someone re-keys or re-maps the EBOM into the MBOM in a spreadsheet or a second system. Every manual translation is a chance to drop a line, transpose a quantity, or carry over a stale revision — and there’s no automatic check that the two views still describe the same product.

Changes land in one view. An ECO updates the EBOM; the MBOM update is a separate task, done later, by someone else, sometimes forgotten. The engineering truth and the manufacturing truth diverge, and the divergence is discovered at the worst possible moment — during a build.

MBOM confused with as-built. The MBOM is the plan for manufacturing, not the record of what was actually consumed. Teams that treat the MBOM as the as-built lose traceability into which specific lots and serials went into which units.

Phantom sprawl. Kitting phantoms and process groupings accumulate over product generations until the MBOM contains structures nobody can explain and everyone’s afraid to delete.

How ProductFlo handles it

The EBOM↔MBOM problem is a synchronization problem, and synchronization is what an orchestration layer is for. ProductFlo keeps both views on one live graph: specialized agents watch the graph and flag cross-discipline impacts before a change ships — which BOM lines, process steps, and structures an EBOM change touches — and every finding is routed to the right owner as a reviewable diff. The merge gate checks every change against the full engineering graph before it can ship, and for PLM-connected teams, Windchill part structures and BOMs stay in sync with the live graph. Agents propose diffs. Humans approve. Two views, one truth, no re-keying.

Questions about EBOM and MBOM

What is the difference between EBOM and MBOM?+
The EBOM (engineering BOM) describes the product as designed — organized by function, owned by engineering, generated from CAD and ECAD tools. The MBOM (manufacturing BOM) describes the product as built — the same product reorganized around build sequence and process steps, owned by manufacturing. Two views of one product.
Who owns the EBOM and who owns the MBOM?+
Engineering owns the EBOM; manufacturing owns the MBOM. The transformation between them adds what engineering doesn’t care about and manufacturing can’t live without: build sequence, process steps, tooling and fixtures, consumables, packaging materials, and phantom assemblies.
Why do EBOM and MBOM fall out of sync?+
The translation is usually manual — someone re-keys or re-maps the EBOM into the MBOM — and changes land in one view but not the other. An ECO updates the EBOM; the MBOM update is a separate task, done later, by someone else, sometimes forgotten. As ISE Magazine’s Craig Currie describes it: “As changes are made, the EBOM and MBOM fall out of sync... disconnected silos of data that can cause miscommunication, errors, rework, increased product costs, problems with quality and delays in time to market.”
Is the MBOM the same as the as-built record?+
No. The MBOM is the plan for manufacturing, not the record of what was actually consumed — that’s the as-built or batch record. Teams that treat the MBOM as the as-built lose traceability into which specific lots and serials went into which units.
How does ProductFlo keep EBOM and MBOM in sync?+
The EBOM↔MBOM problem is a synchronization problem, and synchronization is what an orchestration layer is for. ProductFlo keeps both views on one live graph: agents flag cross-discipline impacts as reviewable diffs, the merge gate checks every change against the full engineering graph before it can ship, and for PLM-connected teams, Windchill part structures and BOMs stay in sync with the live graph. Agents propose diffs. Humans approve.

Related concept

BOM →

The shared definition of what gets built — and what drifts when nobody watches.

Related concept

Revision control →

How released states get identified so both BOM views agree on the same truth.

Eight definitions, zero marketing. Browse the full glossary.

All glossary terms →

Two views. One truth.

A 30-day pilot on one active product. Fixed $8k. Live on your own BOM in week one.

Book a demo →