VIES Down? How the National Registry Fallback Works

VIES is a gateway, not a database. Every validation it answers is forwarded to one of 27 national tax authorities, so when one of those goes down, VIES has nothing to tell you. What most integrations do next is fail the request or serve a cached answer. On the Pro and Business plans Avatcado tries one more thing first: for ten EU countries the same tax authority publishes its VAT register directly, and Avatcado asks it. The Free plan goes straight to the cached answer. This guide explains exactly when the register step happens, which registers answer, how to read the response, and how to switch the step off for a single request.

Why VIES needs a fallback

Member state outages are routine rather than exceptional. A single country can be unavailable for minutes or hours while the rest of VIES answers normally, and there is no way to route around it inside VIES itself: the Commission holds no copy of the national data.

The data is not secret, though. Romania, Czechia, Finland, France, Latvia, Slovakia, Slovenia, Croatia, Estonia and Belgium all publish their VAT registers as a public web service or as open data. When the VIES route to one of those countries is broken, its own register is still there. The fallback is a second road to the same authority, not a second-hand copy of VIES.

The remaining countries have no equivalent public source, so their outages are handled by the cache alone. The coverage page lists what backs every country Avatcado validates.

What triggers the fallback

The fallback is an outage path, not a shortcut. A validation only reaches it after the VIES call has been retried and still came back with no answer, and only for EU country codes. Two things count as no answer:

• An availability fault from VIES: MS_UNAVAILABLE, MS_MAX_CONCURRENT_REQ, TIMEOUT, SERVICE_UNAVAILABLE, GLOBAL_MAX_CONCURRENT_REQ or VOW-ERR-11.
• A network failure or timeout reaching VIES itself.

A number that VIES does answer for never reaches a register, whether the answer is valid or invalid. VIES remains the authority on every request it can serve; the register only speaks when VIES cannot.

The precedence: register, cache, stale cache, 503

Once a request is on the outage path, Avatcado works down a fixed order and stops at the first step that can answer. Every step is visible in meta, so your code never has to guess which one it got:

• The national register. Only for the ten countries below, and only when the register confirms the number is VAT registered. You get source_status: "fallback", source naming the register, cached: false and stale: false.
• The most recent stored result, still inside its cache window. You get source_status: "unavailable", cached: true and stale: false.
• An older stored result. Same fields, but stale: true, so you can apply your own policy to an answer that has aged past the TTL.
• A 503. When nothing above can answer, the response is an upstream_member_state_unavailable error. That request is refunded automatically: an outage never counts against your monthly quota.

A request that carries requester_vat_number skips every step on this list by default and goes straight to the 503, because none of them can produce the consultation number it exists to collect. The section on skipping the fallback below covers that rule and how to opt back in.

Which registers answer

Ten countries have a national register in the path. The table is generated from the same data the API routes with, so it cannot drift from what actually runs:

Each register has limits worth knowing before you rely on it, because they decide which numbers it can confirm at all:

