Post-Brexit customs and IOSS for British sellers shipping to the EU

What to take away

• Seller software has to carry customs declarations, IOSS and Union One-Stop Shop logic in the same order record that already holds VAT and stock.
• A customs declaration needs a description, commodity code, value, origin, weight and the correct EORI, or the parcel stalls at the border.
• IOSS covers consignments up to EUR 150 into the EU; the Union One-Stop Shop is for sellers established in the EU or NI, not for a plain GB company.
• Rules of origin decide whether a zero-tariff claim is available, and the evidence has to sit on file, not in a help article.
• The Windsor Framework keeps Northern Ireland aligned with EU goods rules, so GB to NI movements need the XI EORI and extra data.
• Carriers and brokers consume the same fields, so a clean handoff is a data problem before it is a logistics problem.

What a customs declaration needs from a British seller's order data

A customs declaration is a structured statement of what is moving, what it is worth and where it came from. HMRC is the regulator that receives it through the customs systems.

The HMRC landing page is where the current forms, codes and notices sit, and seller software should treat it as the source of truth rather than a fixed field list.

For a British seller, the declaration is built from order data that already exists. The product title, the quantity, the unit price, the shipping charge, the buyer address and the seller identity all feed it.

What is often missing is the commodity code, the country of origin and the net weight. Those three are the usual causes of a held parcel.

The minimum set for a simple export looks like this.

• Consignor name and address, plus the EORI of the seller
• Consignee name and address, plus a contact email or phone for the EU side
• Goods description a buyer would recognise, not a marketing title
• Commodity code at six digits or more
• Country of origin for each line
• Net and gross weight, plus the number of parcels
• Declared value and currency, with the Incoterms rule

Incoterms matter because they decide who is the importer of record. DAP means the buyer pays the import VAT and duty on arrival. DDP means the seller does. A seller tool that defaults to DAP without saying so will generate complaints when the carrier invoices the buyer.

A customs declaration is not a single document any more. It is a data set that is lodged electronically, then reused by the carrier, the broker and the destination customs authority. That is why the order record has to be the single source.

If the warehouse management system holds one version and the marketplace holds another, the declaration will disagree with the parcel.

UK sellers also need to separate the export declaration from the import declaration. The export side is filed with HMRC. The import side is filed in the destination country, usually by the carrier or a fiscal representative. Seller software that only models the export half will look complete until the first EU return arrives.

The practical test is simple. Can the tool produce a declaration from an order without a human retyping the address, the value or the code? If not, the seller is paying for a form filler, not a customs engine.

Import One-Stop Shop and Union One-Stop Shop compared for UK sellers

The Import One-Stop Shop, usually shortened to IOSS, is a VAT collection scheme for distance sales of imported goods into the EU. It applies to consignments with a value up to EUR 150.

The seller charges the destination VAT at checkout, then files one monthly return through the IOSS portal. The background on how the scheme works for cross-border sales is set out in the IOSS overview.

The Union One-Stop Shop is a different scheme with a similar name. It covers intra-EU distance sales and some domestic supplies by non-established sellers. A GB company with no EU establishment cannot normally use it for goods already inside the EU unless it has registered somewhere in the Union. That distinction is the one most seller tools get wrong.

Feature	Import One-Stop Shop	Union One-Stop Shop
Main use	Imported goods up to EUR 150	Intra-EU distance sales and certain domestic supplies
Who can register	Sellers, marketplaces and intermediaries	Sellers established in the EU or NI, plus some non-established cases
VAT charged	At checkout, destination rate	At checkout, destination rate
Return	One monthly IOSS return	One periodic OSS return
Typical GB seller	Yes, for direct-to-consumer parcels	Rarely, unless established in the EU or NI

A British seller shipping from England to France will usually rely on IOSS for small parcels. A British seller with a warehouse in the Netherlands may use the Union One-Stop Shop for sales from that stock.

The two schemes can sit side by side in one business, which is why the software has to label each order with the scheme that applies.

Marketplaces complicate this. Many large marketplaces are the deemed supplier for imported goods and collect the VAT themselves. In that case the seller does not use its own IOSS number for those sales. The software has to know which channel owns the VAT, or the seller will double report.

Registration for IOSS is not automatic and not free in every member state. An intermediary can register on behalf of a non-EU seller. The intermediary then carries the filing duty. Seller software should record the intermediary identifier next to the IOSS number so the return can be reconciled.

For sellers who ship both ways, the safest design is a tax rule per order line. The rule looks at the destination, the value, the channel and the establishment of the seller. It then picks IOSS, Union One-Stop Shop, or ordinary import VAT. That rule belongs in the order pipeline, not in a spreadsheet maintained by one person.

The core customs and VAT frame for a UK business selling abroad is set out in the government guidance on buying and selling outside Great Britain. It is the right starting point before any software configuration.

Rules of origin and how preferential treatment is evidenced

