There is no universal distributor data checklist — build the feed your channel actually accepts

There is no universal distributor data checklist — build the feed your channel actually accepts

Distributor product data requirements are the identifiers, classifications, technical attributes, product relationships, digital assets, and exchange rules a particular distributor or data pool expects from a supplier. There is no universal checklist that guarantees acceptance everywhere. A workable product-data feed matches the receiving channel’s required format, version, schema, validation rules, and onboarding process.

For manufacturers, the problem is usually not that product information does not exist. It is that information is spread across ERP records, spreadsheets, PDF datasheets, image libraries, and product teams. Distributor product data requirements turn those scattered sources into a structured-data task: classify each product, map the applicable attributes, connect packaging levels, provide the expected assets, and validate the output before it reaches the receiving system.

The right starting point is not a generic template. It is a documented understanding of what each target channel actually accepts.

What distributor product data requirements mean in practice

A distributor may receive data through a data pool, spreadsheet template, XML catalog, JSON payload, or direct integration. The delivery method is only one part of the requirement. The receiving organization may also define product identifiers, classification rules, permitted values, packaging relationships, image standards, documentation, and correction workflows.

In the 2BA data-pool model, manufacturers, importers, and agents are the primary source of product and trade data, ETIM technical attributes, digital assets, and product relationships. Wholesalers use that classified manufacturer data and its assets as a baseline, then add commercial trade data such as gross price, packaging unit, and GTIN.

That division matters. If the product baseline is incomplete or incorrectly structured, a downstream partner has less reliable information to build on. It also means manufacturers should separate the data they own from commercial data maintained by wholesalers.

EDATA illustrates how data quality can become visible to users of a data pool. It grades product records as In Development, Bronze, Silver, or Gold according to the data provided, while its manufacturer-level scoring also considers criteria including data freshness. Its dashboard shows product count, when a range was last updated, and field-population metrics.

Sonepar illustrates how specific distributor product data requirements can become. Its January 2025 supplier guidance makes the Supplier Product ID mandatory and states that a product cannot be onboarded without it. The guidance prefers GTIN and requires it for suppliers using commerce connectors or configurators in a Sonepar Spark webshop. It also requires GTIN uniqueness by product and packaging level, with a maximum of 14 digits and a check digit.

For 2BA communication, a Global Location Number, or GLN/GS1 address code, is required to identify an organization as a legal and functional entity.

The practical conclusion is simple: document distributor product data requirements one channel at a time. A field that is essential for one recipient may be optional, irrelevant, or differently formatted for another.

Build a channel-specific requirements matrix

A requirements matrix gives product, ecommerce, and data teams a shared view of what each recipient expects. It prevents the misleading assumption that a catalog is either universally complete or universally incomplete.

Keep confirmed requirements and open questions in separate columns. Public documentation does not always reveal the exact mandatory-field list, quality score, or publication threshold for every product family. Confirm those details with the intended distributor or data-pool contact rather than inferring them from another channel’s rules.

Use the format and version your channel accepts

Format choice is a frequent source of avoidable rework. ETIM International released ETIM xChange 1.0 on February 19, 2024, as a JSON-based format for exchanging product master data. It also published a mapping from ETIM xChange to ETIM BMEcat wherever mapping is possible.

However, the arrival of a newer format does not mean established formats have disappeared. 2BA supports ETIM xChange V2.0, ETIM xChange V1.0/V1.1 JSON, BMEcat 2005 V5.0 XML, and the older DICO SALES005 XML format. It states that DICO SALES005 is no longer being developed while still listing it as supported.

These positions are not contradictory. ETIM xChange is a newer JSON-based exchange route, while BMEcat remains part of operational support in at least some data-pool workflows. The correct choice is the format and version accepted by the receiving channel, not a generic assumption about the newest standard.

BMEcat requires disciplined XML validation

A BMEcat submission is not simply a spreadsheet saved as XML. 2BA’s BMEcat 2005 ETIM documentation requires schema validation without errors and identifies incorrect headers, missing mandatory elements, incorrect XSD order, empty optional elements, unescaped ampersands, and malformed opening or closing elements as common failures.

