EU Product Identifiers Become Mandatory Nov. 1

The European Commission's Product Identifier mandate goes live on November 1, 2026, and the carriers your shippers depend on are not treating it as one deadline. FedEx has already set its own cutoff five days earlier, UPS pushed its enforcement to the EU's own date, and at least one widely used shipping platform is still listing its DHL Express support as "in development." If your team ships B2C parcels into the EU from outside the bloc and your integration doesn't carry the right fields by next week, you're looking at held shipments, not a warning email.

What changes on November 1

From November 1, 2026, every item in a B2C parcel imported into the EU needs a Product Identifier (PID) on its customs declaration. EU customs requires product identifiers for each item in a qualifying non-B2B shipment, regardless of the shipment's value, and without this information, customs can delay, hold, or return the package, even though most affected shipments fall under €150. The legal basis is Delegated Regulation (EU) 2026/1022, and the requirement has been running on a soft-launch basis since summer: from July 1 onward, all B2C shipments imported into the EU should include three Product Identifiers for each individual product, remaining voluntary until November 1, 2026, when the requirement becomes mandatory.

B2B shipments are out of scope. PIDs only apply to distance sale B2C shipments and are not required for B2B VAT registered recipients in the destination country. For anyone processing EDIFACT declarations, note that this sits on top of specific message types: product identifiers are required on H1, H6, and H7 declarations.

Three codes, three different jobs

Think of this as a new mandatory payload field, not a paperwork tweak. The Commission defines three identifiers, and two of them are non-negotiable on every line item:

• M-PID: your own SKU or product code. Your own SKU or product code used to identify the product in your catalogue. Mandatory on every item.
• NS-PID: the model, part or style number assigned by the manufacturer. Also mandatory.
• S-PID: a globally recognised identifier such as a GTIN, EAN, UPC or ISBN, where available. Mandatory only when it exists.

What happens when no barcode exists is where platforms diverge. Most customs code lists use an exception code: if a globally recognized retail barcode exists, declare it as the S-PID under code C129; if no barcode exists, declare exception code Y081. FedEx does it differently on its own commercial invoice fields: if the S-PID is non-existent write "NO" and never leave this field blank when using FedEx automated tools or on your Commercial Invoice. If your integration logic was built to treat a blank field as "no data," check it this week.

Carriers are not all enforcing on the same day

On the Shippo side, the staged approach is explicit: until November 1, 2026, missing sku_code or manufacturer_code results in a warning only, shipments can still be created and labels purchased, but from November 1, shipments to EU destinations require sku_code and manufacturer_code on every customs item, and label purchases with some carriers will fail when these values are missing. FedEx's own timeline runs a few days ahead of the EU's date: PID fields will be mandatory from October 26, 2026, while recipient email will also be mandatory on FedEx Ship Manager at fedex.com and FedEx API from November 1.

DHL Express is the carrier worth double-checking directly with your account team. On the carrier's own EDI side, things look ready: DHL has updated its Global EDI messages, IFTMIN D01B v3, to support the inclusion of EUCR Product Identifiers in shipment data. But if you route DHL Express through a multi-carrier shipping platform rather than DHL's EDI directly, check your vendor's status specifically. Linnworks, for instance, states that product identifier support is currently in development for the DHL Express integration, with the required specifications received from the carrier and work ongoing to add support for ItemSku, NonStandardMidCode and ProductMidCode. A carrier being ready doesn't mean the layer you integrate through is.

The field-name problem

Every platform names these three fields differently, which is the part that actually eats engineering time:

• Shippo: manufacturer_code, manufacturer_standard_code, and eu_exempt_category on customs items, alongside sku_code.
• EasyPost: customs_items.code, customs_items.manufacturer_product_id, and customs_items.standardized_product_id.
• Linnworks: ItemSku for M-PID, NonStandardMidCode for NS-PID, and ProductMidCode for S-PID, used as item extended properties.
• FedEx: no separate API fields at all. PIDs get identified using the proper header (M-PID; NS-PID; S-PID) followed by the respective code, appended directly into the item description string.

If your team maintains direct connections to five or six carriers, that's five or six different mapping jobs against your ERP's product master, on a deadline that's already passed for one of them. This is the exact maintenance burden that pushes shippers toward a TMS with carrier connectivity built in, such as Cargoson, or toward aggregator layers like Shippo, EasyPost or nShift that absorb the field-mapping work centrally rather than leaving it to whoever last touched your FedEx integration.

What to do before next week

1. Pull your product master and confirm every active SKU has a manufacturer code captured somewhere, not just your own internal SKU. Most ERPs don't store this as a distinct field today.
2. Test each carrier's sandbox for the actual field name, not the name used in their marketing PDF. They don't match EasyPost's or Shippo's naming, and they don't match each other.
3. Decide how you'll handle the no-barcode case per carrier: exception code Y081 for standard customs code lists, literal "NO" text for FedEx.
4. If you file EDIFACT declarations, confirm your message version supports the new segments, the way DHL's IFTMIN D01B v3 now does.
5. If you route through a multi-carrier platform, get your vendor's DHL Express (or other laggard carrier) rollout date in writing rather than assuming parity with FedEx and UPS.

This is the second EU data mandate in five months, following July's shift from a blanket de minimis exemption to item-level duty. The pattern holds: EU customs is moving from parcel-level declarations toward structured, product-level data, and the carriers that build this once into a clean API field will cause you far less pain than the ones still bolting it onto a description string.