• ANAF: Zero-padded or non-numeric CUI shapes are not looked up (^[1-9]\d{1,9}$).
• ARES: Only 8-digit numbers (legal entities); 9 and 10 digit numbers issued to individuals are not looked up.
• PRH: Open data has no private traders, municipalities or wellbeing services counties, so a missing record is never served as invalid.
• DGFiP: VAT status from the DGFiP list of active intra-EU VAT numbers (refreshed daily). Name and address both come from the public company search (recherche-entreprises.api.gouv.fr), and the answer carries company null when that second call fails.
• VID: Register lists no natural persons and carries no addresses.
• FS SR: The VAT register list behind the API is republished every morning, so an answer reflects the previous day. Every registration type on the list counts as registered, including section 7 and 7a registrations that VIES also confirms. Keyed API with an allowance of 1,000 requests per hour.
• FURS: Companies filed under a VAT-group identifier are not served (VIES did not confirm a member's own number).
• Porezna uprava: The VAT payer list carries no names or addresses, so a porezna answer has company null.
• RIK: Estonian VAT groups share one VAT number; the snapshot names one member of the group.
• KBO: Companies only: sole traders are never answered from the snapshot and fall through to the cache. VAT status is read from the register's VAT activities; the open data carries no VAT registration date. Loaded once in full, then kept current from the daily update files.

Every register has its own page under VAT registries with the endpoint, the data it publishes, and the sample response Avatcado parses.

Live registers vs daily snapshots

The ten registers do not work the same way, and the difference matters for how fresh a fallback answer is.

Queried live on the request (6): Romania (ANAF), Czech Republic (ARES), Finland (PRH), France (DGFiP), Latvia (VID), Slovakia (FS SR). These authorities expose a public endpoint that answers per number, so Avatcado calls it while your request is open, with a 10 second timeout. If the register is slow or down too, the request falls through to the cache. France is a two-step case: the VAT status comes from the DGFiP list of active intra-EU numbers, while the name and address come from the public company search, and they are null when that second call fails.

Answered from a daily snapshot (4): Slovenia (FURS), Croatia (Porezna uprava), Estonia (RIK), Belgium (KBO). These authorities publish a bulk file of VAT payers instead of a per-number endpoint. A scheduled job downloads each file twice a day, parses it, and stores it as a snapshot that fallback lookups read from. Belgium's mirror stores companies only: sole traders never appear in it, so their numbers fall through to the cache exactly as if Belgium had no register at all.

A snapshot is only trusted while it is demonstrably fresh. Two gates apply, and either one retires it:

• The snapshot itself must be less than 3 days old. An older one means the sync has been failing quietly.
• The source file must have changed within the last 14 days. A file frozen for longer than that suggests the mirror is polling an endpoint the authority has abandoned.

A snapshot that fails either gate is not used at all, and the request falls through to the cache exactly as if the country had no register. A stale file is worse than no fallback, so it is never served.

Reading the response

A fallback answer is an ordinary validation response with three fields that tell you where it came from: source_status, source, and the cache flags.

{
  "data": {
    "valid": true,
    "vat_number": "RO1590082",
    "country_code": "RO",
    "company": {
      "name": "EXEMPLU SRL",
      "address": "STR. EXEMPLU 1, BUCURESTI"
    },
    "requested_at": "2026-09-04T10:30:00Z"
  },
  "meta": {
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "request_duration_ms": 380,
    "cached": false,
    "stale": false,
    "source": "anaf",
    "source_status": "fallback"
  }
}

• source_status: "fallback" means VIES was unavailable and a national register answered in its place.
• source names which one, using the ids in the table above (anaf, ares, prh, dgfip, vid, fssr, furs, porezna, rik, kbo).
• cached: false and stale: false: a fallback answer is a fresh lookup, not an old result being reused.
• consultation_number is not present on the response at all. Only VIES issues consultation numbers; a register cannot. If you need one for an audit trail, re-validate the number through VIES once the member state is back.

A fallback result is stored like any other, so the next request for that number is served from cache. That cache hit also schedules a background VIES refresh, which means the number returns to a VIES-sourced answer on its own once the member state recovers, without you having to queue a re-check.

Branching on the meta fields takes a few lines:

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

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

if (meta.source_status === "fallback") {
  // Confirmed by the national register while VIES was down.
  // No consultation number is available for this answer.
  console.info(`VIES down for ${data.country_code}, confirmed by ${meta.source}`);
  markForRevalidation(data.vat_number);
}

The positive-only rule

A register can only ever confirm a registration. A miss, whether the register says "not registered" or simply has no record, is never turned into valid: false. The request falls through to the cache instead.

This is not caution for its own sake. The published registers do not cover everything VIES covers, so a miss is genuinely ambiguous:

• Finnish open data contains no private traders and no municipalities.
• The Latvian register lists no natural persons.
• ARES cannot look up the 9 and 10 digit numbers issued to individuals in Czechia.

Serving those misses as invalid would reject real, VAT registered customers during an outage, which is a far worse failure than not answering. The trade-off runs the other way too, and it is worth stating plainly: a number that the register lists as deregistered keeps being served from its stored result for as long as the outage lasts, because a negative from the register is not acted on. Fallback answers are a bridge across an outage, not a replacement for a VIES check.

What valid: true means on a fallback

It means the number is registered for VAT in that country, according to that country's own register. That is a slightly different statement from the one VIES makes.

VIES reports whether a number is valid for intra-EU trade. A domestic register reports domestic VAT registration, which can be the broader set: a business can be registered for VAT at home without being listed for intra-Community supplies. For most billing and onboarding decisions the two answers agree, and treating a fallback answer as valid is the right call. For a zero-rated intra-Community supply where you want documented proof, treat the fallback as provisional: it keeps checkout moving, and you re-validate through VIES afterwards to get the consultation number your records need.

The reverse charge guide covers what that proof has to look like.

Skipping the fallback

A register answer never carries a consultation number, because only VIES issues one. So when a request supplies requester_vat_number, the register is skipped by default, and so is the cache: the request is a fresh VIES attempt unless you explicitly opt into either path. A consultation number is not guaranteed. No flag is needed to use these requester defaults:

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

During an outage such a request does not fall back to anything. No register is consulted, and no stored result is served either, not even the older one a request without a requester would get, because neither can carry the consultation number the request exists to collect. It fails with a refunded 503, upstream_member_state_unavailable or upstream_unavailable, whose message says the register was not consulted because requester_vat_number was supplied, and you retry once VIES is back.

Explicit values always win. Pass fallback=true next to a requester to accept a register answer anyway; it has no consultation number, so treat it as a signal to re-validate later. Pass cache=true to accept a stored result, including one that repeats the consultation number from an earlier check with the same requester, and to get a stored result during an outage. Without a requester the register step is on by default, and fallback=false still switches it off for any single request. Both flags are accepted on every plan; fallback is a no-op on Free, which never consults a register.

Testing it

You do not have to wait for an outage to see the shape of a fallback response. In test mode with a Pro or Business test key, RO555555555 returns one:

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

The response carries source_status: "fallback" and source: "anaf", so you can assert on both in your integration tests. Test mode reaches no upstream and uses no quota, which makes the outage path as easy to cover as the happy one. Test mode mirrors the plan gate: on a Free test key the same number answers the refunded 503 with the upgrade message, exactly as production would.

For the full picture of what answers each country and what company data it discloses, see the coverage page, the VIES downtime guide for the decision flow around stale results, and the supported countries reference in the API docs.

The register fallback is included in the Pro and Business plans; the free tier covers the cache path. Start validating for free →