DPP data quality: five checks before publication

Establish the applicable framework first

The ESPR requires accurate, complete and current DPP data. Applicable product rules determine the information and identification level required; Annex III is not a universal checklist of mandatory fields. Assess Swiss domestic law separately from requirements affecting EU exports. SECO’s June 2026 announcement describes a Swiss legislative proposal, rather than establishing a general existing DPP obligation. The checks below are an organisational suggestion. A registration identifier replaces neither the passport nor evidence of conformity. [1] [2] [4]

1. Does the data belong to the right product?

Start with one product family and a specific record. Check the model, variant, version and, where relevant, batch or individual item. Do these details agree across PLM, ERP and supplier documents? A valid identifier is insufficient if its supporting document describes a different configuration. Record the relationship and responsible role. Keep unresolved relationships visible instead of silently deciding them during an import. [1]

2. Can you trace the source and its validity?

For each selected value, record its source, document or data version, and responsible specialist. Check whether that source applies to this exact product version. A date alone does not establish that information is current. Define changes that trigger another review, such as a different material or an updated supplier specification. Treat missing evidence as an unresolved task; a plausible estimate is no substitute for confirmed information. [1] [3]

3. Do units and translations agree?

A number needs an unambiguous meaning: net mass and shipping weight are different. Review its unit, decimal separator, reference quantity and conversion rule together. Teams in German-speaking Switzerland, Romandy and Ticino should use the same definition even when labels differ. This also applies to English-speaking decision-makers in Swiss companies. Translate explanations, not product identifiers. An approved glossary and a reviewed sample record help reveal changes in meaning before data is distributed.

4. Who may read, edit and approve?

Separate read access, data maintenance and the internal decision to publish. The ESPR provides for controlled access and editing rights; design your approval procedure around the product and organisation. Use test roles to check that confidential supplier information does not become public accidentally. Document responsibilities and unresolved questions. Successfully saving or exporting a record does not mean that the responsible specialist has confirmed its contents. [1]

5. Can changes still be traced?

Record the value changed, the reason, supporting evidence and the role making the change. Define when affected data needs another review and publication. An export can succeed while an older version remains accessible. Compare the approved version with the content actually being delivered. Include operational responsibilities: who responds to incorrect data, and how are availability and recovery organised? A useful test follows a correction all the way to its published result. [1]

Fictional test case: an error by a factor of 1,000

For the entirely fictional “Housing A”, the relevant supplier document gives a mass of 1,200 g. After an incorrect import, the output field instead contains 1,200 kg. The team pauses publication, confirms the product version and source, then checks the conversion to 1.2 kg. Following documented specialist review, it approves the corrected version and checks the delivered output. This example illustrates a review process; it is neither a customer reference nor a statutory tolerance.

Start with a manageable set of data

Bring an anonymised system overview and a representative product data example to a discussion with VALNARO. Together, we can scope a limited review process covering the data model, interfaces and responsibilities. Deliverables and scope are agreed in advance. Begin with a few clearly defined attributes and test deliberately incorrect cases too. This makes the decisions your team still needs to take before publication visible.

Explore further

Sources and practical context