Classification standards
Your categories are built for your buyers. A classification standard is built so that your customer's procurement system can understand your articles without reading a word of your prose. They are two different structures over the same products, and you need both.
The scenario
A large customer — a Konzern, an energy utility, a hospital group — sends you a
catalog specification. Somewhere in it: "Artikel sind nach eCl@ss 12.0 zu
klassifizieren, Merkmale gemäß Standard zu befüllen." Your catalog has
categories called Fittings and Fasteners, and attributes called
thread_size and material. Neither maps to anything in that document.
That specification is not a formality. Without the classification, the file you send cannot be loaded into their system, and you are not a supplier in their shop. This is the single most common reason a technically finished B2B catalog project stalls at the last metre.
What a classification system is
Three layers, always the same shape:
| Layer | eCl@ss term | What it is | Example |
|---|---|---|---|
| Class | Sachgruppe / Klasse | Where the article belongs in a fixed global tree | 23-11-01-01 Hexagon head screw |
| Feature | Merkmal | A standardised property that class may carry | AAA123 Thread size |
| Value | Merkmalswert | The value, often from a fixed list, with a fixed unit | M8, unit mm |
The point is that all three are global identifiers, not words. Your customer's
system does not need to know that you call the field thread_size or that your
label is German. It reads the class code, the feature code and the value, and it
knows exactly what it received. That is the entire value proposition, and it is
why the standards feel bureaucratic — they are designed to be readable by
software in a country you have never sold to.
eCl@ss, ETIM and UNSPSC
| eCl@ss | ETIM | UNSPSC | |
|---|---|---|---|
| Origin | German industry consortium | Dutch/European, electrical trade | UN-backed, global |
| Depth | Class and features and values | Class and features and values | Class only |
| Structure | 4 levels, 8-digit code | Class + feature groups | 4 levels, 8-digit code |
| Strong in | Industry, MRO, chemicals, DACH manufacturing | Electrical, HVAC, sanitary, building services | Procurement reporting, spend analysis, public sector |
| Releases | Twice a year | Roughly annual | Periodic |
| Who asks for it | German and European corporate procurement, SAP-based buyers | Elektrogroßhandel, TGA, Sanitär-Heizung-Klima | Global corporates, Ariba/Coupa spend categories |
The practical reading of that table:
- eCl@ss is the one German B2B asks for. If you sell industrial goods, fasteners, tools, chemicals or MRO to German or Austrian corporates, this is the standard in your specifications.
- ETIM is the one the trades ask for. Elektro, Sanitär, Heizung, Klima. If your customers are Elektrogroßhändler or TGA contractors, ETIM is not optional, and it usually arrives together with a BMEcat requirement.
- UNSPSC is shallower and used differently. It classifies what kind of spend an article is, for reporting and category management. It has no features, so it cannot describe an article — which is why a customer asking for UNSPSC alone usually wants it for their spend analytics, not for their catalog search.
You may well need two of them at once, for different customers. That is normal and it is the reason classification is modelled as an additional layer on the product rather than as your category tree.
23-11-01-01
splits screws in ways no buyer navigates, and your buyers' tree groups things
eCl@ss keeps far apart. Keep both, map between them, and never try to make one
do the other's job.Why procurement systems require it
Inside a large customer, the catalog you deliver does not go to a person. It goes into SAP Ariba, Coupa, Onventis, Mercateo or an SAP SRM instance, where it sits next to catalogs from forty other suppliers. Classification is what makes those forty catalogs behave like one:
- Search across suppliers. A buyer searches for a hexagon screw and gets candidates from every supplier, because every supplier used the same class.
- Comparison on features. Their system can put your
M8next to a competitor'sM8because both are the same feature code with the same unit. Free-text descriptions cannot be compared. - Approval and cost-centre rules. Approval workflows and budgets are often written against classes — "chemicals over €500 need a second approver". An unclassified article cannot be routed.
- Spend reporting. The controlling department reports by category. Your articles are invisible in that report without a class.
This is also why classification and punchout are related but not the same. A punchout session sends buyers into your shop, so your own search and categories do the work — classification still matters because the order data and the article master flowing back carry it. A static catalog upload has nothing else to go on.
Mapping your attributes to standard features
This is where the work actually is, and it is more work than the class assignment.
Class assignment is per family and mostly mechanical: your Hexagon screws family maps to one eCl@ss class, and every product in it inherits it. An afternoon covers a mid-sized catalog.
Feature mapping is per attribute, per class, and it is where the mismatches live:
| Mismatch | Example | What you do |
|---|---|---|
| Unit differs | You store bar; the feature expects kPa | Convert on export, from the measurement family |
| Value list differs | Your option is v4a; the feature expects a specific value code | Map option code → standard value code, once per attribute |
| You have no attribute | The class requires a feature you never captured | Create the attribute and fill it, or accept an incomplete class |
| You have several | Your length_mm and length_inch map to one feature | Pick the standard unit and convert |
| The feature is free text | The standard allows any string | Lowest risk; map directly |
The second row is the one that pays off twice: mapping your option codes
rather than your labels means the mapping survives translation. v4a maps to a
standard value once, and works in every language. This is the practical reason
option codes matter more than option
labels.
How this works in the Revenue Cloud
- Classification is a layer on the product, alongside your own categories, not instead of them.
- The class is assigned per family and can be overridden per product for the cases where one family spans two classes.
- Features are mapped from your attributes, with unit conversion and value mapping declared once and applied on every export — see Map attributes to a classification.
- Completeness is measured against the standard as well as against your own family. A product can be 100% complete for your web shop and fail eCl@ss validation because a required feature is empty.
- Multiple classifications coexist. eCl@ss for one customer, ETIM for another, from the same product data.
Next
- Catalog exchange formats — the file the classification travels in.
- Map attributes to a classification
- Sell through marketplaces and channels