What is BMEcat? Versions, Structure and How ETIM Travels Inside It

BMEcat is an XML format for sending a product catalogue from a supplier to a buyer. It is the default in European B2B trade, particularly in electrical wholesale, building services, industrial supply and public procurement, and it is almost always the file a German or Dutch wholesaler means when they ask for "your catalogue in the standard format". It is also the vehicle that carries ETIM classification data, which is why the two get discussed together so often that some people assume they are the same thing.

They are not. ETIM says how a product is classified and which features it has. BMEcat is the envelope that gets the classification, the features, the prices, the descriptions and the images from your system to theirs.

What BMEcat is and who owns it

BMEcat is owned and published by BME e.V., the German association for supply management, procurement and logistics. Development runs through its eBusiness Standardization Committee, with working groups for the detailed schema work. The specification is free to download.

What BMEcat defines is the structure of a catalogue transmission: who sent it, to whom, in which currency and language, what kind of transaction it is, and then the products themselves with their identifiers, descriptions, classifications, features, prices, packaging, logistics data and media references. What it does not define is the classification itself. BMEcat carries whatever classification system you declare, whether that is ETIM, eCl@ss, UNSPSC or the buyer's own catalogue group structure.

The version history, and which one you will actually be asked for

Five releases matter:

• BMEcat 1.0, 8 November 1999. Historic.
• BMEcat 1.2, 27 March 2001. DTD-based. Still in active use, and still the version a surprising number of receivers ask for.
• BMEcat 2005, 14 November 2005. Moved from DTD to XML Schema. Declared fully downward compatible with 1.2.
• BMEcat 2005.1. The specification document itself is dated 3 October 2010, while BME's own version page gives 2012. The two sources conflict, so treat the year as approximate.
• BMEcat 2005.2, 1 October 2022. The current version.

The practical reading of that timeline: the format has been stable for two decades, and 1.2 has never gone away. If you are building an export, build it to produce both a 1.2 file and a 2005.2 file from the same internal model, because you will be asked for both.

Note that "fully downward compatible" is a claim about the schema, not a promise that a 2005 file will import somewhere expecting 1.2. The migration pain between them is not element renaming, it is the move from a DTD to a namespaced XML Schema, and the receiver's own profile. Which is the thing that actually breaks BMEcat imports.

How a BMEcat file is put together

The shape is simple and worth knowing before you open one:

1. A HEADER block carrying the catalogue metadata: catalogue ID and version, language, currency, the supplier and buyer parties, and validity dates.
2. Exactly one transaction element, and this is the part people get wrong. A BMEcat file contains one of T_NEW_CATALOG, T_UPDATE_PRODUCTS or T_UPDATE_PRICES. Not two. Not all three.

The three transaction types do different jobs. T_NEW_CATALOG is a complete catalogue, and the receiver is entitled to treat anything absent from it as withdrawn. T_UPDATE_PRODUCTS is a delta of product records. T_UPDATE_PRICES is a price-only delta, which is the one you want for a quarterly price list rather than resending 40,000 products.

The most common operational error here is sending a partial catalogue as T_NEW_CATALOG. The receiver deletes everything you left out. Sending a full catalogue as T_UPDATE_PRODUCTS is the milder mirror of the same mistake: discontinued lines never disappear, and the buyer's catalogue slowly fills with products you no longer sell.

Within the transaction, each product carries the supplier's own article number as its key, descriptions in short and long form, order units and content units, price details by price type and validity, references to other products, mapping into the catalogue group structure, media references for images and datasheets, and the feature blocks that carry classification.

How ETIM travels inside BMEcat

This is the part that matters most in practice, because a wholesaler asking for "ETIM in BMEcat" is asking for a specific arrangement of four elements inside the product features block:

• REFERENCE_FEATURE_SYSTEM_NAME declares which classification system and which release, for example an ETIM release identifier.
• REFERENCE_FEATURE_GROUP_ID carries the ETIM class, the EC code.
• FNAME carries the ETIM feature, the EF code.
• FVALUE carries the value, which for a list feature is an EV code and for numeric or logical features is the number or the boolean.

Two points here correct widespread assumptions. First, ETIM unit codes, the EU codes, do not normally travel in the file. ETIM fixes the unit per feature, so the receiver derives it from the feature definition rather than reading it from your file. If you are populating a unit element per feature, check the receiver's profile before you spend time on it.

Second, and this is the one that costs real money: ETIM International publishes around twenty country-specific BMEcat guidelines. A file built to the Dutch guideline is not automatically acceptable to a German receiver, and neither is automatically acceptable to a Norwegian one. "ETIM BMEcat compliant" is therefore not a portable claim. Ask which country guideline, which ETIM release, and which version of the format, and expect the answer to differ by customer. The guide to implementing ETIM covers the class and feature mapping work that sits behind this, and ETIM mapping software exists largely because that work has to be redone for every receiver.

The four things that break an import

The receiver's profile, not the standard

The standard is permissive. Receivers are not. Almost every large wholesaler publishes a profile that narrows the standard: which elements are mandatory, which classification system and release, which price types, which image formats and resolutions, which units of measure, how many characters a long description may run to. A file that validates against the BMEcat schema and fails the receiver's profile is the normal case, not the exception. Get the profile document before you build the export, not after the first rejection.

