A supplier sends you a BMEcat file. It is 300MB of XML, half the descriptions are in German, and nobody can tell you whether it is version 1.2 or version 2005. BMEcat is the XML standard for exchanging product catalogues between suppliers, distributors and procurement systems, published by BME e.V. in Germany. If you buy from continental European manufacturers, you will meet it, and the English-language explanations of it are thin.
What BMEcat is, and what it is not
BMEcat is a transport format. It moves a catalogue from one party to another as a structured XML document. It is not a classification standard, it is not a data model for your business, and it does not decide what your products mean.
A BMEcat file carries product identifiers, short and long descriptions, and prices with currency and tax. It also carries order units and pack quantities, references to images and data sheets, product features, and the supplier’s own catalogue group tree. Everything in it is the supplier’s view of their range, expressed in their units, their language and their categories.
That distinction matters because of what people expect. Teams open a BMEcat file hoping to find a clean taxonomy and typed attributes. What they find is a container. The meaning arrives separately, in the form of a classification standard referenced from inside the file. Getting that separation right is the same problem we work through on every taxonomy and attribution engagement, whatever format the data arrives in.
Who publishes BMEcat and which versions matter
BMEcat is owned and published by BME e.V., the Bundesverband Materialwirtschaft, Einkauf und Logistik, the German association for materials management, purchasing and logistics. It came out of a project with the Fraunhofer Institute and German universities, backed by large German industrials.
Version 1.0 was adopted in November 1999. Version 1.2 followed in 2001 and became the de facto format for electronic catalogue exchange in German-speaking B2B. Version 2005 was published in November 2005. Two revisions followed: 2005.1-advanced in 2012, built with eCl@ss to support their object-oriented model, and 2005.2, released on 1 October 2022.
Four live versions in one format is a problem you inherit rather than solve.
BMEcat 1.2
Still the version we receive most often, twenty-five years after it was written. It is simple, widely supported and limited in three ways that cause real work.
It handles one language per catalogue document. A supplier publishing in German, English and French sends three files. It has no concept of a configurable product. And its element naming uses ARTICLE and SUPPLIER_AID, which will not match anything you write against the 2005 schema.
BMEcat 2005 and its revisions
Version 2005 renamed the core object from ARTICLE to PRODUCT, and SUPPLIER_AID to SUPPLIER_PID. That rename alone breaks naive mappings written against 1.2.
The substance of the release was multi-language catalogues in a single file, plus multi-supplier catalogues and configurable products. It also added dynamic price formulas, richer logistics data, and references to external catalogues for punchout scenarios. The specification is explicit on the language point. In 2005 a multilingual catalogue is one document, with a lang attribute on language-dependent elements. Version 1.2 required a separate document per language.
Check the declared version before anyone writes a mapping. It is the cheapest ten minutes in the project.
How a BMEcat file is put together
Every file has two parts: a HEADER and a transaction.
The HEADER carries catalogue metadata rather than products. Catalogue ID and version, generation date, default language, default currency, territory, buyer and supplier party details, and any framework agreement reference. If the currency or language is wrong here, every price and every description downstream is wrong with it.
The transaction is one of three types, and the choice has consequences.
- T_NEW_CATALOG replaces the catalogue. The receiving system is entitled to discard everything it held before and load only what is in this file.
- T_UPDATE_PRODUCTS modifies products and assortment without touching unrelated data.
- T_UPDATE_PRICES replaces prices for the products named in the file.
Suppliers send partial exports as T_NEW_CATALOG more often than you would believe. The receiving system does exactly what the standard tells it to do, and half the range disappears from the trading portal. When we scope a receiving process, the transaction type is one of the first validation rules we write.
The product record
Inside the transaction, each product carries a predictable set of blocks.
- Identifiers. SUPPLIER_PID for the supplier’s own number, plus manufacturer part number and manufacturer name. INTERNATIONAL_PID carries the GTIN or EAN, with a type attribute.
- Descriptions. DESCRIPTION_SHORT is the mandatory short line, tightly length-limited. DESCRIPTION_LONG holds the marketing copy and often contains basic HTML.
- Order details. ORDER_UNIT, CONTENT_UNIT and the number of content units per order unit, plus minimum order quantity and order interval. This block is where a box of 100 becomes a single item, or the reverse.
- Prices. Price type, amount, tax rate, currency, validity dates and quantity scales.
- Features. The block that carries classification values.
- MIME references. Images, data sheets and safety data sheets, referenced by filename and purpose rather than embedded.
- Catalogue group mapping. Which node of the supplier’s own tree the product sits in.
The catalogue group system
BMEcat lets the supplier ship their own category tree alongside the products. The structure is simple. A root, nodes and leaves, each with a group ID and a parent ID. Products are mapped to groups separately.
It is the supplier’s tree, built for the supplier’s website. It is not your taxonomy and it should never be loaded as one. Treat it as evidence about what the supplier sells, then map it into your own structure. The pattern is the same one we describe in our guide to B2B product classification.
BMEcat, ETIM and eCl@ss: transport versus meaning
This is the part that English-language articles get wrong most often. BMEcat carries classification data. It does not define it.
Two classification standards dominate what travels inside BMEcat files in European distribution. eCl@ss is the broad cross-industry standard, strongest in industrial and process manufacturing. ETIM is the technical product classification used in electrical, HVAC, plumbing and increasingly building materials. UNSPSC and proficl@ss also appear. So do dozens of supplier-specific feature systems.
How ETIM data sits inside a BMEcat file
ETIM International published guidelines specifically for carrying ETIM data in BMEcat. The mechanics are worth knowing, because they explain why the files look unreadable.
Inside the product features block, REFERENCE_FEATURE_SYSTEM_NAME states the ETIM version in the form ETIM-9.0, or the value DYNAMIC. REFERENCE_FEATURE_GROUP_ID holds the ETIM class code, something like EC000905. Each feature name is a code such as EF008618, and each value is a code such as EV000123. Where a value is genuinely absent, the guideline provides codes for not applicable, missing value and unknown.
So an ETIM BMEcat file contains almost no readable words in the technical data. It contains codes. Without the ETIM dictionary for the correct version, in the correct language, the file tells you nothing. That single fact accounts for most of the panic we see when a distributor first opens one.
It also means the ETIM version is load-bearing. Class and feature codes change between releases. A file stamped ETIM-7.0 loaded against an ETIM 9 dictionary produces silent mismatches rather than errors.
How eCl@ss data sits inside a BMEcat file
eCl@ss BASIC fits the flat feature model without difficulty. eCl@ss ADVANCED does not, which is why BMEcat 2005.1-advanced exists. It adds feature groups and a tree structure using feature IDs and parent IDs so that nested, aspect-based property sets survive the trip.
If a supplier tells you they send eCl@ss ADVANCED, confirm the BMEcat version in the same sentence. The two are tied together.
The receiving guideline matters more than the standard
Here is the thing nobody warns you about. Almost nobody exchanges plain BMEcat. They exchange BMEcat plus a receiving guideline, and the guideline is stricter than the standard.
Take Unite, the European B2B marketplace formerly trading as Mercateo. Its published BMEcat 1.2 guideline caps the supplier product number at twelve characters. The short description must be between ten and eighty characters. Image purposes are restricted to a short list, and the guideline names the price type to use for public versus customer-specific catalogues. 2ba, the Dutch data pool for the installation sector, publishes its own rules for how ETIM codes must be populated. In the UK, the Electrical Distributors’ Association and the Builders Merchants Federation sit behind ETIM UK and Ireland. The EDATA pool has its own expectations again.
A file that validates against the BMEcat schema can still be rejected by every trading partner you have. Read the receiving guideline before you build the export, not after the first rejection. This is exactly the discipline that makes supplier onboarding a repeatable process instead of a queue of one-off arguments.
Where BMEcat files go wrong in practice
Six patterns account for most of the failures we see.
Version drift. Mappings written for 1.2 applied to 2005 files, or the reverse. The element names differ, so the load either fails loudly or, worse, silently produces empty fields.
Codes with no dictionary. ETIM or eCl@ss codes loaded as literal strings, so the PIM ends up storing EV000123 as the value of a colour attribute. Somebody notices six months later on the website.
Unit confusion. Order unit, content unit and units per order unit populated inconsistently, so a pack of fifty is priced as one. This is the error that costs actual money.
Prices without their context. Price amount taken and price type, tax rate, currency, validity dates and quantity scale dropped. A net customer price loaded as a list price is a commercial problem, not a data problem.
Images referenced but not delivered. MIME references point at filenames the supplier never sent, or sent in a separate archive with a different folder structure. Technical documents are worse than images here, and they matter more in industrial ranges. We wrote about that pressure in more detail in our piece on industrial product data and technical specifications.
Language assumptions. A 1.2 file is single-language by design. Load a German file into an English catalogue without checking the header language field. Schraube appears on your product listing pages.
ETIM xChange and the direction of travel
BMEcat is not standing still, and neither is what sits inside it.
ETIM International released ETIM BMEcat guideline 5.0 on 30 June 2021. It stated at the time that this would be the last version of ETIM BMEcat. The replacement is ETIM xChange, a JSON format controlled by ETIM International rather than borrowed from another body. Version 1.0 arrived, then 1.1 became the applicable version. Version 2.0 was officially released on 27 November 2025. It added environmental data fields for life cycle and product declarations, and packaging material data for EU packaging regulation.
At the same time, BME has been working with European standardisation on EuroCat. That is a European standards series for digital product catalogues, and it uses BMEcat as its syntax binding.
Read those two together and the practical answer is unglamorous. BMEcat is not disappearing from your inbox this decade. In electrical and installation supply chains, ETIM xChange is where the classification data is heading. Your PIM will need to accept both formats for a long transition. Plan for two receiving pipelines, not a migration date.
What to do if you are receiving BMEcat today
Four things, in order.
First, build a version and guideline check as the front door. Declared BMEcat version, transaction type, header language, header currency, classification system and version. Reject or quarantine on failure rather than loading and fixing.
Second, keep the supplier’s codes. Store the ETIM class code, the feature codes and the value codes as delivered, alongside the resolved human-readable values. When a supplier upgrades ETIM versions, you will need the originals.
Third, treat the supplier’s catalogue group system as an input to mapping, never as your taxonomy. Your structure is a commercial asset. Theirs is a byproduct of their website.
Fourth, decide who owns the mapping. In our experience the load itself is rarely the hard part. Somebody has to decide what the supplier’s fields mean in your model. That decision needs an owner with authority. That is the work we do inside a taxonomy and attribution programme. It is also why we treat supplier data onboarding as an operating process, not a project.
Key takeaways
- BMEcat is an XML transport format published by BME e.V. It carries a catalogue. It does not define what your products mean.
- Four versions are live: 1.2, 2005, 2005.1-advanced and 2005.2. Version 1.2 is single-language and uses different element names. Check the version before writing any mapping.
- Classification data travels inside BMEcat as codes. An ETIM file needs the correct ETIM dictionary version to be readable at all.
- The receiving guideline from a marketplace or data pool is stricter than the standard. Build to the guideline.
- ETIM xChange, a JSON format, is replacing ETIM BMEcat for electrical and installation supply chains, with version 2.0 released in November 2025. Expect to support both formats through a long transition.
- Unit and price context fields cause the errors with real commercial cost. Validate them first.
BMEcat files may be arriving faster than your team can map them. Your suppliers in the electrical sector may be asking which format you want. We design the receiving process for distributors in exactly that position. Book a thirty minute discovery call and we will open a real file with you.