> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://tieback.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://tieback.io/docs/_mcp/server. # ERP vs PIM vs PLM: What's the Difference? > A vendor neutral explanation of ERP, PIM, PLM and MDM: what each system owns, what it does not own, how they work together, and how Digital Product Passport programmes should draw on each of them. ## Executive Summary Ask five people in a manufacturing business where product data lives and you will get five answers: the PLM system, the ERP, the PIM, a master data platform, or a spreadsheet maintained by someone in regulatory affairs. All five answers are usually correct, and that is the problem. ERP, PIM, PLM and MDM are not competing systems. They are four different answers to four different questions about the same product. **PLM** owns how the product is defined and engineered. **ERP** owns how the business transacts and executes against it. **PIM** owns how the product is described to commercial channels. **MDM** owns the reconciliation between them, so that the organisation has one agreed identity and one agreed set of shared attributes. A [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) programme touches all four, and this is where most programmes go wrong. The attributes a passport must publish do not sit in one place: composition and specifications come from PLM, identifiers, packaging and logistics attributes from ERP, commercial descriptions and imagery from PIM, and the reconciled identity from MDM. Teams that fail to map this end up either duplicating attributes in the publication layer or wiring the passport directly to whichever system was easiest to integrate. The framework in this article, **The Enterprise Product Data Landscape**, orders these systems by what they own and shows why the passport sits at the end of the chain and the customer beyond it. The governing rule is the one established in [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data): each attribute has exactly one owning system, everything downstream references it, and the passport publishes rather than authors. Nothing in this article is vendor specific. The boundaries described are functional. Real products overlap them: many ERP suites include product data modules, several PLM platforms offer commercial enrichment, and some MDM platforms present themselves as PIM. What matters is not the badge on the software but whether each attribute has one unambiguous home. Framework TBF-021 The Enterprise Product Data Landscape Assigns clear ownership to PLM, ERP, PIM and MDM so teams know which system is authoritative for which attribute. ## Table of Contents * [Definition](#definition) * [Enterprise Systems Overview](#enterprise-systems-overview) * [The Enterprise Product Data Landscape](#the-enterprise-product-data-landscape) * [PLM Explained](#plm-explained) * [ERP Explained](#erp-explained) * [PIM Explained](#pim-explained) * [MDM Explained](#mdm-explained) * [How They Work Together](#how-they-work-together) * [Digital Product Passports Across Enterprise Systems](#digital-product-passports-across-enterprise-systems) * [Benefits](#benefits) * [Common Mistakes](#common-mistakes) * [Frequently Asked Questions](#frequently-asked-questions) * [Key Takeaways](#key-takeaways) * [Related Glossary Terms](#related-glossary-terms) * [References](#references) * [About This Article](#about-this-article) ## Definition PLM (Product Lifecycle Management) governs the definition of a product from concept through design, engineering change and retirement. ERP (Enterprise Resource Planning) governs the execution of business processes against that product: procurement, manufacturing, inventory, fulfilment and finance. PIM (Product Information Management) governs the enriched commercial description of the product for sales channels. MDM (Master Data Management) governs the reconciliation and stewardship of shared identity and attributes across all of them. The simplest way to hold the distinction is to attach a question to each system: * **PLM** answers: what is the product, as designed and specified? * **ERP** answers: what is the business doing with it? * **PIM** answers: how is it described to buyers? * **MDM** answers: which record is the agreed one, and what do the shared attributes mean? None of these answers a fifth question, what happened to a specific unit in the physical world , which is the domain of event data and [EPCIS](/docs/knowledge-base/standards-and-technology/what-is-epcis) rather than of any of these systems. > **Functional, not commercial, boundaries** > > Software vendors regularly cross these lines, and that is legitimate. Use the boundaries to decide > where an *attribute* is owned, not to decide how many products you must buy. One well-governed > platform can hold several of these roles; four platforms with no ownership map will still produce > conflicting data. ## Enterprise Systems Overview Before examining each system, it helps to see them side by side. | System | Primary question | Typical owners | Data character | Change rhythm | | ------- | -------------------------- | ------------------------------------ | ------------------------------------- | ------------------------------ | | **PLM** | What is it, as designed? | Engineering, R\&D, quality | Structures, specifications, documents | Governed revisions and changes | | **ERP** | What are we doing with it? | Supply chain, manufacturing, finance | Transactions plus operational master | Continuous transactions | | **PIM** | How is it described? | Marketing, e-commerce, category | Copy, media, channel attributes | Frequent, campaign driven | | **MDM** | Which record is the truth? | Data governance, IT | Golden records, mappings, hierarchies | Slow, deliberate, audited | Three further systems appear regularly in passport programmes and are worth naming so they are not confused with the four above: **QMS** holds conformity evidence, test results and certificates; **MES** holds production execution data; **WMS** and transport systems hold movement and location events. They are sources of evidence and events, not substitutes for the product record. ## The Enterprise Product Data Landscape Organisations rarely disagree that all four systems are needed. They disagree about which one "owns" a given attribute, and that disagreement is what produces duplicated, divergent product information, and, eventually, a passport that contradicts the technical file. **The Enterprise Product Data Landscape** resolves this by ordering the systems by the direction in which trusted product information flows, ending with the audience that consumes it. Each layer is described by what it owns and, just as importantly, by what it does not own. The structural claim is the same as in the Product Data Foundation Model, applied to systems rather than to data categories: **information flows downward and dependency never reverses**. PIM may consume ERP and PLM attributes; PLM must never take an engineering value back from a marketing description. The passport may consume all four; none of them may treat the passport as a source. Systems of record Reconciliation Publication and audience 01 PLM Product definition **Owns:** the engineering definition, bill of materials, materials and substances, specifications, tolerances, revisions, engineering change and design documentation. **Does not own:** prices, stock, orders, channel copy, or the reconciled commercial identity of the product. 02 ERP Business execution **Owns:** the operational and commercial record, item codes, units of measure, packaging and logistics attributes, costs, suppliers, inventory, orders, production and financial postings. **Does not own:** the engineering definition, marketing narrative, or the governance of attribute meaning across the enterprise. 03 PIM Commercial description **Owns:** the channel-facing description, commercial names, marketing copy, translations, imagery and media, category attributes and channel-specific formatting. **Does not own:** composition, conformity evidence, stock, price of record, or any regulated technical value it merely displays. 04 MDM Reconciled truth **Owns:** the golden record, identity resolution and de-duplication, cross-system mappings, hierarchies, shared attribute definitions, validation rules and the stewardship workflow behind them. **Does not own:** the origin of any attribute. MDM reconciles and governs; it does not invent engineering, commercial or channel values. 05 Digital Product Passport Governed publication **Owns:** the publication itself, audience scoping, disclosure rules, language and format, the published snapshot, its version history and the binding to a persistent identifier and [data carrier](/docs/knowledge-base/standards-and-technology/what-is-a-data-carrier) . **Does not own:** any product fact. Every attribute it shows must trace to PLM, ERP, PIM, MDM, a quality system or an event record. 06 Customers Audience **Owns:** the judgement. Consumers, retailers, repairers, recyclers and [market surveillance](/docs/knowledge-base/glossary/market-surveillance) authorities decide whether the published information is usable, consistent and credible. **Does not own:** anything upstream, which is precisely why the quality of every layer above becomes visible here. Information flows downward. Each attribute is owned once, referenced many times, and published last. ## PLM Explained PLM is where a product first exists as a definition rather than an intention. **What it owns.** The structural and technical truth of the product: the engineering bill of materials, component and material specifications, substances and their concentrations, drawings and CAD, tolerances and test methods, revision history and the engineering change process that governs how a definition may be altered. In regulated industries it commonly also holds the technical file structure and the linkage between design decisions and conformity requirements. **What it does not own.** Anything commercial or operational. PLM does not know what the product costs to buy today, how many are in the Rotterdam warehouse, what the marketplace listing says, or which retailer ordered what. Attempts to make PLM the enterprise product catalogue typically fail because its change control, appropriately heavy for engineering, is unusable for daily commercial work. **Why passports depend on it.** Most of the genuinely difficult passport attributes are PLM attributes: material composition, substances of concern, recycled content by component, repairability and spare part structure, durability characteristics. If these are held only in drawings and PDFs rather than as structured, queryable data, the passport programme becomes a data extraction project. #### A composition attribute that only PLM can answer A passport must state recycled content by material for a product with fourteen components. That number is not in the ERP, which knows purchase costs, nor in the PIM, which knows the marketing claim. It is derived from the engineering bill of materials plus supplier declarations held against each component. If the BOM is structured, the figure is computed. If it is a drawing note, it is estimated, and an estimate published as fact is the beginning of a compliance problem. ## ERP Explained ERP is where the business actually runs, and consequently where most organisations have their highest data volumes and their strongest operational discipline. **What it owns.** The operational item record and everything transacted against it: internal item codes, units of measure and conversions, packaging hierarchies and logistics attributes, weights and dimensions as handled, suppliers and purchase terms, standard and actual costs, inventory, work orders, sales orders, shipments and financial postings. In many organisations the ERP also holds the [GTIN](/docs/knowledge-base/standards-and-technology/what-is-a-gtin) and other trade identifiers, because that is where they are used commercially. **What it does not own.** The engineering definition, the marketing narrative, or the governance of what an attribute means across functions. An ERP will happily store a "material" field; it has no opinion on whether that field means primary material, dominant material by mass, or the material named on the label. That ambiguity is exactly what MDM exists to resolve. **Why passports depend on it.** Identity and logistics attributes usually originate here, and so does the answer to the question "which markets and channels does this product actually reach?" , which determines which regulatory obligations apply. #### Treating the ERP item master as the whole product record The ERP item master is complete for operations and structurally incapable of holding substance detail, test evidence or lifecycle documentation. Programmes that assume "the ERP has the product data" discover the gap after committing to a delivery date. ## PIM Explained PIM exists because commercial channels need far more descriptive content, in far more variants, than operational systems are designed to hold. **What it owns.** The presentation of the product to buyers: commercial names and short and long descriptions, translations and locale variants, imagery, video and documents for display, category and marketplace-specific attributes, and channel-specific formatting and syndication rules. **What it does not own.** Any technical or regulated fact. A PIM may display a weight, a material percentage or a certification, but it is a consumer of those values. When a PIM becomes the place where such values are typed in, the organisation has moved a regulated attribute into a system whose change control is designed for marketing copy. **Why passports depend on it.** Passports are read by humans in many languages, and the discipline of multi-language, multi-channel content management already lives in PIM. The translation workflows, media governance and locale handling a passport needs are frequently solved problems there. **Where the boundary genuinely blurs.** Some attributes are legitimately dual: a product name may be commercial in a catalogue and regulated on a label. The resolution is not to argue about systems but to split the attribute, a commercial name owned by PIM and a legal or label name owned by the regulated record, and to publish the correct one for each audience. #### Publish claims from the source, not the copy Where a value appears in both PIM and a technical system, publish the technical system's value to the passport and let PIM's version serve the marketing channel. If the two must be identical, make PIM's value a synchronised read of the source rather than an independently maintained field. ## MDM Explained MDM is the least visible of the four and the one that determines whether the other three can be combined at all. **What it owns.** Reconciliation and governance: identity resolution and de-duplication across systems, the cross-reference between the PLM part number, the ERP item code, the PIM product and the external identifier, product hierarchies and classifications, the canonical definition of each shared attribute, validation rules, and the stewardship workflow that decides who may change what. **What it does not own.** Origination. MDM does not invent an attribute value; it selects, validates and publishes the agreed one. An MDM programme that begins authoring product facts has become a fifth [system of record](/docs/knowledge-base/glossary/system-of-record) and has recreated the problem it was bought to solve. **Why passports depend on it.** A passport is published against one identity. In an organisation with several ERPs, a legacy PLM and a marketplace catalogue from an acquisition, the question "is this the same product?" is a real, unsolved question. Publishing before answering it produces duplicate passports for the same product, visible externally, and hard to retract. > **MDM without an MDM platform** > > Smaller organisations frequently perform the MDM function with a governed attribute register, a > clear ownership map and validation at the point of entry. The function is mandatory; the platform > is not. ## How They Work Together In a healthy architecture the flow is predictable and the ownership is boring. 1. **Definition.** A product is created in PLM with its structure, materials and specifications under engineering change control. 2. **Commercialisation.** ERP creates the item record for procurement, manufacturing, logistics and finance, referencing the PLM definition and adding operational attributes and trade identifiers. 3. **Reconciliation.** MDM links the PLM part, the ERP item and any external identifier into a single governed identity, applies the agreed attribute definitions and validates completeness. 4. **Enrichment.** PIM takes the governed record and adds channel content, translations and media for each market and marketplace. 5. **Evidence.** Quality and production systems attach certificates, test results and, where relevant, batch or unit-level records to the governed identity. 6. **Publication.** The passport layer selects the attributes each audience is entitled to, renders them, snapshots them and binds them to the identifier printed on the product. 7. **Consumption.** Customers, retailers, repairers, recyclers and authorities read the result, and compare it with everything else the organisation has published. Two integration principles keep that flow stable. **Reference, do not replicate**: downstream systems point at the owning system's value rather than storing an independent copy. Where a copy is unavoidable for performance or offline use, it is an explicitly dated, one-way synchronised copy, never an editable field. And **change propagates forward**: an engineering change that alters a published attribute must trigger review and re-publication, not silent divergence. #### One attribute, four systems, one owner Product weight. PLM holds the designed mass. ERP holds the shipping weight including packaging. PIM displays a rounded figure for the listing. The passport publishes the value relevant to the disclosure requirement. These are three genuinely different numbers, and the failure mode is not having three numbers, it is having three numbers that all claim to be "the weight" with no definition attached to any of them. ## Digital Product Passports Across Enterprise Systems A useful way to plan a passport programme is to take the attributes you must publish and assign each one an owning system before writing any integration. | Passport attribute group | Usual owning system | Common failure | | ------------------------------------ | ----------------------------- | --------------------------------------------------------------------------------------- | | Product identity and trade codes | ERP, reconciled by MDM | Duplicate identities across regions or acquisitions | | Commercial and legal naming | PIM (commercial), MDM (legal) | One name field used for two different purposes | | Material composition and substances | PLM | Held in documents rather than as structured data | | Specifications and performance | PLM | Published from a datasheet rather than the source | | Conformity evidence and certificates | QMS, linked from MDM | Expiry dates untracked, so published claims lapse | | Packaging and logistics attributes | ERP | Confused with product-level dimensions | | Responsible party and market scope | ERP and regulatory records | Wrong [economic operator](/docs/knowledge-base/glossary/economic-operator) for a market | | Repair, spares and end-of-life | PLM, service systems | Never modelled, because nothing commercial needed it | | Batch or unit-level history | Event data, not these systems | Batch claims published against a model identifier | | Translations and media | PIM | Regulated text translated without review | Three design rules follow. **Integrate to the owner, not to the easiest endpoint.** The convenient integration is usually to whichever system has a modern API. The correct integration is to whichever system owns the attribute. Where those differ, the shortcut becomes permanent and the lineage is lost. **Publish a snapshot, keep the lineage.** The published artefact should be immutable, but each attribute in it should record where it came from and when. That lineage is what turns a regulatory challenge from an investigation into a lookup. **Design for re-publication.** Engineering changes, certificate renewals and supplier substitutions will all invalidate published content. The programme needs a defined trigger and workflow for re-publishing, or the passport slowly becomes a historical document presented as current. ## Benefits **Faster passport delivery.** An attribute-to-system ownership map removes the single largest source of delay in passport programmes, which is discovering mid-build that nobody owns a required value. **Defensible published claims.** Every figure traces to an owning system and a named owner, so a challenge is answered by retrieval rather than reconstruction. **Lower integration cost.** Point-to-point connections from the publication layer to whatever was convenient are replaced by a small number of durable interfaces to owning systems. **Consistency across channels.** The same governed values feed marketplaces, retailer portals, datasheets and passports, so external parties stop finding contradictions. **Cleaner change management.** Engineering changes propagate through a known path, and the systems that must react, including the passport, are identifiable in advance. **Reduced duplication.** Reconciled identity prevents the same product being published twice under different codes, which is both a compliance and a customer-experience failure. **Better use of existing investment.** Most organisations already own the systems they need. The gain comes from ownership clarity rather than from new software. ## Common Mistakes #### Asking which system is 'the' product system The question has no answer, and pursuing it produces a political contest rather than an architecture. Ask instead which system owns each *attribute*. #### Buying a platform to avoid governance MDM and PIM platforms formalise decisions; they do not make them. Without agreed definitions and named owners, a new platform becomes an additional place where inconsistent data is stored. #### Publishing regulated values from the PIM Because the PIM already syndicates content, it is a tempting source for the passport. Its change control is designed for marketing copy, and regulated attributes published through it lose their link to the technical source. #### Using ERP customer-facing fields as compliance data Free-text ERP description fields are often repurposed over years for local needs. Treating them as a structured source produces published values whose meaning no one can now reconstruct. #### Leaving PLM out of the passport programme Composition, substances and repairability are the hardest passport attributes and they live in PLM. Programmes staffed only from commercial and IT functions consistently underestimate this. #### Ignoring identity reconciliation until publication Duplicate or ambiguous identity is discoverable early and expensive late. Once two passports exist for one product, the fix is externally visible. ## Frequently Asked Questions **Do we need all four systems to publish a Digital Product Passport?**\ No. You need all four *functions*. A smaller organisation may perform product definition, operations and enrichment in fewer systems, provided each attribute still has one owner and one home. **Can a PIM act as the passport platform?**\ It can host the content, but it should not become the source of regulated values. If a PIM is used, treat it as a publication channel that consumes governed data, with lineage back to owning systems. **Is MDM the same as a data warehouse?**\ No. A warehouse aggregates data for analysis and is a read-only consumer. MDM governs the operational [golden record](/docs/knowledge-base/glossary/golden-record) that transactional systems and publications rely on. **Where should the GTIN live?**\ Usually the ERP, because that is where trade identifiers are used commercially, with MDM ensuring it is unique and correctly associated with one governed product identity. **What about QMS, MES and WMS?**\ QMS holds conformity evidence, MES holds production execution, and WMS and transport systems produce movement events. They are important sources for a passport but they are not the product record. **How do event data and these systems relate?**\ Events describe what happened to identified objects and are typically shared using [EPCIS](/docs/knowledge-base/standards-and-technology/what-is-epcis). They reference the identity governed here; they do not replace any of these systems. **Should the passport hold its own copy of attributes?**\ It holds an immutable published snapshot, which is a copy with a purpose and a date. That is different from authoring an attribute that exists nowhere else. **What is the first step for an organisation with all four systems already?**\ Build the attribute-to-system ownership map for the products you must publish first. It usually takes weeks, not months, and it reprices the entire programme. ## Key Takeaways ## Related Articles * [How Enterprise Systems Support Digital Product Passports](/docs/knowledge-base/enterprise-systems-and-data-architecture/how-enterprise-systems-support-digital-product-passports) * [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data) * [What is a Golden Record?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-a-golden-record) * [What is Master Data Management (MDM)?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-master-data-management) * [Building an Enterprise Digital Product Passport Architecture](/docs/knowledge-base/enterprise-systems-and-data-architecture/building-an-enterprise-digital-product-passport-architecture) * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [How Does a Digital Product Passport Work?](/docs/knowledge-base/digital-product-passports/how-does-a-digital-product-passport-work) * [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain) ## Related Glossary Terms Definitions of record for the terms used above live in the [glossary](/docs/knowledge-base/glossary/overview). * [Product Data](/docs/knowledge-base/glossary/product-data) * [Product Identifier](/docs/knowledge-base/glossary/product-identifier) * [Product Lifecycle](/docs/knowledge-base/glossary/product-lifecycle) * [Product Traceability](/docs/knowledge-base/glossary/product-traceability) * [Digital Product Passport](/docs/knowledge-base/glossary/digital-product-passport) * [Data Carrier](/docs/knowledge-base/glossary/data-carrier) * [GS1](/docs/knowledge-base/glossary/gs1) * [Economic Operator](/docs/knowledge-base/glossary/economic-operator) * [Conformity Assessment](/docs/knowledge-base/glossary/conformity-assessment) * [Market Surveillance](/docs/knowledge-base/glossary/market-surveillance) * [Sustainability Data](/docs/knowledge-base/glossary/sustainability-data) * [Circular Economy](/docs/knowledge-base/glossary/circular-economy) * [ESPR](/docs/knowledge-base/glossary/espr) * [Delegated Act](/docs/knowledge-base/glossary/delegated-act) ## References * International Organization for Standardization, ISO 8000 series on data quality and master data: [https://www.iso.org/standard/81745.html](https://www.iso.org/standard/81745.html) * International Organization for Standardization, ISO/IEC 11179 on metadata registries: [https://www.iso.org/standard/78914.html](https://www.iso.org/standard/78914.html) * International Organization for Standardization, ISO 9001 on quality management systems: [https://www.iso.org/standard/62085.html](https://www.iso.org/standard/62085.html) * International Organization for Standardization: [https://www.iso.org](https://www.iso.org) * GS1 identification keys, including the GTIN: [https://www.gs1.org/standards/id-keys](https://www.gs1.org/standards/id-keys) * GS1 General Specifications: [https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications](https://www.gs1.org/standards/barcodes-epcrfid-id-keys/gs1-general-specifications) * GS1 EPCIS and Core Business Vocabulary standard: [https://www.gs1.org/standards/epcis](https://www.gs1.org/standards/epcis) * GS1, the global standards organisation: [https://www.gs1.org](https://www.gs1.org) * Regulation (EU) 2024/1781 establishing a framework for the setting of ecodesign requirements for sustainable products, including Digital Product Passport provisions, Official Journal of the European Union: [https://eur-lex.europa.eu/eli/reg/2024/1781/oj](https://eur-lex.europa.eu/eli/reg/2024/1781/oj) * European Commission, Ecodesign for Sustainable Products Regulation: [https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation\_en](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/ecodesign-sustainable-products-regulation_en) * EUR-Lex, official portal for European Union law: [https://eur-lex.europa.eu](https://eur-lex.europa.eu) ## About This Article About This Article
Last Reviewed
2026-08-08
Next Scheduled Review
2027-08-08
Article Version
1.0
tieback Knowledge is a continuously maintained reference library covering Digital Product Passports, product traceability, product compliance and related regulations. Articles are reviewed regularly as legislation, standards and implementation guidance evolve. ## Related Docs * [What is Product Master Data?](/docs/knowledge-base/enterprise-systems-and-data-architecture/what-is-product-master-data) * [How Product Data Moves Through the Supply Chain](/docs/knowledge-base/standards-and-technology/how-product-data-moves-through-the-supply-chain) * [What Information Does a Digital Product Passport Contain?](/docs/knowledge-base/digital-product-passports/what-information-does-a-digital-product-passport-contain) * [How Should Organisations Prepare for Digital Product Passports?](/docs/knowledge-base/implementation/how-should-organisations-prepare-for-digital-product-passports)