Export your BMEcat XML, validate it against the ETIM XSD schema, check guideline mandatory fields for your target country, fix errors in code formats and value types, then re-validate. A clean file passes both XSD and business rule checks with zero errors.
Why validate before sending
Every time a distributor receives a BMEcat file with errors, they send it back. The rejection email arrives two to five business days later. You fix the errors, re-export, re-send. Another round of review. Another week lost. For a catalog with 5,000 products, one namespace error in the header rejects the entire file.
Validation before sending eliminates this cycle. You catch structural problems, missing fields, and data format issues before the file leaves your system. The whole process takes minutes, not weeks.
Start by running your file through the ETIM BMEcat validator to get a baseline error count. Then work through the fixes below.
Step 1: Export your BMEcat XML
Export the file from your PIM, ERP, or catalog management system. The export should produce a valid XML file with:
- A root
BMECATelement with the correct namespace - A
HEADERsection with catalog metadata, supplier info, and dates - A transaction element (
T_NEW_CATALOGorT_NEW_PRODUCTDATA) containing your products PRODUCT_FEATURESelements with ETIM class and feature data
Before running any validation, confirm the ETIM version with your trading partner. ETIM 4.0 and 5.0 use different XSD schemas and namespaces. The ETIM 5.0 namespace is https://www.etim-international.com/bmecat/50. The 4.0 namespace is https://www.etim-international.com/bmecat/40. Using the wrong namespace causes an immediate full-file rejection.
Step 2: Run XSD schema validation
XSD validation checks whether your XML file conforms to the structural rules defined by the ETIM BMEcat schema. This catches:
- Missing required elements (like SUPPLIER_PID or DESCRIPTION_SHORT)
- Elements in the wrong order
- Invalid attribute values
- Namespace mismatches
- Malformed XML syntax
Upload your file to the ETIM Schema Validator, select the correct schema version (ETIM 5.0 or 4.0), and run the check. The validator returns a list of XSD errors with line numbers.
Common XSD errors and their fixes:
| Error | Cause | Fix |
|---|---|---|
| Element not expected | Wrong element order in product | Reorder elements per XSD sequence |
| Namespace mismatch | Root namespace doesn't match schema | Update xmlns in BMECAT root element |
| Missing element | Required child element absent | Add the missing element to the parent |
| Invalid value for type | String where number expected | Fix data type in the value |
Step 3: Check guideline mandatory fields
XSD validation only enforces structural rules. The ETIM guideline adds business rules on top. These are fields that the XSD marks as optional but the ETIM data exchange guideline marks as mandatory or "promoted mandatory" (+m).
For ETIM 5.0, the guideline defines 247 element rules. 49 of those are promoted mandatory fields that the XSD alone does not enforce. On top of that, 46 rules have country-specific overrides. A field that is optional for France might be mandatory for Germany or Norway.
The fields that catch most teams off guard:
Header level: CATALOG dates (DATETIME type="catalog_date"), SUPPLIER ADDRESS, and USER_DEFINED_EXTENSIONS fields like UDX.EDXF.CATALOG_TYPE.
Product level: PRODUCT_ORDER_DETAILS (ORDER_UNIT, CONTENT_UNIT, NO_CU_PER_OU, PRICE_QUANTITY), PRODUCT_PRICE_DETAILS with valid start and end dates, and PRODUCT_LOGISTIC_DETAILS with CUSTOMS_TARIFF_NUMBER.
Country-specific: Germany (DE) requires PRODUCT_STATUS, SPECIAL_TREATMENT_CLASS, ROHS_INDICATOR, packing unit dimensions, and at least one product image (MIME code MD01). Norway requires UDX.EDXF.MIME_ORDER on every MIME entry.
Step 4: Fix structural errors
Structural errors prevent the file from parsing correctly. Fix these first.
Namespace errors. The most common. Your PIM might export with a legacy namespace or a custom one. The ETIM 5.0 file must declare xmlns="https://www.etim-international.com/bmecat/50" on the root BMECAT element.
Code format errors. ETIM class codes must be exactly EC followed by six digits. Feature codes must be EF followed by six digits. Value codes must be EV followed by six digits. Anything else fails. Common mistakes: lowercase letters (ec001049), missing leading zeros (EC1049), or extra characters (EC001049-A).
Boolean value errors. ETIM boolean features accept only true or false. Not Yes, not 1, not TRUE. This is case-sensitive.
<!-- Wrong -->
<FVALUE>Yes</FVALUE>
<FVALUE>1</FVALUE>
<!-- Right -->
<FVALUE>true</FVALUE>
Decimal separator errors. All numeric values must use a dot as the decimal separator. Comma-separated decimals like 16,5 are rejected. This applies to PRICE_AMOUNT, feature values, dimensions, and every other numeric field.
Step 5: Fix content errors
Content errors mean the file parses but the data is wrong or incomplete.
Missing FVALUE_DETAILS. When a feature value is unknown, set FVALUE to "-" and add FVALUE_DETAILS with one of: NA (not applicable), MV (missing value), or UN (unknown). Omitting FVALUE_DETAILS for a dash value triggers a warning.
Range values in a single FVALUE. If a product has a rated voltage range of 100-240V, do not write <FVALUE>100-240</FVALUE>. Use two separate FVALUE elements:
<FEATURE>
<FNAME>EF000004</FNAME>
<FVALUE>100</FVALUE>
<FVALUE>240</FVALUE>
<FUNIT>VLT</FUNIT>
</FEATURE>
DESCRIPTION_SHORT too long. The BMEcat schema allows up to 150 characters, but many receivers truncate at 80. Keep it concise. Do not repeat the manufacturer name or article number in the short description, as that is particularly penalized by the German VEG scorecard.
Price date logic. The valid_end_date must not be earlier than valid_start_date. This sounds obvious, but copy-paste errors from previous catalog cycles make it surprisingly common.
Step 6: Re-validate and send
After fixing errors, validate your ETIM BMEcat XML again. Aim for zero errors. Warnings are acceptable but should be reviewed. Common acceptable warnings include optional fields that your source data does not cover.
Once the file validates cleanly, document the validation result (product count, zero errors, warning count) and include it when you send the file to your trading partner. This saves their team from running the same checks and speeds up acceptance.
Worked example: fixing a rejected file
A manufacturer exports 2,300 products from their PIM for the German market. The distributor rejects the file. Running it through the validator reveals:
- 1 XSD error: namespace set to ETIM 4.0 but distributor requires 5.0
- 2,300 guideline errors: PRODUCT_STATUS missing on every product (mandatory for DE)
- 4,600 warnings: no product images (MIME code MD01) on any product
The namespace fix is a single find-and-replace on the root element. PRODUCT_STATUS requires adding <PRODUCT_STATUS type="new">new</PRODUCT_STATUS> to each PRODUCT_DETAILS. The image warning needs attention but is not a blocking error.
After the fixes, re-validation shows zero errors and 2,300 image warnings (which the team flags for a follow-up image upload project). The distributor accepts the file on the next submission.