Why distributor portals reject product-data files — and what the error report actually means

A distributor’s rejection of product data usually means that the submitted file failed a defined validation rule. The error report is not a subjective review of the catalog. It is a technical diagnostic that identifies problems such as malformed XML, missing mandatory fields, invalid identifiers, unsupported classification values, or incomplete product relationships.

The most efficient response is to fix errors in dependency order. A portal cannot reliably assess attribute completeness if it cannot first parse the file. Likewise, a technically complete record may still fail if its GTIN, packaging hierarchy, or ETIM class is invalid.

Structural validation and schema failures

Most distributor portals and data pools start with automated validation. Before they assess descriptions, images, or technical specifications, they check whether the submitted file conforms to the required structure.

For BMEcat submissions, schema validation must complete without errors. Common failures include incorrect headers, missing mandatory elements, elements in the wrong XSD order, empty optional elements, unescaped ampersands, and malformed opening or closing tags. These are structural failures: the receiving system may be unable to read the document beyond the point where the error occurs.

An XML export can therefore appear acceptable in a spreadsheet view while failing at upload. For example, a product description containing an unescaped ampersand can make the XML malformed. The issue is not the wording of the description; it is that the character breaks the document syntax.

Portal checks also go beyond confirming that a field contains a value. Validation can assess file structure, columns, data types, required fields, formats, and business-consistency rules. A template may be rejected when rows are empty, tabs or columns have been reordered or altered, brand names are inconsistent, or a brand has not been declared.

A useful way to interpret the report is to separate four kinds of failure:

Schema or header errors: the file does not match the required document profile.
Missing mandatory fields: a required element, column, or value is absent.
Format errors: the field exists, but the value has the wrong type, length, structure, or permitted format.
Business-rule errors: individual values may be valid in isolation but are inconsistent when evaluated together.

In the FAB-DIS workflow, the detailed report locates an error by details such as block, brand, commercial reference, row, field, check statement, and erroneous value. An orange Anomaly(ies) status means corrections are still required; a green Compliant status permits the compliance report to be downloaded and the file to be shared. A compliance number is issued only when there are no blocking errors and must be renewed when the file is updated.

The practical lesson is simple: repair structural errors before investigating content quality. Until the validator can parse and interpret the entire file, later-stage errors may be incomplete or misleading.

Missing identifiers and broken hierarchies

Once the file structure passes, the distributor validates the entities and relationships within it. This is where a distributor’s rejection of product data often reflects a broken data model rather than a weak product description.

The portal must be able to identify the supplying organisation. In 2BA communication, a Global Location Number, or GLN, identifies an organisation as a legal and functional entity. The supplier identity must connect correctly to the account and profile used for the submission.

At product level, identifiers determine whether a record can be processed commercially. Sonepar’s supplier guidance makes the Supplier Product ID mandatory and states that a product cannot be onboarded without it. It also prefers GTINs and requires them in specified commerce-connector and configurator scenarios. Sonepar’s product-data guidelines require unique identifiers at every packaging level; a GTIN can contain no more than 14 digits, must have a valid check digit, and must be unique for the relevant product and packaging level.

The distinction between a product and an orderable trade item is crucial. A product record holds the core manufacturer information: classification, technical attributes, assets, and product descriptions. Trade-item records define the orderable forms of that product, including packaging levels and commercial identifiers.

Every packaging form needs its own GTIN and article code in the 2BA model, and the relationship between products and trade items is expected to be complete. If the base unit, inner pack, carton, or pallet is missing a link, duplicated, or attached to the wrong parent record, the distributor cannot establish what the customer can order.

This matters because wholesalers may use the manufacturer’s classified product data and assets as a baseline, then add their own commercial trade data, including gross price, packaging unit, and GTIN. A broken relationship in the source data can prevent those downstream commercial records from being attached correctly.

When an identifier error appears in a portal log, check these points before changing descriptive content:

Is the supplier identifier associated with the correct legal entity and portal account?
Does every product have its required supplier product ID?
Are GTINs valid, unique, and assigned to the correct packaging level?
Does every orderable item link to the intended base product?
Are pack quantities and units consistent with the stated trade-item hierarchy?

Classification errors and missing features

Classification errors are often harder to resolve because a value may look reasonable to a person while remaining invalid for the product class selected by the validator.

The ETIM model consists of six entities: product groups, product classes, synonyms, features, values, and units. ETIM uses two classification levels—product groups and product classes—and each product class belongs to exactly one product group. The selected class determines the technical feature set available for a product.

That class-first structure is important. A supplier cannot reliably enrich a product until it has established the correct class and the features, values, units, identifiers, and media slots associated with that class. If a product is assigned to the wrong class, otherwise accurate attributes can fail validation because they are not permitted in that class.

ETIM defines four feature types:

Alphanumeric list values
Logic values
Numeric single values
Numeric ranges

Alphanumeric values must come from the fixed allowed-value list for the relevant class. Numeric values and numeric ranges normally require a unit. ETIM classes, features, values, and units use language-independent unique identifiers, while their labels and descriptions vary by language. ETIM’s model documentation explains why sending a translated label instead of an expected identifier can trigger an invalid-value error.

