What the PLM Vendors Will Tell You
Duro, OpenBOM, PTC, Teamcenter: they all tell the same story. The eBOM is the product as designed. It comes out of Onshape or SolidWorks or KiCad, organized by function, full of specs and tolerances. The mBOM is the product as built. It's derived from the eBOM, reorganized by assembly sequence, and padded with the things design never tracks: consumables, tooling, fixtures, packaging, work instructions.
The standard example is screws. Your eBOM lists twelve of them as one line, qty 12. The mBOM scatters them into the subassemblies where they actually get installed, because that maps to how the product gets put together.
The definition is correct. It also describes a company you are not running.
You Have One BOM. Your CM Has Another.
Here's what actually happens at a startup.
You build a BOM in your CAD tool or a spreadsheet. It's your source of truth. You send it to your contract manufacturer; sheet metal to Xometry, a board to your PCBA shop, full assembly to your CM. They open it in their system and rebuild it for their floor. They regroup the subassemblies to match how their line runs. That reorganization is the mBOM, and it lives on their production line, not yours.
So the mBOM does exist. You're just not the one holding it.
Then they do the thing nobody warns you about: they swap your vendors for theirs.
The Vendor Swap You Never Approved
Contract manufacturers come with their own supplier relationships, and they trust them more than the ones in your BOM. You specced a resistor from one vendor; your CM already buys that resistor from someone else, at a better price, with a lead time they can count on. So they use their guy. They are not asking. From their seat, sourcing a part they already stock is the obvious call.
In isolation, it's a reasonable decision. Across your whole BOM, it means the parts going into your product are coming from suppliers you never chose and may not even know about.
That version of your BOM, reorganized and re-sourced, lives in their ERP. Your BOM lives in yours. They drift apart in silence.
The moment it matters arrives later. The vendor your CM quietly substituted hits a shortage. Your lead times double. You call to ask why, and they tell you they've been buying that part from that supplier for six months. You check your records; your BOM says something else entirely. Now you're reconstructing a divergence nobody wrote down, during a shortage, which is the worst possible time to be doing it.
Why This Is Worse for You Than for Boeing
A contract manufacturer optimizes for its own constraints: lead time, cost, floor efficiency. Reorganizing your subassemblies cuts their setup time. Sourcing from their existing supplier cuts their procurement hassle. Every one of those moves makes their job easier and your product less visible to you.
A big company absorbs this. They have second-source agreements, procurement teams, and enough volume that the CM doesn't freelance on sourcing. You have none of that. You can't eat a lead-time shock, and you can't run down a quality problem when you don't know whose part is actually in the unit. The gap between your BOM and their build is a liability you carry alone.
The Fix Is a Conversation, Not a Second BOM
You don't need to stand up a formal mBOM in your own systems. Most startups never should. What you need is for your CM's version to stop being invisible.
Treat what the CM actually builds as the truth, and pull it back into your BOM:
- When they substitute a part, they document it in writing. Not a verbal aside, not a buried Slack line. The new part, and the reason: lead time, cost, an existing supplier relationship. You read it, you decide whether to accept it or push back.
- When they accept your BOM, they confirm it explicitly. The revision they're building to, the subassemblies they're using, the parts they're sourcing and from whom. You write it down and compare it to your file. Where it doesn't match, you ask why.
- When something changes, you update your BOM to match reality. Not because you're maintaining two documents, but because your BOM should describe what is being built, not what you drew.
Then you keep talking about it. Your CM uses their supplier for screws because of price and lead time; you record that. When that supplier has a shortage six months out, you're not blindsided, you already know the dependency exists, and you can lean on the CM to dual-source before it bites.
What the Sync Buys You
It buys visibility: you know what's in your product instead of guessing from what you designed. It buys speed when a shortage hits, because you already know which supplier is involved and skip the week of reverse-engineering your own supply chain. It buys leverage, because understanding your CM's sourcing lets you challenge a risky swap or demand a second source before the problem shows up. And it buys clean handoffs, because when you change manufacturers or ramp production, you have a real record of what was being built instead of a design file that stopped matching reality a year ago.
The mBOM isn't a document your CM keeps from you. It's a conversation you refuse to stop having, written down, so you and the people building your product are working from the same reality.
For a startup, that's the whole of eBOM vs mBOM.
oroForge keeps your BOM, your revisions, and your supplier data in one place so the gap between what you designed and what's getting built stays small. See how it works.
