Table of Contents
- What Does Excel Have to Do With Digital Product Passport Readiness?
- Why Is Excel a Problem for Product and Material Data?
- What Is the Difference Between Data Formatting and Data Structure?
- Why Does XML Matter for Machine-Readable Product Data?
- Does Converting Excel to XML Make Data DPP Ready?
- What Data Needs to Be Structured Before XML Conversion?
- How Should FMD Data Be Prepared Before XML Conversion?
- 1. Identify the product
- 2. Establish the BOM
- 3. Map component information
- 4. Connect material information
- 5. Connect substance information
- 6. Attach evidence
- 7. Validate the data
- 8. Structure the output
- How Do You Validate Data Before Converting It?
- How Does BOM Structure Fit Into the Process?
- What Happens When Supplier Data Comes in Different Formats?
- Can Existing FMD Data Be Reused for DPP?
- What Does an Excel-to-XML Workflow Look Like?
- Stage 1: Collect
- Stage 2: Normalise
- Stage 3: Map
- Stage 4: Validate
- Stage 5: Evidence
- Stage 6: Structure
- Stage 7: Transform
- Stage 8: Maintain
- What Should an Excel-to-XML Readiness Checklist Include?
- Product structure
- Material data
- Supplier data
- Evidence
- Data quality
- Structured data
- Lifecycle management
- How Can Manufacturers Avoid Building Another Data Silo?
- How Does FMD Support the DPP Data Foundation?
- How Can Regilient Support FMD and DPP Data Readiness?
- From Spreadsheet Data to Structured Product Intelligence
- Recommended next step
Digital Product Passport (DPP) requirements are moving product information toward structured, interoperable digital data. For manufacturers, that creates a practical problem long before a DPP is published: much of the product and material information needed to build it may still live in Excel files, spreadsheets, supplier documents and disconnected systems.
The European Commission describes the DPP as a digital container for information about products, components and materials. The information required depends on the applicable product legislation, and economic operators are responsible for compiling the required data digitally and maintaining its accuracy throughout the product lifecycle. Internal Market SME
That makes the journey from supplier data → FMD → structured product data → DPP an important part of DPP readiness.
Converting an Excel file to XML can be part of that journey. But XML conversion by itself does not make product data DPP-ready.
The real challenge is making sure the data is complete, structured, validated, connected to the right product and component relationships, and capable of being maintained over time.
What Does Excel Have to Do With Digital Product Passport Readiness?
For many electronics manufacturers, product information has accumulated across spreadsheets for years.
A typical product may have:
- Product and part numbers in an ERP system
- BOM information in PLM
- Material declarations from suppliers
- RoHS and REACH declarations in compliance systems
- FMD information in spreadsheets
- Test reports in PDF files
- Supplier information in email
- Sustainability information in separate databases
The problem is not necessarily that Excel is incapable of storing useful information.
The problem is that spreadsheet data is often structured for people rather than for connected, machine-readable data exchange.
DPP implementation requires product information to follow the data structure and obligations defined by the applicable legislation. The European Commission also identifies interoperability, data exchange, data formats and machine-readable information as important parts of the DPP framework. Internal Market SME
So the question is not simply:
"How do we convert Excel to XML?"
It is:
"How do we turn the product and material data in Excel into reliable structured data that can support the applicable DPP requirements?"
Why Is Excel a Problem for Product and Material Data?
Excel can be useful for collecting and reviewing data, but problems appear when it becomes the primary system for managing product information.
Common issues include:
☐ Different suppliers use different column names
☐ Material descriptions are inconsistent
☐ Part numbers do not match across files
☐ Units are entered differently
☐ Required fields are left blank
☐ Material and substance relationships are unclear
☐ Supplier data is stored separately from the BOM
☐ Supporting evidence is stored somewhere else
☐ Older declarations remain mixed with current information
☐ Changes to components are not reflected everywhere
☐ The same product information is manually copied into multiple files
These problems become more significant when information needs to move between systems.
A spreadsheet may tell a compliance professional that a component contains a particular material. A structured data model needs to represent what that component is, which product it belongs to, what material is associated with it, what information is known about that material, and where the supporting evidence comes from.
That relationship is more important than the file extension.
What Is the Difference Between Data Formatting and Data Structure?
This distinction is critical.
Formatting describes how information is represented.
Structure describes how information relates to other information.
For example, an Excel file might contain:
Product | Component | Material | Substance | Weight |
|---|---|---|---|---|
Product A | Component 001 | Aluminum | Substance X | 250 g |
Converting that row into XML does not automatically establish whether:
- Product A is the correct product identifier
- Component 001 is part of the current BOM
- Aluminum is the correct material classification
- Substance X is correctly identified
- 250 g refers to the component, material or substance
- the information came from an approved supplier declaration
- the declaration is still current
The XML can be technically valid while the underlying information is still wrong or incomplete.
This is why data quality and data modelling need to come before file conversion.
Why Does XML Matter for Machine-Readable Product Data?
XML is a structured format that can represent relationships between data elements.
Instead of treating product information as cells in a spreadsheet, structured data can represent relationships such as:
Product → Component → Material → Substance
That is useful when information needs to move between systems or be processed automatically.
The DPP framework is being developed around interoperability, structured information, machine-readable data, data exchange and related technical standards. The European Commission's DPP work now includes standards covering areas such as identifiers, interoperability, data carriers, APIs, data exchange protocols and data storage. Internal Market SME
However, XML should not be treated as a universal DPP format.
The exact technical requirements depend on the applicable product legislation, delegated acts and technical specifications.
XML is a way of structuring and exchanging data. It is not, by itself, a declaration of DPP compliance.
Does Converting Excel to XML Make Data DPP Ready?
No.
This is one of the most important distinctions manufacturers should make.
A simple conversion could look like:
Excel → XML
A more useful DPP readiness workflow looks like:
Supplier data → FMD → Validation → Product structure → BOM relationships → Evidence → Structured data → Applicable DPP requirements
The difference is significant.
A file can be converted into XML while still containing:
- Missing information
- Duplicate records
- Incorrect units
- Outdated supplier declarations
- Inconsistent component identifiers
- Unvalidated material information
- Missing evidence
- Incorrect product relationships
The European Commission states that economic operators must provide product data digitally according to the data structure and obligations defined by the relevant legislation. They are also responsible for maintaining the accuracy of DPP information throughout the product lifecycle. Internal Market SME
So conversion is a technical step inside a larger data-readiness process.
What Data Needs to Be Structured Before XML Conversion?
Before converting product information, manufacturers need to understand what the data actually represents.
For FMD-driven product information, the underlying relationships may include:
Product
↓
BOM / Assembly
↓
Component
↓
Material
↓
Substance
↓
Supporting evidence
Depending on the applicable requirement, additional information may be associated with the product, component or material.
The important point is that the manufacturer should know what each data field means and how it relates to the rest of the product.
For example:
Data area | Question to resolve |
|---|---|
Product | Which product does this information belong to? |
Component | Which component or part is involved? |
Material | What material is associated with the component? |
Substance | What substances are present or relevant? |
Quantity | What does the reported quantity represent? |
Supplier | Who provided the information? |
Evidence | What document or declaration supports it? |
Date | When was the information provided or validated? |
Status | Is the information current and accepted? |
Relationship | Where does this component sit in the product structure? |
This creates a foundation that can be transformed into machine-readable data more reliably.
How Should FMD Data Be Prepared Before XML Conversion?
Full Material Disclosure can provide a useful product and material data foundation because it can connect information about components, materials and substances.
But FMD data should not simply be exported without validation.
A practical preparation process is:
1. Identify the product
Establish the product identifier and the product version or relevant product structure.
2. Establish the BOM
Connect the product to its current components and assemblies.
3. Map component information
Make sure component numbers, descriptions and supplier information are consistent.
4. Connect material information
Associate each relevant component with its material information.
5. Connect substance information
Where required, identify relevant substances and their relationships to materials.
6. Attach evidence
Connect declarations, reports or other supporting information to the relevant records.
7. Validate the data
Check completeness, consistency, units, identifiers, dates and relationships.
8. Structure the output
Only after the underlying information is reliable should manufacturers transform it into the required structured format.
This is where FMD becomes more than a compliance record.
It can become part of the product-data foundation needed for downstream digital workflows.
For a broader explanation of FMD and how material, component and substance information fits together, see the Full Material Disclosure guide.
How Do You Validate Data Before Converting It?
Validation should happen before conversion, not after.
A useful validation checklist includes:
☐ Product identifiers are consistent
☐ Current BOM information is being used
☐ Component numbers match the source system
☐ Supplier information is associated with the correct component
☐ Material information is complete
☐ Substance information is correctly associated
☐ Units are consistent
☐ Required fields are populated
☐ Supporting evidence is available
☐ Declaration dates are recorded
☐ Outdated information is identified
☐ Duplicate records are removed
☐ Data relationships are preserved
☐ Exceptions are documented
The goal is not merely to create an XML file that passes a technical parser.
The goal is to create structured product information that can be trusted.
How Does BOM Structure Fit Into the Process?
The BOM is the bridge between the product and the underlying material information.
Without that connection, manufacturers can end up with a collection of material records without a reliable understanding of where those materials exist in the product.
Consider:
Product A
→ Assembly 01
→ Component 001
→ Material X
→ Substance Y
That relationship is much more useful than simply storing:
Material X | Substance Y
The first structure provides product context.
This becomes particularly important when a manufacturer needs to determine which products are affected by a material change, supplier update or regulatory requirement.
It also supports the broader product-data chain:
Supplier → Material → Component → BOM → Product → DPP
That chain is central to turning supplier information into usable product intelligence.
What Happens When Supplier Data Comes in Different Formats?
Supplier data rarely arrives in one consistent format.
One supplier may provide:
- Excel
- CSV
- XML
- IPC declaration
- Laboratory report
- Technical drawing
- PDF declaration
- Structured portal submission
Another supplier may provide completely different information.
Trying to force every supplier into the same file format at the beginning can create unnecessary friction.
A better approach is to establish a common internal data model.
The supplier's original format can then be mapped into that model.
For example:
Supplier Excel
↓
Supplier XML
↓
IPC declaration
↓
PDF evidence
↓
Structured internal FMD record
Once the information has been normalised and validated, the manufacturer can use it for downstream compliance and product-data workflows.
This is also why supplier data collection should be treated as part of the FMD process rather than as a separate administrative activity.
See how to get FMD data without constantly chasing suppliers for a practical supplier data-collection workflow.
Can Existing FMD Data Be Reused for DPP?
Potentially, yes.
But reuse depends on the quality, scope and structure of the underlying data and the requirements applicable to the product.
The European Commission makes clear that the exact information required in a DPP depends on the relevant product legislation. Internal Market SME
That means manufacturers should avoid assuming that every FMD field will automatically become a DPP field.
Instead, think about FMD as one potential source of product and material information.
For example:
FMD
→ Material composition
→ Component information
→ Substance information
→ Supplier evidence
→ Product relationships
These records can potentially support downstream requirements where the applicable DPP rules call for relevant product, material or substance information.
The benefit is reuse.
Instead of collecting the same underlying information repeatedly for different compliance and sustainability processes, manufacturers can build a controlled product-data foundation and reuse appropriate information where requirements overlap.
What Does an Excel-to-XML Workflow Look Like?
A practical workflow can be structured into eight stages.
Stage 1: Collect
Bring together product, BOM, component, supplier and material information.
Stage 2: Normalise
Standardise identifiers, units, naming conventions and data fields.
Stage 3: Map
Connect suppliers, components, materials and substances to the correct product structure.
Stage 4: Validate
Identify missing, inconsistent, duplicate or outdated information.
Stage 5: Evidence
Connect declarations, reports and other supporting records to the relevant data.
Stage 6: Structure
Map validated information into the required data model.
Stage 7: Transform
Generate the required machine-readable representation, such as XML where applicable.
Stage 8: Maintain
Update the underlying information when products, suppliers, components, materials or requirements change.
The last stage is easy to overlook.
DPP readiness is not a one-time export exercise. The European Commission specifically places responsibility on economic operators to maintain the accuracy of DPP information throughout the product lifecycle. Internal Market SME
What Should an Excel-to-XML Readiness Checklist Include?
Before attempting to convert product data into structured output, ask:
Product structure
☐ Do we have a current product structure?
☐ Can every relevant component be connected to the correct product?
☐ Are product and component identifiers consistent?
Material data
☐ Do we know which materials are associated with each relevant component?
☐ Is the material information complete?
☐ Are material and substance relationships clear?
Supplier data
☐ Do we know which supplier provided each record?
☐ Can we identify missing supplier information?
☐ Are supplier submissions validated?
Evidence
☐ Can each important claim be traced back to supporting evidence?
☐ Are declaration dates recorded?
☐ Can outdated evidence be identified?
Data quality
☐ Are units standardised?
☐ Are duplicate records identified?
☐ Are mandatory fields complete?
☐ Are inconsistent values flagged?
Structured data
☐ Is there a defined data model?
☐ Are relationships between records preserved?
☐ Can the data be exchanged between systems?
☐ Does the output match the applicable technical requirements?
Lifecycle management
☐ Can the data be updated when the product changes?
☐ Can supplier changes be reflected?
☐ Can affected products be identified when material information changes?
This checklist helps separate data readiness from simple file conversion.
How Can Manufacturers Avoid Building Another Data Silo?
The worst outcome would be to create a new DPP spreadsheet or XML repository that becomes disconnected from the rest of the compliance process.
A better architecture connects DPP readiness to the product data manufacturers already need for compliance.
For example:
Supplier data
→ FMD
→ BOM
→ Product compliance
→ Sustainability data
→ DPP data
The same underlying product information can then support multiple workflows where the applicable requirements overlap.
This is particularly important as manufacturers manage multiple regulatory requirements at the same time.
The goal should not be to create a separate database for every regulation.
The goal should be to create a reusable, controlled product-data foundation.
How Does FMD Support the DPP Data Foundation?
FMD does not replace the DPP.
Instead, it can provide a useful source of product and material information that may support DPP preparation.
The relationship can be thought of as:
Supplier disclosures
↓
Full Material Disclosure
↓
Validated material and substance data
↓
Product and BOM relationships
↓
Structured product information
↓
Applicable DPP data
↓
DPP registration and lifecycle management
The exact DPP data requirements remain product-specific and depend on the applicable legislation and delegated acts. Internal Market SME
That distinction matters because manufacturers should prepare their data architecture now without assuming that today's spreadsheet structure or a generic XML schema represents the final requirement for every product.
How Can Regilient Support FMD and DPP Data Readiness?
Regilient can help manufacturers build the product and material data foundation behind these workflows.
The focus is not simply on converting one file into another.
It is on managing the underlying information across the lifecycle:
Collect → Validate → Connect → Assess → Document → Monitor → Update → Reuse
This can include supplier data collection, FMD management, BOM-level product intelligence, compliance assessment, supporting evidence and structured product information.
For manufacturers preparing for DPP requirements, that creates an opportunity to address the underlying data problem before the final DPP output is required.
The European Commission's DPP implementation work is already moving toward interoperable data exchange, machine-readable information and technical infrastructure for DPP registration and lifecycle management. Internal Market SME
The practical question is therefore not just whether a manufacturer can generate XML.
It is whether the manufacturer can trust the product data being put into that XML.
From Spreadsheet Data to Structured Product Intelligence
Excel to XML is not the real transformation.
The real transformation is:
Unstructured supplier information → validated FMD → connected product data → structured information → reusable DPP data
For electronics manufacturers, that means DPP preparation should start with the quality and structure of the product data already being collected.
If material information is incomplete, disconnected from the BOM or difficult to trace back to suppliers, converting it into XML will not solve the underlying problem.
Build the data foundation first. Then build the digital passport on top of it.
Recommended next step
Start by mapping your existing supplier, FMD, BOM and product information into one connected data structure. From there, identify which information can support current compliance workflows and which fields may be required for applicable DPP requirements.
Internal content path:
FMD foundation → supplier data collection → structured product data → DPP readiness.
The broader Full Material Disclosure guide explains the FMD foundation, while the DPP FMD compliance guide focuses specifically on preparing FMD data for Digital Product Passport requirements.