Engineering BOM vs Manufacturing BOM: What Electronics Teams Need to Know

What is an engineering BOM?

An engineering BOM (EBOM) is the parts list as the design defines it. It is organised the way the product is designed — by function and by assembly — and it answers one question: what does this thing consist of?

For an electronic board, the EBOM is the list that comes out of the schematic. Every reference designator, every component, every value. It exists before anyone has decided how the board will be built.

What is a manufacturing BOM?

A manufacturing BOM (MBOM) is the parts list as production needs it. It is organised by how the thing gets built, and it contains items the design never mentions: solder paste, stencils, labels, packaging, the screws that hold the board into an enclosure, test fixtures.

The same board can have one EBOM and several MBOMs — one per plant, per assembler, or per packaging configuration.

The difference in one table

Where electronics is a special case

Most writing about EBOM and MBOM comes from mechanical and large-manufacturer contexts, where the gap between the two is enormous. In electronics the picture is narrower, and that matters for deciding whether you need both.

A populated board — the PCBA — is usually one line in a mechanical BOM, and hundreds of lines in the electrical one. Putting every 0402 capacitor into the mechanical CAD model slows it down and tells the mechanical engineer nothing. So the board's own BOM is already a specialised document, closer to an EBOM than to anything else.

Firmware frequently appears on neither list, which is its own problem and usually solved by adding an explicit line for the programmed image and its version.

When one BOM is enough

For a lot of hardware teams, a single BOM is the right answer and a second one is overhead.

A single BOM works when:

the board is assembled by one external assembler; the assembler supplies its own consumables and does not want them itemised; there is one packaging configuration; nobody is doing material requirements planning against the list.

In that situation an MBOM would be a copy of the EBOM plus three lines nobody reads. Adding it creates a synchronisation problem without solving one.

When the structures genuinely diverge

The point where a second structure starts earning its place:

Panelisation. The assembler builds in panels of six, so the quantity that gets ordered is not the quantity on the board.

Consumables that are costed. When paste, stencils and adhesive have to be planned and priced per build.

Subassemblies. The board is built, tested and stocked as an item, and then installed into an enclosure in a separate operation with its own list.

Multiple plants or assemblers. Each with different approved sources, different work instructions, sometimes different alternates.

Phantom items. Groupings that exist only to make the build plan readable and have no physical reality.

A worked example

The ORION CONTROL UNIT is a fictional two-board product used here as an example. Its Main Control Board has 142 components.

EBOM, as engineering sees it:

ORION CONTROL UNIT
├── Main Control Board (PCBA)   ×1
│     ├── U1  STM32F407VGT6     ×1
│     ├── C12–C18  100 nF 0402  ×7
│     └── … 139 more lines
├── Power Supply Board (PCBA)   ×1
└── Enclosure assembly          ×1

MBOM, as the assembler needs it:

ORION CONTROL UNIT — build
├── Main Control Board (PCBA)   ×1
│     ├── Bare PCB, rev C       ×1
│     ├── Solder paste SAC305   0.8 g
│     ├── Stencil, rev C        (fixture, not consumed)
│     ├── U1  STM32F407VGT6     ×1
│     └── … components
├── Power Supply Board (PCBA)   ×1
├── Enclosure, machined         ×1
├── M3×6 screws                 ×4
├── Serial label                ×1
└── Antistatic bag + box        ×1

Sample data. Note what changed: the bare PCB appears as a purchased item, the paste has a quantity, the stencil is listed but not consumed, and four screws and a label exist that the schematic never knew about.

The mistake that causes most of the damage

The two lists drift. Engineering issues a new revision, the MBOM in the ERP is updated by someone else a week later, or not at all, and from then on manufacturing is building to a document that no longer matches the design.

Two habits prevent it:

1. One direction of derivation. The MBOM is derived from the EBOM, never

edited independently and then reconciled. If a part changes in the MBOM without changing in the EBOM, that is a defect, not a shortcut.

1. The EBOM revision is stated on the MBOM. So you can always answer which

design state the build list came from.

Which one should you keep under control?

If you only control one, control the EBOM. It is the one that describes the product, it is the one that has to survive for the life of the design, and it is the one you will need when somebody asks in four years what was on the board that shipped.

The MBOM is usually reconstructable from the EBOM plus the process. The EBOM is not reconstructable from anything.

Keeping an EBOM correct is mostly discipline. Keeping it connected is harder: six months and three revisions later, the question stops being "is this list right?" and becomes "which revision of the board does this list belong to, and where are the Gerbers that match it?"

That is what XKEMA is built around — the bill of materials belongs to the board it describes, and both carry their own revisions.

BOM management How to create an electronics BOM How to manage BOM revisions Prototype BOM vs production BOM