Rules of origin decide the economic nationality of a good. They matter because a UK good may qualify for a reduced or zero tariff under a trade agreement, while the same good made elsewhere may not.

The Department for Business and Trade sets the trade policy and support context, and its department page is the place to check the current agreement position.

Preference is not granted automatically. The exporter has to claim it and hold evidence. For many goods the evidence is a statement on origin added to the invoice, plus records that show how the origin rule was met. That statement is a legal declaration, so the software that generates it has to know the rule for the product.

There are two common ways a product qualifies. It may be wholly obtained, which suits agricultural goods. Or it may be sufficiently worked or processed, which uses a product-specific rule. Those rules can be based on a change in tariff classification, a maximum share of non-originating materials, or a specific production step.

A seller tool should store the origin rule per product, not per order. The rule is a property of the item. The order then inherits it. When a supplier changes, the rule may change too, so the product record needs a review date.

Supplier declarations are the weak point. A UK seller buying components from abroad needs a declaration from the supplier to show the origin of those inputs. Without it, the seller cannot prove the finished good qualifies. Software can hold a supplier declaration register with expiry dates and chase the renewals.

The evidence pack for a preferential shipment normally contains the invoice with the origin statement, the supplier declarations, the bill of materials and the production records. A customs audit can ask for these years later. A tool that only prints the invoice statement and keeps nothing else is storing a claim without its proof.

For low-value parcels, the administrative cost of proving preference can exceed the duty saved. Sellers should model that trade-off. A simple threshold rule in the software, based on duty rate and consignment value, will stop the team chasing declarations that are not worth the effort.

Origin also affects the customs declaration itself. The country of origin field is not the same as the country of dispatch. A parcel sent from a Manchester warehouse may contain goods of German origin. The declaration must say Germany if that is the origin, and the preference claim must follow the same fact.

The Windsor Framework and Northern Ireland movements after Brexit

Northern Ireland sits in a unique position. Under the Windsor Framework, goods moving there from Great Britain are treated differently depending on whether they are staying in Northern Ireland or moving on to the EU. The framework replaced the older Northern Ireland Protocol arrangements and introduced green and red lanes for goods movements.

The green lane is for goods that stay in Northern Ireland. It uses a simplified process and a trusted trader scheme. The red lane is for goods at risk of entering the EU. It follows full customs controls and EU rules. The seller has to declare which lane applies before the goods move.

That decision is a data decision. The software needs to know the end use of the goods, the trader's authorisation status and the category of the product. Some goods, such as certain food and plant products, face additional checks under the framework.

A GB seller shipping to a consumer in Belfast is not the same as a GB seller shipping to a business that will onward sell into Ireland. The first may use the simplified green lane. The second is likely to need the red lane and full EU compliance.

XI EORI numbers are the identifier for this trade. An XI EORI is a Northern Ireland EORI, issued with the prefix XI. A GB seller that moves goods to or from Northern Ireland may need one in addition to its GB EORI. The number is used on declarations for those movements and is separate from the GB number.

Software has to hold both numbers and pick the right one per movement. Using a GB EORI on an NI declaration is a common error that leads to rejection. The rule should be driven by the origin and destination of the movement, not by the seller's head office address.

The framework also affects parcels sent by businesses to consumers in Northern Ireland. The arrangements have been phased, and the detail has changed more than once. Seller software should treat the rules as configurable, with effective dates, rather than hard-coded logic that ages badly.

For sellers who also trade with Ireland, the NI route can be a staging post. Goods can move to Northern Ireland under the framework and then to Ireland under EU rules. That path needs clean records at each step, because the two legs have different legal bases.

Fields seller software must encode for EU and NI shipments

Most seller tools already store the order, the customer and the payment. The customs layer adds a second set of fields. If those fields are missing, the tool cannot produce a compliant declaration, and the seller falls back to manual entry.

The core fields are these.

1. Seller legal identity, including the registered name and the EORI, with a separate XI EORI where Northern Ireland movements apply.
2. Product record with description, commodity code, country of origin, net weight and unit value.
3. Order line with quantity, line value, currency and the Incoterms rule.
4. Consignee record with address, contact details and, for business buyers, a VAT or EORI number.
5. Tax rule that selects IOSS, Union One-Stop Shop or ordinary import VAT per line.
6. Preference flag that records whether a rules of origin claim is being made, plus the evidence reference.
7. Carrier handoff record with the parcel count, gross weight and the declaration reference.

Each field needs an owner and a validation rule. A commodity code should be checked against a tariff list at the point of entry. A country of origin should be a controlled list, not free text. An EORI should be format-checked for the country prefix.

Validation is where most tools are weak. They accept any string in the origin field and any number in the weight field. The result is a declaration that passes the seller's own screen and fails at the border. A good tool blocks the order until the data is complete, or flags it for review.

The tax rule is the most complex field. It depends on the destination country, the consignment value, the sales channel and the establishment of the seller. It should be tested against known scenarios, including a EUR 150 boundary case and a marketplace deemed-supplier case.

