A supplier sends a catalogue file. It is valid XML, it opens, it contains prices – and still, after the import, part of the products sit in the shop without a single technical feature, because their classification does not match your own filters. This is where two questions part ways that are constantly mixed up in daily work: how catalogue data travels from one company to another – and what it means once it arrives. For the first question there is BMEcat, an XML-based exchange format for catalogue data in the B2B field (BME e. V.). For the second there are classifications such as ETIM. This article shows what each standard does, how a catalogue file is built, where imports typically fail and in what order the build-out pays off in your own B2B shop.
Two standards, two different jobs
BMEcat describes how a catalogue file is built: which elements exist, in what order they appear, which of them are mandatory and how a target system is to process them. ETIM describes something else, namely what a product is: which class it belongs to and which features that class requires. The two standards do not compete, they sit on top of one another. The BMEcat standard is explicitly not tied to any particular classification system and proposes no classifications of its own (BMEcat 2005.2, chapter 1.3); it carries the classification that two partners have agreed on. Keeping that separation in mind saves you a recurring discussion in catalogue projects – the question of why a cleanly imported catalogue still leaves the filter pages empty.
BMEcat ist ein XML basiertes standardisiertes Austauschformat für Katalogdaten im B2B-Bereich.
BME e. V., German Association for Supply Chain Management, Procurement and Logistics
The standard is anything but new. Version 1.0 was adopted in Frankfurt in November 1999, with the technical development carried out by the Fraunhofer Institute for Industrial Engineering and the universities of Duisburg-Essen and Linz (BME e. V.). With version 1.2, presented at CeBIT 2001 in Hanover, BMEcat established itself as the de facto standard for exchanging electronic product catalogues (BME e. V.). Version 2005 was released on 4 November 2005 (BME e. V.). The current edition carries the number 2005.2 (BME e. V.) and, in the specification's version history, the date 1 October 2022 (BMEcat 2005.2). In practice that means: an importer receives files spanning more than two decades of standard history, and anyone reading only one edition fails on the first delivery from a company that uses the other.
A catalogue is called “export_2026.xml” and is nevertheless BMEcat 1.2. The binding statement sits in the file's root element, together with the transaction. Both belong in the first check before the import – before character set, before field lengths, before anything else. An importer that guesses the version will, in case of doubt, process fields that do not exist in that edition and skip others that are mandatory.
The three transactions: what a catalogue file actually does
A BMEcat file is not a pile of data, it is a statement of intent. BMEcat provides three transactions (BMEcat 2005.2, chapter 3.1): T_NEW_CATALOG transmits a new catalogue, T_UPDATE_PRODUCTS updates product data, T_UPDATE_PRICES updates price data. The transaction sits in the catalogue document directly beneath the root element and determines which data areas may be present at all; in a price update these are only the price-determining details. Using the update transactions makes it possible to reduce the volume of documents to be transmitted, because changes do not require the complete catalogue to be sent again (BMEcat 2005.2, chapter 3.1).
| Transaction | What is transmitted | Example cadence from the specification | Pitfall on import |
|---|---|---|---|
| T_NEW_CATALOG | The complete catalogue | once a year | Articles that are missing have been dropped – the import must treat that as a statement |
| T_UPDATE_PRODUCTS | Changed and new products | every three months | The mode per product decides between create, change and delete |
| T_UPDATE_PRICES | Only price-determining details | when price changes occur | Product data stays untouched; a full import here wipes out maintenance work |
| No statement | Not provided for | not applicable | Reject the file rather than guess – the transaction is not an optional detail |
The catalogue header area has the same structure for all three transactions (BMEcat 2005.2, chapter 3.2.1). It carries the details identifying the catalogue and its validity, the creator and the recipient, plus default values that apply to all contained products – language and currency, for example. These very defaults tend to be overlooked on import. A catalogue without a currency statement per product is not necessarily faulty; it relies on the statement in the header. Skipping the header and going straight into the product loop produces silent errors that only surface on the invoice. How closely catalogue maintenance and order processing are linked is shown in the article on EDI integration in order processing.
<?xml version="1.0" encoding="UTF-8"?>
<BMECAT version="2005">
<HEADER>
<CATALOG>
<LANGUAGE default="true">eng</LANGUAGE>
<CATALOG_ID>CAT-2026-01</CATALOG_ID>
<CATALOG_VERSION>004.012</CATALOG_VERSION>
<CURRENCY>EUR</CURRENCY>
</CATALOG>
<SUPPLIER>
<SUPPLIER_ID type="supplier_specific">L-88</SUPPLIER_ID>
<SUPPLIER_NAME>Example Electrical Wholesale</SUPPLIER_NAME>
</SUPPLIER>
</HEADER>
<!-- Prices only: product data stays untouched -->
<T_UPDATE_PRICES prev_version="004.011">
<PRODUCT mode="update">
<SUPPLIER_PID type="supplier_specific">4711-16A</SUPPLIER_PID>
<PRODUCT_PRICE_DETAILS>
<DATETIME type="valid_start_date"><DATE>2026-10-01</DATE></DATETIME>
<PRODUCT_PRICE price_type="net_customer">
<PRICE_AMOUNT>4.90</PRICE_AMOUNT>
<PRICE_QUANTITY>1</PRICE_QUANTITY>
<LOWER_BOUND>10</LOWER_BOUND>
</PRODUCT_PRICE>
</PRODUCT_PRICE_DETAILS>
</PRODUCT>
</T_UPDATE_PRICES>
</BMECAT>What ETIM describes: class, feature, value, unit
The ETIM model is a two-level classification model (ETIM International). Product groups sit at the top, product classes below them, and every class belongs to exactly one group. The group level exists mainly for administration; the actual work sits in the class. A class bundles similar products from different manufacturers and defines which features belong to the description. A feature in turn is described by name, feature type, unit and value. This structure is the reason a filter bar over ETIM data works without special logic: the values do not come from free text but from a predefined list.
- A – alphanumeric: a fixed list of possible values, such as colours or designs (ETIM International). In the shop this becomes a selection list, not a text input.
- L – logical: a yes-or-no statement (ETIM International). In the shop a switch that filters cleanly.
- N – numeric: a single numeric value (ETIM International) that needs a unit of measure – except for features of the “number of …” kind.
- R – range: two numeric values bounding a span (ETIM International). In the shop this is the case where simple importers regularly fail, because they only provided for a single numeric field.
The sheer scale is why complete feature maintenance has the character of a project. Across all sectors, the ETIM 10.0 release counts 159 product groups, 5,640 classes, 17,377 features, 16,163 values and 188 units (ETIM International). These figures describe the model, not your own assortment: an electrical wholesaler touches only a section of them, a specialist fewer still. The task is therefore not to cover ETIM completely, but to fill the classes of your own assortment cleanly – and to know which features are expected in those classes.
Official international ETIM releases appear about every three years (ETIM International). The current edition, ETIM 10.0, was released in December 2024 (ETIM International) and is the result of 5,264 requests for change in total; 119 new classes were added (ETIM International). For ETIM 11.0 the deadline for submitting change requests ran until 30 June 2026, and the final release is planned for 1 December 2026 (ETIM International). Between the official releases there are dynamic interim releases that contain classes already published or approved for publication and mark differences from the official state through change codes (ETIM International).
Between two ETIM releases, classes disappear, new ones emerge and features move. Anyone who stores the class code on the product without carrying the corresponding release cannot later say what a value meant. The resilient structure stores three details per product: class code, release and the time of assignment. Those three fields cost an hour during the build and typically save days of reconstruction at the next change.
The release format of the model itself is called ETIM IXF and is based on XML; it can contain several language versions in a single file (ETIM International). The coding structure and the system language ETIM English are freely available, as are several local language versions, German among them (ETIM International). That matters in practice, because feature names can then be output in both language versions of a shop without a translation of your own – the codes are language-independent, the labels come from the model.
Alongside the core model there are the ETIM Modelling Classes, an extension for representing products as three-dimensional objects. So far ETIM MC comprises 360 classes for frequently modelled products (ETIM International). For dealers with a planning focus this is the connection to construction planning; for everyone else a level worth knowing about but not worth filling yet.
Mapping: where supplier data becomes shop data
The actual work of a catalogue project is the mapping, and it has two layers. The first is field mapping: which element of the file fills which field in the shop. The second is feature mapping: which supplier feature corresponds to which feature of the class. The first layer is usually described in a day, the second needs domain knowledge about the assortment. The illustration above shows both kinds of gap that arise: a source field with no target, and a mandatory feature of the class for which no value was delivered. Neither is a fault in the file – they are results that someone has to decide on.
Identification
Supplier article number, manufacturer number and GTIN are three different things. The key for matching is the supplier's number combined with the supplier's own code – a GTIN can be missing or carried by several dealers.
Classification
The class is stored per product, together with the name of the classification system and its version. Without the version the class code cannot be interpreted unambiguously later.
Features
Feature code, value and unit belong together in one row. A value without a unit is unusable for numeric features, and so is a unit without a conversion rule.
Media and attachments
Images, data sheets and drawings arrive as references. Whether the targets are reachable is not stated in the file – the import has to check that itself, and check the content type, not just the status code.
Version 2005.2 improved matters here. Feature names of a product may now be up to 80 characters long, which allows a more precise designation of product features (BME e. V.). In addition, feature values can be given both as their own expression and as a reference to an expression in the classification system, in any combination (BME e. V.). That is exactly the flexibility you need when a supplier delivers the larger part of its features classified and the rest as free text. Where this data is maintained permanently is a separate decision: in the shop, in the ERP system or in a PIM system. The article on product data sovereignty describes the trade-off in detail.
Where imports typically fail
Catalogue imports rarely fail on the XML. They fail on assumptions that are not stated in the file and that nobody has therefore verified. The following six points come up in projects so regularly that they belong in every check routine before the first record is written to the database.
- Units without conversion: one supplier delivers millimetres, the next centimetres. Both are correct. Without normalisation to one target unit per feature, the shop filters two orders of magnitude together – and returns hits that nobody can retrace.
- Decimal separators: a comma instead of a full stop silently turns 1.5 metres into 15 or into zero. The check belongs before the conversion, not after it.
- Prices without reference: a price without a price unit and a quantity unit is not a number but a guess. Cable per metre and cable per 100 metres differ by two zeros.
- References into the void: image and document addresses from the catalogue are often reachable only during a limited window. A status code of 200 does not prove an image – only the content type of the response does.
- Multilingual catalogues: in BMEcat 2005, multilingual catalogues can be transmitted with a single catalogue document (BME e. V.). An importer that ignores the language statement overwrites the first language version with the last one read.
- Discontinued articles: a product update deletes nothing by itself. Anyone who does not actively retire delisted goods keeps selling them – the article on handling unavailable products shows the consequences in the shop.
The countermeasure is unspectacular and effective: every catalogue first runs against a check that does not write to the database but counts. How many products, how many with a class, how many with a complete feature set, how many with reachable images. Only when those figures match the advance notice does the write run follow – and it runs on a test instance with realistic but non-sensitive test data. Without that separation, you learn the difference between a warning and an error on the production system.
ETIM xChange: the format changes, the model stays
Where ETIM International previously recommended the BMEcat standard, there is now a format of its own: ETIM xChange, a JSON-based exchange standard for product master data (ETIM International). Version 2.0 was officially released on 27 November 2025 (ETIM International). It brings, among other things, extended environmental data fields for life cycle assessments and environmental product declarations, an element for packaging material details and support for managing serial numbers (ETIM International). The model behind it does not change: classes, features, values and units remain the same.
For planning purposes that does not mean BMEcat will disappear any time soon. In some countries national formats remain the industry standard, in part alongside ETIM xChange and ETIM BMEcat (ETIM International). In parallel, ETIM has been part of the GDSN master data exchange standard from GS1 since 27 May 2024 (ETIM International), so classes, features, values and units can also be transmitted along that route. A dealer building today should therefore not bet on one format, but separate the mapping from the file: the feature logic belongs in your own data, the reading in an exchangeable adapter. Anyone exchanging catalogues across borders also meets the requirements of the Geo-blocking Regulation.
Anyone sourcing catalogues from twenty suppliers will serve both routes for years. That is not a slip-up but the normal case during the transition. What matters is only that both routes feed into the same internal structure and that the check stays the same. Two separate import lines, each with its own feature logic, are the construction that is costly to unwind later.
The shop as a catalogue sender
So far this has been about the import. The opposite direction is often forgotten, although it is asked for regularly in B2B: a business customer wants to see their supplier's catalogue inside their own procurement system. There are two routes for that, and they are frequently confused. One is the catalogue file that purchasing reads in. The other is the session in the external system, where a buyer jumps from their procurement application into the shop and hands the basket back – described in the article on punchout catalogues with OCI and cXML. Punchout is the session, BMEcat is the file before it. BMEcat 2005 explicitly counts these routes among external catalogues (BME e. V.).
The same requirements apply to the export as to the import, only with the roles reversed. The shop must be able to decide per customer which assortment and which prices go into the file, it must supply classification and features, and it must version the catalogue. Anyone carrying spare-part or accessory relationships should pass the product references along, because they are otherwise lost in the target system – what such a structure looks like is shown in the article on the spare parts catalogue with assembly search. A catalogue export containing only number, text and price meets the letter and misses the point: in the target system nobody then finds the product, because no features arrive there to filter on.
The order of a roll-out
Catalogue projects rarely fail on the technology and often on the sequence. Starting with the importer means building against a data situation you do not yet know. The following sequence has proven itself in projects because each step closes a decision before the next effort begins.
- Take stock: which suppliers deliver in which format and in which edition. Three real files say more than any assurance over the phone.
- Delimit the classes: which classes of the classification system does your own assortment touch. That list is the scope of the project, not the total scope of the model.
- Define the target structure: class, release, feature, value and unit as separate fields – not as free text and not as a compound block in a single column.
- Write the mapping: one traceable mapping file per supplier that can be maintained in daily operation without programming.
- Check before writing: count instead of write, with fixed thresholds. A run that falls below the threshold is aborted and reported.
- Agree the cadence: who delivers when, in which transaction, and who decides on open mappings. Without a named responsibility, maintenance is left undone.
The effort is distributed differently than many expect. Programming the reading is the smaller part; agreeing the features with purchasing is the larger one. That is exactly why it pays to start early with one supplier and thirty classes rather than twenty suppliers and the entire assortment. We support this build-out in Shopware projects just as in grown custom developments; the sequence stays the same.
What operation demands afterwards
A catalogue import is not a project with an end date but a procedure. Regular work follows: new delivery files, changing class assignments, a release change of the classification system every few years. The question of who decides the open mappings is therefore more important than the question of which library reads the XML. In practice a short list of open points per run, addressed to a named person, has proven itself – rather than a log that nobody opens.
For the gaps that remain even after a careful mapping there are two routes. The first is to ask the supplier; it is the cleaner one but takes time. The second is enrichment in house, where missing features are derived from data sheets and descriptions and then verified. How that runs under control is described in the article on automated data enrichment and on our service page for product data enrichment. What matters in both cases is the provenance per value: delivered, derived or set manually. Without that distinction you cannot decide which value wins at the next delivery.
The commercial core is sober. A clean catalogue exchange does not raise revenue at the push of a button; it lowers the effort per maintained article and makes assortments filterable in the first place. In companies with a five-digit article count, that is the difference between a shop where customers find a product through its features and a catalogue you can only operate with an article number. Anyone seriously expanding their B2B business will, as a rule, not get past this foundation.
This article draws on the BMEcat 2005.2 specification published by BME e. V. and on the association's BMEcat pages covering origin, versions and downloads, as well as on the publications of ETIM International regarding the model structure, release policy, exchange format and the release announcements for ETIM 10.0, ETIM 11.0, ETIM xChange 2.0 and the inclusion of ETIM in the GDSN network of GS1. The figures on the scope of ETIM 10.0 come from the statistics table that ETIM International published with the release announcement and refer to the column covering all sectors. On the market penetration of the two standards, the available material comes mostly from parties involved; we are not aware of robust surveys, which is why no adoption rate is stated here.
As a rule yes, as soon as more than two or three suppliers are involved. A spreadsheet is a result, not a format: column order, headers and separators change from run to run, and nobody owes you consistency. BMEcat defines the structure, the mandatory details and the meaning of the transmission (BME e. V.), so an importer can work against the same expectation for years. With a single supplier and a stable spreadsheet, the effort can in our experience be greater than the benefit.
BMEcat is the transport format, ETIM the classification. BMEcat defines how the file is built; ETIM defines which class a product has and which features belong to it. The BMEcat standard is not tied to a particular classification system (BMEcat 2005.2, chapter 1.3) but carries the system that two partners have agreed on. In practice that means: a BMEcat file can contain ETIM features, but it does not have to – and that is exactly the point to clarify before any project.
Official international releases appear about every three years (ETIM International); ETIM 10.0 dates from December 2024, and ETIM 11.0 is planned for 1 December 2026 (ETIM International). In between there are dynamic interim releases (ETIM International). For the shop this is above all a design requirement: store the release and the time of assignment alongside the class code. A change then becomes a migration with a known scope instead of a search in the dark.
The reading can be automated, the decision on open mappings typically not completely. A run ends, in our experience, with a remainder: source fields without a target and mandatory features without a value. That remainder should be small, visible and assigned to a person. A procedure that conceals it does not create automation but silent gaps in the assortment, which only surface when a search returns nothing.
That depends on the number of output channels, not on the article count alone. As long as the shop is the only target, maintenance can stay there. As soon as catalogues are exported, further sales routes are served or print data is produced, maintenance usually moves into a system of its own, because otherwise the shop becomes the source for everything. The trade-off and the transition path are covered in our overview of interfaces and system integration.
With three real supplier files and a list of the classes your assortment touches. That gives you the scope, and from it follows whether the first step is an importer, a feature structure or an export route. This preliminary clarification costs a few hours and prevents the costly variant: a finished importer for a data model that cannot hold the features at all. If you would like to go through this together, get in touch – we look at the files and size up the effort.