What a VAT Check Returns Beyond Valid or Invalid

Most people think of a VAT check as a yes/no question: is this number registered or not. That answer is the floor. Depending on the country and the source that answers, the same check can also hand you the company's name, address, registration date, legal form, industry, and its registry code — enough to fill in a billing profile or sanity-check who you're onboarding without asking the customer to type any of it.

This guide walks through every field a validation can return, where each one actually comes from, and the three jobs the extra data does well. The scope is the EU-27 plus XI (Northern Ireland), which is what VIES covers. One thing to hold onto from the start: coverage varies by country, and richer data does not come from VIES itself.

Valid/invalid is the floor, not the ceiling

A bare VIES lookup answers one question — is this VAT ID registered right now. For a lot of use cases that is all you need. But that single boolean throws away work you've already paid for: to answer it, the system had to reach a national VAT database, and that database often knows more than "yes".

The extra fields fall into two groups, and the distinction matters for how much you can rely on them:

• What VIES can return directly — at most the registered name and address, and only where the member state chooses to expose them. Many do not, so these are frequently absent even for a perfectly valid number.
• What comes from national sources — registration date, legal form, industry, and the registry code. These are pulled from national company-registry and tax-authority systems, not from VIES. Availability and freshness differ from country to country.

So "beyond valid or invalid" is not a single richer answer. It's a spread: some numbers come back with almost nothing extra, some come back with a near-complete company profile. Treating that spread as guaranteed is the main mistake to avoid — more on that below.

The full response, field by field

Here's a live check and a realistic enriched response. It uses only the fields the API actually returns, and it deliberately shows some as null so the shape of "coverage varies" is visible rather than described.

curl https://api.vatnode.dev/v1/vat/EE100931558 \
  -H "Authorization: Bearer $VATNODE_API_KEY"

{
  "valid": true,
  "vatId": "EE100931558",
  "countryCode": "EE",
  "countryName": "Estonia",
  "companyName": "Example OÜ",
  "companyAddress": "Tartu mnt 10, 10145 Tallinn, Estonia",
  "companyRegistrationDate": "2011-03-14",
  "companyForm": "Osaühing",
  "industryDescription": "Computer programming activities",
  "registryCode": "10093155",
  "registryCodeName": "Registrikood",
  "countryVat": "standard 24%",
  "checkId": "b3f1c2a8-8f2e-4c1e-9a7d-2f0b1c9d4e55",
  "verifiedAt": "2026-08-10T09:12:00.000Z",
  "source": "national registry (EE)",
  "consultationNumber": null
}

What each field is:

• valid — the boolean floor. Everything else is context around it.
• vatId, countryCode, countryName — the identity of what you checked, normalised.
• companyName, companyAddress — the registered trader details. These may come from VIES itself where the member state provides them, or from a national source; either way they can be null.
• companyRegistrationDate — when the entity was registered. National-source data.
• companyForm — the legal form in local terms (here Osaühing, the Estonian private limited company). National-source data.
• industryDescription — a human-readable activity classification. National-source data.
• registryCode / registryCodeName — the company's identifier in its national register, and the local name of that identifier. This is distinct from the VAT ID and is what you use to look the entity up in its home registry.
• countryVat — the applicable VAT context for the country.
• checkId, verifiedAt, source — the evidence trio: your reference for this check, when it ran, and which database answered. source is VIES, CACHE, or a national registry code.
• consultationNumber — the VIES-issued reference, populated only when VIES itself answered. It's null here because a national registry answered.

Notice the pairing in this example: source is a national registry, so the richer fields are filled but consultationNumber is null. Flip that — a plain VIES answer — and you'd often see companyRegistrationDate, companyForm, and industryDescription come back null while consultationNumber is populated. The full response schema documents every field, and the audit evidence fields covers the checkId / verifiedAt / source / consultationNumber set specifically.

Where the data comes from: VIES vs national registries

Get this part right — it's the difference between an accurate mental model and an expensive assumption.

VIES is a routing layer. It forwards your query to the relevant national VAT database and reports back registration status. In some member states it also returns the registered name and address; in others it returns nothing but the boolean. That's a member-state choice, not a vatnode limitation — the official Your Europe VIES guidance and the European Commission VIES service both describe name/address as optional and country-dependent.

