VIES Downtime: Why It Happens and How to Handle It

If you validate EU VAT numbers, you depend on VIES. And VIES goes down. Not occasionally, but regularly, and often for specific countries rather than the entire system. This guide explains why VIES downtime happens, how it affects your application, and what you can do about it.

Why VIES goes down

VIES is not a single database. It is a gateway operated by the European Commission that routes validation requests to 27 independent national tax authority databases. When you validate a French VAT number, VIES forwards your request to the French tax authority (DGFiP). When you validate an Italian number, it goes to Italy's Agenzia delle Entrate.

This means VIES availability is only as good as the weakest link in any given request. Each member state maintains its own infrastructure with its own uptime characteristics, maintenance windows, and capacity limits.

Common offenders

In our own VIES uptime monitoring, some member states have been less reliable than others:

• Italy: Frequent maintenance windows, sometimes during business hours. Agenzia delle Entrate (the Italian tax authority that powers VIES for IT VAT numbers) has regular planned outages on its VAT registry service.
• Spain: The Agencia Tributaria service experiences intermittent availability, particularly during tax filing periods.
• Greece: AADE (Independent Authority for Public Revenue) has had extended outages lasting hours.
• Belgium: Occasional rate limiting issues that cause cascading failures.

In the same monitoring data, Germany, the Netherlands, and the Nordic countries tend to have the most reliable national services.

You can monitor current and historical availability on our VIES uptime monitor.

What happens to your application

When a member state is down and you call VIES directly, you get a SOAP fault with code MS_UNAVAILABLE or TIMEOUT. If your code is not built to handle this, your checkout flow, invoice generation, or customer onboarding breaks. The user sees an error and either retries (adding load) or abandons the process.

This is particularly painful for SaaS applications where VAT validation happens at signup or checkout. A 30-minute outage in one country means you cannot process any customers from that country for 30 minutes.

Strategies for handling downtime

Build your own cache

Cache validation results on your side with a TTL (e.g., 24 hours). When VIES is down, serve the cached result. Trade-offs: you need to manage cache storage, decide on an acceptable staleness window, and handle cache misses for numbers you have never seen before. A 24-hour cache is generally reasonable because VAT registrations do not change frequently.

Retry with backoff

Implement exponential backoff on VIES failures. This helps with transient issues but does not solve sustained outages. If a member state is down for an hour, your users are still waiting. Retries are a good complement to caching, not a replacement.

Use a wrapper API

Instead of calling VIES directly, use an API that handles caching, retries, and fallback logic for you. This is what Avatcado does.

How Avatcado handles VIES downtime

When a member state goes down, Avatcado first asks that country's own tax register on the Pro and Business plans. Ten countries publish one it can query: Belgium, Croatia, Czechia, Estonia, Finland, France, Latvia, Romania, Slovakia and Slovenia. When the register confirms the number is VAT registered, that answer is served with meta.source_status: "fallback". Everything else is covered by the cache: every validation result is stored and served transparently while the upstream is unavailable. The response tells you exactly what happened through the meta fields.

The coverage page lists which register backs each country, and how the national registry fallback works walks through the full precedence, the freshness gates on the daily snapshots, and why a register is only ever used to confirm a registration, never to reject a number.

A normal (live) response:

curl https://api.avatcado.com/v1/validate?vat_number=IT12345678901 \
  -H "Authorization: Bearer avat_live_your_api_key"

{
  "data": {
    "valid": true,
    "vat_number": "IT12345678901",
    "country_code": "IT",
    "company": {
      "name": "ESEMPIO S.R.L.",
      "address": "VIA ROMA 1, 00100 ROMA"
    },
    "consultation_number": null,
    "requested_at": "2026-03-24T10:30:00Z"
  },
  "meta": {
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "request_duration_ms": 1420,
    "source_status": "live"
  }
}

A stale cache response (when Italy is down):

{
  "data": {
    "valid": true,
    "vat_number": "IT12345678901",
    "country_code": "IT",
    "company": {
      "name": "ESEMPIO S.R.L.",
      "address": "VIA ROMA 1, 00100 ROMA"
    },
    "consultation_number": null,
    "requested_at": "2026-02-25T14:00:00Z"
  },
  "meta": {
    "request_id": "661f9500-f30c-52e5-b827-557766551111",
    "request_duration_ms": 45,
    "cached": true,
    "cached_at": "2026-02-25T14:00:00Z",
    "stale": true,
    "source_status": "unavailable"
  }
}

Here's what each meta field tells you:

• cached: true means this result came from cache, not a live lookup.
• cached_at tells you when the original lookup happened.
• stale: true means the cache entry has expired (it is older than the cache window) but is being served because the upstream is unavailable.
• source_status: "unavailable" means the member state service was down when Avatcado tried to reach it.
• source_status: "fallback" means the member state was down and its national tax register confirmed the number as VAT registered (Belgium, Croatia, Czechia, Estonia, Finland, France, Latvia, Romania, Slovakia and Slovenia). A register that does not confirm the number is never served; the request falls through to the cache instead.
• source_status: "degraded" means VIES returned a result but Avatcado detected a possible silent false negative (some member states return "invalid" for valid numbers during partial outages).

And when no cached result exists at all, the 503 error response is still self-describing: it echoes the normalized vat_number you submitted inside the error object and carries a meta.validation_id referencing the recorded attempt, so your logs prove the validation was tried even though no answer was available.

Handling meta fields in your code

Here's how you might use these fields in a TypeScript application:

const response = await fetch(
  "https://api.avatcado.com/v1/validate?vat_number=IT12345678901",
  { headers: { Authorization: "Bearer avat_live_your_api_key" } }
);

const { data, meta } = await response.json();

if (data.valid) {
  if (meta.stale) {
    // Result is valid but based on stale cache
    // Consider flagging for re-validation later
    console.log("Valid (stale cache, upstream was down)");
  } else {
    console.log("Valid (fresh result)");
  }
}

// Log source status for monitoring
if (meta.source_status === "fallback") {
  console.info(`VIES down for ${data.country_code}, answered by the national register (${meta.source})`);
} else if (meta.source_status === "unavailable") {
  console.warn(`VIES unavailable for ${data.country_code}`);
} else if (meta.source_status === "degraded") {
  console.warn(`VIES degraded for ${data.country_code}, result may be unreliable`);
}

Get started

Stop building VIES reliability infrastructure yourself. Avatcado handles caching, retries, and stale fallback so your application stays up even when VIES does not.

Monitor VIES availability in real-time on our uptime monitor. Read the VIES REST and SOAP API guide for the upstream error fields your client must inspect, including service faults carried inside HTTP 200 responses.

Avatcado's free tier includes 500 validations per month with the same caching and reliability features as paid plans.

Start validating for free →