Validate German VAT Numbers (USt-IdNr.) in Node.js

Germany is the largest EU market for most B2B SaaS, and the German VIES node is one that engineering teams learn to design around: it rate-limits and it goes offline more than you would like. If you are validating German VAT numbers in Node.js, the format check is the easy part. Getting a reliable answer when VIES DE is throttling or temporarily down is the actual problem — and, unlike some member states, Germany has no national second opinion you can fall back to. Here is the full pipeline, including what to do when VIES DE cannot answer.

What a German VAT number looks like

Germany issues two different tax identifiers, and developers regularly confuse them:

• USt-IdNr. (Umsatzsteuer-Identifikationsnummer) — the EU VAT ID. Format: DE + 9 digits. This is what goes on cross-border B2B invoices and what VIES validates.
• Steuernummer — the domestic tax number issued by the local Finanzamt. Format varies by federal state (10 or 11 digits, sometimes with slashes). This is not a VAT ID and is not valid for VIES.

If a customer gives you a number without the DE prefix and it contains slashes, they sent you the wrong thing. Ask for the USt-IdNr.

Step 1: format validation

Before you make any network call, reject malformed input. The regex is short, but you need to decide up-front which mode you are running in:

• Strict (API mode) — your service exposes a documented DE + 9-digit format. Reject anything else.
• Lenient (checkout mode) — accept what the customer types and try to make it work. Spaces, dots, and a missing DE prefix are common; auto-correct them and log the original input.

Make the difference explicit in code, not implicit:

const DE_VAT_PATTERN = /^DE\d{9}$/

function normaliseGermanVatId(
  input: string,
  opts: { mode?: 'strict' | 'lenient' } = {}
): string | null {
  let cleaned = input.replace(/[\s.\-]/g, '').toUpperCase()
  // Lenient mode: prepend DE when the user typed only the 9 digits
  if (opts.mode === 'lenient' && /^\d{9}$/.test(cleaned)) {
    cleaned = `DE${cleaned}`
  }
  return DE_VAT_PATTERN.test(cleaned) ? cleaned : null
}

// Strict (default) — API consumers should send a fully-qualified ID
normaliseGermanVatId('DE 123 456 789') // → 'DE123456789'
normaliseGermanVatId('123456789') // → null

// Lenient — for checkout forms where customers paste 9 digits
normaliseGermanVatId('123456789', { mode: 'lenient' }) // → 'DE123456789'
normaliseGermanVatId('DE12345678', { mode: 'lenient' }) // → null (still wrong length)

There is a checksum algorithm (MOD 11-10) computed internally when a USt-IdNr. is issued, but it is not officially documented for third-party client use. Do not gate on it. Treat checksum failure as a soft signal that may warrant a warning, never as grounds to reject — the authoritative yes/no comes from VIES.

Step 2: VIES — and why DE is special

VIES is the EU-wide validation service. For most member states it works fine. For Germany it does not, often enough that you have to design around it.

VIES is a federation of 27 national nodes. When you query a DE number, the European Commission routes the request to the BZSt (Bundeszentralamt für Steuern) system in Bonn. BZSt rate-limits and occasionally takes the node offline. The result your application sees from VIES is either:

• A valid/invalid answer
• MS_UNAVAILABLE (the German node is down)
• SERVICE_UNAVAILABLE (VIES itself is degraded)
• A timeout after ~10 seconds

You cannot fix the VIES DE node. And for German numbers there is no separate national endpoint you can query instead — which is the part that trips up teams porting a fallback strategy from another country.

Step 3: why there is no national validity fallback for Germany

For some member states, when the VIES path is unavailable you can back-fill the answer from a national tax authority or company registry, and record which source actually answered. Germany is not one of them, and it is worth being precise about why.

BZSt does operate eVatR (elektronische Bestätigung von Umsatzsteuer-Identifikationsnummern), an electronic confirmation service. But eVatR is Germany's tool for a German business to confirm the VAT number of a foreign trading partner — it is the German entry point into the EU confirmation system, not a public endpoint for confirming a German number on someone else's behalf. It is not a drop-in replacement for a VIES DE lookup of a DE number: attempts to use it that way are rejected as unauthorized (evatr-0006), because confirming a German number requires an entitlement eVatR does not grant to that flow.

The practical consequence is blunt: for a German USt-IdNr., VIES is the only source of a yes/no. When VIES DE is down, the honest result is "unavailable" — not "invalid", and not a verdict fabricated from a company register. So a resilient German validator does not reach for a second source; it treats the outage as transient, refuses to invent a verdict, and queues a re-check:

