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 of the member-state paths engineering teams commonly build fallback logic around. 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 offline is the actual problem. Here is the full pipeline.

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) used internally by BZSt, 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 or BZSt.

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. What you can do is fall back to BZSt directly.

Step 3: BZSt fallback

BZSt operates eVatR (elektronische Bestätigung von Umsatzsteuer-Identifikationsnummern), a separate validation endpoint for German VAT IDs. It is the same authority that backs VIES DE — but the direct path is more reliable than going through the VIES federation.

There are two important differences between BZSt and VIES:

1. BZSt requires a valid German VAT ID as the requester. You cannot call BZSt with a non-German VAT number on the requester field. If your company is not German, you cannot use BZSt directly — only as a proxy through a service that has a DE VAT ID.
2. BZSt does not disclose trader name or address as returned data. A qualified eVatR check can confirm whether the name, address, and postcode you supplied match what BZSt has on file (and return a per-field match status), but BZSt will not hand you those fields if you do not already have them. VIES, by contrast, returns trader name and address when valid (and when the trader has not opted out of disclosure under EU rules). For invoicing under § 14 UStG you usually need to be able to show the name and address, so BZSt is a fallback for the yes/no signal — and optionally a confirmation that the data you already collected matches.

Here is the pattern a resilient validator should implement:

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

  try {
    const vies = await callVies(cleaned)
    if (vies.status === 'OK') {
      return {
        valid: vies.valid,
        name: vies.name,
        address: vies.address,
        source: 'VIES',
      }
    }
  } catch (e) {
    // fall through to BZSt
  }

  // VIES DE unavailable — try BZSt
  const bzst = await callBzst(cleaned)
  return {
    valid: bzst.valid,
    name: null,        // BZSt does not return this
    address: null,
    source: 'BZST',
  }
}

Implementing callBzst yourself means SOAP, a registered requester VAT ID, and handling their error codes (Status A through Status E). It is doable — and a reasonable choice if your team is German and already has a USt-IdNr. to act as the requester.

You have three honest options for the DE fallback path:

1. Build the BZSt integration directly. Costs engineering time and ongoing maintenance, but gives you full control.
2. Queue retries against VIES without a fallback. Simplest. Works fine if your flow can tolerate a "we'll get back to you" UX.
3. Use a VAT validation provider that already runs the pipeline. Several exist; the rest of this article walks through how vatnode does it.

Step 4: use vatnode and skip the boilerplate

vatnode runs the full pipeline above on every German request. If VIES DE is healthy, you get a VIES response with name and address. If VIES DE is unavailable, vatnode automatically retries against BZSt and returns the BZSt result. The response shape is the same — only the source field changes.

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",
//   "vatNumber": "123456789",
//   "name": "Example GmbH",          // null if source = BZST
//   "address": "Musterstr. 1, ...",  // null if source = BZST
//   "source": "VIES",                 // or "BZST"
//   "consultationNumber": "WAPIAAAAX...",
//   "checkedAt": "2026-05-22T08:30:00.000Z"
// }

The source field is what lets your invoicing logic know whether you have the trader name. Branch on it:

if (data.source === 'VIES') {
  // Use data.name and data.address on the invoice
} else if (data.source === 'BZST') {
  // BZSt validated the ID — fetch name/address from your CRM
  // or ask the customer to confirm
}

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 or BZST)
• consultationNumber (if from VIES)
• name and address (if from VIES)
• checkedAt timestamp

If source was BZST, schedule a re-check next time VIES recovers so you can capture the consultation number and trader details. 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 fall back to BZSt or queue for retry — never block checkout on this. See the VIES alternative with automatic fallback for the broader pattern across all member states.