EBOM vs MBOM: two views of one product, not two products

What an EBOM is

The engineering bill of materials is the structure engineering releases. It usually comes out of CAD or EDA, gets managed in PLM, and is organized by function: the frame assembly, the glazing assembly, the hardware kit. It carries part numbers, revision levels, materials, and the parent-child relationships that match how the designer thinks about the product.

The EBOM changes through engineering change orders (ECOs). It mostly ignores factories: the same design can be built in two plants.

What an MBOM is

The manufacturing bill of materials is the structure the plant builds from. It is organized by how the product moves through the floor, not how it was drawn. It adds things the engineer never modeled: adhesives and sealants, packaging, labels, fixtures, and phantom assemblies that exist only to group work. It is tied to routings and work centers, and it is often plant-specific.

The MBOM usually lives in ERP or MES, because that is where MRP, purchasing, and costing read it.

EBOM vs MBOM, side by side

Vendor explainers from PTC and Mars PLM draw the same line. Their recommendation is a synchronization layer between PLM and ERP.

Why they drift

In most companies the MBOM starts life as a copy of the EBOM that someone restructures, either by hand or with a tool. From that point on there are two lists, and drift comes from a handful of ordinary events:

• An ECO lands in PLM, and the ERP update is a separate step. If that step is a manual re-key or a nightly job, there is a window where the plant builds last revision's part.
• Manufacturing changes the MBOM for real reasons. A supplier swap, a different kit, a new phantom. The change never flows back, so engineering cannot see it.
• Restructuring loses the link. When an engineering assembly is dissolved into three manufacturing kits, the MBOM lines often stop pointing back to the EBOM item they came from. A practitioner in an r/SolidWorks thread on moving BOMs into ERP describes exactly this: not every assembly has a manufacturing equivalent, so some have to be dissolved to match the MBOM hierarchy.
• Spreadsheets carry it between teams. Excel is still how many companies move a BOM from one desk to the next. Every export is a snapshot that starts aging the moment it is saved.

A sync job makes the copies match more often. It does not decide which copy owns a given field, and it does not record why a change was made.

"EBOM to MBOM conversion" is the wrong frame

Search for this topic and you will find plenty of guides on EBOM-to-MBOM "transformation" or "conversion" in Windchill, Teamcenter, and SAP. The word conversion implies the EBOM goes in and a new object comes out. That is how the drift starts.

A better model: the parts and revisions are shared. Engineering edges say what contains what by design. Manufacturing edges say what is assembled with what, at which operation, in which plant. Manufacturing-only items are nodes that appear only in the manufacturing view. The EBOM and the MBOM are two ways of walking the same graph.

{
  "id": "bom.win.cw-440",
  "graph": {
    "nodes": [
      { "id": "frame",    "item": "thermally-broken aluminum frame", "rev": "C" },
      { "id": "glazing",  "item": "insulated glass unit",            "rev": "B" },
      { "id": "hardware", "item": "projected-casement hardware set", "rev": "A" },
      { "id": "sealant",  "item": "structural glazing sealant",      "mfg_only": true }
    ],
    "edges": [
      { "from": "frame", "to": "glazing",  "rel": "contains",  "view": ["ebom", "mbom"] },
      { "from": "frame", "to": "hardware", "rel": "assembles", "view": ["ebom", "mbom"] },
      { "from": "frame", "to": "sealant",  "rel": "consumes",  "view": ["mbom"], "op": "glaze" }
    ]
  }
}

In this shape, an ECO that bumps the glazing revision is a single write. The EBOM view and the MBOM view both read the new revision because neither one keeps its own copy.

The two copies nobody draws

Most EBOM-vs-MBOM diagrams stop at manufacturing. In a configure-to-order business, the same product exists in at least two more places:

• The quote. CPQ holds a sales version of the product: options, prices, and lead times. It is often maintained by a different team, with its own part list.
• The invoice. Billing holds yet another version: lines, units of measure, and revenue-recognition rules.

If the EBOM and the MBOM drift, the plant builds the wrong revision. If the quote drifts from the MBOM, the plant builds something other than what was sold. If the invoice drifts from the quote, finance bills for something other than what shipped. It is the same problem in three places, and syncing the first pair does not fix the other two.

How to check your own EBOM and MBOM

1. Pick one product that changed recently. Something with an ECO in the last quarter is ideal.
2. Pull the released EBOM and the current MBOM for one plant. Flatten both to part number, revision, and total quantity.
3. Diff them. Every engineering part should appear in the MBOM at the same revision and the same total quantity. Every MBOM-only line should be a manufacturing item you can name.
4. For each mismatch, write down which system was right and who should have changed it. That list is your real ownership model, whatever the process document says.

If you also pull the quote and the invoice for one order of that product, you have the whole drift picture in four files.