For example, a text value containing an ampersand must be escaped correctly in XML. Structural problems are not product-content problems, but they can stop a receiving system from processing the file. Validate against the required schema before submitting a full catalog.

Classify products before measuring completeness

A product cannot be assessed against an applicable feature set until it has been assigned to the appropriate class. ETIM has six entities: product groups, product classes, synonyms, features, values, and units. It uses two classification levels—product groups and product classes—and each product class belongs to one product group. The class defines the technical feature set that applies to the product.

This makes classification the first step in meaningful enrichment. Establish the target schema—class, required features, permitted values, units, identifiers, and media slots—before assessing or improving attribute fill rates.

A dependable workflow follows this order:

1. Identify the receiving channel and its specification.
2. Assign the product to the appropriate class.
3. Load the features and allowed values for that class.
4. Map internal source values to the target feature types and units.
5. Validate identifiers, attributes, packaging, and assets.
6. Measure completeness against the applicable schema.
7. Export in the confirmed channel format and version.

Normalize values according to ETIM rules

ETIM defines four feature types: alphanumeric list values, logic true/false values, numeric single values, and numeric ranges. Alphanumeric values must use the fixed allowed-value list associated with the class. Numeric and range values normally require a unit.

That means free text is not always suitable for a technical feature. A value may need to be selected from an allowed list, expressed with a standard unit, or split into separate fields. A product description can provide useful context, but it does not replace a missing classified attribute.

ETIM classes, features, values, and units have language-independent identifiers, while their descriptions are language-dependent. This allows the same underlying classification data to be presented in different languages without changing its technical identity.

BMEcat 2005.2 accommodates both ECLASS-x.y and ETIM-x.y classification-system names. That compatibility does not prove that a particular distributor requires a given eCl@ss version. The reviewed distributor and data-pool material operationally emphasizes ETIM, so manufacturers should confirm the required classification directly with each channel.

Validate before sharing the file

Validation should be an ongoing process rather than a final handoff. FAB-DIS provides a clear example: its Easy-Check service checks file structure and completeness, identifies blocking errors and recommended improvements, creates reports, and issues a compliance number when a file is compliant.

A FAB-DIS compliance number is issued only when a file has no blocking errors. It records the file version, validation date, and reference version, and it must be renewed for each file update.

Easy-Check validates columns, data types, formats, required fields, and business-consistency rules. The workflow is explicit: declare brands, submit a file in Checks, download the report, correct anomalies until the file is Compliant, then share the file with distributors through the portal and track downloads.

FAB-DIS can flag a brand as unrecognized or expired when templates include empty rows; when tabs or columns are altered, missing, reordered, or added; when brand names are inconsistent across tabs; or when a brand has not been declared.

Its feedback supports detailed correction. An orange “Anomaly(ies)” status indicates that correction is needed, while a green “Compliant” status allows the compliance report to be downloaded and the file to be shared. The error report has 2 tabs, including a detailed sheet locating an error by block, brand, commercial reference, row, field, check statement, and erroneous value. The compliance report has 4 tabs, including summary and detailed completeness KPIs.

FAB-DIS subscribers can run Easy-Check repeatedly without a limit on the number of checks. Regardless of the receiving system, the same operating principle applies: resolve structural and data-quality errors in a controlled internal process before treating a feed as ready for distribution.

Model packaging as trade-item data

Packaging logic is a core part of distributor product data requirements. Distributors need a reliable distinction between the underlying product and the forms in which it can be ordered, stored, priced, and delivered.

2BA’s manufacturer workflow distinguishes a product from an orderable trade item. Every packaging form needs its own GTIN and article code, and the product-to-trade-item relationship is expected to be 100% complete.

Sonepar similarly specifies unique identifiers at every packaging level, preferably GTIN, and validates GTIN format and uniqueness by product and packaging level.

For each orderable packaging level, record the identifier, packaging unit, and relationship to the underlying product. Where the channel requests them, include relevant logistics and dimensional details in the expected fields and units.

