Selling from the UK to the EU: Ecommerce Implementation Requirements

Choose the legal and operational route before configuring the store

This guide focuses on a UK consumer-goods retailer dispatching physical products to EU customers. It is technical and operational guidance, not tax, legal or product-compliance advice. Product category, destination country, delivery terms, marketplace involvement and stock location can change the answer; have a qualified adviser approve the route before release.

For goods leaving Great Britain, a sale to an EU customer is an export. HMRC permits zero rating only when its conditions are met and the seller obtains and retains evidence; the current notice also separates goods in Northern Ireland sent to the EU from Great Britain exports. A GB exporter normally needs a GB EORI number. HMRC: VAT Notice 703 · GOV.UK: get an EORI number

For eligible B2C consignments not exceeding €150, IOSS can collect destination VAT at checkout and report it through one import-scheme registration. The European Commission states that a taxable person not established in the EU needs an EU-established intermediary to use the import scheme. This is a VAT simplification, not a replacement for customs data, carrier transmission, product rules or records. European Commission: register for OSS and IOSS · European Commission: low-value customs formalities

Northern Ireland is not a field variation on the same rule. HMRC provides the Union OSS route for eligible distance sales of goods from Northern Ireland to EU consumers, including its €10,000 threshold explanation. If stock can dispatch from GB and NI, persist the warehouse territory against every order and route from that fact. HMRC: VAT One Stop Shop for Northern Ireland

A real WooCommerce decision: one “EU plugin” was four systems

In February 2024, Appycodes worked through EU-selling options for an established UK medical supplier running WooCommerce. The delivery record shows the business comparing an IOSS-focused extension with a heavier EU VAT plugin that also promoted VAT-number validation. In the same discussion, the team considered euro presentment through a country-pricing extension and then a custom integration to load a euro price tier from the client's inventory system.

The difficult decision was not which plugin had the longest feature list. The broader VAT plugin offered validation, but Appycodes judged it heavy for the store. The lighter IOSS route did not answer how the catalogue's approved euro prices would arrive from the ERP. Meanwhile, Stripe's ability to take euros did not establish the product price, VAT route or customs handoff. Four concerns—tax collection, B2B VAT evidence, currency presentment and source-of-truth pricing—had been compressed into one “sell to Europe” request.

The practical lesson is durable: a checkout extension should not be allowed to invent the catalogue price, infer product origin or become the only record of why VAT was charged. For B2B routes, an EU VAT number can be checked through VIES, but that result is one tax-status input rather than a complete decision about the customer or transaction. European Commission: VAT identification and VIES

The Appycodes Border Readiness Gate

Score the proposed route from 0 to 3 across five gates: 0 means unknown or contradicted, 1 means discussed, 2 means configured and 3 means demonstrated with a completed test plus owned evidence. This is an Appycodes implementation model, not a compliance certification. A zero in VAT, customs or product blocks release regardless of total.

A retailer might score Market 3, VAT 2, Customs 1, Product 0 and Operations 2: 8/15, hold. The zero is decisive. An attractive checkout cannot compensate for missing responsible-person details or an unapproved product listing. Under the EU General Product Safety Regulation, distance-sale offers in scope must visibly provide product identification, manufacturer details, the EU responsible person where required, and applicable warnings or safety information. Category-specific legislation may add more. EUR-Lex: General Product Safety Regulation, Article 19

A route table for the first implementation decision

Do not market “zero duty from the UK” as a universal rule. The UK–EU agreement provides preference only when products meet the relevant rules of origin and the claim is supported. A product bought from a third country, stored in Britain and forwarded unchanged does not become UK-originating because the parcel has a UK return address. Start from the correct commodity code, then determine the product-specific origin rule and evidence. HMRC: UK–EU product-specific rules of origin

One order needs five evidence boundaries

The storefront should collect facts; a versioned rule service should classify the route; the order should store the result. Downstream systems then add their own evidence. This prevents a later VAT-rate, catalogue or plugin change from silently rewriting the explanation for an old order.

The tax ledger needs destination VAT and reporting periods. The product master needs commodity classification, origin evidence and the product information approved for each market. The customs payload needs descriptions, quantities, values, weights and parties. The carrier needs the fields its chosen service accepts. Reconciliation joins export proof, import result, VAT return, delivery, refund and return. These records share an order ID, but none should impersonate the others.

Implement the route as data, not theme conditionals

The classifier below is intentionally conservative. It chooses a review route; it does not calculate tax or declare an order compliant. Production code should receive approved country lists, VAT rates, exclusions and effective dates from owned configuration. The important part is that dispatch territory, customer type and consignment facts are inputs, and the selected version is stored with the order.

