On 1 November 2026, the European Union began requiring product identifiers in the customs data for in-scope low-value business-to-consumer imports sold through distance sales. The change creates a practical data challenge: the merchant SKU, manufacturer reference and internationally standardized identifier may live in three different systems. This guide explains the requirement, the identifiers, and the software controls a seller or platform team can put in place without confusing product-data preparation with customs filing.

The European Commission's November 2026 announcement and Dutch Customs implementation guidance are primary references. Specific shipment arrangements, customs procedures and trading-party responsibilities should always be confirmed with the relevant declarant or customs adviser.

Who is affected by the EU product identifier requirement?

The operational focus is low-value cross-border B2C e-commerce imports. The published implementation guidance describes declarations using IOSS and related arrangements, including procedure codes F48, F49 and F53. The common practical threshold is an intrinsic consignment value not exceeding EUR 150. This is not a rule requiring every company in the world to buy a PIM or obtain a new barcode for every product.

A non-EU brand selling direct to EU customers, a marketplace seller shipping through an overseas warehouse, or a platform coordinating merchant data with a shipping provider may need to provide the identifiers. Pure B2B shipments and domestic EU sales do not automatically fall into this particular low-value distance-sales customs scenario; other rules may still apply.

The important question is not simply where your company is registered. Determine whether the individual consignment and customs procedure are in scope, which party is the declarant, and what data that party requires from the seller, manufacturer and marketplace.

What are M-PID, NS-PID and S-PID?

  • M-PID, the merchant product identifier, connects a specific product or variant to its merchant or marketplace offer. It may be a seller SKU, listing reference or other platform-issued product identifier. Its owner is the merchant or selling platform, not necessarily the manufacturer.
  • NS-PID, the non-standardized manufacturer product identifier, connects the item to a manufacturer, producer or supplier reference such as a model, style or part number. It is not the same thing as an international barcode standard.
  • S-PID, the standardized manufacturer product identifier, uses a recognized standard such as GTIN/EAN/UPC or ISBN where applicable. A valid-looking numeric string is not proof that an identifier was correctly assigned to that exact product or packaging level.

For relevant declarations, the merchant and non-standard manufacturer identifiers are expected. The standardized identifier is reported where one exists; when none exists, the official customs data model provides an exception code instead of inviting a merchant to invent a number.

Dutch Customs specifies C127 for M-PID, C128 for NS-PID, C129 for S-PID where available, and Y081 when no standardized identifier exists. Those are customs reporting codes, not fields that every PIM must use internally. Your integration should translate its own data contract into the format the customs or logistics partner actually accepts.

Do businesses have to purchase new GTINs because of this rule?

Not necessarily. The Commission explains that identifiers often already exist on listings, invoices, supplier catalogs or packaging. If a product has an authentic standardized identifier, capture it from the authoritative source and validate it. If none exists, follow the relevant declaration's exception process rather than creating a fictional GTIN or recycling an unrelated product's barcode.

There is also a difference between technical validation and ownership verification. A check digit can catch certain typos; it cannot prove that a GTIN is legitimately assigned, matches the intended product, or corresponds to the correct carton or individual item. For the system design implications, see our GS1 and GTIN workflow guide.

Where should the identifiers live: Shopify, ERP, PIM or a shipping system?

Treat the identifiers as separate product attributes with explicit owners. A commerce platform may own the sales offer and variant listing reference. ERP or a supplier master may own the manufacturer's model number. A PIM or a connected source may manage approved standardized identifiers and packaging relationships. The shipment workflow should consume these approved values, not silently generate replacements.

For a multi-brand seller, manufacturers and suppliers may use inconsistent names, file formats or variant granularity. A PIM integration layer can normalize those records, retain source provenance, and surface missing information to buyers or supplier onboarding teams.

Use the following minimum product-data contract as a starting point. It is a software design example, not a legal form or a prescribed customs schema:

  • Merchant identifier: the exact offer or variant reference, merchant account, destination channel and version.
  • Manufacturer reference: supplier/manufacturer identity, model or style code, product and variant mapping, source evidence.
  • Standardized identifier: type, value, product level, verified source and an explicit 'not available' state when appropriate.
  • Shipment linkage: order item, quantity, applicable customs regime, declarant/shipping partner and the field mapping they require.
  • Audit context: who supplied or changed an identifier, when it was approved, validation results, transmission status and exception history.

This model is most useful when the identifier comes from one upstream system but must be transmitted into several downstream channels. For the wider integration pattern, read our product data syndication architecture guide.

