A recent r/engineering thread on EBOM-to-MBOM translation collected 134 upvotes and 81 comments. The answers split into two camps: “PLM would fix this if companies actually deployed it properly,” and “our team of eight doesn’t have budget for PDM let alone PLM.” Both responses miss the same root cause. The problem starts in how SolidWorks generates an EBOM and what that structure cannot express that manufacturing requires.
What SolidWorks Actually Gives You
When you insert a BOM table into a SolidWorks drawing or export one from an assembly, you get a direct reflection of the assembly tree. Each component becomes a row. Sub-assemblies appear as parent items with children. Quantities are instance counts.
This is your EBOM. It mirrors design intent: how the product is structured as an engineered artifact. The hierarchy makes sense from a design perspective — the motor housing sub-assembly groups together because those parts were designed together, not because they’re fabricated together.
Manufacturing doesn’t consume products in the same structure they were designed in.
The Four Gaps Between EBOM and MBOM
1. Phantom Assemblies
In SolidWorks assemblies, you frequently create sub-assemblies that are organisational containers — a “fastener group” or “hardware sub-assembly” that you modelled together for clarity but which the shop floor just picks individually from bins. Nobody builds that sub-assembly as a unit.
In MBOM terms, these are phantom assemblies. They appear in the EBOM but collapse in the MBOM: every component moves up one BOM level, and the phantom itself disappears. SolidWorks has no native concept of a phantom. You either flatten manually or maintain a parallel BOM structure in Excel.
Identifying phantoms requires a conversation between engineering and manufacturing — “do you actually build this sub-assembly, or do you just install the parts directly?” That conversation rarely happens before the ERP team starts keying in the BOM.
2. Virtual Components
SolidWorks lets you add virtual components to a BOM table — items that appear in the BOM but have no .sldprt file. Standard fasteners, adhesives, lubricants, packaging. You add them by right-clicking in the BOM table and inserting a row, or by adding a part to the assembly in virtual mode.
The problem: virtual components are drawing-BOM entities. They don’t live in the assembly file in a way that persists reliably across team members. When another engineer opens the assembly and regenerates the BOM in a different drawing template, virtual components may not appear, or appear differently. There is no single source of truth.
For ERP, every MBOM line item must map to a part number in the item master. Virtual components that only exist in a drawing BOM cannot make that jump reliably. They end up copied manually — which means they drift as soon as a hardware change is made.
3. Operations and Routing
The MBOM needs manufacturing operations: weld, press brake, paint, powder coat, QC inspection. These are not parts. SolidWorks has no representation for a work centre or a routing step.
Some teams add operations as virtual components with $PRP:"Description" set to “WELD PER DRAWING” or “POWDER COAT — BLACK.” This technically places text in the BOM table. But ERP systems model operations as routing records — a separate data structure from BOM line items, with sequence numbers, machine assignments, and standard times. A BOM row is the wrong container.
The mismatch forces a manual translation step regardless of how clean the EBOM is.
4. Make vs. Buy Classification
Every MBOM item carries a make/buy indicator. Fabricated sheet metal parts: make. Standard hardware: buy. Subcontracted assemblies: buy. SolidWorks doesn’t have this concept natively.
The standard workaround is a custom property — Make_Buy with values like “Make”, “Buy”, “Sub”. It works, but only if every engineer on the team maintains it on every part, consistently, across every configuration. In practice, it drifts. New parts get created without it. Copied parts carry the wrong value from the source.
Custom Properties Are the Bridge — When They’re Maintained
Custom properties are the primary mechanism for attaching manufacturing-relevant data to SolidWorks parts. They live in the .sldprt file and propagate through assemblies into BOM tables. The ones that matter:
Description— the item description for the ERP item masterPart Number— your internal part number (teams that use filenames here cause downstream pain)Material— full specification, not just “Steel”; write “A36 HR Steel” or “304 SS 2B”Finish— surface treatment: “Clear Anodize”, “Zinc Plate”, “Powder Coat RAL 9005”Make_Buy— make/buy classificationMass— drives shipping weight and landed cost estimates
The reliability of the EBOM-to-MBOM handoff is directly proportional to how consistently these are populated. A 40-component BOM where 12 parts have blank Description fields requires 12 manual lookups before the ERP team can create item masters. This is where the gap between EBOM and MBOM becomes an operations problem, not an engineering one.
PDM enforces required fields at check-in, which is the strongest safeguard. Without PDM, you’re relying on individual discipline and code reviews of BOM exports before they leave engineering.
Configurations Multiply the Problem
If your parts use configurations — which they should, for variant management — the MBOM question becomes: which configuration is the manufactured item?
SolidWorks BOMs can show the active configuration, all configurations as separate rows, or a merged view. There’s no native way to mark a configuration as “this is the released, shipped state.” Teams that build configurable products need one BOM row per variant, each with its own part number.
The correct approach: set Part Number at the configuration level, not the part level. In the BOM options, configure the column to pull $PRP@ConfigurationName:"Part Number". This gives each configuration a distinct part number that maps to a distinct ERP item. Most teams don’t implement this until they’ve discovered the hard way that configuration-level properties propagate differently from part-level ones.
Configuration-to-part-number mapping also breaks down at the cut list level. The SolidWorks cut list names through insert-part and derived configurations article covers that specific problem in detail.
The ERP Handoff in Practice
Even when the EBOM is clean, the handoff to ERP is usually manual. The standard workflow:
- Export BOM to Excel from SolidWorks drawing
- Add columns for operations, lead times, preferred vendors, cost centres
- Import to ERP via a template or hand-key into the item master
- On every engineering change: repeat steps 1–3 for the affected parts
Step 4 is where drift accumulates. An engineer modifies a countersink, re-exports the DXF, sends it to the fabricator. Nobody updates the ERP item master revision. The MBOM is now showing the old geometry.
The PDM BOM problem on the SolidWorks shop floor describes this failure mode exactly: PDM manages the revision history in CAD, but downstream manufacturing data — routing, operations, make/buy — lives outside CAD and gets out of sync with every change that doesn’t trigger a formal ECO process.
What to Clean Up Before the Handoff
If you’re preparing an assembly for MBOM creation without a PLM system, the practical checklist:
At the part level:
Description,Part Number,Material, andMake_Buypopulated at the configuration level — not just the part levelMaterialincludes full specification: grade, condition, and finish for raw stock- Part numbers match the ERP item master exactly — no trailing spaces, no case variation
At the assembly level:
- Virtual components either have corresponding ERP item masters, or are moved to a separate hardware list in the drawing notes
- Sub-assemblies that are phantoms on the shop floor are identified, typically via a custom property
Assembly_Type = Phantomthat the ERP team knows to flatten - Configurations documented: which config maps to which product variant or sales order option
At the BOM table level:
- Identical parts set to
Display as one itemwhere quantities should be combined - Child parts in phantom sub-assemblies manually checked for correct level assignment in the exported MBOM
- BOM compared against a known build (physical count or production traveller) before it leaves engineering
Where CadShift BOM Manager Fits
CadShift’s BOM export resolves custom properties from the active configuration of each component, not just what’s visible in the drawing BOM. Material, Make_Buy, Finish, and any team-defined properties come through consistently in the exported file without copy-paste from the SolidWorks BOM table.
This removes one manual step — the export itself — and eliminates the category of errors that come from manually transcribing BOM data. It doesn’t solve the upstream problem: blank properties are still blank, phantom assemblies still require a manufacturing conversation, operations still need a routing structure. But it means the data that does exist lands cleanly in the handoff file.
The four levels of CAD automation in SolidWorks puts this in context: the BOM export step is level 2 (batch output), and it’s worth automating precisely because manual BOM transcription introduces errors at predictable rates on every release cycle.
The Structural Problem Has No Shortcut
The EBOM-to-MBOM gap persists because the two BOMs serve different masters. The EBOM serves the designer. The MBOM serves the factory. No tool bridges a phantom assembly problem that engineering hasn’t decided to address. No export script captures routing steps that nobody has defined.
The teams that hand off cleanly don’t have better tools than everyone else. They have a rule — every part entering the system gets its properties populated — and a process for catching violations before the BOM leaves engineering. The friction is upstream. The export is the easy part.