eBOM vs mBOM: the real difference, with a line-by-line example

The answer in three lines

eBOM stands for Engineering Bill of Materials; mBOM for Manufacturing Bill of Materials. The "e" and the "m" say who builds it and what it's for: one describes the product as designed, the other the product as it is made.

If you have only one BOM in your company, that isn't necessarily a problem — many SMEs work that way. But then someone is doing the conversion by hand somewhere, and it's that invisible work that deserves a look.

1. One valve, two bills of materials

Take a simple, telling example: a shut-off valve assembled on a line. Here is what engineering hands over, straight out of the CAD assembly.

The engineering BOM (eBOM) — 9 lines

This list is accurate, complete… and unusable as-is on the shop floor. Here's what methods turn it into.

The manufacturing BOM (mBOM) — 17 lines, across 3 levels

Nine lines on one side, seventeen on the other, and neither is wrong. This is the point I spend the most time getting accepted in meetings: it isn't about making two departments agree on one list, but about accepting that there are two, and organising the handover cleanly.

2. The 6 systematic differences

Across industries, the same six differences recur. Knowing them lets you anticipate the conversion work instead of discovering it line by line.

• 1. Assembly sub-assemblies. Methods group parts that design didn't group, because they're assembled together, at one station, before final assembly. Those sub-assemblies exist nowhere in CAD.
• 2. Consumables. Glue, grease, threadlocker, welding wire, paint: invisible in the model, essential on the floor and in purchasing. They're often expressed in units CAD doesn't know — grams, drops, metres.
• 3. Supply state. Design says "body"; manufacturing distinguishes the purchased casting from the machined part, sometimes with two part numbers and an operation between them.
• 4. Scrap and losses. An offcut rate on raw material, a breakage percentage on a fragile component: quantities that mean nothing in design and are vital to compute real requirements.
• 5. What isn't modelled. Rivets, labels, packaging, manuals, "obvious" fasteners: everything the designer left out because it doesn't change the geometry, and that the shop must nonetheless order.
• 6. Order and hierarchy. The eBOM follows the product's functional logic; the mBOM follows the order in which hands touch it. Two different trees for the same leaves.

3. From eBOM to mBOM: three ways, only one good

The handover always happens. The question is whether it happens in plain sight or in a file nobody backs up.

Manual re-keying — the most common, the worst

Someone exports the eBOM, pastes it into a spreadsheet, adds their lines, reorganises, and keys the result into the ERP. It works… until the first change. From then on the two lists diverge silently, and nobody knows which one governs. It's the exact mechanism that produces parts built to the wrong revision.

Raw automatic transfer — better, but not enough

The eBOM is pushed automatically into the ERP, where methods complete it. Re-keying disappears, but additions made on the ERP side get overwritten at the next transfer unless something protects them. You then need an explicit rule on what is re-imported and what isn't.

Managed transformation — the right answer

The eBOM and mBOM coexist as two distinct, linked structures: every mBOM line knows which eBOM line it derives from, and methods-only additions are flagged as such. A design change then surfaces as a discrepancy to handle, not as an overwrite. That's a PLM's job, and precisely the boundary described in the complete guide to the PDM → PLM → ERP chain.

4. Who owns what: the rule to write down

Most BOM conflicts aren't technical: they're unsettled ownership questions. The rule fits in four lines, and the only work is getting both departments to accept it.

• Engineering owns the eBOM. It alone adds, removes or modifies a definition part. Nobody else touches it, ever.
• Methods own the mBOM. They add sub-assemblies, consumables, scrap and packaging, and organise the structure by assembly order.
• An mBOM line derived from the eBOM cannot be edited on the methods side. If it causes trouble, it becomes a change request back to engineering — not a local fix.
• One list governs purchasing, and everyone knows which. That's the question your organisation must be able to answer in one sentence.

5. The other BOMs you'll meet

eBOM and mBOM are the two main ones, but others appear as soon as the product lives longer:

• The service BOM (sBOM): what a technician can replace in the field. It excludes welded parts and anything that doesn't come apart, and instead groups maintenance kits that exist in neither of the other two.
• The as-built BOM: what actually left the shop, serial number by serial number, with the substitutions accepted that day. Essential as soon as recalls or contractual warranties are involved.
• The configuration BOM: the list of possible options rather than one specific unit, for catalogued products with variants. It needs a tool that can manage compatibility rules between options.

The acronym pBOM is the most ambiguous of the five: some vendors use it as a synonym for mBOM, others for the intermediate step between design and routings. When a vendor or customer mentions a pBOM, ask which one they mean before comparing offers.

No need to set them all up at once. But knowing they exist prevents loading the mBOM with needs that belong to after-sales — a frequent confusion, and costly to untangle.

6. FAQ

What's the difference between eBOM and mBOM?

The eBOM describes the product as designed, with a functional structure derived from CAD. The mBOM describes how it's actually built: assembly sub-assemblies, consumables, scrap, packaging, and a structure following the assembly order. Both are correct, they simply answer different questions.

Can you have just one BOM?

Yes, and many SMEs do so without harm while the product stays simple and the team small. But the conversion still happens, somewhere, by someone — usually in a personal spreadsheet. The risk isn't the absence of an mBOM, it's that it exists without being managed.

Who should create the mBOM: engineering or methods?

Methods, because they alone know the work centres, routings, times and scrap rates. Asking engineering to produce an mBOM directly means asking it to industrialise — that's another job.

Should the mBOM live in the PLM or the ERP?

Both approaches exist and work. What matters isn't the location but the rule: one system is authoritative, the direction of flow is written down, and methods' additions are never overwritten by an automatic transfer.

How do I know whether my BOMs have diverged?

Take three products at random and compare the design list with the one used to purchase, line by line. The number of unexplained discrepancies gives you the measure — and makes a far more convincing argument than any talk about best practice.

Do you need a PLM to manage both?

Not necessarily at the start: a well-configured PDM and clean properties already cover the eBOM. PLM becomes useful when both structures must be linked, traced and modified together across departments — one of the signals to switch.

What does eBOM mean?

Engineering Bill of Materials: the structured list of the product's components as designed, usually derived from the CAD assembly and managed in the PDM or PLM.

What is a pBOM?

A process (or production) BOM. The term varies by vendor: sometimes a synonym for mBOM, sometimes an intermediate step where manufacturing engineers restructure the eBOM by workstation before linking it to routings. Always clarify which one is meant.