VIES Consultation Number API: How to Get It Programmatically

Every EU invoicing platform calls VIES. But most only retrieve the valid/invalid result — and discard the most legally important part: the consultation number.

This guide explains what the VIES consultation number is, why EU tax authorities ask for it, and how to capture it on every validation call via API.

What Is the VIES Consultation Number?

When you submit a qualified VAT number lookup to the VIES REST API (with your own VAT number in the requesterMemberStateCode and requesterNumber fields), the European Commission's server returns a consultation number — a unique alphanumeric identifier that looks like this:

WAPIBE0516R5LO6BV

This number is generated at the exact moment of the check and records:

• The VAT number that was queried
• The result returned (valid/invalid, name, address)
• The exact timestamp of the request
• The identity of the requester

The EU Commission's own documentation describes it as the "request identifier" — and it is stored on DG TAXUD's servers. Any EU tax authority can independently verify it.

Why Does It Matter for EU B2B Invoices?

Under EU VAT rules (Directive 2006/112/EC, Article 138), zero-rated intra-Community supplies are only VAT-exempt if the buyer is a taxable person in another EU member state. The supplier must be able to prove they verified this at the time of invoicing.

During an audit, the tax authority in your country will typically ask:

1. What was the VAT number of the buyer?
2. Was it valid on the invoice date?
3. How do you prove it was valid?

The answer to #3 is the consultation number. It provides an independent, verifiable timestamp from a neutral third party (the European Commission) that the lookup happened, when it happened, and what result it returned.

The Official VIES REST API

The European Commission provides a REST API at:

https://ec.europa.eu/taxation_customs/vies/rest-api/check-vat-number

A simple (unqualified) request — no consultation number returned:

{
  "countryCode": "DE",
  "vatNumber": "123456789"
}

A qualified request — consultation number included in response:

{
  "countryCode": "DE",
  "vatNumber": "123456789",
  "requesterMemberStateCode": "NL",
  "requesterNumber": "NL000000000B01"
}

The qualified response includes a requestIdentifier field:

{
  "countryCode": "DE",
  "vatNumber": "123456789",
  "requestDate": "2026-06-17+01:00",
  "valid": true,
  "name": "Example GmbH",
  "address": "Musterstraße 1, 10115 Berlin",
  "requestIdentifier": "WAPIBE0516R5LO6BV"
}

The requestIdentifier is your consultation number.

What Goes Wrong in Practice

Despite this being a single additional field in the response, most accounting platforms and VAT validation libraries fail to capture it. Common issues:

VIES downtime is a significant real-world problem. The service runs on member-state infrastructure with no SLA. During busy periods — month-end, quarter-end — individual country endpoints regularly return errors. A robust implementation needs fallback to national registries.

Implementing It: Key Considerations

1. Always use qualified requests

You need your own VAT number to make a qualified request. Pass requesterMemberStateCode and requesterNumber on every call. If you're building for multiple companies, each company should use their own VAT number as the requester.

2. Store the requestIdentifier per transaction

Link it to the invoice: buyer VAT number, validation timestamp, requestIdentifier, and the name/address returned. Store this in your database or export it to the invoice record.

3. Handle VIES downtime with national registry fallback

When VIES returns an error, fall back to the member state's national VAT registry. Most EU countries expose their own lookup endpoint — the result won't include a VIES consultation number, but it provides a dated validation record that is still meaningful audit evidence.

4. Rate limiting and retries

VIES enforces rate limits. Implement exponential backoff with a cap. For high-volume platforms (thousands of invoices/day), cache valid results with a TTL of 24 hours — a VAT number that was valid this morning is still valid this afternoon.

Building It Yourself vs. Using an API

Building a correct VIES integration with qualified requests, consultation number storage, national registry fallback, per-transaction audit logging, and retry logic takes meaningful engineering time. For most accounting platforms, this is a compliance feature — not a core product differentiator.

The table below compares building it in-house versus using a purpose-built VAT validation API:

The Vatnode API

Vatnode is a purpose-built EU VAT validation API that handles the full qualified-request flow:

{
  "vat_number": "DE123456789",
  "requester_vat": "NL000000000B01"
}

{
  "valid": true,
  "name": "Example GmbH",
  "address": "Musterstraße 1, 10115 Berlin",
  "consultation_number": "WAPIBE0516R5LO6BV",
  "validated_at": "2026-06-17T09:14:32Z",
  "source": "vies"
}

Every response includes the consultation_number and validated_at timestamp. When VIES is unavailable, the API automatically retries against the relevant national registry and flags "source": "national_registry".

Summary

The VIES consultation number is the difference between proving you checked a VAT number and hoping your records hold up in an audit. It's issued by the European Commission at the moment of the check, stored server-side, and independently verifiable by any EU tax authority.

Most platforms miss it because they use simple (unqualified) VIES requests or discard the requestIdentifier field. A correct implementation requires qualified requests, stored consultation numbers, national registry fallback, and a per-invoice audit log.

If you're building or maintaining EU invoicing software, this is the compliance gap worth closing.

Related reading: Audit-Proof EU VAT Validation Guide · EU VAT Validation API Overview · Vatnode.com