Validate ETIM XML Export: A Step-by-Step Playbook
Stop ETIM XML files bouncing back. Validate structure, version, feature codes, and units before every export with this step-by-step playbook.
When a distributor ships an ETIM-classified catalog to a customer, marketplace, or data pool and it bounces back with cryptic schema errors, the root cause is almost always the same: the file was never validated against the ETIM dictionary and the container XSD before it left. A single malformed feature value, a retired class code, or a wrong unit on a numeric field can reject thousands of articles at once. Claro prevents that by keeping your ETIM data trusted as catalogs change — resolving class and feature assignments, validating exports against the declared version, and writing clean, provenance-tracked records back into your PIM or ERP before every file ships.
Run this playbook every time a file leaves your hands: after a fresh PIM export, after a supplier delivers ETIM data you intend to forward, and after any change to your classification mapping. Validate the file you are going to send, not a representative sample.
What an ETIM XML validation failure costs
A failed submission is not just an inconvenience. Retailers and data pools typically enforce strict acceptance windows. A rejected file means delayed listings, failed replenishment orders, or a missed product launch. The cost compounds when the rejection surfaces only after thousands of articles have been processed by the receiver’s ingest pipeline and then rolled back.
| Before validation | After validation with Claro |
|---|---|
| Free text 'Yellow' in alphanumeric feature causes wholesale rejection | EV code resolved before export; every value maps to a valid dictionary entry |
| Retired ETIM 7 feature slips into an ETIM 9 file undetected | Version-aware check flags retired codes against the declared release |
| Wrong unit on a numeric feature passes schema but corrupts data downstream | Unit codes checked per feature; mismatches surfaced before the file ships |
| Mandatory features missing for a class; some articles silently drop | Required-field coverage checked per class across the full catalog |
| Catalog re-exported between check and send; validation covers the wrong artifact | Validate and send the same provenance-tracked artifact every time |
Validate ETIM XML step by step
- 1Confirm the format and ETIM release
ETIM travels inside container formats such as BMEcat (with the ETIM feature extension) or ETIM xChange. Open the file and check the declared ETIM version — for example ETIM 8 or ETIM 9 — and the container version. A BMEcat 1.2 wrapper and a BMEcat 2005 wrapper expect different elements, and a receiver configured for one will reject the other. Note both versions before you continue.
- 2Validate the file is well-formed and schema-valid
First confirm the XML is well-formed: every tag closes, encoding is declared (usually UTF-8), and there are no stray characters from a CSV-to-XML conversion. Then validate it against the published XSD for your container and ETIM version. Well-formed is not the same as valid. A furniture catalog can parse cleanly yet still violate the schema because a required header block is missing.
- 3Check class and feature identifiers against the dictionary
Every article should reference a real ETIM class code (EC code) and only features (EF codes) that belong to that class in the declared release. A common failure is carrying a feature from an old release that was retired or moved. Cross-check each EC and EF against the ETIM dictionary for your declared version. An MRO supplier reclassifying valves often finds features that were valid in ETIM 7 but no longer exist in ETIM 9.
- 4Validate feature value types and value codes
ETIM features are typed: alphanumeric (a fixed list of EV value codes), logical (true or false), numeric, or range. Confirm that alphanumeric features carry a valid EV code — not free text — and that numeric features carry a number, not a string with a unit appended. Shipping the literal text ‘Yellow’ instead of the EV code for that color is one of the most frequent reasons a catalog is rejected.
- 5Verify units of measure on numeric features
Numeric features require a unit, and ETIM expects a specific unit code often aligned to standardized UN/ECE Rec 20 unit codes. Millimetres, inches, and centimetres are not interchangeable in the dictionary. A case-pack weight sent in grams against a feature that expects kilograms will pass schema validation but produce wrong data downstream, so check units even when the file looks structurally correct.
- 6Spot-check mandatory and conditional fields
Beyond the schema, most receivers enforce business rules: a description in the required language, a valid GTIN, supplier and manufacturer identifiers, and mandatory features per class. Pull a representative sample across your product range and confirm these are populated. Empty mandatory features are a top cause of partial acceptance, where some articles load and others silently drop.
- 7Diff against the last accepted export
Compare this export to the previous version the receiver accepted. Unexpected changes in class assignments, dropped features, or an unintended version bump usually signal a mapping or generation problem in your PIM. Catching classification drift here prevents shipping a regression to your customer. Claro surfaces this comparison automatically, with field-level provenance showing what changed and why.
Common pitfalls
| Pitfall | Why it slips through | What to check |
|---|---|---|
| Free text in an alphanumeric feature | It looks like a real value | Every value resolves to a valid EV code |
| Wrong unit code on a numeric feature | Schema only checks the field exists | Unit matches what the feature expects |
| Retired feature from an old release | It was valid last year | EC and EF exist in the declared ETIM version |
| Encoding mismatch | Most rows render fine | UTF-8 declared and special characters intact |
| Missing mandatory feature | Other articles load fine | Required features populated per class |
| Validated a sample, shipped the full file | Sample passed cleanly | Validate the exact artifact you are about to send |
A second trap is validating a sample rather than the shipping file. Generate, validate, and send the same artifact. If your PIM re-exports between the check and the send, you have validated nothing.
Related
Tool
ETIM BMEcat Validator
Upload a BMEcat file with ETIM features and get structure and feature errors back instantly.
Tool
ETIM xChange Validator
Check an ETIM xChange file against the expected structure before you syndicate it.
Glossary
What Is ETIM in BMEcat?
How ETIM classes and features are carried inside the BMEcat container format.
Playbook
ETIM Classification Workflow for Distributors
The upstream process that produces a clean, exportable ETIM dataset.
Guide
Classification Drift and How to Catch It
Why class and feature assignments degrade over time and how to detect it.
Playbook
Validate eCl@ss in BMEcat
The equivalent pre-flight checklist for eCl@ss-classified BMEcat files.
FAQ
What is the difference between well-formed and valid ETIM XML?
Well-formed means the XML parses: tags close, encoding is declared, and the structure is syntactically correct. Valid means it also conforms to the ETIM and container schema (XSD) and uses real class, feature, value, and unit codes. A file can be well-formed but invalid, which is why you validate against the XSD and the ETIM dictionary, not just open it in a browser.
Why does my ETIM file get rejected even though it opens fine?
Opening fine only proves it is well-formed. Rejection usually comes from schema violations, retired or wrong class and feature codes, free text where an EV value code is expected, wrong unit codes, or missing mandatory features. Run the file through XSD validation and a dictionary check for your declared ETIM version to surface these.
Which ETIM version should I export?
Export the version your receiver expects, not the newest one you have. Many data pools and customers lag behind the latest release, and sending ETIM 9 to a system configured for ETIM 8 will fail. Confirm the target version per receiver and validate against that version specifically.
Do I need to validate units separately from the schema?
Yes. The schema confirms a unit field is present and well-typed, but it does not know that a length feature should be in millimetres rather than centimetres. A wrong unit passes schema validation and corrupts data downstream, so check unit codes against what each numeric feature expects.
Can I validate just a sample of the catalog?
Use a sample to design your checks, but always validate the exact file you are about to ship. Errors often cluster in specific classes or supplier batches, so a sample can pass while the full export fails. Validate the shipping artifact end to end.
Claro
See where your catalog breaks — free
Claro runs this automatically: resolve identity, fill missing attributes, validate updates, and write clean records back into your PIM/ERP. Upload a sample supplier file for a free catalog audit.
Get a free catalog audit