async function validateGermanVat(vatId: string) {
  const cleaned = normaliseGermanVatId(vatId)
  if (!cleaned) {
    return { valid: false, error: 'INVALID_FORMAT' }
  }

  const vies = await callVies(cleaned)
  if (vies.status === 'OK') {
    return {
      valid: vies.valid,
      name: vies.name,
      address: vies.address,
      source: 'VIES',
    }
  }

  // VIES DE is unavailable and there is no national endpoint that will confirm a
  // German number for you. Do NOT downgrade to a company register and call it
  // valid — that produces false positives. Surface the outage and queue a re-check.
  return { valid: null, status: 'UNAVAILABLE', retryQueued: true }
}

Do not hardcode a list of which countries have a national fallback and which do not — coverage changes, and the honest description is "tax authority and company registry APIs" rather than a fixed roster. Germany's specific reality is simply that VIES is the sole authority for a DE number.

That leaves two sensible ways to handle a VIES DE outage, fastest first:

1. Use vatnode. It runs a requester-qualified VIES DE call, returns one stable response shape, and includes the consultation number when VIES answers. When VIES DE is down it surfaces a transient error instead of guessing — you queue a retry and move on. Free for low volume — 100 checks a month, no card — and low cost above that.
2. Queue retries against VIES yourself. Simplest to write. Works only if your flow can tolerate a "we'll get back to you" UX, and you own the retry/backoff and the transient-vs-invalid distinction.

Step 4: use vatnode and skip the boilerplate

vatnode runs the full pipeline above on every German request: format normalization, a requester-qualified VIES DE call, and a stable response shape. If VIES DE is healthy, you get a VIES response with name and address and a consultation number. If VIES DE is unavailable, vatnode returns a transient error rather than a fabricated verdict — you retry, you do not block checkout, and you never persist a valid you cannot stand behind.

const res = await fetch('https://api.vatnode.dev/v1/vat/DE123456789', {
  headers: { Authorization: `Bearer ${process.env.VATNODE_API_KEY}` },
})

const data = await res.json()
// {
//   "valid": true,
//   "countryCode": "DE",
//   "vatId": "DE123456789",
//   "companyName": "Example GmbH",
//   "companyAddress": "Musterstr. 1, ...",
//   "source": "VIES",
//   "consultationNumber": "WAPIAAAAX...",
//   "checkId": "019d2a89-a5d9-7b97-b710-57b84604de2b",
//   "verifiedAt": "2026-05-22T08:30:00.000Z"
// }

For a German check the source is always VIES — it is the only authority for a DE number — so a valid result carries the trader name and address you need for invoicing. When VIES DE cannot answer, you get an explicit transient error code instead, not a result to branch on:

if (res.ok) {
  const data = await res.json()
  // source === 'VIES' for German numbers — use data.name and data.address
} else {
  const { code } = await res.json()
  // VIES_UNAVAILABLE / UPSTREAM_TIMEOUT etc. — transient, queue a re-check,
  // never treat as "invalid" and never block checkout on it.
}

The consultationNumber is the VIES-issued reference that proves you validated the number on a specific date. Store it as audit evidence — the European Commission explicitly recommends keeping proof of validation, and many finance teams retain it because auditors may request evidence of VAT validation on intra-EU reverse-charge supplies. See the VIES downtime guide for why this matters and how to surface it in your audit trail.

What to store in your database

For German VAT IDs specifically, your validation log should include:

• The cleaned VAT ID (uppercase, no separators)
• valid (boolean)
• source (VIES — the only authority for a DE number)
• consultationNumber (from the requester-qualified VIES call)
• name and address (from VIES)
• checkedAt timestamp

If VIES DE was unavailable at check time, you have no verdict to store — record the attempt and the outage, not a fabricated valid, and schedule a re-check for when VIES recovers so you can capture the answer and the consultation number. The Node.js VAT validation guide shows the schema vatnode customers use for this.

Common gotchas

• Customer types the Steuernummer. Detect the slashes early and reject. A 12/345/67890 is never a USt-IdNr.
• Customer omits the DE prefix. In checkout flows, use the lenient normalisation mode shown above so a bare 9-digit number is auto-prefixed. In strict API mode, reject and let the caller resubmit — and log the original input either way.
• Spaces and dots. Germans write VAT IDs with spaces (DE 123 456 789) and sometimes dots. Strip them.
• You query VIES and get MS_UNAVAILABLE. This is not "invalid". Treat it as a transient error and queue for retry — there is no national endpoint that will confirm a German number in the meantime, so never fall over to a company register and call it valid, and never block checkout on it. See the VIES alternative with automatic fallback for the broader pattern across member states that do have a fallback.