Article 3 of 12 in PLM Foundations · PLMV-KB-003 · Rev. B · Reviewed 2026-11-04
PLM vs ERP: Where the Bill of Materials Should Live
PLM owns the product definition: CAD data, the engineering bill of materials (EBOM) and engineering changes until release. ERP owns planning, purchasing, production and cost, and acts as the execution master. The EBOM belongs in PLM. The manufacturing BOM (MBOM) can sit in PLM or in ERP, provided one system owns it and release to ERP is a controlled event.
Key takeaways
- PLM is the system of record for product definition, and ERP is the system of record for transactions and execution.
- The EBOM belongs in PLM, and the MBOM can sit in PLM, in ERP or be split between them, with one owner per BOM view.
- SAP and Microsoft both document change records and engineering-owned data inside their ERP products, which shows how the handover is modelled on the ERP side.
- Integration failures usually come from unclear ownership and effectivity rules, rarely from the interface technology.
What is the difference between PLM and ERP?
PLM manages how a product is defined and changed before anything is built. ERP manages how it is planned, bought, built, stocked and invoiced. Both hold items and bills of materials, which is why they appear to compete. The difference is purpose: PLM handles iterations, alternatives and approvals, while ERP needs one valid structure per plant and date to run material planning and production.
The ISA-95 standard gives a vocabulary for the ERP side. It places business planning and logistics, including ERP, at level 4 and manufacturing operations management at level 3, and it concentrates on the interface between them. PLM sits upstream of both and feeds them released definitions.
Where should the bill of materials live?
The EBOM belongs in PLM, next to the CAD structure and the engineering change process. The MBOM has three common homes.
PLM-centric. Manufacturing engineers build the MBOM in PLM from the EBOM and release it to ERP per plant. This gives one traceable chain from design to production and suits multi-site companies with frequent changes.
ERP-centric. PLM releases the EBOM and ERP users restructure it into a plant BOM. Manufacturing knowledge stays in ERP, and traceability between the two BOMs is weaker. It suits stable products.
Split. PLM owns the structure and ERP owns plant attributes and routings. Examples in the register include SAP PLM with S/4HANA, Oracle Cloud PLM with Oracle Fusion Cloud ERP and Infor PLM with Infor CloudSuite. The profile of Siemens Teamcenter lists a gateway to SAP S/4HANA and SAP ECC, and the profile of Arena PLM lists ERP systems through its Integration Marketplace. The BOM views are explained in EBOM, MBOM and SBOM.
PLM and ERP side by side
| Data or process | Owner | Notes |
|---|---|---|
| Part numbers, engineering attributes | PLM | ERP receives them on release |
| CAD models, drawings, specifications | PLM | ERP may hold a link |
| Engineering BOM | PLM | Not edited in ERP |
| Manufacturing BOM | PLM or ERP | One owner, see the models above |
| Routings, work centres, plant attributes | ERP or MES | Lead times, planning type, stock rules |
| Engineering change requests and orders | PLM | ERP receives effectivity |
| Standard and actual cost | ERP | PLM may show roll-ups for design decisions |
| Inventory, orders, invoices | ERP | Not held in PLM |
How do engineering changes flow from PLM to ERP?
Both vendors document the receiving side. SAP Learning describes the change number in S/4HANA as the controlled record for BOM edits: it captures why a change was made, can group several objects, and carries validity for a BOM header or single components. Microsoft documents engineering versions and a release wizard in Dynamics 365 Supply Chain Management. An engineering company owns products, versions, attributes and engineering BOMs, and releases them to operational companies. Operational companies cannot remove released BOM lines and see the engineering fields as read-only, but they can add local lines such as packaging. Microsoft also offers manual acceptance, so each receiving company reviews a release before it becomes active.
A robust handover therefore has a trigger (approved change order), a payload (released objects with revision and effectivity), validation in ERP with errors returned, an acknowledgement stored in PLM and instructions for stock and open orders. Engineering change management covers the process, and PLM integration architecture the interfaces.
What goes wrong when the boundary is unclear?
- Duplicate items. ERP users create temporary parts that PLM never sees.
- Unmanaged effectivity. A change becomes active on the transfer date instead of the planned date.
- Attribute sprawl. Hundreds of fields synchronise both ways without an owner.
- Cost blindness. Engineers cannot see the cost effect of a change because ERP costs never return.
A data ownership matrix agreed before integration design prevents most of these. List each object and attribute group, the owning system, the receiving systems and the event that triggers transfer. Review it when a plant, ERP instance or product line is added. Product data that spans customers, suppliers and channels is covered in PLM vs PIM vs MDM vs ERP.
Frequently asked questions
Should the MBOM live in PLM or ERP?
Both are valid. A PLM-managed MBOM gives better traceability from design to production and suits multi-plant companies with frequent changes. An ERP-managed MBOM keeps manufacturing knowledge close to planning and suits stable products. The requirement is a single owner per BOM view, with rules for effectivity and plant-specific data written down before integration work starts.
Which data flows back from ERP to PLM?
Common return flows include confirmation that a revision is active per plant, standard costs, stock and open order quantities for change impact analysis, and supplier or purchasing status. These flows are usually read-only in PLM. They help change boards judge the cost of a change and decide what happens to existing inventory before approving an engineering change order.
Do PLM and ERP need to come from the same vendor?
No. Many companies run PLM and ERP from different vendors and connect them through connectors or middleware. A single-vendor stack can simplify integration and support contracts, while a mixed stack lets each system be selected on its own merits. In both cases, data ownership rules and release logic need explicit design and testing.
Sources
- Microsoft Learn: Release product structures, Dynamics 365 Supply Chain Management
- Microsoft Learn: Engineering companies and data ownership rules
- SAP Learning: Managing material BOM changes with a change number, SAP S/4HANA Cloud Public Edition
- ISA: ISA-95 standard, enterprise-control system integration
Revision history
| Rev. | Date | Summary |
|---|---|---|
| B | Rewritten to answer where the bill of materials should live, with SAP and Microsoft documentation on change numbers and released structures, and a change flow section. | |
| A | Initial release. |
Written by Stephan Spijkers. Reviewed 4 November 2026 by the PLM Vendors editorial team. Regulatory dates and vendor details change; check the sources for the latest position. Corrections with a source: info@plmvendors.com.
Continue in PLM Foundations