Transaction type mismatches

Covered above, and worth repeating because it is the one with destructive consequences. Agree in writing which transaction type you send, on what cadence, and what the receiver does with products absent from a full catalogue.

Classification release drift

You declare your ETIM release in the file. The receiver is on a release too, and it may not be the same one. Class and feature codes are added and deprecated between ETIM releases, so a class that is valid in your release may not exist in theirs. The fix is the same as for any standards work: store the release alongside the classification on every product record, and be able to generate output against more than one release. The changes between ETIM 8 and 9 are a good illustration of how much can move in one step.

Media references that point nowhere

BMEcat references images and documents rather than embedding them, so the file can be perfect and the import still fail because the referenced file is missing, is the wrong format, or is at a resolution the receiver rejects. Media is also where the profile rules tend to be strictest, because the buyer is going to publish these images on their own site.

BMEcat and ETIM xChange

The ETIM BMEcat Guideline reached version 5.0 and 5.0.1, and that is the final version. ETIM International's successor format is ETIM xChange, a JSON format, with version 2.0 released on 27 November 2025.

What that does and does not mean. It does mean the ETIM-specific guidance layered on top of BMEcat is now frozen, and that new investment from ETIM International is going into xChange. It does not mean BMEcat is being retired: BMEcat is BME's standard, not ETIM's, and the installed base of wholesalers importing BMEcat 1.2 and 2005 files is enormous. Nor does it mean xChange is what your customers want today; adoption is early, and a wholesaler's import pipeline does not get rewritten because a new format exists.

The reasonable planning position is that BMEcat remains the format you must support for the foreseeable future, and that xChange is a second output you add when a specific customer asks for it. Both are generated from the same internal product model, which is the whole argument for not treating any single output format as your source of truth.

How it compares with other catalogue formats

• BMEcat. European B2B, supplier-to-buyer catalogue transmission, XML, free specification, carries any classification system. Strongest in electrical, HVAC, building services, industrial supply and public sector procurement.
• cXML and OCI punchout. Procurement-oriented, used for hosted catalogues and punchout sessions into Ariba, Coupa and SAP. Thinner product data, more transactional. Frequently requested alongside BMEcat, not instead of it.
• GS1 GDSN. Consumer goods, data pools, brick-level GPC classification. Different world, different audience.
• ACES and PIES. North American automotive aftermarket. Entirely separate machinery, and covered in the ACES and PIES explainer.
• The customer's spreadsheet template. Still, in practice, the most common format of all, and the reason so many suppliers never get as far as BMEcat.

A distributor selling into several European markets will typically end up maintaining BMEcat output against two or three ETIM releases and half a dozen receiver profiles, plus punchout catalogues and plus the spreadsheets. That is the work that ETIM and standards mapping software is built to absorb.

What it costs

The specification is free. That is genuinely the end of the story for the format itself: no licence, no per-file charge, no membership requirement to read the spec.

ETIM is the cost. Access to the ETIM classification data in a usable form runs through ETIM International and its national member organisations, and in practice that means membership. Budget for the classification data, the mapping effort and the ongoing release maintenance, not for the file format.

Getting a BMEcat file out of a real catalogue

The export itself is the easy part. Four things have to be true before the export can produce anything a receiver will accept.

1. Every product has a classification, with its release recorded. Not a category name, a code, against a declared ETIM or eCl@ss release.
2. Features are populated as typed values, not text. A numeric feature needs a number, a list feature needs the value code, a logical feature needs a boolean. "Approximately 230V" in a numeric field fails.
3. Units and order quantities are normalised. Order unit, content unit and the ratio between them have to be consistent, because the receiver calculates pricing from them.
4. Media is present, named predictably, and at the required resolution. Fix this before the first export, not after.

Those four requirements are the actual project. Steps one and two are where an automated mapping and normalisation layer earns its place: classifying a product against an ETIM class and populating typed features from a supplier datasheet is repetitive, rule-resistant work that a model handles well when it is choosing from a fixed class and value list rather than writing free text. SKULaunch extracts the attributes from supplier PDFs and spreadsheets, maps them to the ETIM class and feature codes, and generates the BMEcat output per receiver profile, with the classification suggestions carrying a confidence score so a person reviews the uncertain ones rather than all of them.

Key takeaways

• BMEcat is a free XML catalogue format from BME e.V. It carries classification data; it is not itself a classification.
• Version 1.2 from 2001 is still widely required. The current version is 2005.2, from 1 October 2022. Build an export that can produce both.
• One file, one transaction type. Sending a partial catalogue as T_NEW_CATALOG tells the receiver to delete everything you omitted.
• ETIM rides in the product features block through four elements: system name and release, class, feature, value. ETIM unit codes normally do not travel in the file.
• There are around twenty country-specific ETIM BMEcat guidelines, so "ETIM BMEcat compliant" means nothing without the country, the ETIM release and the BMEcat version.
• What breaks imports is the receiver's profile, not the standard. Get the profile first.
• The ETIM BMEcat Guideline is final at 5.0.1, with ETIM xChange 2.0 as the JSON successor. Plan to support BMEcat for years yet, and add xChange when a customer asks.
• The format is free. The classification data and the mapping work are the cost.