CAD-to-ERP BOM Sync: The Short Version
CAD-to-ERP BOM sync means pushing the as-designed bill of materials from Siemens NX and Teamcenter into your ERP’s as-manufactured structure without manual re-entry. inteliScience builds these connectors on NXOpen and the Teamcenter-SAP gateway, with human validation on the field mapping. Done right, it removes 780+ wasted engineering hours a year.
| Manual re-entry | Automated sync | |
|---|---|---|
| Who types the BOM into ERP | An engineer, twice | Nobody |
| When ERP sees a change | Days after release | Minutes after the ECO is approved |
| Typical error source | Decimal slips, stale revisions | Mapping rules, caught once |
| Design time reclaimed | None | ~3 hours per engineer per week |
The Problem: A CAD BOM Was Never Built to Enter Your ERP
Ask any engineering team where the day goes and someone will mention it: after the model is done, the same part list gets typed a second time into SAP. One of the CAD-in-engineering surveys we ran put it bluntly: people want AI to “automate SAP processes such as BOM” and keep “change logs in the system without the need for manual indexing.” That is not a fancy request. It is a plea to stop copying numbers between two windows.
The reason it hurts is structural. A CAD BOM, sometimes called the design BOM or DBOM, describes the product from a geometric perspective: what mates with what, in which assembly. Your ERP wants something else entirely. It wants procurement data, make-vs-buy flags, units of measure, and a material master number that no CAD system knows about.
So the CAD BOM cannot simply be “pushed” into ERP. It lacks procurement information, its metadata does not line up with ERP fields, naming conventions drift between the two systems, and it often contains items (reference geometry, weld representations, skeleton parts) that ERP cannot interpret. Every one of those gaps is currently closed by a human retyping and re-checking. That human is expensive and, on a bad Friday, wrong.
eBOM and mBOM Are Not the Same List
Here is the distinction that most “just connect the two systems” projects underestimate. The engineering BOM (eBOM) defines the product as designed. The manufacturing BOM (mBOM) defines it as built, with phantom assemblies, consumables, process steps, and plant-specific substitutions that never appear in the model.
Siemens’ own guidance is to keep these structures decoupled: the eBOM lives in Teamcenter, the mBOM is planned on the ERP side, and a governed handover connects them. In a typical Teamcenter-to-SAP flow, the EBOM is created as a versioned structure in Teamcenter and handed over to SAP, where the manufacturing planner turns it into an MBOM. The two are related, not identical, and the transformation between them is where the real engineering sits.
Sync, then, is not a copy. It is a controlled translation from one structure to another, with rules about what carries over and what gets added downstream. Treat it as a copy and you will fight duplicate parts and mismatched revisions for years.
Three Ways to Sync, and the One We Recommend
There are three honest patterns, and they are not equally good.
- Mirror every CAD revision. Every save or minor revision propagates to ERP. Simple to build, and noisy enough that planners start ignoring the updates within a month. We advise against it except for tiny catalogs.
- Selective propagation. Only structures marked “Released” flow through. Cleaner, and a reasonable default for teams without formal change control.
- Change-order driven. An approved engineering change order (ECO) is the trigger. The ERP update, the effectivity date, and the revision history all hang off one governed event.
Our clear recommendation for any team above a handful of BOMs is the change-order-driven pattern. It matches how manufacturing actually consumes changes, by effectivity rather than by CAD timestamp, and it gives auditors a single record to follow. Selective propagation is the acceptable fallback while you stand up change control. Full mirroring is a trap dressed up as the easy option.
How the Automation Actually Works
The mechanics are less exotic than vendors make them sound. You read the released structure out of NX or Teamcenter, transform it against a mapping, and write it to ERP on the trigger you chose above.
Extraction from an NX assembly is a short NXOpen script:
# Extract the released BOM from an NX assembly (NXOpen, Python)
import NXOpen
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
root = work_part.ComponentAssembly.RootComponent
rows = []
for child in root.GetChildren():
proto = child.Prototype.OwningPart
rows.append({
"part_number": child.DisplayName,
"quantity": 1, # duplicates get rolled up in the next step
"revision": proto.GetStringAttribute("Revision"),
})The transform is where discipline lives. You define, once, how each engineering attribute maps to an ERP master-data field, then fire the write only when the change order is approved, never on every CAD save.
# Sketch: map engineering attributes to ERP fields, push only on "Released"
FIELD_MAP = {
"part_number": "MATNR", # SAP material number
"quantity": "MENGE", # component quantity
"revision": "REVLV", # revision level
}
def to_erp(row):
return {FIELD_MAP[k]: v for k, v in row.items() if k in FIELD_MAP}
if change_order.status == "Released":
positions = [to_erp(r) for r in roll_up(rows)]
erp_client.upsert_bom(header=item, positions=positions)For SAP shops, most of this rides on the Teamcenter Gateway for SAP S/4HANA, the connector Siemens and SAP built jointly, shipped as the SAP Integration Gateway Service in the Teamcenter 2506 release (mid-2025). You rarely write the socket-level plumbing yourself. What you build is the mapping, the trigger logic, and the error handling around it. That is exactly the work an out-of-the-box gateway leaves on your desk. If your automation lives in custom NXOpen and scripting, our NX programming and automation work is the layer that keeps those extractors alive across NX upgrades.
This runs as a POC. What’s missing for production: field-mapping governance, ECO-triggered effectivity, revision-conflict handling, SAP master-data validation, monitoring, and rollback. We close the gap from “the script synced one BOM on my laptop” to “the whole plant trusts the ERP structure”. See how we deliver NX-to-ERP automation.
What Breaks in Production
A demo syncs one clean assembly. Production breaks on the messy 5%, and that 5% is the whole job.
The aim is not 100% automation. It is roughly 95% automated with 5% held back for deliberate human validation, the parts where an engineer must confirm a make-vs-buy call or resolve a naming clash. The failures cluster in predictable places: attributes that exist in NX but have no ERP field, part numbers that follow different conventions on each side, and revisions that arrive out of order when two engineers release in the same hour.
Field mapping is the quiet killer. Hand-maintaining a spreadsheet of “engineering attribute to ERP field” across thousands of part types does not scale, and it rots. This is one of the few places where an LLM earns its keep: we use a language model to propose mappings between engineering attributes and ERP master-data fields, then an engineer approves the mapping once and it becomes a rule. The AI drafts; the human signs. That keeps the human-in-the-loop principle your engineers asked for, without making them the bottleneck. It is the same pattern we apply across our enterprise AI integration work: AI does the tedious first pass, people own the decision.
The other reliable failure is treating the sync as fire-and-forget. Without monitoring and a rollback path, a bad mapping quietly corrupts hundreds of BOM lines before anyone notices. Change logs and effectivity dating are not paperwork; they are how you unwind a mistake.
Cost and Payback
The money case is unusually clean, because manual BOM entry has a measurable price.
| Failure mode (manual) | Reported cost |
|---|---|
| Manual BOM entry, 5 engineers × 3h/week | 780 hours/year, ~$39,000 in salary |
| Outdated specs reaching the floor | 200 units reworked, ~$45,000 + 80h QC |
| A single decimal-point error | ~$23,000 in unusable material |
| Wrong components across global sites | ~$67,000 mis-sourced |
Those figures come from industry case tallies of BOM errors, not from a marketing deck, and they line up with what we see on real handovers. The upside is symmetric: integrated flows shorten the engineering-to-manufacturing handoff, and payback comes fastest for teams carrying more than 50 BOMs or processing over 100 changes a month. Below that volume, honest answer: fix your naming conventions first and revisit automation later. We have delivered this kind of engineering automation where the payback was fast, and we have also told teams they were too small to bother yet.
If your BOM transfer runs through Teamcenter, our Teamcenter SAP integration service covers material masters, BOMs and change numbers between Teamcenter and SAP.
Frequently Asked Questions
What is the difference between an eBOM and an mBOM?
The eBOM is the product as designed: the structure that comes out of Siemens NX and Teamcenter. The mBOM is the product as manufactured, with process steps, consumables, and plant-specific items added on the ERP side. Sync connects them; it does not make them identical.
Can you push a CAD BOM directly into SAP or another ERP?
Not cleanly. A CAD BOM lacks procurement data, uses naming that rarely matches ERP fields, and contains items ERP cannot interpret. You need a mapping layer and a trigger, which is exactly what the automation provides. Skipping that layer is why so many “direct” integrations quietly fail.
How much does CAD-to-ERP BOM automation cost, and when does it pay back?
Cost depends on ERP, connector, and how messy your part data is. The reference point most teams care about: payback comes fastest once you are above roughly 50 BOMs or 100 monthly changes, against 780+ engineering hours a year lost to manual entry. Under that volume, the numbers rarely justify it yet.
Should we sync every CAD revision or only released ones?
Only released ones, and ideally only on an approved engineering change order. Mirroring every revision floods ERP with noise that planners learn to ignore. Change-order-driven sync matches how manufacturing consumes changes, by effectivity date, and gives you a clean audit trail.
Do we need Teamcenter, or can we connect NX directly to ERP?
You can extract a BOM straight from NX with NXOpen, and for small shops that is enough. But without Teamcenter you take on revision control, effectivity, and change governance yourself. For most manufacturers the Teamcenter-to-ERP path is less custom code and far less risk.
Next Step
If manual BOM re-entry is eating your engineers’ week, the fastest way to know whether automation pays back is a short scoping conversation: no product pitch, just an honest read on your volume and data quality.