Validate ECLASS in BMEcat: A Step-by-Step Playbook

Step-by-step playbook to validate ECLASS in BMEcat: check IRDIs, class codes, units, and feature values before a catalog upload is rejected.

Catalog uploads that fail ECLASS validation cost distributor data teams hours of triage per export cycle. The rejection is rarely a missing field — it is a class code retired two releases ago, an IRDI that belongs to the wrong class, or a unit string the receiver never recognizes. By the time the bounce-back arrives, the shipment date may already be at risk.

This playbook walks you through how to validate ECLASS in BMEcat before a file leaves your systems, so rejections happen in your sandbox instead of at the customer’s import queue. Claro applies these same validation checks as a governed, automated step — resolving product identity, confirming every classification reference against the live ECLASS dictionary, and writing clean records back into your PIM or ERP so the same defect does not return on the next supplier refresh.

Before and after: messy vs. trusted

Without ECLASS validation	With ECLASS validation
Retired class codes pass schema checks silently	Every class code confirmed against the declared release
Features matched by display name, wrong IRDIs go undetected	Each feature validated by IRDI, not label
Free-text unit strings import but read as garbage downstream	Units mapped to the coded value the feature requires
Mandatory features missing on technically valid files	Coverage check catches empty required attributes
Same mapping errors resurface after every supplier refresh	Canonical mapping layer prevents drift across releases

Steps to validate ECLASS in BMEcat

1

Confirm the BMEcat and ECLASS versions match the receiver

Open the file header and read the BMEcat version (commonly 1.2 or 2005) and the declared CLASSIFICATION_SYSTEM name and version. A furniture supplier sending ECLASS 12.0 to a customer still on 11.1 will pass schema checks but fail class lookups. Record the exact target release before you validate anything else.
2

Verify the XML is well-formed and schema-valid

Before semantics, check syntax. Parse the file against the BMEcat DTD or schema to catch unclosed tags, wrong encoding, or misplaced ARTICLE_FEATURES blocks. A quick pass through the BMEcat Viewer surfaces structural breaks that an MRO feed often picks up during ERP export.
3

Resolve every class reference (ACLASS) against the dictionary

Each article points at an ECLASS class via its classification group code. Confirm that code exists in the declared release and is a leaf class, not an intermediate node. Industrial distributors frequently inherit feeds where fasteners are pinned to a deprecated class that was split across two codes in a later version.
4

Validate feature IRDIs, not just feature names

ECLASS features are identified by IRDIs, not labels. A feature named Width means nothing if its IRDI does not match the property defined for that class. Check that every FEATURE references a valid IRDI that belongs to the article’s class. See What Is an ECLASS IRDI? for the exact identifier structure to expect.
5

Check value lists, units, and data types per feature

For enumerated features, confirm each value maps to a permitted value IRDI from the dictionary. For numeric features, confirm the unit code is the one ECLASS expects, not a free-text string. A CPG catalog that ships net weight in lb where the feature expects a UNECE-coded kg value will import but read as garbage downstream. See UNECE Rec 20 Unit Codes for the coding reference.
6

Spot-check coverage and required features

Validity is not completeness. Pull a sample across classes and confirm the must-have features for each class are present and populated, not just structurally valid. Empty mandatory features are the quiet reason a technically valid file still gets rejected by a strict receiver.
7

Run the full file and triage by error class

Validate the entire export with the ECLASS BMEcat Validator, then group failures: bad class codes, unknown IRDIs, unit mismatches, missing values. Fix at the source mapping, not row by row, so the same defect does not return on the next export.

Common pitfalls

Other traps that catch distributor teams repeatedly:

Pitfall	Why it slips through	Fix
Version mismatch	Schema validates, class lookups silently fail	Pin both BMEcat and ECLASS release before validating
Feature matched by name	Labels look right to humans	Validate the IRDI, never the display name
Free-text units	Importers accept any string	Map units to the coded value the feature expects
Deprecated leaf classes	Old code still parses	Re-map against the current release leaf classes
Empty mandatory features	File is structurally valid	Run a coverage check, not just a schema check

If errors keep reappearing after every supplier refresh, the problem is mapping drift rather than a one-time data fix. Claro maintains a canonical product-data layer that governs classification and enrichment as a continuous process — resolving identity, validating each update against the live ECLASS dictionary, and writing trusted records back into your existing PIM or ERP. See Classification Drift and How to Catch It for a deeper look at why valid files degrade over time.

Tool

ECLASS BMEcat Validator

Upload a BMEcat file and check class codes, IRDIs, units, and values against the ECLASS dictionary.

Tool

BMEcat Viewer

Inspect article structure and feature blocks before running semantic validation.

Glossary

What Is an ECLASS IRDI?

Understand the identifier format that makes feature validation reliable.

Glossary

What Is ETIM in BMEcat?

How the other major classification standard rides inside the same file format.

Playbook

ETIM Classification Workflow

The companion workflow for distributors classifying against ETIM.

Guide

Classification Drift and How to Catch It

Why valid files degrade over time and how to monitor for it.

FAQ

What does it mean to validate ECLASS in BMEcat?

It means confirming that every classification reference in a BMEcat file resolves to a real ECLASS class for the declared release, that each feature uses a valid IRDI belonging to that class, and that units and enumerated values match the dictionary. It goes beyond checking that the XML is well-formed.

Why does my BMEcat file pass schema validation but still get rejected?

Schema validation only checks structure. A receiver also checks semantics: whether the class code exists, whether mandatory features are populated, and whether units are coded correctly. A structurally perfect file with a retired class code or an empty required feature will still fail at import.

Do I validate features by name or by IRDI?

By IRDI. Feature names are display labels and can repeat across unrelated classes, so a name like ‘Length’ proves nothing. The IRDI uniquely identifies the property defined for a specific class, which is why it is the only reliable thing to validate against.

What happens when ECLASS releases a new version?

Classes can be split, merged, or retired, and feature IRDIs can change. A file mapped to an older release may still parse but point at classes that no longer exist as valid leaf nodes. Re-validate against the target release whenever you or your customer upgrade.

Can the same BMEcat file carry both ECLASS and ETIM?

Yes. BMEcat can hold multiple classification systems, and many distributor catalogs ship both. Validate each system independently against its own dictionary, since a valid ECLASS block tells you nothing about whether the ETIM block is correct.

How does Claro help prevent recurring ECLASS validation failures?

Claro maintains a canonical product-data layer that resolves product identity, validates classification against the current ECLASS release, and writes clean records back into your PIM or ERP. Because enrichment and classification are governed steps rather than manual cleanup, the same mapping errors do not resurface on the next supplier refresh or version upgrade.