type SaleFacts = {
  dispatchFrom: 'GB' | 'NI' | 'EU';
  customer: 'B2C' | 'B2B';
  destinationIsEU: boolean;
  intrinsicGoodsValueEUR: number;
  containsExciseGoods: boolean;
};

type TaxRoute =
  | 'IOSS_CANDIDATE'
  | 'STANDARD_IMPORT_REVIEW'
  | 'NI_UNION_OSS_REVIEW'
  | 'EU_STOCK_REVIEW'
  | 'B2B_REVIEW'
  | 'NOT_EU_ROUTE';

export function classifyEuSale(f: SaleFacts): TaxRoute {
  if (!f.destinationIsEU) return 'NOT_EU_ROUTE';
  if (f.customer === 'B2B') return 'B2B_REVIEW';
  if (f.dispatchFrom === 'NI') return 'NI_UNION_OSS_REVIEW';
  if (f.dispatchFrom === 'EU') return 'EU_STOCK_REVIEW';

  if (
    f.dispatchFrom === 'GB' &&
    f.intrinsicGoodsValueEUR <= 150 &&
    !f.containsExciseGoods
  ) {
    return 'IOSS_CANDIDATE';
  }

  return 'STANDARD_IMPORT_REVIEW';
}

// Persist the decision; never recompute an old order from today's rules.
await orders.create({
  ...basket,
  taxRoute: classifyEuSale(facts),
  taxRuleVersion: 'eu-sales-2026-09-21',
  dispatchFrom: facts.dispatchFrom,
  destinationCountry: basket.destinationCountry,
  goodsValueEUR: facts.intrinsicGoodsValueEUR,
  commoditySnapshot: basket.lines.map(({ sku, commodityCode, origin }) => ({
    sku, commodityCode, origin,
  })),
});

Build the implementation in this order:

1. Create a market-launch record. Name the EU countries, consumer or business route, dispatch warehouse, currencies, languages, returns address, payment methods and delivery promise. One approved row should be able to disable checkout for that market.
2. Complete the product master. Store the commodity code, plain-language customs description, country of origin, weight, value basis, restricted-goods flags and product-compliance artefacts per SKU. Keep evidence and approver alongside the value, not in a spreadsheet that fulfilment cannot query.
3. Design destination pricing. Decide whether a euro figure is converted live or comes from an approved price list. Then calculate tax and delivery separately. The Appycodes project record shows why an ERP euro tier and a currency plugin are different architectures.
4. Freeze the checkout decision. Save the route, rule version, VAT rate and amount, dispatch origin, importer promise, product snapshots, shipping service and customer-facing total. Never rebuild an invoice from today's catalogue.
5. Map carrier fields explicitly. Treat IOSS transmission, EORI, commodity codes, origin, values, descriptions and recipient data as a tested contract per service. Reject incomplete orders into an operator queue instead of producing a plausible label with missing facts.
6. Test a real low-risk shipment. Confirm the customer total, export event, destination clearance, absence or presence of charges, tracking, delivery and documents. A label generated in sandbox proves only that the API accepted a payload.
7. Reconcile exceptions and returns. Record rejected imports, address fixes, undelivered parcels, refunds, returned goods, replacement shipments and tax adjustments. A return crossing the border is an operational flow, not merely a refund button.

Common failure modes we design out

Also distinguish marketplace responsibility from direct-store responsibility. A marketplace may be deemed supplier for some VAT purposes, but that does not automatically move every customs, consumer, product-safety or fulfilment obligation. Record who owns each gate for the exact channel and route; do not copy settings from a marketplace account into the direct website.

What Appycodes recommends after real implementations

Our rule is to make the commercial promise only after the systems can reproduce it. The UK medical-supplier project exposed the trap: IOSS, VAT-number validation, euro pricing and the ERP catalogue looked like one feature but had different owners and failure modes. Our work with the Creoate cross-border marketplace and Easyship shipping calculators reinforces the same architecture: pricing, tax, customs and fulfilment remain explicit services joined by durable order facts. Appycodes implements these boundaries through our web and commerce engineering service.

Primary sources

• HMRC: VAT on goods exported from the UK (Notice 703)
• GOV.UK: get an EORI number
• European Commission: register for OSS and IOSS
• European Commission: low-value consignments and IOSS
• HMRC: VAT One Stop Shop for Northern Ireland
• HMRC: UK–EU product-specific rules of origin
• European Commission: VAT identification numbers and VIES
• EUR-Lex: General Product Safety Regulation

Technical and operational guidance, not legal, tax, customs, financial or product-compliance advice. Rules and carrier services change; have qualified advisers approve the route and re-check primary sources before launch.