You've got an invoice, a supplier onboarding form, or a freight handoff in front of you, and the only thing missing is the EORI number. You know the company name. You also know the official tools don't let you search by name, which is the part most guides skip until the end.
That mismatch is the whole problem. If you've been trying to “check EORI number by company name” in HMRC or the European Commission system, you've already found the dead end. The practical fix is a two-stage workflow, first resolve the entity from documents or direct contact, then validate the candidate number in the right jurisdiction.
Table of Contents
- The EORI Number Search Problem You Face
- Official EORI Registries by Jurisdiction
- Finding the EORI Before You Validate It
- Running the Validation Against HMRC and the European Commission
- Using TaxID and Similar APIs for Production Lookups
- Common Failure Modes and How to Recover
- Putting It Together and Staying Compliant
The EORI Number Search Problem You Face
The first surprise is simple. Official public EORI tools do not work like a business directory, they are validation tools. HMRC's GB checker validates a full EORI number you already have, and the European Commission's EOS checker does the same for EU and XI numbers, not company-name discovery.
That matters because many teams approach the problem backward. A finance lead gets a supplier invoice with a company name, a customs team gets a handoff from a freight forwarder, or a developer is wiring a billing flow and wants a clean yes-or-no answer before shipping paperwork. None of those starting points contain the identifier the official registries require.
What the official tools actually do
They confirm whether an EORI is valid, and, where the holder consented, they can return the registered business name and address after you've supplied the number. That is the operational detail that trips people up. The registry is built for number-in, details-out, not name-in, number-out.
Practical rule: if you don't already have an EORI candidate, you are not doing validation yet. You are doing entity resolution.
That is why the useful mental model is closer to enriching CRM with identity resolution than to searching a public register. In production, I treat the company name as a clue, not a key. The public lookup happens only after I have turned that clue into a plausible identifier.
For a quick baseline on what an EORI is and why customs systems care about it, the plain-language glossary at TaxID's EORI number definition is a useful reference. The important point for this guide is narrower. Company name alone is never enough for the official registries, so the workflow has to start somewhere else.
Official EORI Registries by Jurisdiction
The registry you use depends on the prefix in front of the number. GB routes to HMRC's Great Britain checker, XI routes to the European Commission's EOS path, and EU member-state prefixes route there too. That split is not cosmetic. It determines whether validation succeeds at all HMRC guidance, European Commission EOS checker.
Great Britain, Northern Ireland, and the EU are not one system
HMRC's public checker validates GB EORI numbers and, when the holder has consented, can show the registered business name and address. HMRC also says that the same checker covers XI numbers and EORI numbers issued by the 27 EU member states, but that does not turn it into a company-name search. It still expects a complete EORI number as input.
The European Commission's checker follows the same model. It validates the EORI number you provide, not a business-name directory. For operational teams, that means there is no single official endpoint for “lookup by company name”, so jurisdiction routing has to happen before validation.
The reliable pattern is simple, identify the likely jurisdiction first, then validate only when the prefix and structure look plausible.
What the official tools do
If consent exists, the official systems can return the registered business name and address after the EORI is supplied. If consent does not exist, a valid number may come back with limited detail. That is a privacy rule built into the registry design, not a sign that the checker is broken.
For teams building software, the takeaway is boring but important. Do not normalize this into one global search box. Build a jurisdiction router, then point the candidate number at the correct validator. The registry is built for number-in, details-out, not name-in, number-out.
Finding the EORI Before You Validate It
The fastest way to recover an EORI from a company name is usually not a registry search. It's pulling the identifier from the paperwork that already exists, or asking the counterparty for it directly. In a SaaS billing flow, that's the same principle as resolving a customer record from an invoice address before you ever hit a tax API.
Start with the documents you already hold
Invoices, purchase orders, customs entries, freight forwarder paperwork, and carrier handoffs are the first places to check. If the business has already shipped before, the EORI is often sitting in the trade trail even if nobody remembered to surface it during onboarding. That's the cleanest path because you're recovering the exact identifier rather than inferring one.
If you use a broker or freight forwarder, check their records too. They often keep the customs-facing identifier alongside the shipment reference, and that can save a lot of back-and-forth with the counterparty. The key is to ask for the number as a trade identifier, not as a general company search.
Ask directly, then narrow with VAT
When the company name is all you have, a short direct request is usually the quickest legitimate route. A simple message asking for the EORI on invoices or customs paperwork is better than trying to reverse-engineer it from a name that may have multiple legal entities behind it. For onboarding flows, that should be a standard field, not a rescue step.
VAT can help narrow the search, especially when a business is easier to identify in a public VAT register than in customs records. If you already know the VAT number, you can route to the correct member state and validate the likely EORI candidate there. That's not the same as name search, but it often gets you close enough to recover the actual customs identifier.
If the company can't give you the EORI quickly, you probably need better onboarding, not a more clever registry query.
For a dev team, the practical order is usually: request the number, inspect trade documents, check freight records, then use VAT as a narrowing key if the jurisdiction is known. That sequence is slower than a magic company-name search, but it works in real trade workflows.
Running the Validation Against HMRC and the European Commission
Once you've got a candidate, the job changes from discovery to validation. The input format matters because the official tools are strict about jurisdiction and structure, and the wrong prefix is enough to make a valid business look invalid. In production, that's why I normalize first and validate second.
Format the identifier before you call the checker
GB numbers belong in HMRC's checker. XI numbers and EU member-state numbers belong in the European Commission path. The candidate needs its full prefix, and the structure has to look plausible before you ship it to the remote service HMRC EORI guidance, European Commission EOS checker.
If you're validating batches, HMRC's public API supports up to 10 EORI numbers per request. That's useful for supplier cleansing or onboarding queues, but it still assumes you already have the identifiers. It doesn't solve discovery, only validation HMRC EORI guidance.
Use the right validator, not the nearest one
The UK checker is for GB-prefixed numbers and the European Commission checker is for XI and EU member-state numbers. In practice, the easiest failure to avoid is sending a Northern Ireland identifier to the GB checker and then assuming the company isn't registered. That's a routing bug, not a customs finding.
For anyone wiring this into a data pipeline, the data-quality angle matters as much as the customs rule. The team at data quality best practices has a useful framing for validation systems, and the same principle applies here. Validate format locally, then validate status remotely.
If you're using a VAT record as the lead, the most common pattern is to infer the likely member state from the VAT prefix, build the candidate EORI route, and then call EOS with the full number. The remote result tells you whether the record is valid and, where consent exists, whether the registered name and address are exposed.
A working example
A French counterparty gives you a VAT number and a company name, but no EORI. You'd use the VAT information to narrow to the French jurisdiction, construct the candidate EORI format that matches that counterparty, then send the full number to the European Commission's checker. If the number is valid and consent has been given, you can confirm the registered details there European Commission EOS checker.
That's the whole move. Resolve first, validate second, and route by jurisdiction every time.
Using TaxID and Similar APIs for Production Lookups
A checkout flow cannot stop because one registry endpoint is slow or a SOAP client broke overnight. In production, the useful pattern is to separate entity resolution from jurisdiction-routed validation, then keep the registry-specific failure modes out of the application layer. A managed tax-ID service can handle format checks before the remote call, return machine-readable errors, and absorb transient registry behavior so your app does not have to.
TaxID's VAT validation API is one example of that pattern. It validates VAT numbers across 31 countries, including the 27 EU member states, the UK, Switzerland, Norway, and Australia, and it returns clean JSON with validation status, registered company name, and address when available TaxID VAT validation API. That still is not EORI discovery by company name, but it can help you resolve the business identity before you attempt the EORI step. If your workflow also needs to integrate customs data API, you still need to route the final lookup through the correct authority, because the API layer does not change the registry rules.
What matters in a production wrapper
The value sits in the control plane, not just the lookup. Country-specific format checks happen before the remote call, Redis-backed 24-hour caching speeds repeat lookups, and TaxID reports that cached requests can return in under 10ms TaxID product overview. The API also uses machine-readable errors like vat_invalid and service_unavailable, which keeps your code from parsing brittle text.
That design fits the systems people build. Stripe checkout, B2B invoicing, supplier onboarding, and KYC flows all benefit from a response model your app can route on without guesswork. For a lot of teams, the difference between an internal wrapper and a managed API is less about raw capability and more about how much error-handling code they want to own.
If you are maintaining your own SOAP wrapper today, the hidden cost is not the first integration, it is the outage handling and edge-case cleanup six months later.
There is still a place for an in-house wrapper when you have very specific compliance logic or low volume. If your team wants a simpler integration path, a managed service with predictable JSON responses and a status page is easier to fold into billing code than a brittle SOAP client. The official registries still remain the source of truth, the API just makes them usable inside real products.
For teams already validating VAT in a billing stack, the practical migration path is simple. Keep your existing flow, swap the transport layer, and preserve the same decision points in your code. The more your downstream systems depend on a clean yes-or-no answer, the more that abstraction pays for itself.
Common Failure Modes and How to Recover
The failure patterns are predictable once you've shipped this in production. The first one is obvious, a company-name-only request gets nothing back because the registry never accepted that key in the first place. The rest are more annoying because they look like system problems when they're really data problems.
The errors you'll actually see
- Incomplete company-name request, the user gave you a name but no EORI. Fix it by adding a jurisdiction filter and a required identifier step before validation.
- Wrong country prefix, the candidate is structurally fine but sent to the wrong validator. Fix it by routing GB to HMRC and XI or EU prefixes to the European Commission path.
- Name mismatch or missing details, the EORI is valid, but the name isn't returned. That usually means consent wasn't given, so treat the record as valid and cache only the status you're allowed to keep.
- Official API timeout or outage, the remote checker can't answer right now. Queue the lookup, retry with backoff, and surface a machine-readable “temporarily unavailable” state instead of failing the whole checkout.
The root cause is often not customs at all. It's that the workflow assumed name search would exist, then treated every missing record as a broken registry. In a billing system, that's how you end up blocking legitimate customers because your code couldn't distinguish missing input from failed validation.
Recovery should be explicit
HMRC's EORI guidance makes the jurisdiction split clear, and that's exactly what your recovery logic should mirror. If the prefix is wrong, reject fast. If the service is down, queue and retry. If the number is valid but the name is hidden, keep the result and move on.
For downstream operations, an ops dashboard should show the same state your code sees, not a generic error blob. That's one reason teams like machine-readable API errors, and it's also why service-resilience notes like VIES downtime resilience guidance are worth reading before you wire validation into a revenue path. The fix is always more effective when the failure mode is explicit.
Putting It Together and Staying Compliant
The clean workflow is shorter than many expect. Get the identifier from the counterparty or the trade paperwork, normalize it by prefix, route it to the right official validator, and only then store the result. If you're validating at scale, a managed API can sit in front of the official registries and make the process survivable inside checkout or onboarding.
| Stage | What you do | Tool or source | Typical outcome |
|---|---|---|---|
| Entity resolution | Ask for the identifier, inspect invoices or customs paperwork, narrow with VAT if needed | Counterparty docs, freight records, VAT records | You recover a plausible EORI candidate |
| Format normalization | Check prefix and structure before any remote call | Internal validation logic | The candidate is routed correctly |
| Official validation | Submit the full EORI to the correct registry | HMRC checker or European Commission checker | Valid, invalid, or valid with limited disclosure |
| Production hardening | Cache, retry, and surface machine-readable errors | Managed API or your own wrapper | Fewer checkout failures and cleaner ops handling |
The compliance part matters just as much as the technical one. If you store EORI data, you need a clear lawful basis, a retention rule, and an audit trail for why the record was captured. If the official validator returns a name and address only when the holder consented, don't treat hidden details like missing data in your own database.
That distinction saves teams from a lot of avoidable trouble. Your system should know whether it saw a valid EORI, whether name disclosure was allowed, and when the record was last checked. When customs asks how you validated a supplier, that audit trail is what you'll want.
If you hand this to a junior developer, the checklist is straightforward. Resolve the entity, validate by jurisdiction, store only what you're allowed to keep, and revalidate when the workflow depends on it. That's the difference between a tidy integration and one that breaks the first time a supplier enters the wrong prefix.
If you're building EORI or VAT checks into a billing flow, TaxID gives you a single API for validation, structured errors, and clean JSON responses without having to fight brittle registry behavior yourself. Visit TaxID to see how it fits into checkout, onboarding, or supplier validation when you need the lookup to work the same way every time.