eCl@ss

eCl@ss is two things bolted together: a taxonomy and a property dictionary. Most people who say "we need eCl@ss" mean the second one, even when they only ask for the first.

The taxonomy is a four-level hierarchy, two digits per level, producing an eight-digit code of the form 27-14-11-01:

Level	Code shape	What it does
Segment	27	Broadest bucket. Segment 27 covers electrical engineering, automation and process control
Main group	27-14	Narrows to a product family
Group	27-14-11	Narrows again
Commodity class	27-14-11-01	The terminal class. This is what carries the attribute list

The dictionary is the part that matters. Each commodity class points to a set of properties. Every property has a stable identifier (an IRDI, shaped like 0173-1#02-AAO677#002), a datatype and a unit, and enumerated properties also carry a fixed value list. So "rated voltage" is not a free-text field you invent. It is a registered property with a defined unit and a defined way to express it.

eCl@ss ships in versioned releases and in two flavors. BASIC gives you the class plus a flat property list. ADVANCED adds structured aspects, blocks and cardinality, so you can describe configurable and multi-variant products properly.

These three get lumped together as "classification standards." They are not interchangeable, and picking the wrong one is how a catalog project stalls.

Dimension	eCl@ss	ETIM	UNSPSC
Governed by	eCl@ss e.V. (Germany)	ETIM International (Netherlands)	GS1 US, on behalf of UNDP
Scope	Cross-industry: automation, electrical, chemicals, MRO, lab, construction	Technical trades: electrical, HVAC, plumbing, building materials, tools	Everything, broadly and shallowly
Class code	8 digits, four levels (27-14-11-01)	EC + 6 digits (EC000123)	8 digits, four levels (segment/family/class/commodity)
Attributes included?	Yes. Full property dictionary with IRDIs, units and value lists	Yes. Features (EF…), values (EV…), units (EU…)	No. Classification only
Property identifiers	IRDI, per IEC 61360 / ISO 13584	ETIM feature codes	None
Primary use	Industrial catalog exchange, BMEcat, Industrie 4.0 / Asset Administration Shell	Distributor catalogs in the trades	Spend analysis, procurement reporting, tax and sourcing categorization
Commonly requested in	DACH and the wider EU	Benelux, DACH, Nordics	US enterprise procurement

The practical read:

• If a buyer asks for UNSPSC, they want to categorize spend. One code per SKU and you are done.
• If a buyer asks for ETIM, they are a distributor in the electrical or HVAC trades and they want features filled in.
• If a buyer asks for eCl@ss, they want a class code and a populated property set, usually delivered inside a BMEcat file, usually at a specific release version.

Many manufacturers end up maintaining all three. They do not conflict. They answer different questions about the same 3/8-16 Grade 8 hex bolt.

The class code is the easy half. The property set is where the labor is.

Take a UL listed 600V wire connector. Classifying it takes one decision. Completing its eCl@ss property set looks more like this:

eCl@ss property	Example value	Where it usually lives today
Manufacturer name	Ideal Industries	PIM, clean
Manufacturer part number	30-1041	PIM, clean
GTIN	07837430104113	ERP, sometimes stale
Rated voltage	600 V	Page 4 of a PDF spec sheet
Wire range, min (smallest conductor)	22 AWG	Buried in a table image
Wire range, max (largest conductor)	10 AWG	Same table image
Approval mark	UL Listed (UL 486C)	A certificate file nobody indexed
Operating temperature, max	105 °C	Marketing copy, unstructured

Every row after the second one has to be found, converted to the unit eCl@ss expects, and mapped to the right IRDI at the right release version. Then repeat across 40,000 SKUs.

The two failure modes are predictable. Distributors reject files for missing mandatory properties: the class demanded twelve, you sent five. Or they reject for unit and value-list violations: you sent "105C" as a string where the property wants a numeric in °C, or you sent "black" where the class carries an enumerated color list with its own value IRDIs.

A classification project ships a code. An eCl@ss project ships filled fields.

A modern PIM is the right place to store eCl@ss: class codes, versioned property sets, export mappings. Anglera works alongside Akeneo, Salsify, Syndigo, inriver and Pimberly rather than replacing them.

The unsolved problem is that the fields arrive empty.

That is the gap Anglera works in. The PIM stores your product data; Anglera does the work of completing it: reading the spec sheets, the certificates and the supplier tables, pulling out the rated voltage and the wire range and the approval mark, converting them into the units and value lists the target eCl@ss class demands, and writing them back into the PIM you already run.

A few things worth planning for:

• Version drift. eCl@ss releases annually. A distributor on release 12 and one on release 14 are not asking for the same file. Map once, re-map on cadence.
• BASIC vs ADVANCED. Do not promise ADVANCED for a configurable product line until you know your source data can actually support the block structure.
• Multi-standard reality. The same populated attribute, 600 V rated voltage, feeds eCl@ss, ETIM and your own PDP. Complete it once, express it three ways. Re-collecting it per standard is avoidable waste.

Treat eCl@ss as a practice, not a project. The catalog gains SKUs every quarter and the standard revises every year, so the fill work never fully ends. It just needs to stop being a fire drill.