Catalog exchange formats
At some point a customer stops browsing your shop and asks you to send them your catalog as a file. What they mean by "a file" depends entirely on which industry they are in and which system they run — and getting it wrong costs weeks.
The three answers, and who asks for each
| Format | Who asks | What it carries | Effort |
|---|---|---|---|
| BMEcat | German and European corporate procurement, SAP/Ariba/Onventis shops | Articles, prices, media, classification, features, multi-language | High once, low afterwards |
| Datanorm | The trades — Elektro, Sanitär, Heizung, Klima; Handwerker software | Articles, prices, discount groups, updates | Low, and rigid |
| Excel or CSV | Everyone else, especially first requests | Whatever the customer's spreadsheet says | Low each time, unbounded in total |
The trap is the third row. An Excel export takes an afternoon and feels like the pragmatic answer. Twenty customers later you maintain twenty spreadsheets with twenty column orders, and every price change is twenty manual exports. The point of an export profile is to make the twentieth one cost the same as the second.
BMEcat
BMEcat is the German standard for exchanging catalog data, published by the Bundesverband Materialwirtschaft, Einkauf und Logistik. It is XML, it is verbose, and it is what a corporate procurement department means when they say "send us your catalog".
What a BMEcat file carries:
- Article identity — your article number, the manufacturer's number, EAN, and the customer's own material number where you know it.
- Descriptions — short and long, per language. One file can carry German and English side by side, which is the reason BMEcat and translation are the same project.
- Prices — with currency, validity dates, price unit, quantity scale and tax. The price unit matters: € per 100 pieces is a different thing from € per piece and the field for it is not optional.
- Order units and packaging — order unit, content unit, packing quantity. Almost every rejected BMEcat file is rejected here first.
- Classification — the eCl@ss or ETIM class per article, plus the standard features and their values. See Classification standards.
- Media — images, datasheets, drawings, either as URLs or as files delivered alongside.
Two versions are in real use: 1.2, which is old and still requested, and 2005 (also called 2005.1), which is the current one and the one that carries classification properly. Ask which one; do not assume.
BMEcat also distinguishes a full catalog from an update: T_NEW_CATALOG
replaces everything, T_UPDATE_PRODUCTS changes articles, T_UPDATE_PRICES
changes only prices. Sending a full catalog when the customer expected a price
update replaces their whole assortment, including the articles their buyers had
in saved lists.
Datanorm
Datanorm is older, simpler, and completely unlike BMEcat: fixed-width text records rather than XML, defined by the German building-trades associations, and built for Handwerker software running on a laptop in a van.
What matters about it in practice:
- It is record-based. Article records, price records, discount-group records, long-text records — each a line with fixed positions. There is no nesting and no repetition.
- It has almost no media and no classification. Datanorm describes an article well enough to order and invoice it, not well enough to shop for it.
- Discount groups are central. The trades price by Rabattgruppe applied to a list price, and Datanorm carries that structure natively where BMEcat carries net prices. This is a real modelling difference, not a formatting one — see Price lists.
- Versions matter and are not compatible. Datanorm 4 and 5 are both live; ask.
If your customers are Elektro-, Sanitär- or Heizungsbetriebe, Datanorm is not legacy. It is what their software reads, and it will still be what their software reads in ten years.
The customer-specific Excel
Most requests start here, and many should stay here. A small customer with no procurement system wants a spreadsheet: article number, description, their price, their unit.
Handle it as a profile rather than as a favour:
- Give it a name and an owner — the customer.
- Fix the columns and their order in the profile, not in whoever exports it.
- Fix the assortment and the price basis — this customer's negotiated prices, their agreed articles, their currency.
- Put it on a schedule if they want it regularly, and deliver it the same way every time.
The moment a spreadsheet export is generated by hand, it will eventually be generated with last quarter's prices by someone covering for a holiday.
Punchout removes the need — mostly
If a customer sets up punchout, they stop needing a catalog file. Their buyer clicks through from their own procurement system into your live shop, with their assortment and their prices, and returns with a filled basket. Nothing is exported, nothing is stale, and the whole class of "the price in the catalog is from March" problems disappears.
That is the better arrangement, and it is why punchout is worth pushing for. But "mostly" is doing real work in that heading:
- Their approval and reporting layer still wants classification. The order data flowing back carries the class, and their spend reporting needs it.
- Some categories are still uploaded. Many customers punch out for technical goods and upload a static catalog for high-volume C-parts, because their buyers order those without looking.
- Not every system supports it, and not every buyer is allowed to leave their own environment.
- Marketplaces are catalog uploads by another name. Mercateo, Amazon Business and dealer portals all want a feed, and it is usually a BMEcat or a format one step away from it. See Sell through marketplaces and channels.
How this works in the Revenue Cloud
- Exports are profiles, not scripts: a format, a channel, an assortment, a price basis, a language set and a schedule. See Catalog export profiles.
- The channel decides the content. An export channel is a distinct cut of the catalog, with its own scoped attribute values and its own completeness measure.
- Classification travels with the export where the format supports it.
- Delivery is part of the profile — download, SFTP drop, or upload to the customer's portal. See SFTP and file exchange.