Understanding EU Product Identifiers in techSHIP [Information]
Last updated: October 22, 2026
EU product identifiers provide item-level product information that participating carriers can use for qualifying business-to-consumer (B2C) shipments imported into the European Union.
Beginning with the November 1, 2026 requirements described for this initiative, you may need to provide these identifiers for individual products in shipments entering the EU from outside the EU.
This article explains the identifiers available in techSHIP, the ways you can supply them, how values from your client item catalog reach order lines, how Order Management Rules (OMR) interact with those values, and how B2B/B2C classification relates to this workflow.
Carrier and customs requirements can vary by integration and shipment. The functionality described here helps you store and prepare product identifier data in techSHIP; it does not independently determine whether your shipment is legally exempt or guarantee that a carrier will accept the shipment.
When EU Product Identifiers Apply
The business use case covered by this functionality is a business-to-consumer (B2C) shipment imported into the European Union from outside the EU. What matters is the shipment origin, destination, and recipient type, not the geographic region where your techSHIP location is hosted.
The EU product identifier requirement described for this initiative applies when all of the following conditions are met:
The shipment destination is in the European Union. The order is being shipped to an EU member state.
The shipment originates outside the European Union. Shipments moving between two EU countries are not imports for this use case.
The shipment is business-to-consumer (B2C). The recipient is acting as a consumer rather than as a qualifying business recipient.
The selected carrier integration requires the applicable product identifiers for that shipment. Specific identifier requirements, validation, limits, and transmission behavior can vary by carrier integration.
A qualifying business-to-business (B2B) shipment may fall outside the product-identifier requirement described by this initiative.
Do not classify a consumer shipment as a business shipment solely to bypass identifier requirements. Your Shipper type and Receiver type should represent the actual parties involved in the shipment.
Carrier and customs requirements can vary by shipment and integration. techSHIP helps you store and provide product identifier data, but it does not independently determine your legal eligibility for an exemption.
Product Identifiers Available in techSHIP
techSHIP uses three line-level fields for the product identifiers associated with this initiative.
Identifier | techSHIP Field | Purpose |
|---|---|---|
Merchant Product Identifier (M-PID) | SKU | Your merchant or internal product identifier. SKU already existed before this functionality. |
Non-Standardized Manufacturer Product Identifier (NS-PID) | Manufacturer Product Identifier | The manufacturer's model, part, style, or equivalent product identifier. |
Standardized Product Identifier (S-PID) | UPC | The field used for standardized identifiers such as UPC, EAN, GTIN, or ISBN. |
Manufacturer Product Identifier is not automatically derived from SKU. If the same value is valid for both fields in your business process, you can configure that mapping with an Order Management Rule, but techSHIP does not make that assumption for you.
UPC is not limited to UPC-format values for this functionality. The field represents the supported standardized product-identifier concepts, including UPC, EAN, GTIN, and ISBN.
Choose How to Supply Product Identifiers
You can use one or more sourcing strategies depending on where you maintain your product data. These strategies are alternatives that can work together; you do not need to configure all of them.
Strategy | When to Use It |
|---|---|
Client item catalog | Use your catalog when you maintain reusable identifier values for a client's SKUs and want techSHIP to fill missing order-line values from matching items. You can maintain these items manually or through spreadsheet import. |
Host System or integration | Use an upstream source when your Host System or integration already knows the correct identifier values and can supply them with the order. |
Order Management Rules (OMR) | Use OMR when you have a verified business mapping that allows you to derive or assign an identifier automatically. |
Manual order-line correction | Edit an individual order line when you need to review or correct one shipment without changing your catalog or upstream integration. |
To configure or maintain your product identifier source, use the applicable procedure:
For client-level item maintenance, see 📄 How to Manually Set Up Items for a Client [Step-by-Step Guide].
For bulk catalog maintenance, see 📄 How to Import Items for a Client from an XLSX File [Step-by-Step Guide].
For shared item maintenance across multiple clients, see 📄 Global Item Maintenance: Managing Items Across Multiple Clients [Guide].
For automated identifier assignment or B2B classification, see 📄 Setting up Order Management Rules: EU Product Identifiers and B2B Classification [Guide].
To review or correct identifiers on an individual order, see 📄 How to view and/or edit an order's packages and SKUs [Step-by-Step guide].
How Catalog Values Reach Order Lines
Your client item catalog can supply missing Manufacturer Product Identifier and UPC values to an order line when all of the following are available:
Customer items are enabled for the Location,
The order line has a usable SKU, and
A matching item belongs to the same client as the order.
Catalog matching is case-insensitive by SKU. If more than one item for the same client uses the same SKU, techSHIP selects the item with the lowest item ID. Avoid duplicate catalog SKUs when you need predictable identifier sourcing.
Each identifier is handled independently. For example, if an order line already has a UPC but has no Manufacturer Product Identifier, catalog fallback can populate only the missing manufacturer identifier while preserving the existing UPC.
When You Save a New or Changed-SKU Line
When you save an order through the order interface, a new line or a line whose SKU has changed can receive missing identifier values from its matching catalog item.
This save-stage lookup is not restricted to EU destinations. If the prerequisites are met, it can populate missing values even when the order is not being shipped to the EU.
Existing nonempty values are preserved. Changing a line's SKU does not automatically clear identifiers associated with the previous SKU, so you should review the identifiers after changing SKU.
When You Process an EU-Destination Order
When you process an order with an EU destination, techSHIP performs another catalog lookup for identifier fields that are still empty. This processing-stage fallback applies regardless of whether the order originally came from the order screen, a Host System, an API integration, or another supported import path.
This lookup occurs Before Processing-trigger Order Management Rules. It considers the destination and catalog prerequisites, but the lookup itself does not require a non-EU origin, a consumer classification, a specific carrier, or the November 1 effective date.
Catalog population is broader than carrier eligibility. An identifier can be copied onto an EU-destination order even when the shipment later falls outside a particular carrier's product-identifier requirement. Populating data and deciding whether a carrier transmits or validates that data are separate steps.
If the matching catalog item does not contain a usable value, the corresponding order-line field remains unchanged.
How Order Management Rules Affect Identifier Values
There is no permanent source hierarchy in which catalog, API, manual entry, or another source always wins. The result depends on when a value is supplied and whether a configured rule later changes it.
A typical lifecycle can include the following events:
Your Host System, integration, or manual workflow can supply a line value first. A later catalog fallback preserves that value while it remains nonempty.
An After Order Import rule can populate an empty identifier before processing-time catalog fallback. Because the field is then populated, the catalog fallback does not replace it.
The processing-time catalog fallback can populate an identifier that is still empty for an eligible EU-destination order.
A Before Processing-trigger rule runs after catalog fallback and can inspect, replace, or clear the value that is present at that time.
Because rules can intentionally overwrite fields, statements such as “API always wins,” “manual values always win,” or “the catalog always wins” are not reliable.
An unconditional OMR assignment can replace a valid identifier from another source. When your intent is only to fill missing information, configure the rule conditions so the target field is empty before assigning a value.
Catalog Fallback Is Not Synchronization
The client item catalog is a reusable fallback source, not a permanent synchronization relationship between an item and every order line that references its SKU.
Changing a catalog identifier does not automatically update an already populated order line. Existing nonempty line values remain unchanged during later catalog fallback.
Editing an identifier on an order line does not update the catalog item. Use the catalog workflow separately when you need to change the reusable value.
Clearing an order-line identifier is not a permanent suppression instruction. If the line later qualifies for processing-time catalog fallback, techSHIP can populate the empty field again.
Existing orders are not bulk-migrated or backfilled automatically. However, an older order that still has empty identifier fields can receive catalog values during a later eligible processing attempt.
The Enable International option on an item controls whether the international fields are visible in the item interface. It does not act as the switch that enables or disables catalog-to-order population, and disabling it does not delete stored Manufacturer Product Identifier or UPC values.
For the complete field reference, see 📄 Understanding International Item Fields for Customs and Compliance [Information].
Shipper and Receiver Classification
Shipper type and Receiver type are order-level classifications that help represent whether the parties involved in a shipment are acting as businesses, consumers, or another supported party type.
For the EU product-identifier use case, Receiver type is particularly important when distinguishing consumer and business shipments. You should set the classification according to the actual business relationship rather than according to which validation result you want to obtain.
If the order does not provide an explicit classification, the applicable carrier integration resolves the missing value according to its own supported defaults and configuration. Those defaults are not universal across carriers.
Other should not be used as a substitute for a known business or consumer classification when you need reliable EU shipment handling.
A Business classification is operational data, not proof of a regulatory exemption. techSHIP does not determine whether your shipment qualifies as B2B for customs or regulatory purposes.
Integration Support
Order-line identifier fields and the Client item catalog are available through the API. Use the applicable techSHIP API reference for your integration when you need implementation details by referring to: 📄 Getting started using techSHIP API [Information].
Do not assume that every Host System automatically supplies Manufacturer Product Identifier simply because the field is available in techSHIP. Your integration must map and provide the value, or you must use another supported sourcing strategy such as the client item catalog or OMR.
Identifier Presence and Carrier Acceptance
Having values in SKU, Manufacturer Product Identifier, and UPC does not by itself confirm that those values are valid for the product, required for the shipment, transmitted by the selected carrier integration, or accepted during label creation.
Carrier integrations own their own applicability, transmission rules, validation, limits, and missing-data behavior. Review 📄 techSHIP supported Carriers - Master List [Guides List] and the applicable carrier configuration documentation before relying on identifier support for a specific shipping workflow.
Once you understand your carrier's requirements, choose the identifier sourcing strategy that best matches where you maintain trusted product data, then configure the relevant catalog, integration, OMR, or order-line workflow.