You're wiring a new checkout or customs workflow when a field labelled EORI appears beside a VAT number. Both may begin with the same country prefix, and both identify a business, so it's tempting to store them in one tax_id column and move on.
That shortcut creates problems later. A VAT number belongs to the tax system, while an EORI number belongs to the customs system. A VAT lookup can support a reverse-charge decision, but it doesn't prove that the customer can lodge an import declaration. An EORI can identify the party responsible for customs activity, but it isn't evidence of VAT registration.
The practical rule is simple: treat EORI and VAT as separate identifiers, separate fields, and separate validation pipelines. That design works for B2B SaaS billing, marketplaces, fulfilment platforms, and businesses moving physical goods across the EU's external border.
Table of Contents
- The Two Identifiers Every Cross-Border Business Hits
- What an EORI Number Actually Is
- What a VAT Number Does and Does Not Cover
- EORI vs VAT in One Clear Comparison
- How to Get an EORI in the EU and the UK
- When Billing and Compliance Workflows Need Each One
- Designing the Data Model and Validation Pipeline
- Putting It All Together With a Validation API
The Two Identifiers Every Cross-Border Business Hits
A developer usually meets the distinction at an inconvenient moment. A customs broker sends a payload containing eori_number, the billing system already has vat_number, and someone asks whether the first field is just another version of the second. The team maps both values to the same customer attribute, the test order passes, and the mistake surfaces only when a declaration is rejected or a tax decision is made from the wrong record.
The identifiers serve different operational questions:
- VAT asks: Is this business registered for value-added tax, and can the transaction use the relevant VAT treatment?
- EORI asks: Which economic operator is interacting with customs for import, export, or transit activity?
The European VAT system has its roots in two directives adopted on 11 April 1967, when the European Economic Community had six members. Those directives aimed to replace national turnover taxes with a common value-added tax framework, with Member States expected to replace their general indirect-tax systems by 1 January 1970. The historical development is documented in the European Parliament briefing on the EU VAT system.
That background matters to developers because VAT identification operates in a harmonized European framework, but registration and company details remain administered by national tax authorities. EORI follows a different customs identity model, with national customs authorities assigning and maintaining the identifier while EU infrastructure supports consultation and status checks.
Production rule: Never infer customs capability from a successful VAT lookup.
A B2B SaaS platform may need only a VAT number to decide whether an invoice can use a reverse-charge treatment. A marketplace importing inventory may need an EORI for the customs party, a VAT number for tax reporting, or both, depending on the transaction and roles involved. Accounting teams also benefit from separating tax and customs records, as shown in these practical ecommerce accounting tips from Snyp.
What an EORI Number Actually Is
A shipment can have a valid VAT number and still fail a customs workflow because the customs identifier is missing or inactive. EORI means Economic Operators Registration and Identification. It is the standardized EU customs identifier for economic operators and other persons involved in customs activity. For a definition and format overview, see the EORI number glossary. The European Commission states that an EORI is mandatory for clearance of all types of customs operations in the EU customs territory, including import, export, and transit.
Customs uses the number to identify the party responsible for the interaction. That party may be a trader, importer, exporter, carrier, freight forwarder, warehouse operator, or another person involved in customs activity. A non-EU business may also need an EU EORI when it carries out customs activity through the relevant customs arrangement, including situations involving an EU indirect customs representative.
What the identifier enables
An EORI does not register a company for VAT or determine how much tax is due. It connects the operator to customs declarations and related customs processes. Customs systems use it to associate an import, export, or transit declaration with the economic operator behind the movement.
The EU customs territory uses a country prefix followed by an identifier whose detailed format varies by Member State. EU EORI numbers can contain up to 15 alphanumeric characters after the country prefix, according to the European Commission's EORI guidance. A prefix and length check therefore work as an early filter, not as proof that the record is legally valid.
An EORI has no fixed expiry date, yet it can later be invalidated, for example when the holder requests it or ceases business activity. The recorded data is retained for 10 years after invalidation, while an operator may hold only one valid EORI at a time. Store these states separately: the format looks plausible, remote status is confirmed, or the identifier was previously valid but is now inactive.
The GB and XI distinction
The UK creates a separate implementation detail. A GB EORI is used for Great Britain customs activity. Northern Ireland uses an XI-prefixed EORI under EU customs legislation. These identifiers are not interchangeable labels for one generic UK tax identity.
The UK government's EORI introduction guidance states that a GB EORI starts with GB and has 12 digits. For a VAT-registered business, its first nine digits mirror the VAT number, but VAT registration is not required to obtain a GB EORI. That relationship is jurisdiction-specific, so an application must never generate an EORI by combining a VAT prefix with a guessed suffix.
What a VAT Number Does and Does Not Cover
A VAT number is a tax registration identifier. It helps tax authorities and trading partners associate a business with VAT obligations, reporting, and transactions that may receive a particular treatment under the applicable rules.
For a B2B software company, the VAT number commonly enters the workflow when a customer requests an intra-community invoice or when the supplier assesses whether a cross-border service can use a reverse-charge treatment. For goods businesses, VAT data can also matter to import accounting, distance sales, and schemes such as OSS or IOSS. The exact result still depends on the transaction, customer status, place of supply, and local rules.
A VAT number doesn't identify the customs operator. It doesn't automatically authorize a business to lodge an import, export, or transit declaration, and a valid VAT result isn't a substitute for an EORI check. A business can have a valid VAT number while its EORI is absent, inactive, or connected to a different customs entity.
The EU VAT number glossary is useful for separating the tax identifier from the customs identifier, but your own data model must preserve that separation too.
A compact comparison
| Question | VAT number | EORI number |
|---|---|---|
| Primary purpose | VAT registration and tax treatment | Customs identification |
| Typical workflow | B2B invoicing, VAT reporting, reverse charge | Import, export, and transit clearance |
| Issuing administration | National tax authority | National customs authority |
| Cross-border role | Supports relevant intra-EU tax transactions | Identifies the customs operator across the EU customs territory |
| Validation route | Relevant VAT validation system | Relevant national or EU-supported EORI service |
| Relationship | May exist without an EORI | May exist without VAT registration |
Four mixed situations explain most implementation errors. A business can import goods without being VAT-registered, so it may need an EORI without a VAT number. A services company can be VAT-registered and never cross a customs frontier, so it may need VAT validation only. A UK business can hold a GB EORI while a Northern Ireland customs flow requires an XI EORI. A marketplace can have VAT obligations under a platform scheme while another party remains the importer of record.
The customer record should represent those realities instead of forcing every business into an artificial EORI-and-VAT pair.
EORI vs VAT in One Clear Comparison
The cleanest way to compare the two is to ask what each identifier allows a system to do. EORI identifies the operator in customs activity. VAT identifies the business in the tax system. The identifiers may appear on related commercial paperwork, but they answer different legal and operational questions.
| Dimension | EORI number | VAT number |
|---|---|---|
| Identifier owner | Economic operator or other person involved in customs activity | VAT-registered business or taxable person |
| Main scope | Import, export, and transit customs operations | VAT registration, reporting, and relevant taxable supplies |
| Issuing authority | National customs authority | National tax authority |
| Format | Country prefix with jurisdiction-specific alphanumeric structure | Country-specific VAT format |
| Geographic use | EU customs territory, subject to the applicable customs role | Relevant national and intra-EU VAT framework |
| Validation endpoint | EORI infrastructure or national customs service | Relevant VAT system, such as the applicable EU validation service |
| Status model | Valid, invalidated, or otherwise not confirmed | Valid, invalid, or unavailable response states, depending on the service |
| Lifetime | No fixed expiry date, but can be invalidated | Depends on the underlying VAT registration |
The legal distinction matters even when the business uses one provider to check both. A unified API can normalize the responses, but it shouldn't collapse the identifiers into a single status or field.
Four common mixed cases
An importer without VAT registration may still need an EORI because customs clearance concerns the movement of goods, not only VAT registration. The customs workflow should collect the EORI independently and avoid rejecting the record merely because a VAT number isn't present.
A VAT-only services trader may invoice customers in other EU countries without filing customs declarations. Its onboarding flow may require VAT validation for billing and reverse-charge logic, while an EORI field would add unnecessary friction.
A Great Britain operator with Northern Ireland activity needs jurisdiction-aware routing. A GB prefix and an XI prefix signal different customs contexts, so country and role data should accompany the raw identifier.
A marketplace or platform may collect or calculate VAT under a scheme without being the importer of record. The platform's tax role doesn't automatically make it the customs operator. Capture the EORI of the party named for the customs operation, not the identifier of whichever account happens to pay the invoice.
For every record, store the identifier type explicitly. Don't decide whether DE... is VAT or EORI from the prefix alone, because the same country prefix can occur in both systems with different formats and meanings.
How to Get an EORI in the EU and the UK
An application workflow depends on where the customs activity takes place and which authority is responsible for the operator. The important engineering assumption is not that every jurisdiction issues numbers in the same way. It is that your system should capture the authority, country context, entity name, address, and status alongside the identifier.
In the EU, the national customs authority handles EORI registration and the EU provides shared infrastructure for storing, collecting, distributing, and consulting EORI data. The operator communicates the EORI to customs when carrying out customs operations. A business should confirm the registration path with the relevant national customs authority rather than deriving the number from its VAT ID.
In the UK, the application path depends on whether the customs activity concerns Great Britain or Northern Ireland. A GB EORI belongs to the Great Britain customs context. An XI-prefixed EORI is used in the EU customs layer for relevant Northern Ireland activity. Your onboarding form should therefore ask where the customs operation occurs, not just which country appears on the company profile.
Capture the right facts
For an importer or exporter, collect the legal entity name, registered address, country of establishment, customs role, and the EORI supplied by the responsible authority. If a broker or freight forwarder is lodging the declaration, record that party's role separately from the customer's own identifier.
A B2B SaaS checkout usually shouldn't ask for an EORI merely because the customer is European. Capture a VAT number when the billing treatment requires it. A physical-goods platform should request EORI data when the customer, seller, carrier, or representative will participate in customs activity.
Don't cache an EORI forever just because it has no fixed expiry date. The number can be invalidated, and the European Commission retains the record after invalidation for audit and consultation purposes. Re-check it at a meaningful customs milestone, especially before a declaration is submitted.
The exact application channel, required evidence, and response process vary by authority. Keep those details in configuration and link your internal record to the source and time of the check rather than embedding assumptions into a single global validator.
When Billing and Compliance Workflows Need Each One
Consider a French SaaS company selling a subscription to a German business. The billing service asks for the German customer's VAT number because the invoice treatment may depend on the customer's VAT status and the nature of the service. It doesn't need the customer's EORI just because the buyer is located in another EU Member State.
The application should capture the VAT value, normalize whitespace and case, validate it through the relevant VAT system, and store the response with a timestamp. If the result supports the intended invoice treatment, the invoicing service can apply its configured tax logic. That decision should remain independent of any customs identifier.
Now consider a UK direct-to-consumer brand importing goods from China into Rotterdam. The customs workflow needs to know which operator is responsible for the customs activity. That means collecting and validating the applicable EORI before the declaration is prepared. The VAT record may also matter to the brand's tax and import-accounting process, but it doesn't replace the EORI.
Capture is not validation
Teams often treat a customer-entered field as proof because the value looks plausible. A safer workflow separates the moments:
- Capture: collect
vat_idoreori_idduring checkout, onboarding, purchase-order intake, or shipment setup. - Pre-validation: normalize case and whitespace, identify the jurisdiction, and reject obvious format errors locally.
- Remote validation: query the relevant VAT or customs service.
- Operational decision: allow invoicing, tax treatment, fulfilment, or declaration preparation only when the required identifier has the required status.
- Re-check: validate again when the transaction reaches a later compliance milestone.
A previously valid EORI can later be invalidated. That makes a single onboarding check insufficient for a shipment that may be declared later.
Keep two fields, even with matching prefixes
A workable customer or transaction object might contain:
| Field | Meaning |
|---|---|
vat_id |
The customer's VAT identifier, if relevant to the tax workflow |
eori_id |
The customs operator's EORI, if relevant to customs activity |
country_code |
Jurisdiction used for routing and interpretation |
validation_status |
Normalized result for the specific identifier |
checked_at |
Time of the latest remote or authoritative check |
source |
Service or authority that returned the result |
Prefix-and-length checks are filters, not legal validation. They can stop a VAT number from being sent to an EORI endpoint, or catch a malformed GB value, but they can't prove registration, ownership, or current status.
Designing the Data Model and Validation Pipeline
A reliable integration starts with an identifier record, not a text input. Store the raw value exactly as supplied for audit, then create a normalized value for comparison and remote requests. Keep the type explicit so a value beginning with a familiar country prefix can't move between tax and customs workflows without notice.
A durable validation row
| Field | Purpose | Example |
|---|---|---|
identifier_type |
Selects the validation pipeline | vat or eori |
country_code |
Routes jurisdiction-specific rules | GB, XI, or an EU country code |
raw_value |
Preserves the user-submitted value | Original input with spacing retained |
normalized_value |
Supports consistent checks and lookup | Uppercase value without surrounding whitespace |
syntax_status |
Records local pre-validation | pass or fail |
remote_status |
Records the authoritative response | valid, invalid, unknown, or unavailable |
checked_at |
Establishes when the result was obtained | Validation timestamp |
source |
Identifies the endpoint or service | VAT service or national EORI service |
response_reference |
Connects the result to an audit record | Provider request or response identifier |
recheck_required |
Signals that a later workflow must validate again | true before customs submission |
The syntax layer should normalize case and whitespace, then route by jurisdiction. EU EORI formats vary by Member State, and UK rules distinguish GB from XI. A valid-looking prefix can't establish that the number exists or belongs to the company making the request.
For VAT, the remote path may use the relevant EU VAT validation system. For EORI, the path may use EU-supported EORI consultation infrastructure or a national customs service. Those systems can differ in fields, availability, response structure, and handling of incomplete data, so your application should expose one internal status model rather than passing provider-specific text through every product.
Caching without losing evidence
Caching is useful, but cache policy should follow the business risk. A checkout VAT lookup may be reused briefly to avoid repeated calls while the customer edits an order. An EORI result may be retained for an operational workflow, but a shipment should still trigger a deliberate re-check when customs submission is imminent.
Record the input, normalized value, identifier type, country, endpoint, request time, response time, status, returned name and address when available, and the decision made by the calling service. If customs later asks why a shipment was released, an audit trail is more useful than a boolean called is_valid.
Teams building supplier or prospect workflows can apply the same discipline to broader enrichment systems. A practical guide to data enrichment tools for sales from looot helps frame enrichment as structured, traceable data work rather than a collection of copied fields.
Audit rule: Store what you checked, where you checked it, what came back, and which transaction used the result.
Putting It All Together With a Validation API
The common assumption is that one successful identifier lookup proves the customer is compliant. It doesn't. A VAT response proves something about the VAT record returned by the VAT system. An EORI response proves something about the customs identifier returned by the relevant customs service. Neither response should be promoted into a universal “business approved” flag.
A practical API workflow looks like this:
- Receive
vat_id,eori_id,country_code, and the transaction context. - Normalize each supplied value without overwriting the raw input.
- Run the jurisdiction-specific syntax check.
- Send VAT values to the relevant VAT service and EORI values to the appropriate customs endpoint.
- Normalize responses into shared statuses such as
valid,invalid,unknown, andunavailable. - Cache according to the workflow and log the complete decision trail.
- Return separate results so the calling service can decide whether to invoice, fulfil, or prepare a declaration.
Why a wrapper layer helps
A wrapper prevents every product team from implementing country routing, retries, timeout handling, response mapping, and audit logging independently. It also gives the application a stable contract when national services return different fields or when an external service is temporarily unavailable.
A service such as TaxID can sit at that boundary for teams that need a unified validation endpoint. It can accept the identifier and jurisdiction, route VAT and EORI checks through their appropriate systems, and return normalized results for billing or customs workflows. The implementation still needs separate fields and business decisions, even when the API surface is unified.
The REST integration pattern described in this TaxID guide to using a REST API fits naturally into checkout, onboarding, supplier approval, and shipment orchestration services.
Use this checklist before shipping the integration:
- Separate the fields: Store VAT and EORI independently.
- Route by type and jurisdiction: Never send every tax-looking value to one endpoint.
- Validate the required identifier: VAT for tax decisions, EORI for customs activity.
- Handle GB and XI explicitly: The prefix signals different customs contexts.
- Keep raw and normalized values: Preserve evidence while making lookups consistent.
- Re-check before high-risk actions: Especially before a customs declaration.
- Return actionable statuses: Let the caller distinguish invalid, unavailable, and not checked.
TaxID provides a developer-focused way to validate VAT and company identification numbers through a REST API, with normalized responses for billing and compliance workflows. If your product needs separate VAT and EORI handling without rebuilding routing, caching, and error normalization, visit TaxID and evaluate the integration against your checkout or customs flow.