What is Product Master Data?
Executive Summary
Most failed product data programmes fail for the same reason. The organisation treats the thing it publishes as the thing it knows, and discovers too late that it never had a single, agreed, governed answer to the question: what is this product?
Product master data is that answer. It is the durable, authoritative description of a product as a commercial and physical object: what it is called, what it is made of, what it weighs, how it is identified, which category it belongs to, which specifications it meets, and which organisation is responsible for it. It changes rarely, it is reused everywhere, and it is the reference every other system quotes.
It is not the same as the records of what the business did with the product. A purchase order, a sales invoice, a stock movement and a production run are transactional data: high volume, time-stamped, and meaningful only in the context of a specific business process. Nor is it the same as the record of what happened to a specific unit in the physical world. A pack, a shipment, a receipt and a repair are event data: observations of objects moving and changing state, often across organisational boundaries.
Confusing these three is the most common and the most expensive architectural mistake in product data. Transactions and events are both derived from, and dependent on, master data. Master data answers “what is it”. Transactional data answers “what did we do”. Event data answers “what happened to it”.
Digital Product Passports sit at the end of that chain, not the start. A passport is a governed presentation of trusted product information to an audience outside the organisation. It consumes master data, reference data and, where relevant, selected transactional and event data. It does not author them, and it must never become the place where a product attribute is first invented.
That single principle carries most of the practical guidance in this article: the passport is a consumer, the master record stays the system of record. Organisations that hold that line publish consistently across every channel and survive their first regulatory question. Organisations that break it end up maintaining a second, divergent product catalogue whose only purpose is compliance, and which nobody in the business trusts.
Distinguishes master, reference, transactional and event data, and shows which of them a passport consumes.
Table of Contents
- Definition
- Why Product Master Data Matters
- The Product Data Foundation Model
- Master Data vs Transactional Data
- Master Data vs Event Data
- Master Data and Digital Product Passports
- Who Owns Product Master Data
- What Good Product Master Data Looks Like
- Benefits
- Common Mistakes
- Frequently Asked Questions
- Key Takeaways
- Related Glossary Terms
- References
- About This Article
Definition
Product master data is the authoritative, governed set of attributes that describe a product as a persistent commercial and physical entity, independent of any single business transaction or physical event. It includes identification, naming, classification, composition, physical characteristics, specifications, responsible parties and lifecycle status, and it is intended to be created once, governed centrally and reused by every system and channel that needs to describe the product.
Three properties distinguish master data from everything else an organisation stores about a product.
It is durable. A product’s material composition, dimensions and identifier do not change every day. When they change, the change is deliberate, governed and usually versioned. Compare that with a stock level, which changes continuously and meaningfully.
It is shared. The same product record is quoted by procurement, manufacturing, quality, finance, logistics, e-commerce, marketing, customer service and regulatory affairs. It has no single owning process; it has an owning organisation. That is precisely why it needs governance rather than local convenience.
It is referential. Transactions and events point at master data. A sales order line refers to a product; it does not restate the product’s material composition. The moment a transaction starts carrying its own copy of a master attribute, the organisation has created a divergence it will spend years reconciling.
Master data is what the product is. Everything else your systems record is what you did with it or what happened to it.
What Typically Sits in a Product Master Record
The exact shape varies by industry, but the categories are consistent:
- Identity: internal product code, GTIN or other product identifier, and the identity level the record describes (model, variant, batch or item).
- Naming and description: commercial name, technical description, and translations.
- Classification: internal category, industry classification, customs and tariff codes.
- Composition: bill of materials, substances, material percentages, recycled content.
- Physical characteristics: dimensions, weight, packaging configuration, hazard attributes.
- Specifications and conformity: standards met, test methods, certificates and their validity.
- Responsibility: manufacturer, brand owner, importer, and the relevant economic operator for a given market.
- Lifecycle status: in development, active, restricted, discontinued, withdrawn.
Why Product Master Data Matters
The business case for master data is usually written in the language of efficiency. That undersells it. The real case is that almost every serious product obligation resolves, eventually, to a master data question.
Consider a small set of ordinary questions an organisation must be able to answer:
- Which of our products contain this substance, and in what quantity?
- Which products are affected if this component supplier is suspended?
- Which markets is this variant approved to be sold in, and under whose responsibility?
- What is the recycled content we publicly claim, and where is the evidence?
- Which products must be withdrawn if this certificate expires next month?
None of these can be answered from a transaction log. All of them require a complete, current, trusted description of the product portfolio. Where that description is fragmented across spreadsheets, an ERP, a PLM system, a handful of regional catalogues and a marketing content system, the answer takes weeks and is contested when it arrives.
Regulation is raising the cost of that fragmentation. As ESPR delegated acts define disclosure requirements per product group, and as market surveillance authorities gain the ability to query published product information directly, the gap between what an organisation believes about its products and what it can demonstrate becomes a compliance exposure rather than an internal inconvenience.
A manufacturer publishes a product weight of 2.4 kg on its website, sourced from a marketing content system, while its engineering record says 2.62 kg after a design revision. Both numbers are internally defensible and neither is malicious. When a regulator compares the published passport with the technical file, the discrepancy is not read as a data quality issue. It is read as an unreliable declaration, and every other claim on the page inherits that doubt.
The Product Data Foundation Model
Organisations rarely disagree about whether data quality matters. They disagree about where a particular attribute belongs, and that disagreement is what produces duplicated, divergent product information.
The Product Data Foundation Model resolves that by ordering product information into six layers, each of which depends on the layers above it. It is deliberately architectural rather than technological: it says nothing about which systems you own, only about what kind of data you are looking at and what it is allowed to depend on.
The structural claim of the model is simple and consequential. Data may depend downward, never upward. Transactional data may reference master data; master data must never be derived from a transaction. A passport may consume any layer above it; no layer above it may depend on the passport. When an organisation violates that direction of dependency, it has not built an integration, it has built a second source of truth.
The thing itself: designed, made, packaged, sold, used and eventually recovered. Every data layer below is an attempt to describe this accurately.
The governed description of the product: identity, naming, classification, composition, physical characteristics, specifications, responsible parties and lifecycle status. Created once, versioned deliberately, reused everywhere.
The controlled lists master data points at: units of measure, country codes, currencies, material and substance taxonomies, classification schemes, standards registers. Small, slow moving, and shared far beyond one organisation.
Purchase orders, production orders, invoices, stock movements, returns. High volume, time-stamped, process-bound, and always quoting a master record rather than restating it.
Observations of identified objects in the physical world: packed, shipped, received, sold, repaired, recovered. Frequently shared across organisations using EPCIS, and meaningless without the identity supplied by master data.
A curated, audience-aware view of trusted product information, published under a
persistent identifier and reachable from a data carrier
Dependency runs one way only. Digital Product Passports consume trusted product information. They do not replace Product Master Data.
Reading the Model
Two readings are useful.
Read downwards, the model is a supply chain for information. The product exists; master data describes it; reference data gives that description a shared vocabulary; transactions record commercial activity against it; events record physical activity against it; the passport publishes a selected, trustworthy subset.
Read upwards, the model is a diagnostic. Take any attribute currently shown on a published passport and ask which layer authored it. If the answer is “the passport”, you have found a governance defect, and it will show up later as an inconsistency between the passport, the technical file and the commercial catalogue.
Master Data vs Transactional Data
The distinction is easiest to see in the behaviour of the data rather than its content.
The practical rule follows from the last row. A transaction references master data. If a sales order line contains a hard copy of the product’s material composition, that copy is frozen at the moment of the transaction and will silently diverge from the master record forever after.
There is one legitimate exception, and it is important. Where a transaction must record the state of the product as it was at that moment for legal or audit reasons, snapshotting is correct. An invoice should preserve the price and description as agreed. That is a deliberate, dated snapshot with a clear reason, not a shortcut. The test is whether the copy is presented as history or presented as current truth.
When master data is poor, teams often reconstruct a product list from transaction history, because the transactions are complete and the master file is not. The result looks authoritative and is not: it contains only products that were traded, inherits every data entry error ever made, has no view of products in development, and cannot represent an attribute nobody ever needed to sell.
Master Data vs Event Data
Event data is closer to master data in one respect, in that both concern the product rather than the paperwork. It differs in every other respect.
The dependency is one directional and absolute. An event says something happened to an identified object. If the identifier does not resolve to a governed master record, the event is a timestamped string with no meaning. This is why organisations that invest in traceability before investing in master data usually stall: they can capture events perfectly and still cannot say what the events are about.
A garment: master data says it is style 4482, 60 percent organic cotton, 320 grams, GTIN 05012345678900, manufactured under a named brand owner, active in the EU. Transactional data says 400 units were purchased on a specific order at a specific price and 12 were returned. Event data says serial 0001 was packed in Portugal on 3 March, shipped on 4 March, received in Rotterdam on 7 March and sold in Berlin on 22 April. Remove the master record and the other two become unreadable.
Master Data and Digital Product Passports
A Digital Product Passport is a publication. That framing settles most of the design questions.
A passport takes information that already exists and is already governed, selects the subset that a given audience is entitled to and required to see, renders it in an accessible and machine readable form, binds it to a persistent identifier, and makes it reachable from the physical product through a data carrier and a resolver. Every one of those verbs is a verb about presentation.
What a passport should not do is author product facts. The moment a compliance team types a recycled content percentage directly into a passport authoring screen because the master system does not yet have a field for it, three things become true simultaneously: the organisation has a public claim with no internal source, the technical file and the passport can now disagree, and the fix has been deferred to whoever handles the first challenge.
The Practical Consequences
Snapshot at publication, source from the master record. Passports are usually immutable snapshots for good reason: a consumer or authority scanning a code must see what was published for that product at that time. That snapshot should be produced from master data at the moment of publication, and re-published deliberately when master data changes. Immutability of the published artefact is not a licence to edit the artefact instead of the source.
Publish a subset, deliberately. Master data contains commercially sensitive material: costs, supplier identities, formulations. Passport design is largely an exercise in deciding which attributes each audience receives. That decision is far easier when the underlying record is complete and classified, and nearly impossible when it is fragmented.
Model identity before publishing. A passport is published against a specific level of identity: a model, a batch, or an individual item. Master data must be able to express that level, because a batch-level claim published against a model identifier is not a small inaccuracy, it is an unverifiable statement.
Expect the audit question. The useful test of any published attribute is whether you can name, within one minute, the system that holds it, the person accountable for it and the evidence behind it. If the honest answer is “the passport”, the architecture has inverted.
Give every attribute that appears on a passport a named owning system and a named data owner before it is published. Where a required attribute has no home, extend the master model rather than capturing it in the publication layer. A passport programme that improves master data is a strategic investment; one that bypasses master data is technical debt with a public URL.
Who Owns Product Master Data
Ownership is where most master data initiatives quietly fail, because ownership is confused with custody.
Custody is the system that stores the record: PLM for engineering definition, ERP for commercial and logistics attributes, a dedicated MDM platform for consolidation, a QMS for conformity evidence, a PIM for enriched commercial content. Custody is an implementation decision and organisations legitimately differ.
Ownership is the named person or function accountable for the correctness of an attribute. That cannot be delegated to a system, and it cannot be assigned to IT. The owner of material composition is an engineering or product function. The owner of market approval status is regulatory affairs. The owner of the commercial description is the product or brand function.
A workable model has four roles: a data owner accountable for the attribute, a data steward who maintains it day to day, a governance forum that arbitrates when definitions conflict across functions, and consumers who agree to reference rather than replicate. When the passport programme arrives, it joins as a consumer, not as a new owner.
What Good Product Master Data Looks Like
Rather than an abstract maturity scale, six observable properties:
- Complete. Every attribute required by the markets you sell in is populated for every active product, with a deliberate, recorded reason where it is not applicable.
- Unique. One product, one master record. Duplicates created by regional systems or acquisitions are identified and merged, not tolerated.
- Accurate. Values match physical and documentary reality, and are verified against the technical file rather than assumed.
- Consistent. The same attribute means the same thing across functions, expressed in the same units, drawn from the same reference lists.
- Governed. Every attribute has an owner, a definition, a validation rule and an audit trail of who changed what, when and why.
- Current. Changes flow from source to master record in a known, monitored timeframe, and downstream consumers, including passports, are re-published when material attributes change.
Pick five products at random and five attributes you publish. For each of the twenty-five combinations, ask which system holds the value, who owns it and when it was last verified. The proportion you can answer without investigation is a fairer measure of readiness than any maturity assessment.
Benefits
Regulatory defensibility. Published claims trace to an owned, evidenced source, so a challenge is answered by retrieval rather than by investigation.
Faster product launches. New markets and channels consume an existing record instead of triggering a fresh data collection exercise per launch.
Lower cost of change. A corrected attribute is fixed once and propagates, rather than being chased across catalogues, datasheets, marketplaces and packaging artwork.
Credible sustainability reporting. Material, substance and recycled content figures aggregate reliably because they are recorded once against a governed structure.
Faster and narrower recalls. When composition and supplier attributes are complete and joined to event data, the affected population is identified precisely instead of conservatively.
Interoperability. Partners, marketplaces and authorities receive consistent product information, which reduces onboarding friction and rejected data submissions.
Passport readiness. Publication becomes a configuration task instead of a data archaeology project, which is the single largest determinant of how long a passport programme takes.
Common Mistakes
Building the missing attributes into the publication layer because it is the fastest route to a visible deliverable. It works until the first inconsistency, after which the organisation is maintaining two product catalogues and trusts neither.
Certificates, datasheets and test reports are evidence. They are not structured master data. An attribute that exists only inside a PDF cannot be validated, compared, aggregated or published reliably.
IT owns systems, not the meaning of attributes. When accountability for material composition sits with a platform team, definitional conflicts between functions are never resolved, only configured around.
A one-off cleanse with no change to how data is created returns to its prior state within a reporting cycle. Quality is a property of the intake process, not of the most recent remediation.
Master models built around current commercial need cannot express batch-level identity, substance detail or end-of-life information. These become the exact attributes future regulation asks for.
Denormalising composition or classification onto orders and shipments for convenience creates frozen values that diverge silently. Reference the master record; snapshot only where a legal record of the moment is genuinely required.
Frequently Asked Questions
Is product master data the same as a PIM system?
No. A PIM is one possible custodian, usually focused on enriched commercial and marketing content
for sales channels. Product master data is a category of data, not a category of software, and it
typically spans PLM, ERP, QMS and MDM as well.
Does a Digital Product Passport replace product master data?
No, and this is the central point of the article. A passport is a governed presentation of trusted
product information to an external audience. Master data remains the system of record; the passport
consumes it.
Can we start a passport programme before master data is in order?
Yes, for a narrow pilot, provided you are honest that the pilot’s purpose is to discover data gaps
rather than to demonstrate readiness. What you must not do is close those gaps inside the
publication layer.
Where does reference data stop and master data start?
Reference data is the shared, controlled vocabulary that many organisations use identically: units,
country codes, material taxonomies, classification schemes. Master data is your specific product’s
description expressed using that vocabulary.
Is a bill of materials master data?
Generally yes: it is a durable, governed structural description of the product. Its execution in a
particular production run is transactional, and the movements of the components are events.
How does event data relate to the technical file?
The technical file evidences that the product as designed conforms. Event data evidences what
happened to specific units. Both reference master data; neither substitutes for it.
Who should own product master data in practice?
Ownership belongs with the functions accountable for the meaning of each attribute, coordinated by a
governance forum, with IT accountable for the platforms rather than the content.
What is the smallest useful first step?
Produce a single attribute inventory for the products you must publish first: attribute, definition,
owning system, data owner, current completeness. It is unglamorous and it consistently reframes the
programme.
Key Takeaways
Related Articles
- ERP vs PIM vs PLM: What’s the Difference?
- How Enterprise Systems Support Digital Product Passports
- What is a Golden Record?
- What is Master Data Management (MDM)?
- What is Product Data Governance?
- Building an Enterprise Digital Product Passport Architecture
- How Should Organisations Prepare for Digital Product Passports?
- What Data Goes in a Digital Product Passport, and Where Does It Come From?
Related Glossary Terms
Definitions of record for the terms used above live in the glossary.
- Product Data
- Product Identifier
- Product Lifecycle
- Product Traceability
- Digital Product Passport
- Data Carrier
- GS1
- Economic Operator
- Conformity Assessment
- Market Surveillance
- Sustainability Data
- Circular Economy
- ESPR
- Delegated Act
References
- International Organization for Standardization, ISO 8000 series on data quality, including master data exchange: https://www.iso.org/standard/81745.html
- International Organization for Standardization, ISO/IEC 11179 on metadata registries: https://www.iso.org/standard/78914.html
- International Organization for Standardization: https://www.iso.org
- GS1 identification keys, including the GTIN: https://www.gs1.org/standards/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
- GS1, the global standards organisation: 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
- Regulation (EU) 2023/1542 concerning batteries and waste batteries, Official Journal of the European Union: https://eur-lex.europa.eu/eli/reg/2023/1542/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
- EUR-Lex, official portal for European Union law: https://eur-lex.europa.eu
About This Article
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.