Commercial data may follow a different route from product master data. 2BA’s ICC condition message exchanges standard or customer-specific purchasing conditions, including net prices or discount codes by item group, but does not support project-specific or volume- and amount-based purchase-price agreements. It also provides webservices for direct integration between external systems and its database.

Prioritize complete and usable data

There is no verified universal completeness threshold for distributor product data requirements. The available evidence supports distributor-specific scoring, mandatory fields, and staged requirements rather than a cross-industry 80%, 90%, or 100% target.

EDATA rewards greater volumes of data and data freshness through its quality levels. Its pool holds product codes, descriptions, GTINs, marketing bullets, order units, images, datasheets, certificates, manuals, ETIM-based technical specifications, packaging and volumetric data, packaging-material breakdowns, and sustainability information. That sustainability information includes embodied carbon, recyclability, WEEE, RoHS, REACH, energy-efficiency, and battery data.

EDATA offers BMEcat XML catalog exports, individual Excel and CSV templates, a combined Master + ETIM workbook with a separate tab for each product type, APIs for individual and bulk product retrieval, and asset exports as URLs or downloadable files with an index.

Sonepar’s shopper-facing guidance focuses on relevance as well as coverage. It advises suppliers to publish no more than 3 to 4 variant groups per product and to select ETIM features customers use for filtering and expect to see.

These positions should guide prioritization:

• Complete mandatory identifiers and applicable core technical attributes first.
• Ensure packaging-level relationships are correct.
• Provide required product and compliance documentation.
• Improve secondary attributes and richer media according to product importance and channel requirements.
• Use the receiving channel’s schema and rules as the measure of readiness, not a generic percentage.

Use a media-priority model

Rich-media requirements are channel-specific. Sonepar treats a primary image and product or compliance documentation as must-haves for all products. It reserves richer media—including manuals, videos, multiple views, 360-degree views, and detail shots—for core or fast-moving products. Its minimum online image size is 1000 × 1000 pixels, and its recommendation is 2000 × 2000 pixels.

A useful asset plan separates a baseline for every active product from a richer package for priority ranges. For a channel with requirements similar to Sonepar’s, the baseline includes a usable primary image and relevant product or compliance documentation. The priority layer can include manuals, video, multiple product views, 360-degree imagery, and detail shots for core or fast-moving products.

This is a way to sequence work, not to treat long-tail products as unimportant. Start by identifying active products that do not meet the channel’s baseline. Next, identify commercially important ranges or products frequently used in online discovery, then enrich those ranges with the additional assets the channel can use. An absent primary image or missing required document should generally be resolved before a supplementary view is created for a product that already meets the baseline.

The product record and the asset record also need to remain connected. An image, manual, certificate, or other document must refer to the correct product or trade item and remain aligned when an article is replaced, packaging changes, or a document is updated. The asset reference should follow the receiving channel’s specified method, whether that is a supplied file, a URL, or another defined exchange field.

Use the requirements matrix to record the baseline by recipient: accepted image types, dimensional guidance, document categories, asset-reference method, and product-family exceptions. A data pool may hold a document type without requiring it for every SKU, while a distributor can request category-specific documentation. The available sources do not establish a universal list of mandatory documents by product category or market. Confirm those requirements with the intended recipient rather than assuming that an accepted asset type is required for every product.

The result is a practical media backlog: first close baseline gaps, then add priority assets where channel guidance supports them, and finally expand coverage across the remaining range. That is more defensible than applying the richest possible media package to every SKU regardless of its channel role.

A practical preflight process

Before preparing a full catalog feed, use a repeatable preflight process:

1. Confirm the destination specification. Record the required format, version, identifiers, classification, asset rules, and validation process.
2. Separate product and trade-item records. Link every orderable packaging form to the correct product.
3. Classify first. Assign the product class before calculating feature completeness.
4. Normalize values. Standardize permitted values, units, identifiers, and asset references.
5. Validate the structure. Check XML or JSON against the receiving schema and preserve required template structure for spreadsheet-based processes.
6. Test representative records. Include products with variants, multiple packaging levels, unusual units, documents, and incomplete legacy information.
7. Log corrections. Record the failed rule, source field, correction, owner, and preventive action.
8. Confirm the update method. Ask whether the recipient expects full-file replacement, incremental changes, or integrated updates.