For example, a free-text material description may be understandable to a human reviewer but unacceptable if the class requires one of its predefined list values. Similarly, a numeric measurement without a required unit may fail even though the number itself is correct.

The transport format must also match the recipient’s requirements. BMEcat 2005.2 accommodates both ECLASS-x.y and ETIM-x.y classification-system names, meaning the container can support either classification approach.

ETIM xChange provides a JSON-based route for product-master-data exchange. ETIM International released ETIM xChange 1.0 on 19 February 2024 and published field mappings to ETIM BMEcat where mapping is possible. ETIM International’s announcement presents it as an additional exchange format, not evidence that every recipient has stopped accepting BMEcat.

The correct approach is to confirm the receiving portal’s accepted profile and version. A generic assumption that the newest format is always accepted can itself lead to a distributor rejecting product data.

When a valid file still falls short

A file can pass schema, identifier, and classification checks while still falling short of a data pool’s content expectations. This is different from a parsing failure. The file may be technically ingestible, but the product record may have insufficient attributes, assets, documentation, or freshness for the intended channel.

EDATA holds master data including product codes, descriptions, GTINs, marketing bullets, order units, images, datasheets, certificates, and manuals. It also supports ETIM-based technical specifications, packaging and volumetric data, packaging-material breakdowns, and sustainability information such as embodied-carbon, recyclability, WEEE, RoHS, REACH, energy-efficiency, and battery data.

EDATA grades records as In Development, Bronze, Silver, or Gold according to the data provided. Manufacturer-level scoring also considers criteria including data freshness, while the dashboard shows product counts, the date a range was last updated, and field-population metrics. EDATA’s FAQ makes clear that data quality is an ongoing operational measure.

There is no verified sector-wide completeness threshold that applies to every distributor, product family, or market. A quality score, a compliant import, and a commercial listing decision are not necessarily the same thing. Suppliers should obtain the target distributor’s current requirements for the relevant product category rather than rely on a universal percentage.

Completeness also does not mean placing every available attribute in every storefront view. Sonepar advises suppliers to publish no more than three to four variant groups per product and to select ETIM features customers use for filtering. Its supplier guidance supports a distinction between complete source data and curated shopper-facing content.

The same applies to assets. Sonepar treats a primary image and product or compliance documentation as requirements for all products, while richer media such as videos, multiple views, 360-degree views, and detail shots are prioritised for core or fast-moving products. Its minimum online image size is 1000 × 1000 pixels, and its recommended size is 2000 × 2000 pixels. Sonepar’s guidance therefore points to a media-priority model rather than a maximum-media requirement for every SKU.

How to resolve a distributor product-data rejection

Use the error report as a structured work queue, not as a single undifferentiated list of defects. Start by retaining the submitted file, the report, and the portal’s stated format or profile. This makes it possible to compare the next validation result with the original one and to establish whether a correction fixed the underlying cause or only changed the reported symptom.

Confirm the accepted format and version. Check the portal’s schema, profile, classification release, and transport requirements. A BMEcat file can be structurally valid for one profile while still using a version, field mapping, or local extension the recipient does not accept.
Repair structural errors first. Fix malformed XML, headers, mandatory elements, field order, and invalid characters. Do not work around spreadsheet-template errors by manually deleting columns, tabs, or apparently blank rows: altered, missing, reordered, or added columns and tabs can trigger anomalies. Address blocking items before treating completeness suggestions as a release decision.
Group repeated errors by their cause. Use the detailed report’s block, row, field, check statement, and erroneous-value information to identify common patterns. If the same check fails across a range, review the export mapping, controlled-value table, or source-system rule before correcting individual records. This is usually more reliable than editing one rejected row at a time.
Validate supplier and product identifiers. Check GLNs, supplier product IDs, GTINs, check digits, and packaging-level uniqueness. Then restore product-to-trade-item relationships so that every orderable form has the intended parent product and matching packaging information.
Correct classification before expanding attributes. Confirm the ETIM or eCl@ss class, then validate the applicable features, values, units, and identifiers. A missing unit or a free-text value in a controlled list is best corrected in the classification mapping rather than in a storefront description.
Address channel requirements. Add the required images, documents, technical fields, and sustainability information for the target data pool or distributor. Keep this work separate from file-validity fixes: a record can be readable and compliant with a schema while still needing richer content for a particular channel.
Validate again and review the new report. Repeated validation is a normal part of the FAB-DIS process. Correct anomalies until the status is Compliant, then share the file with distributors. A compliant result confirms that the file has cleared the portal’s blocking checks; it should not be treated as proof of a separate commercial listing decision.

A distributor’s rejection of product data becomes manageable when the team distinguishes structural failures from identifier, hierarchy, classification, and content-quality issues. Fixing the first failed dependency usually reduces the number of downstream errors and produces a clearer path to a compliant submission.

Upload your product data to identify structural, identifier, and classification issues before submission.

Why distributor portals reject product-data files — and what the error report actually means