The classification people have done their job. ETIM International keeps the model current, BMEcat ships in 4.0.3 and 5.0, ETIM xChange adds a cleaner transport layer, and ECLASS sits next to all of it. For a B2B manufacturer in electrical, HVAC, fasteners, or building materials, the standards that describe a product in machine-readable form are mature, free, and well documented. With Produktdatengaudi gathering the ETIM and BMEcat community in Sundern on July 7, the format conversation is about to get another round of well-earned attention.
They’re right. The standards are good, and the people maintaining them are not the problem.
But I think they’re being too polite about the distance between a standard existing and a supplier actually sending you data that respects it. The format is solved. Supplier discipline is not. That gap is where PIM implementations quietly run over budget.
A standard is a destination, not a delivery
Here is the quiet truth from 70+ PIM implementations: almost nobody receives BMEcat. They receive an Excel export with merged cells, a PDF catalogue, a price list with the attributes living in the product description as free text, and a folder of images named by the supplier’s internal SKU. BMEcat 5.0 is a beautiful description of where that data should end up. It says nothing about how it arrives.
This is the misread we see again and again. A team buys a PIM, points at the ETIM model, and assumes the standard will discipline the inputs. It does the opposite. The standard raises the bar for what “done” means, which makes the upstream cleanup larger, not smaller. You now have to map free-text supplier fields to ETIM classes and features, normalise units, resolve variants, and fill the mandatory attributes the supplier never tracked. The classification standard told you the target. It handed you none of the work to reach it.
A standard is a destination. Your supplier sent you a delivery. The two are not the same thing, and the difference is paid for in person-days.
What the gap actually costs
Across our implementations, getting 1,000 products from raw supplier inputs to PIM-ready, fully classified, attributes populated, variants resolved, runs to roughly three months of manual work and about 14,000 EUR. That number is not the cost of importing BMEcat. Importing clean BMEcat is fast. That number is the cost of manufacturing standard-shaped data out of inputs that were never standard-shaped to begin with.
It gets heavier at the high end of the ICP. A Pimcore installation with a Classification Store and 500 to 600 attributes is normal for these manufacturers, not exotic. Each of those attributes is a field a supplier has to fill correctly, or a field someone on your team fills on the supplier’s behalf. Multiply by catalogue size and the upstream becomes the dominant line item in the project. The import itself is a rounding error.
The teams that feel this most are the ones onboarding from many sources at once. A global manufacturer pulling product data out of several ERP systems and dozens of supplier formats is not fighting the standard. It is fighting the entropy in front of the standard.
| Where the work lives | Manual, per 1,000 SKUs | What the standard covers |
|---|---|---|
| Supplier inputs to structured data | High (the bulk of 3 months) | Nothing |
| Mapping to ETIM classes and features | High | Defines the target only |
| Filling mandatory attributes | High | Defines which are mandatory |
| Generating valid BMEcat for the PIM | Low | Fully covered |
Read the right column honestly. The standard covers the cheap part. The expensive part, the supplier-to-structured transformation, is exactly the part it leaves to you.
Why “just ask suppliers for BMEcat” doesn’t hold
The obvious objection: make BMEcat a contractual requirement and push the work to the supplier. It is a reasonable instinct, and it works for the small minority of suppliers with mature data operations. For everyone else it produces one of three outcomes. They send nothing and you lose the catalogue. They send invalid BMEcat that passes their export but fails your validation, and you spend the saved time on debugging someone else’s file. Or they send a best-effort spreadsheet and ask you to handle the rest, which returns you to the original problem with a contract clause attached.
Document AI does not rescue this either. Generic extraction tools read a PDF and hand back text. They do not know that this manufacturer’s “Nennspannung” maps to a specific ETIM feature, that these twelve rows are variants of one model, or that a missing IP rating is a mandatory field for this product class. PIM-aware extraction does. The difference between reading a document and producing standard-classified product data is the entire job.
The CFO framing: you are paying for the transformation, not the format
If you run product data, this is the sentence to take to finance. The cost driver in a PIM program is not licensing and it is not the standard. It is the per-SKU cost of turning supplier chaos into classified, attribute-complete data. Quote that number, cost per 1,000 SKUs onboarded, and the business case stops being about software and starts being about throughput.
This is where AI-native onboarding changes the math instead of decorating it. The job is to compress the supplier-to-structured step, the one the standard ignores and the one that eats the budget. In production that step looks like 15 minutes from a supplier PDF to PIM-ready data on a live file, 4,000 products processed in around 90 seconds, 128 variants recognised from a single PDF. The output is standard-shaped: ETIM classes, populated features, resolved variants, ready for the BMEcat your PIM wanted all along. The standard was never the bottleneck. The on-ramp to it was.
The payback question follows directly. If the manual path is roughly 14,000 EUR per 1,000 SKUs and the upstream step can be cut by up to 95 percent, the saving is not a software discount. It is the recovery of the single largest line item in the project, repeated for every catalogue and every new supplier you onboard.
The standard isn’t the test. Your supplier data is.
ETIM and BMEcat answer one question well: what should good product data look like. They were never designed to answer the harder one: how do you get there from what your suppliers actually send. Produktdatengaudi will rightly celebrate the format. The work that decides your timeline and your budget happens before the format, in the messy middle between a supplier’s spreadsheet and a valid BMEcat file.
So the question for any team standing up or scaling a PIM in 2026 is not whether you have adopted the standard. It is simpler and more uncomfortable. Is your supplier data standard-ready, or just standard-aware?
If you want to see the upstream step compressed on your own files rather than a canned demo, that is the test worth running. Bring a real supplier PDF or Excel export and watch where the three months actually goes.
Related reading on the same gap: how to audit supplier data quality before onboarding, the three operational reasons your PIM isn’t saving time yet, why document AI won’t fix your product data, and why the EU Digital Product Passport will break a PIM that depends on clean structured data.