Registration date, legal form, industry, and registry code do not come from VIES at all. They come from national company-registry and tax-authority sources. Some countries expose a rich, well-maintained registry over an API; some expose a little; some expose nothing programmatically. So the enrichment you get for one country can look nothing like another, and that's inherent to how the underlying data is published — not something a single provider can flatten away.

The practical consequence: write your integration to treat every enrichment field as optional. A number that returns a full profile today might return a sparser one for a different country tomorrow, and both are correct results. This is the same "format valid is not registered" caution one level up — see format valid vs registered — extended to the data itself: present is not the same as complete.

Use case: onboarding autofill

The cleanest win. When a business signs up and enters its VAT ID, you can validate that number and use what comes back to pre-fill the rest of the form — legal name, address, sometimes legal form — instead of making the user retype details their tax authority already holds.

The flow is one call at the moment the VAT ID is entered:

1. User types their VAT ID.
2. You call the validation endpoint.
3. If valid is true and companyName / companyAddress are present, pre-fill the billing profile and let the user confirm or edit.
4. If those fields are null, fall back to manual entry — the number is still validated, you just didn't get the extras.

That "confirm or edit" step matters. Enrichment is reference data, not gospel; showing it as an editable default respects that the registry could be stale while still saving the user most of the typing. It also keeps a bad or outdated registry record from silently becoming your billing address.

Use case: KYB-lite / lightweight due diligence

The second job is a sanity check on who you're dealing with. When a company gives you a VAT ID, the enriched response lets you confirm the number resolves to a real registered entity, that its name matches what the customer told you, and that its legal form and industry are consistent with the relationship you're entering.

Be precise about what this is and isn't. It's KYB-lite — a fast, automated signal that feeds a Know Your Business / AML process. It is not KYB or AML on its own. Full due diligence involves beneficial-ownership checks, sanctions screening, and document verification that a VAT lookup does not perform. What VAT enrichment gives you is a cheap first filter: it flags the mismatches and the entities that don't resolve, so a human only spends time on the cases that need it.

Used that way — as the first gate feeding a real process, not as the process — it's genuinely useful. Positioned as "we do KYB via VAT lookup", it's wrong, and it will fail an actual compliance review.

Use case: data quality and keeping records current

The third job is quieter and often the highest-value one at scale: cleaning and maintaining the customer data you already have. Running your existing VAT IDs through validation surfaces numbers that no longer resolve, names that have drifted from the registry, and addresses that have moved. The registryCode gives you a stable national identifier to reconcile against, independent of the VAT ID.

Because each check carries verifiedAt and source, you also get a dated provenance for every field you refresh — you know when a value was confirmed and which database confirmed it. Store the check result rather than just the derived fields and you build a record you can defend later, the same way you would with audit evidence fields. Refresh on a cadence that fits your risk, not on every page load — the data doesn't change often enough to justify hammering the underlying sources.

What you must not assume

Four assumptions to keep out of your code and your copy:

• Not every VAT number returns full company data. Many valid numbers return the boolean and little else. Design for null.
• Enrichment does not verify or certify a company. It reports what national sources hold. A returned record is reference data, not a legal attestation that the company is trading, solvent, or who it claims to be.
• Registration date, legal form, and industry do not come from VIES. They come from national registries and are absent wherever those registries don't expose them. Don't attribute them to VIES in your UI or your logs.
• A valid VAT ID doesn't make the details current. valid: true means registered at the time of the check. The enrichment fields are only as fresh as the registry behind them.

This is general information about EU VAT and VIES, not tax or compliance advice — confirm the treatment of your own case with a qualified adviser.

FAQ

What data can you get from a VAT number?

A validation can return the company name and address (where the member state provides them via VIES) and, from national company registries where available, the registration date, legal form, and industry — plus the registry code that identifies the entity. Coverage varies by country.

Is company data available for every EU country?

No. Beyond the name and address VIES sometimes returns, the richer registry fields come from national company registry and tax-authority sources, and their coverage and detail vary by country — some expose a lot, some none.

Does a valid VAT number mean the company details are current?

No. A valid result confirms the number is registered at the time of the check; the enrichment fields are reference data whose freshness depends on the underlying registry, so treat them as a strong signal, not a legal certification.

Can I use VAT enrichment for onboarding or KYB?

Yes, as autofill and lightweight due diligence (KYB-lite) — pre-filling a billing profile or sanity-checking a company. It feeds a KYB/AML process; on its own it does not satisfy one.