The representative-record test should cover the catalog patterns most likely to expose a mapping problem. Select a product with multiple orderable packaging levels, a product with variants, an item using numeric technical features and units, and a product with images or documentation. Include a legacy record with incomplete source information if such records form part of the intended range. The aim is not to prove that a small sample looks complete; it is to test whether the proposed mapping handles difficult cases before the same logic is applied at scale.

Preflight should distinguish source-data issues from exchange-file issues. A missing technical value, incorrect product classification, or absent trade-item relationship is a product-data issue. An incorrect header, invalid XSD order, empty optional XML element, or unescaped ampersand is a file-structure issue. Both can prevent a feed from being ready, but they require different corrective actions. 2BA’s BMEcat documentation specifically identifies those structural XML errors as common failures and requires schema validation without errors.

For template-based submissions, preserve the template exactly unless the recipient instructs otherwise. FAB-DIS notes that empty rows, altered, missing, reordered, or added tabs or columns, inconsistent brand names across tabs, and undeclared brands can produce brand-related issues during validation. This is why a visually correct workbook should not be assumed to be structurally acceptable.

Keep a correction log throughout the process. For every failed check, record the rule, product or trade-item reference, source field, correction, owner, and preventive action. Where the same failure appears repeatedly, change the source-data rule or export mapping rather than repairing records one at a time. FAB-DIS’s detailed error reporting illustrates the level of traceability useful for this work: it can locate an issue by block, brand, commercial reference, row, field, check statement, and erroneous value.

Finally, repeat validation after corrections. FAB-DIS subscribers can run Easy-Check repeatedly without a limit on the number of checks, and its workflow is to correct anomalies until the file is Compliant before sharing it with distributors. A channel’s validation result should be treated as evidence that the submitted file met that validation process, not as proof of commercial listing or approval.

Frequently asked questions

What are distributor product data requirements?

They are channel-specific rules for supplying product information. They may cover file formats, versions, identifiers, classification, technical attributes, packaging relationships, images, documents, validation checks, and update processes.

Is ETIM xChange replacing BMEcat?

Not universally. ETIM xChange is a JSON-based product-master-data format, but 2BA supports ETIM xChange V2.0, ETIM xChange V1.0/V1.1, BMEcat 2005 V5.0, and DICO SALES005. Use the format and version explicitly accepted by the receiving channel.

Why did my BMEcat export fail validation?

Common causes include incorrect headers, missing mandatory elements, incorrect XSD order, empty optional elements, unescaped ampersands, and malformed opening or closing elements. The applicable schema must validate without errors.

Do distributors require a 100% spec fill rate?

There is no verified universal threshold. Some data pools use quality levels and field-population metrics, while distributor guidance can prioritize mandatory identifiers, relevant technical attributes, and shopper-facing filters. Measure completeness against the applicable product class and the target channel’s documented requirements.

How do I calculate spec fill rate?

Assign the correct classification first. Then compare populated applicable technical features with the feature set defined by that class, while separately tracking the receiving channel’s mandatory fields. Without the correct class, the denominator is unreliable.

What is the best first step?

Create a channel-specific requirements matrix. Confirm the accepted format and version, mandatory identifiers, classification, packaging relationships, asset baseline, and validation process before preparing a full feed.

Upload your product data and organize it for the next channel-specific feed.

Sources

• Step 1: Communicaton standard manufacturer
• File exchange wholesaler - 2BA
• ETIM xChange version 1.0 now available!
• BMEcat 2005 ETIM Version 5.0 - 2ba
• Specification BMEcat® 2005.2
• Step 2: Trade item information - 2ba
• www.sonepar.com
• Model information - ETIM International
• Easy-Check control and validation - FAB-DIS
• Compliance number - FAB-DIS
• FAQ - EDATA data pool