A practical example: one product sold through two channels

Imagine a fictional manufacturer with a jacket model JKT-710 and a size-medium variant. Its manufacturer catalog holds model code JKT-710; the merchant's direct-store listing is STORE-778-M; and a second marketplace gives the same variant a different merchant offer identifier. The manufacturer has assigned a legitimate standardized product identifier to the variant, recorded in the company's controlled product data.

The product record should preserve the common manufacturer code and standardized identifier while selecting the correct merchant reference for each sale. If the merchant reference changes after a catalog migration, the product's manufacturer identity should not change just to make the declaration pass. If an identifier is missing, stop the affected order item for review or follow the applicable exception workflow.

That is why a one-time field added to a shipping form may be enough for a small seller, while a large catalog with several merchants, suppliers and fulfillment partners needs better data ownership, validation and synchronization.

Validation rules before a customs or carrier handoff

  • Determine whether this particular consignment and declaration is in scope. Do not run a blanket rule against every shipment worldwide.
  • Confirm that the merchant identifier maps to the exact product or variant sold, rather than only the generic parent product.
  • Require a manufacturer code from the appropriate source, and distinguish missing data from a supplier record that has not yet been approved.
  • Check standardized identifier syntax and, where feasible, its assigned product identity and packaging level. Do not substitute an invented code.
  • Represent an absent S-PID as an explicit, reviewable state so the applicable exception can be passed to the customs partner.
  • Validate downstream field length, supported formats, customs codes and whether the partner accepts per-item or grouped declarations.
  • Record failed submissions, rejection reasons, changed source versions, retry attempts, and final partner acknowledgement.

In systems with asynchronous shipping-label creation or marketplace acceptance, a successful API transport response is not proof that customs data was accepted. Keep the downstream transaction ID and the final state. Our product-data quality and retailer-readiness guide covers how to handle attribute exceptions with assigned owners.

What a PIM/ERP integration should and should not promise

A well-designed integration can discover which source owns each identifier, check completeness, map variants, maintain evidence and automate the handoff to a shipping or customs intermediary. It can also make exceptions visible to merchandising or operations teams instead of forcing every order to fail silently.

It cannot replace the responsibility of an economic operator, a customs broker or another authorized declarant. Nor does software engineering make a business a GS1 issuing authority. A system should support compliance processes without marketing itself as a guaranteed legal certification.

Likewise, participation in the GS1 Global Data Synchronisation Network requires a certified data pool. A custom PIM can connect to a suitable provider, but is not a GDSN-certified pool simply because it stores GTIN data. See GS1's certified data pool guidance.

What changes in 2028?

The European Commission says more comprehensive e-commerce product data requirements are planned alongside the EU Customs Data Hub in July 2028. That does not mean all of the 2028 data elements or interfaces should be treated as finalized today. Build flexible data models and configurable destination mappings, so the team can change accepted fields and validation rules when the official contracts are published.

The separate EU Digital Product Passport program also has product-category-specific timelines. Do not conflate battery passports, broader ecodesign plans, barcode adoption goals and this November 2026 customs identifier requirement into a single law affecting every product.

A focused implementation plan for cross-border sellers

  • Discovery: identify three real product variants, the source of each identifier, and one in-scope shipping/customs flow.
  • Data quality: audit missing or conflicting merchant, manufacturer and standardized codes across a representative SKU sample.
  • Mapping: document the fields needed by the specific marketplace, carrier, customs broker or platform API.
  • Controlled pilot: transmit a small set of valid records plus deliberate negative cases through a supported test flow.
  • Operations: implement exception queues, approvals, audit history, retries and outcome monitoring before expanding across the entire catalog.

Start with an existing integration if it reliably handles these cases. Custom software is most justified when multiple systems, high catalog complexity, country-specific data contracts, or recurring exceptions make the current process fragile.

How NxtHatch can help

NxtHatch can assess the data architecture and build custom product-data validation, PIM/ERP integrations, identifier management, channel mapping, controlled data delivery and operational monitoring. We start with a representative source catalog and a real destination contract, then choose configuration, supported connectors or custom engineering based on the gap.

Explore our custom PIM software development services or contact NxtHatch to review a sample catalog and EU-bound shipment workflow. For legal interpretation or declaration decisions, involve the appropriate customs adviser or authorized declarant.

Sources reviewed November 5, 2026: European Commission, Product identifiers for e-commerce imports; Dutch Customs, Including product identifiers in your e-commerce declaration; USPS, New EU Product Identifier Requirements.