How to Sync the BOM Between PLM and ERP
how to sync BOM between PLM and ERP
Also searched as
- PLM to ERP BOM integration best practice
- engineering BOM vs manufacturing BOM sync
- which system owns the BOM PLM or ERP
- EBOM to MBOM transfer to ERP
Short answer
Make PLM the system of record for the engineering BOM (EBOM) and ERP the system of record for the manufacturing BOM (MBOM), and push only released data from PLM to ERP on a change-release event. Never edit the same BOM structure in both systems, and treat every failed transfer as a visible work item, not a silent log line.
Applies to: Any PLM (Windchill, Teamcenter, Arena, Agile, Propel, Aras, SolidWorks PDM) feeding any ERP (SyteLine, LN, M3, NetSuite, SAP, Dynamics, Epicor)
How to set up a PLM to ERP BOM sync
- 1Write down data ownership per attribute: PLM owns part number, description, revision, EBOM structure and CAD links; ERP owns cost, lead time, planning parameters, routing and MBOM.
- 2Define the trigger as a released change order (ECO) reaching its final lifecycle state, not a nightly poll of every modified part.
- 3Map PLM item attributes to ERP item master fields in a spreadsheet first, including unit of measure, item type, make or buy code and lifecycle status.
- 4Map PLM BOM lines to ERP BOM lines, deciding how phantom assemblies, reference designators, find numbers and alternates are represented in each system.
- 5Build the transfer through the ERP's supported import path (staging table, BOD, REST API or import utility) and never write directly into production BOM tables.
- 6Add an acknowledgement step: ERP returns success or a specific error per line, and PLM records the sync status against the released ECO.
- 7Create an error queue owned by a named person, with alerts, so a rejected BOM is fixed the same day.
- 8Test with five real assemblies including one with an alternate, one phantom and one multi-level structure before cutting over.
EBOM and MBOM are not the same document
The engineering BOM describes what the product is: every part as designed, grouped by function or assembly, with reference designators and find numbers. The manufacturing BOM describes how it is built: grouped by operation or kit, with consumables, packaging, phantom sub-assemblies for planning and sometimes different quantities per work center.
Syncing a raw EBOM straight into ERP usually produces a structure that planning cannot use. MRP wants the structure that matches how the plant stages material. The common pattern is that PLM releases the EBOM, an engineer or a rules step derives the MBOM (adding routing links, phantoms, scrap factors), and only the MBOM becomes the planning BOM in ERP.
Some PLM suites hold both views and push the MBOM. Others only hold the EBOM and the ERP side is where manufacturing engineering builds the MBOM. Either works as long as one place is clearly the master for each view and the link between them is traceable.
Release-triggered sync beats polling
Polling the PLM for changed items every night sends work-in-progress data. An engineer who saves a draft revision at 4 pm should not create an ERP item at 11 pm. Trigger from the workflow state: when an ECO reaches Released, collect every affected item and BOM at that revision and send them as one package.
A package is better than individual messages because ERP needs the new item to exist before a BOM line can reference it, and a child item before its parent. Sort the package so items go first, then BOM headers bottom-up, then BOM lines. If any piece fails, hold the whole ECO in a sync-failed state.
Keep the package idempotent. If the same ECO is sent twice, the second run should detect the same revision and do nothing, not create a duplicate BOM line or a second revision record.
Release package order: 1. New or changed ITEMS (item master) 2. BOM HEADERS bottom-up (lowest level first) 3. BOM LINES with effectivity dates 4. Document links and attachments 5. Acknowledgement back to PLM per ECO
Line-level mapping decisions that cause rework
Reference designators are the classic mismatch. PLM keeps R1, R2, R3 as one line with quantity 3 or as three lines; ERP BOMs often need one line per component. Decide once and apply it everywhere. The same goes for find numbers, which ERP may treat as a sequence that must be unique within a BOM.
Alternates and substitutes need an explicit rule. If PLM holds approved manufacturer parts (AML/AVL) and ERP holds substitute items with priorities, the sync should create ERP substitute records only for engineering-approved alternates, not every purchasable part number.
Quantity per and unit of measure conversions break silently. A PLM line in millimeters against an ERP item stocked in meters will transfer without error and plan wrongly. Validate UoM against the ERP item master in the transfer, and reject mismatches.
Failure handling and reconciliation
Most failed syncs are data problems, not network problems: an item with no make or buy code, a UoM that does not exist in ERP, a parent flagged obsolete, a duplicate find number. Return the ERP's error text to the PLM against the ECO so the engineer sees it where they work.
Run a reconciliation report weekly. Compare released PLM revisions to the ERP active revision for each item and list differences. Drift always appears eventually, from emergency edits made directly in ERP or from a skipped ECO, and the report finds it before the next build uses the wrong structure.
Lock the sync targets in ERP. If planners or buyers can edit BOM lines directly, the next release will overwrite their change or, worse, merge with it. Use permissions to make the synced fields read-only outside the interface user.
Common pitfalls
- !Letting both PLM and ERP edit the same BOM lines, which guarantees drift and arguments about which is right.
- !Syncing on save or on a nightly poll instead of on a released change, which pushes draft data into planning.
- !Writing directly into ERP BOM tables with SQL, bypassing validation, audit fields and effectivity logic.
- !Ignoring unit of measure and make or buy mismatches, which transfer cleanly and then plan incorrectly.
- !No owner for the error queue, so rejected BOMs sit for weeks while the shop builds from paper.
- !Treating the integration as a one-time project instead of something that needs a regression test whenever either system is upgraded.
How an ERP-grounded AI assistant handles this
An AI assistant grounded in the ERP (ERPray, or SyteRay on SyteLine) can answer the questions that make a sync trustworthy: which active BOMs differ from the PLM released revision, which items failed the last transfer and why, and which assemblies in open work orders use a superseded structure. It reads the data and shows the query, so an engineering manager can verify the answer. It does not write BOMs; changes still go through the interface and your approval flow.
Frequently asked questions
Should PLM or ERP own the BOM?
Split it. PLM owns the engineering BOM and the revision history, because that is where design intent and change control live. ERP owns the manufacturing BOM, since planning, routing and costing depend on it. The key is that each view has exactly one master and the link between them is recorded.
Do I need middleware or an iPaaS for this?
Not always. For one PLM and one ERP, a direct integration using the ERP's import API or staging tables can be enough. Middleware earns its place when you have several plants, several ERPs, or need queuing, retries and monitoring that you do not want to hand-build.
How often should the BOM sync run?
On every released change, not on a clock. Event-driven release means ERP sees a change within minutes of approval. A nightly reconciliation job is still worth running as a safety net to catch drift and missed transfers.
What happens to open work orders when a BOM syncs?
That depends on the ERP and on effectivity. Existing work orders usually keep the BOM snapshot they were released with, while new orders pick up the new revision from its effective date. You must decide per change whether open orders are reworked, used up or scrapped.
Related
ECO and ECN Process Across PLM and ERP
An ECR requests a change, an ECO authorizes and defines it, and an ECN notifies the organization once it is released. PLM should run the workflow up to release, and ERP should receive the released result with an effectivity and a disposition for existing stock and open orders.
How-toEngineering Change Impact on Open Orders
Before releasing an engineering change, run a where-used on each changed part, then list open work orders, purchase orders, stock, WIP and customer orders that reference it, and set a disposition (use up, rework, scrap, return, or cut over). Record the decision per quantity so planners act on it instead of guessing.
How-toManaging Item Revisions and Effectivity in ERP
A revision identifies a released state of a part or BOM; effectivity says when, or for which units, that revision applies. Use date effectivity for most changes, lot or serial effectivity when traceability matters, and keep revision letters controlled by PLM so ERP never invents its own.
How-toHow to Create ERP Items from CAD Automatically
Generate the part number once, in one place (usually PDM or PLM), carry the attributes as CAD properties, and push a released item to the ERP item master through its import interface with validation. Retyping parts into ERP is the main source of duplicates, wrong units and missing make or buy codes.
How-toHow to Run an ERP User Access Review (Quarterly Checklist)
An ERP user access review is a recurring control where system owners confirm that every active user, role and privileged permission is still justified. Extract users and roles from the ERP itself, join them to HR status, send each business owner a scoped list to certify or revoke, record the decisions, and execute the removals with ticket evidence.
How-toHow to Test ERP Backup and Disaster Recovery
A backup is only proven when you have restored it and a user has transacted in the restored system. Define RTO and RPO with the business, restore the full ERP stack (database, application, integrations, attachments, secrets) to an isolated environment, run a scripted smoke test, time every step, and record gaps as action items.
AI for ERPAI for Engineering Change Impact on BOMs, Routings, and Open Orders
AI reads a proposed ECO against live BOM, routing, and open order data to show engineering exactly what a change touches before it gets released.
AI for ERPAI for Arena PLM: Questions, Change Drafts and ERP Comparisons Without Handing Over Your BOMs
AI for Arena PLM using its REST API: query items, BOMs, AML and change orders, draft ECO text and compare to your ERP with models you control.
Stuck on PLM and ERP (engineering and manufacturing BOM)?
Talk to engineers who work inside PLM and ERP (engineering and manufacturing BOM) every week, and who build private AI that answers these questions from your own ERP data.