The preference flag is often skipped because it is optional. It should not be. Even a decision not to claim preference is a decision worth recording, with the reason. That record protects the seller if a customer or an auditor asks why duty was paid.

Data protection sits alongside this. Customs data includes names, addresses and sometimes personal identifiers. The data flows mapping work that a seller does for GDPR should cover customs sharing too, because carriers and brokers are additional recipients.

Sellers mapping current UK rules onto one England orders will find the same fields reappear in VAT and consumer law, so it pays to define them once.

Before any of this is switched on, it is worth running the gate identity, orders and tax check, because customs is one more gate on the same order pipeline.

Worked example: one parcel from Manchester to Dublin

A Manchester seller of cycling accessories ships one parcel to a consumer in Dublin. The order value is EUR 120, so it falls under the IOSS threshold. The seller is a GB company with no EU establishment. The goods are made in Manchester from UK and imported components.

Step 1. The order record captures the buyer address in Ireland, the line value in euro and the shipping charge. The tax rule fires on the destination and the value, and selects IOSS. The seller's IOSS number is attached to the order.

Step 2. The product record supplies the commodity code, the net weight and the country of origin. The origin is the United Kingdom, and the seller has a supplier declaration for the imported components. The preference flag is set to claim the UK-EU agreement rate if it applies.

Step 3. The declaration is generated from the order. It includes the GB EORI of the seller, the description, the code, the value and the origin. No XI EORI is needed because the destination is Ireland, not Northern Ireland.

Step 4. The carrier receives the parcel data, including the IOSS number and the electronic declaration reference. The carrier files the import declaration in Ireland and clears the goods.

Step 5. The seller files the monthly IOSS return, reconciling the VAT collected at checkout with the orders shipped. The preference evidence stays on file in case of audit.

If the same parcel went to Belfast instead, the lane decision would change. A consumer parcel staying in Northern Ireland could use the simplified green lane. The seller would need an XI EORI for that movement, and the declaration would reference the framework arrangements rather than the EU import rules.

If the value were EUR 180, the IOSS rule would not apply. The seller would charge VAT at the Irish rate only if registered, or rely on the carrier to collect import VAT from the buyer. That is a different customer experience and a different set of fields.

Carrier data, commodity codes and declaration handoffs

The carrier is the last mile of the customs process. It needs the declaration data in a format it can accept, usually an electronic message tied to the parcel label. If the data is incomplete, the carrier either rejects the parcel or clears it with a default code, which can lead to the wrong duty.

Commodity codes are the most common handoff failure. A six-digit code is the international baseline. The EU and the UK use longer codes for duty and statistical purposes. A seller tool should store at least the six-digit code and allow the full code where the carrier requires it.

Codes change. Tariff updates happen periodically, and a code that was correct last year may be split or merged. Software should version the code list and flag products whose code has not been reviewed. A simple annual review task, driven by the product record, prevents most of these errors.

Carrier integrations vary. Some accept a full declaration message. Others accept a commercial invoice PDF and a data file. The seller tool should expose the same underlying fields in both formats, so the data is entered once. Duplicate entry is where errors multiply.

Handoff also includes the return leg. If a parcel is refused, it becomes a return import. That needs its own declaration and may attract duty relief if the goods are returned within a set period. The software should link the original export to the return so the relief can be claimed.

Finally, the seller should keep the declaration data for the retention period required by HMRC. That is usually several years. A tool that deletes old orders after twelve months will lose the evidence the seller needs. Retention rules belong in the configuration, not in the default settings.

Common questions

Do I need an IOSS number if I sell through a marketplace? Often no. Many marketplaces are the deemed supplier for imported goods and use their own IOSS number. Check the channel terms before registering, because a second number can create duplicate filings.

What is the difference between a GB EORI and an XI EORI? A GB EORI identifies a trader with the UK customs authority. An XI EORI is for Northern Ireland movements under the Windsor Framework. A seller may need both, and the software must select the right one per movement.

Can a GB company use the Union One-Stop Shop? Usually not for goods already in the EU unless it has an establishment in a member state. The Union One-Stop Shop is mainly for EU and Northern Ireland established sellers. Imported goods up to EUR 150 normally use IOSS instead.

How long do I keep rules of origin evidence? HMRC expects records to be kept for several years after the claim. The exact period depends on the agreement and the tax. Store the supplier declarations, bills of materials and invoices together so an audit can be answered quickly.

What happens if the commodity code is wrong? The parcel may be delayed, cleared at the wrong duty rate, or rejected. The seller can face corrections and penalties. Validate codes at the point of entry and review them when tariffs change.

Does the Windsor Framework change parcel rules for consumers in Northern Ireland? Yes. Consumer parcels staying in Northern Ireland can use a simplified process under the framework, while goods at risk of moving to the EU follow full controls. The rules have been phased, so check the current position before configuring the software.