ECLASS IRDI Format: Structure, Segments, and Why It Matters

When a hydraulics supplier, a CPG vendor, and a furniture importer all send you a “volume” attribute, your PIM has no way to know those three columns mean the same thing — unless every attribute carries a stable, globally registered identifier. That is the problem the ECLASS IRDI format solves, and why distributors who skip it end up with a manual-exception queue that grows faster than their team can clear it. Claro reads IRDIs directly from supplier feeds, infers them when they are missing, and writes the resolved keys back into your PIM or ERP — so the join logic that keeps your catalog clean runs automatically, not by hand.

Definition

An ECLASS IRDI is a globally unique, machine-readable identifier that pins down exactly one ECLASS class, property, enumerated value, or unit of measure so that two systems can agree on what a product attribute means without relying on its human-readable label.

IRDI stands for International Registration Data Identifier, a structure defined by ISO/IEC 11179 and ISO 29002 for naming data elements unambiguously. ECLASS, the cross-industry classification and product-description standard, assigns an IRDI to every object in its dictionary: each class, each property (for example nominal voltage or thread size), each allowed value, and each unit. Because the identifier is registered globally, the same IRDI means the same thing in a German supplier’s PIM, a Dutch distributor’s ERP, and a North American marketplace catalog.

The eclass irdi format is a concatenation of fixed segments rather than a single opaque number. A typical IRDI begins with a registration authority identifier (an ICD code plus organization code that points to ECLASS as the issuing body), followed by an item code that identifies the specific dictionary entry, and a version identifier so that a property defined in one ECLASS release can be distinguished from a revised definition in a later one. You will often see IRDIs written with separators such as hyphens and a hash before the version block. The exact punctuation can vary by serialization (BMEcat, AutomationML, or Asset Administration Shell), but the underlying segments are stable.

Why the ECLASS IRDI format matters for product data

Labels lie; identifiers do not. The word “capacity” might mean litres in one furniture catalog and ampere-hours in another, and a column header named “width” could be a package dimension or a product dimension. When every property carries an IRDI, a matching or enrichment engine can join records on the identifier instead of guessing from free text — which is the difference between a clean automated merge and a queue of manual exceptions.

Consider a real MRO scenario. A distributor ingests feeds from a hydraulics manufacturer, a cleaning-supplies vendor, and a furniture importer. Each supplier ships a thread-size or volume attribute under a different local name and unit, but all three reference the same ECLASS property IRDI. A canonical product-data layer reads the IRDI, normalises the units, and folds the values into one golden record, so deduplication no longer trips over synonyms. The same identifiers feed downstream AI search: when a product knowledge graph is built on IRDIs, a generative engine answering a buyer’s question can cite a specific, verifiable property rather than paraphrasing an ambiguous spec sheet.

IRDIs also make change management auditable. Because the version segment is part of the identifier, you can detect when a supplier re-classifies a product against a newer ECLASS release and decide whether to re-map, rather than silently inheriting a shifted definition. That provenance is what lets a distributor trust automated classification at scale. It is the same principle behind data provenance at the attribute level.

Before and after: working with and without IRDIs

Claro ingests IRDI values directly from BMEcat and structured supplier feeds, infers the correct IRDI when a feed omits it, and writes the resolved identifier back into your PIM or ERP. The result is a canonical attribute layer that stays consistent as your supplier base scales — no hand-tuned mapping scripts, no synonym dictionaries to maintain.

Related

FAQ

What does IRDI stand for? +

IRDI stands for International Registration Data Identifier. It is a globally registered, version-aware identifier defined under ISO/IEC 11179 and ISO 29002 that names a data element so any system can interpret it the same way, regardless of the human-readable label attached to it.

How is an ECLASS IRDI different from the dotted ECLASS class code? +

The dotted code — for example 27-37-09-01 — marks a position in the ECLASS hierarchy and is convenient for people to read and navigate. The IRDI is the globally registered identifier that also encodes the issuing authority and a version segment, making it the reliable key for joining and matching data between systems across languages and releases.

Does every ECLASS property have its own IRDI? +

Yes. ECLASS assigns IRDIs not only to classes but also to individual properties, enumerated values, and units of measure. That granularity is what lets a data pipeline map a single attribute such as nominal voltage across dozens of supplier feeds without depending on each supplier’s local label.

Where do ECLASS IRDIs appear in real catalog files? +

You encounter them in catalog and data-exchange formats such as BMEcat, in AutomationML files, and in the Asset Administration Shell used for digital twins and Industry 4.0 applications. The separators can differ by serialization, but the registration-authority, item-code, and version segments remain consistent across all formats.

Why should distributors store the IRDI and not just the label? +

Labels and units vary by supplier and language, so matching on text produces false merges and a queue of manual exceptions. Storing the IRDI gives a stable, unambiguous key for deduplication, attribute enrichment, and AI search. Its version segment also lets you audit when a supplier shifts to a newer ECLASS release and decide whether to re-map, rather than silently inheriting a shifted definition.

How does Claro use ECLASS IRDIs to clean up supplier feeds? +

Claro reads the IRDI embedded in each incoming supplier feed — whether from a BMEcat file or a direct API — and uses it as the authoritative join key when merging attributes across sources. When a property arrives without an IRDI, Claro infers the correct one from the attribute name, unit, and classification context, then writes the resolved IRDI back into your PIM or ERP so downstream systems always have a consistent, version-stamped key.