EU customs identifiers on FedEx: where EORI, IOSS, and VAT shipments actually get held

The empty Recipient Customs ID field

An EU-bound FedEx shipment can be perfectly packed, perfectly labeled, with a clean commercial invoice — and still sit at customs for days because the Recipient Customs ID field on the manifest is empty or carrying the wrong identifier type.

This is one of the more consistently expensive workflow gaps we still see across eCommerce shipping infrastructure for merchants moving into the EU at meaningful volume. The carrier-side capability has been clean for years; the FedEx Ship API accepts EORI, VAT, IOSS, and TAX_ID identifiers in the right field positions, the documentation flows correctly to EU customs, and the broker handoff is well-understood. The gap sits at the eCommerce integration layer, where most multi-carrier shipping apps either treat the four identifier types as four separate fields the merchant has to populate per order, or skip the identifier handling entirely and hope customs lets the shipment through on the commercial invoice alone.

What follows is the integrator-side view on EU customs identifier handling — what each of the four identifiers actually does, where the workflow consistently breaks at scale, and what the workflow looks like when it holds up.

What the four EU customs identifiers actually do

EU customs needs to know who the buyer is in their jurisdiction’s terms. That “who” is an identifier, and which identifier each buyer needs depends on whether they’re a business, a private individual, and what value bracket the order falls into.

EORI (Economic Operators Registration and Identification number) is required for any business clearing EU customs as a commercial importer. Every EU-based business engaged in import-export has an EORI issued by their country’s customs authority; UK businesses post-Brexit have a GB-EORI for shipments into the EU. The EORI is what allows EU customs to recognize a German distributor, French wholesaler, or Dutch fulfillment partner as a legitimate commercial importer.

VAT registration number is used for VAT-registered buyers and certain B2C flows. EU businesses are VAT-registered above modest revenue thresholds. The VAT number functions as a tax identifier and, in some flows, as the customs identifier — for example, when a B2C buyer is a small VAT-registered business buying for resale.

IOSS (Import One-Stop Shop) is the EU’s scheme for low-value B2C imports. As of July 2021, the EU eliminated the €22 import-VAT exemption — every commercial good entering the EU is now subject to VAT. IOSS lets non-EU sellers register once, collect VAT at checkout, and ship into the EU on a pre-paid basis. The IOSS number on the FedEx manifest tells EU customs the VAT is collected; the shipment clears without VAT being assessed at the border. IOSS applies to consignments under €150.

TAX_ID is the fallback for jurisdictions outside the EORI / VAT / IOSS conventions — some Latin American countries, some APAC countries, and edge cases.

Where the workflow actually breaks — three failure patterns from the merchant base

Three patterns show up consistently when merchants migrate to PluginHive from other shipping apps:

1. Wrong identifier type for the buyer profile. The merchant has an IOSS number registered and configured, but the integration applies it to a B2B shipment to a German distributor — where the consignee’s EORI was the right identifier. Or the reverse: a B2C consumer order under €150 leaves with the buyer’s “TAX_ID” field populated with their personal national ID, and the seller’s IOSS number doesn’t reach the manifest at all. EU customs assesses VAT at the border, the buyer receives a “duty owed” notice, and refuses delivery. The customs side accepted the field; it just wasn’t the right field for this shipment type.

2. IOSS number scoped wrong at the integration level. IOSS lives at the seller level — one IOSS number covers all the seller’s qualifying B2C shipments into the EU under €150. Most multi-carrier apps treat it as a per-order field, asking the operations team to fill it in shipment-by-shipment. At small EU volume this works; at production volume the field gets missed on a non-trivial share of orders. Those orders pay VAT at the border that should have flowed through IOSS at checkout. The merchant pays for IOSS registration and gets a fraction of its operational value.

3. Empty Recipient Customs ID field on B2B shipments. The most common failure. The merchant ships to a German wholesale account, the integration’s checkout flow doesn’t ask the wholesale account for their EORI, and the shipment leaves with the field blank. EU customs holds the package at the border until someone provides the EORI. The merchant’s support team scrambles to extract the EORI from the buyer, often with a 24-72 hour delay. By the time customs has the identifier, the shipment has sat in limbo for days.

These three patterns aren’t edge cases. They’re recurring monthly issues for any DTC or B2B merchant doing 50+ EU-bound shipments per week.

The workflow that holds up at scale

The workflow that doesn’t break treats the four identifiers as a single Recipient Customs ID field with a type selector — EORI, VAT, IOSS, or TAX_ID — and routes the type from order context, not from per-order manual selection.

IOSS lives at the seller level, configured once in the carrier settings. Every qualifying B2C shipment under €150 destined for the EU has the IOSS number on the FedEx manifest automatically. VAT is collected at the merchant’s Shopify or WooCommerce checkout. EU buyers receive packages without surprise customs fees.

EORI lives at the buyer/account level. B2B accounts capture the recipient EORI at account setup (or post-checkout email), and every commercial shipment to that account carries the right identifier without operations team intervention.

The shipment builder picks the identifier type per route — B2B vs B2C, value above or below €150, EU vs UK vs non-EU — without asking the merchant to remember which is which. Brexit-era GB-EORI handling for UK shippers into the EU works through the same logic, with the GB-EORI on the shipper side and the buyer’s EU-EORI on the recipient side.

The fulfillment team prints labels, not customs forms.

Where this sits in the broader 2026 customs picture

EU customs identifier handling is one of the operational areas where the gap between carrier capability and eCommerce integration depth is widest. The FedEx Ship API accepts the four identifier types cleanly. EU customs processes them cleanly when they’re attached correctly. The integration layer is where most merchants still feel friction — and where the recurring “why did our EU shipment get held” support load originates.

The broader policy environment in 2026 makes this gap more visible than it was three years ago. EU customs has been increasingly electronic-first; IOSS adoption among non-EU sellers continues to grow as the €22 exemption fades from memory; Brexit-era GB-EORI requirements have stabilized into routine. The capability and the policy framework are both in place. Closing the integration-layer gap is one of the lower-cost workflow improvements available to any merchant shipping at meaningful EU volume.

EU customs identifier handling still feels like one of the under-built capability areas across Shopify and WooCommerce shipping infrastructure for cross-border DTC and B2B.

Happy to connect with anyone on the FedEx International Trade Services / EU regional partnerships side exploring EU customs-identifier workflow automation further.

This article reflects patterns observed across PluginHive’s EU-bound merchant base on FedEx. EU customs regulations and IOSS specifics evolve — verify current EU customs and member-state guidance, plus FedEx International Trade Services documentation, before commercial commitments.

PluginHive solutions for this workflow

Automate EU customs identifier handling — EORI, IOSS, VAT, TAX_ID — from within your WooCommerce or Shopify FedEx shipping setup.