Glossary Term

VIES (VAT Information Exchange System)

The European Commission's federated lookup service for validating intra-EU VAT numbers. VIES does not hold a central database — it forwards each query to the issuing Member State's tax administration and returns the live response. Frequently confused with Peppol participant lookup; the two solve different problems.

Quick Facts

Coverage
27 EU Member States + Northern Ireland (XI)
Operator
European Commission, DG TAXUD
Interfaces
Web form, SOAP (legacy), REST/JSON (since 2023)
Legal basis
VAT Directive 2006/112/EC reverse-charge evidence
Architecture
Federated proxy — no central VAT database
Status codes
valid / invalid / MS_UNAVAILABLE / INVALID_INPUT
Not the same as
Peppol SMP / participant lookup
Consultation number
Optional proof-of-check identifier

Definition

What it is

VIES is the front door to every EU Member State's VAT registration database, plus Northern Ireland. A query consists of a country code and a VAT number (NL123456789B01, DE123456789, BE0123456789, etc.); the response is valid or invalid, plus — for most Member States — the registered business name and address. The service is operated by the European Commission's DG TAXUD and exposed under taxation-customs.ec.europa.eu/vies.

The critical implementation detail is that VIES is not a database. It is a real-time message router. When a caller asks "is BE0123456789 valid?", VIES forwards the question to the Belgian tax administration's VAT system and proxies the answer back. If Belgium's system is unavailable, VIES returns MS_UNAVAILABLE, not invalid. This single fact is the source of most VIES integration bugs.

What it is used for

VIES has one legal purpose and several practical ones.

The legal purpose is to support the reverse-charge mechanism on intra-EU B2B supplies. Under Directive 2006/112/EC, a supplier who zero-rates an intra-EU supply must hold evidence that the customer is a VAT-registered taxable person in another Member State. VIES is the authoritative evidence: a successful VIES check on the customer's VAT number, captured with a date and a confirmation reference, is what auditors expect to see in the invoice file.

The practical uses are broader:

  • Customer onboarding KYB checks in ERP, accounting, and billing systems.

  • Invoice header validation — sanity-checking the BT-31 (Seller VAT identifier) and BT-48 (Buyer VAT identifier) before issuing.

  • Fraud detection for unusual zero-rated supply patterns.

  • Address pre-fill in onboarding flows where the Member State returns business name and registered address.
  • How VIES is exposed technically

    There are three integration surfaces:

    1. The web form at europa.eu/youreurope, intended for ad-hoc human use.
    2. SOAP web service (checkVatService.wsdl) — the historical machine interface, still the most widely used.
    3. REST API — added in 2023, returns JSON, modelled on the SOAP service's response.

    The response shape is essentially: countryCode, vatNumber, requestDate, valid (boolean), name (optional), address (optional), and a requestIdentifier consultation number (optional, requested by setting requesterCountryCode and requesterVatNumber) which serves as proof of the check.

    Rate limiting is informal but real: the service has no published quota, but high-volume callers will see throttling. Production implementations cache positive results for 24 hours and negative results for shorter periods, and always treat MS_UNAVAILABLE as "retry later" rather than "customer is bad."

    VIES vs. Peppol participant lookup

    These two are routinely conflated. They are different:

  • VIES answers "is this VAT number valid for intra-EU trade?" The identifier is a VAT number; the answer is about tax registration.

  • Peppol participant lookup (via the SML / SMP chain) answers "can this business receive an e-invoice through Peppol, and if so where?" The identifier is a Peppol participant ID (often the country VAT number under scheme 9925 for Belgium, 0192 for Norway, 0184 for Denmark, etc.); the answer is about e-invoice routing.
  • A business can be valid in VIES but have no Peppol participant entry (it cannot receive structured invoices via Peppol). Conversely, a VAT number can be unregistered in VIES but the business has a Peppol participant ID under a different identifier scheme (e.g. Belgium's CBE number). Tools like PeppolReady's checker bundle both calls precisely because customers ask "is this counterparty ready for our invoice?" and need both answers.

    For ERP vendors implementing Peppol-routed e-invoicing, VIES validation is still useful — it catches typos in the buyer's VAT number before the invoice is sent — but it does not replace SMP lookup. Both checks belong in the pre-flight validation, ideally in parallel.

    Common failure modes

    VIES integration goes wrong in predictable ways:

  • Format normalisation. Spaces, dots, country prefixes (BE 0123.456.789 vs. BE0123456789) cause cache misses and false negatives.

  • Spain and Italy edge cases. Both countries return valid=true with empty name/address in many cases — name and address fields are not guaranteed to be populated. Code that requires name+address to consider the check "passed" will fail silently against valid Spanish customers.

  • Germany's special rule. Until 2007, Germany's VAT IDs did not flow into VIES; legacy systems with cached "valid" responses can still hold pre-VIES references that are no longer authoritative.

  • Northern Ireland. Post-Brexit, NI VAT numbers carry the XI prefix; Great Britain numbers (GB) are no longer in VIES at all and need a separate HMRC check.

  • Treating MS_UNAVAILABLE as failure. A common production bug: an unavailable Belgian tax system causes the ERP to block valid Belgian customers from invoicing.
  • Relation to EN 16931 and ViDA

    EN 16931 references VAT identifiers in BT-31 (seller) and BT-48 (buyer) but does not mandate VIES validation — validation is a business control, not a syntactic rule. The Peppol BIS Billing 3.0 Schematron similarly checks format but not VIES status.

    ViDA's Digital Reporting Requirements will, from July 2030, route intra-EU B2B transaction data into a central reporting system at near-real time. The reporting system implicitly relies on accurate VAT identifiers; in practice this raises the operational stake on getting VIES checks right at the point of issuance, even though the DRR specification itself does not invoke VIES as a step.

    Related Content