# TaxID — Full content
> Developer-first EU VAT validation REST API. Full text of every content page, for LLM ingestion.

Source of truth: https://www.taxid.dev/llms.txt (index) and https://www.taxid.dev/sitemap.xml.

---

# Country VAT number formats

## Austria (AT) Local name: UID (Umsatzsteuer-Identifikationsnummer). Format: ATU + 8 digits. Example: ATU12345678. Standard rate: 20%, reduced 13%, 10%.
Austrian VAT numbers always start with ATU (not just AT). The U stands for Unternehmer (entrepreneur). Austria has one of the most active VIES registrations in Central Europe.
Validate: https://www.taxid.dev/validate-vat/at

## Belgium (BE) Local name: BTW/TVA (Belasting over de Toegevoegde Waarde / Taxe sur la Valeur Ajoutée). Format: BE + 0 or 1 + 9 digits (10 digits total). Example: BE0123456789. Standard rate: 21%, reduced 12%, 6%.
Belgian VAT numbers begin with BE0 (for companies registered before 2003) or BE1 (newer). All Belgian companies must register within 15 days of commencing taxable activity.
Validate: https://www.taxid.dev/validate-vat/be

## Bulgaria (BG) Local name: ДДС (Данък върху добавената стойност). Format: BG + 9 or 10 digits. Example: BG123456789. Standard rate: 20%, reduced 9%.
Bulgaria uses the Latin prefix BG even though its local name uses Cyrillic script. Companies with 9-digit EIK (commercial register number) and individuals with 10-digit EGN both receive VAT numbers in this format.
Validate: https://www.taxid.dev/validate-vat/bg

## Cyprus (CY) Local name: ΦΠΑ (Φόρος Προστιθέμενης Αξίας). Format: CY + 8 digits + 1 letter. Example: CY12345678A. Standard rate: 19%, reduced 9%, 5%.
Cypriot VAT numbers consist of 8 digits followed by a single alphabetic check character. Cyprus has a thriving international business community and many EU holding companies are registered here due to its favourable tax treaties.
Validate: https://www.taxid.dev/validate-vat/cy

## Czech Republic (CZ) Local name: DIČ (Daňové identifikační číslo). Format: CZ + 8, 9, or 10 digits. Example: CZ12345678. Standard rate: 21%, reduced 12%.
Czech VAT numbers (DIČ) can have 8 digits (legal entities), 9 digits (individuals), or 10 digits (foreign entities). In 2024 Czech Republic simplified from 3 rates to 2 rates (21% and 12%).
Validate: https://www.taxid.dev/validate-vat/cz

## Germany (DE) Local name: USt-IdNr. (Umsatzsteuer-Identifikationsnummer). Format: DE + 9 digits. Example: DE123456789. Standard rate: 19%, reduced 7%.
Germany's USt-IdNr. is distinct from the Steuernummer (local tax number). Only the USt-IdNr. is used for EU cross-border transactions and VIES validation. German companies may take up to 4 weeks to receive their USt-IdNr. after registration.
Validate: https://www.taxid.dev/validate-vat/de

## Denmark (DK) Local name: Moms-nummer / CVR-nummer. Format: DK + 8 digits. Example: DK12345678. Standard rate: 25%.
Denmark has a flat 25% VAT rate with no reduced rates, making it one of the simpler EU VAT systems. The VAT number is the same as the CVR (Central Business Register) number with the DK prefix added.
Validate: https://www.taxid.dev/validate-vat/dk

## Estonia (EE) Local name: KMKR (Käibemaksukohustuslase registreerimise number). Format: EE + 9 digits. Example: EE123456789. Standard rate: 22%, reduced 9%.
Estonia increased its standard VAT rate from 20% to 22% in January 2024. As a digital-first nation, Estonia has excellent VIES connectivity and typically returns validation results in under 200ms.
Validate: https://www.taxid.dev/validate-vat/ee

## Greece (EL) Local name: ΑΦΜ (Αριθμός Φορολογικού Μητρώου). Format: EL + 9 digits. Example: EL123456789. Standard rate: 24%, reduced 13%, 6%.
Greece uses the two-letter prefix EL (not GR) for VAT numbers, reflecting the Greek name Ελλάδα. The ΑΦΜ is a 9-digit number where the last digit is a check digit. Greek island regions (Lesbos, Chios, Samos, etc.) have reduced rates.
Validate: https://www.taxid.dev/validate-vat/el

## Spain (ES) Local name: NIF / CIF (Número de Identificación Fiscal / Código de Identificación Fiscal). Format: ES + letter/digit + 7 digits + letter/digit. Example: ESA12345678. Standard rate: 21%, reduced 10%, 4%.
Spain has three VAT identifier types: CIF for companies (letter + 7 digits + letter), NIF for individuals (8 digits + letter), and NIE for foreign nationals (X/Y/Z + 7 digits + letter). All are validated through VIES as Spanish VAT numbers.
Validate: https://www.taxid.dev/validate-vat/es

## Finland (FI) Local name: ALV-numero (Arvonlisäveronumero). Format: FI + 8 digits. Example: FI12345678. Standard rate: 25.5%, reduced 14%, 10%.
Finland increased its standard VAT rate from 24% to 25.5% in September 2024, making it one of the highest in the EU. The Finnish business ID (Y-tunnus) and VAT number share the same 8-digit number with different prefixes.
Validate: https://www.taxid.dev/validate-vat/fi

## France (FR) Local name: N° TVA (Numéro de TVA intracommunautaire). Format: FR + 2 alphanumeric chars + 9 digits. Example: FRXX123456789. Standard rate: 20%, reduced 10%, 5.5%, 2.1%.
French VAT numbers have a unique format: the first two alphanumeric characters after FR are computed from the SIREN number and can include letters O and I (unlike most EU countries). France has one of the most complex reduced rate structures with four different rates.
Validate: https://www.taxid.dev/validate-vat/fr

## Croatia (HR) Local name: OIB / PDV ID (Osobni identifikacijski broj / Porez na dodanu vrijednost). Format: HR + 11 digits. Example: HR12345678901. Standard rate: 25%, reduced 13%, 5%.
Croatia joined the EU in 2013 and adopted the euro in 2023. The Croatian VAT number (PDV ID) uses the personal identification number (OIB) as its basis, which is 11 digits long with a check digit at the end.
Validate: https://www.taxid.dev/validate-vat/hr

## Hungary (HU) Local name: ANUM (Adószám). Format: HU + 8 digits. Example: HU12345678. Standard rate: 27%, reduced 18%, 5%.
Hungary has the highest standard VAT rate in the EU at 27%. The Hungarian tax number (adószám) has 11 digits in total (8-digit base + 3 additional digits for local tax), but only the first 8 digits appear in the EU VAT number.
Validate: https://www.taxid.dev/validate-vat/hu

## Ireland (IE) Local name: VAT registration number. Format: IE + digit + alphanumeric + 5 digits + 1-2 letters. Example: IE1234567A. Standard rate: 23%, reduced 13.5%, 9%, 4.8%.
Irish VAT numbers have one of the most complex formats in the EU, with several valid patterns used for different entity types. Ireland is particularly important for tech companies — many major US software companies have their EU headquarters here.
Validate: https://www.taxid.dev/validate-vat/ie

## Italy (IT) Local name: Partita IVA. Format: IT + 11 digits. Example: IT12345678901. Standard rate: 22%, reduced 10%, 5%, 4%.
The Italian Partita IVA (P.IVA) consists of 11 digits where the last digit is a check digit computed using the Luhn algorithm. Italy also issues Codice Fiscale (CF) for individuals, which has a different alphanumeric format and is not the same as the P.IVA.
Validate: https://www.taxid.dev/validate-vat/it

## Lithuania (LT) Local name: PVM mokėtojo kodas. Format: LT + 9 digits (companies) or 12 digits (individuals). Example: LT123456789. Standard rate: 21%, reduced 9%, 5%.
Lithuania uses two VAT number lengths: 9 digits for legal entities and 12 digits for natural persons registered as taxpayers. The country has a growing startup ecosystem and is a leading fintech hub in the Baltics.
Validate: https://www.taxid.dev/validate-vat/lt

## Luxembourg (LU) Local name: Numéro TVA / MwSt-Nummer. Format: LU + 8 digits. Example: LU12345678. Standard rate: 17%, reduced 14%, 8%, 3%.
Luxembourg has the lowest standard VAT rate in the EU at 17%. It is a major hub for e-commerce (Amazon, PayPal, Skype) due to its historically favourable VAT treatment for digital services, though the EU's OSS scheme has since harmonised this.
Validate: https://www.taxid.dev/validate-vat/lu

## Latvia (LV) Local name: PVN reģistrācijas numurs (Pievienotās vērtības nodoklis). Format: LV + 11 digits. Example: LV12345678901. Standard rate: 21%, reduced 12%, 5%.
Latvian VAT numbers are 11 digits long and use the same base as the Latvian personal identification code. Latvia has a growing tech sector and is a key fintech licensing jurisdiction in the Baltic region.
Validate: https://www.taxid.dev/validate-vat/lv

## Malta (MT) Local name: VAT registration number. Format: MT + 8 digits. Example: MT12345678. Standard rate: 18%, reduced 7%, 5%.
Malta is a popular jurisdiction for gaming, fintech, and iGaming companies. The mandatory VAT registration threshold is €35,000 for goods and €35,000 for services, one of the lowest in the EU.
Validate: https://www.taxid.dev/validate-vat/mt

## Netherlands (NL) Local name: BTW-nummer (Belasting over de Toegevoegde Waarde). Format: NL + 9 digits + B + 2 digits. Example: NL123456789B01. Standard rate: 21%, reduced 9%.
Dutch VAT numbers include a unique 'B' separator followed by 2 digits (typically '01') which identifies the legal entity within a group. The Netherlands is the European logistics hub — Rotterdam is Europe's largest port — making Dutch VAT validation critical for import/export workflows.
Validate: https://www.taxid.dev/validate-vat/nl

## Poland (PL) Local name: NIP (Numer Identyfikacji Podatkowej). Format: PL + 10 digits. Example: PL1234567890. Standard rate: 23%, reduced 8%, 5%.
Poland has the largest economy in Central and Eastern Europe and one of the most active B2B trading nations in the EU. The NIP (Numer Identyfikacji Podatkowej) is 10 digits with a check digit. Poland also uses REGON (statistical ID) and KRS (court register number) but these are different from the NIP.
Validate: https://www.taxid.dev/validate-vat/pl

## Portugal (PT) Local name: NIF / NIPC (Número de Identificação Fiscal / Número de Identificação de Pessoa Coletiva). Format: PT + 9 digits. Example: PT123456789. Standard rate: 23%, reduced 13%, 6%.
Portugal uses NIF for individuals and NIPC for companies, both as 9-digit numbers. The Azores and Madeira autonomous regions have different (lower) VAT rates. Portugal was one of the first EU countries to mandate electronic invoicing (SAF-T) for tax compliance.
Validate: https://www.taxid.dev/validate-vat/pt

## Romania (RO) Local name: CIF / CF (Cod de Identificare Fiscală / Cod Fiscal). Format: RO + 2 to 10 digits. Example: RO1234567890. Standard rate: 19%, reduced 9%, 5%.
Romania has one of the most variable VAT number lengths in the EU (2 to 10 digits), which can complicate format validation. Romania has a growing IT outsourcing sector and is a significant source of B2B services across the EU.
Validate: https://www.taxid.dev/validate-vat/ro

## Sweden (SE) Local name: Momsnummer (Mervärdesskattenummer). Format: SE + 12 digits. Example: SE123456789012. Standard rate: 25%, reduced 12%, 6%.
Swedish VAT numbers (momsnummer) are 12 digits long, derived from the Swedish organisation number by adding '01' at the end. Sweden is a major B2B market and home to many global tech companies including Spotify, King, and Klarna.
Validate: https://www.taxid.dev/validate-vat/se

## Slovenia (SI) Local name: DDV ID (Davek na dodano vrednost Identifikacijska številka). Format: SI + 8 digits. Example: SI12345678. Standard rate: 22%, reduced 9.5%, 5%.
Slovenia is a small but strategically positioned EU market between Italy and Austria. The DDV ID (VAT ID) is 8 digits. Slovenia increased its standard VAT rate from 22% to 22% in recent years, maintaining one of the more moderate rates in the region.
Validate: https://www.taxid.dev/validate-vat/si

## Slovakia (SK) Local name: IČ DPH (Identifikačné číslo pre daň z pridanej hodnoty). Format: SK + 10 digits. Example: SK1234567890. Standard rate: 23%, reduced 19%, 5%.
Slovakia increased its standard VAT rate from 20% to 23% in January 2025 as part of fiscal consolidation. The IČ DPH is a 10-digit number that must pass a modulo 11 check digit validation.
Validate: https://www.taxid.dev/validate-vat/sk

## United Kingdom (GB) Local name: VAT Registration Number. Format: GB + 9 digits. Example: GB123456789. Standard rate: 20%, reduced 5%.
Since Brexit (January 2021), the UK is no longer part of the EU VAT system and cannot be validated via VIES. UK VAT numbers are validated directly through the HMRC API. UK businesses selling digitally to EU customers must register for VAT in an EU member state or use the OSS scheme.
Validate: https://www.taxid.dev/validate-vat/gb

## Australia (AU) Local name: ABN (Australian Business Number). Format: 11 digits. Example: 51824753556. Standard rate: 10%.
Australia's GST (Goods and Services Tax) is a flat 10% with no reduced rates. ABN validation is done through the Australian Business Register (ABR) Lookup API. ABNs are 11-digit numbers derived from the ACN (Australian Company Number) with a two-digit prefix.
Validate: https://www.taxid.dev/validate-vat/au

## Norway (NO) Local name: MVA-nummer (Merverdiavgiftsnummer). Format: NO + 9 digits + MVA. Example: NO123456789MVA. Standard rate: 25%, reduced 15%, 12%.
Norway is part of the European Economic Area (EEA) but not the EU, so Norwegian VAT numbers are not available via VIES. They are validated through the Brønnøysundregistrene (Norwegian Business Register) REST API. The MVA suffix distinguishes the VAT number from the organisation number.
Validate: https://www.taxid.dev/validate-vat/no

## Switzerland (CH) Local name: MWST/TVA/IVA (UID-Nummer). Format: CHE- + 3 digits + . + 3 digits + . + 3 digits. Example: CHE-123.456.789. Standard rate: 8.1%, reduced 2.6%, 3.8%.
Switzerland raised its VAT rate from 7.7% to 8.1% (standard) in January 2024. Swiss UID numbers follow the format CHE-XXX.XXX.XXX and are validated through the BFS UID register. Switzerland is not an EU member, so VIES does not apply.
Validate: https://www.taxid.dev/validate-vat/ch

## Canada (CA) Local name: GST/HST Registration Number. Format: 9 digits + RT + 4 digits. Example: 123456789RT0001. Standard rate: 5%.
Canada's federal GST is 5%. Most provinces also levy a provincial sales tax (HST ranges from 13–15%). A GST/HST number is 15 characters: 9-digit BN (Business Number) + RT + 4-digit program account number. Quebec has its own QST system administered separately by Revenu Québec.
Validate: https://www.taxid.dev/validate-vat/ca

## India (IN) Local name: GSTIN (Goods and Services Tax Identification Number). Format: 2-digit state code + 10-digit PAN + entity number + Z + check digit. Example: 22AAAAA0000A1Z5. Standard rate: 18%, reduced 12%, 5%, 0%.
India's GST replaced a complex system of central and state taxes in 2017. GSTIN is a 15-character identifier where the first 2 digits are the state code, the next 10 are the PAN, and the last 3 identify the entity and include a check digit. India has one of the world's largest GST-registered business populations.
Validate: https://www.taxid.dev/validate-vat/in

## Singapore (SG) Local name: GST Registration Number. Format: 9 digits + 1 letter. Example: 199900888E. Standard rate: 9%.
Singapore raised its GST rate from 8% to 9% in January 2024. Businesses with taxable turnover exceeding SGD 1 million must register for GST. The GST registration number is typically the company's UEN (Unique Entity Number) followed by a check letter.
Validate: https://www.taxid.dev/validate-vat/sg

## New Zealand (NZ) Local name: GST Number (Goods and Services Tax Registration Number). Format: 8 or 9 digits. Example: 123456789. Standard rate: 15%.
New Zealand's GST is a flat 15% with no reduced rates, making it one of the simpler VAT/GST regimes globally. GST numbers are 8 or 9 digits and are often the same as the IRD (Inland Revenue Department) number. Businesses with annual turnover over NZD 60,000 must register.
Validate: https://www.taxid.dev/validate-vat/nz

## South Africa (ZA) Local name: VAT Registration Number. Format: 4 + 9 digits (always starts with 4). Example: 4123456789. Standard rate: 15%, reduced 0%.
South Africa's VAT rate is 15%. All South African VAT numbers start with the digit 4 and are 10 digits total. Businesses with annual taxable supplies exceeding ZAR 1 million must register. SARS administers VAT and verifies registration status through its eFiling portal.
Validate: https://www.taxid.dev/validate-vat/za

## United Arab Emirates (AE) Local name: TRN (Tax Registration Number). Format: 15 digits. Example: 100123456700003. Standard rate: 5%, reduced 0%.
The UAE introduced VAT at 5% in January 2018. TRNs are 15-digit numbers issued by the Federal Tax Authority. The UAE is a major hub for B2B SaaS and fintech across the Middle East and Africa (MENA) region. Businesses with taxable turnover over AED 375,000 must register.
Validate: https://www.taxid.dev/validate-vat/ae

## Mexico (MX) Local name: RFC (Registro Federal de Contribuyentes). Format: 4 letters + 6-digit date + 3-character homoclave. Example: XAXX010101000. Standard rate: 16%, reduced 0%.
Mexico's RFC is a 13-character tax ID for companies (12 for individuals). The first 4 characters are derived from the company name, the next 6 from the date of incorporation, and the last 3 are a homoclave assigned by SAT. Mexico applies a border-region reduced rate of 8% in some areas.
Validate: https://www.taxid.dev/validate-vat/mx

## Japan (JP) Local name: インボイス登録番号 (Invoice Registration Number / Qualified Invoice Issuer Number). Format: T + 13-digit corporate number. Example: T1234567890123. Standard rate: 10%, reduced 8%.
Japan introduced a Qualified Invoice System (インボイス制度) in October 2023. Registered businesses receive a 13-digit invoice registration number prefixed with T. The 8% reduced rate applies to food and non-alcoholic beverages. Japan's consumption tax (消費税) replaced the simpler sales tax in 1989.
Validate: https://www.taxid.dev/validate-vat/jp

## Iceland (IS) Local name: VSK-númer (Virðisaukaskattsnúmer). Format: IS + 5 or 6 digits. Example: IS123456. Standard rate: 24%, reduced 11%.
Iceland is part of the EEA but not the EU, so its VAT numbers are not in VIES. Iceland applies a 24% standard rate and 11% reduced rate (food, accommodation, books). The VSK-númer is 5 or 6 digits and is validated by RSK (the Icelandic Directorate of Internal Revenue).
Validate: https://www.taxid.dev/validate-vat/is

## Malaysia (MY) Local name: Sales and Service Tax (SST) Registration Number. Format: B + 10 digits. Example: B10000012345. Standard rate: 8%, reduced 0%.
Malaysia reintroduced the Sales and Service Tax (SST) in 2018 after replacing the previous GST system. Sales tax is 5–10% on goods; service tax is 8% (raised from 6% in March 2024). SST registration numbers start with B. Malaysia is a growing technology market and regional B2B hub in Southeast Asia.
Validate: https://www.taxid.dev/validate-vat/my

## South Korea (KR) Local name: 사업자등록번호 (Saeopja Deungrok Beonho — Business Registration Number). Format: 3 digits + - + 2 digits + - + 5 digits. Example: 123-45-67890. Standard rate: 10%, reduced 0%.
South Korea applies a flat 10% VAT (부가가치세) with no reduced rates. The 10-digit Business Registration Number is formatted as XXX-XX-XXXXX. Korea is a major technology market; companies like Samsung, LG, Kakao, and Naver require VAT validation for B2B transactions.
Validate: https://www.taxid.dev/validate-vat/kr

## Hong Kong (HK) Local name: Business Registration Number (BR Number). Format: 8 digits. Example: 12345678. Standard rate: 0%.
Hong Kong has no VAT or GST. Its standard rate is 0% — making it one of the few major financial centers without consumption tax. The Business Registration Number (BR) is an 8-digit identifier issued by the Companies Registry and IRD. HK is a critical hub for APAC B2B SaaS and fintech.
Validate: https://www.taxid.dev/validate-vat/hk

## Brazil (BR) Local name: CNPJ (Cadastro Nacional da Pessoa Jurídica). Format: 14 digits (often displayed as XX.XXX.XXX/XXXX-XX). Example: 11222333000181. Standard rate: 17%, reduced 12%, 7%.
Brazil has one of the world's most complex tax systems with multiple overlapping taxes (ICMS, ISS, PIS, COFINS). CNPJ is the primary company tax identifier, 14 digits with two check digits using modulo 11. Brazil is the largest economy in Latin America and a major B2B SaaS market.
Validate: https://www.taxid.dev/validate-vat/br

## Turkey (TR) Local name: VKN (Vergi Kimlik Numarası — Tax Identification Number). Format: 10 digits. Example: 1234567890. Standard rate: 20%, reduced 10%, 1%.
Turkey raised its standard VAT rate from 18% to 20% in July 2023. The VKN is a 10-digit tax identification number with a check digit algorithm. Turkey is a candidate EU country and a significant market for European B2B SaaS companies. The reduced 10% rate covers items like food, medicine, and certain services.
Validate: https://www.taxid.dev/validate-vat/tr

## Thailand (TH) Local name: เลขประจำตัวผู้เสียภาษี (Tax Identification Number / TIN). Format: 13 digits. Example: 1234567890123. Standard rate: 7%.
Thailand's VAT rate is currently 7% (temporarily reduced from the statutory 10% rate, in effect since 1997 and renewed periodically). The 13-digit TIN doubles as both corporate and individual identification. Thailand is a growing regional hub for B2B SaaS in Southeast Asia.
Validate: https://www.taxid.dev/validate-vat/th

## Indonesia (ID) Local name: NPWP (Nomor Pokok Wajib Pajak — Taxpayer Identification Number). Format: 15 digits (old format: XX.XXX.XXX.X-XXX.XXX). Example: 012345678901234. Standard rate: 11%, reduced 0%.
Indonesia raised its VAT rate from 10% to 11% in April 2022 (with a further increase to 12% planned). The NPWP is a 15-digit identifier transitioning to a 16-digit NIK-based format as part of tax ID reform. Indonesia is the fourth most populous country and the largest economy in Southeast Asia.
Validate: https://www.taxid.dev/validate-vat/id

---

# VAT / GST rates by country

## Austria — Umsatzsteuer (USt)
Standard rate: 20%. Reduced rates: 13%, 10%.
Austria has kept its 20% standard rate unchanged since 1984, making it one of the most stable VAT regimes in Europe. It is unusual in operating two reduced rates plus a 13% parking rate, and a special 19% rate applies in the Jungholz and Mittelberg border regions. Invoices above €10,000 must show the customer's UID number for input tax deduction.
Details: https://www.taxid.dev/vat-rates/at

## Belgium — BTW / TVA
Standard rate: 21%. Reduced rates: 12%, 6%.
Belgium applies 21% standard VAT with reduced rates of 12% and 6%, and is one of the few EU countries that still zero-rates daily newspapers. Demolition-and-reconstruction housing projects enjoy a 6% rate under a permanent scheme introduced in 2024. Belgian VAT returns are being migrated to the new "VAT chain" system with substitute returns for non-filers.
Details: https://www.taxid.dev/vat-rates/be

## Bulgaria — ДДС (Данък върху добавената стойност)
Standard rate: 20%. Reduced rates: 9%.
Bulgaria became the 21st member of the eurozone on 1 January 2026, so VAT amounts are now invoiced in euro rather than leva. The 20% standard rate has been stable since 1999 — one of the longest-unchanged rates in the EU — with a single 9% reduced rate centred on tourism. VAT returns are filed monthly with no quarterly option, unusual among smaller EU economies.
Details: https://www.taxid.dev/vat-rates/bg

## Cyprus — ΦΠΑ (Φόρος Προστιθέμενης Αξίας)
Standard rate: 19%. Reduced rates: 9%, 5%.
Cyprus charges 19% standard VAT — below the EU average — alongside 9% and 5% reduced rates, which supports its large international holding-company and shipping sectors. A special 5% rate applies to the acquisition or construction of a primary residence, subject to size limits tightened in 2023. The island's VAT law also covers the British Sovereign Base Areas of Akrotiri and Dhekelia.
Details: https://www.taxid.dev/vat-rates/cy

## Czech Republic — DPH (Daň z přidané hodnoty)
Standard rate: 21%. Reduced rates: 12%.
The Czech Republic simplified its system in January 2024 by merging two reduced rates into a single 12% band and moving books to a true 0% rate — a rarity in the EU. The 21% standard rate has held since 2013. Czech VAT payers must also file a separate monthly control statement (kontrolní hlášení) that cross-matches invoices between suppliers and customers.
Details: https://www.taxid.dev/vat-rates/cz

## Germany — Umsatzsteuer / Mehrwertsteuer (USt/MwSt)
Standard rate: 19%. Reduced rates: 7%.
Germany's 19% standard rate is among the lowest of the large EU economies and has not changed since 2007, apart from a six-month COVID cut in 2020. From January 2026 restaurant and catering food is back at the 7% reduced rate, reversing the post-pandemic return to 19%. The Kleinunternehmer small-business limits were raised to €25,000/€100,000 net in 2025, and B2B e-invoicing is being phased in from 2025 onwards.
Details: https://www.taxid.dev/vat-rates/de

## Denmark — Moms (Meromsætningsafgift)
Standard rate: 25%.
Denmark is the purest single-rate VAT system in the EU: 25% applies to virtually everything, with no reduced bands at all — only newspapers escape via a zero rate. That flat design dates from 1992 and makes Danish compliance unusually simple, but the registration threshold of DKK 50,000 is among the lowest in Europe. The VAT number is simply the company's CVR business register number with a DK prefix.
Details: https://www.taxid.dev/vat-rates/dk

## Estonia — Käibemaks (KM)
Standard rate: 24%. Reduced rates: 13%, 9%.
Estonia has raised VAT twice in two years — 20% to 22% in 2024 and to 24% in July 2025 — to fund defence spending, and the increase was made permanent in March 2025. Accommodation moved from 9% to 13% and press publications from 5% to 9% in January 2025. As a digital-first state, Estonia handles registration and filing entirely online through EMTA's e-services, typically within days.
Details: https://www.taxid.dev/vat-rates/ee

## Greece — ΦΠΑ (Φόρος Προστιθέμενης Αξίας)
Standard rate: 24%. Reduced rates: 13%, 6%.
Greece applies 24% standard VAT, but its most distinctive feature is geographic: five Aegean islands (Leros, Lesbos, Kos, Samos and Chios) enjoy rates reduced by 30%, a concession tied to the migration crisis and repeatedly extended. The country uses the EL prefix rather than GR in VIES, reflecting the Greek-language country name. Greece's myDATA e-books platform now pre-fills VAT returns from transmitted invoice data.
Details: https://www.taxid.dev/vat-rates/el

## Spain — IVA (Impuesto sobre el Valor Añadido)
Standard rate: 21%. Reduced rates: 10%.
Spain is one of the few EU countries with no VAT registration threshold at all — even a €1 sale triggers registration — though a use-based exemption for small businesses is under discussion. Large taxpayers must report invoice data to AEAT within four days under the SII real-time system. The Canary Islands sit outside EU VAT entirely, applying their own IGIC tax (7% general rate), while Ceuta and Melilla levy the IPSI instead.
Details: https://www.taxid.dev/vat-rates/es

## Finland — Arvonlisävero (ALV)
Standard rate: 25.5%. Reduced rates: 13.5%, 10%.
Finland's 25.5% standard rate, introduced in September 2024, is the second-highest in the EU after Hungary — and the only one expressed in half-points. The reduced-rate structure has been in constant motion: most 10% items jumped to 14% in 2025, and that band was then trimmed to 13.5% in January 2026. The åland Islands are excluded from the EU VAT area for goods, creating a tax border within Finland itself.
Details: https://www.taxid.dev/vat-rates/fi

## France — TVA (Taxe sur la Valeur Ajoutée)
Standard rate: 20%. Reduced rates: 10%, 5.5%.
France invented VAT in 1954, and its four-rate structure (20/10/5.5/2.1) remains one of the most layered in Europe — the 2.1% super-reduced rate for press and reimbursable medicines survives as a grandfathered exception. Corsica and the overseas departments apply their own lower rate schedules. A controversial plan to collapse the small-business thresholds into a single €25,000 limit was definitively repealed in November 2025 after protests from micro-entrepreneurs.
Details: https://www.taxid.dev/vat-rates/fr

## Croatia — PDV (Porez na dodanu vrijednost)
Standard rate: 25%. Reduced rates: 13%, 5%.
Croatia shares the EU's joint-highest 25% standard rate with Denmark and Sweden, a level set during the 2012 fiscal consolidation. The country adopted the euro in 2023 and raised its registration threshold to €60,000 in 2025, the most generous in the EU after Italy and France. Tourism, the backbone of the economy, benefits from the 13% rate on accommodation.
Details: https://www.taxid.dev/vat-rates/hr

## Hungary — ÁFA (Általános forgalmi adó)
Standard rate: 27%. Reduced rates: 18%, 5%.
Hungary's 27% standard rate has been the highest in the world since 2012. The counterweight is an aggressive 5% band covering medicines, books, internet access, district heating and new housing, plus an 18% middle rate for dairy and bakery staples. NAV's real-time invoice reporting (RTIR) system, mandatory since 2018, gives the authority same-day visibility of every domestic B2B invoice.
Details: https://www.taxid.dev/vat-rates/hu

## Ireland — VAT (Value-Added Tax)
Standard rate: 23%. Reduced rates: 13.5%, 9%.
Ireland retains one of the EU's broadest zero-rate baskets — most food, children's clothing, books and oral medicines are 0% under grandfathered pre-1991 rules that newer member states cannot replicate. The unusual 4.8% super-reduced rate applies solely to livestock. As the European base for many US tech firms, Ireland is disproportionately important in VIES B2B validation traffic, and its bi-monthly filing cycle is unique in the EU.
Details: https://www.taxid.dev/vat-rates/ie

## Italy — IVA (Imposta sul Valore Aggiunto)
Standard rate: 22%. Reduced rates: 10%, 5%.
Italy was the first country in the world to mandate universal B2B e-invoicing: since 2019 every domestic invoice must flow through the SdI exchange system, cutting its once-enormous VAT gap. The 22% standard rate is flanked by 10%, 5% and a grandfathered 4% on basic foods and publications. Small businesses below €85,000 can opt out of VAT entirely under the forfettario flat-tax regime.
Details: https://www.taxid.dev/vat-rates/it

## Lithuania — PVM (Pridėtinės vertės mokestis)
Standard rate: 21%. Reduced rates: 12%, 5%.
Lithuania raised its middle reduced rate from 9% to 12% in January 2026, touching books, accommodation, passenger transport and firewood, while keeping medicines and periodicals at 5%. The 21% standard rate dates from the 2009 crisis budget. As one of Europe's leading fintech licensing hubs, Lithuania sees heavy VAT registration activity from e-money and payment institutions serving the whole EU.
Details: https://www.taxid.dev/vat-rates/lt

## Luxembourg — TVA (Taxe sur la valeur ajoutée)
Standard rate: 17%. Reduced rates: 14%, 8%.
Luxembourg's 17% standard rate is the lowest in the EU, a deliberate policy that historically attracted Amazon, PayPal and other digital giants to book EU sales there before the 2015 place-of-supply reform. It still operates four rates including a 3% super-reduced band and a 14% parking rate on wines and fuels. The entire structure was cut by one point during 2023 as an anti-inflation measure — an EU first.
Details: https://www.taxid.dev/vat-rates/lu

## Latvia — PVN (Pievienotās vērtības nodoklis)
Standard rate: 21%. Reduced rates: 12%, 5%.
Latvia is a rare case of a country that cut its standard VAT rate after the financial crisis, trimming 22% to 21% in 2012 once austerity targets were met. A special 12% rate covers medicines and heating, while a 5% band supports books, periodicals and fresh produce typical of Latvian farming. The VAT number reuses the 11-digit personal or registration code, simplifying cross-checks against the business register.
Details: https://www.taxid.dev/vat-rates/lv

## Malta — VAT (Taxxa fuq il-Valur Miżjud)
Standard rate: 18%. Reduced rates: 7%, 5%.
Malta's 18% standard rate is tied with a handful of others as the EU's second-lowest, and the island zero-rates food and medicines outright. In 2024 it added an unusual fourth rate of 12% aimed squarely at its yacht-charter and private-healthcare niches. As a hub for iGaming and fintech licensing, Malta's VAT treatment of gambling and electronically supplied services is unusually well developed.
Details: https://www.taxid.dev/vat-rates/mt

## Netherlands — BTW (Belasting over de toegevoegde waarde)
Standard rate: 21%. Reduced rates: 9%.
The Netherlands pushed hotel and other short-stay accommodation from the 9% reduced rate to the full 21% standard rate in January 2026 — one of the sharpest single-category VAT increases in recent EU history, while culture, books and sport kept their reduced rate after a fierce parliamentary battle. Dutch VAT numbers carry a distinctive 'B' sub-number identifying entities within a fiscal unity. Rotterdam's port status makes the Dutch import-VAT deferment licence (Article 23) a major cash-flow tool for EU importers.
Details: https://www.taxid.dev/vat-rates/nl

## Poland — VAT (Podatek od towarów i usług, PTU)
Standard rate: 23%. Reduced rates: 8%, 5%.
Poland's 23% rate was introduced in 2011 as a temporary crisis measure and has simply never been reversed. The compliance regime is among Europe's most data-heavy: the JPK_V7 file merges the VAT return with a full SAF-T ledger, and the KSeF national e-invoicing platform becomes mandatory for large businesses in 2026. The registration threshold rose to PLN 240,000 in January 2026, partly to offset years of high inflation.
Details: https://www.taxid.dev/vat-rates/pl

## Portugal — IVA (Imposto sobre o Valor Acrescentado)
Standard rate: 23%. Reduced rates: 13%.
Portugal's VAT is regionally fragmented: the mainland charges 23/13/6, but Madeira applies 22/12/5 and the Azores just 16/9/4 — the lowest standard rate anywhere in the EU VAT area. The 23% mainland rate dates from the 2011 troika bailout. Portugal pioneered certified invoicing software: every invoice must come from AT-certified software with ATCUD codes and be reported via the monthly SAF-T file.
Details: https://www.taxid.dev/vat-rates/pt

## Romania — TVA (Taxa pe valoarea adăugată)
Standard rate: 21%. Reduced rates: 11%.
Romania reversed a decade of VAT cuts in August 2025, lifting the standard rate from 19% to 21% and collapsing the old 9% and 5% bands into a single 11% rate to plug one of the EU's largest budget deficits. A transitional 9% rate survives for some housing sales until August 2026. Romania persistently records the EU's widest VAT gap, which is driving rollout of mandatory RO e-Factura e-invoicing and SAF-T reporting.
Details: https://www.taxid.dev/vat-rates/ro

## Sweden — Moms (Mervärdesskatt)
Standard rate: 25%. Reduced rates: 12%, 6%.
Sweden's 25% rate has been fixed since the sweeping 1990–91 tax reform, sharing the EU's top spot with Denmark and Croatia. Unusually, prescription medicines are zero-rated rather than reduced-rated — a concession few EU states obtained. The 6% culture band covering books, newspapers and public transport reflects long-standing Nordic media policy, and Skatteverket consistently ranks among the world's most digitised tax agencies.
Details: https://www.taxid.dev/vat-rates/se

## Slovenia — DDV (Davek na dodano vrednost)
Standard rate: 22%. Reduced rates: 9.5%, 5%.
Slovenia raised VAT to 22% during the 2013 banking crisis as the price of avoiding an international bailout, and the rate has stuck. A separate 5% band was carved out in 2020 for books and publications, including digital editions. Wedged between Italy, Austria, Croatia and Hungary, Slovenia handles outsized transit-trade VAT flows relative to its two-million population, and mandatory B2B e-invoicing is scheduled for mid-2026.
Details: https://www.taxid.dev/vat-rates/si

## Slovakia — DPH (Daň z pridanej hodnoty)
Standard rate: 23%. Reduced rates: 19%, 5%.
Slovakia executed one of the EU's sharpest recent hikes, jumping from 20% to 23% in January 2025 and restructuring its reduced rates into 19% (most food, electricity) and 5% (essentials, medicines, accommodation). From 2026 foods high in sugar or salt are punitively re-rated at the full 23% — an early experiment in health-steered VAT. The IČ DPH number must pass a modulo-11 check, making format validation stricter than in most member states.
Details: https://www.taxid.dev/vat-rates/sk

## United Kingdom — VAT (Value Added Tax)
Standard rate: 20%. Reduced rates: 5%.
Since Brexit the UK runs its own VAT system: numbers are validated through HMRC's API rather than VIES, and imports from the EU are treated like any other imports, with postponed VAT accounting available. The zero-rate basket — most food, books, children's clothing, new homes — is among the broadest in the world. Northern Ireland remains inside the EU VAT area for goods (prefix XI), a unique dual arrangement under the Windsor Framework.
Details: https://www.taxid.dev/vat-rates/gb

## Australia — GST (Goods and Services Tax)
Standard rate: 10%.
Australia's GST has stayed at exactly 10% since its introduction in 2000 — any change requires the unanimous agreement of all states and territories, which has proven politically impossible. Instead of reduced rates, whole categories like basic food, health and education are "GST-free" (zero-rated). Foreign sellers of digital products and low-value goods to Australian consumers must register once sales exceed AUD 75,000, under rules that pioneered the taxation of inbound e-commerce.
Details: https://www.taxid.dev/vat-rates/au

## Norway — MVA (Merverdiavgift)
Standard rate: 25%. Reduced rates: 15%, 12%.
Norway matches the EU's top standard rate at 25% despite never joining the Union, with 15% on food and 12% on transport and tourism. Books and newspapers — print and digital — are fully zero-rated, a cornerstone of Norwegian media policy, and EV purchases were long VAT-exempt to drive the world's highest electric-car adoption. Foreign e-commerce sellers use the simplified VOEC scheme for consignments under NOK 3,000.
Details: https://www.taxid.dev/vat-rates/no

## Switzerland — MWST / TVA / IVA
Standard rate: 8.1%. Reduced rates: 2.6%, 3.8%.
Switzerland has the lowest standard VAT rate of any European country at 8.1%, set by federal referendum — the 2024 increase was approved by popular vote to shore up the AHV pension fund. The registration test is unusual: a foreign company owes Swiss VAT registration if its worldwide turnover exceeds CHF 100,000, even on its first franc of Swiss sales. The special 3.8% lodging rate covers the hotel sector, and Liechtenstein applies Swiss VAT law under treaty.
Details: https://www.taxid.dev/vat-rates/ch

## Canada — GST / HST (Goods and Services Tax / Harmonized Sales Tax)
Standard rate: 5%.
Canada layers consumption taxes: the 5% federal GST applies everywhere, but five provinces blend it into a single HST of 13–15%, while British Columbia, Saskatchewan and Manitoba charge separate PST and Quebec administers its own 9.975% QST. The effective rate therefore ranges from 5% in Alberta to 15% in the Atlantic provinces. Since 2021, non-resident digital platforms must register under a simplified regime once Canadian B2C sales pass CAD 30,000.
Details: https://www.taxid.dev/vat-rates/ca

## India — GST (Goods and Services Tax)
Standard rate: 18%. Reduced rates: 5%, 0%.
India's "GST 2.0" reform of September 2025 was the biggest overhaul since the tax launched in 2017: the 12% and 28% slabs were scrapped, moving ~99% of former 12% items down to 5% and most 28% items to 18%, while a new 40% demerit rate hits luxury cars, tobacco and sugary drinks. GST is split between centre and states (CGST/SGST or IGST inter-state), and the 15-character GSTIN embeds the taxpayer's PAN and state code. E-invoicing through the IRP portal is mandatory above ₹5 crore turnover.
Details: https://www.taxid.dev/vat-rates/in

## Singapore — GST (Goods and Services Tax)
Standard rate: 9%.
Singapore completed a two-step GST rise to 9% in January 2024, cushioned by an assurance package of household vouchers — the city-state's first rate change since 2007. The SGD 1 million registration threshold is one of the highest in the world, keeping most small businesses outside the system. Overseas vendors selling digital and imported services to Singapore consumers must register under the Overseas Vendor Registration regime once global turnover tops SGD 1 million and local B2C sales exceed SGD 100,000.
Details: https://www.taxid.dev/vat-rates/sg

## New Zealand — GST (Goods and Services Tax)
Standard rate: 15%.
New Zealand's GST is the textbook "pure" consumption tax cited in tax-policy literature worldwide: 15% on virtually everything, including food and government charges, with almost no exemptions or reduced rates. That breadth lets it collect more revenue per rate point than nearly any other VAT/GST. New Zealand was also an early mover on taxing the digital economy, capturing foreign digital services in 2016 and low-value imported goods in 2019.
Details: https://www.taxid.dev/vat-rates/nz

## South Africa — VAT (Value-Added Tax / BTW)
Standard rate: 15%. Reduced rates: 0%.
South Africa's planned 2025 VAT increase to 15.5% collapsed spectacularly: the proposal split the governing coalition and was withdrawn weeks before taking effect, keeping the rate at 15%. The zero-rated basket of 19 staple foods, from maize meal to eggs, is the system's main equity tool. Foreign suppliers of electronic services must register once their South African sales pass ZAR 1 million — one of Africa's earliest digital-VAT regimes, dating to 2014.
Details: https://www.taxid.dev/vat-rates/za

## United Arab Emirates — VAT (ضريبة القيمة المضافة)
Standard rate: 5%. Reduced rates: 0%.
The UAE introduced VAT only in 2018, as part of a GCC-wide framework, and has held the line at 5% — among the lowest VAT rates in the world — even as neighbouring Saudi Arabia tripled its rate. Designated free zones receive special treatment, with qualifying goods transactions outside the scope of VAT. The FTA's EmaraTax platform handles registration and filing, and e-invoicing is being phased in from 2026 under the "Peppol-based" UAE model.
Details: https://www.taxid.dev/vat-rates/ae

## Mexico — IVA (Impuesto al Valor Agregado)
Standard rate: 16%. Reduced rates: 0%.
Mexico zero-rates food and medicines across the board — far more broadly than most VAT systems — which keeps its effective VAT collection among the OECD's lowest despite the 16% headline rate. An 8% preferential rate applies along the northern and southern border strips to keep prices competitive with US neighbours. Every invoice must be a CFDI digital tax receipt stamped through SAT, making Mexico's e-invoicing mandate one of the oldest and strictest in the world.
Details: https://www.taxid.dev/vat-rates/mx

## Japan — 消費税 (Shōhizei)
Standard rate: 10%. Reduced rates: 8%.
Japan's consumption tax (shōhizei) reached 10% in 2019 after two politically bruising increases, with food and non-alcoholic drinks held at 8% — but only for takeaway; the same bento eaten in the shop is taxed at 10%. The 2023 Qualified Invoice System was a structural shift: input credits now require a T-prefixed registration number, pulling millions of small businesses into registration. Liability is assessed on a base period two years back, a mechanism unique to Japan.
Details: https://www.taxid.dev/vat-rates/jp

## Iceland — VSK (Virðisaukaskattur)
Standard rate: 24%. Reduced rates: 11%.
Iceland trimmed its standard rate to 24% in 2015 while pushing the reduced rate up to 11%, narrowing the gap between bands to curb classification gaming. The 11% rate is the backbone of the tourism economy, covering hotels and travel services for the island's two-million-plus annual visitors. As an EEA member outside the EU, Icelandic VSK numbers are not in VIES and must be checked against Skatturinn's register.
Details: https://www.taxid.dev/vat-rates/is

## Malaysia — SST (Sales and Service Tax / Cukai Jualan dan Perkhidmatan)
Standard rate: 8%. Reduced rates: 0%.
Malaysia is the rare country that introduced a modern GST and then repealed it: the 6% GST lasted only from 2015 to 2018 before being scrapped after a change of government, restoring the older single-stage SST. Today service tax runs at 8% (6% for food and telecoms) and sales tax at 5–10% on manufactured and imported goods, with the scope expanded substantially in July 2025 to cover more services. Because SST is single-stage, there is no input-credit mechanism — a key difference from VAT/GST systems.
Details: https://www.taxid.dev/vat-rates/my

## South Korea — 부가가치세 (Bugagachise)
Standard rate: 10%. Reduced rates: 0%.
South Korea adopted Asia's first full VAT in 1977 and has never moved the 10% rate — one of the longest-unchanged rates in the world. Compliance is hyper-digitised: electronic tax invoices through the NTS system are mandatory for corporations, feeding pre-filled returns. Foreign providers of digital services to Korean consumers have had to register and charge VAT since 2015, and "simplified taxpayer" status eases the burden for the smallest sole traders.
Details: https://www.taxid.dev/vat-rates/kr

## Hong Kong — No VAT/GST levied
Standard rate: 0%.
Hong Kong levies no VAT, GST or sales tax of any kind — one of the only major trading economies in the world without a consumption tax. A 5% GST was proposed in 2006 but abandoned within months under public pressure, and the idea resurfaces periodically when fiscal deficits widen. Government revenue rests instead on profits tax, salaries tax, stamp duty and land premiums. For cross-border sellers this means no registration, no invoicing rules and no import VAT — though Hong Kong businesses selling into other countries must still register there.
Details: https://www.taxid.dev/vat-rates/hk

## Brazil — ICMS / IPI / PIS / COFINS (transitioning to IBS / CBS)
Standard rate: 17%. Reduced rates: 12%, 7%.
Brazil is mid-flight through the world's largest VAT reform: the notoriously complex stack of ICMS (state), ISS (municipal), IPI, PIS and COFINS is being replaced by a dual VAT — federal CBS and shared IBS — phased in from 2026 (test rates of 0.9% + 0.1% this year) until full operation in 2033. The combined target rate is expected around 26–28%, which would be among the highest in the world. Until then, the existing ICMS averages ~17–20% by state and inter-state rates of 7% and 12% still apply.
Details: https://www.taxid.dev/vat-rates/br

## Turkey — KDV (Katma Değer Vergisi)
Standard rate: 20%. Reduced rates: 10%, 1%.
Türkiye raised its standard KDV rate from 18% to 20% in July 2023 as part of post-election fiscal tightening, with the middle rate moving to 10% and the 1% super-low band for staples like bread kept intact. There is no registration threshold — even the smallest trader must register before the first sale. Non-resident digital service providers have had to register and charge Turkish VAT on B2C sales since 2018 ('VAT No. 3' regime).
Details: https://www.taxid.dev/vat-rates/tr

## Thailand — ภาษีมูลค่าเพิ่ม (VAT)
Standard rate: 7%.
Thailand's VAT has a statutory rate of 10%, but a "temporary" reduction to 7% — first granted during the 1997 Asian financial crisis — has been renewed by royal decree every year for nearly three decades, making the 7% rate one of tax policy's most durable temporary measures. Foreign e-service providers above THB 1.8 million in Thai B2C sales must register under the VES regime introduced in 2021. Exports and international transport are zero-rated rather than exempt, preserving input credits.
Details: https://www.taxid.dev/vat-rates/th

## Indonesia — PPN (Pajak Pertambahan Nilai)
Standard rate: 11%. Reduced rates: 0%.
Indonesia's 2025 VAT change is a study in political compromise: the statutory PPN rate rose to 12%, but a last-minute regulation set the tax base at 11/12 of the price for everything except luxury goods, leaving the effective rate at 11% for ordinary purchases. The PKP registration threshold of IDR 4.8 billion is among the highest in the world relative to income. Foreign digital platforms have collected PPN on sales to Indonesian consumers since 2020.
Details: https://www.taxid.dev/vat-rates/id

## Ukraine — ПДВ (Податок на додану вартість)
Standard rate: 20%. Reduced rates: 14%, 7%.
Ukraine has kept its VAT system running through wartime, with the 20% standard rate unchanged and the SAF-T-style electronic VAT administration system (SEA VAT) still blocking invoices that lack registered VAT credit cover. The unusual 14% band applies to grain and oilseed supplies, reflecting the weight of agriculture in exports. Non-resident providers of digital services must register and charge 20% VAT under the 2022 "Google tax" rules.
Details: https://www.taxid.dev/vat-rates/ua

## Serbia — PDV (Porez na dodatu vrednost)
Standard rate: 20%. Reduced rates: 10%.
Serbia pairs a 20% standard rate with one of the region's most advanced compliance stacks: the SEF e-invoicing platform has been mandatory for all B2B transactions since 2023, and electronic VAT recording (eEvidencija) extends it further. The 10% reduced rate covers an unusually broad basket including the first sale of new apartments. As an EU candidate, Serbia continues aligning its PDV law with the VAT Directive.
Details: https://www.taxid.dev/vat-rates/rs

## Bosnia and Herzegovina — PDV (Porez na dodatu vrijednost)
Standard rate: 17%.
Bosnia and Herzegovina runs one of Europe's simplest VAT designs: a single 17% rate with no reduced bands, administered at the state level by the Indirect Taxation Authority even though most other taxes are split between the two entities and Brčko District. The rate has never changed since VAT was introduced in 2006, and the 17% level is the lowest standard VAT rate in the Balkans. Proposals for a reduced food rate resurface regularly but have never passed.
Details: https://www.taxid.dev/vat-rates/ba

## North Macedonia — ДДВ (Данок на додадена вредност)
Standard rate: 18%. Reduced rates: 10%, 5%.
North Macedonia's 18% standard rate sits at the low end of the Balkans, and its 5% band is notably broad — covering computers and software alongside food and medicines, a legacy of early-2000s digitisation policy. The 10% middle rate was carved out for hospitality after the pandemic. As an EU candidate the country is gradually aligning its DDV law with the EU VAT Directive.
Details: https://www.taxid.dev/vat-rates/mk

## Albania — TVSH (Tatimi mbi Vlerën e Shtuar)
Standard rate: 20%. Reduced rates: 6%.
Albania's 20% TVSH comes with a strikingly high registration threshold of ALL 10 million, keeping much of its small-business economy outside the VAT net. The 6% reduced rate is a deliberate tourism subsidy covering hotels and agritourism. Albania was an early adopter of real-time invoice reporting in the region: the 2021 "fiskalizimi" reform requires every invoice to be cleared through the tax administration's platform at the moment of issue.
Details: https://www.taxid.dev/vat-rates/al

## Montenegro — PDV (Porez na dodatu vrijednost)
Standard rate: 21%. Reduced rates: 15%, 7%.
Montenegro uses the euro without being an EU or eurozone member, so its VAT amounts are already euro-denominated ahead of accession. In January 2025 it inserted a new 15% middle band — moving books, hotels and restaurant services up from 7% — as part of fiscal consolidation tied to its EU candidacy. Tourism dominates the economy, which is why accommodation kept a preferential rate rather than moving to the full 21%.
Details: https://www.taxid.dev/vat-rates/me

## Moldova — TVA (Taxa pe valoarea adăugată)
Standard rate: 20%. Reduced rates: 12%, 8%.
Moldova's 20% TVA features a dedicated 12% band for the hospitality sector — introduced as COVID relief and made permanent — alongside an 8% rate anchored on bread, dairy and medicines. As an EU candidate country, Moldova is progressively transposing the EU VAT Directive, including OSS-style rules for cross-border e-commerce planned in its accession roadmap. Wine production, a key export, benefits from zero-rating on external sales.
Details: https://www.taxid.dev/vat-rates/md

## Georgia — დღგ (damatebuli ghirebulebis gadasakhadi)
Standard rate: 18%.
Georgia charges a flat 18% VAT with no reduced rates, but its 2021 VAT code rewrite aligned definitions, place-of-supply and exemption rules with the EU Directive under the EU Association Agreement — unusual for a non-candidate at the time. The country's flagship Estonian-style profit tax means VAT is the main recurring tax most companies deal with. Non-resident digital service providers have been required to register and charge 18% on B2C sales since 2021.
Details: https://www.taxid.dev/vat-rates/ge

## Armenia — ԱԱՀ (Avelats’vats arzheki hark)
Standard rate: 20%.
Armenia's flat 20% VAT coexists with a generous turnover-tax regime: businesses under AMD 115 million a year can pay a low percentage-of-revenue tax instead of VAT, one of the highest opt-out ceilings in the region. The booming IT sector benefits from zero-rating of services exported to non-residents. Since 2022, non-resident e-service providers must register and charge Armenian VAT on B2C sales.
Details: https://www.taxid.dev/vat-rates/am

## Azerbaijan — ƏDV (Əlavə dəyər vergisi)
Standard rate: 18%.
Azerbaijan applies a flat 18% ƏDV and runs one of the more inventive anti-fraud incentives anywhere: consumers get part of the VAT refunded to their bank cards when they request fiscal receipts for cashless purchases, a scheme designed to squeeze the cash economy. Oil-sector PSA contractors operate under separate tax protocols outside the standard VAT regime. Foreign e-commerce platforms selling to Azerbaijani consumers fall under VAT-at-source withholding by local banks.
Details: https://www.taxid.dev/vat-rates/az

## Russia — НДС (Налог на добавленную стоимость)
Standard rate: 22%. Reduced rates: 10%.
Russia raised its standard VAT to 22% on 1 January 2026 — the second 2-point hike in seven years — to finance a widening wartime budget deficit, while keeping the 10% rate on socially sensitive goods. Simultaneously, the income ceiling that exempted simplified-regime (USN) small businesses from VAT was cut drastically, dragging hundreds of thousands of small firms into VAT for the first time. Russia pioneered automated VAT gap control: the ASK NDS-2 system cross-matches every invoice in the country in near-real time.
Details: https://www.taxid.dev/vat-rates/ru

## Israel — מע"מ (Ma'am — Mas Erech Musaf)
Standard rate: 18%.
Israel raised VAT back to 18% in January 2025 as part of a war-driven budget package, reversing the 2015 cut. Unusually, fresh fruit and vegetables are zero-rated entirely, and the resort city of Eilat is a VAT-free zone under its free-trade-area law. The phased "Israel Invoices" clearance model now requires allocation numbers from the Tax Authority for B2B invoices above a falling threshold — a real-time anti-fraud control inspired by Latin American clearance systems.
Details: https://www.taxid.dev/vat-rates/il

## Saudi Arabia — ضريبة القيمة المضافة (VAT)
Standard rate: 15%.
Saudi Arabia executed the sharpest VAT increase in modern history, tripling the rate from 5% to 15% overnight in July 2020 when oil revenues collapsed. Officials have repeatedly floated an eventual reduction, but 15% remains the rate underpinning Vision 2030's non-oil revenue targets. ZATCA's FATOORA e-invoicing mandate — clearance-based for B2B since 2023 and rolling out in waves by turnover — is the most advanced in the Gulf, and real-estate transactions are carved out into a separate 5% transfer tax.
Details: https://www.taxid.dev/vat-rates/sa

## Qatar — No VAT levied (GCC framework signed, implementation pending)
No single national rate.
Qatar has signed the GCC VAT Framework Agreement, which commits members to a 5% VAT, but nearly a decade on it still has not implemented it — gas revenues have kept the fiscal pressure low. The only consumption levy in force is a 100%/50% excise tax on tobacco, energy drinks and carbonated drinks. Businesses should monitor the General Tax Authority: implementing legislation has been drafted, and Qatar is widely expected to follow Oman as the next GCC adopter when revenue needs demand it.
Details: https://www.taxid.dev/vat-rates/qa

## Kuwait — No VAT levied (GCC framework signed, implementation pending)
No single national rate.
Kuwait is the GCC member furthest from implementing VAT: successive governments have shelved the bill in the face of strong parliamentary opposition, leaving the country with no VAT, no general sales tax and minimal excise coverage. A 15% corporate tax on multinationals aligned to the OECD Pillar Two rules took effect in 2025, signalling that broader tax reform — including the GCC-agreed 5% VAT — is back on the agenda as oil-revenue dependence becomes harder to sustain.
Details: https://www.taxid.dev/vat-rates/kw

## Oman — ضريبة القيمة المضافة (VAT)
Standard rate: 5%.
Oman became the fourth Gulf state to implement VAT in April 2021, holding to the GCC-agreed 5% rate and cushioning the impact by zero-rating a 93-item basket of basic foods. Crude oil and gas supplies are zero-rated, reflecting the sector's export weight. The rate has survived fiscal-balance programmes without increase, and e-invoicing is on the Tax Authority's roadmap following the Saudi model.
Details: https://www.taxid.dev/vat-rates/om

## Bahrain — ضريبة القيمة المضافة (VAT)
Standard rate: 10%.
Bahrain doubled its VAT to 10% in January 2022 — the second Gulf state after Saudi Arabia to break above the GCC framework's 5% — as part of an IMF-watched fiscal balance programme for the most oil-revenue-strapped GCC economy. Its zero-rate basket is broader than its neighbours', extending to healthcare, education and domestic transport rather than merely exempting them, which preserves input-credit recovery for those sectors.
Details: https://www.taxid.dev/vat-rates/bh

## Jordan — ضريبة المبيعات العامة (General Sales Tax)
Standard rate: 16%.
Jordan's 16% General Sales Tax operates like a VAT with input credits, but layers a ladder of special rates (1%–10%) on listed essentials rather than one clean reduced band — a structure repeatedly reshaped under IMF programmes. A parallel "special tax" applies excise-style surcharges to cars, fuel, alcohol and tobacco. The national e-invoicing platform (JoFotara) became mandatory for deducting business expenses in 2025, tightening enforcement.
Details: https://www.taxid.dev/vat-rates/jo

## Lebanon — TVA / ضريبة القيمة المضافة
Standard rate: 11%.
Lebanon's 11% VAT has survived a sovereign default, a banking collapse and a currency that lost more than 95% of its value — though collections cratered as the cash economy took over. Since 2023 VAT on imports and many domestic supplies is calculated at the Sayrafa/market exchange rate rather than the defunct official peg, effectively re-basing the tax in real terms. Essential goods including food, books, medicines and agricultural inputs are exempt.
Details: https://www.taxid.dev/vat-rates/lb

## Egypt — ضريبة القيمة المضافة (VAT)
Standard rate: 14%. Reduced rates: 5%.
Egypt swapped its old general sales tax for a true VAT in 2016 under an IMF programme, stepping the rate from 13% to 14% within a year. Professional and consultancy services carry a special 10% "schedule tax" rate, and machinery for production gets 5% — a deliberate industrial-policy tilt. Egypt was an African e-invoicing pioneer: B2B e-invoices through the ETA platform have been mandatory since 2023, with e-receipts following for B2C, and non-resident digital service providers must register under a simplified vendor regime.
Details: https://www.taxid.dev/vat-rates/eg

## Nigeria — VAT (Value Added Tax)
Standard rate: 7.5%. Reduced rates: 0%.
Nigeria's 7.5% is one of the lowest VAT rates in the world, and the sweeping 2026 Tax Reform Acts kept it there after a proposed increase was dropped in parliament. The reform still changed the system fundamentally: input VAT can now be recovered on services and fixed assets (previously only on resold goods), essentials were zero-rated rather than exempted, and the federal tax agency was rebranded the Nigeria Revenue Service. VAT revenue is shared between federal, state and local governments under a contested derivation formula.
Details: https://www.taxid.dev/vat-rates/ng

## Kenya — VAT (Value Added Tax)
Standard rate: 16%. Reduced rates: 0%.
Kenya's 16% VAT is enforced through one of Africa's most aggressive digitisation drives: the eTIMS system requires every business expense to be backed by an electronically transmitted invoice to be deductible, effectively making e-invoicing universal. The 2023 move of fuel from 8% to 16% was among the most contested tax measures in recent Kenyan politics. Kenya also taxes the digital economy hard — non-resident digital service providers must register and charge 16% VAT, alongside a separate digital service levy regime.
Details: https://www.taxid.dev/vat-rates/ke

## Ghana — VAT (Value Added Tax) + NHIL/GETFL levies
Standard rate: 15%.
Ghana's headline 15% VAT is only part of the bill: the NHIL (2.5%) and GETFund (2.5%) levies stack on top, producing a 20% effective rate after the 2026 budget abolished the 1% COVID-19 levy that had pushed the combined burden to 21.9%. The same reform scrapped the 3% flat-rate scheme for retailers and nearly quadrupled the registration threshold to GHS 750,000, pulling small traders out of the net. The GRA's e-VAT invoicing system is being phased in for large taxpayers.
Details: https://www.taxid.dev/vat-rates/gh

## Morocco — TVA / الضريبة على القيمة المضافة
Standard rate: 20%. Reduced rates: 10%.
Morocco just completed a three-year VAT simplification: the 2024 Finance Law phased the old 7% and 14% intermediate rates into a two-rate system of 20% and 10% by 2026, with utilities like water and electricity migrating in annual steps. Basic staples (bread, couscous, milk) are exempt outright. The reform also introduced VAT withholding by large customers on supplier invoices — an anti-fraud device borrowed from Latin America — and non-resident digital platforms must register for Moroccan VAT.
Details: https://www.taxid.dev/vat-rates/ma

## Tunisia — TVA / الأداء على القيمة المضافة
Standard rate: 19%. Reduced rates: 13%, 7%.
Tunisia's 19% standard rate dates from the 2018 austerity budget that followed its IMF agreement, sitting atop reduced bands of 13% and 7%. Registration is tied to activity rather than turnover — businesses under the réel regime register from the start, while a forfait regime covers micro-traders. Exporters and companies in offshore regimes have historically enjoyed deep VAT advantages, a structural feature of Tunisia's dual onshore/offshore economy.
Details: https://www.taxid.dev/vat-rates/tn

## Algeria — TVA / الرسم على القيمة المضافة
Standard rate: 19%. Reduced rates: 9%.
Algeria raised its TVA to 19% in the 2017 finance law when oil revenues slumped, and the rate has held since. The 9% band notably covers internet access — a digital-inclusion subsidy unusual in the region. Hydrocarbon activities, the heart of the economy, sit largely outside the ordinary VAT regime under sector-specific taxation, and the import-heavy consumer market means much VAT is collected at customs.
Details: https://www.taxid.dev/vat-rates/dz

## Ivory Coast — TVA (Taxe sur la valeur ajoutée)
Standard rate: 18%. Reduced rates: 9%.
Côte d'Ivoire anchors the WAEMU monetary zone's largest economy with an 18% TVA — the rate band (15–20%) is set regionally by WAEMU directive, constraining national rate-setting. The 9% reduced rate targets staples like milk and pasta plus solar equipment. The DGI's e-invoicing platform (FNE) began rolling out in 2025, putting Côte d'Ivoire among West Africa's e-invoicing front-runners, and cocoa exports — the world's largest — are zero-rated.
Details: https://www.taxid.dev/vat-rates/ci

## Tanzania — VAT (Kodi ya Ongezeko la Thamani)
Standard rate: 18%. Reduced rates: 0%.
Tanzania charges 18% VAT on the mainland, while semi-autonomous Zanzibar administers its own separate VAT law at the same rate — invoices and registrations do not carry across, a trap for businesses operating on both sides. The 2015 VAT Act trimmed a notoriously long exemption list, though agriculture and tourism carve-outs keep returning in annual finance acts. Non-resident providers of digital services must register under a simplified regime introduced in 2022.
Details: https://www.taxid.dev/vat-rates/tz

## Uganda — VAT (Value Added Tax)
Standard rate: 18%. Reduced rates: 0%.
Uganda's 18% VAT has been stable for nearly three decades, but its enforcement transformed with EFRIS — the Electronic Fiscal Receipting and Invoicing Solution that requires receipts and invoices to be generated through URA systems in real time, with penalties for traders who bypass it. Non-resident digital service providers (streaming, advertising, marketplaces) must register and account for 18% VAT under rules effective since 2023, complementing a separate digital services tax.
Details: https://www.taxid.dev/vat-rates/ug

## United States — State and local sales taxes (no federal VAT)
No single national rate.
The United States is the only major economy without a VAT or GST. Instead, 45 states plus DC levy single-stage retail sales taxes, with combined state-and-local rates ranging from 0% (Delaware, Montana, New Hampshire, Oregon, and statewide-exempt Alaska) to over 10% in parts of Louisiana. There is no input-credit mechanism: tax applies once, at the final retail sale, and B2B purchases for resale are exempt via resale certificates. Since the 2018 Wayfair ruling, remote and foreign sellers must register state-by-state once they cross economic nexus thresholds — typically USD 100,000 of in-state sales — making US compliance a 50-jurisdiction patchwork rather than a single registration.
Details: https://www.taxid.dev/vat-rates/us

## Argentina — IVA (Impuesto al Valor Agregado)
Standard rate: 21%. Reduced rates: 10.5%.
Argentina's 21% IVA is augmented by a punitive 27% rate on utilities supplied to businesses and softened by 10.5% on staples and housing construction — and the whole system is wrapped in a web of withholding and perception regimes that often collect the tax before a sale even settles. The tax agency AFIP was dissolved and replaced by ARCA in late 2024. Digital services from foreign platforms have been subject to 21% IVA collected via payment cards since 2018.
Details: https://www.taxid.dev/vat-rates/ar

## Chile — IVA (Impuesto al Valor Agregado)
Standard rate: 19%.
Chile was the world's e-invoicing pioneer — electronic invoicing through the SII began in 2003 and became universal in 2018, so the authority pre-fills most VAT returns from invoice data. The 19% rate applies with no reduced bands, and since 2023 it covers virtually all services after Chile abolished one of the world's last broad service exemptions. Foreign digital platforms have collected Chilean IVA on B2C sales since 2020 under a simplified regime that now spans marketplaces and low-value imports.
Details: https://www.taxid.dev/vat-rates/cl

## Colombia — IVA (Impuesto sobre las Ventas)
Standard rate: 19%. Reduced rates: 5%.
Colombia's 19% IVA arrived with the 2017 structural reform and coexists with a parallel "national consumption tax" on restaurants and mobile services — two overlapping indirect taxes that trip up foreign entrants. The 5% band backs an industrial-policy mix from coffee to electric vehicles. DIAN's UBL-based e-invoicing mandate is one of Latin America's strictest, and three day-long "IVA-free days" a year suspend the tax on selected consumer goods, a uniquely Colombian retail event.
Details: https://www.taxid.dev/vat-rates/co

## Peru — IGV (Impuesto General a las Ventas)
Standard rate: 18%.
Peru's 18% headline rate is actually two taxes — a 16% IGV plus a 2% municipal promotion tax (IPM) collected together. Its signature anti-evasion device is the detracciones system: customers in designated sectors must deposit a slice of the invoice into the supplier's state-controlled bank account, usable only to pay taxes. A temporary 8% rate supports small restaurants and hotels, and foreign digital services have been subject to IGV withholding since late 2024.
Details: https://www.taxid.dev/vat-rates/pe

## Ecuador — IVA (Impuesto al Valor Agregado)
Standard rate: 15%. Reduced rates: 0%.
Ecuador raised IVA from 12% to 15% in April 2024 — initially framed as temporary funding for the war on drug gangs, then consolidated as the permanent rate. The economy is fully dollarised, so VAT amounts are set directly in US dollars. An unusually broad zero-rate basket covers food staples, medicines and books, and holiday-period decrees have occasionally trimmed the rate for tourism services to 8% on specific weekends.
Details: https://www.taxid.dev/vat-rates/ec

## Uruguay — IVA (Impuesto al Valor Agregado)
Standard rate: 22%. Reduced rates: 10%.
Uruguay carries Latin America's joint-highest standard IVA at 22%, but actively discounts it: card payments for restaurants and small purchases earn automatic IVA rebates of several points, a financial-inclusion incentive that made electronic payment ubiquitous. The 10% minimum rate covers staples and hotels, while tourists enjoy temporary zero-rating on gastronomy and car rentals each high season. Uruguay was also early to tax foreign digital services, applying IVA to platforms like Netflix since 2018.
Details: https://www.taxid.dev/vat-rates/uy

## Paraguay — IVA (Impuesto al Valor Agregado)
Standard rate: 10%. Reduced rates: 5%.
Paraguay's 10% IVA is the lowest standard rate in South America, the centrepiece of a deliberately minimal "triple 10" tax model (10% IVA, 10% corporate, 10% personal) used to attract investment and maquila manufacturing. Real estate transactions enjoy the 5% rate on a reduced base, producing one of the region's lightest property tax burdens. Foreign digital platforms have IVA withheld by card issuers, and the new DNIT merged tax and customs administration in 2023.
Details: https://www.taxid.dev/vat-rates/py

## Bolivia — IVA (Impuesto al Valor Agregado)
Standard rate: 13%.
Bolivia's 13% IVA hides a quirk found almost nowhere else: the tax is calculated "inside" the price (tax-inclusive base), so the effective rate on the net price is about 14.94%. The rate has not moved since the 1986 hyperinflation stabilisation programme. Compliance has a consumer-facing twist too — individuals recover part of the IVA on receipts through the RC-IVA credit against payroll tax, incentivising Bolivians to demand invoices.
Details: https://www.taxid.dev/vat-rates/bo

## Dominican Republic — ITBIS (Impuesto sobre Transferencias de Bienes Industrializados y Servicios)
Standard rate: 18%. Reduced rates: 16%.
The Dominican Republic calls its VAT "ITBIS" and runs it at 18% with an unusual 16% second band for a short list of named groceries like yogurt, coffee and chocolate. Tourism — the economic engine — benefits from exemptions under CONFOTUR-approved projects. The DGII is phasing in mandatory e-invoicing (e-CF) through 2026 by taxpayer size, and foreign digital services are slated for ITBIS withholding via payment processors.
Details: https://www.taxid.dev/vat-rates/do

## Costa Rica — IVA (Impuesto al Valor Agregado)
Standard rate: 13%. Reduced rates: 4%, 2%, 1%.
Costa Rica converted its old sales tax into a full IVA in 2019, keeping the 13% headline but finally taxing services — and softening the blow with a four-tier rate ladder (13/4/2/1) that gives the basic food basket a token 1%. Electronic invoicing predates the IVA itself and is universal. Cross-border digital services are captured by card-issuer withholding on payments to listed foreign platforms, an approach later copied elsewhere in the region.
Details: https://www.taxid.dev/vat-rates/cr

## Guatemala — IVA (Impuesto al Valor Agregado)
Standard rate: 12%.
Guatemala's 12% IVA has been untouched since 2001, making it one of Central America's most stable — and lowest — rates. A constitutional earmark sends a fixed slice of IVA revenue to municipalities and social funds, which is why rate-change proposals rarely survive. Small traders under GTQ 150,000 a year can instead pay a 5% turnover tax as pequeños contribuyentes, and the FEL e-invoicing regime became universal in 2023.
Details: https://www.taxid.dev/vat-rates/gt

## Panama — ITBMS (Impuesto a la Transferencia de Bienes Corporales Muebles y la Prestación de Servicios)
Standard rate: 7%.
Panama's 7% ITBMS is among the lowest VAT-type rates in the Americas, fitting its dollarised, services-and-logistics economy built around the Canal and the Colón Free Zone — where re-exports move untaxed. Higher rates of 10% apply to alcohol and hotel accommodation and 15% to tobacco. Food, medicines and school supplies are exempt outright, and businesses earning under USD 36,000 a year stay outside the system entirely.
Details: https://www.taxid.dev/vat-rates/pa

## China — 增值税 (Zēngzhíshuì)
Standard rate: 13%. Reduced rates: 9%, 6%.
China's VAT — the world's largest by revenue — gained a statutory foundation on 1 January 2026 when the country's first VAT Law took effect, replacing "interim" regulations that had governed for three decades; rates stayed at 13/9/6. The dual-track system splits taxpayers into general (full input credit) and small-scale (3% levy, no credits) categories. Export refunds are a trade-policy lever: refund rates vary by product and are adjusted to steer industries, as when solar and battery refunds were trimmed in 2024.
Details: https://www.taxid.dev/vat-rates/cn

## Philippines — VAT (Value-Added Tax)
Standard rate: 12%. Reduced rates: 0%.
The Philippines pushed VAT to 12% in 2006 — still the rate today — and in mid-2025 became one of Southeast Asia's latest adopters of VAT on foreign digital services, obliging non-resident platforms like streaming and cloud providers to register with the BIR. Businesses under PHP 3 million in sales escape VAT but pay a 3% percentage tax on gross receipts instead. The Ease of Paying Taxes Act recently shifted VAT filing from monthly to quarterly, a rare compliance simplification in the region.
Details: https://www.taxid.dev/vat-rates/ph

## Vietnam — Thuế GTGT (Thuế giá trị gia tăng)
Standard rate: 10%. Reduced rates: 8%, 5%.
Vietnam's statutory 10% VAT has effectively been 8% for most goods since 2022 — the "temporary" stimulus cut has been renewed repeatedly and now runs to 31 December 2026, expanded to logistics and IT services. The rewritten VAT Law took effect in January 2026, quintupling the household-business exemption threshold to VND 500 million and tightening rules on foreign e-commerce platforms, which must withhold and remit VAT for their sellers. E-invoicing has been universal since 2022.
Details: https://www.taxid.dev/vat-rates/vn

## Pakistan — Sales Tax (GST)
Standard rate: 18%.
Pakistan's "sales tax" is a VAT in mechanics but split by constitution: the federal FBR taxes goods at 18%, while each province levies its own sales tax on services (13%–16%), so a national supplier may file five-plus returns a month. Export sectors lost their cherished zero-rating on domestic sales in 2019, a recurring battleground in IMF negotiations. Higher "further tax" surcharges punish sales to unregistered buyers, a stick to drag the informal economy into registration.
Details: https://www.taxid.dev/vat-rates/pk

## Bangladesh — মূসক / VAT (Mushak)
Standard rate: 15%. Reduced rates: 10%, 7.5%, 5%.
Bangladesh enacted a clean single-rate 15% VAT law in 2012 but never implemented it as designed — when the law finally took effect in 2019 it carried a ladder of 5%, 7.5% and 10% rates alongside the 15%, plus truncated bases for many sectors, leaving one of South Asia's most fragmented VAT systems. The ready-made garment export industry, the economy's backbone, operates on zero-rating with bonded warehouses. NBR is rolling out electronic fiscal devices in retail to plug chronic leakage.
Details: https://www.taxid.dev/vat-rates/bd

## Sri Lanka — VAT (Value Added Tax)
Standard rate: 18%.
Sri Lanka's VAT tells the story of its 2022 default: slashed to 8% in a disastrous 2019 stimulus, the rate was ratcheted to 12%, 15% and finally 18% as the IMF programme demanded revenue, while exemptions for fuel and electricity were stripped away. From October 2025, non-resident digital platforms must register and charge 18% VAT on services to Sri Lankan consumers. The threshold of LKR 60 million keeps most small businesses out, but the SVAT deferment scheme for exporters was abolished in the consolidation.
Details: https://www.taxid.dev/vat-rates/lk

## Nepal — मूल्य अभिवृद्धि कर (VAT)
Standard rate: 13%.
Nepal has run a single 13% VAT rate since 2005, resisting the multi-rate drift of its neighbours — the IMF regularly cites it as a regional example of rate simplicity. Basic agricultural produce, the livelihood of most of the population, is exempt rather than zero-rated. Foreign digital service providers above NPR 3 million in Nepali sales must register under rules introduced in 2023, and lottery-style incentives reward consumers who collect VAT invoices.
Details: https://www.taxid.dev/vat-rates/np

## Cambodia — អាករលើតម្លៃបន្ថែម (VAT)
Standard rate: 10%.
Cambodia's 10% VAT has been static since 1999 in a heavily dollarised economy where returns are filed in riel but most business runs in US dollars. It was an early Southeast Asian mover on taxing the digital economy: non-resident e-commerce and digital service providers have had to register and charge 10% VAT since 2022. The garment and footwear export sector — the economy's anchor — runs on zero-rating, while basic foods sold by unregistered traders stay outside the net.
Details: https://www.taxid.dev/vat-rates/kh

## Taiwan — 營業稅 (Business Tax / VAT)
Standard rate: 5%.
Taiwan's 5% VAT (officially "business tax") is one of the lowest credit-invoice rates in the world and has not moved since 1986, anchored by the politically sensitive Government Uniform Invoice system — every receipt doubles as a lottery ticket in the famous bimonthly uniform-invoice draw that turns consumers into enforcement agents. Financial institutions pay gross-receipts business tax at separate rates instead. Foreign digital service providers above NT$480,000 in annual sales have registered and charged 5% since 2017.
Details: https://www.taxid.dev/vat-rates/tw

## Kazakhstan — ҚҚС / НДС (Қосылған құн салығы)
Standard rate: 16%. Reduced rates: 10%, 5%.
Kazakhstan's new Tax Code delivered the country's first VAT increase in over a decade: 12% became 16% on 1 January 2026, with new reduced bands of 5% for medicines (stepping to 10% in 2027) and 10% for periodicals. The registration threshold was simultaneously halved to 10,000 MCI, pulling tens of thousands of small businesses into the net to fund a budget squeezed by oil-revenue volatility. Foreign internet companies selling to Kazakh consumers face new VAT obligations from 2026 as well.
Details: https://www.taxid.dev/vat-rates/kz

## Uzbekistan — QQS (Qoʻshilgan qiymat soligʻi)
Standard rate: 12%.
Uzbekistan moved against the global tide by cutting VAT twice — from 20% to 15% in 2019 and to 12% in 2023 — as the centrepiece of its post-isolation liberalisation, betting that lower rates plus digitisation would out-collect the old system. The bet has broadly paid off: receipts grew as e-invoicing, online cash registers and QR-receipt lotteries formalised the bazaar economy. Businesses under UZS 1 billion can stay on a simplified turnover tax instead.
Details: https://www.taxid.dev/vat-rates/uz

---

# Integration & framework guides

## Stripe EU VAT: Validate Tax IDs Before Charging Customers
https://www.taxid.dev/use-cases/stripe-eu-vat

When you sell B2B across EU borders, EU VAT Directive 2006/112/EC requires you to verify that the buyer holds a valid VAT registration before you can apply zero-rate (reverse charge). Skipping this check and zero-rating an invoice to an unregistered buyer creates a VAT liability that falls on your business, not the customer.

The practical flow is: at checkout the buyer enters their VAT number, your server calls GET /api/v1/validate/:country/:vat, and if the response contains status: 'active' you call stripe.customers.update({ tax_exempt: 'reverse' }) to flip the customer's tax treatment. Stripe then applies zero VAT on all future invoices for that customer. The TaxID response also returns company_name and company_address, which you should store in Stripe customer metadata for audit purposes.

VIES, the underlying EU service, can return status: 'service_unavailable' for some member-state nodes at any time. Build a fallback so that an unavailable VIES does not silently zero-rate the customer; the safest approach is to charge normal VAT and allow the customer to reclaim it, rather than to wrongly exempt an unverified number.

Stripe Tax automates VAT rate calculation and filing across 30+ countries, but it depends entirely on the tax_exempt flag you set on the customer object to determine reverse-charge eligibility. There is no built-in mechanism in Stripe that checks whether a VAT number is actually registered in VIES. A buyer can enter a plausible-looking number — even a correctly formatted one belonging to another company — and Stripe will zero-rate the invoice without complaint. TaxID queries the live VIES registry in real time and returns the name and address registered with the member state's tax authority, so you can cross-check the declared company details before applying zero-rate.

EU Invoice Directive 2006/112/EC Article 226 requires that zero-rated B2B invoices carry the annotation 'Reverse charge'. Stripe automatically adds this notation when tax_exempt: 'reverse' is set on the customer, so you do not need to handle invoice annotation separately. What you do need to handle is the correction flow: if a customer's VAT number later turns out to be invalid, you must issue a corrective invoice with VAT and pay the difference to the tax authority. The original buyer cannot be held liable for the tax — the liability sits with the seller.

Subscription businesses face an additional challenge: VAT registrations change. Companies deregister voluntarily, get cancelled by the tax authority, or restructure across borders. A number valid at signup may be revoked six months later. For any recurring billing integration, add a background job that re-validates all reverse-charge customers — weekly for high-revenue accounts, monthly for everyone else — and flags any returning status: 'invalid' for your finance team to review before the next invoice cycle.

1. **Collect VAT number at checkout** — Add a dedicated VAT number input to your Stripe Checkout custom form or Payment Element. Place it in the billing-address section and label it clearly as 'EU VAT number' so buyers know it is optional for consumers but required for B2B reverse-charge treatment.
2. **Validate via TaxID API** — On form submission, call GET /api/v1/validate/:country/:vat from your server (never from the browser, to protect your API key). Parse the JSON response: check status === 'active' before proceeding; if status is 'invalid' return a form error, and if status is 'service_unavailable' log a warning and fall back to standard VAT rather than silently exempting.
3. **Apply zero-rate if valid** — When the API returns status: 'active', call stripe.customers.update({ id: customerId, tax_exempt: 'reverse' }) to enable reverse-charge treatment on the Stripe customer object. This causes Stripe Tax to suppress VAT on all subsequent invoices for that customer and adds the reverse-charge annotation required by EU invoice rules.
4. **Store result on Stripe customer metadata** — Persist the validated VAT number, the company_name and company_address from the TaxID response, and the validation timestamp in stripe.customers.update({ metadata: { vat_number, vat_company_name, vat_validated_at } }). This gives you an auditable trail showing the VAT was valid at the time of the transaction, which is required under EU record-keeping obligations.
5. **Set up periodic re-validation** — For subscription products, schedule a background job that re-calls GET /api/v1/validate/:country/:vat for every customer with tax_exempt: 'reverse' at least once a month. Stripe webhooks (customer.updated) can trigger a sync when a customer's details change, but they will not detect a VIES deregistration unless you actively re-check. Flag customers returning status: 'invalid' for your finance team before the next billing cycle.

### FAQ

**How often should I re-validate EU VAT numbers?**
Validate at every checkout for one-off transactions. For subscription customers, run a background job that re-checks all customers with tax_exempt: 'reverse' at least monthly. VAT registrations can be cancelled between billing cycles, and a tax audit will ask for proof that the number was valid at the time of each invoice — not just at signup.

**What should I do when VIES returns service_unavailable?**
Never silently zero-rate an unverified number. The safest fallback is to charge standard local VAT and issue a credit note once VIES recovers and confirms the number is valid. Alternatively, display a message asking the buyer to retry in a few minutes. Log every service_unavailable response with the customer ID and timestamp so you can follow up.

**Does Stripe Tax validate EU VAT numbers automatically?**
No. Stripe Tax calculates and collects the correct VAT based on the customer's location and the tax_exempt flag, but it does not call VIES or any other registry to check that a VAT number is real or currently registered. You must call an independent validation API — such as TaxID — before setting tax_exempt: 'reverse' on the Stripe customer.

**Which EU countries can I validate?**
TaxID validates VAT numbers for all 27 EU member states via VIES: Austria (AT), Belgium (BE), Bulgaria (BG), Croatia (HR), Cyprus (CY), Czech Republic (CZ), Denmark (DK), Estonia (EE), Finland (FI), France (FR), Germany (DE), Greece (EL), Hungary (HU), Ireland (IE), Italy (IT), Latvia (LV), Lithuania (LT), Luxembourg (LU), Malta (MT), Netherlands (NL), Poland (PL), Portugal (PT), Romania (RO), Slovakia (SK), Slovenia (SI), Spain (ES), and Sweden (SE).

**Can I call the TaxID API directly from the browser?**
No. Always call the TaxID API from your server-side code, never from client-side JavaScript. A browser request would expose your API key to anyone who inspects network traffic. Pass the VAT number to a backend endpoint, validate there, and return only the result (valid: true/false) to the frontend.

---

## UK VAT validation in Shopify B2B
https://www.taxid.dev/use-cases/shopify-uk-vat

Since Brexit, UK VAT registration is administered by HMRC independently of the EU VIES system. UK VAT numbers follow the format GB + 9 digits and are validated against HMRC's API. B2B sellers shipping goods or supplying digital services to UK-registered businesses can zero-rate those supplies, but only if the buyer's VAT number is verified and recorded at the time of sale.

In Shopify, the integration happens either through a checkout extension that calls your backend on address confirmation, or via an order-created webhook. The webhook approach is safer because it fires for all order channels. Your handler calls GET /api/v1/validate/GB/:vatNumber, and if the response returns status: 'active', you use the Shopify Admin API to set tax_exempt: true on the customer and add a metafield storing the validated VAT number and timestamp.

Making Tax Digital for VAT mandates that the VAT number used to justify a zero-rated supply is recorded in your VAT account. Storing the TaxID request_id alongside the order is good practice: it gives you an audit-ready reference showing which third-party validation confirmed the number's status on a specific date.

1. **Add VAT number field to billing address** — Use a Shopify Checkout UI Extension or a custom storefront to add a 'UK VAT number' input to the billing address step. Persist the value in a customer metafield (namespace: 'tax', key: 'vat_number') so it is available to webhooks and future orders without asking again.
2. **Validate on order creation via webhook** — Subscribe to the orders/create webhook in your Shopify Partner app. When it fires, read the vat_number metafield, call GET /api/v1/validate/GB/:vatNumber, and handle the three possible status values: 'active' proceeds to exemption, 'invalid' triggers a follow-up email to the customer, and 'service_unavailable' queues a retry job to avoid incorrectly exempting an unverified number.
3. **Tag customer as B2B if valid** — On a valid response, use the Shopify Admin REST API (PUT /admin/api/2024-01/customers/:id.json) or GraphQL mutation to add the tag 'b2b-verified' to the customer. This tag can drive Shopify discount scripts, price list assignments, and B2B metafield visibility without re-querying the VAT status on every session.
4. **Apply tax exemption** — Update the customer object with tax_exempt: true via the Shopify Admin API to suppress VAT on subsequent orders. Store the validated VAT number, the company_name from the TaxID response, and the validation date in customer metafields for Making Tax Digital record-keeping; HMRC requires you to retain evidence of VAT validation for at least six years.

---

## WooCommerce Spain NIF/CIF validation
https://www.taxid.dev/use-cases/woocommerce-spain-vat

Spain uses three distinct tax identifier formats: NIF for legal entities (a letter + 7 digits + a control letter, e.g. A12345678), NIF persona física for individuals (8 digits + letter, i.e. the standard DNI), and NIE for foreign nationals (X, Y, or Z + 7 digits + letter). Validating Spanish tax IDs in WooCommerce requires handling all three formats and understanding that only legal entities appear in VIES with the ES prefix; individual NIFs are not VIES-registered and should be captured for invoicing purposes only.

The WooCommerce integration uses the woocommerce_checkout_fields filter to inject a NIF/CIF input, and the woocommerce_checkout_process action to validate it server-side before the order is placed. When the customer saves their billing address, your plugin calls GET /api/v1/validate/ES/:nif, checks the response, and either proceeds or returns a checkout error. For verified legal entities, the order meta is updated with the company_name from the TaxID response, enabling correct invoice rendering.

Spanish Hacienda requires that invoices issued to businesses include the recipient's NIF and registered company name. Storing the TaxID-validated company_name ensures your WooCommerce PDF invoices are compliant with Real Decreto 1619/2012, Spain's invoice regulation. If VIES returns service_unavailable for the ES node, fall back to format validation only and flag the order for manual review rather than blocking the purchase.

1. **Add NIF/CIF field to checkout** — Use the woocommerce_checkout_fields filter to inject a custom 'billing_nif' field into the billing section. Set it as required for customers selecting Spain as their billing country by combining the filter with a conditional on billing_country === 'ES', so domestic buyers are always prompted while foreign buyers are not.
2. **Validate via TaxID API on save** — Hook into woocommerce_checkout_process to call GET /api/v1/validate/ES/:nif server-side before order creation. If status is 'active', store the company_name in order meta; if 'invalid', call wc_add_notice() with type 'error' to surface the failure inline; if 'service_unavailable', allow checkout but flag the order with a custom meta key (e.g. _vat_pending_verification: 1) for asynchronous re-validation.
3. **Display validation status to customer** — After the API call, render inline feedback using JavaScript and the WooCommerce checkout block's update_checkout event: show a green company name confirmation for valid numbers, a red 'VAT number not found in VIES' message for invalid ones, and a neutral 'Validation service temporarily unavailable' notice for service_unavailable responses, so the buyer understands why checkout proceeds without exemption.
4. **Auto-apply B2B pricing rules** — On successful validation, use the woocommerce_customer_taxable_class filter to return 'zero-rate' for the order, and assign the customer role 'b2b-verified' via wp_update_user. The zero-rate tax class suppresses WooCommerce's VAT calculation, and the role gates access to wholesale price lists or catalog discounts configured via WooCommerce Product Tables or a role-based pricing plugin.

---

## EU VAT compliance for SaaS billing
https://www.taxid.dev/use-cases/saas-billing-eu

EU VAT treatment for SaaS subscriptions hinges on a single question: is the customer a taxable person (business) or a private consumer? Under EU VAT Directive 2006/112/EC Article 196, if the buyer is a VAT-registered business in another EU member state, the supply is zero-rated and the buyer accounts for VAT under the reverse-charge mechanism. If the buyer is a consumer, you must charge VAT at the rate applicable in their country of residence, which is where the EU One Stop Shop (OSS) scheme becomes relevant.

At signup, call GET /api/v1/validate/:country/:vat to confirm the VAT number. A response with status: 'active' classifies the account as B2B: set tax_treatment: 'reverse_charge' in your billing database and pass tax_exempt: 'reverse' to Stripe. A missing or invalid VAT number classifies the account as B2C: determine the customer's country from their IP or billing address and apply the local OSS VAT rate. Store the company_name and company_address from the TaxID response on the customer record; these fields must appear on compliant EU VAT invoices.

Re-validate VAT numbers periodically — VIES supports querying at any time, and a business can deregister. A safe approach is to re-validate on each subscription renewal and cache the result for 24 hours (matching TaxID's cache window for active numbers). If a previously valid number returns invalid on renewal, freeze the reverse-charge treatment, notify the customer, and revert to charging VAT until a valid number is supplied.

1. **Collect VAT number at signup** — Add an optional VAT number field to your signup form and show it conditionally when the user selects an EU country. Use a client-side regex to catch obvious format errors before the form is submitted (e.g. DE must be DE + exactly 9 digits), reducing unnecessary API calls and giving instant feedback to users who mistype their number.
2. **Validate and classify customer (B2B/B2C)** — On form submission, call GET /api/v1/validate/:country/:vat from your server. Set the customer's tax_treatment column to 'reverse_charge' when status === 'active', 'standard_rate' when status === 'invalid' or no VAT number was provided, and 'pending' when status === 'service_unavailable' so a background job can retry within the hour. Store the cached flag from the response to distinguish a live VIES confirmation from a cached result.
3. **Configure billing engine for correct tax** — Pass the tax classification to your billing engine: for reverse_charge customers, disable VAT calculation and add a 'Reverse charge — VAT to be accounted for by the recipient' line to the invoice per EU invoice Directive Article 226(11a). For B2C customers, apply the destination-country VAT rate and flag the invoice for OSS reporting. Using Stripe Tax, this translates to tax_exempt: 'reverse' for B2B and a standard tax_behavior: 'exclusive' subscription for B2C.
4. **Generate compliant PDF invoices** — EU-compliant invoices must include the supplier's VAT number, the buyer's VAT number (for reverse-charge invoices), the company_name and company_address from the TaxID validation response, and the reverse-charge annotation. Render these fields from your customer record into your PDF template; missing any of them can cause the invoice to be rejected by the buyer's tax authority and denied as input VAT credit.

---

## DAC7 marketplace seller VAT verification
https://www.taxid.dev/use-cases/marketplace-seller-onboarding

DAC7 (EU Directive 2021/514) requires digital platforms operating in or selling into the EU to collect and report tax identification information for sellers who earn more than €2,000 or complete 25 or more transactions in a calendar year. The platform must validate the tax ID it collects, not merely store whatever the seller provides. Failure to collect or report accurate data exposes the platform to penalties in each EU member state where it operates.

During onboarding, call GET /api/v1/validate/:country/:vat for every seller who provides a VAT number. Store the full API response — including status, company_name, company_address, cached, and request_id — alongside the seller's account record and the timestamp of validation. The request_id is especially important as it serves as an auditable reference proving that a third-party VIES lookup was performed, which satisfies the 'reasonable steps' standard under DAC7's due diligence rules.

Because DAC7 reports are filed annually per calendar year, build your data model so that each seller record tracks the validation result at the time of onboarding plus any subsequent re-validations triggered when the seller's country changes or their VAT number is updated. For sellers below the €2,000/25-transaction threshold, validation is still best practice to prevent fraudulent accounts from exploiting B2B pricing on your platform.

1. **Collect VAT number during seller registration** — Add a VAT number field to your seller onboarding flow and make it required for EU-resident sellers who select 'business' account type. Apply client-side country-prefix validation (e.g. FR must start with FR followed by two alphanumeric characters and nine digits) to catch format errors early, but treat client-side checks as UX only — always re-validate server-side.
2. **Validate via TaxID API** — Call GET /api/v1/validate/:country/:vat from your onboarding backend and store the entire JSON response body. For status: 'service_unavailable', set the seller's tax_status to 'pending' and schedule an automatic retry using a queue (e.g. BullMQ or SQS) so validation completes before the seller's first payout rather than silently passing an unverified number.
3. **Store validation result and timestamp** — Persist status, company_name, company_address, request_id, and validated_at in your sellers table. Index validated_at so your DAC7 reporting job can efficiently query sellers whose validation is older than 12 months and trigger a re-validation sweep before the annual January 31 filing deadline.
4. **Generate annual DAC7 reports** — At year-end, query all sellers whose cumulative platform earnings exceed €2,000 or who completed 25+ transactions. For each, include the validated company_name, company_address, and VAT number from your stored TaxID results in the XML report file submitted to your competent tax authority. Sellers whose VAT was never successfully validated (status remained 'pending') must be flagged and withheld from payouts per DAC7 Article 12 obligations.

---

## ERP supplier VAT number validation
https://www.taxid.dev/use-cases/erp-supplier-validation

In accounts-payable workflows, a supplier's VAT number is used to reclaim input VAT on their invoices. If the VAT number stored in your ERP is incorrect or belongs to a deregistered business, your input VAT reclaim on that invoice may be denied during an audit. Validating supplier VAT numbers at the point of creation — rather than during an audit — prevents costly corrections and late reclaim penalties.

Most ERPs expose a webhook or script hook when a new vendor record is saved: SAP uses Business Add-Ins (BAdIs) on the XK01 transaction, NetSuite uses a beforeSubmit User Event script on the Vendor record, and Xero exposes the contacts.created webhook. Each hook should call GET /api/v1/validate/:country/:vat, update the vendor record with the returned company_name (to confirm the name matches the invoice), and set a custom field (e.g. vat_validation_status) to 'active', 'invalid', or 'pending'.

For existing supplier databases, batch validation is the practical path: export all vendor VAT numbers to a CSV, run them through the TaxID API with controlled concurrency (no more than 10 parallel requests to respect rate limits), and import the results back. Active numbers are cached for 24 hours by TaxID, so large batches of known-good numbers return in under 10 ms each, making nightly refresh jobs economically viable.

1. **Trigger on new supplier creation** — Register a webhook or server-side script that fires when a new vendor record is saved in your ERP. In SAP, implement a BAdI on the VENDOR_ADD_DATA enhancement spot; in NetSuite, use a beforeSubmit User Event script on the Vendor record type; in Xero, subscribe to the contacts.created webhook via the Xero API. Pass the supplier's country code and VAT number extracted from the vendor form to your validation service.
2. **Validate VAT via webhook or batch** — Call GET /api/v1/validate/:country/:vat from your middleware and inspect the status field. For real-time hooks, respond synchronously to the ERP with the result so the save can be blocked or warned inline. For batch jobs, process up to 10 concurrent requests at a time and implement exponential backoff for 429 rate-limit responses; TaxID caches active numbers for 24 hours so previously validated numbers return in under 10 ms.
3. **Update supplier record with validation status** — Write the status, company_name, company_address, request_id, and validated_at back to the ERP vendor record using custom fields. Storing the company_name alongside the validation result lets AP staff cross-check that the name on an incoming invoice matches the VIES-confirmed entity name, catching cases where a supplier has restructured and their invoices now reference a different legal entity.
4. **Flag mismatches for manual review** — Set the ERP vendor record to a 'hold' payment status when status is 'invalid' or when the company_name from VIES does not match the name on file. Route a task to the AP team's review queue with the TaxID request_id as a reference. This ensures that an invalid number never silently passes through to a posted invoice, which would require a manual VAT correction with your tax authority.

---

## Node.js VAT API — EU VAT Validation in Node.js
https://www.taxid.dev/use-cases/nodejs-vat-validation

Node.js's native fetch (available since v18 without flags, and polyfillable with node-fetch in earlier versions) is sufficient to call the TaxID REST API. The API returns a consistent JSON shape — { valid, status, company_name, company_address, cached, request_id } — that maps cleanly to a TypeScript interface, giving you type-safe access to validation results throughout your application.

VIES, the underlying EU SOAP service, can return status: 'service_unavailable' for specific member-state nodes without any HTTP error code — the TaxID API normalises this into the status field so your code does not need to parse SOAP faults. Your error-handling logic should branch on three cases: 'active' (proceed), 'invalid' (reject the VAT number), and 'service_unavailable' (treat as a temporary error and retry or fail open with a warning).

For high-throughput Node.js services, caching TaxID results in Redis with a TTL matching the API's own cache window (86400 seconds for active numbers, 3600 seconds for invalid) lets you serve sub-millisecond responses for repeat lookups without consuming API quota. Use the composite key `vat:${country}:${vatNumber}` and store the full response JSON so every consumer has access to company_name and request_id without a round-trip.

1. **Install node-fetch or use native fetch** — In Node.js 18+ no installation is needed — global fetch is available by default. For Node.js 16 or earlier, add node-fetch v3 (ESM) or v2 (CJS) to your project. Avoid the deprecated node-fetch v1 or the unmaintained isomorphic-fetch package; they lack proper error handling for network timeouts, which matters when VIES member-state nodes are slow.
2. **Create validateVAT helper function** — Write an async function that accepts (country: string, vat: string) and calls GET https://api.taxid.pro/v1/validate/${country}/${vat} with an Authorization: Bearer YOUR_API_KEY header. Type the return value as { valid: boolean; status: 'active' | 'invalid' | 'service_unavailable'; company_name: string | null; company_address: string | null; cached: boolean; request_id: string } so callers get compile-time safety on every field.
3. **Add error handling for VIES unavailability** — Check the status field before using the result: throw a retriable VATServiceUnavailableError when status === 'service_unavailable' so upstream callers (Express middleware, queue workers) can decide whether to retry or fail open. Never silently treat service_unavailable as valid — doing so would zero-rate invoices for customers whose VAT numbers were never actually confirmed with VIES.
4. **Cache results in Redis or memory** — After a successful API call, store the JSON-serialised response in Redis with SETEX vat:${country}:${vat} 86400 <json> for active numbers and SETEX vat:${country}:${vat} 3600 <json> for invalid ones; these TTLs match TaxID's own cache policy. For single-server deployments without Redis, a simple in-process Map with a timestamp-based eviction check is an acceptable lightweight alternative.

---

## Python VAT API — EU VAT Validation in Python / Django
https://www.taxid.dev/use-cases/python-vat-validation

Python's requests library (or the async httpx for FastAPI applications) provides a clean interface for calling the TaxID REST API. The API accepts a country code and VAT number as path parameters and returns a uniform JSON object, making it straightforward to map into a Python dataclass or Pydantic model for type-safe downstream handling.

In a Django application, the natural home for validation logic is a service layer class (e.g. VATValidator) that is called from form validation (clean() methods), REST framework serializers, or Celery tasks. Storing the result in a dedicated VATValidation model — with fields for status, company_name, company_address, request_id, and validated_at — creates an audit table that satisfies EU record-keeping requirements without polluting your main customer or order models.

Handling service_unavailable correctly is the most important resilience concern. Never allow a service_unavailable response to silently pass as valid; instead, raise a dedicated exception (e.g. VIESUnavailableError) that your view or serializer catches and converts to an HTTP 503 or a user-facing message. For background tasks, use Celery's retry mechanism with a countdown of 300 seconds to re-attempt validation when the VIES node recovers.

1. **Use requests or httpx library** — Install requests for synchronous Django/Flask apps or httpx for async FastAPI applications. Call GET https://api.taxid.pro/v1/validate/{country}/{vat} with headers={'Authorization': f'Bearer {settings.TAXID_API_KEY}'} and set a timeout of 10 seconds to prevent VIES latency from blocking your request threads indefinitely.
2. **Create VATValidator class** — Encapsulate the API call in a VATValidator class with a validate(country, vat_number) method that returns a typed dataclass or Pydantic BaseModel mirroring the response schema: valid (bool), status (Literal['active','invalid','service_unavailable']), company_name (str | None), company_address (str | None), cached (bool), request_id (str). This decouples your business logic from the HTTP transport layer.
3. **Handle service_unavailable gracefully** — In your validator, raise a VIESUnavailableError (subclassing Exception) when status == 'service_unavailable'. Catch this in Django views with a try/except block and return a 503 response or a form error telling the user to retry. In Celery tasks, use self.retry(exc=exc, countdown=300) to schedule a re-attempt; this prevents indefinite pending states while respecting VIES recovery windows.
4. **Store results in Django model** — Create a VATValidation model with fields: customer (FK), country_code (CharField), vat_number (CharField), status (CharField with choices), company_name (CharField nullable), request_id (UUIDField), validated_at (DateTimeField auto_now_add). Query this table first before calling the API to serve cached results, and invalidate cached records older than 24 hours for active numbers and 1 hour for invalid ones.

---

## EU VAT validation in PHP / Laravel
https://www.taxid.dev/use-cases/php-vat-validation

PHP applications using Laravel can integrate TaxID validation through a combination of a service class, a custom FormRequest validation rule, and a database migration for storing results. The service class wraps the HTTP call, the custom rule hooks into Laravel's validator so VAT numbers can be validated in any FormRequest with a single line, and the database table provides the audit trail required by EU VAT regulations.

The HTTP call itself uses Laravel's Http facade (built on Guzzle): Http::withToken(config('services.taxid.api_key'))->get("https://api.taxid.pro/v1/validate/{$country}/{$vat}"). The response JSON maps to a PHP array with keys valid, status, company_name, company_address, cached, and request_id. Cache the response in Redis using Cache::put("vat:{$country}:{$vat}", $response, $ttl) where $ttl is 86400 for active numbers and 3600 for invalid ones.

Symfony users follow the same pattern using Symfony's HttpClient component (HttpClient::create()->request('GET', $url, ['auth_bearer' => $apiKey])) and a custom ConstraintValidator. The key architectural difference is registering the validator as a tagged service in services.yaml. In either framework, surfacing validation feedback in the Blade or Twig template as an inline message (company name on success, error text on failure) significantly reduces checkout abandonment compared to generic error messages.

1. **Create VATValidationService** — Generate a service class (php artisan make:service VATValidationService) that injects Laravel's Http facade and calls GET https://api.taxid.pro/v1/validate/{country}/{vat} with withToken(config('services.taxid.api_key')). Return the decoded JSON as a PHP object or DTO so callers never access raw array keys and get IDE autocompletion on status, company_name, and request_id.
2. **Add Laravel validation rule** — Create a custom rule class (php artisan make:rule ValidEUVatNumber) that calls VATValidationService::validate() in the passes() method and returns true only when status === 'active'. Use the rule in your FormRequest: 'vat_number' => ['required', 'string', new ValidEUVatNumber($request->country)]. This makes VAT validation available anywhere Laravel's validator runs, including API controllers and queue jobs.
3. **Cache results in Redis** — Before making an HTTP request in VATValidationService, check Cache::get("vat:{$country}:{$vat}"). On a cache miss, call the API and store the result with Cache::put("vat:{$country}:{$vat}", $result, $ttl) where $ttl = $result->status === 'active' ? 86400 : 3600. Using Laravel's cache abstraction means you can switch from Redis to Memcached or database cache without changing the service class.
4. **Display validation feedback in Blade** — After the form submits, pass the VATValidationResult to your Blade view and conditionally render an inline confirmation block: show the company_name in green when status is active, an error alert when invalid, and a warning notice when service_unavailable. Displaying the company name that VIES returned is a strong trust signal for B2B buyers and reduces support tickets from customers unsure whether their number was accepted.

---

## Real-time VAT validation in React checkout
https://www.taxid.dev/use-cases/react-checkout-vat

Real-time VAT validation in a React checkout improves B2B conversion by giving buyers instant feedback — they see the legal company name confirmed on screen before they complete payment, which builds trust and catches typos before they cause invoice problems downstream. The interaction pattern is: debounce input, send to a server-side API route (not directly to TaxID from the browser), display a loading spinner, then show the result inline.

The browser must never call TaxID directly because that would expose your API key. Instead, create a thin /api/validate-vat route in your Next.js or Express backend that proxies to GET /api/v1/validate/:country/:vat and returns only the fields the frontend needs (status, company_name). The React component uses a 500 ms debounce to avoid firing on every keystroke, and useTransition (in Next.js 14 Server Actions) or a standard useEffect + AbortController to cancel in-flight requests when the user keeps typing.

The component should manage four distinct UI states: idle (no input), loading (spinner), valid (green badge + company name), and error (red message with the specific error type). Distinguishing between 'invalid' (wrong number) and 'service_unavailable' (VIES temporarily down) in the error state prevents user confusion — for service_unavailable you should reassure the buyer that their number will be validated after checkout rather than implying their VAT registration is incorrect.

1. **Add VAT number input field** — Render the VAT number input conditionally when the billing country is an EU member state, using a controlled input whose value is stored in React state. Show a short format hint below the field (e.g. 'DE + 9 digits for German VAT numbers') derived from the selected country code to reduce format-related validation failures before the user even submits.
2. **Debounce validation calls (500ms)** — Wrap the onChange handler with a useEffect cleanup pattern or a library like use-debounce to wait 500 ms of inactivity before triggering a fetch to your /api/validate-vat server route. Use an AbortController and pass its signal to fetch() so that if the user types again before the response arrives, the stale request is cancelled and you never apply an out-of-date validation result to the current input value.
3. **Show loading spinner and status** — Maintain a validationState value in component state ('idle' | 'loading' | 'valid' | 'invalid' | 'unavailable'). Set it to 'loading' immediately when the debounced call fires, then update it when the server responds. Render distinct UI for each state: a spinner icon during loading, a check icon during valid, an X icon during invalid, and a warning icon during unavailable, so the checkout form communicates status without relying on text alone.
4. **Display company name on success** — When the API returns status: 'active', display the company_name from the response in a highlighted confirmation block below the input (e.g. 'Validated: Acme GmbH'). This serves as a human-readable sanity check that the buyer entered the correct number for their business, and it gives your support team an instant reference when reviewing orders without needing to re-query VIES.

---

## Bulk VAT number validation via CSV import
https://www.taxid.dev/use-cases/bulk-vat-import

Bulk VAT validation is typically needed in three scenarios: migrating customer data from a legacy system where VAT numbers were collected but never verified, running a periodic audit of your existing customer or supplier database, and performing a one-time cleanse before filing annual VAT reports. In all three cases the data source is a CSV or database dump, and the goal is to enrich each row with the current VIES status, the VIES-confirmed company name, and a validation timestamp.

The TaxID API is rate-limited, so bulk jobs must control concurrency rather than firing all requests simultaneously. A practical approach is to process rows in batches of 10 concurrent requests using Promise.allSettled (JavaScript) or asyncio.gather with a semaphore (Python), with exponential backoff on 429 responses. Since TaxID caches active numbers for 24 hours, if you run the same batch job on consecutive days, the majority of previously-valid numbers will return from cache in under 10 ms, making re-validation economical.

For very large datasets (tens of thousands of numbers), structure the job as a queue of individual validation tasks (e.g. BullMQ or Celery) so it is resumable after failures, and write partial results to the output file as each batch completes rather than holding everything in memory. This also lets you prioritise re-validation of numbers whose last validated_at timestamp is older than your data freshness policy.

1. **Parse CSV with VAT numbers** — Use a CSV library (csv-parse in Node.js, Python's built-in csv module, or League\Csv in PHP) to stream-parse the input file row by row rather than loading the entire file into memory. Extract the country_code and vat_number columns; if the CSV does not have separate columns, use a regex to split the two-letter country prefix from the numeric portion (e.g. /^([A-Z]{2})(.+)$/) before calling the API.
2. **Validate in parallel (max 10 concurrent)** — Use a concurrency-limited executor: in Node.js, p-limit(10) wrapped around Promise.allSettled is idiomatic; in Python, asyncio.Semaphore(10) with asyncio.gather achieves the same effect. Limit to 10 concurrent requests to stay within API rate limits and to avoid overwhelming VIES member-state nodes, which are known to become unresponsive under high request volumes.
3. **Collect results with rate limit awareness** — On each API response, inspect the HTTP status code: a 429 means you've exceeded the rate limit — back off exponentially (e.g. 1s, 2s, 4s) and retry the failed row. For status: 'service_unavailable' in the response body, log the row as 'pending' and add it to a retry queue rather than marking it as invalid, since the VIES node may recover within minutes. Store valid, invalid, and pending counts in a running summary to report at job completion.
4. **Export enriched CSV with status + company name** — Write the output CSV with the original columns plus: vat_status (active/invalid/service_unavailable), company_name, company_address, request_id, and validated_at. Include request_id so downstream users can reference the specific TaxID lookup that produced the result — this is valuable for audit purposes when a customer disputes their validation outcome.

---

## Validate German USt-IdNr. (DE VAT numbers)
https://www.taxid.dev/use-cases/germany-ustidnr-check

Germany issues two distinct tax numbers to businesses: the Steuernummer (a domestic 10–13 digit number used for income tax filings with the Finanzamt) and the Umsatzsteuer-Identifikationsnummer (USt-IdNr.), which is the EU VAT number prefixed with DE followed by exactly 9 digits (e.g. DE123456789). Only the USt-IdNr. is registered in VIES and valid for cross-border B2B transactions; the Steuernummer cannot be used for reverse-charge invoicing and should not be accepted as a substitute.

German companies can look up their USt-IdNr. through the Bundeszentralamt für Steuern (BZSt). When a German buyer provides a 10–13 digit number without the DE prefix, it is almost certainly a Steuernummer — your validation UI should detect this pattern and prompt the user to enter their EU VAT number instead rather than passing it to the API as a malformed request.

The Bundeszentralamt für Steuern also offers a qualified confirmation service (qualifizierte Bestätigungsabfrage) that checks whether a specific company name and address matches the VIES record, not just whether the number is valid. TaxID returns the company_name and company_address fields from VIES, so you can implement this cross-check locally by comparing the VIES-returned company name against the name provided by the buyer, flagging significant mismatches for manual review.

1. **Accept DE prefix with 9 digits** — Validate the format client-side with the regex /^DE[0-9]{9}$/ before calling the API. If the input matches a Steuernummer pattern (/^[0-9]{10,13}$/ without a country prefix), surface a specific message explaining the difference: 'This looks like a Steuernummer. Please enter your EU USt-IdNr. starting with DE.' This prevents unnecessary API calls for a format that VIES will always reject.
2. **Validate format before VIES call** — Strip whitespace and slashes from the input, then call GET /api/v1/validate/DE/:vatNumber. The API will forward the request to the German BZSt node in VIES; response times for German lookups are typically 200–800 ms, so set a client-side timeout of at least 5 seconds and show a loading indicator to prevent users from submitting the form before the response arrives.
3. **Handle German Tax Agency response times** — The BZSt VIES node is one of the more reliable EU nodes but can return service_unavailable during system maintenance windows (typically early morning CET). When this occurs, do not block the user's checkout or form submission; instead, persist a vat_pending_validation flag on the record and queue a background re-validation job that retries every 15 minutes for up to 4 hours before escalating to manual review.
4. **Return company name and address if available** — The TaxID API returns company_name and company_address from the VIES response for German numbers when the BZSt node provides them. Display the company_name on screen as a confirmation step — for high-value B2B transactions, prompt the buyer to confirm 'Is this your company: [company_name]?' before proceeding. Store both fields alongside the order for your accounts-receivable team and for inclusion on reverse-charge invoices.

---

## Validate French TVA numbers (FR VAT)
https://www.taxid.dev/use-cases/france-tva-validation

French TVA intracommunautaire numbers follow the format FR + 2 alphanumeric characters + 9 digits (the SIREN number of the company). Unlike most EU member states where the check characters are purely numeric, France allows letters in positions 3 and 4, including O and I, which commonly cause confusion with the digits 0 and 1. The 2-character key is algorithmically derived from the SIREN using the formula (12 + 3 × (SIREN mod 97)) mod 97, but this is an internal cross-check — the authoritative source for active status is VIES.

The DGFiP (Direction générale des Finances publiques) submits French VAT registrations to VIES, but there can be a lag of several days between when a company receives its TVA number and when it appears as active in VIES. This means a newly-registered French company may provide a syntactically valid TVA number that still returns service_unavailable or invalid from VIES while the registration propagates. Build a retry flow for this edge case rather than rejecting the buyer outright.

French invoicing rules (Code Général des Impôts Article 289) require that reverse-charge invoices include both the supplier's and the recipient's TVA intracommunautaire numbers. The company_name returned by TaxID from the VIES lookup should match the SIREN-registered name; mismatches (e.g. a holding company TVA number used on an invoice for a subsidiary's purchase) are a common source of input VAT denial by the French tax authority.

1. **Accept FRXX... format with alphanumeric chars** — Validate input with /^FR[A-HJ-NP-Z0-9]{2}[0-9]{9}$/ — note the character class excludes I and O from the standard [A-Z0-9] set because the French algorithm never produces those characters, but if a user types them, provide a friendly message rather than a generic 'invalid format' error. Normalise the input to uppercase before validating, as many French businesses write their TVA in mixed case.
2. **Handle French Tax Agency (DGFiP) VIES responses** — Call GET /api/v1/validate/FR/:vatNumber and be prepared for a status of 'service_unavailable' when the DGFiP node is under maintenance, which occurs more frequently than for some other EU member states. Implement a retry strategy: if service_unavailable is returned, wait 60 seconds and retry up to three times before falling back to format-only validation and flagging the record for asynchronous re-validation.
3. **Return SIRET-linked company name** — The company_name in the TaxID response for French numbers is the official registered name from the DGFiP's VIES submission, which is typically linked to the company's SIREN record. Display it as a confirmation to the buyer and store it in your customer record; French invoices subject to reverse charge must include the exact registered company name as it appears in official registers, and using the VIES-returned name eliminates ambiguity.
4. **Cache results for 24 hours** — TaxID already caches active French VAT number responses for 24 hours server-side, so repeat calls for the same number within that window return in under 10 ms with cached: true in the response. Implement client-side caching in your application using the same 24-hour TTL for active numbers and a 1-hour TTL for invalid responses, using the composite key fr:{vatNumber} to namespace the cache.

---

## Validate Dutch BTW numbers (NL VAT)
https://www.taxid.dev/use-cases/netherlands-btw-validation

Dutch BTW numbers follow a distinctive format: NL + 9 digits + B + 2 digits (e.g. NL123456789B01). The 9-digit base is the company's RSIN (Rechtspersonen en Samenwerkingsverbanden Informatienummer) from the KvK (Kamer van Koophandel, the Dutch Chamber of Commerce), and the B01/B02 suffix identifies the fiscal unit — B01 is the primary VAT entity, while higher numbers (B02, B03, etc.) indicate subsidiaries within a Dutch fiscal unity (fiscale eenheid). This means two companies with the same RSIN base but different B-suffixes are legally distinct VAT entities.

The Belastingdienst (Dutch Tax and Customs Administration) submits BTW registrations to VIES. Dutch BTW numbers are validated by VIES using a modulus-11 algorithm on the 9-digit RSIN, but the authoritative check for active registration status is always the VIES lookup — do not rely on the checksum alone to accept a number as valid for reverse-charge purposes.

A common integration mistake is stripping the B-suffix before calling the API, which results in a malformed request. Always pass the full NL123456789B01 format including the literal character B and the two-digit suffix to GET /api/v1/validate/NL/:vatNumber. The API returns KvK-linked company_name and company_address when the Belastingdienst node provides them, which you should cross-check against the company name the buyer entered.

1. **Handle NLxxxxxxxxx B01 format** — Normalise user input by removing spaces and converting to uppercase, then validate with /^NL[0-9]{9}B[0-9]{2}$/. If the user enters the number without the B-suffix (a common mistake), prompt them specifically: 'Dutch BTW numbers end in B followed by two digits, e.g. NL123456789B01.' Do not attempt to auto-append B01 — the correct suffix is determined by the company's fiscal unity status, and guessing it would produce a different VAT entity.
2. **Validate 9-digit base + B + 2 digits suffix** — After format normalisation, call GET /api/v1/validate/NL/:vatNumber with the full string including the B-suffix. Optionally perform a client-side modulus-11 checksum on the 9-digit RSIN (as specified by the Belastingdienst) before the API call to reject obviously invalid numbers instantly; however, pass all format-valid numbers to the API regardless of the checksum result, since VIES is the authoritative source.
3. **Check against Dutch Tax and Customs Administration** — The TaxID API forwards the request to the Belastingdienst's VIES node. Response times are typically under 500 ms. The Belastingdienst node is generally reliable but can return service_unavailable during the first business days of January when VAT registration systems are under higher load. Implement a 3-retry policy with 30-second delays for service_unavailable responses to handle these transient outages.
4. **Return KvK-linked company data** — TaxID returns the company_name and company_address from the VIES response for Dutch numbers. The company_name is the trade name registered with the Belastingdienst, which may differ from the KvK-registered trade name for companies operating under a different commercial name. Store both the BTW number and the VIES-confirmed company_name in your customer record to support the name-check requirement for Dutch reverse-charge invoices.

---

## Validate Spanish NIF and CIF numbers
https://www.taxid.dev/use-cases/spain-nif-cif-check

Spain uses three identifier formats under the umbrella of NIF (Número de Identificación Fiscal). For legal entities (S.L., S.A., cooperatives, etc.), the identifier is a letter + 7 digits + a control character (e.g. A12345678) — these are often called CIF historically, but the official term since 2008 is NIF for legal persons. For Spanish individuals, the NIF is the DNI: 8 digits + a letter (e.g. 12345678Z), computed from a fixed letter table on the number modulo 23. For foreign nationals, the NIE replaces the first digit with X, Y, or Z followed by 7 digits and a letter (e.g. X1234567L).

Only legal-entity NIFs are registered in VIES with the ES prefix; individual NIFs and NIEs are never VIES-registered because Spanish individuals are not VAT taxable persons. Before calling the TaxID API, your application should detect the identifier type: if it starts with a letter that corresponds to the legal-entity alphabet (A, B, C, D, E, F, G, H, J, N, P, Q, R, S, U, V, W), proceed with a VIES lookup; if it matches the DNI or NIE pattern, validate the checksum locally and capture it for invoicing without querying VIES.

The Agencia Tributaria (AEAT) processes ES VIES queries. Response times are generally under 1 second, but the AEAT node can be slow during peak periods (end of fiscal quarter). For the VIES query, pass the full identifier including the ES prefix to GET /api/v1/validate/ES/:nif. The company_address returned typically includes the registered address from the AEAT's records, which should be stored for legal invoicing compliance.

1. **Identify NIF vs CIF vs NIE format** — Run the input through three sequential regex checks: /^[ABCDEFGHJNPQRSUVW][0-9]{7}[0-9A-J]$/ for legal-entity NIFs (CIF), /^[0-9]{8}[A-Z]$/ for individual DNI/NIF, and /^[XYZ][0-9]{7}[A-Z]$/ for NIE. Only legal-entity NIFs should trigger a VIES lookup; for DNI and NIE patterns, validate the checksum locally and store the identifier for invoice rendering without calling the external API.
2. **Validate checksum locally before API call** — For legal-entity NIFs, compute the control character using the AEAT's algorithm: sum odd-position and even-position digits separately (with a conversion table for letters in even positions), derive the modulo-10 remainder, and look up the expected control character. For individual NIFs/DNIs, use the modulo-23 algorithm against the fixed letter sequence 'TRWAGMYFPDXBNJZSQVHLCKE'. Reject numbers that fail the local checksum with a specific error message before consuming an API call.
3. **Query VIES for active registration** — Call GET /api/v1/validate/ES/:nif for legal-entity NIFs that pass local checksum validation. The ES country code instructs TaxID to query the AEAT's VIES node. Parse the response: status: 'active' confirms the entity is VIES-registered and eligible for reverse-charge; status: 'invalid' means the NIF is not in VIES (the entity may exist but not be VAT-registered for EU transactions); status: 'service_unavailable' means the AEAT node is temporarily unreachable.
4. **Return AEAT-confirmed company details** — On a valid response, store the company_name and company_address from the TaxID response in your customer record. Spanish invoicing regulations (Real Decreto 1619/2012) require B2B invoices to include the buyer's NIF and registered name; using the AEAT-confirmed company_name from VIES eliminates discrepancies that arise when buyers provide a trade name instead of their registered legal entity name.

---

## Validate Italian Partita IVA
https://www.taxid.dev/use-cases/italy-partita-iva-validation

Italian Partita IVA numbers consist of the IT prefix followed by exactly 11 digits (e.g. IT12345678901). The first 7 digits identify the business, the next 3 digits identify the province of registration (a value between 001 and 100, plus special codes 120, 121, and 999 for certain entities), and the final digit is a check digit computed using a Luhn-variant algorithm. This local checksum validation catches transposition errors before they reach the VIES network.

The Luhn-variant for Italian VAT works as follows: sum the digits in odd positions (1, 3, 5, 7, 9) as-is; for digits in even positions (2, 4, 6, 8, 10), double each digit — if the result is 10 or more, subtract 9; sum all values; the check digit (position 11) is (10 - (total mod 10)) mod 10. If a provided number fails this check, reject it immediately without calling the TaxID API, since VIES will also reject it and the API call would be wasted.

The Agenzia delle Entrate submits Italian Partita IVA registrations to VIES. The Italian VIES node is generally reliable but returns only the registered status without company name or address for many Italian entities, unlike some other EU member states. When company_name is null in the TaxID response, fall back to displaying the validated Partita IVA number as confirmation rather than showing a blank field, and consider supplementing with a lookup against the Italian Business Register (Registro delle Imprese) if full company details are required.

1. **Validate 11-digit IT format** — Strip the IT prefix and any spaces, then confirm the remainder is exactly 11 numeric digits using /^[0-9]{11}$/. Additionally, check that digits 8–10 (the province code, 0-indexed) form a value between 001 and 100 inclusive or match the special codes 120, 121, or 999; province codes outside this range indicate a malformed number that should be rejected before the checksum step.
2. **Run Luhn checksum locally** — Implement the Italian VAT Luhn variant: iterate over the first 10 digits; for odd positions (1,3,5,7,9, 1-indexed), add the digit directly; for even positions (2,4,6,8,10), double it and subtract 9 if the result is ≥ 10; sum all values and compute (10 - (sum mod 10)) mod 10; compare to digit 11. Reject numbers where the check digit does not match before calling GET /api/v1/validate/IT/:vatNumber, as this eliminates a significant proportion of typo-induced invalid API calls.
3. **Query VIES for active status** — After passing local format and checksum checks, call GET /api/v1/validate/IT/:vatNumber. The TaxID API queries the Agenzia delle Entrate's VIES node. A status: 'active' response confirms the Partita IVA is registered for EU intra-community transactions and that reverse-charge treatment under Article 196 of the VAT Directive applies. A status: 'invalid' means the number exists in Italian records but is not currently active in VIES — the business may be newly registered, suspended, or operating only domestically.
4. **Handle Agenzia delle Entrate response** — The Italian VIES node frequently returns a valid status without accompanying company_name or company_address data. Handle null values gracefully: display 'Partita IVA verified' with the validated number when company_name is null, rather than showing a blank confirmation. For invoicing, source the legal company name from an alternative Italian business register API (e.g. Registro delle Imprese via Infocamere) if required for invoice compliance under DPR 633/1972.

---

## B2B Invoice VAT Validation — Validate VAT Numbers Before Invoicing
https://www.taxid.dev/use-cases/b2b-invoice-validation

An EU B2B invoice that claims reverse-charge treatment must carry the buyer's valid VAT number at the time the invoice is issued. If the VAT number on the invoice turns out to be invalid — because it was entered incorrectly, the business deregistered, or it was never VIES-active — the invoice can be challenged by tax authorities in the buyer's country, resulting in denial of the buyer's input VAT reclaim and a potential VAT liability for the seller who zero-rated the supply without a valid registration to back it up.

The practical implementation is a pre-generation hook: before your invoicing engine (whether that is Stripe Billing, a custom PDF generator, or a third-party tool like Docusign or Invoiced) renders the invoice, call GET /api/v1/validate/:country/:vat. TaxID caches active numbers for 24 hours, so for high-volume invoice runs the majority of repeat lookups return in under 10 ms. Use the response's cached field to distinguish a live VIES confirmation from a cached one; for very high-value invoices, consider forcing a live check by implementing a separate daily re-validation routine.

If the validation returns invalid, block invoice generation and raise an alert to your accounts-receivable team with the customer ID, the failing VAT number, and the TaxID request_id. Store the full validation result — status, company_name, company_address, request_id, and timestamp — in an audit log table indexed by invoice_id. This log satisfies the EU requirement that businesses maintain evidence of the VAT status of their B2B customers for at least ten years.

1. **Trigger before invoice creation** — Insert a pre-generation step in your invoicing pipeline that calls GET /api/v1/validate/:country/:vat immediately before rendering or dispatching the invoice. For Stripe Billing, implement this in an invoice.created webhook handler that checks the status and cancels (voids) the invoice via stripe.invoices.voidInvoice() if the VAT number is invalid, preventing an incorrect invoice from ever reaching the customer.
2. **Cache validation result for 24h** — Store the TaxID response in your application cache (Redis or database) using the key invoice_vat:{customer_id} with a TTL of 86400 seconds for active numbers and 3600 seconds for invalid ones, matching TaxID's own cache policy. Check this cache before calling the API so that monthly invoicing runs for thousands of customers do not each independently call the API for the same customer, preserving your API quota and keeping the pipeline fast.
3. **Block invoice if VAT is invalid** — When status is 'invalid', halt the invoicing pipeline for that customer, set a flag (e.g. invoice_blocked_reason: 'invalid_vat') on the customer record, and notify your AR team via email or Slack webhook with the customer name, the invalid VAT number, and the TaxID request_id. Do not silently generate the invoice with a valid-VAT assumption — the tax liability risk of issuing a zero-rated invoice without a confirmed active VAT registration sits with the seller.
4. **Log validation for audit trail** — Persist every validation check to an invoice_vat_audit table with columns: invoice_id, customer_id, country_code, vat_number, status, company_name, request_id, validated_at. Index on invoice_id and validated_at for efficient retrieval during tax audits. EU VAT regulations require records to be kept for at least 10 years, and having the request_id enables you to dispute any challenge by demonstrating you performed a live VIES verification at the time of invoicing.

---

## EU OSS VAT validation for digital services
https://www.taxid.dev/use-cases/digital-services-oss-registration

Under the EU VAT rules for digital services (effective 2015, consolidated in the 2021 OSS reform), a supplier of electronically supplied services must charge VAT at the rate applicable in the customer's country of residence when selling to EU consumers. However, when the customer is a VAT-registered business in another EU member state, the supply falls under the reverse-charge mechanism (EU VAT Directive Article 196) and the supplier charges zero VAT. The entire tax obligation classification — OSS B2C at local rate, or reverse-charge B2B at zero — therefore hinges on whether the customer holds a valid VAT number.

The decision tree at checkout is: does the customer provide a VAT number? If yes, call GET /api/v1/validate/:country/:vat. If status: 'active', classify as B2B reverse-charge, charge zero VAT, and record for the OSS return as a non-reportable B2B supply. If status: 'invalid' or no VAT number provided, classify as B2C, determine the customer's country from billing address (two-factor evidence is best practice: IP geolocation + billing country), look up the local VAT rate, and record the transaction for the OSS quarterly return.

OSS returns are filed quarterly and must separately report each member state's B2C revenue at that state's VAT rate. Maintaining a clean classification at the transaction level — storing each order's vat_treatment ('reverse_charge' or 'oss_b2c'), the customer's member state, and the applied rate — makes the quarterly OSS filing a straightforward aggregation rather than a retroactive classification exercise.

1. **Determine customer location** — Collect two non-contradictory pieces of evidence for the customer's EU member state: their billing address country and their IP geolocation country. EU VAT rules for digital services require two-factor evidence to determine the place of supply; a single data point (e.g. billing country alone) can be challenged by tax authorities. If both factors agree, use that country as the place of supply; if they conflict, apply the customer's declared billing address with a note for audit purposes.
2. **Validate VAT number for B2B classification** — Call GET /api/v1/validate/:country/:vat when the customer provides a VAT number at checkout. A response of status: 'active' classifies the sale as B2B reverse-charge: set vat_treatment: 'reverse_charge' and zero_rate: true on the order. A response of status: 'invalid' reverts the customer to B2C classification; do not block the purchase, but do flag the invalid number so your support team can follow up. For status: 'service_unavailable', hold the B2B classification pending re-validation and apply standard VAT conservatively.
3. **Apply reverse charge or local VAT rate** — For B2B reverse-charge orders, issue the invoice with zero VAT and include the annotation 'VAT reverse charged — Article 196 EU VAT Directive' and the buyer's validated VAT number. For B2C orders, apply the VAT rate for the customer's member state: maintain a rate table keyed by ISO country code (e.g. DE: 19%, FR: 20%, IT: 22%, ES: 21%) or use a tax provider such as Stripe Tax or Avalara that handles rate lookups automatically.
4. **Record for OSS quarterly returns** — Store each transaction with: vat_treatment ('reverse_charge' | 'oss_b2c'), member_state (ISO code), vat_rate_applied, vat_amount, and net_amount. At quarter-end, aggregate oss_b2c rows by member_state to produce the per-country revenue and VAT amounts for the OSS return filed in your EU registration country. Reverse-charge transactions are excluded from OSS reporting — they are reported only by the buyer on their local VAT return.

---

## Build a tax compliance platform with VAT validation
https://www.taxid.dev/use-cases/tax-compliance-platform

A tax compliance SaaS platform needs VAT validation as a foundational capability that multiple product features — invoicing, billing, KYB, seller onboarding — can consume without each embedding its own HTTP client and caching logic. The right architecture is a dedicated VAT validation microservice or module that exposes an internal API, manages its own cache layer, and publishes domain events (e.g. VATValidated, VATInvalidated, VATStatusChanged) that other modules subscribe to.

Multi-tenancy introduces additional complexity: each tenant's VAT validation requests must be isolated so one tenant's cache cannot bleed into another's, API key quotas must be enforced per-tenant if you are re-selling TaxID capacity, and audit logs must be partitioned by tenant_id for data-residency compliance. Structure your internal validation service to accept a tenant_id alongside every request and prefix all cache keys and audit table rows with the tenant scope.

Webhook notifications are valuable when VAT numbers change status — a business can deregister from VIES, causing a previously valid customer to become invalid. Implement a daily re-validation job for all customers with status: 'active' (TaxID's 24-hour cache window means once-daily calls are the minimum meaningful frequency) and fire a webhook to the tenant's configured endpoint when a status change is detected. Include the old_status, new_status, company_name, request_id, and timestamp in the webhook payload for downstream automation.

1. **Design VAT validation microservice** — Create a standalone service (or a well-bounded module) with a single public method: validate(tenantId, country, vatNumber): Promise<VATResult>. Internally, check the tenant-scoped cache first (key: {tenantId}:vat:{country}:{vat}), call GET /api/v1/validate/:country/:vat on a miss, store the response with the appropriate TTL (86400 s for active, 3600 s for invalid), and emit a domain event via your message bus. This design allows the service to be independently scaled and replaced without touching callers.
2. **Implement webhook for real-time updates** — Allow tenants to register a webhook URL in their platform settings. When your daily re-validation job detects a status change (e.g. a previously active number returns invalid), POST a signed webhook payload to the tenant's URL with fields: event: 'vat.status_changed', old_status, new_status, country, vat_number, company_name, request_id, and occurred_at. Sign the payload with HMAC-SHA256 using a per-tenant secret so tenants can verify the webhook's authenticity before acting on it.
3. **Store validation history per customer** — Maintain a vat_validation_history table with columns: id, tenant_id, customer_id, country_code, vat_number, status, company_name, company_address, request_id, source ('api_call' | 'cache' | 'background_revalidation'), and validated_at. Never overwrite previous rows — append a new row on every validation event. This append-only log lets you reconstruct the exact validation status at any historical point in time, which is essential for defending reverse-charge decisions during a tax audit.
4. **Build compliance dashboard with audit trail** — Expose a compliance dashboard screen that shows each customer's current VAT status, the date of last validation, the source (live VIES vs cached), and the full history of status changes. Add a manual re-validate button that calls your microservice with source: 'manual' and refreshes the UI. Include a CSV export of the audit trail filtered by date range so tenants can produce the evidence bundle required by their local tax authority without needing to query your database directly.

---

## Next.js server action for VAT validation
https://www.taxid.dev/use-cases/next-js-vat-form

Next.js 14 Server Actions allow you to call server-side code directly from a React component without writing a separate API route. For VAT validation, this means the TaxID API key never leaves the server, the fetch call runs in the Node.js runtime where you have access to environment variables, and the result is streamed back to the client as a serialised server response. The form component uses useTransition to track the pending state and provide optimistic UI feedback while the validation runs.

The Server Action calls GET /api/v1/validate/:country/:vat with the Authorization header populated from process.env.TAXID_API_KEY, parses the JSON response into a typed VATResult object, and returns it to the client. The 'use server' directive marks the function as a Server Action, and calling it from the client triggers a POST to Next.js's internal actions endpoint — the network request is handled by the framework, not by your code.

Using useTransition alongside the Server Action provides two benefits: isPending is true while the action is running, which drives the loading spinner, and the transition does not block the React render pipeline, so the rest of the page remains interactive. Combine this with React's useOptimistic hook if you want to speculatively show a 'validating' state before the server confirms, giving instant visual feedback to users on high-latency connections.

1. **Create Server Action for VAT validation** — Define an async function in a file with 'use server' at the top (or inline with the directive). The function signature should be: async function validateVAT(country: string, vat: string): Promise<VATResult>. Inside, call fetch(`https://api.taxid.pro/v1/validate/${country}/${vat}`, { headers: { Authorization: `Bearer ${process.env.TAXID_API_KEY}` }, next: { revalidate: 3600 } }) and return the typed response. The next.revalidate option enables Next.js data cache for repeated lookups.
2. **Add optimistic UI with useTransition** — In your client component, call const [isPending, startTransition] = useTransition() and wrap the Server Action call in startTransition(() => { validateVAT(country, vat).then(setResult) }). Set isPending to true immediately while the transition is in flight, which triggers your loading indicator without blocking the rest of the page. This pattern is idiomatic Next.js 14 and avoids the complexity of manual loading state management.
3. **Display company name confirmation** — When the Server Action resolves with status: 'active', update component state with the result and render the company_name from the VATResult in a highlighted confirmation block. For status: 'invalid', show an inline validation error adjacent to the VAT input field. For status: 'service_unavailable', display a non-blocking warning ('VAT verification is temporarily unavailable — your number will be validated shortly') and allow the form to proceed so users are not blocked by a VIES outage.
4. **Handle pending and error states** — Use isPending from useTransition to show a spinner on the submit button and disable the VAT input during validation, preventing double-submissions. Wrap the startTransition call in a try/catch to handle network errors and surface them as a user-facing error state rather than a silent failure. For the error state, distinguish between a TaxID API error (HTTP 4xx/5xx) and a VIES service_unavailable response (HTTP 200 with status: 'service_unavailable') — they require different UX responses.

---

## EU VAT validation in Go
https://www.taxid.dev/use-cases/go-vat-validation

Go's standard library net/http package is fully capable of calling the TaxID REST API without any third-party dependencies. The API returns a JSON object that maps cleanly to a Go struct, and the encoding/json package handles unmarshalling with no additional setup. This zero-dependency approach is well-suited to Go microservices where dependency footprint and binary size are concerns.

Defining a typed VATResult struct (with fields Valid bool, Status string, CompanyName string, CompanyAddress string, Cached bool, RequestID string and appropriate json tags) gives you compile-time safety and eliminates the map[string]any boilerplate. Wrap the HTTP call in a function that returns (*VATResult, error) so callers receive a nil pointer on non-200 responses and can apply standard Go error handling patterns.

For production microservices, create a shared http.Client with a custom timeout (typically 10 seconds to account for slow VIES member-state nodes) and reuse it across calls rather than using http.Get, which creates a new client with no timeout on each call. For high-throughput services, add a sync.Map or an external Redis cache keyed on country + vat number to serve repeat lookups without consuming API quota.

1. **Import net/http and encoding/json from the standard library** — No go get is required — both packages ship with the Go standard library. Declare a VATResult struct with JSON tags matching the TaxID response fields: Valid (json:"valid"), Status (json:"status"), CompanyName (json:"company_name"), CompanyAddress (json:"company_address"), Cached (json:"cached"), and RequestID (json:"request_id"). This struct is your single source of truth for the API contract.
2. **Build a GET request with the Authorization header** — Construct the URL as fmt.Sprintf("https://api.taxid.pro/v1/validate/%s/%s", country, vat) and create an http.Request with http.NewRequestWithContext(ctx, http.MethodGet, url, nil). Set the Authorization header with req.Header.Set("Authorization", "Bearer "+apiKey) using an API key loaded from os.Getenv("TAXID_API_KEY"). Always pass a context so the caller can enforce timeouts and cancel in-flight requests during graceful shutdown.
3. **Decode the JSON response into map[string]any or a typed struct** — After executing the request with client.Do(req), check resp.StatusCode == http.StatusOK before decoding. Use json.NewDecoder(resp.Body).Decode(&result) where result is your VATResult pointer. Always call resp.Body.Close() in a defer statement to avoid connection leaks, which are especially impactful in high-concurrency services where leaked connections exhaust the connection pool.
4. **Handle valid, invalid, and service_unavailable cases** — Switch on result.Status after decoding: case "active" proceeds with B2B reverse-charge logic; case "invalid" returns a validation error to the caller; case "service_unavailable" returns a sentinel error (e.g. ErrVIESUnavailable = errors.New("VIES temporarily unavailable")) that the caller can identify with errors.Is and handle by retrying or falling back to standard VAT rather than silently treating the number as valid.

---

## EU VAT validation in Java
https://www.taxid.dev/use-cases/java-spring-vat-validation

Java 11 introduced java.net.http.HttpClient as a modern, non-blocking replacement for the legacy HttpURLConnection. Combined with Jackson's ObjectMapper for JSON deserialization, it provides a clean, dependency-minimal path to calling the TaxID REST API. For Spring Boot applications, the natural pattern is to encapsulate the HttpClient in a @Service bean, inject the API key from @Value("${taxid.api-key}"), and return a typed VATResult record.

Define a Java record (Java 16+) or a simple POJO for VATResult with fields: boolean valid, String status, String companyName, String companyAddress, boolean cached, String requestId. Jackson's @JsonProperty annotation handles the snake_case-to-camelCase mapping. Using a record makes the result immutable and provides equals/hashCode/toString for free, simplifying caching and logging.

In Spring Boot, register the VATValidationService as a @Service, wire it into your @RestController or @Service billing layer, and test it with @SpringBootTest and a mocked HttpClient using Mockito. For integration tests, use WireMock to stub the TaxID API and simulate all three status responses (active, invalid, service_unavailable) to verify your branching logic without network access.

1. **Use java.net.http.HttpClient — no extra HTTP library needed** — Create a shared HttpClient instance: HttpClient client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(5)).build(). Make it a Spring @Bean or a static field — HttpClient is thread-safe and designed for reuse. Avoid creating a new HttpClient per request, which would bypass connection pooling and create unnecessary overhead under load.
2. **Set the Authorization header with your API key from environment** — Build the request: HttpRequest request = HttpRequest.newBuilder().uri(URI.create("https://api.taxid.pro/v1/validate/" + country + "/" + vat)).header("Authorization", "Bearer " + apiKey).timeout(Duration.ofSeconds(10)).GET().build(). Load apiKey from System.getenv("TAXID_API_KEY") or, in Spring Boot, inject it with @Value("${taxid.api-key}") in the service constructor. Never hardcode the key.
3. **Deserialize the JSON response with Jackson ObjectMapper** — Send the request synchronously with client.send(request, BodyHandlers.ofString()) and pass the response body to objectMapper.readValue(response.body(), VATResult.class). Configure ObjectMapper with DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES set to false so new fields added to the TaxID response in the future do not break deserialization. Throw a VATServiceException wrapping the HTTP status code for non-200 responses.
4. **Return B2B validation status to your billing or checkout logic** — Return the VATResult record to your caller and branch on result.status(): for "active", set the customer's taxTreatment to REVERSE_CHARGE in your billing model; for "invalid", throw a VATValidationException that your controller maps to a 422 response with a user-facing message; for "service_unavailable", throw a VATServiceUnavailableException that maps to 503 so the caller can implement retry logic without coupling it to the service implementation.

---

## EU VAT validation in Ruby / Rails
https://www.taxid.dev/use-cases/ruby-rails-vat-validation

Ruby's standard Net::HTTP library, combined with the built-in JSON module, is sufficient to call the TaxID REST API without adding gems. The idiomatic Rails pattern is a service object (app/services/vat_validation_service.rb) that wraps the HTTP call, and an ActiveRecord concern or model callback that invokes the service on customer creation or update. This keeps the HTTP logic isolated from the model layer and testable with standard RSpec doubles.

The service class uses Net::HTTP.start with use_ssl: true and sets the Authorization header on the request object. The response body is parsed with JSON.parse, giving a Ruby hash with string keys (valid, status, company_name, company_address, cached, request_id). Symbolise the keys with response.transform_keys(&:to_sym) for idiomatic Ruby access. Wrap the HTTP call in a begin/rescue block catching Net::HTTPError and JSON::ParserError to handle network failures without crashing the calling thread.

For Rails applications, storing the validation result in a VATValidation ActiveRecord model (with columns: customer_id, country_code, vat_number, status, company_name, request_id, validated_at) provides both the audit trail required by EU VAT regulations and a caching layer. Query this model before calling the API: skip the network call if a record exists with validated_at within the last 24 hours for active status, or within the last hour for invalid status.

1. **Use Net::HTTP with use_ssl = true for the HTTPS request** — Require 'net/http', 'uri', and 'json' at the top of your service class. Parse the URL with URI.parse("https://api.taxid.pro/v1/validate/#{country}/#{vat}") and open a connection with Net::HTTP.start(uri.host, uri.port, use_ssl: true, open_timeout: 5, read_timeout: 10). Setting explicit timeouts prevents the HTTP call from blocking a Puma worker thread indefinitely when VIES member-state nodes are slow.
2. **Set the Authorization header with your API key from ENV** — Build a Net::HTTP::Get request object: request = Net::HTTP::Get.new(uri). Set the header with request['Authorization'] = "Bearer #{ENV.fetch('TAXID_API_KEY')}". Use ENV.fetch (not ENV[]) so that a missing environment variable raises a KeyError at startup rather than silently sending an unauthenticated request that returns a 401 in production.
3. **Parse the JSON response with Ruby's built-in JSON module** — Call response = http.request(request) and check response.code == '200' before parsing. Parse the body with result = JSON.parse(response.body, symbolize_names: true) to get symbol-keyed access (:status, :company_name, :request_id, etc.). Rescue JSON::ParserError in case the API returns a non-JSON error body, and raise a VATService::ParseError with the raw body included for debugging.
4. **Update your ActiveRecord model with the validation result and company name** — After parsing, upsert a VATValidation record: VATValidation.upsert({ customer_id:, country_code:, vat_number:, status: result[:status], company_name: result[:company_name], request_id: result[:request_id], validated_at: Time.current }, unique_by: [:customer_id, :vat_number]). Also update the parent Customer record's company_name if the VIES-returned name differs, and set tax_exempt: true on the customer when status is 'active'.

---

## EU VAT validation in .NET / C#
https://www.taxid.dev/use-cases/dotnet-vat-validation

.NET 6+ provides System.Net.Http.HttpClient and System.Text.Json as first-class built-ins, making the TaxID REST API call straightforward without adding NuGet packages. The recommended pattern in ASP.NET Core is IHttpClientFactory, which manages HttpClient lifetimes, connection pooling, and DNS rotation — avoiding the socket exhaustion issue that arises from instantiating HttpClient with new HttpClient() in per-request code.

Define a C# record for the response: record VATResult(bool Valid, string Status, string? CompanyName, string? CompanyAddress, bool Cached, string RequestId). Use JsonPropertyName attributes to handle the snake_case API fields. Returning a record rather than a class gives you value equality and immutability, which simplifies unit testing and caching key comparisons.

For ASP.NET Core applications, register the typed client in Program.cs: builder.Services.AddHttpClient<VATValidationService>(client => { client.BaseAddress = new Uri("https://api.taxid.pro/"); client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", builder.Configuration["TaxID:ApiKey"]); }). This makes the API key injectable from appsettings.json or environment variables without the service class needing to access IConfiguration directly.

1. **Register HttpClient via IHttpClientFactory in your DI container** — In Program.cs or Startup.cs, call builder.Services.AddHttpClient<VATValidationService>(client => { client.BaseAddress = new Uri("https://api.taxid.pro/"); client.Timeout = TimeSpan.FromSeconds(10); }). This registers a typed HttpClient that is injected into VATValidationService via constructor injection, follows ASP.NET Core's recommended lifetime management, and automatically rotates DNS to handle infrastructure changes at the TaxID API.
2. **Set the Authorization header with your API key from IConfiguration** — In the VATValidationService constructor, set _httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", configuration["TaxID:ApiKey"]). Store the key in appsettings.json under TaxID:ApiKey and override it with an environment variable TAXID__APIKEY (double underscore for nested keys) in your deployment environment, keeping the key out of source control.
3. **Deserialize the response with System.Text.Json into a C# record type** — Call var response = await _httpClient.GetAsync($"v1/validate/{country}/{vat}", cancellationToken) and check response.EnsureSuccessStatusCode(). Deserialize with var result = await response.Content.ReadFromJsonAsync<VATResult>(cancellationToken: cancellationToken). Configure JsonSerializerOptions with PropertyNamingPolicy = JsonNamingPolicy.SnakeCaseLower (available in .NET 8) or use [JsonPropertyName("company_name")] attributes on the record properties to map snake_case API fields to PascalCase C# names.
4. **Return the VATResult to your controller or application service** — Return the VATResult record from ValidateAsync and let the caller switch on result.Status: "active" triggers Stripe tax_exempt: 'reverse' or equivalent billing logic; "invalid" returns a ValidationProblem response from your API controller; "service_unavailable" throws a VIESUnavailableException that your global exception handler maps to HTTP 503, signalling to the client that it should retry rather than treating the number as definitively invalid.

---

## EU VAT validation in Cloudflare Workers
https://www.taxid.dev/use-cases/cloudflare-workers-vat-validation

Cloudflare Workers run JavaScript/TypeScript at the network edge across 300+ data centres worldwide, meaning VAT validation requests are handled within milliseconds of the end user regardless of their location in the EU. Workers have no cold starts (unlike AWS Lambda or Vercel Functions), making them ideal for latency-sensitive checkout flows where VAT validation is in the critical path.

The TaxID API is called from inside the Worker's fetch handler using the standard global fetch function, with the API key injected via env.TAXID_API_KEY (a Worker secret stored with wrangler secret put TAXID_API_KEY). The Worker can also serve as a reverse-proxy caching layer: use the Cloudflare Cache API (caches.default) to store validation results at the edge for 24 hours for active numbers, reducing round-trips to the TaxID origin for repeat lookups from the same edge node.

Workers integrate naturally with Cloudflare D1 (SQLite at the edge) or KV (key-value store) for audit logging. Storing each validation result in KV with a composite key of {country}:{vat} and a TTL matching TaxID's cache window means that multiple Workers across different edge nodes share the same cached results, maximising cache hit rates across a globally distributed checkout infrastructure.

1. **Create a Worker with the standard fetch handler** — Initialise the project with npm create cloudflare@latest and choose the 'Hello World' TypeScript template. The Worker's entry point is export default { async fetch(request: Request, env: Env): Promise<Response> { ... } }. Define the Env interface with TAXID_API_KEY: string so TypeScript enforces that the secret binding is declared in wrangler.toml before the Worker is deployed.
2. **Store TAXID_API_KEY as a Worker secret via wrangler secret put** — Run npx wrangler secret put TAXID_API_KEY in your terminal and paste the API key when prompted. This encrypts the key at rest in Cloudflare's secret store and injects it into env.TAXID_API_KEY at runtime without it appearing in wrangler.toml or source control. Never use a plaintext [vars] entry in wrangler.toml for the API key — vars values are visible in the Cloudflare dashboard to any team member with Workers access.
3. **Forward validation requests to the TaxID API with env.TAXID_API_KEY** — Inside the fetch handler, extract country and vat from the request URL path or query string, then call: const res = await fetch(`https://api.taxid.pro/v1/validate/${country}/${vat}`, { headers: { Authorization: `Bearer ${env.TAXID_API_KEY}` } }). Parse the JSON response and inspect result.status to determine the validation outcome before returning a response to the caller.
4. **Return the JSON response with Cache-Control headers for valid results** — For status: 'active' responses, set Cache-Control: public, max-age=86400 on the Worker's outbound response so Cloudflare's edge cache stores the result for 24 hours. Use the Cache API (const cache = caches.default; await cache.put(request, response.clone())) for fine-grained control. For invalid and service_unavailable responses, set Cache-Control: no-store to prevent negative results from persisting beyond the current request.

---

## EU VAT validation in Deno
https://www.taxid.dev/use-cases/deno-vat-validation

Deno's built-in fetch API, first-class TypeScript support, and permission-based security model make it an excellent runtime for calling external APIs like TaxID. The permission system requires --allow-net to make outbound HTTP requests and --allow-env to read environment variables, which means the validation function cannot silently make network calls without explicit operator approval — a useful security property for compliance-sensitive applications.

Deno Deploy runs the same code globally on V8 isolates with sub-millisecond cold starts, making it a viable alternative to Cloudflare Workers for edge-deployed VAT validation. The deployment is triggered by a git push with no Docker, no YAML manifests, and no build step — the TypeScript source is executed directly. Environment variables (including the TaxID API key) are configured in the Deno Deploy dashboard and injected via Deno.env.get('TAXID_API_KEY').

TypeScript interfaces defined in Deno are structurally typed, so the VATResult interface doubles as documentation and a compile-time guard against typos in field access. Because Deno has no node_modules directory and no package.json, dependency management for this use case is entirely optional — the standard library's fetch and JSON.parse are the only tools needed.

1. **Use Deno's built-in fetch — no imports needed for HTTP** — Deno's global fetch is available in all contexts without any import. Define an async function validateVAT(country: string, vat: string): Promise<VATResult> that calls fetch(`https://api.taxid.pro/v1/validate/${country}/${vat}`, { headers: { Authorization: `Bearer ${Deno.env.get('TAXID_API_KEY')}` } }). The function is immediately usable in any Deno script without installing dependencies or modifying a package manifest.
2. **Load the API key from Deno.env or a .env file** — In local development, create a .env file with TAXID_API_KEY=your_key and load it using Deno's built-in --env flag (deno run --env --allow-net --allow-env validate.ts). In Deno Deploy, set the environment variable in the project dashboard. Access it with Deno.env.get('TAXID_API_KEY') and throw an error at startup if it is undefined rather than silently sending unauthenticated requests.
3. **Define a TypeScript interface for the VATResult response** — Declare: interface VATResult { valid: boolean; status: 'active' | 'invalid' | 'service_unavailable'; company_name: string | null; company_address: string | null; cached: boolean; request_id: string; }. Cast the parsed JSON to this interface with const result = await response.json() as VATResult. While this is a type assertion rather than runtime validation, combining it with a runtime check on result.status being one of the three known values adds a safety net against unexpected API changes.
4. **Run with --allow-net --allow-env or deploy to Deno Deploy** — Execute locally with deno run --allow-net=api.taxid.pro --allow-env=TAXID_API_KEY validate.ts — scoping --allow-net to the specific domain restricts the script from making outbound calls to any other host, which is a stronger security posture than blanket --allow-net. For Deno Deploy, push the file to GitHub and connect the repository in the Deno Deploy dashboard; the runtime permissions are automatically granted to the deployed isolate.

---

## EU VAT validation on Vercel Edge
https://www.taxid.dev/use-cases/vercel-edge-vat-validation

Vercel Edge Functions run on the V8 isolate runtime in Vercel's global network, executing your Next.js API routes at the edge closest to the end user. Declaring export const runtime = 'edge' on an API route opts it into this runtime, which has sub-50ms cold starts and no Node.js-specific APIs (no fs, no child_process) — but it has full access to the global fetch, which is all that is needed to call the TaxID REST API.

Next.js's built-in data cache understands the next: { revalidate } option in fetch calls, so passing next: { revalidate: 3600 } to the TaxID API request caches the response at the Vercel edge for one hour. For active VAT numbers, you can extend this to 86400 (24 hours) to match TaxID's own cache window. The cached: true field in the TaxID response tells you whether TaxID itself served the result from cache, providing two layers of caching transparency.

Vercel Edge Functions compose naturally with Next.js Middleware, allowing you to intercept requests and validate VAT numbers before they reach your page handlers. However, for checkout flows where VAT validation is user-initiated, an API route with export const runtime = 'edge' called from a React component is the more appropriate pattern — it keeps the validation result in the component's state and allows for the optimistic UI patterns described in the React use case.

1. **Create an API route with export const runtime = 'edge'** — Create app/api/validate-vat/route.ts and export export const runtime = 'edge' alongside the GET handler. The edge runtime restricts you to Web API-compatible code (no Node.js built-ins), but fetch, URL, Request, and Response are all available. Destructure country and vat from the request URL using new URL(request.url).searchParams to parse the incoming query parameters safely.
2. **Store TAXID_API_KEY in your Vercel environment variables** — Add TAXID_API_KEY to your Vercel project's environment variables via the Vercel dashboard (Settings > Environment Variables) for Production, Preview, and Development environments. Access it in the edge function with process.env.TAXID_API_KEY — Vercel injects environment variables into the edge runtime the same way as the Node.js runtime. Never use next.config.js env for secrets, as those values are bundled into the client-side JavaScript.
3. **Call the TaxID API with next: { revalidate: 3600 } for edge caching** — Inside your GET handler, call: const res = await fetch(`https://api.taxid.pro/v1/validate/${country}/${vat}`, { headers: { Authorization: `Bearer ${process.env.TAXID_API_KEY}` }, next: { revalidate: 86400 } }). The next.revalidate: 86400 option instructs Next.js's data cache to store this response for 24 hours at the edge, matching TaxID's cache window for active numbers and eliminating redundant origin requests for frequently-queried VAT numbers.
4. **Return NextResponse.json to your React frontend or webhook handler** — Parse the TaxID response with const data = await res.json() and return NextResponse.json(data, { headers: { 'Cache-Control': data.status === 'active' ? 'public, max-age=86400' : 'no-store' } }). Setting Cache-Control on the edge function response tells Vercel's CDN layer how long to serve the cached response to subsequent requests for the same country+vat combination, providing a second caching layer on top of Next.js's data cache.

---

## EU VAT Validation for SaaS Businesses
https://www.taxid.dev/use-cases/vat-validation-for-saas

Under EU VAT Directive 2006/112/EC, a SaaS business supplying digital services to EU businesses can apply the reverse-charge mechanism, which shifts the VAT liability to the buyer. This is only valid when you can prove the buyer holds a valid, active VAT registration in their member state. Without verification, you are liable for the full VAT amount — regardless of what the customer claimed.

The TaxID API lets you verify any EU VAT number in real time against the VIES registry before issuing a zero-rated invoice. For each checkout or subscription activation, call GET /api/v1/validate/:country/:vat from your server and check that status is 'active'. Only then set the customer's tax treatment to reverse-charge in your billing system (Stripe, Paddle, or your own invoicing stack).

Subscription SaaS businesses face an ongoing compliance risk: VAT registrations can be cancelled after signup. A number valid at onboarding may be revoked six months later. Schedule a monthly background job to re-validate all reverse-charge customers and flag any returning 'invalid' status before the next billing cycle. The TaxID batch endpoint lets you validate up to 25 numbers per request, which is efficient for large customer lists.

Keep an audit trail: store the validated VAT number, the company_name and company_address from the TaxID response, and the validation timestamp on each invoice or subscription record. EU tax authorities in a VAT audit will ask for proof that the number was valid at the time of each transaction — not just at the time of signup.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup. No credit card required. Store the key as an environment variable in your SaaS backend — never client-side.
2. **Add a VAT number field to your SaaS checkout** — Add a labeled VAT number input to your checkout or onboarding flow. Mark it as optional for consumers and required for customers who request B2B zero-rate treatment. Collect both the country code and the VAT number string.
3. **Validate server-side before creating the subscription** — Before completing checkout, call GET /api/v1/validate/:country/:vat from your server. If status is 'active', flag the customer as reverse-charge eligible and store the validated company details. If 'invalid', return a form error. If 'service_unavailable', charge standard VAT and follow up.
4. **Apply reverse-charge in your billing system** — Update the customer's billing record to reflect reverse-charge treatment. In Stripe, set tax_exempt: 'reverse'. In Paddle, use the customer tax ID field. In your own invoicing stack, add an 'RC' annotation to the invoice and set the VAT rate to zero.
5. **Re-validate monthly for subscription customers** — Run a background job at least once a month that re-calls the TaxID API for every reverse-charge customer. Flag any returning 'invalid' for your finance team to review before the next invoice cycle. Use the batch endpoint (POST /api/v1/validate) to validate up to 25 numbers in one request.

### FAQ

**Do I need to validate EU VAT numbers for every SaaS sale?**
You need to validate when a customer claims B2B reverse-charge treatment (zero-rate VAT). Without a valid, verified VAT number, you cannot legally apply zero-rate — you must charge the standard VAT rate for the customer's country. Consumer sales (B2C) do not require VAT number validation.

**What happens if I zero-rate an invoice without validating the VAT number?**
The VAT liability falls on your business, not the customer. If a tax authority audits you and finds zero-rated invoices without verified VAT numbers, you will owe the full VAT amount plus interest and potentially penalties. The TaxID validation record (company_name, address, validation timestamp) is your proof of due diligence.

**Which EU countries does TaxID cover for SaaS reverse-charge validation?**
All 27 EU member states via VIES: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, and Sweden.

**How do I handle VIES downtime in my SaaS checkout?**
If the TaxID API returns status: 'service_unavailable', do not silently zero-rate the customer. The safest fallback is to charge standard VAT and issue a credit note once VIES recovers. Alternatively, display a message asking the customer to retry in a few minutes. Always log service_unavailable events with customer ID and timestamp.

---

## EU VAT Validation for E-commerce
https://www.taxid.dev/use-cases/vat-validation-for-ecommerce

Cross-border B2B e-commerce in the EU is subject to the intra-community supply rules: when selling goods or services to a VAT-registered business in another EU country, you can apply zero-rate (VAT-exempt) treatment — but only if you can prove the buyer's VAT number is valid and active at the time of sale.

Many e-commerce platforms (Shopify, WooCommerce, Magento, PrestaShop) allow customers to enter a VAT number at checkout, but they do not verify it against any official registry. A customer can enter a plausible-looking number — or even a valid number belonging to another company — and the platform will zero-rate the order without complaint. The TaxID API checks the number against the live VIES registry in real time and returns the company name and address registered with the member state's tax authority.

Build a server-side validation step into your checkout flow: after the customer submits their VAT number, call the TaxID API before confirming the order. If the number is 'active', apply zero-rate and store the validated company details in the order record. If it is 'invalid', show an error. If VIES is temporarily unavailable ('service_unavailable'), charge standard VAT and issue a credit note once the system recovers.

For marketplaces and stores processing high order volumes, use the batch endpoint (POST /api/v1/validate) to validate up to 25 numbers per request. Combined with the 24-hour cache on valid numbers, this keeps API costs predictable even during peak checkout periods.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup and store your API key as a server-side environment variable. Never expose it in client-side JavaScript or checkout scripts.
2. **Add a VAT number field to your checkout** — Add a clearly labeled VAT number input to your B2B checkout form. For WooCommerce, use a checkout hook. For Shopify, use a custom storefront field or checkout extension. For custom stores, add the field to your billing section.
3. **Validate via the TaxID API before confirming the order** — On form submission, call GET /api/v1/validate/:country/:vat from your server. Parse the two-character country prefix from the VAT number (e.g., 'DE' from 'DE123456789'). Check that status === 'active' before applying zero-rate. Return a form error for 'invalid'; charge standard VAT for 'service_unavailable'.
4. **Store the validated company details on the order** — Persist the company_name and company_address from the TaxID response alongside the VAT number and validation timestamp in your order database. This audit record is required under EU invoice rules if you are audited.

### FAQ

**Does my e-commerce platform validate EU VAT numbers automatically?**
No. Shopify, WooCommerce, Magento, and most e-commerce platforms collect VAT numbers as text fields but do not verify them against VIES or any official registry. You need to integrate a validation API — such as TaxID — to check that the number is real and currently active.

**What is the difference between format validation and live VIES validation?**
Format validation checks that the VAT number matches the expected pattern for the country (e.g., DE123456789 for Germany). Live VIES validation checks the number against the EU Commission's registry and confirms it is currently registered to an active business. Only live validation satisfies the EU's verification requirement for zero-rating B2B supplies.

**Which countries can I validate for my e-commerce store?**
The TaxID API validates all 27 EU member states via VIES, plus UK (HMRC), Norway (Brønnøysund Register), and Australia (ABN Lookup). For EU exports, all 27 member states are eligible for zero-rate treatment under intra-community supply rules.

---

## B2B Marketplace EU VAT Compliance
https://www.taxid.dev/use-cases/vat-validation-for-b2b-marketplace

B2B marketplaces face a unique VAT compliance challenge: they must determine the correct tax treatment for transactions between multiple sellers and buyers across EU member states. When a buyer claims B2B status with a EU VAT number, the marketplace must verify that number is real and active before any zero-rate treatment can be applied. Failure to verify exposes the marketplace — or its sellers — to VAT liability.

The TaxID API is designed for high-volume B2B environments. The batch endpoint accepts up to 25 VAT numbers per request, processed in parallel. Valid numbers are cached for 24 hours and invalid numbers for 1 hour, so frequently transacting buyers are validated from cache rather than hitting VIES on every order. The 'cached' field in the response tells you exactly whether the result is live or cached.

For marketplace architectures, call the TaxID API at buyer onboarding to validate and store the VAT number. Re-validate all buyer VAT numbers monthly via a background job using the batch endpoint. On each transaction, check the stored validation status rather than calling the API on every order — this keeps per-transaction latency low while maintaining compliance.

Store the company_name and company_address from the TaxID response in your buyer profile. These details must appear on zero-rated invoices under EU Invoice Directive 2006/112/EC Article 226. Having them verified and stored at onboarding means your invoice generation can pull accurate company details without relying on what buyers self-reported.

1. **Validate at buyer onboarding** — When a business registers on your marketplace, collect their EU VAT number and call GET /api/v1/validate/:country/:vat from your server. Store the validation result (valid, company_name, company_address, validation timestamp) in the buyer's profile.
2. **Apply correct tax treatment per transaction** — At transaction time, check the buyer's stored validation status. If the buyer has a validated 'active' VAT number in an EU country different from the seller's, apply zero-rate (reverse charge) treatment. Otherwise, apply the seller's local VAT rate.
3. **Re-validate all buyers monthly** — Use the batch endpoint (POST /api/v1/validate) to re-validate up to 25 buyer VAT numbers per request. Run this job monthly for all buyers with reverse-charge status. Flag any returning 'invalid' for your compliance team to review and notify the buyer.
4. **Include verified company details on invoices** — Populate invoices with the company_name and company_address from the TaxID validation response, not just from buyer self-registration. This satisfies EU invoice requirements and ensures the billing name matches the tax authority's records.

### FAQ

**Is the B2B marketplace liable for VAT if a buyer provides a fake VAT number?**
If the marketplace makes a good-faith effort to verify the VAT number — for example by calling VIES via the TaxID API and storing the validation record — EU VAT rules (Regulation 282/2011, Article 17) provide protection from liability if the number later turns out to be fraudulent. The key is having a documented verification process and audit trail.

**How does the TaxID batch endpoint help with marketplace scale?**
The batch endpoint (POST /api/v1/validate) accepts up to 25 VAT numbers per request, processed in parallel. Combined with 24-hour caching on valid numbers, this makes monthly re-validation of thousands of buyers efficient and cost-effective. Use it for nightly or weekly reconciliation jobs rather than validating on every transaction.

---

## VAT Validation API for Accounting and Invoicing Tools
https://www.taxid.dev/use-cases/vat-validation-for-accounting-software

Accounting software that generates EU B2B invoices carries a responsibility to verify that zero-rated invoices are correctly applied. When a user creates an invoice for a foreign EU business, the software should validate the buyer's VAT number against VIES before allowing zero-rate treatment. Without this check, accountants and finance teams may unknowingly produce non-compliant invoices.

The TaxID API provides a straightforward REST endpoint that accounting software can call when a user enters a VAT number on a customer record or invoice. The response returns the company_name and company_address registered with the member state's tax authority — which often differs from the self-reported billing details. Displaying this verified information lets the user confirm they are invoicing the right company.

For accounting software with large user bases, the TaxID batch endpoint allows validating multiple VAT numbers in a single API call. This is useful for import flows (bulk customer import, CSV upload) and for monthly compliance checks that re-validate all customers flagged as reverse-charge eligible.

The TaxID API response includes a request_id field that can be stored as an audit reference on each invoice. If a tax authority questions a zero-rated invoice, the accounting software can display the validation record — VAT number, company name, validation timestamp, and request ID — as proof of due diligence.

1. **Validate when a user adds an EU customer** — When a user creates or updates a customer record with an EU VAT number, call GET /api/v1/validate/:country/:vat from your server. Display the returned company_name and company_address so the user can confirm they are adding the correct company.
2. **Block zero-rate invoices for unvalidated customers** — Prevent your invoice UI from allowing zero-rate treatment until the customer's VAT number has been validated as 'active'. Show a validation badge on the customer record — green for active, yellow for pending re-validation, red for invalid.
3. **Store the validation record on each invoice** — When generating a zero-rated invoice, attach the TaxID request_id, the validated company_name, company_address, and validation timestamp to the invoice record. This creates the audit trail required by EU invoice rules.
4. **Re-validate reverse-charge customers on a schedule** — Run a monthly background job using the TaxID batch endpoint to re-validate all customers marked as reverse-charge. Notify accountants of any numbers that have become invalid so they can update customer records and adjust upcoming invoices.

### FAQ

**Why should accounting software validate VAT numbers via API instead of asking users to check manually?**
Manual VIES lookups are error-prone and create no audit record. An API integration validates in real time at the point of customer creation, displays verified company details, and stores a timestamped validation record on each invoice. This reduces manual errors and gives accountants documented proof of compliance.

**Can TaxID validate VAT numbers in bulk for customer imports?**
Yes. The batch endpoint (POST /api/v1/validate) accepts up to 25 VAT numbers per request, processed in parallel. For bulk imports of hundreds of customers, you can fan out multiple batch requests concurrently to validate all entries efficiently.

---

## EU VAT Validation for HR and Payroll Platforms
https://www.taxid.dev/use-cases/vat-validation-for-hr-payroll

HR and payroll platforms operating across the EU increasingly provide employer-of-record (EOR), contractor management, and payroll processing services on a cross-border basis. When invoicing a client business in another EU member state for these services, the supplier can apply reverse-charge if the client holds a valid EU VAT registration. Without verification, the supplier must charge and remit VAT in the client's country — a complex and costly obligation.

The TaxID API provides a real-time validation step that HR platforms can integrate into their client onboarding workflow. When a client business registers and provides their EU VAT number, call the TaxID API to verify it before generating the first invoice. The response returns the registered company name and address, which should match the client's self-reported billing details — a useful fraud-detection signal.

Payroll platforms process invoices on recurring schedules (monthly, bi-weekly) for the same set of clients. Re-validating every client's VAT number on every invoice would add latency and API cost. Instead, validate at onboarding and re-validate monthly via a background job using the TaxID batch endpoint. Store the most recent validation result and timestamp with each invoice for audit purposes.

Cross-border HR services frequently involve multiple EU countries. The TaxID API supports all 27 EU member states via VIES, plus UK (HMRC) for post-Brexit clients. This single endpoint covers the entire EU market, so HR platforms do not need country-specific integrations for each jurisdiction.

1. **Validate at client onboarding** — When a client business signs up, collect their EU VAT number and call GET /api/v1/validate/:country/:vat from your server. Display the returned company_name and company_address to confirm the client's identity before activating their account.
2. **Apply reverse-charge on cross-border invoices** — For clients in a different EU member state with a validated 'active' VAT number, generate invoices with zero VAT and the annotation 'VAT: Reverse charge'. This is required by EU Invoice Directive 2006/112/EC Article 226 for intra-community B2B supplies.
3. **Re-validate clients monthly before invoice generation** — Before each monthly billing cycle, run a batch re-validation of all reverse-charge clients using the TaxID batch endpoint. Flag any clients whose VAT number has become 'invalid' for your finance team to review before generating invoices.
4. **Attach validation records to each invoice** — Store the TaxID request_id, validated company_name, company_address, and validation timestamp with each invoice. This audit trail is your proof of due diligence if a tax authority questions a zero-rated invoice during a VAT inspection.

### FAQ

**Do HR and payroll platforms need to validate EU VAT numbers for every invoice?**
Strictly speaking, you must be able to prove the VAT number was valid at the time of each invoice. The most efficient approach is to validate at onboarding and re-validate monthly, storing the result with each invoice. This satisfies the verification requirement without calling the API on every invoice generation.

**Can TaxID validate UK client VAT numbers for post-Brexit HR services?**
Yes. UK VAT numbers (GB-prefixed) are validated via the HMRC Making Tax Digital API. Pass the full GB-prefixed number (e.g., GB123456789) to the same TaxID endpoint (/api/v1/validate/GB/GB123456789) and it routes to HMRC automatically. UK is no longer part of VIES after Brexit.

---

## VAT Validation for Anti-Money Laundering (AML) Compliance
https://www.taxid.dev/use-cases/aml-vat-validation

Anti-Money Laundering (AML) regulations across the EU, UK, and globally require businesses in financial services, fintech, legal, and increasingly B2B SaaS to perform due diligence on the companies they transact with. A core component of that due diligence is confirming that the counterparty is a legitimately registered business — not a shell entity or a company that has ceased to trade. VAT registration status is one of the most reliable and programmatically accessible indicators of active business status available from government registries.

The TaxID API validates VAT numbers against 31 official government registries in real time and returns the registered company name, address, and registration status. For AML purposes, this creates a verifiable record that at the time of transaction initiation, the counterparty's VAT number was active and matched the declared company identity. The company_name and address fields from VIES allow cross-referencing against the company's self-reported details — a discrepancy (e.g., the VAT number belongs to a real company but the declared name does not match) is a risk signal that warrants enhanced due diligence.

AML regulations in the EU (particularly the 6AMLD and AMLD5) require firms to maintain records of due diligence checks for a minimum of five years. The TaxID API's request_id field uniquely identifies each validation query and can be used as a reference in your compliance records. Store the full response — status, company_name, address, validated_at, and request_id — with each transaction record to satisfy record-keeping obligations.

For high-risk counterparties, VAT validation is a first-line check within a broader AML workflow, not a substitute for it. It is most valuable as an automated gate that screens out clearly invalid or unregistered entities before they reach manual review queues. A business with an invalid VAT number, a number that returns service_unavailable on repeated attempts, or a number where the name does not match the declared company name should be flagged for enhanced due diligence rather than automatically rejected or approved.

1. **Trigger validation at transaction initiation** — Call GET /api/v1/validate/:country/:vat from your server when a new counterparty relationship or high-value transaction is initiated. Do not rely on prior validation records — always validate in real time at the point of due diligence, since VAT registrations change.
2. **Cross-reference returned company details** — Compare the company_name and address returned by the API against the counterparty's self-declared company name and registered address. A mismatch is a risk signal. Exact string matching is too strict — normalise for formatting and legal suffixes (GmbH, Ltd, SRL), but flag substantial name differences for manual review.
3. **Handle service_unavailable as pending — not cleared** — If the API returns service_unavailable, do not proceed as though the counterparty is validated. Queue the transaction for re-validation within 24 hours and hold any risk decision until VIES recovers. Do not log service_unavailable responses as 'verified' in your compliance records.
4. **Store the full response as a compliance record** — Persist the complete API response — status, company_name, address, request_id, and validated_at — with the transaction record. EU AML regulations require due diligence records to be retained for 5 years. The request_id uniquely identifies the VIES query and can be referenced in audit documentation.
5. **Re-validate for ongoing relationships** — For counterparties with recurring transactions, re-validate VAT status monthly or before high-value transactions. A status change from active to inactive or invalid in an established relationship is a significant risk signal warranting immediate review.

### FAQ

**Does VAT validation satisfy AML due diligence requirements?**
VAT validation is a useful component of due diligence but is not by itself sufficient for AML compliance. It confirms that a business is or was registered with a tax authority, but it does not screen for sanctions, PEPs, or adverse media. Use it as a first-line automated check within a broader AML framework that also includes sanctions screening and, for high-risk counterparties, enhanced due diligence.

**Which industries require VAT validation as part of AML?**
Financial services, payment processors, and fintech companies regulated under the EU's AMLD5/6AMLD directives are the primary users. Additionally, B2B SaaS companies that sell to financial sector clients, legal and accounting firms with corporate clients, and marketplace platforms with high-value seller onboarding increasingly integrate VAT validation into their AML workflows.

**What happens when VIES is unavailable during a required AML check?**
The correct approach is to hold the transaction pending re-validation, not to proceed as cleared or to reject outright. Log the service_unavailable event with the counterparty ID and retry within a few hours. If VIES remains unavailable for an extended period, escalate to manual due diligence for time-sensitive transactions.

---

## Tax ID Verification for KYC (Know Your Customer) Workflows
https://www.taxid.dev/use-cases/kyc-tax-id-verification

Know Your Customer (KYC) for B2B contexts — often called KYB (Know Your Business) — requires confirming the legal existence and registration status of a business entity before onboarding it as a customer, partner, or supplier. A VAT or Tax ID number is one of the most reliable identifiers available: it is issued by a government authority, publicly verifiable against an official registry, and changes only when the business restructures or ceases to trade. The TaxID API provides programmatic access to 31 official registries for this purpose.

The most common KYC use case is B2B SaaS customer onboarding: a business signs up, provides their company name and VAT number, and the platform must verify that the company exists and is currently registered before activating the account for business pricing, extended payment terms, or high-volume usage. The TaxID API call takes under 2 seconds and returns the registry-confirmed company name and address, which can be cross-referenced against the customer's self-declared details.

For regulated industries — financial services, legal, accounting, payment processing — KYB requirements go beyond VAT validation and include beneficial ownership verification, sanctions screening, and adverse media checks. In these contexts, VAT validation is a first-line automated check that screens out clearly invalid entities before they reach the more expensive manual review steps in the KYB pipeline.

The TaxID API is particularly useful for EU-wide KYC because it covers all 27 member states plus UK, Norway, Switzerland, and Australia through a single endpoint. You do not need to integrate with 31 different national registries — the API handles the routing, SOAP-to-JSON translation, and error handling for each country, and returns a consistent response shape regardless of which registry was queried.

1. **Collect the Tax ID at onboarding** — Add a VAT/Tax ID field to your B2B signup or onboarding form. Label it clearly for each market: 'VAT Number' for EU/UK, 'ABN' for Australia, 'MVA Number' for Norway. Use the country selected in the billing address to determine which label and format to display.
2. **Validate in real time via the TaxID API** — On form submission, call GET /api/v1/validate/:country/:vat from your server. Return a loading state while the API call is in progress (VIES calls can take up to 2 seconds). Confirm the returned company_name matches the declared company name before proceeding — a mismatch is a KYC risk signal.
3. **Cross-reference company name and address** — Compare the company_name and address from the API response against the customer's self-declared details. Use fuzzy matching to handle abbreviations and legal suffix variations (Ltd/Limited, GmbH, SRL). A substantial name mismatch should trigger a manual review step, not automatic rejection — the business may have recently rebranded or be filing under a trading name.
4. **Store the KYC record at the account level** — Persist the full API response — vat_number, company_name, address, status, request_id, validated_at — with the customer account record. This is your KYC documentation showing that identity was verified at onboarding. The request_id ties back to the specific VIES query made at that point in time.
5. **Schedule periodic re-validation for active accounts** — For accounts with elevated risk or regulatory exposure, schedule quarterly re-validation of all VAT numbers. For standard accounts, annual re-validation is typically sufficient. Automate this with the TaxID batch endpoint to process your full customer list in a single API call.

### FAQ

**Is VAT validation the same as a KYC check?**
VAT validation confirms that a business is registered in an official government tax registry and is currently active. This is equivalent to a business existence check — one component of KYC/KYB. A complete KYB workflow also includes beneficial ownership identification, sanctions screening, and adverse media review. VAT validation automates the first and most reliable component.

**Can I use the TaxID API for sole traders and partnerships, not just limited companies?**
Yes, with caveats. Sole traders and partnerships can hold VAT registrations in most EU countries and the UK if their taxable turnover exceeds the registration threshold. However, not all VIES member states return company_name for sole traders — some return only the registration status. Australia's ABR covers all entity types including sole traders and trusts.

**What should I do when the API returns a valid status but the company name does not match?**
A name mismatch between the VIES-registered name and the customer's self-declared name is a KYC risk signal, not necessarily a rejection. Common explanations include trading under a different name, a recent acquisition or rebranding, or simply a data entry error. The safest approach is to flag for manual review rather than automatically rejecting — allow the customer to upload a company registration document to resolve the discrepancy.

---

## VAT Number Verification for B2B Vendor and Supplier Onboarding
https://www.taxid.dev/use-cases/vendor-onboarding-vat-check

Vendor and supplier onboarding has a VAT problem that most procurement teams discover during audit rather than during onboarding. When a supplier provides an invalid or expired VAT number, the VAT treatment on their invoices may be wrong from day one. For cross-border EU purchases with reverse-charge treatment, an invalid supplier VAT number means your company cannot claim the input tax deduction on that invoice. For domestic purchases, an invalid VAT number means the supplier may not be entitled to charge VAT — and your company should not have paid it.

The TaxID API validates supplier VAT numbers against 31 official registries in real time. Integrating it into your vendor onboarding workflow creates a programmatic gate that flags invalid, inactive, or unregistered suppliers before their first invoice enters your accounts payable system. The returned company_name and address also serve as a first-pass vendor identity check — comparing the registry-confirmed company details against the vendor's self-declared information catches data entry errors and, in higher-risk cases, supplier fraud.

For larger organisations with ERP systems (SAP, Oracle, NetSuite), VAT validation can be integrated directly into the vendor master data creation workflow. When a new vendor record is created and a VAT number is entered, the ERP calls the TaxID API and stores the validated company name, address, and validation timestamp in the vendor master. This eliminates the manual step where procurement teams screenshot the VIES portal.

Accounts payable teams processing invoices from hundreds or thousands of suppliers face a related challenge: supplier VAT registrations can expire between onboarding and the date of the first invoice, particularly in the EU where businesses occasionally allow their VAT registration to lapse while continuing to operate. A monthly batch re-validation of all active suppliers in your vendor master flags any suppliers whose VAT status has changed before those invoices reach your finance team.

1. **Add VAT validation to the vendor registration form** — When a new vendor submits their details via your supplier portal or ERP onboarding form, trigger a TaxID API call immediately on VAT number submission. Display the validated company name and address to the vendor for confirmation — this catches transposition errors and confirms they have provided the correct number for the legal entity invoicing you.
2. **Gate vendor activation on validation status** — Only activate vendors with status: 'active'. For vendors returning service_unavailable (VIES temporarily down), hold the vendor record as 'pending validation' and auto-retry within 24 hours. For vendors returning invalid or inactive, route the record to manual review with the validation failure reason — do not silently activate.
3. **Store the validation record in the vendor master** — Persist vat_number, company_name, address, validation_status, request_id, and validated_at in the vendor master data record. For ERP systems, map these fields to the appropriate vendor master data fields (or custom fields if the ERP does not natively support them). This provides an auditable record of due diligence at the point of onboarding.
4. **Run monthly batch re-validation of all active vendors** — Schedule a monthly batch job using the TaxID batch endpoint to re-validate all VAT numbers in your vendor master. Flag vendors whose status has changed from active to inactive or invalid for procurement review before their next invoice is processed. This is particularly important for markets like Romania and Bulgaria where supplier VAT deregistrations are more frequent.
5. **Integrate with invoice matching workflow** — For three-way matching systems (PO → receipt → invoice), add a VAT validation check as part of invoice approval. If an invoice arrives from a vendor whose VAT number has become invalid since onboarding, flag the invoice for AP review before payment. The input VAT deduction on that invoice may need to be reversed.

### FAQ

**What is the difference between validating vendor VAT numbers and buyer VAT numbers?**
Buyer VAT validation (for sales invoices) determines whether you can apply zero-rate reverse charge when selling. Vendor VAT validation (for purchase invoices) determines whether the supplier is entitled to charge VAT and whether you can claim input tax deductions on their invoices. Both use the same TaxID API endpoint — the business logic on what to do with the result differs.

**Our ERP creates vendor records in bulk from CSV imports. Can we validate a list of VAT numbers at once?**
Yes. The TaxID batch endpoint accepts up to 500 VAT numbers per request and returns a validation result for each. This is the recommended approach for ERP bulk imports, initial vendor master audits, and monthly re-validation jobs. See the bulk VAT import use case for a CSV-to-API integration pattern.

**How should we handle a supplier who insists their VAT number is correct but VIES returns invalid?**
First, ask the supplier to confirm their VAT number via their government tax portal or registration certificate. It is possible they have transitioned to a different legal entity (e.g., reorganised from a sole trader to a limited company) and are providing an old number. If they cannot provide a valid, VIES-confirmed VAT number, your options are to treat the supply as VAT-inclusive (charge standard VAT rate) and advise the supplier to resolve their registration status, or to escalate for legal review before proceeding with the vendor relationship.

---

## Vue.js VAT Validation: Real-time Tax ID Checks with Composition API
https://www.taxid.dev/use-cases/vue-vat-validation-guide

Vue.js 3's Composition API makes it straightforward to encapsulate VAT validation logic in a reusable composable. The key design principle is the same as any frontend framework: never call the TaxID API directly from the browser. Your API key would be visible in network requests. Instead, build a thin backend endpoint (any server-side framework works — Node.js, PHP, Python, Go) that accepts the VAT number and calls TaxID, then return only the fields your UI needs.

The validation composable manages three reactive states: idle (no input or input too short), loading (API call in flight), and result (one of valid, invalid, or unavailable). Debouncing is essential — without it, every keystroke triggers an API call. A 600ms debounce is the right balance between responsiveness and API quota efficiency.

For the company name confirmation pattern that B2B checkout flows require, bind the composable's company_name and address return values to a read-only confirmation block below the input. Show it only when the state is 'valid'. This gives users the visual confirmation they need before submitting the form: they can see the registered company name and address match what they expect.

Error handling has two distinct cases: format_invalid (user input error — show a format hint immediately) and service_unavailable (VIES is down — show a non-blocking warning and proceed with standard VAT). Never block the user from completing checkout when VIES is unavailable; that creates a hard dependency on an external service with variable uptime.

For server-side rendered applications using Nuxt.js, the same composable works client-side with a Nuxt server route as the backend proxy. The useFetch composable in Nuxt 3 can replace the raw fetch call in the composable, adding SSR support and automatic hydration.

1. **Create the server-side proxy endpoint** — Add a backend route that accepts POST with a vatNumber body, calls GET /api/v1/validate/:country/:vat with your server-side API key, and returns only the fields your frontend needs: valid, status, companyName, address. This keeps the API key server-side and gives you a place to add rate limiting.
2. **Build the useVatValidation composable** — Create a composable that accepts a vatNumber ref, debounces changes by 600ms using watchEffect and a manual setTimeout, calls your proxy endpoint on each debounced change, and returns reactive refs for state ('idle' | 'loading' | 'valid' | 'invalid' | 'unavailable'), companyName, address, and errorMessage.
3. **Build the VatInput component** — Create a Vue component that takes a modelValue prop (for v-model), emits update:modelValue and vatValidated events, uses useVatValidation internally, and renders inline feedback below the input: a spinner when loading, a green confirmation box with company name when valid, a red error message when invalid, and a yellow warning when unavailable.
4. **Handle the vatValidated event in the parent form** — Listen for the vatValidated event from VatInput in your checkout form component. When the event fires with a valid result, store the vatNumber and companyName in your form state. When the input is cleared, reset these to null. Submit both to your backend along with the order data so the VAT validation is recorded alongside the order.
5. **Add Nuxt server route for Nuxt 3 projects** — For Nuxt 3, create server/routes/api/validate-vat.post.ts. Use the event body to get vatNumber, call the TaxID API with useRuntimeConfig().taxidApiKey, and return the filtered result. Register the key in nuxt.config.ts under runtimeConfig.taxidApiKey (not runtimeConfig.public — keeps it server-only).

### FAQ

**Can I use Vue 2 with the Options API instead?**
Yes. Extract the debounce and fetch logic from the composable into a mixin, and use data() for the reactive state instead of ref(). The fetch call and response handling are identical — only the Vue-specific wiring changes. Vue 2 with the @vue/composition-api plugin can also use the composable pattern directly.

**How do I test the composable with Vue Test Utils?**
Mock the fetch call using vi.spyOn(global, 'fetch') in Vitest or jest.spyOn in Jest. Mount a wrapper component that uses the composable, trigger input changes, advance timers past the debounce threshold with vi.runAllTimers(), then assert the reactive state. Avoid making real API calls in tests — they are non-deterministic and consume quota.

**Does this work with Pinia or Vuex for global state?**
Yes. If VAT validation status needs to be accessible from multiple components (for example, a checkout summary and a billing form), move the composable's state into a Pinia store action. The composable stays as a local helper that calls the store action rather than managing its own state.

---

## Next.js VAT API Integration: Server Components & API Routes
https://www.taxid.dev/use-cases/nextjs-vat-api-server-client

Next.js 14's App Router introduces two distinct integration points for VAT validation: API routes for client-side form validation, and React Server Components for server-side data fetching during page renders. Understanding when to use each is important. Client-side form validation — where the user types a VAT number and sees immediate feedback — belongs in a Client Component backed by an API route. Pre-filling a billing page with known company data belongs in a Server Component.

For checkout flows, create a POST API route at app/api/validate-vat/route.ts. This route receives the VAT number from the frontend, calls the TaxID API using the TAXID_API_KEY environment variable (which is only available server-side in Next.js), and returns the filtered result. The frontend never sees the API key. For form state, use useActionState or a standard useState hook with a fetch call — whichever fits your form architecture.

Server Actions (introduced in Next.js 14) offer a third option: define the validation as a server action and call it directly from a Client Component with the 'use server' directive. This eliminates the need for an explicit API route and reduces boilerplate. The downside is that server actions are not cacheable by the browser and add a network round-trip that is less visible than an explicit API route.

For recurring billing flows in Next.js, validation typically happens in a server-side webhook handler rather than in the UI. When Stripe fires an invoice.created webhook, the handler calls the TaxID API to validate the customer's stored VAT number, updates the Stripe customer's tax_exempt status if the validation result has changed, and logs the result for audit compliance. This is the same pattern as the Stripe SaaS guide, implemented in a Next.js Route Handler.

Middleware in Next.js can also play a role: if you have a /dashboard/billing route where users update their VAT number, you can add middleware that re-validates the VAT number on every visit to that route and updates the stored validation status. This keeps your records current without requiring a background job.

1. **Create the API route proxy** — Add app/api/validate-vat/route.ts. Parse the vatNumber from the JSON body, extract the 2-letter country prefix, and call GET https://taxid.dev/api/v1/validate/:country/:vat with the server-side TAXID_API_KEY environment variable. Return only { valid, status, companyName, address } to the client — never the raw response or the request_id (unless you need it for client-side display).
2. **Build the useVatField client hook** — Create a hooks/useVatField.ts file. The hook manages input value, debounced fetch to /api/validate-vat, loading state, and the validation result. Wire it to a controlled input. Expose onValidVat(vatNumber, companyName) callback for the parent form to capture the validated VAT details.
3. **Integrate into a Server Action form (optional)** — For forms that use Server Actions, add a validateVat server action in actions/vat.ts marked with 'use server'. Accept FormData, extract vatNumber, call the TaxID API directly (server-side), and return the result. Invoke with useActionState in the Client Component. This replaces the API route approach and is cleaner for progressive-enhancement forms.
4. **Server Component: pre-fill billing from stored VAT** — In a Server Component (no 'use client' directive), you can fetch VAT validation data directly on render. Read the customer's stored vatNumber from your database, call the TaxID API to get the latest status, and pass the result as props to the billing form Client Component. This pattern is useful for billing settings pages where you want to show the current validation status without a client-side API call on load.
5. **Webhook handler for subscription re-validation** — Add app/api/webhooks/stripe/route.ts. On invoice.upcoming events, read the Stripe customer's vat_number metadata, call the TaxID API, and if the status has changed (e.g., went from active to inactive), update the customer's tax_exempt flag in Stripe and notify your finance team via email or Slack. Log every validation with request_id for audit.

### FAQ

**Should I use an API route or a Server Action for VAT validation?**
Use an API route if you need the validation endpoint to be callable from outside Next.js (e.g., from a mobile app or external service). Use a Server Action if the validation is only ever called from within your Next.js application — it reduces boilerplate. For checkout flows, either approach works; the API route is more explicit and easier to test with curl.

**How do I handle TAXID_API_KEY in Next.js so it's never exposed to the browser?**
Define it in .env.local as TAXID_API_KEY=vat_xxxx (without the NEXT_PUBLIC_ prefix). Next.js only exposes environment variables prefixed with NEXT_PUBLIC_ to the browser. Any variable without that prefix is only available in server-side code — API routes, Server Components, Server Actions, and middleware.

**Can I use Edge Runtime for the API route?**
Yes. The TaxID API is a standard REST endpoint that works with the Fetch API available in Edge Runtime. Add export const runtime = 'edge' to your validate-vat/route.ts. Edge Runtime is faster globally but does not support Node.js-specific APIs — since the validation only needs fetch and basic string manipulation, Edge is fully compatible.

---

## VAT API Rate Limiting & Caching: Production Best Practices
https://www.taxid.dev/use-cases/vat-api-rate-limiting-caching

Every TaxID plan has a monthly validation quota. Burning through quota faster than necessary is expensive and avoidable. The single most effective optimisation is caching: a VAT number that returns 'active' today will almost certainly return 'active' again tomorrow — VIES itself only updates in real time, but registrations rarely change day-to-day. A 23-hour cache window (matching VIES's own cache TTL) eliminates the vast majority of redundant API calls in any application where the same customers validate repeatedly.

For single-instance applications, an in-memory Map or a library like node-lru-cache is sufficient. The limitation is that the cache is lost on process restart and is not shared across multiple instances in a horizontally scaled deployment. For production applications running on multiple servers or in serverless environments, use a shared Redis cache with a TTL matching the 23-hour window.

Request deduplication is the second key optimisation. If your application can generate concurrent validation requests for the same VAT number (for example, a user who submits the checkout form twice in quick succession, or a batch job that processes the same vendor multiple times), add a deduplication layer that detects in-flight requests for the same key and waits for the first result rather than making a parallel duplicate API call.

Rate limit handling requires defensive coding for 429 responses. When your application receives a 429, back off exponentially — wait 1 second, then 2, then 4 — before retrying. Track your monthly usage by counting validation calls in your own database. The TaxID API does not expose a usage endpoint, so your only reliable view of quota consumption is what your application has tracked.

For serverless environments (Vercel Edge, Cloudflare Workers, AWS Lambda), in-memory caching is unreliable because each function invocation may run in a separate process. Always use an external cache store in serverless contexts. Upstash Redis is a good choice — it has a REST API that works from any serverless runtime including Edge functions that cannot use native TCP connections.

1. **Add in-memory caching for single-instance apps** — Create a Map-based cache in your VatValidator service class. On each validation call, check the cache for a recent result (under 23 hours old) before calling the API. Only cache 'active' and 'inactive' results — do not cache 'service_unavailable', as the registry may recover before your 23-hour TTL expires.
2. **Upgrade to Redis for multi-instance deployments** — Replace the in-memory Map with an Upstash Redis client (REST API works in serverless). Use setex with a TTL of 82800 seconds (23 hours). Use the normalised VAT number (uppercase, spaces stripped) as the cache key prefixed with 'vat:'. The TaxID API marks cached responses with cached: true — combine your Redis cache hit with the API's own caching for maximum efficiency.
3. **Implement request deduplication** — Add a pendingRequests Map that stores in-flight Promise<VatResult> objects keyed by the normalised VAT number. Before making an API call, check if a request is already in flight for the same key. If so, return the existing Promise instead of making a new API call. Remove the key from the map when the Promise resolves (in both success and error cases).
4. **Track quota usage** — Count every outgoing TaxID API call (not cache hits) in a database counter. Use a monthly bucket key (e.g., 'vat_calls:2026-06') and increment it with each real API call. Alert your team when you reach 80% of your plan limit. This gives you time to upgrade or investigate unexpected usage spikes before hitting the hard limit.
5. **Handle 429 with exponential backoff** — Wrap your API call in a retry loop that detects HTTP 429 responses and backs off exponentially: wait 1000ms, then 2000ms, then 4000ms, for a maximum of 3 retries. Log every 429 with the affected VAT number, current timestamp, and retry attempt number. If all retries exhaust, return service_unavailable — never throw an unhandled error to the caller for rate limit responses.

### FAQ

**How long should I cache VAT validation results?**
23 hours is the recommended maximum — this matches VIES's own internal cache window. VIES only guarantees real-time status at the point of the query; caching for 23 hours is considered compliant for EU VAT purposes. For high-risk transactions (high-value invoices or new customers), re-validate immediately rather than relying on cache.

**Should I cache 'service_unavailable' responses?**
No. A service_unavailable response means the registry is temporarily offline — caching it would prevent you from getting the real status once the registry recovers. Only cache 'active' and 'inactive' results, which represent definitive answers from the national registry.

**What happens when I hit the 429 rate limit?**
The TaxID API returns HTTP 429 with a Retry-After header indicating when the rate limit window resets. Implement exponential backoff as described in the steps above. For batch jobs, spread requests over time using a queue rather than parallel execution — this prevents spikes that trigger rate limiting.

---

# Platform integrations

## Stripe
https://www.taxid.dev/vat-api/integrations/stripe

Use the TaxID API to validate EU VAT numbers inside Stripe Checkout before applying zero-rate treatment. Avoid VAT liability on unverified B2B customers and maintain an auditable validation record on every Stripe invoice.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup — no credit card required. The free plan includes 100 validations per month. Your API key is available immediately after email confirmation.
2. **Add a VAT number field to your Stripe checkout form** — Add a text input for EU VAT numbers to your Stripe Payment Element or custom checkout form. Label it clearly as optional for consumers and required for B2B reverse-charge treatment. Place it in the billing-address section.
3. **Validate server-side before charging** — On form submission, call GET /api/v1/validate/:country/:vat from your server (never from the browser — this protects your API key). Check that status === 'active' before proceeding. If status is 'invalid', return a form error. If status is 'service_unavailable', log a warning and fall back to charging standard VAT rather than silently exempting.
4. **Apply zero-rate on the Stripe customer** — When the API returns status: 'active', call stripe.customers.update({ tax_exempt: 'reverse' }) to enable reverse-charge treatment on the Stripe customer object. Also store the validated VAT number, company_name, and company_address from the TaxID response in Stripe customer metadata for audit purposes.
5. **Re-validate on a schedule for subscriptions** — For subscription businesses, schedule a background job that re-validates all customers with tax_exempt: 'reverse' at least monthly. VAT registrations can be cancelled between billing cycles, and a tax audit will ask for proof that the number was valid at the time of each invoice — not just at signup.

### FAQ

**Does Stripe Tax validate EU VAT numbers automatically?**
No. Stripe Tax calculates and collects VAT based on the customer's location and the tax_exempt flag, but it does not call VIES or any registry to verify that a VAT number is real or currently registered. You must validate independently — for example using TaxID — before setting tax_exempt: 'reverse' on the Stripe customer.

**What should I do when TaxID returns service_unavailable?**
Never silently zero-rate an unverified number. The safest fallback is to charge standard local VAT and issue a credit note once VIES recovers and confirms the number is valid. Log every service_unavailable response with the customer ID and timestamp so you can follow up.

**Can I call the TaxID API from the browser inside Stripe.js?**
No. Always call the TaxID API from your server-side code, never from client-side JavaScript. A browser request would expose your API key to anyone who inspects network traffic. Validate server-side and return only the result (valid: true/false) to the frontend.

**How often should I re-validate EU VAT numbers for Stripe subscriptions?**
Validate at every checkout for one-off transactions. For subscription customers, run a background job that re-checks all customers with tax_exempt: 'reverse' at least monthly. VAT registrations can be cancelled between billing cycles.

**Which EU countries does TaxID support for Stripe integration?**
TaxID validates VAT numbers for all 27 EU member states via VIES, plus UK (HMRC), Norway (Brønnøysund Register), and Australia (ABN Lookup). All 27 EU countries are eligible for Stripe reverse-charge treatment under EU VAT Directive 2006/112/EC.

---

## Shopify
https://www.taxid.dev/vat-api/integrations/shopify

Add EU VAT number validation to your Shopify B2B storefront. Automatically verify EU business customers against VIES before applying tax exemptions on cross-border orders, so you never wrongly zero-rate an unregistered buyer.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup. No credit card required. The free plan includes 100 validations per month, which is enough for early-stage B2B storefronts.
2. **Build a Shopify app or custom storefront field for VAT input** — Create a Shopify app (using Remix or the Shopify CLI) with a custom checkout UI extension that adds a VAT number field to the billing form. Alternatively, use a headless storefront with a server action that calls the TaxID API before the order is confirmed.
3. **Validate via a server-side app route** — In your Shopify Remix app route, call GET /api/v1/validate/:country/:vat from the server using the TAXID_API_KEY environment variable. Check that status === 'active' before applying any tax exemption. Never expose the API key in client-side JavaScript.
4. **Apply Shopify tax exemption for verified businesses** — When the TaxID API returns valid: true, update the Shopify customer object to set tax_exempt: true via the Shopify Admin API or GraphQL Storefront API. This prevents Shopify from calculating tax on future orders for that customer.
5. **Store validation result in Shopify customer metafields** — Persist the validated VAT number, company_name, and company_address from the TaxID response in Shopify customer metafields. This gives you an auditable record showing the VAT was valid at the time of the transaction, which is required under EU record-keeping obligations.

### FAQ

**Does Shopify validate EU VAT numbers automatically?**
No. Shopify does not call VIES or any other registry to verify that a VAT number is real or currently active. You must integrate an independent validation API — such as TaxID — to verify VAT numbers before applying tax exemptions on your Shopify storefront.

**Can I use the TaxID API with Shopify Plus?**
Yes. Shopify Plus gives you access to checkout customizations via the Checkout Extensibility UI, which allows you to add custom fields and server-side validation logic. You can call the TaxID API from your app backend during checkout to validate EU VAT numbers before the order is placed.

**What happens if VIES is temporarily unavailable?**
If the TaxID API returns status: 'service_unavailable', do not silently exempt the customer. The safest approach is to allow the order through with standard tax and send the customer a follow-up email asking them to provide their VAT number again once VIES recovers. Log the event with the customer ID and order ID.

**Which countries can I validate for my Shopify B2B store?**
TaxID validates VAT numbers for all 27 EU member states via VIES, plus UK (HMRC), Norway (Brønnøysund Register), and Australia (ABN Lookup). This covers the most common B2B export markets for Shopify merchants.

---

## Node.js
https://www.taxid.dev/vat-api/integrations/node

Validate EU VAT numbers from any Node.js backend — Express, Fastify, Next.js API routes, or plain scripts — using Node 18+ native fetch or axios. Returns company name, address, and registration status from VIES in under 100ms.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup. No credit card required. Store your API key as an environment variable (TAXID_API_KEY) — never hardcode it in source files or commit it to version control.
2. **Make a GET request using native fetch (Node 18+) or axios** — Call GET /api/v1/validate/:country/:vat with your API key in the Authorization header. Node 18 and above include native fetch — no extra dependencies needed. For older Node versions, use axios or node-fetch.
3. **Parse the response and check valid and status fields** — The API returns a JSON object with valid (boolean), status (string), company_name, and company_address. Check valid === true for a passing EU business. The status field gives more detail: 'active', 'invalid', 'not_found', or 'service_unavailable'.
4. **Handle VIES service_unavailable gracefully** — VIES has occasional downtime. When status === 'service_unavailable', do not reject the customer — instead, log the event and apply a conservative fallback (charge standard VAT and follow up). The TaxID API caches results for 24h (valid) and 1h (invalid) to reduce upstream dependency.

### FAQ

**Do I need any npm packages to call the TaxID API from Node.js?**
No. Node.js 18 and above include the native Fetch API, so you can call the TaxID REST API with a single await fetch() call. For older Node versions (14, 16), use the axios or node-fetch package.

**Can I use the TaxID API in a Next.js API route or server action?**
Yes. Call the TaxID API from any Next.js server-side context: API routes (pages/api/), Route Handlers (app/api/), or Server Actions. Never call it from the client side — that would expose your API key.

**How do I validate multiple VAT numbers in a single Node.js request?**
Use the batch endpoint: POST /api/v1/validate with a JSON body containing a 'numbers' array (up to 25 entries). Each entry specifies a country code and VAT number. Results are returned in the same order, processed in parallel — ideal for bulk imports or nightly reconciliation jobs.

**What is the response time for the TaxID API from Node.js?**
Cached results respond in under 10ms. Uncached requests that hit VIES typically complete in 100–400ms. The response includes a 'cached' boolean so you can see whether the result came from cache. Valid numbers are cached for 24 hours, invalid numbers for 1 hour.

---

## Python
https://www.taxid.dev/vat-api/integrations/python

Validate EU VAT numbers from any Python backend — Django, Flask, FastAPI, or scripts — with a single HTTP call using requests or httpx. Returns live VIES registration status, company name, and address in under 100ms.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup. No credit card required. Store your API key as an environment variable (TAXID_API_KEY) using python-dotenv or your framework's secrets management — never hardcode it.
2. **Call the API with requests or httpx** — Use the requests library for synchronous code (Django, Flask) or httpx for async code (FastAPI, Starlette). Both libraries let you pass the Authorization header and parse the JSON response in two lines.
3. **Parse the JSON response** — The API returns a dict with valid (bool), status (str), company_name, and company_address. Check data['valid'] is True for an active EU business. The status field can be 'active', 'invalid', 'not_found', or 'service_unavailable'.
4. **Handle service_unavailable separately from invalid** — VIES has occasional downtime. Raise a distinct exception for status 'service_unavailable' so your code handles it differently from a genuinely invalid VAT number. A good pattern: log the event, charge standard VAT, and queue the customer for re-validation once VIES recovers.

### FAQ

**Which Python library should I use to call the TaxID API?**
Use requests for synchronous Django or Flask apps. Use httpx for async FastAPI or Starlette apps. Both are straightforward — import the library, pass the Authorization header, and call resp.json(). No special SDK needed.

**Can I use the TaxID API in a Celery background task?**
Yes. Celery tasks run synchronously (unless you use gevent/eventlet), so use the requests library. This is a good pattern for subscription re-validation: queue a Celery task for each customer with tax_exempt status and re-validate their VAT number monthly.

**How do I validate multiple EU VAT numbers in one Python request?**
Use the batch endpoint: POST /api/v1/validate with a JSON body containing a 'numbers' list of up to 25 dicts, each with 'country' and 'vat' keys. Results are returned in the same order, processed in parallel on the TaxID side.

**How do I set a request timeout for the TaxID API in Python?**
Pass timeout=10 to requests.get() or httpx.get(). This gives the API up to 10 seconds to respond, which covers VIES latency even during slow periods. Always set a timeout — without one, a VIES timeout will hang your worker indefinitely.

---

## PHP
https://www.taxid.dev/vat-api/integrations/php

Validate EU VAT numbers from PHP backends using cURL or Guzzle. Works with Laravel, Symfony, WordPress, and plain PHP. Returns live company data from VIES in a single REST call — no SOAP or XML required.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup. Store your API key in your .env file as TAXID_API_KEY and load it with getenv() or your framework's config (config('services.taxid.key') in Laravel, $this->getParameter() in Symfony).
2. **Make a GET request with cURL or Guzzle** — Use curl_init() and curl_exec() for plain PHP or WordPress, or the GuzzleHttp\Client for Laravel and Symfony. Both approaches send the Authorization header with your API key and parse the JSON response.
3. **Parse the JSON response** — Call json_decode($body, true) to get an associative array. Check $data['valid'] === true for an active EU business. The $data['status'] field can be 'active', 'invalid', 'not_found', or 'service_unavailable'.
4. **Handle errors and service downtime** — Throw a distinct exception for status 'service_unavailable' so you can handle it separately from a genuinely invalid VAT number. A good fallback: charge standard VAT, log the event, and queue the customer for re-validation once VIES recovers.

### FAQ

**Do I need a SOAP library to validate EU VAT numbers from PHP?**
No. TaxID exposes a simple REST/JSON API — no SOAP, no XML, no PHP SoapClient required. A single curl_exec() or Guzzle request is all you need. This avoids the complexity and maintenance burden of working with the raw VIES SOAP endpoint directly.

**How do I call the TaxID API from Laravel?**
Use Laravel's built-in Http facade: Http::withToken(config('services.taxid.key'))->get('/api/v1/validate/DE/DE123456789')->json(). This wraps Guzzle under the hood and handles JSON parsing, timeout configuration, and retry logic cleanly.

**Can I use the TaxID API in WordPress via wp_remote_get?**
Yes. WordPress's wp_remote_get() function handles cURL internally and works with any REST API. Pass the Authorization header in the 'headers' array option. Use is_wp_error() to handle network failures gracefully rather than crashing.

**How do I validate EU VAT numbers in batch from PHP?**
Use the batch endpoint: POST /api/v1/validate with Content-Type: application/json and a body containing a 'numbers' array of up to 25 objects, each with 'country' and 'vat'. Process the response array 1-to-1 with your input for bulk customer onboarding or reconciliation.

---

## WooCommerce
https://www.taxid.dev/vat-api/integrations/woocommerce

Add EU VAT number validation to WooCommerce checkout. Verify EU business customers against VIES before applying zero-rate tax exemptions on cross-border B2B orders, using WooCommerce hooks and the TaxID REST API.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup. Define the API key as a constant in wp-config.php (define('TAXID_API_KEY', 'your_key')) or load it from a secure environment variable. Never hardcode it in theme files or commit it to version control.
2. **Add a VAT number field to WooCommerce checkout** — Use the woocommerce_after_billing_form action hook to add a text field for the EU VAT number. Label it clearly as optional for consumers and required for B2B customers who want zero-rated invoices.
3. **Validate via the TaxID API on order submission** — Hook into woocommerce_checkout_process to call wp_remote_get() with the TaxID API endpoint and your Authorization header. Extract the country code from the first two characters of the VAT number. If status is 'invalid', call wc_add_notice() with an error message. If status is 'service_unavailable', allow through and log the event for manual follow-up.
4. **Apply WooCommerce zero-rate tax class for valid EU businesses** — When the API returns valid: true, apply WooCommerce's built-in 'Zero Rate' tax class to the order. You can do this by hooking into woocommerce_cart_tax_totals or by updating the customer's tax_exempt status programmatically via the WooCommerce REST API.
5. **Store VAT number and validation result in order metadata** — In the woocommerce_checkout_create_order hook, call $order->update_meta_data() to persist the VAT number and validation timestamp. This creates an auditable record for each order, which is required under EU invoice record-keeping obligations.

### FAQ

**Is there a WooCommerce plugin that does EU VAT validation?**
Several plugins exist, but most use the raw VIES SOAP endpoint directly, which has no SLA and frequent downtime. The TaxID API wraps VIES with caching, rate limiting, and a stable REST interface — giving you more reliable validation with a simple HTTP call from your custom plugin or functions.php.

**How do I zero-rate an order in WooCommerce for a validated EU business?**
Apply WooCommerce's built-in 'Zero Rate' tax class to the customer or the cart when the VAT number validates as 'active'. You can update the customer's WooCommerce tax_exempt status, or override the tax totals in the woocommerce_cart_tax_totals filter for the current session.

**What if VIES is down during WooCommerce checkout?**
If the TaxID API returns service_unavailable, do not block the order or silently zero-rate it. The safest approach is to allow the order through with standard VAT rates, log the event, and send the customer a follow-up email asking them to provide their VAT number again. The TaxID API caches results for 24 hours, so most valid numbers will already be cached.

**How do I validate UK VAT numbers in WooCommerce?**
UK VAT numbers start with 'GB' and are validated via the HMRC API (not VIES). The TaxID API handles UK validation transparently — just pass the GB-prefixed number to the same endpoint (/api/v1/validate/GB/GB123456789) and it routes to HMRC automatically.

---

## Go
https://www.taxid.dev/vat-api/integrations/go

Validate EU VAT numbers from Go backends using only the standard library. Returns VIES registration status, company name, and address in a single REST call — no SOAP, no XML, no external packages required.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup. Store your API key as an environment variable (export TAXID_API_KEY=your_key) and read it with os.Getenv(). Never hardcode credentials in source files.
2. **Make a GET request with net/http** — Create an http.Request with http.NewRequest("GET", url, nil), set the Authorization header, and call http.DefaultClient.Do(req). This uses only the Go standard library — no external packages or go get required.
3. **Decode the JSON response** — Use json.NewDecoder(resp.Body).Decode(&result) to parse the response into a map[string]any or a typed struct. Check result["valid"] == true for an active EU business, and result["status"] for the detailed outcome ('active', 'invalid', 'not_found', 'service_unavailable').
4. **Handle service_unavailable and implement retries** — VIES has occasional downtime. When status is 'service_unavailable', return a distinct error type from your validate function so callers can handle it differently from an invalid VAT number. Implement exponential backoff with a maximum of 3 retries for transient errors.

### FAQ

**Do I need any Go packages to call the TaxID API?**
No. The TaxID API is a plain REST/JSON endpoint — Go's standard library (net/http + encoding/json) is all you need. This avoids adding external dependencies to your go.mod for a simple HTTP call.

**How do I create a typed struct for the TaxID API response in Go?**
Define a struct with json tags matching the response fields: type VATResult struct { Valid bool `json:"valid"`; Status string `json:"status"`; CompanyName *string `json:"company_name"`; CompanyAddress *string `json:"company_address"` }. Use a pointer for nullable fields so you can distinguish null from empty string.

**How do I validate multiple EU VAT numbers in Go?**
Use the batch endpoint: POST /api/v1/validate with Content-Type: application/json and a body like {"numbers": [{"country": "DE", "vat": "DE123456789"}]}. Alternatively, fan out multiple concurrent GET requests using goroutines and collect results via a channel — the single-validation endpoint is designed for concurrent use.

**Can I use the TaxID API inside a gRPC service?**
Yes. Call the TaxID REST API from your gRPC service handler using net/http. Since gRPC handlers run in goroutines, use a shared http.Client with connection pooling (set MaxIdleConnsPerHost) to avoid opening a new TCP connection per validation request.

---

## Laravel
https://www.taxid.dev/vat-api/integrations/laravel

Add EU VAT validation to your Laravel application with the TaxID API. Wire it into a Form Request validation rule, a dedicated service class, or a queued job so a business customer's VAT number is checked against VIES before you apply reverse-charge treatment or persist it to your database.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup — no credit card required, 100 validations/month on the free plan. Add the key to your .env file as TAXID_API_KEY and reference it through config/services.php rather than reading env() directly, so it works under config:cache in production.
2. **Create a VatNumber service** — Add an App\Services\VatValidator class that wraps Laravel's Http client (Illuminate\Support\Facades\Http). Call Http::withToken(config('services.taxid.key'))->get("https://www.taxid.dev/api/v1/validate/{$country}/{$vat}") and return the decoded JSON. Set a timeout of 10 seconds so a slow VIES lookup never hangs a request.
3. **Enforce it with a Form Request rule** — Generate a custom rule with php artisan make:rule ValidVatNumber and call the service inside passes(). Attach the rule to your checkout or onboarding Form Request so an invalid number is rejected with a validation error before it ever reaches your controller. Treat a status of 'service_unavailable' as a soft-pass, not a failure.
4. **Store the validated result** — When status === 'active', persist the returned company_name, company_address, and a validated_at timestamp alongside the VAT number on your Customer model. This gives you the audit trail a tax authority will ask for, and lets you skip re-validation for numbers checked within the cache window.
5. **Re-validate subscriptions with a scheduled command** — For recurring billing, add an Artisan command to app/Console/Kernel.php scheduled monthly that re-checks every customer flagged for reverse-charge. VAT registrations can be cancelled between billing cycles, and you need proof the number was valid at the time of each invoice — dispatch the checks onto a queue to avoid rate limits.

### FAQ

**How do I validate a VAT number inside a Laravel Form Request?**
Create a custom rule class with php artisan make:rule ValidVatNumber, inject your VatValidator service, and call the TaxID API inside the passes() method. Return true only when the response status is 'active'. Reference the rule in the rules() array of your Form Request so Laravel rejects invalid numbers automatically and returns a 422 with your message.

**Should I call the TaxID API from a Livewire or Blade component directly?**
No — always validate from server-side code (a service class, Form Request, or job), never from Alpine/JavaScript in the browser, because that would expose your API key. In Livewire, call the service from an action method on the server and bind only the boolean result back to the view.

**How should I handle a VIES timeout in a Laravel queue job?**
The TaxID API returns status 'service_unavailable' when VIES is temporarily down. In a queued job, do not mark the number invalid — instead release the job back onto the queue with a delay ($this->release(300)) so it retries after five minutes. Configure tries and backoff on the job class to cap the retries.

**Which EU countries can I validate from Laravel?**
All 27 EU member states via VIES, plus the UK (HMRC), Norway (Brønnøysund), Switzerland, and Australia (ABN). The endpoint and your Laravel service code are identical for every country — you pass the two-letter country code and the number, and the API routes to the correct authority.

---

## Django
https://www.taxid.dev/vat-api/integrations/django

Validate EU VAT numbers in your Django project with the TaxID API. Drop it into a model field validator, a Django REST Framework serializer, or a Celery task so every VAT number is verified against VIES before a B2B order is zero-rated or a customer record is committed to the database.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup for a free key with 100 validations/month. Read it from the environment with os.environ or django-environ and expose it through settings.py as TAXID_API_KEY — never hard-code it or commit it to your repository.
2. **Write a validation helper** — Add a small function in a services.py module that uses requests (or httpx for async views) to call https://www.taxid.dev/api/v1/validate/{country}/{vat} with an Authorization: Bearer header and a 10-second timeout. Return the parsed JSON so the rest of your code works with a plain dict.
3. **Enforce it in a serializer or form** — In Django REST Framework, add a validate_vat_number() method to your serializer that calls the helper and raises serializers.ValidationError when status is 'invalid'. For classic Django forms, do the same in clean_vat_number(). This keeps validation at the boundary so bad numbers never reach your view logic.
4. **Persist the company details** — When status == 'active', save the returned company_name, company_address, and a validated_at datetime on your Customer or Company model. Storing the snapshot means you can prove the number was valid at capture time and avoid a redundant VIES call on the next request within the cache window.
5. **Re-validate with a Celery beat task** — Schedule a periodic Celery task that re-validates all customers marked for reverse-charge at least monthly. A registration valid at signup can be revoked later, and tax audits expect evidence for each invoice date. Handle 'service_unavailable' by retrying the task with self.retry(countdown=300) rather than flagging the number invalid.

### FAQ

**How do I validate a VAT number in a Django REST Framework serializer?**
Add a validate_<fieldname>() method — e.g. validate_vat_number(self, value) — that calls your TaxID helper and raises rest_framework.serializers.ValidationError if the response status is not 'active'. DRF runs it automatically during is_valid(), so an invalid number produces a clean 400 response with your error message.

**Can I validate VAT numbers in an async Django view?**
Yes. Use httpx.AsyncClient instead of requests and await the call inside an async def view. The TaxID endpoint is a simple GET, so it fits naturally into async views and ASGI deployments without blocking the event loop. Keep the timeout at around 10 seconds.

**What should my Celery task do when TaxID returns service_unavailable?**
Treat it as transient, not as an invalid number. Call self.retry(countdown=300, max_retries=5) to re-run the task after five minutes. Never overwrite a previously-valid flag on a 'service_unavailable' response, or a temporary VIES outage would incorrectly strip reverse-charge status from real businesses.

**Does the django-localflavor VAT field validate against VIES?**
No. Packages like django-localflavor only check that a VAT number matches the expected format for a country — they never confirm the number is actually registered. The TaxID API performs the live VIES lookup, so combine format checking with a real registration check before applying any tax exemption.

---

## Java (Spring Boot)
https://www.taxid.dev/vat-api/integrations/java

Validate EU VAT numbers from Java and Spring Boot with the TaxID API using the JDK's built-in HttpClient — no heavy SOAP stubs required. Add it to a @Service bean or a Bean Validation constraint so VAT numbers are checked against VIES before your application applies reverse-charge treatment or persists a customer.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup for a free key with 100 validations/month. Inject it through Spring's @Value("${taxid.api-key}") from application.yml, and source the value from an environment variable so it never lands in your JAR or version control.
2. **Build a VatValidationService bean** — Create a @Service that holds a single reusable java.net.http.HttpClient. Build a GET request to https://www.taxid.dev/api/v1/validate/{country}/{number} with an Authorization: Bearer header, send it, and deserialize the JSON body with Jackson into a small record. Reuse one HttpClient instance rather than creating one per call.
3. **Expose it as a Bean Validation constraint** — Define a @ValidVat annotation backed by a ConstraintValidator that calls the service. Annotate the vatNumber field on your request DTO so Spring MVC rejects invalid numbers with a 400 before they reach your controller. Return true on a 'service_unavailable' status so a VIES outage does not block legitimate submissions.
4. **Persist the validation snapshot** — When status equals 'active', store companyName, companyAddress, and a validatedAt Instant on your Customer JPA entity next to the VAT number. This provides the audit evidence tax authorities require and lets you skip a redundant lookup for numbers already validated inside the cache window.
5. **Schedule re-validation with @Scheduled** — Add a @Scheduled method that re-validates every customer flagged for reverse-charge on a monthly cadence. VAT registrations can lapse between invoices, so periodic re-checks keep your tax treatment defensible. Run the batch on a bounded thread pool and back off on 'service_unavailable' rather than marking numbers invalid.

### FAQ

**Do I need the VIES SOAP WSDL to validate VAT numbers in Java?**
No. The classic approach of generating JAX-WS stubs from the VIES WSDL is brittle and hard to maintain. The TaxID API wraps VIES behind a plain REST endpoint, so you call it with the JDK's HttpClient and parse JSON — no SOAP, no wsimport, no XML marshalling.

**How do I turn VAT validation into a Bean Validation annotation?**
Create a custom @ValidVat annotation and a ConstraintValidator<ValidVat, String> whose isValid() method calls your validation service. Place @ValidVat on the DTO field, and Spring's @Valid handling will trigger it automatically, returning a MethodArgumentNotValidException (HTTP 400) for invalid numbers.

**Should I reuse a single HttpClient across requests?**
Yes. java.net.http.HttpClient is thread-safe and manages its own connection pool, so build one instance as a Spring singleton bean and inject it everywhere. Creating a new client per validation wastes resources and can exhaust file descriptors under load.

**How do I handle a temporary VIES outage in Spring?**
The API returns status 'service_unavailable' when a national registry is down. In your validator, do not fail closed — allow the submission through, log the event, and enqueue a background re-check. Configure Resilience4j or a simple @Retryable if you want automatic retries with backoff.

---

## Ruby on Rails
https://www.taxid.dev/vat-api/integrations/rails

Validate EU VAT numbers in Ruby on Rails with the TaxID API. Wrap it in a service object or a custom ActiveModel validator so a customer's VAT number is checked against VIES before an order is zero-rated — with a background re-check via Active Job and Sidekiq for subscriptions.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup for a free key with 100 validations/month. Store it with Rails encrypted credentials (bin/rails credentials:edit) or an ENV var, and read it via Rails.application.credentials.taxid_api_key so it never appears in your codebase.
2. **Write a VatValidator service object** — Add app/services/vat_validator.rb with a class method that uses Net::HTTP (or Faraday if you already depend on it) to GET https://www.taxid.dev/api/v1/validate/#{country}/#{number} with an Authorization bearer header. Parse the JSON and return a small result struct so callers work with valid?, status, and company_name.
3. **Enforce it with a custom validator** — Create a VatNumberValidator < ActiveModel::EachValidator that calls the service and adds an error when status is 'invalid'. Declare validates :vat_number, vat_number: true on your model so an invalid number fails save and surfaces in the form. Treat 'service_unavailable' as valid so a VIES outage does not block sign-ups.
4. **Store the validated company data** — On a status of 'active', save company_name, company_address, and validated_at to the record. Keeping the snapshot gives you audit-ready proof and lets you skip re-validation for numbers already checked within the cache window, keeping form submissions fast.
5. **Re-validate with Active Job and Sidekiq** — Schedule a recurring job (sidekiq-cron or solid_queue) that re-validates customers flagged for reverse-charge monthly. Registrations can be cancelled between invoices, and audits expect per-invoice evidence. On 'service_unavailable', re-enqueue the job with a delay instead of clearing the reverse-charge flag.

### FAQ

**How do I add a custom VAT validator in Rails?**
Subclass ActiveModel::EachValidator (e.g. VatNumberValidator) and implement validate_each(record, attribute, value) to call your TaxID service, adding record.errors when the number is not active. Then use validates :vat_number, vat_number: true on the model. Rails runs it during save so invalid numbers never persist.

**Should validation run in the request or a background job?**
Validate synchronously at the point of capture — checkout or onboarding — so the customer gets immediate feedback on a wrong number. Use Active Job only for the periodic re-validation of already-stored numbers, where latency does not matter and you want to avoid blocking a web request.

**How do I keep my API key out of the Rails codebase?**
Use Rails encrypted credentials via bin/rails credentials:edit and read the key with Rails.application.credentials.taxid_api_key, or fall back to an ENV var loaded through dotenv-rails in development. Never commit the key or the master.key file to version control.

**What happens when VIES is temporarily unavailable?**
The API returns status 'service_unavailable'. In your validator, allow the record to save and flag it for a later re-check rather than rejecting it, so a transient registry outage doesn't block a real business from signing up. Your Sidekiq re-validation job will confirm the number once VIES recovers.

---

## .NET / C#
https://www.taxid.dev/vat-api/integrations/dotnet

Validate EU VAT numbers in .NET and C# with the TaxID API using HttpClient and IHttpClientFactory. Add it to an ASP.NET Core service or a minimal-API endpoint so VAT numbers are verified against VIES before your application applies reverse-charge treatment or writes a customer to the database.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup for a free key with 100 validations/month. Store it in user-secrets during development (dotnet user-secrets set) and in your host's configuration or Key Vault in production, then bind it through IConfiguration — never in appsettings.json committed to source control.
2. **Register a typed HttpClient** — In Program.cs, call builder.Services.AddHttpClient<VatValidationClient>() so IHttpClientFactory manages the handler lifetime and connection pooling. Set the Authorization bearer header and a 10-second timeout on the typed client. This avoids the socket-exhaustion problems of newing up HttpClient per request.
3. **Deserialize the response** — Define a VatResult record with [JsonPropertyName] attributes for valid, status, company_name, and company_address, then read the endpoint with GetFromJsonAsync<VatResult>. Check that Status == "active" before applying any tax exemption; branch on "service_unavailable" separately from "invalid".
4. **Validate at the API boundary** — Call the client from a minimal-API endpoint or an MVC controller action during checkout or onboarding, returning a 400 ProblemDetails when the number is invalid. On success, persist company_name, company_address, and a ValidatedAt timestamp on your EF Core entity for the audit trail.
5. **Re-validate with a hosted service** — Add a BackgroundService (IHostedService) or a Hangfire recurring job that re-validates customers flagged for reverse-charge monthly. Registrations can lapse between billing cycles. On a 'service_unavailable' response, skip and retry later instead of clearing the exemption flag.

### FAQ

**Why should I use IHttpClientFactory for VAT validation in .NET?**
Instantiating HttpClient per request can exhaust available sockets under load, while a single static instance won't honor DNS changes. IHttpClientFactory solves both by pooling and rotating handlers. Register a typed client with AddHttpClient<VatValidationClient>() and inject it wherever you validate.

**How do I deserialize the TaxID response in C#?**
Create a record with System.Text.Json [JsonPropertyName] attributes mapping to valid, status, company_name, and company_address, then call GetFromJsonAsync<VatResult>() on the HttpClient. The snake_case JSON maps cleanly to your PascalCase properties via the attributes.

**Where should I store the API key in an ASP.NET Core app?**
Use the Secret Manager (dotnet user-secrets) in development and Azure Key Vault, AWS Secrets Manager, or environment variables in production, bound through IConfiguration. Keep the key out of appsettings.json and any file tracked in git.

**How do I distinguish an invalid number from a VIES outage?**
Branch on the status field: 'invalid' means the number is genuinely not registered and you should charge local VAT, while 'service_unavailable' means the registry is temporarily down. Never treat 'service_unavailable' as invalid — retry it from a background service instead.

---

## Next.js
https://www.taxid.dev/vat-api/integrations/nextjs

Validate EU VAT numbers in Next.js with the TaxID API from a Route Handler or Server Action. Keep your API key server-side, cache validated results with the App Router's fetch cache, and return only the boolean result to your client checkout form.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup for a free key with 100 validations/month. Add it to .env.local as TAXID_API_KEY without the NEXT_PUBLIC_ prefix, so it stays on the server and is never bundled into client JavaScript.
2. **Create a Route Handler** — Add app/api/validate-vat/route.ts with a GET handler that reads the country and number from search params and calls https://www.taxid.dev/api/v1/validate/{country}/{vat} with an Authorization bearer header. Return NextResponse.json with only the fields your client needs. Because this runs server-side, the key never leaves your infrastructure.
3. **Cache validated results** — Pass next: { revalidate: 3600 } to the fetch call so the App Router caches a valid lookup for an hour, matching the API's own cache window. Repeat checks for the same number then resolve instantly at the framework layer without another round-trip to VIES.
4. **Validate in a Server Action for forms** — For a checkout form using Server Actions, mark an async function with 'use server', validate the submitted VAT number inside it, and return a typed result. This keeps the key server-side and lets you revalidatePath or update state without exposing an API route publicly.
5. **Handle the three response states in the UI** — Map 'active' to a success state that enables reverse-charge, 'invalid' to an inline form error, and 'service_unavailable' to a soft warning that lets the customer continue while you flag the number for a background re-check. Never silently zero-rate on a 'service_unavailable' response.

### FAQ

**Should VAT validation run in a Route Handler or a Server Action?**
Both keep your key server-side. Use a Route Handler when you need a callable endpoint — for example, live validation as the user types via fetch from a client component. Use a Server Action when validation is part of a form submission, so you can validate and mutate state in one server round-trip without a separate API route.

**How do I stop my TaxID API key from leaking to the browser?**
Name the variable TAXID_API_KEY (not NEXT_PUBLIC_TAXID_API_KEY) and only read process.env.TAXID_API_KEY inside a Route Handler, Server Action, or server component. Anything prefixed with NEXT_PUBLIC_ is inlined into the client bundle, so never use that prefix for secrets.

**Can I cache VAT validation results in the App Router?**
Yes. Add next: { revalidate: 3600 } to the fetch that calls the TaxID API, and Next.js will serve a valid result from its Data Cache for an hour before re-fetching. This complements the API's own caching and cuts latency for repeat checks of the same number.

**Does this work with the Edge runtime?**
Yes. The handler uses standard fetch, so you can add export const runtime = 'edge' to run it at the Vercel Edge for lower latency. The validation logic is identical; only the deployment target changes.

---

## Cloudflare Workers
https://www.taxid.dev/vat-api/integrations/cloudflare-workers

Validate EU VAT numbers at the edge with Cloudflare Workers and the TaxID API. Store your key as a Worker secret, proxy validation requests globally with sub-50ms latency, and cache valid results at the Cloudflare edge to cut repeat round-trips to VIES.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup for a free key with 100 validations/month. Store it as a Worker secret with wrangler secret put TAXID_API_KEY so it is encrypted at rest and accessed through the env binding — never hard-coded in your Worker source or wrangler.toml.
2. **Write the fetch handler** — In your Worker's fetch(request, env) handler, read the country and number from the request URL, then call https://www.taxid.dev/api/v1/validate/{country}/{vat} with an Authorization header built from env.TAXID_API_KEY. Return Response.json(result) so any origin app can consume it.
3. **Cache valid results at the edge** — Use the Cache API or a Cache-Control header to store 'active' responses at the Cloudflare edge for up to an hour, and skip caching 'invalid' or 'service_unavailable' results. Edge caching means a repeat lookup for the same number is served from the nearest data center without touching VIES again.
4. **Guard the endpoint** — Because a Worker is publicly reachable, add a shared-secret header check or Cloudflare Access in front of it so only your own apps can call it. This prevents third parties from burning your TaxID quota through your Worker.
5. **Return structured results to callers** — Forward the valid, status, company_name, and company_address fields to the calling application, which decides whether to apply reverse-charge. Keep the tax-treatment decision in your origin app, not the Worker, so business logic stays in one place.

### FAQ

**How do I store the TaxID API key in a Cloudflare Worker?**
Use wrangler secret put TAXID_API_KEY to add it as an encrypted secret, then read it from the env argument of your fetch handler (env.TAXID_API_KEY). Do not place the key in wrangler.toml vars or in the Worker source, since those are not encrypted.

**Can I cache VIES lookups at the Cloudflare edge?**
Yes. Use the Workers Cache API or set a Cache-Control header on 'active' responses so Cloudflare serves repeat checks of the same VAT number from the edge for up to an hour. Do not cache 'service_unavailable' responses, or you would pin a transient outage.

**Should I put tax logic in the Worker or the origin app?**
Keep the Worker thin: it should validate and return the result, while the decision to apply reverse-charge belongs in your origin application alongside the rest of your billing logic. This keeps business rules centralized and testable.

**How do I stop others from abusing my validation Worker?**
Protect it with a shared-secret header that your apps send and the Worker checks, or place it behind Cloudflare Access. Since Workers are deployed on public URLs, an unprotected endpoint would let anyone consume your TaxID quota.

---

## Deno
https://www.taxid.dev/vat-api/integrations/deno

Validate EU VAT numbers in Deno and Deno Deploy with the TaxID API using native fetch — no npm install, no build step. Add it to a Deno Deploy handler or a Fresh route so VAT numbers are verified against VIES before you apply reverse-charge treatment.

1. **Get a free TaxID API key** — Sign up at taxid.dev/signup for a free key with 100 validations/month. Provide it as an environment variable and read it with Deno.env.get("TAXID_API_KEY"); on Deno Deploy, set it in the project's environment-variables settings rather than committing it.
2. **Write a validateVAT function** — Use the global fetch — no imports needed — to GET https://www.taxid.dev/api/v1/validate/{country}/{number} with an Authorization bearer header, and type the JSON response with a small interface. Because Deno ships fetch and TypeScript natively, there is no dependency to install or bundle.
3. **Serve it from a handler or Fresh route** — Call the function from a Deno.serve handler or a Fresh routes/api handler, reading the country and number from the request. Return the result as JSON. The same code runs locally with deno run --allow-net --allow-env and unchanged on Deno Deploy.
4. **Branch on the status** — Apply reverse-charge only when status is 'active'. Return a clear error for 'invalid', and for 'service_unavailable' let the request proceed while flagging the number for a later re-check — do not treat a temporary VIES outage as a failed validation.
5. **Deploy globally** — Push to Deno Deploy to run the validator at the edge in dozens of regions with no server to manage. Grant only --allow-net and --allow-env so the isolate has the minimum permissions it needs, keeping the deployment locked down.

### FAQ

**Do I need any dependencies to validate VAT numbers in Deno?**
No. Deno ships a global fetch and native TypeScript, so a single function with fetch and an interface is all you need — there is no npm install, package.json, or build step. This keeps a Deno Deploy isolate tiny and fast to cold-start.

**How do I read the API key on Deno Deploy?**
Set TAXID_API_KEY in your Deno Deploy project's environment-variables settings and read it with Deno.env.get("TAXID_API_KEY"). Locally, pass --allow-env (and --allow-net) so the script may read the variable and make the outbound request.

**Does this work with the Fresh framework?**
Yes. Put the validation call in a routes/api/ handler in your Fresh project and invoke it from your island's form submission. Fresh runs on Deno, so the same fetch-based function works without modification.

**What permissions does the validator need?**
Only --allow-net for the outbound HTTPS request to the TaxID API and --allow-env to read the API key. Granting the minimum flags keeps the Deno security sandbox tight, which is a core benefit of running validation on Deno.

---

# Comparisons

## TaxID vs Vatstack
https://www.taxid.dev/compare/vatstack-alternative

Vatstack is a well-documented EU VAT validation API — probably the most developer-friendly option before TaxID existed. If you're evaluating Vatstack today, the two questions most developers are asking are the free tier ceiling (20 requests/month) and the paid plan ceiling ($9/month for just 1,000 validations). TaxID starts free at 100/month and scales to 1,000,000/month from $149. Here's what you get, and what you give up, with each.

**Why TaxID:**
- 5× more free requests: 100/month vs Vatstack's 20
- Sub-10ms cached responses vs Vatstack's ~300ms
- 100× higher scale ceiling: 1M/month vs Vatstack's 1,000/month paid max
- Format validation before VIES call — saves quota on typos and invalid inputs
- Transparent VIES downtime errors with explicit service_unavailable status

**When Vatstack may fit better:** Vatstack has genuine strengths that TaxID doesn't match today. If your workflow depends on webhooks — async callbacks when a VAT status changes — Vatstack supports this natively and TaxID doesn't. If you need a dashboard-driven team workflow where non-developers can review validation history, Vatstack's UI is stronger. And if you need formal SLA documentation for enterprise procurement, Vatstack is a more established vendor name. If none of these apply — no webhooks, developer-only integration, startup-to-growth scale — TaxID will cost less and respond faster.

### FAQ

**Does TaxID support Vatstack webhooks?**
Not currently. TaxID is a synchronous REST API — each validation request returns a result immediately. If your workflow depends on async webhook callbacks when VAT status changes, Vatstack's webhook feature is currently unique to them. This is an honest limitation of TaxID today.

**How do I migrate from Vatstack to TaxID?**
Change the endpoint from api.vatstack.com/v1/validations?query=DE123456789 to taxid.dev/api/v1/validate/DE/DE123456789. Change the auth header from X-API-KEY to Authorization: Bearer. Both APIs return company_name and valid status — field names are compatible with minimal code changes.

**How does TaxID handle VIES downtime vs Vatstack?**
TaxID returns an explicit service_unavailable status when VIES is unreachable, with a boolean valid: false. This is documented in the error reference. We recommend building a fallback that allows the transaction when status is service_unavailable, rather than hard-failing customers during EU maintenance windows.

**Vatstack vs TaxID pricing: what's the real cost at scale?**
Vatstack's paid plan maxes out at 1,000 validations/month. For anything above that, you'd need to contact them for custom pricing. TaxID's Business plan covers 100,000 validations/month at $149, and custom plans scale to 1,000,000/month. For a SaaS with 500 B2B checkouts/month, TaxID's Starter plan ($19) is cheaper than Vatstack's entry tier ($9 for only 1,000 max).

---

## TaxID vs Vatlayer
https://www.taxid.dev/compare/vatlayer-alternative

Vatlayer is one of the longest-running EU VAT validation APIs — it's referenced in countless tutorials from 2015–2020 and shows up in many Stack Overflow answers. If you're on Vatlayer today, you're probably there because it was the easiest option when you set it up, not because it's still the best choice. The two most common reasons developers leave: HTTPS requires a paid plan (the free tier only supports HTTP), and response times above 500ms during peak hours cause checkout timeouts.

**Why TaxID:**
- HTTPS on all plans — including the free tier
- Sub-10ms cached responses vs Vatlayer's 500ms+ peak latency
- Stripe-style error codes vs Vatlayer's numeric error objects
- Modern REST path parameters vs Vatlayer's query string design
- Actively maintained with documented VIES downtime handling

**When Vatlayer may fit better:** Vatlayer has a free tier of 100 requests/month that has been stable since 2014 — if you want the lowest-friction test with no account setup, it's usable for prototypes on HTTP. For extremely low-volume internal tools under 50 requests/month that tolerate HTTP, it's not worth switching. But for any production checkout that handles real payments, the HTTPS paywall, latency, and lack of modern error handling make Vatlayer a reliability risk.

### FAQ

**Is Vatlayer still maintained in 2026?**
Vatlayer is part of the Apilayer product suite and remains operational, but it has seen limited feature development since 2018. The API design predates modern REST conventions — no path parameters, HTTPS behind a paywall, no SDK libraries. If you are starting a new integration, a more modern alternative avoids inheriting its design constraints.

**Does Vatlayer support HTTPS on the free tier?**
No. Vatlayer's free tier only allows HTTP requests. HTTPS access requires a paid subscription starting at $9.99/month. TaxID enforces HTTPS on all plans including the free tier — plain HTTP requests are redirected.

**How do I switch from Vatlayer to TaxID?**
Change the endpoint from apilayer.net/api/validate?access_key=KEY&vat_number=DE123456789 to taxid.dev/api/v1/validate/DE/DE123456789 with Authorization: Bearer YOUR_KEY. Move the country code from the vat_number string into the URL path. Update field mapping: Vatlayer's company_name maps directly to TaxID's company_name; Vatlayer's valid maps to TaxID's valid.

**Vatlayer shows 500ms response times — is that typical?**
Vatlayer does not cache VIES responses, so every request hits the VIES SOAP endpoint. VIES response times vary by country and load, ranging from 200ms to 800ms+. TaxID caches validated results for 24 hours in Upstash Redis — cached requests return in under 10ms regardless of VIES load.

---

## TaxID vs VATCheck API
https://www.taxid.dev/compare/vatcheckapi-alternative

VATCheck API is the go-to option if you want maximum headroom before paying anything — 500 free validations per month is the highest free tier in the EU VAT API market. If you're building a prototype or low-volume internal tool, that's a legitimate reason to start there. The question is what happens when you grow: VATCheck API's paid plans cap at 5,000 validations/month, while TaxID scales from 1,000 ($19) to 1,000,000 ($149) per month. You may outgrow VATCheck API before your first funding round.

**Why TaxID:**
- 100× higher scale ceiling: 1M/month vs VATCheckAPI's 5,000/month max paid
- VAT rate data via /api/v1/rates endpoint — VATCheckAPI has no rates endpoint
- 24h Redis caching with explicit cached field in response
- Stripe-style error codes with machine-readable status field
- Format validation before VIES call — saves quota on invalid inputs

**When VATCheck API may fit better:** VATCheckAPI's 500-request free tier is genuinely the most generous in the market — 5× TaxID's 100. If you need the widest possible free evaluation window for a prototype or internal tool that will never exceed 400 validations/month, VATCheckAPI is a reasonable choice. It also has historically strong uptime and a clean modern API. The ceiling is the constraint: if you'll ever exceed 5,000 validations/month on a paid plan, you'll need to migrate anyway.

### FAQ

**VATCheckAPI has 500 free requests vs TaxID's 100 — why switch?**
For prototyping, VATCheckAPI's larger free tier is genuinely an advantage — there's no reason to switch if you're evaluating and need headroom. The calculus changes when you go to paid plans: VATCheckAPI maxes out at 5,000 validations/month, while TaxID scales to 1,000,000/month. If your product will ever validate more than a few thousand VAT numbers monthly, building on TaxID avoids a second migration at growth stage.

**Does TaxID have VAT rate data like VATCheckAPI?**
TaxID has a dedicated /api/v1/rates/:country endpoint that returns the standard rate, reduced rates, and super-reduced rate for all 27 EU member states. This endpoint requires no authentication and is cacheable. VATCheckAPI does not have a rates endpoint.

**How do I migrate from VATCheckAPI to TaxID?**
The main change is moving the country code from the vat_number query parameter into the URL path. Change from: vatcheckapi.com/api/v5/check?vat_number=DE123456789&apikey=KEY to: taxid.dev/api/v1/validate/DE/DE123456789 with Authorization: Bearer KEY. Both return the same core fields — valid, company_name, company_address.

**What is VATCheckAPI's max validation volume on paid plans?**
VATCheckAPI's highest listed paid plan covers 5,000 validations/month. TaxID's Business plan covers 100,000 validations/month at $149, and custom plans are available for higher volumes. For any SaaS or marketplace with meaningful B2B checkout volume, TaxID's ceiling is much higher.

---

## TaxID vs LookupTax
https://www.taxid.dev/compare/lookuptax-alternative

LookupTax is built for companies that validate tax IDs globally — US EINs, Brazilian CNPJs, Australian ABNs, and EU VAT in one API. If that's your use case, it's a strong product. But if your scope is EU VAT only, you're paying for global coverage you don't use. LookupTax starts at $29/month for 10,000 validations. TaxID covers all 27 EU member states at $19/month for the same volume — with a 100-request free tier and a self-service signup that takes two minutes.

**Why TaxID:**
- EU-specialized: faster and cheaper for EU-only use cases
- $19/month for 1,000 validations vs LookupTax's $29/month entry point
- 100 free requests/month vs LookupTax's 50
- Simpler API surface — one endpoint for EU VAT, no global routing logic
- Self-service signup: API key in 2 minutes, no onboarding call

**When LookupTax may fit better:** LookupTax is the right choice if you need global tax ID validation beyond EU: US EINs, Australian ABNs, Brazilian CNPJs, or Canadian BNs. TaxID is EU-only and will not help you there. LookupTax also offers official SDKs (Node.js, Python, PHP), formal SLA agreements, batch validation, and webhooks — all features TaxID doesn't currently have. If your compliance team requires any of these, LookupTax is worth the premium. For EU-only validation at startup-to-growth scale with a developer-led team, TaxID is the leaner, cheaper option.

### FAQ

**Does TaxID support global tax ID validation like LookupTax?**
No. TaxID validates EU VAT numbers only — all 27 EU member states via the VIES system. If you need to validate US EINs, Australian ABNs, Brazilian CNPJs, or other non-EU identifiers, LookupTax (or a similar global provider) is the right tool. TaxID's EU specialization means it's faster and cheaper for EU-only workflows, but it is not a like-for-like replacement if you need global coverage.

**Does TaxID have official SDKs like LookupTax?**
Not currently. TaxID's API follows standard REST conventions (Bearer auth, JSON responses, HTTP status codes), so integrating with any HTTP client in any language takes under 10 lines of code. The documentation includes examples for Node.js, Python, PHP, and curl. If typed SDK wrappers are a requirement for your team's workflow, LookupTax has the advantage.

**How does LookupTax's pricing compare to TaxID for EU-only use?**
For EU VAT only: LookupTax starts at $29/month for 10,000 validations. TaxID's Growth plan is $49/month for 10,000 validations — slightly more expensive at that tier. However, TaxID's Starter plan covers 1,000 validations for $19/month, and the free tier covers 100/month. If your volume is under 1,000/month, TaxID is significantly cheaper.

**Does LookupTax have an SLA?**
Yes — LookupTax offers SLA guarantees, which TaxID does not currently provide. If your enterprise procurement or compliance team requires a formal SLA, LookupTax is currently the better choice for that requirement.

---

## TaxID vs Avalara
https://www.taxid.dev/compare/avalara-alternative

Avalara is an enterprise tax compliance platform — it handles tax calculation, filing, and reporting for companies managing millions in tax liability. If someone recommended Avalara for your B2B checkout's EU VAT validation step and you don't need the full compliance stack, you're evaluating a $500+/month enterprise product for a problem that a $19/month API solves. TaxID is not a replacement for Avalara if you need tax calculation or filing. It is a self-service alternative for the specific task of EU VAT number validation — with a free tier, no sales process, and a working API in two minutes.

**Why TaxID:**
- Self-service signup — API key in 2 minutes, no sales call
- $0–$149/month vs Avalara's $500+/month enterprise pricing
- Built for developers: REST API, no SDK required, no ERP integration needed
- Free tier with 100 validations/month to evaluate before paying
- Focused scope: EU VAT validation only — no complexity tax for features you don't use

**When Avalara may fit better:** Avalara is the right choice for several scenarios TaxID cannot handle. If you need full tax compliance — calculation, filing, and reporting across multiple jurisdictions — Avalara is purpose-built for this and TaxID is not. If you require deep ERP integration with SAP, NetSuite, Dynamics 365, or Salesforce Commerce Cloud, Avalara has certified connectors. If you need global coverage beyond EU (US sales tax, Canadian GST, Australian GST), Avalara covers it. And if your procurement process requires a formal MSA, dedicated support, and an SLA, Avalara has enterprise contracts. For teams that only need to validate EU VAT registration numbers — and not calculate, file, or report on EU taxes — TaxID does that specific job at a fraction of the cost.

### FAQ

**Can TaxID replace Avalara for EU VAT compliance?**
Only for one specific task: validating that a customer's EU VAT number is registered. TaxID does not calculate taxes, file VAT returns, or provide compliance reporting. If you use Avalara for those features, TaxID is not a replacement. If you use Avalara (or are evaluating it) solely to check whether a B2B customer's VAT number is valid at checkout, TaxID does that specific job without the enterprise platform overhead.

**What does Avalara do that TaxID doesn't?**
Avalara calculates tax amounts for transactions, handles tax filing and remittance, generates compliance reports, integrates with ERP systems (SAP, NetSuite, Salesforce), and covers global tax types beyond EU VAT (US sales tax, GST, etc.). TaxID only validates whether a VAT number is registered — it returns valid/invalid status, company name, and address. TaxID has no tax calculation, filing, or reporting capabilities.

**Is there a self-service Avalara alternative with no sales process?**
For EU VAT validation specifically: TaxID has self-service signup, a free tier with 100 validations/month, and paid plans from $19/month. No demo call, no MSA, no implementation timeline. You can have a working integration in under an hour. Avalara's full platform requires a sales engagement, scoping, and implementation time typically measured in weeks.

**How much does Avalara cost for EU VAT validation only?**
Avalara doesn't publish pricing for individual features — the platform is sold as an enterprise bundle starting around $500/month for basic tiers, and typical enterprise contracts are significantly higher. If VAT validation is the only thing you need, that price is for an entire compliance platform you won't use. TaxID's Business plan covers 100,000 EU VAT validations/month for $149.

**Does TaxID support tax filing or only validation?**
TaxID validates EU VAT registration numbers only — it confirms whether a VAT number is active in VIES and returns the registered company name and address. It does not calculate tax amounts, generate VAT returns, or file with any tax authority. For those needs, look at dedicated compliance platforms.

---

## TaxID vs VATComply
https://www.taxid.dev/compare/vatcomply-alternative

VATComply is a free, open-source EU VAT validation API — a thin wrapper over the EU's VIES system that needs no API key and no sign-up. That makes it the fastest thing in the world to drop into a prototype: one GET request, no auth. The honest question is what happens when the prototype becomes production. VATComply is a best-effort community service with no SLA, no support, no caching layer, and a ~2 request/second per-IP limit — every call hits VIES live, so it inherits VIES's downtime and latency directly. TaxID is the commercial counterpart: keyed, cached with sub-10ms responses, and covering GB, AU, NO and CH on top of the 27 EU states. Here's the honest trade-off.

**Why TaxID:**
- 24h Redis caching with sub-10ms cached responses — VATComply calls VIES live on every request
- Commercial reliability: per-account API keys, usage analytics and support vs a best-effort community service
- Higher throughput — no hard ~2 request/second per-IP cap
- Coverage beyond the EU: GB (HMRC), Australia (ABR), Norway (Brønnøysund) and Switzerland (BFS)
- Explicit service_unavailable status when VIES is down, instead of a raw upstream failure

**When VATComply may fit better:** VATComply is genuinely the right call in three cases. If your budget is zero and your volume is low — a hobby project, an internal script, a one-off backfill — a free, no-key endpoint is unbeatable. If you would rather self-host or audit the code than depend on any SaaS, VATComply is open source (github.com/madisvain/vatcomply) and you can fork it. And if you are just prototyping and don't yet need reliability, support, or non-EU coverage, there is no reason to pay. You only outgrow it when you need uptime guarantees, higher throughput, a caching layer, GB/AU/NO/CH coverage, or someone to call when it breaks.

### FAQ

**Is VATComply really free?**
Yes — VATComply is completely free and needs no API key or account. It is an open-source (github.com/madisvain/vatcomply) wrapper over the EU VIES system, rate-limited to roughly 2 requests per second per IP. There are no paid tiers. The trade-off is that it is a best-effort community service with no SLA, no support and no uptime guarantee, so it suits prototypes and internal tools better than a production checkout flow.

**What does TaxID add over a free VIES wrapper like VATComply?**
Reliability, performance and coverage. TaxID caches validated results for 24 hours in Redis, so cached lookups return in under 10ms instead of waiting on VIES every time; it is a keyed commercial service with usage analytics and support; and it validates GB (HMRC), Australia (ABR), Norway and Switzerland in addition to the 27 EU states. VATComply is EU/VIES only and calls VIES live on every request.

**How do I migrate from VATComply to TaxID?**
Change the endpoint from api.vatcomply.com/vat?vat_number=DE123456789 to taxid.dev/api/v1/validate/DE/DE123456789, add an Authorization: Bearer YOUR_KEY header, and move the country code into the URL path. Map the response: VATComply's top-level name becomes TaxID's company_name; both return the registered address and a valid boolean.

**Can I self-host VATComply?**
Yes — VATComply is open source, so you can run your own instance rather than depend on the public endpoint. That is a real advantage if you want full control. If you would rather not operate infrastructure and want caching, an SLA path, analytics and non-EU coverage out of the box, a managed API like TaxID handles that for you.

---

## TaxID vs VAT Sense
https://www.taxid.dev/compare/vatsense-alternative

VAT Sense is a capable multi-region tax API — it validates VAT and tax IDs across the EU plus the UK, Australia, Norway, Switzerland, South Africa and Brazil, ships official SDKs in several languages, and can return an official VIES/HMRC consultation number as audit evidence. It has a genuine free tier of 100 validations/month, the same as TaxID. If you're comparing the two, the differences are in the details: VAT Sense authenticates with HTTP Basic auth and returns company data under data.company.company_name; TaxID uses a Bearer token, returns company_name at the top level, and layers a 24h Redis cache in front of VIES for sub-10ms cached responses. Here's the honest side-by-side.

**Why TaxID:**
- Modern Bearer token auth vs VAT Sense's HTTP Basic auth
- Explicit 24h Redis caching with sub-10ms cached responses
- Same 100/month free tier, plus a documented service_unavailable status when VIES is down
- Flat response — company_name at the top level, not nested under data.company
- Focused EU (+GB/AU/NO/CH) surface: one endpoint, no multi-region routing

**When VAT Sense may fit better:** VAT Sense is the better pick in a few real cases. If you need coverage beyond the EU + GB/AU/NO/CH that TaxID handles — specifically South Africa or Brazil — VAT Sense covers them and TaxID does not. If you want official, vendor-maintained SDKs in your language (Python, PHP, Go, Java) rather than hand-rolling HTTP calls, VAT Sense has them today. And if your compliance workflow needs an official VIES/HMRC consultation number as an audit reference, VAT Sense exposes that directly. For a lean, EU-focused integration that prefers Bearer auth and an explicit caching/latency story, TaxID is the tighter fit.

### FAQ

**How does VAT Sense's coverage compare to TaxID?**
Both validate the 27 EU member states via VIES. VAT Sense also covers the UK, Australia, Norway, Switzerland, South Africa and Brazil; TaxID covers the UK (HMRC), Australia (ABR), Norway (Brønnøysund) and Switzerland (BFS), but not South Africa or Brazil. If you need ZA or BR validation, VAT Sense is the better choice.

**Does VAT Sense have official SDKs and does TaxID?**
VAT Sense publishes official SDKs (Python, PHP, Go, Java). TaxID does not ship SDKs today — its REST API (Bearer auth, JSON responses, standard HTTP status codes) integrates with any HTTP client in a few lines, and the docs include Node.js, Python, PHP and curl examples. If typed SDK wrappers are a hard requirement for your team, VAT Sense has the edge; note that VAT Sense's SDKs are versioned 0.x and flagged as subject to change.

**How do I migrate from VAT Sense to TaxID?**
Switch from HTTP Basic auth (username 'user', password = key) to an Authorization: Bearer header, change the endpoint from api.vatsense.com/1.0/validate?vat_number=DE123456789 to taxid.dev/api/v1/validate/DE/DE123456789, and move the country code into the path. Remap the response: VAT Sense's data.company.company_name becomes TaxID's top-level company_name.

**Do I get an official VIES consultation number from TaxID?**
Not currently. VAT Sense can return an official VIES/HMRC consultation number, which is useful as an audit reference proving you checked a VAT number at a point in time. TaxID returns the validation result, company name and address, but does not currently surface a consultation number. If that audit artefact is required by your compliance process, VAT Sense has it today.

---

## TaxID vs Fonoa
https://www.taxid.dev/compare/fonoa-alternative

Fonoa is an enterprise global tax platform — its Lookup product validates tax IDs in real time against 100+ countries and 115+ government sources directly, and it sits alongside a full stack for tax determination, e-invoicing and reporting. If you're an enterprise with worldwide compliance obligations, that breadth is the point. But if your job is validating EU VAT numbers at checkout, Fonoa is a contact-sales, no-free-tier, enterprise-contract product for a task a self-serve API solves. TaxID is not a replacement for Fonoa's global platform — it's a leaner, EU-focused (plus GB/AU/NO/CH) alternative for the specific validation step, with self-serve signup, a free tier, and public pricing.

**Why TaxID:**
- Self-serve signup — API key in 2 minutes, no sales call or contract
- Free tier with 100 validations/month to evaluate before paying
- Transparent, public pricing vs quote-by-sales enterprise contracts
- One simple GET with Bearer auth vs a POST body with a subscription-key header
- Sub-10ms cached responses for the EU (+GB/AU/NO/CH) scope

**When Fonoa may fit better:** Fonoa is the right call for scenarios TaxID doesn't cover. If you need genuinely global coverage — 100+ countries, worldwide TIN/GST validation against direct government sources, not just VIES — Fonoa is built for it. If you're an enterprise whose compliance and audit obligations require contractual SLAs, direct-to-government validation, and a documented paper trail, Fonoa is purpose-built. And if you want one vendor spanning validation, tax determination, e-invoicing and reporting at high volume, Fonoa is a platform, not a single endpoint. For teams that only need to validate EU (and a few nearby) VAT numbers, that platform is far more than the job requires.

### FAQ

**Can TaxID replace Fonoa?**
Only for one specific task: validating EU (and GB/AU/NO/CH) VAT numbers. Fonoa is a global tax platform covering 100+ countries plus tax determination, e-invoicing and reporting. TaxID validates VAT numbers and returns the company name and address — it has no tax calculation, e-invoicing or reporting, and no coverage beyond the EU plus GB/AU/NO/CH. If you use Fonoa solely to check EU VAT numbers, TaxID does that job self-serve; otherwise it is not a like-for-like replacement.

**What does Fonoa do that TaxID doesn't?**
Global coverage (100+ countries, 115+ government sources, worldwide TIN/GST), enterprise contractual SLAs, real-time direct-to-government validation, batch validation at scale, and a full platform for tax determination, e-invoicing and reporting. TaxID is scoped to EU VAT validation plus GB/AU/NO/CH and does none of the platform pieces.

**Is there a self-serve alternative to Fonoa for EU VAT validation only?**
For EU VAT validation specifically, TaxID is self-serve: sign up, get an API key in minutes, and use a free tier of 100 validations/month with public paid pricing — no sales engagement or contract. Fonoa's platform is sold through sales with custom enterprise pricing and no public free tier.

**Does Fonoa publish pricing?**
No. Fonoa uses custom, quote-by-sales enterprise pricing with no public free tier — you contact their team for access and a quote. TaxID publishes its pricing and offers a free tier, so you can evaluate and estimate costs without a sales call.

---

# Glossary

## VIES (VAT Information Exchange System)
https://www.taxid.dev/glossary/vies

The EU Commission's official real-time system for validating VAT numbers across all 27 member states. It queries national tax databases and returns the registration status, company name, and address of any EU-registered business.

VIES (VAT Information Exchange System) is the official EU Commission database for validating EU VAT registration numbers. It sits between your application and the national tax authority of every EU member state — when you query VIES for a German VAT number, VIES forwards that request to the Bundeszentralamt für Steuern and returns the result. It is the only authoritative source for real-time EU VAT validation and is legally mandated for cross-border B2B zero-rate treatment.

## How VIES works

VIES exposes a SOAP/XML web service at ec.europa.eu/taxation_customs/vies/services/checkVatService. When you call it with a country code and VAT number, VIES forwards the request to the relevant national tax authority's database. The response contains four fields: `countryCode`, `vatNumber`, `valid` (boolean), and — when available — `name` and `address` of the registered business.

The 'when available' caveat is important: several EU member states do not share business name and address data through VIES. Germany, France, the Netherlands, Italy, and Spain return full details. Cyprus, Luxembourg, and some Eastern European states return only the `valid` flag. You cannot rely on name/address being present in all responses.

## VIES limitations developers encounter in production

- SOAP/XML protocol — no REST or JSON endpoint. You need a SOAP client or a wrapper library.
- Frequent downtime — VIES targets 99% uptime but national systems regularly cause partial outages. Some countries go offline for hours during weekends and public holidays.
- No caching — every call hits national databases. High-volume applications will hit rate limits (roughly 20–50 req/s across the entire system).
- No error distinction — when a national system is down, VIES returns `MS_UNAVAILABLE` which looks identical to a failed validation from your code's perspective.
- Greece uses `EL` as its VAT prefix, not `GR` (the ISO 3166 country code). This causes silent failures when developers use standard country codes.

> Never fail a customer transaction because VIES returned `MS_UNAVAILABLE`. That status means the national database is temporarily offline — not that the VAT number is invalid. You must handle this case explicitly or you will block valid EU business customers during VIES outages.

## What VIES returns

## Accessing VIES without SOAP

The EU Commission provides a browser-based checker at ec.europa.eu/taxation_customs/vies but this is not suitable for automated use. For production applications, the two options are: (1) call the SOAP service directly using a SOAP client, handling all downtime and rate-limit cases yourself, or (2) use a REST wrapper like [TaxID](/docs) that provides a JSON API, Redis caching, and explicit `service_unavailable` status codes.

### FAQ

**Is VIES free to use directly?**
Yes — the VIES SOAP service is free to call directly. However, it requires a SOAP client, provides no caching, has rate limits, and returns SOAP faults on downtime instead of clean error codes. Most production applications use a REST wrapper to avoid dealing with SOAP in application code.

**How reliable is VIES?**
VIES itself targets 99% uptime, but this figure covers the EU gateway — not the national systems behind it. Individual country databases (especially smaller member states) routinely go offline for maintenance. In practice, expect 1–3 partial outages per month, often during weekends. Monitor the EU's VIES status page or use a wrapper API that exposes availability history.

**Does VIES validate the business name or just the number?**
VIES validates that a VAT number exists in a member state's database and, for most countries, returns the registered company name and address. It does not verify that the name a customer provides matches the registered name — that verification must be done by your application logic.

**Why does VIES sometimes return 'INVALID' for a valid VAT number?**
Three common causes: (1) the national database is temporarily unavailable and VIES misreports it as invalid; (2) the VAT number is valid but the business has not yet been added to VIES (newly registered companies can take days to appear); (3) the number is correctly formatted but the business's registration was revoked. Always distinguish MS_UNAVAILABLE from true invalid responses.

**Can I use VIES in an EU country to validate a non-EU VAT number?**
No — VIES only covers the 27 EU member states. For UK VAT numbers (post-Brexit), you must query HMRC's Companies House API separately. For US EIN, Canadian BN, or other non-EU tax IDs, different national authorities apply.

---

## EU VAT Number
https://www.taxid.dev/glossary/eu-vat-number

A unique identifier issued by a national EU tax authority to businesses registered for value added tax. It enables zero-rate treatment on cross-border B2B transactions and is the basis for all EU VAT compliance.

An EU VAT number (officially: VAT identification number) is a unique ID issued by a national tax authority to a business that is registered to collect and remit value added tax. It consists of a two-letter country prefix followed by up to 12 alphanumeric characters — the exact format is defined by each member state independently, which makes EU VAT validation significantly more complex than validating a single uniform pattern.

## Format by country (top 10 EU markets)

## Common format mistakes

- Using GR instead of EL for Greek VAT numbers — ISO 3166 country code differs from VIES prefix
- Omitting the mandatory B in Dutch VAT numbers (NL123456789B01 — the B is not optional)
- Treating the Austrian U as optional (ATU12345678 — U is always present)
- Not stripping spaces and hyphens before validation — users often type VAT numbers with separators
- Accepting numbers that pass regex but fail VIES — format validity does not equal registration validity

## Why format validation alone is not enough

A VAT number that passes format validation (correct prefix, correct length, valid checksum) still might not be registered in VIES. A business may have deregistered, had its registration revoked, or the number may be well-formatted but completely fabricated. For B2B zero-rate treatment, EU regulations require that you validate the number against VIES — not just check its format.

> Always validate format before calling VIES. Format validation is instant and free; VIES calls take 200–2000ms and count toward rate limits. Reject obviously malformed numbers before spending a VIES call on them.

## What a valid VIES response proves

A VIES `valid: true` response proves three things: (1) a business with that VAT number exists in the national tax authority's database, (2) the registration is currently active as of the query date, and (3) the EU Commission can retrieve the record. It does not prove that the business name the customer provided matches the registered name — that additional check is your responsibility.

### FAQ

**What is the format of an EU VAT number?**
Each EU VAT number starts with a two-letter country prefix followed by up to 12 alphanumeric characters. The exact format varies by country — Germany uses 9 digits, France uses 2 alphanumeric chars + 9 digits, the Netherlands uses 9 digits + mandatory 'B' + 2 digits. There is no single EU-wide format.

**How do I programmatically validate an EU VAT number?**
Two steps: first, validate the format using a country-specific regex (strip spaces and hyphens first). Second, call VIES with the country code and number to confirm the registration is active. Format validation is instant; VIES confirmation takes 200–2000ms. Use the TaxID API to handle both steps with a single REST call and built-in downtime handling.

**Why does Greece use EL instead of GR?**
VIES uses the Greek VAT prefix EL, which predates the ISO 3166 standard that assigned GR as Greece's country code. The VIES system was not updated to match. If you use GR in a VIES lookup for a Greek VAT number, the call will fail silently or return invalid — always use EL for Greek VAT numbers.

**Can a VAT number change for an existing business?**
VAT numbers are generally permanent for the life of a business entity. However, a business may receive a new VAT number after a restructuring, merger, or change in legal form. It's good practice to re-validate stored VAT numbers periodically (monthly or quarterly) rather than assuming a once-validated number remains valid indefinitely.

---

## Reverse Charge VAT
https://www.taxid.dev/glossary/reverse-charge-vat

A VAT accounting mechanism where the buyer — not the seller — accounts for VAT on a cross-border B2B supply. The seller invoices at zero-rate; the buyer self-assesses VAT in their own country. EU law requires VAT number validation before applying it.

Reverse charge is a VAT accounting mechanism that shifts the tax collection obligation from the seller to the buyer on cross-border B2B transactions. Instead of the seller charging VAT and remitting it to their tax authority, the buyer accounts for the VAT in their own country — both 'paying' and claiming it back in the same VAT return, typically resulting in zero net cost. For the seller, it means issuing a zero-rate invoice with a 'reverse charge' notation.

## When reverse charge applies

Reverse charge applies to cross-border B2B supplies of goods and services within the EU when all three conditions are met: (1) both supplier and customer are registered for VAT, (2) the supply crosses an EU member state border, and (3) the customer provides a valid VAT number from a different EU member state. For digital services specifically, reverse charge applies regardless of the customer's country if they have a valid EU VAT number.

## How it works in practice for SaaS billing

- Customer claims to be an EU business and provides their VAT number at checkout
- You validate the VAT number against VIES before applying zero-rate — this is a legal requirement, not optional
- VIES confirms the number is valid and active
- You issue an invoice at 0% VAT with the notation 'VAT reverse charged' and both VAT numbers (yours and the customer's)
- Customer self-assesses VAT in their country by adding it to their VAT return as both input and output tax — net effect is usually zero
- You do not collect or remit VAT for this transaction

> If you apply reverse charge to a transaction and the VAT number turns out to be invalid or the business was not actually registered at the time of the sale, you — the seller — are liable for the full VAT amount on that transaction. You cannot recover it from the customer. This is why validation must happen before applying zero-rate.

## Invoice requirements under reverse charge

- Your VAT registration number
- Customer's VAT registration number (validated)
- The notation 'Reverse charge' or 'Reverse charge — Article 196 EU VAT Directive'
- Net amount (no VAT added)
- 0% VAT rate explicitly stated
- Date of supply

## Reverse charge vs zero-rated vs exempt

These three terms are often confused. Zero-rated means VAT applies at 0% — the transaction is taxable but at a zero rate, and input VAT recovery is allowed. Exempt means VAT does not apply and input VAT cannot be recovered. Reverse charge is a collection mechanism applied on top of the standard VAT treatment — the underlying transaction is typically standard-rated in the customer's country, but the collection obligation moves to them.

### FAQ

**What is EU reverse charge VAT?**
Reverse charge is a mechanism where the buyer accounts for VAT on a cross-border B2B supply instead of the seller. The seller invoices at zero-rate with a 'reverse charge' annotation. The buyer adds the applicable VAT to their own VAT return as both input and output tax, typically netting to zero. It prevents sellers from having to register for VAT in every EU country where they have business customers.

**Does reverse charge apply to all EU B2B transactions?**
No — reverse charge requires the supply to cross an EU member state border. If you and your customer are both registered in the same country, normal domestic VAT rules apply. Reverse charge specifically covers intra-community B2B supplies where supplier and customer are in different EU member states.

**What goes on a reverse charge invoice?**
A reverse charge invoice must include: your VAT number, the customer's VAT number, the notation 'Reverse charge' (or a reference to Article 196 of the EU VAT Directive), the net price, 0% VAT rate, and the date of supply. Some countries require additional fields — check the specific requirements of your country of establishment.

**What if the customer's VAT number is invalid?**
If you cannot confirm a valid VAT number, you must charge VAT at your country's standard rate. If you apply reverse charge on an invalid number and are later audited, you are liable for the VAT. Some businesses maintain a 'last known valid' cache for existing customers and allow transactions with a short validation grace period — but new customers should always be validated before first zero-rate invoice.

---

## B2B VAT Exemption
https://www.taxid.dev/glossary/b2b-vat-exemption

Zero-rate treatment applied to cross-border EU B2B supplies where the buyer holds a valid VAT number in a different member state. Not a true exemption — the transaction is still VAT-applicable; the buyer self-accounts via the reverse charge mechanism.

The term 'B2B VAT exemption' is widely used but slightly misleading. In EU VAT law, the transaction is not exempt — it is zero-rated, meaning VAT applies at 0% and both parties can still recover input VAT. What actually happens is that the VAT collection obligation shifts to the buyer via the reverse charge mechanism. From a billing system perspective, the practical effect is: no VAT charged on the invoice.

## Requirements to apply B2B zero-rate treatment

- The supplier must be registered for VAT in an EU member state
- The customer must hold a valid VAT number registered in a different EU member state
- The VAT number must be validated via VIES before applying zero-rate — this is legally required, not optional
- The supply must cross an EU border (both parties cannot be in the same member state)
- The supply must be of a type eligible for reverse charge (most goods and services qualify)

## B2B vs B2C VAT treatment

## Developer implementation

- Collect VAT number from the customer at checkout or onboarding
- Call the [TaxID API](/docs) (or VIES directly) to validate the number — do not skip this step
- If valid and in a different EU country: set VAT rate to 0%, apply reverse charge notation
- If invalid or missing: apply your standard VAT rate
- Store the validation result with a timestamp — you need an audit trail
- For recurring billing: re-validate monthly or on every renewal to catch deregistrations

> Do not rely on the customer's word that they are a registered EU business. If you apply zero-rate without VIES validation and the number is invalid, your company owes the full VAT amount. HMRC, the Bundeszentralamt, and other EU tax authorities audit this regularly for SaaS companies with high EU revenue.

## Handling the validation failure case

When VIES returns `service_unavailable` — meaning the national database is temporarily offline — you have two compliant options: (1) block the transaction until you can validate (safest, but poor UX), or (2) allow the transaction at full VAT and issue a credit note + zero-rate invoice once validation succeeds. Many SaaS companies choose option 2 with a 24-hour validation window. Caching the last-known-valid result and allowing a short grace period is also defensible during documented VIES outages.

### FAQ

**Is all EU cross-border B2B trade VAT-exempt?**
Not technically exempt — it is zero-rated with reverse charge. But yes, if your customer has a valid VAT number in a different EU member state, you invoice at 0% for most goods and services. Some categories (real estate, certain financial services) have different rules. Digital services B2B are always eligible for zero-rate/reverse charge.

**Must I validate the VAT number before applying zero-rate?**
Yes, this is a legal requirement under EU VAT Directive Article 138. A customer claiming to be a VAT-registered business is not enough — you must verify the registration against VIES. A valid VIES response at the time of the transaction is your audit evidence. Without it, tax authorities can disallow the zero-rate and assess the full VAT against you.

**What is the difference between zero-rated and exempt?**
Zero-rated means VAT applies at 0% — the supply is still within the VAT system, input VAT can be recovered, and it must be reported in your VAT return. Exempt means the supply falls outside the VAT system — no VAT is charged, but input VAT relating to exempt supplies cannot be recovered. B2B cross-border supplies are zero-rated, not exempt.

**Do I need to re-validate stored VAT numbers?**
For ongoing subscriptions, yes. A VAT number that was valid when the customer signed up may become invalid if the business deregisters, goes into administration, or changes its legal structure. Best practice is to re-validate on every renewal or at least monthly for active subscribers. Flag any that become invalid and revert to charging VAT until a new valid number is provided.

---

## DAC7 (EU Directive 2021/514)
https://www.taxid.dev/glossary/dac7

EU Council Directive 2021/514 requiring digital platform operators to collect, verify, and annually report seller income data and VAT numbers to national tax authorities. Applies to marketplaces and gig platforms with 30+ sellers or €2,000+ in facilitated transactions.

DAC7 (officially: EU Council Directive 2021/514 on Administrative Cooperation in Taxation) requires digital platform operators to collect, verify, and report seller income data to their national tax authority. The data is then automatically shared with the tax authorities of all EU member states where the sellers are tax-resident. It came into force on 1 January 2023, with first annual reports due by 31 January 2024.

## Who must comply with DAC7

DAC7 applies to 'platform operators' — businesses that operate a digital interface through which sellers offer goods, services, rental of property, or rental of transport. This includes marketplaces (Etsy-style, Amazon-style), rental platforms (Airbnb-style), freelance platforms (Fiverr-style), and food delivery platforms. The key threshold: if you have 30 or more active sellers in a calendar year, or facilitate more than €2,000 in transactions, you are in scope.

> Pure SaaS products that do not facilitate third-party seller transactions are NOT in scope for DAC7. If you sell your own software directly to customers, DAC7 does not apply to you. It applies when your platform acts as an intermediary between sellers and buyers.

## Seller data you must collect and verify

## VAT validation as a DAC7 requirement

For EU-based business sellers, DAC7 explicitly requires you to verify the VAT registration number. This is not a checkbox exercise — you must confirm the number is valid in the VIES system and document the validation result and date. Unverified or invalid VAT numbers on a DAC7 report expose the platform to penalties from the national tax authority.

## Annual reporting obligations

- Report deadline: 31 January of the year following the reporting period (e.g., January 31, 2025 for 2024 data)
- Report to: your national tax authority, which then shares data with other EU member states
- Excluded sellers: those with fewer than 30 transactions AND less than €2,000 in total consideration in the calendar year
- Notification to sellers: you must notify each seller of the data you have reported about them by the same deadline
- Record retention: keep the underlying data for 10 years

## Implementation approach for developer teams

The practical approach is to collect VAT numbers during seller onboarding and validate them immediately via VIES. Store the validation result and timestamp alongside the seller record. Re-validate quarterly or on each payout cycle. At year-end, generate the report from your seller data, flag any sellers with invalid or missing VAT numbers for manual review, and submit to your national authority in the required XML format (typically based on the OECD Common Reporting Standard schema).

### FAQ

**What is DAC7?**
DAC7 is EU Council Directive 2021/514, which requires digital platform operators (marketplaces, rental platforms, gig platforms) to collect, verify, and annually report seller data — including VAT numbers — to national tax authorities. The data is then shared across all EU member states to help tax authorities identify underreported income.

**Does DAC7 apply to my SaaS product?**
Only if your platform facilitates transactions between third-party sellers and buyers. Pure SaaS products that sell their own software directly to customers are not in scope. If you run a marketplace where sellers list goods or services and buyers purchase through your platform, DAC7 likely applies if you have 30+ sellers or facilitate €2,000+ in annual transactions.

**What happens if I do not comply with DAC7?**
Penalties vary by member state but typically include fines per unreported seller, percentage penalties on under-reported transaction values, and in serious cases, enforcement action against the platform operator. National tax authorities are actively cross-checking marketplace data against VAT returns, so non-compliance is increasingly likely to be detected.

**When are DAC7 reports due?**
Annual reports are due by 31 January of the year following the reporting period. The first reporting period was 2023, with first reports due 31 January 2024. Some member states granted extensions for the first year, but from 2025 onward the 31 January deadline is firm in all EU member states.

**Must I validate seller VAT numbers in real-time or just at onboarding?**
You must be able to report a valid, verified VAT number in your annual DAC7 submission. Best practice is to validate at onboarding (to catch typos immediately) and re-validate at least annually before your report deadline. If a VAT number has become invalid, you must note this in your report and flag it for the relevant tax authority.

---

## EORI Number
https://www.taxid.dev/glossary/eori-number

Economic Operators Registration and Identification number — a unique identifier for businesses engaged in customs activities within the EU. Required for importing or exporting physical goods across EU borders. Distinct from a VAT number and not validated via VIES.

An EORI (Economic Operators Registration and Identification) number is a unique identifier issued by an EU member state customs authority to businesses that import or export goods across EU borders. It is used in customs declarations, import/export documentation, and EU-wide customs risk profiling. An EORI number is not a tax identifier — it does not appear on VAT invoices and cannot be validated via VIES.

## EORI format

EORI numbers follow the format: two-letter EU country code + up to 17 alphanumeric characters. In practice, most EU countries issue EORI numbers that are either their VAT number with a country prefix or their national tax registration number with the country prefix appended. For example, a German EORI number might be DE + a 9-to-15 digit number issued by the Hauptzollamt.

## EORI vs VAT number

## When do you need an EORI number?

- Importing goods into the EU from a non-EU country
- Exporting goods from the EU to a non-EU country
- Moving goods between EU member states that require customs declarations (applies to some excise goods)
- Post-Brexit: UK businesses that import or export goods to/from the EU need both a UK EORI and an EU EORI

## EORI and digital services

> If your business sells only digital services (SaaS, APIs, software licenses, streaming), you do not need an EORI number. EORI is exclusively for businesses that physically move goods across borders. Your relevant identifier for VAT and cross-border transactions is your VAT number, validated via VIES.

## How to obtain an EORI number

EORI registration is done through the customs authority of the EU member state where your business is established. For UK businesses post-Brexit, you register with HMRC. The process typically takes 1–3 business days and is free. You only need to register once — EORI numbers are valid across the entire EU and are automatically shared between member state customs systems.

### FAQ

**What is an EORI number?**
An EORI (Economic Operators Registration and Identification) number is a unique identifier for businesses that import or export physical goods across EU borders. It is used in customs declarations and EU-wide customs risk assessment. It is not a tax number and cannot be used for VAT invoicing or VIES validation.

**Is an EORI number the same as a VAT number?**
No — they are issued by different authorities for different purposes. VAT numbers are tax identifiers used in VAT invoices and validated via VIES. EORI numbers are customs identifiers used in import/export declarations. Some countries issue EORI numbers that incorporate the VAT number, but they remain distinct identifiers with separate validation systems.

**Do I need an EORI if I only sell software (SaaS)?**
No. EORI is only required for businesses that physically move goods across EU borders. If your business sells digital services — SaaS subscriptions, APIs, software licenses, online courses — you have no customs activity and do not need an EORI number. Your relevant compliance obligation is VAT registration and, for B2B sales, VAT number validation via VIES.

**Do UK businesses need an EU EORI after Brexit?**
Yes, if they import or export physical goods to or from the EU. Post-Brexit, UK businesses need both a UK EORI (issued by HMRC) for UK customs purposes and an EU EORI (issued by any EU member state customs authority) for EU customs purposes. The two systems are separate. For digital services, neither is required.

---

## EU OSS Registration
https://www.taxid.dev/glossary/oss-registration

The EU One Stop Shop (OSS) scheme, introduced July 2021, allows businesses selling digital services to EU consumers (B2C) to register for VAT in one EU country and remit VAT for all EU consumer sales through a single return — eliminating the need for separate VAT registrations in each member state.

The EU One Stop Shop (OSS) scheme, introduced 1 July 2021, is a single VAT registration mechanism for businesses selling digital services or goods to consumers (B2C) across the EU. Instead of registering for VAT separately in every EU country where you have consumer customers, you register for OSS in one EU member state and file a single quarterly return there, covering all your EU consumer sales. The tax authorities distribute the VAT to the correct member states.

## Who needs OSS registration

- EU-based businesses selling digital services to EU consumers in other member states, once they exceed €10,000 in annual cross-border consumer sales
- Non-EU businesses selling digital services to EU consumers — the €10,000 threshold does not apply; OSS (or IOSS for goods) is required from the first sale
- Businesses previously registered under the old MOSS (Mini One Stop Shop) scheme — OSS replaced MOSS in July 2021

> OSS only applies to B2C (business-to-consumer) sales. If your EU customer has a valid VAT number and you are making a B2B cross-border supply, reverse charge applies instead — OSS is irrelevant for that transaction. This is why VAT number validation is critical: it determines which regime applies.

## OSS vs the pre-2021 system

Before OSS, the threshold was €35,000–€100,000 per country (varying by member state) — below that, you charged your home country's VAT rate on consumer sales. Above it, you had to register locally. OSS replaced this with a single €10,000 EU-wide threshold for EU businesses (first cross-border sale for non-EU businesses) and a single registration in one member state.

## How OSS interacts with VAT number validation

OSS and VAT number validation work together at the checkout step. When a customer claims to be a business by providing a VAT number, you validate it via VIES. If valid: reverse charge applies — no OSS needed, zero-rate the invoice. If invalid or not provided: treat as B2C — apply the appropriate EU VAT rate and report via OSS. This validation step is the gate between two completely different VAT regimes.

## OSS filing and reporting

- File quarterly — return due by the end of the month following each quarter (Q1 return due April 30)
- Report B2C sales by destination country and applicable VAT rate
- Pay in euros to your country of registration — the OSS portal distributes to other member states
- Keep records for 10 years
- OSS does not cover B2B transactions, imports of goods above €150, or sales to customers in your own member state

### FAQ

**What is EU OSS registration?**
OSS (One Stop Shop) is an EU VAT simplification scheme that lets businesses selling digital services or goods to EU consumers register for VAT in one EU country instead of registering separately in every country where they have consumers. A single quarterly return covers all EU consumer sales, with the OSS authority distributing VAT to the correct member states.

**Does my SaaS business need OSS registration?**
If you sell to EU consumers (individuals without a VAT number), yes — once you exceed €10,000 in annual cross-border consumer sales (or from the first sale if you are based outside the EU). If you sell exclusively to EU businesses (validated VAT numbers), OSS does not apply — reverse charge handles those transactions and no OSS registration is needed.

**Does OSS apply to B2B transactions?**
No. OSS exclusively covers B2C supplies. For B2B cross-border supplies within the EU (where your customer has a valid VAT number), the reverse charge mechanism applies and OSS is irrelevant. This is why validating customer VAT numbers at checkout determines which regime applies: B2B → reverse charge; B2C → OSS.

**Can non-EU businesses use OSS?**
Yes — non-EU businesses can register for OSS (specifically the Non-Union OSS scheme) to cover sales of digital services to EU consumers. The €10,000 threshold does not apply; non-EU businesses must register for OSS before making their first B2C sale to an EU consumer. Registration is done with any EU member state's tax authority of your choice.

---

## Intrastat
https://www.taxid.dev/glossary/intrastat

The EU system for collecting trade statistics on goods moved between EU member states. Required for businesses that trade physical goods above national thresholds. Does not apply to digital services or SaaS. Distinct from VAT reporting.

Intrastat is the EU statistical reporting system for tracking the movement of goods between EU member states. Businesses that trade goods above their country's Intrastat threshold must file monthly or quarterly returns reporting details of their cross-border goods movements. Intrastat data feeds into EU-wide trade statistics but is separate from VAT reporting — you can owe VAT on a transaction without an Intrastat obligation, and vice versa.

## Intrastat vs VAT reporting

## Who must file Intrastat

Intrastat filing is required for VAT-registered businesses in EU member states that import or export goods above the country's annual threshold. Thresholds vary significantly by country and are revised periodically. Small businesses below the threshold are exempt. The thresholds apply separately to arrivals (imports from other EU states) and dispatches (exports to other EU states) — you may be above threshold for one direction but not the other.

## What Intrastat requires you to report

- Your VAT number (as the reporting party)
- Partner country (EU member state goods moved to or from)
- Commodity code (CN8 — 8-digit Combined Nomenclature code)
- Statistical value (approximate transaction value in euros)
- Net mass (weight in kilograms, for most goods categories)
- Nature of transaction code (sale, return, processing, etc.)
- Delivery terms (Incoterms) — required in some member states

## Does Intrastat apply to digital services?

> Digital services — including SaaS subscriptions, API access, software licenses, streaming, and online courses — do not require Intrastat filing. Intrastat covers only physical goods. If your business sells exclusively digital services, your EU reporting obligations are VAT-related (VAT returns, OSS if applicable) and potentially DAC7 if you operate a marketplace. Intrastat does not apply.

> Intrastat reporting covers trade in physical goods between EU member states. It does not apply to digital services, SaaS subscriptions, or software supplied electronically. If you sell digital services cross-border within the EU, your compliance obligations are VIES VAT number validation (for B2B) and OSS registration (for B2C) — not Intrastat.

### FAQ

**What is Intrastat?**
Intrastat is the EU system for collecting statistics on trade in physical goods between EU member states. VAT-registered businesses that move goods above their country's annual threshold must file monthly Intrastat returns with their national statistics office. It is a statistical obligation, not a tax obligation — separate from VAT reporting.

**Does Intrastat apply to SaaS or digital services?**
No. Intrastat exclusively covers physical goods. Digital services — SaaS, APIs, software, streaming — have no Intrastat filing requirement regardless of their value or the volume of EU customers. For digital services, your EU compliance obligations are VAT-related (VAT registration, OSS if selling B2C, reverse charge for B2B, and potentially DAC7 if you are a marketplace operator).

**What are the Intrastat filing thresholds?**
Thresholds vary by country and are typically revised annually. As of 2026: Germany (€800K arrivals / €500K dispatches), France (€460K both), Netherlands (€1M both), Spain (€400K both), Italy (€350K both). Always verify current thresholds with your national statistics office as they change. Thresholds apply separately to arrivals and dispatches.

**Is Intrastat the same as VAT reporting?**
No — they are separate obligations managed by different authorities. VAT reporting is submitted to your national tax authority (Finanzamt, HMRC, DGFIP, etc.) and covers all taxable supplies including digital services. Intrastat is submitted to your national statistics office and covers only physical goods movements above the annual threshold. Some countries use a combined form, but the obligations remain distinct.

---

## Standard VAT Rate
https://www.taxid.dev/glossary/standard-vat-rate

The default VAT rate applied to most goods and services in a country, ranging from 17% (Luxembourg) to 27% (Hungary) across EU member states.

The standard VAT rate (also called the normal rate) is the default percentage applied to goods and services that do not qualify for a reduced or zero rate. Under EU Directive 2006/112/EC, all member states must apply a standard rate of at least 15%. In practice, rates range from 17% in Luxembourg to 27% in Hungary.

## Standard VAT Rates Across the EU (2026)

## Standard Rate for Developers

For SaaS products and digital services, the standard rate almost always applies. When determining which country's standard rate to apply, use the customer's location (not the seller's) for B2C digital services under EU place of supply rules.

### FAQ

**What is the EU minimum standard VAT rate?**
The minimum standard VAT rate required by EU Directive 2006/112/EC is 15%. No EU member state may apply a standard rate below this threshold.

**Does the standard rate apply to SaaS products?**
Yes. Digital services including SaaS subscriptions, API access, and software are subject to the standard rate in the customer's country for B2C sales, or reverse charge for verified B2B sales.

**Which EU country has the lowest standard VAT rate?**
Luxembourg has the lowest standard VAT rate in the EU at 17%. This is followed by Malta at 18%.

**Which EU country has the highest standard VAT rate?**
Hungary has the highest standard VAT rate in the EU at 27%.

---

## Reduced VAT Rate
https://www.taxid.dev/glossary/reduced-vat-rate

A lower VAT rate applied to specific categories of goods and services deemed socially or culturally important, such as food, books, and medical goods. EU reduced rates range from 5% to 15%.

Reduced VAT rates are lower rates that EU member states may apply to specific categories of goods and services. Under EU Directive 2006/112/EC, reduced rates must be at least 5% and can only apply to categories listed in Annex III of the directive. Common reduced-rate categories include food products, pharmaceutical goods, books and publications, and cultural and sporting events.

## Common Reduced-Rate Categories

> SaaS subscriptions and digital services do NOT qualify for reduced rates in any EU member state — they always fall under the standard rate. Reduced rates apply to physical goods and specific, legislated categories.

## Reduced Rates by Country (Examples)

### FAQ

**What is the minimum reduced VAT rate allowed in the EU?**
The minimum reduced rate under EU Directive 2006/112/EC is 5%. Some member states have super-reduced rates below 5% (e.g., 2.1% in France), which are allowed as legacy provisions.

**Do digital products qualify for a reduced VAT rate?**
Generally no. E-books and digital publications are an exception in some countries (e.g., France, Germany, Netherlands). But software, SaaS, API access, and general digital services always fall under the standard rate.

**How do I know if my product qualifies for a reduced rate?**
Check whether your product category is listed in Annex III of EU Directive 2006/112/EC and whether the specific member state has chosen to apply a reduced rate to that category. When in doubt, apply the standard rate — overclaiming a reduced rate is a compliance risk.

---

## Place of Supply
https://www.taxid.dev/glossary/place-of-supply

The tax jurisdiction where a supply of goods or services is deemed to take place for VAT purposes, determining which country's VAT rules apply to the transaction.

Place of supply rules determine which country has taxing rights over a transaction. Getting the place of supply wrong means applying the wrong country's VAT rates and filing in the wrong jurisdiction — a compliance failure that can result in back-taxes and penalties.

## Place of Supply for Digital Services

For digital services (including SaaS, APIs, streaming, and software), the place of supply is always where the customer is located. This applies regardless of where the supplier is based. A German company selling SaaS to a French consumer must apply French TVA at 20%, not German MwSt. at 19%.

## Why This Matters for Developers

Your billing system must determine the customer's location before computing tax. Using the billing address country as a proxy is standard, but for compliance you should also consider IP geolocation as a secondary signal for B2C customers. For B2B, the validated VAT number determines jurisdiction.

> Store both the billing country and the VAT validation result on every transaction. This gives you the evidence needed to justify your tax treatment if audited — a billing address alone is insufficient for reverse charge.

### FAQ

**What is the place of supply for SaaS?**
For SaaS and all digital services, the place of supply is where the customer is located, regardless of where your company is based. This is defined in EU Directive 2006/112/EC, Article 58.

**Does place of supply change for B2B vs B2C?**
The place of supply for digital services is the customer's location in both cases, but the tax treatment differs. B2B sales to verified businesses use reverse charge (no VAT on your invoice). B2C sales require you to charge VAT at the customer's country rate.

**What if a customer claims to be in a low-tax country but their IP shows otherwise?**
You must make a reasonable determination based on the evidence available. Using two non-contradictory pieces of evidence (billing address + payment country) is sufficient under EU rules. Document your determination policy and apply it consistently.

---

## VAT Exemption
https://www.taxid.dev/glossary/vat-exemption

A VAT exemption means a transaction is not subject to VAT, either without the right to deduct input VAT (exempt without credit) or with full input VAT recovery (zero-rated).

A VAT exemption means that VAT is not charged on a particular supply. However, not all exemptions work the same way. The key distinction is whether the supplier can deduct input VAT they paid on purchases related to that exempt supply.

## Two Types of VAT Exemption

## B2B Reverse Charge: The Most Common Exemption for SaaS

For SaaS businesses selling to EU B2B customers, the most relevant 'exemption' is the reverse charge mechanism. When you sell to a verified EU business customer, you issue a zero-VAT invoice and include the note 'Reverse charge'. The buyer self-accounts for VAT in their country. This is not a true exemption — it's a shift of tax liability from seller to buyer.

> The reverse charge mechanism only applies when the customer has a valid EU VAT number. Always validate the VAT number via VIES or an API before issuing a zero-VAT invoice. Wrongly applying reverse charge creates compliance liability for you as the supplier.

### FAQ

**What is the difference between exempt and zero-rated?**
Zero-rated means VAT is charged at 0% — the supplier can still deduct input VAT on purchases. Exempt (without credit) means the supply is outside the VAT system entirely — the supplier cannot deduct input VAT related to exempt supplies.

**Does reverse charge count as a VAT exemption?**
Not technically. Reverse charge shifts the VAT accounting obligation from the supplier to the buyer. The supplier issues a zero-VAT invoice, but VAT is still accounted for — just by the buyer in their jurisdiction.

**Are SaaS products ever VAT-exempt?**
Generally no. SaaS products are not in any EU member state's list of VAT-exempt supplies. The applicable treatment is either standard-rated (B2C), reverse charge (B2B with valid VAT number), or out-of-scope (non-EU customer).

---

## VAT Invoice Requirements
https://www.taxid.dev/glossary/vat-invoice-requirements

The mandatory information that must appear on a VAT invoice under EU Directive 2006/112/EC, including supplier and customer details, VAT number, tax amount, and tax rate.

Under EU Directive 2006/112/EC (Article 226), every VAT invoice must contain specific mandatory elements. An invoice missing any of these elements is non-compliant, and the recipient may not be able to deduct the input VAT — creating a financial and compliance risk for both parties.

## Required Elements on a VAT Invoice

## Reverse Charge Invoice Requirements

For B2B cross-border sales where reverse charge applies, the invoice must: (1) include the customer's VAT number, (2) show 0% VAT or no VAT amount, and (3) include the note 'Reverse charge' (or the equivalent in the customer's language). Without the explicit reverse charge note, the invoice may not be accepted for input VAT recovery by the customer.

> Store all invoice data permanently — including the VAT treatment decision and validation result at the time of sale. Tax authorities can audit transactions up to 7-10 years later. Historical invoices must be reconstructable from stored data.

### FAQ

**What note is required on a reverse charge invoice?**
The invoice must include 'Reverse charge' (or the equivalent in the customer's language) and ideally cite the legal basis: 'Article 196 of Council Directive 2006/112/EC'. Some countries require the note in their local language.

**Can I issue invoices without VAT numbers?**
For B2C invoices (simplified invoices) below a certain threshold (typically €400), some countries allow simplified invoices without the customer VAT number. For B2B invoices or where reverse charge applies, the customer VAT number is always required.

**What is a simplified VAT invoice?**
A simplified VAT invoice contains fewer mandatory elements — typically allowed for small amounts. It still requires the invoice date, supplier VAT number, description, and VAT amount or rate, but can omit the customer's details.

**Do I need to issue invoices immediately?**
EU VAT rules generally require invoices to be issued by the 15th day of the month following the month of supply. However, many countries allow invoicing at the time of supply. Check your country's specific rules.

---

## Tax ID Validation
https://www.taxid.dev/glossary/tax-id-validation

The programmatic process of checking whether a tax identification number (VAT, ABN, UID, or similar) is legitimately registered with the issuing government authority. Tax ID validation confirms both the format and the live registration status of the number.

Tax ID validation is the process of verifying that a tax identification number is registered with the issuing government authority and is currently active. It has two layers: format validation (checking that the number matches the expected structure for its country) and registry validation (querying the live government database to confirm the business is currently registered). Both layers are required for compliance — a correctly-formatted number may belong to a deregistered business.

## Why Tax ID Validation Matters for B2B SaaS

For EU cross-border B2B sales, EU VAT Directive 2006/112/EC requires sellers to verify the buyer's VAT number before applying zero-rate treatment (reverse charge). Without this verification, the seller becomes liable for the full VAT amount on the incorrectly zero-rated invoice. Tax ID validation also serves as a first-line due diligence check: the company name and address returned by the registry can be cross-referenced against the buyer's self-declared details.

## Tax ID Types by Country

The [TaxID API](/vat-api) validates all five types through a single REST endpoint using the same response format. Format validation errors return instantly without consuming API quota. Registry validation queries the live government database and returns the registered company name and address alongside the validation status.

---

## VAT MOSS (Mini One Stop Shop)
https://www.taxid.dev/glossary/vat-moss

A simplified EU registration scheme that allows businesses selling digital services to consumers in multiple EU countries to file a single VAT return in one member state instead of registering for VAT separately in each country. Superseded by the broader OSS (One Stop Shop) scheme in July 2021.

VAT MOSS (Mini One Stop Shop) was an EU VAT simplification scheme introduced in 2015 specifically for businesses selling digital services — software, SaaS, streaming, e-books, and similar — to private consumers (B2C) across EU member states. Before MOSS, selling digital services to consumers in France meant registering for VAT in France, in Germany meant registering in Germany, and so on across all 27 member states. MOSS allowed businesses to file a single quarterly return in their home member state, and that state would distribute the VAT to the relevant destination countries.

## MOSS vs OSS: What Changed in July 2021

In July 2021, the EU replaced VAT MOSS with the broader OSS (One Stop Shop) scheme as part of the EU VAT e-commerce package. OSS covers not only digital services but all B2C cross-border supplies of goods and services. Businesses that were registered under MOSS were automatically migrated to OSS. The mechanics are the same — single registration, single quarterly return, one payment — but the scope is wider. The term 'MOSS' is still frequently used informally to refer to the OSS scheme, particularly in older SaaS billing documentation.

## MOSS / OSS vs B2B Reverse Charge

MOSS and OSS only apply to B2C supplies — sales to private consumers without a VAT number. B2B sales to EU-registered businesses use the reverse charge mechanism instead: the seller charges zero VAT, and the buyer accounts for VAT in their own country. MOSS/OSS is irrelevant for B2B transactions; [reverse charge](/glossary/reverse-charge-vat) and VAT number validation apply. Most SaaS companies serving both B2B and B2C customers need both: OSS for consumer customers and VIES validation for business customers.

> OSS registration is handled through your home member state's tax authority. In the UK post-Brexit, HMRC operates a separate Non-Union OSS scheme. See the [OSS Registration glossary entry](/glossary/oss-registration) for the full registration process.

---

## VAT Number Format
https://www.taxid.dev/glossary/vat-number-format

The country-specific structure that a VAT number must follow to be considered valid. Each EU member state has a unique format: a two-letter country prefix followed by 8–12 characters that may be numeric, alphanumeric, or include specific separators. Format validation is the first step before querying VIES.

Every EU member state has its own VAT number format — a country prefix plus a number of digits or alphanumeric characters that varies by country. Validating the format before querying VIES catches the majority of user input errors instantly, without a network call. This saves API quota, reduces latency, and produces better error messages (telling the user their number looks wrong for a German VAT number is more useful than a generic 'not found in VIES' response).

## EU VAT Number Formats

> Greece uses the prefix EL in VIES, not GR. GR is Greece's ISO country code, but its VAT system uses the EU-internal EL prefix. Submitting GR123456789 to VIES returns a country_not_found error. The TaxID API accepts both GR and EL and normalises internally.

## Non-EU Formats

Outside the EU, the UK uses GB + 9 digits (or XI for Northern Ireland). Australia uses ABNs — 11-digit numbers with no prefix (validated as AU in the TaxID API). Norway uses MVA numbers: 9-digit organisation number + MVA. Switzerland uses UID format: CHE-XXX.XXX.XXX MWST.

For country-specific format details, regex patterns, and live validation tools, see the individual [VAT API country pages](/vat-api). Each page includes the exact format specification, a valid example number, and copy-paste code to validate that country's format in Node.js, Python, and PHP.

---

## VAT Registration Threshold
https://www.taxid.dev/glossary/vat-registration-threshold

The annual taxable turnover level above which a business is required to register for VAT in a given jurisdiction. Businesses below the threshold may choose to register voluntarily. For EU cross-border B2C digital services, the threshold is €10,000 per year across all EU member states combined.

A VAT registration threshold is the annual revenue level above which a business is legally required to register for VAT in a given country. Below the threshold, registration is optional — some businesses register voluntarily to reclaim input VAT. The threshold varies significantly by country and by the type of supply (domestic vs cross-border, goods vs services).

## EU Threshold for Digital Services

For EU cross-border B2C digital services (SaaS, streaming, software, e-books), the threshold is €10,000 in total sales to EU consumers per calendar year — aggregated across all EU member states. Once you exceed €10,000 in EU B2C digital services sales, you must charge and remit VAT in each customer's country. The OSS scheme allows you to do this through a single registration rather than registering in each country. The €10,000 threshold was introduced in July 2021 as part of the EU VAT e-commerce package.

## UK VAT Threshold

The UK VAT registration threshold is £90,000 in taxable turnover in a 12-month rolling period (as of 2024). This applies to UK-sourced revenue for UK-based businesses. For non-UK businesses selling digital services to UK consumers, there is no threshold — you must register from the first supply.

## B2B vs B2C: Threshold Differences

The €10,000 EU threshold applies only to B2C sales (sales to private consumers without a VAT number). B2B sales to EU businesses using the reverse charge mechanism do not count toward the threshold — they are zero-rated in the seller's country and the buyer accounts for VAT in their own country. For a SaaS company selling primarily to businesses, the practical compliance path is VIES VAT number validation for B2B customers, and OSS registration once B2C EU consumer sales exceed €10,000.

> If a customer provides a valid VAT number (confirmed via VIES), they are B2B — reverse charge applies regardless of their billing location. If no VAT number is provided, treat the customer as B2C — charge VAT at the destination country rate. This is why accurate VAT number validation at checkout matters for determining the correct tax treatment.

## EU member state domestic VAT registration thresholds

Domestic VAT thresholds apply to businesses established in that member state. They are distinct from the EU-wide €10,000 OSS threshold for cross-border digital services. For most SaaS companies selling cross-border, the €10,000 OSS threshold is the relevant number — not the domestic thresholds listed below.

## OSS threshold vs domestic registration threshold

> Non-EU businesses have no registration threshold for EU B2C digital services. If your company is incorporated outside the EU and you sell a single digital service to an EU consumer, you are required to register for VAT — either via the Non-Union OSS scheme or directly in the customer's member state. The €10,000 threshold applies only to EU-established businesses.

## Developer context: why thresholds matter for your billing system

For a SaaS billing system, thresholds affect two routing decisions. First, if your EU B2C revenue is below €10,000/year, you can apply your home country's VAT rate to all EU B2C customers and remit it locally — no OSS needed. Your billing system only needs to implement this more complex routing once you cross the threshold. Second, domestic thresholds matter if you have a local subsidiary in an EU country — once that entity's local revenue crosses the domestic threshold, it must register for local VAT independently of the group's OSS registration.

### FAQ

**What is the EU-wide OSS threshold for digital services?**
€10,000 per calendar year in total B2C digital services revenue across all EU member states (excluding your home country's domestic sales). Once you exceed this, you must charge VAT at each customer's country rate and either register for OSS or register locally in each country where you have customers.

**Does the €10,000 threshold apply per country or EU-wide?**
EU-wide. It is the combined total of your B2C digital services sales to all EU customers (excluding your own member state). Selling €500 each to customers in 20 different EU countries counts as €10,000 total and triggers the threshold.

**Do B2B sales (with reverse charge) count toward the threshold?**
No. The €10,000 OSS threshold applies only to B2C sales. B2B cross-border sales using the reverse charge mechanism are zero-rated and do not count toward OSS threshold calculations.

**What happens if I exceed the threshold mid-year?**
You must register for OSS and start charging the correct country-specific VAT rate from the transaction that causes you to exceed the threshold. You cannot apply it retrospectively to previous transactions in the same year.

**I'm a US company selling SaaS to EU consumers — what's my threshold?**
Zero. Non-EU businesses have no registration threshold. You are required to register for EU VAT (typically via the Non-Union OSS scheme) from your first B2C sale to an EU consumer.

---

## EU VAT Directive
https://www.taxid.dev/glossary/eu-vat-directive

EU Council Directive 2006/112/EC — the primary legal framework governing VAT across all EU member states. It defines the rules for taxable persons, taxable transactions, the place of supply, VAT rates, exemptions, and the reverse charge mechanism. Compliance with the VAT Directive is a legal obligation for businesses selling across EU borders.

EU Council Directive 2006/112/EC (commonly called 'the VAT Directive') is the primary legal text governing VAT across all 27 EU member states. It defines who is a taxable person, what constitutes a taxable supply, how to determine where a supply takes place (the 'place of supply' rules), which supplies are exempt, what VAT rates apply, and how the reverse charge mechanism works. National VAT laws across the EU implement this Directive — Germany's Umsatzsteuergesetz (UStG), France's Code général des impôts, and the UK's pre-Brexit VAT Act are all implementations of the same underlying framework.

## Key Articles for SaaS and Digital Services

## Article 138: The VAT Validation Requirement

Article 138 is the provision most directly relevant to VAT number validation. It requires that for a cross-border B2B supply to qualify for zero-rate treatment, the supplier must have 'taken reasonable steps to ensure that the customer is a taxable person'. In practice, 'reasonable steps' means querying VIES to verify that the customer's VAT number is currently registered — not just accepting the number the customer provides. Without this verification, zero-rating is not legally justified and the seller bears the VAT liability.

The [TaxID API](/vat-api) queries the live VIES registry in real time and returns a request_id that can be used as evidence of due diligence. Storing the API response — status, company name, address, and request_id — with each zero-rated invoice creates the documentation required by Article 138 in the event of a tax audit.

---

# Blog

## Check EORI Number by Company Name: A 2026 Guide
https://www.taxid.dev/blog/check-eori-number-by-company-name · 2026-08-13

Learn how to check EORI number by company name quickly. Verify EU customs registrations, avoid delays, and ensure compliance with our expert guide.

---

## Switzerland VAT Number Validation for Developers
https://www.taxid.dev/blog/switzerland-vat-number-validation · 2026-08-12

Switzerland VAT number validation for developers. Format rules, regex, API calls, Node.js and Python code, caching, and checkout integration.

---

## Company Registration Number Verification: A Practical Guide
https://www.taxid.dev/blog/company-registration-number-verification · 2026-08-11

Master company registration number verification with API examples, format validation, and caching strategies for SaaS billing flows.

---

## Cross Border VAT Rules Explained for SaaS Developers
https://www.taxid.dev/blog/cross-border-vat-rules · 2026-08-10

Learn cross border vat rules and how SaaS developers can validate VAT IDs, apply reverse charge, and integrate TaxID with Stripe for compliant checkout flows.

---

## Sample ABN Number: Format, Validation, and Safe Examples
https://www.taxid.dev/blog/sample-abn-number · 2026-08-09

Learn the correct format for a sample ABN number, how to validate it, and see safe examples to use in testing or documentation.

---

## Company Tax ID Lookup: A Developer Guide to EU VAT
https://www.taxid.dev/blog/company-tax-id-lookup · 2026-08-08

Learn how to use a company tax ID lookup to validate EU VAT numbers with our developer guide. Simplify compliance and reduce errors in 2026.

---

## Tax ID Search Florida
https://www.taxid.dev/blog/tax-id-search-florida · 2026-08-07

Master your tax ID search Florida workflow with official sites like Sunbiz and DOR, plus tips for automating EIN lookups.

---

## Tax ID Lookup Nonprofit: A Practical Verification Guide
https://www.taxid.dev/blog/tax-id-lookup-nonprofit · 2026-08-06

Learn how to verify nonprofit tax IDs across the US, EU, and beyond. Step-by-step tax id lookup nonprofit checks with real APIs and code samples.

---

## Resale Tax ID Lookup: The Developer's Complete Guide
https://www.taxid.dev/blog/resale-tax-id-lookup · 2026-08-05

Learn how to perform a resale tax id lookup across US states and EU markets. Step-by-step guide with manual checks and API integration patterns.

---

## VAT Compliance Checklist: Build a Resilient Billing System
https://www.taxid.dev/blog/vat-compliance-checklist · 2026-08-04

Use our developer-friendly VAT compliance checklist to handle ID validation, invoicing, and OSS rules for 2026. Simplify your billing today.

---

## Tax ID Lookup Free
https://www.taxid.dev/blog/tax-id-lookup-free · 2026-08-03

Learn how to perform a tax ID lookup free with public registries, APIs, and code examples for resilient VAT and EIN validation in SaaS billing.

---

## How to Check Company Tax Number: Easy Guide
https://www.taxid.dev/blog/check-company-tax-number · 2026-08-02

Learn how to check company tax number with our step-by-step guide. Verify VAT and tax IDs easily.

---

## VAT in Switzerland: A Developer's Guide to Rates and Billing
https://www.taxid.dev/blog/vat-in-switzerland · 2026-08-01

Practical guide to VAT in Switzerland for developers: rates, registration, SaaS rules, reverse charge, and validation APIs for reliable billing.

---

## Goods and Service Tax Status Explained for SaaS Billing
https://www.taxid.dev/blog/goods-and-service-tax-status · 2026-07-31

Learn what goods and service tax status means, how to check it, and how to wire it into your SaaS checkout, invoicing, and reverse-charge flows.

---

## Intra Community VAT Number UK: Post-Brexit Guide
https://www.taxid.dev/blog/intra-community-vat-number-uk · 2026-07-30

Learn how intra community VAT number UK rules work after Brexit, including Northern Ireland exceptions and reverse charge logic.

---

## EORI Number Validation: Regex & API Guide 2026
https://www.taxid.dev/blog/eori-number-validation · 2026-07-29

Master EORI number validation with regex patterns, routing logic, and code samples. Learn client-side checks, server-side fallbacks, and reliable API

---

## VAT Rate in Switzerland: 2026 Guide & Thresholds
https://www.taxid.dev/blog/vat-rate-in-switzerland · 2026-07-28

Learn the current VAT rate in Switzerland (8.1%), reduced and accommodation rates, the CHF 100,000 threshold, and SaaS/e-commerce compliance.

---

## EU VAT No Check Explained for Developers
https://www.taxid.dev/blog/eu-vat-no-check · 2026-07-27

EU VAT no check meaning explained for devs. Learn how VIES works, why checks fail, and how to build resilient VAT validation into checkout flows.

---

## VAT Calculator Italy: Rates, Formulas & Integration
https://www.taxid.dev/blog/vat-calculator-italy · 2026-07-26

Use our vat calculator italy to master Italian VAT. Learn IVA rates, reverse charge rules, and integrate automated validation for your checkout.

---

## VAT Number GB
https://www.taxid.dev/blog/vat-number-gb · 2026-07-25

Vat number gb - Learn how to validate a GB VAT number with format rules, HMRC checks, and code examples for Node.js, Python, and Stripe

---

## VAT in Hungary: Rates, Registration, and Validation
https://www.taxid.dev/blog/vat-in-hungary · 2026-07-24

A practical guide to VAT in Hungary covering the 27% standard rate, registration thresholds, and VIES validation for developers.

---

## Are Tax ID Numbers Public a Developer's Guide
https://www.taxid.dev/blog/are-tax-id-numbers-public · 2026-07-23

Find out are tax id numbers public in your jurisdiction, how public access works, and best practices to validate and store TaxID securely.

---

## Invoice Legal Requirements UK: Your 2026 Compliance Guide
https://www.taxid.dev/blog/invoice-legal-requirements-uk · 2026-07-22

Discover the complete invoice legal requirements uk for 2026. Learn mandatory fields, VAT rules, and automate compliance for B2B SaaS and developers with our

---

## What Is VAT Compliance: SaaS & E-commerce Guide 2026
https://www.taxid.dev/blog/what-is-vat-compliance · 2026-07-21

Learn what is vat compliance for SaaS & e-commerce in 2026. This guide covers reverse charge, VIES, risks, and a technical checklist for developers.

---

## How to Find EU VAT Number: A Developer's Guide 2026
https://www.taxid.dev/blog/find-eu-vat-number · 2026-07-20

Learn how to find EU VAT number with manual VIES lookups & reliable API validation. Covers caching, error handling, & Node.js/Python examples for 2026.

---

## Tax ID Lookup Ohio: Your 2026 Business Guide
https://www.taxid.dev/blog/tax-id-lookup-ohio · 2026-07-19

Need to do a tax id lookup ohio? Our 2026 guide helps you find any business tax ID, use the Secretary of State search, verify EINs, and request W-9s for

---

## What Is Company Identification Number: 2026 Guide
https://www.taxid.dev/blog/what-is-company-identification-number · 2026-07-18

Learn what is company identification number and its critical role in 2026 EU SaaS billing. Explore formats, validation, and API compliance.

---

## Validate Tax ID Number: A Developer's 2026 Guide
https://www.taxid.dev/blog/validate-tax-id-number · 2026-07-17

Validate tax ID number with our 2026 developer's guide. Learn modern REST API usage, format checks, caching, Stripe integration, & VIES outage handling with

---

## Sales Tax Netherlands: 2026 VAT Compliance Guide
https://www.taxid.dev/blog/sales-tax-netherlands · 2026-07-16

Your guide to sales tax netherlands (BTW). Understand 2026 VAT rates, registration, reverse-charge, and automate compliance for your billing systems.

---

## Italy VAT Rate: A SaaS Guide for 2026
https://www.taxid.dev/blog/italy-vat-rate · 2026-07-15

Your guide to the Italy VAT rate in 2026. Learn the standard & reduced rates, B2B reverse charge rules for SaaS, and how to validate Italian VAT IDs.

---

## Tax ID Lookup Washington State: 2026 Guide
https://www.taxid.dev/blog/tax-id-lookup-washington-state · 2026-07-14

Perform a precise tax id lookup washington state in 2026. Our guide details UBI vs. EIN, using state databases, and steps if a business is unlisted.

---

## Developers' 2026 Guide to E Invoice Compliance
https://www.taxid.dev/blog/e-invoice-compliance · 2026-07-13

Learn about e invoice compliance for developers in 2026. Explore EU standards, validation, API integration, and handling VIES outages. Stay compliant!

---

## What Is a Tax Identification Number? TINs & VAT IDs
https://www.taxid.dev/blog/what-is-a-tax-identification-number · 2026-07-12

Discover what is a tax identification number (TIN), how EU VAT IDs function, and why validation is crucial for B2B invoicing, checkouts, and compliance in 2026.

---

## Developer's Guide to Check Vat Number in Uk 2026
https://www.taxid.dev/blog/check-vat-number-in-uk · 2026-07-11

Need to check vat number in uk? Validate VAT numbers using HMRC tools & APIs. Essential guide for compliant SaaS billing in 2026.

---

## MwSt in Germany: A Developer's Guide to VAT Compliance
https://www.taxid.dev/blog/mwst-in-germany · 2026-07-10

A developer's guide to MwSt in Germany. Learn VAT rates, B2B/B2C rules, reverse charge, and how to automate ID validation in your SaaS checkout.

---

## A Guide on How to Get Vat No for SaaS & E-commerce
https://www.taxid.dev/blog/how-to-get-vat-no · 2026-07-09

Learn how to get vat no for your business. Our guide covers EU & UK thresholds, registration steps, required documents, and when you can skip it.

---

## England VAT Tax: A Developer's Guide for 2026
https://www.taxid.dev/blog/england-vat-tax · 2026-07-08

Your guide to England VAT tax for SaaS and e-commerce. Understand rates, registration, reverse charge, and how to automate UK VAT validation for 2026.

---

## A Developer's Guide to Tax Number Lookup
https://www.taxid.dev/blog/tax-number-lookup · 2026-07-07

Learn how to implement a reliable tax number lookup for EU VAT and beyond. A developer's guide to VIES, reverse charge, and building resilient billing systems.

---

## Business Address Lookup API: KYC & Billing in 2026
https://www.taxid.dev/blog/business-address-lookup-api · 2026-07-06

Learn how a business address lookup API works for KYC & billing. Choose the right service to avoid VIES compliance pitfalls in 2026.

---

## Mastering UK Sales Tax (VAT) for SaaS in 2026
https://www.taxid.dev/blog/uk-sales-tax · 2026-07-05

A guide to UK sales tax (VAT) for SaaS. Learn 2026 registration, B2B reverse charge, & compliant checkout flows with code examples.

---

## Check Your GST Application Status in Under 2 Minutes
https://www.taxid.dev/blog/gst-application-status · 2026-07-04

Anxious about your GST application status? Learn how to track it on the portal with your ARN, understand what each status means, and fix common delays.

---

## What Is Acn Number: Your 2026 Australian Guide
https://www.taxid.dev/blog/what-is-acn-number · 2026-07-03

Wondering what is acn number in Australia for 2026? Our guide defines ACN, compares it to ABN, & shows verification for compliant B2B SaaS billing.

---

## Tax Compliance Automation for SaaS Developers
https://www.taxid.dev/blog/tax-compliance-automation · 2026-07-02

Learn tax compliance automation for SaaS. This guide covers system architecture, API integration, EU VAT, reverse charge, and vendor selection for developers.

---

## TVA in Switzerland: A Developer's Guide to Swiss VAT
https://www.taxid.dev/blog/tva-in-switzerland · 2026-07-01

A developer-friendly guide to TVA in Switzerland. Learn Swiss VAT rates, registration, B2B/B2C rules, and how to programmatically validate VAT numbers.

---

## Build a Robust VAT Number Validator: A Developer's Guide
https://www.taxid.dev/blog/vat-number-validator · 2026-06-30

Build a robust VAT number validator. Handle format checks, VIES lookups, outages, and integrate with Node.js, Python & Stripe.

---

## Tax ID Lookup for Providers: API Guide 2026
https://www.taxid.dev/blog/tax-id-lookup-for-providers · 2026-06-29

Guide to tax id lookup for providers using TaxID API. Validate EU VAT numbers with Node.js/Python, handle errors, & integrate with Stripe.

---

## Build a VAT Converter Online: A Developer's Guide
https://www.taxid.dev/blog/vat-converter-online · 2026-06-28

Learn to build a robust VAT converter online for your app. This guide covers calculations, rate lookups, VAT ID validation with TaxID, and Stripe integration.

---

## Mastering Stripe Checkout VAT: EU Validation Guide for 2026
https://www.taxid.dev/blog/stripe-checkout-vat · 2026-06-27

Master EU VAT validation using stripe checkout vat. This guide covers reverse charge, Node.js/Python implementation, and handling VIES outages efficiently.

---

## VAT Number Verification: A Developer's Guide for 2026
https://www.taxid.dev/blog/vat-number-verification · 2026-06-26

Learn how VAT number verification works, from VIES and DAC7 compliance to building a resilient system with Node.js/Python. A complete guide for developers.

---

## VAT Tax Sweden: Your 2026 Ultimate Guide
https://www.taxid.dev/blog/vat-tax-sweden · 2026-06-25

Get your complete 2026 guide to vat tax sweden. Learn about VAT rates, registration, reverse charge for SaaS, and how to validate VAT IDs with an API.

---

## The Developer's Guide to Reverse Charge VAT
https://www.taxid.dev/blog/reverse-charge-vat · 2026-06-24

Learn how reverse charge VAT works for B2B transactions in the EU and UK. A practical guide for developers on validation, invoicing, and error handling.

---

## Tax ID Verification Online: Developer Guide 2026
https://www.taxid.dev/blog/tax-id-verification-online · 2026-06-23

Implement robust tax ID verification online. Our developer guide covers programmatic validation, error handling, caching, and Node.js/Python examples.

---

## Value Added Tax Germany: Developer's 2026 Guide
https://www.taxid.dev/blog/value-added-tax-germany · 2026-06-22

Explore value added tax germany for developers. Learn about 2026 VAT rates, reverse-charge, USt-IdNr validation, and B2B SaaS implementation.

---

## How to Validate Company Registration Number: A Dev Guide
https://www.taxid.dev/blog/validate-company-registration-number · 2026-06-21

Learn how to validate company registration number with a resilient API. A step-by-step developer guide for EU/UK validation using Node.js & Python examples.

---

## VAT Registration Number Switzerland: 2026 Ultimate Guide
https://www.taxid.dev/blog/vat-registration-number-switzerland · 2026-06-20

Master your vat registration number switzerland with our 2026 guide. Learn correct format, verification, registration rules, and integration for Swiss UID

---

## Validate VAT Number VIES: Official Tool & API Guide 2026
https://www.taxid.dev/blog/vat-number-vies · 2026-06-19

Validate your vat number vies using the official tool and SOAP API. Our guide covers common failures, caching, and why modern APIs are better in 2026.

---

## VAT Validation UK for Developers: HMRC & Post-Brexit Rules
https://www.taxid.dev/blog/vat-validation-uk · 2026-06-18

Guide to VAT validation UK for developers. Learn post-Brexit rules, query HMRC, and build a production-ready system with Node.js/Python examples.

---

## How Much Is the VAT in UK 2026: Dev Guide
https://www.taxid.dev/blog/how-much-is-the-vat-in-uk · 2026-06-17

Discover how much is the vat in uk (standard rate 20%) in 2026. Get our developer guide to VAT registration, SaaS billing, reverse charges, and API validation.

---

## Validate European VAT Number: Developer Guide 2026
https://www.taxid.dev/blog/validate-european-vat-number · 2026-06-16

Validate European VAT number with this guide. Handle VIES outages, caching, client/server logic using Node.js/Python & a modern API.

---

## Tax Identification Number Switzerland
https://www.taxid.dev/blog/tax-identification-number-switzerland · 2026-06-15

Learn about the tax identification number switzerland, including UID, AHV, and VAT formats. Get a clear guide to validate them for B2B billing in 2026.

---

## EU VAT Identification Number: Guide & Automation 2026
https://www.taxid.dev/blog/eu-vat-identification-number · 2026-06-14

Your complete guide to the EU VAT identification number. Master country formats, VIES validation, reverse charge rules, and automate checks in your app.

---

## VAT Number Format a Developer's Reference Guide
https://www.taxid.dev/blog/vat-number-format · 2026-06-13

A complete developer's guide to the VAT number format for every EU country, UK, CH, NO, & AU. Includes regex, examples, and a robust validation workflow.

---

## Real-time Business Registration Number Lookup API Guide 2026
https://www.taxid.dev/blog/business-registration-number-lookup · 2026-06-12

Perform a real-time business registration number lookup with our REST API. This developer guide covers EU VIES, Node.js/Python, and error handling.

---

## B2B Invoice VAT Automation: Number Validation for ERP Systems
https://www.taxid.dev/blog/b2b-invoice-vat-automation · 2026-06-12

Automate EU VAT number validation in ERP invoice workflows: validate at vendor onboarding, verify on invoice receipt, handle bulk imports, and build an audit trail for tax compliance.

B2B invoice workflows require VAT validation in two directions: validating your customers' VAT numbers before issuing zero-rated sales invoices, and validating your vendors' VAT numbers before accepting their input VAT claims on purchase invoices. Both use the same TaxID API endpoint, but the compliance risk and the business logic on failure differ. This guide covers both, plus the bulk validation patterns needed for ERP integration.

## Outbound Invoices: Validating Your Customers

For sales invoices applying zero-rate (reverse charge), validate the customer's VAT number before creating the invoice. This validation result is the legal basis for the zero-rate treatment — store the `request_id` from the API response alongside the invoice record.

## Inbound Invoices: Validating Your Vendors

When a vendor sends you a VAT invoice, validating their VAT number serves two purposes: confirming they are entitled to charge VAT (so your input VAT deduction is valid) and detecting fraudulent invoices. If a vendor's VAT number is inactive or format-invalid, do not pay the VAT portion until they resolve the registration issue.

## Bulk Validation for ERP Imports

ERP systems often import vendor and customer lists from CSV. For bulk validation at import time, use the TaxID batch endpoint which validates up to 500 numbers per request. This avoids rate limit issues from calling individual validation endpoints for each record.

---

## Canadian Business Number (BN) API: Tax ID Validation Guide
https://www.taxid.dev/blog/canada-business-number-api · 2026-06-12

Validate Canadian Business Numbers (BN) and GST/HST registration numbers using the TaxID API. Covers BN format, GST/HST account numbers, and code examples.

Canada uses a Business Number (BN) system administered by the Canada Revenue Agency (CRA). A BN is a 9-digit identifier assigned to businesses for federal tax purposes. When a business registers for GST/HST, they get a 15-character Program Account Number: the 9-digit BN followed by a 2-letter program identifier (RT for GST/HST) and a 4-digit reference number. The TaxID API validates Canadian business numbers against CRA's Business Registry.

## Canadian Tax ID Formats

## Validating Canadian Business Numbers

## GST/HST and Provincial Sales Tax

Canada has two levels of sales tax: federal GST (5%) and provincial HST or PST depending on the province. Provinces with HST (Ontario, New Brunswick, Nova Scotia, Prince Edward Island, Newfoundland) collect both in a single tax. Provinces with PST (British Columbia, Saskatchewan, Manitoba) collect them separately. The TaxID API validates GST/HST registration at the federal level — provincial tax registration is a separate system.

> For digital services sold to Canadian businesses: B2B digital services between registered businesses are generally zero-rated under the GST/HST rules for intangible personal property. Validate the Canadian business's BN to confirm registration before applying zero-rate.

---

## India GSTIN Validation API: GST Number Verification for Developers
https://www.taxid.dev/blog/india-gstin-validation-api · 2026-06-12

Validate Indian GSTIN (Goods and Services Tax Identification Number) using the TaxID API. Covers GSTIN format, state codes, registration types, and code examples.

India's GST system uses a GSTIN (Goods and Services Tax Identification Number) — a 15-character alphanumeric tax ID assigned to every GST-registered business. Unlike EU VAT numbers, a GSTIN encodes state-level information and the registrant's PAN (Permanent Account Number), making format validation more complex. The TaxID API validates GSTINs against the GSTN (Goods and Services Tax Network) and returns the registered business name and state.

## GSTIN Format

A GSTIN is always 15 characters in the format: 2-digit state code + 10-character PAN + 1-digit entity number + 1 letter Z (always Z) + 1 check digit.

## Common State Codes

---

## Marketplace Seller VAT Verification: Onboarding Compliance Guide
https://www.taxid.dev/blog/marketplace-seller-vat-onboarding · 2026-06-12

Verify EU VAT numbers during marketplace seller onboarding. Covers DAC7 obligations, batch validation of existing sellers, periodic re-checks, and the audit trail you need for compliance.

DAC7 (Council Directive 2021/514/EU) requires digital platforms and marketplaces to collect, verify, and report seller information — including VAT registration — to EU tax authorities. From 1 January 2023, covered platforms must validate and report seller tax IDs annually, with retroactive reporting obligations for pre-existing sellers. A VAT validation API is the technical tool that makes this obligation automatable at scale.

## What DAC7 Requires From Marketplaces

- Collect VAT number (and TIN/tax identification number) from every EU-resident seller at onboarding.
- Verify the VAT number is valid at the time of collection.
- Perform annual re-validation and report inactive numbers to the relevant tax authority.
- Withhold first payment to new sellers until VAT number is validated (for platforms that handle payment flows).
- Store the validated VAT number, company name, registered address, and the date of validation for at least 7 years.

## Onboarding Validation Flow

## Annual DAC7 Re-validation Batch

---

## SaaS Billing VAT Compliance: Automate B2B Tax ID Verification
https://www.taxid.dev/blog/saas-billing-vat-compliance-guide · 2026-06-12

Complete guide to automating EU VAT compliance in SaaS billing: validate at signup, re-validate on invoice, store the audit trail, and handle subscription edge cases.

SaaS companies selling to EU businesses face a VAT compliance challenge that does not exist for one-time e-commerce: the subscription relationship outlasts any single VAT validation. A customer whose VAT number was valid at signup may have their registration cancelled six months later. The correct architecture validates at signup, re-validates before each invoice, stores a full audit trail, and handles all edge cases — plan upgrades, dunning periods, cancelled subscriptions — without creating tax liabilities.

## The SaaS VAT Compliance Lifecycle

## Signup Flow

## Pre-Invoice Re-validation

## Handling Subscription Edge Cases

- Dunning: Re-validate before each retry invoice. A lapsed VAT registration during a failed payment period means the retry invoice should include VAT.
- Plan upgrade mid-cycle: A prorated invoice is a separate taxable supply. Re-validate before generating the upgrade invoice.
- VAT number change: When a customer updates their VAT number, immediately validate the new number and update the Stripe customer's tax_exempt status. Log the change with both old and new numbers.
- Deregistration during a billing cycle: If re-validation detects an inactive VAT number mid-cycle, flag for finance review. Do not retroactively change previous invoices — they were correctly zero-rated when issued.

---

## How to Test Your VAT API Integration: Mocking & Staging Guide
https://www.taxid.dev/blog/vat-api-testing-guide · 2026-06-12

Test all four VAT API status codes reliably without real API calls. Covers mock strategies in Node.js, Python, PHP, and Go, plus test VAT numbers and staging environment setup.

Your VAT API integration has four distinct code paths — one for each status code. Without a deliberate testing strategy, most codebases only test the happy path (`active`) and discover the `service_unavailable` handling is broken when VIES actually goes down in production. This guide covers how to test all four paths without making real API calls.

> TaxID provides test API keys (`vat_test_...`) that return predictable responses without consuming your monthly quota. Use your test key in CI/CD and local development, your live key only in production.

## Test VAT Numbers

When using a test API key, send specific VAT numbers to trigger each response state:

## Node.js / TypeScript: Mock with Vitest

## Python: Mock with unittest.mock

## Testing the Full Checkout Flow

Unit tests for the API call function are necessary but not sufficient. Also write integration tests that exercise your full checkout or invoice creation flow with each status code. These tests should verify that: (1) `active` results in zero-rate applied and company name stored; (2) `inactive` returns a user-facing validation error; (3) `service_unavailable` charges standard VAT and queues for re-validation; (4) network errors do not crash the checkout.

---

## VAT API Error Handling: Timeouts, Fallbacks & Retry Strategies
https://www.taxid.dev/blog/vat-api-error-handling-guide · 2026-06-12

Production-ready error handling for VAT API integrations: request timeouts, VIES service_unavailable fallback, retry logic, circuit breakers, and monitoring patterns.

VAT API errors fall into two categories: errors you can tell the user about (bad input), and errors that require a fallback strategy (infrastructure failures). The most common mistake is treating all errors the same — either blocking the user for everything or allowing everything through. The right approach is to be strict about user input errors and graceful about infrastructure failures.

## The Four Things That Can Go Wrong

## Setting Request Timeouts

Always set an explicit timeout on VAT API calls. VIES queries member states in real time, and some member states respond slower than others. The TaxID API itself has a 10-second internal timeout per VIES request. Set your timeout to 6-7 seconds — long enough to succeed in almost all cases, short enough not to block your users for a noticeably long time.

## Retry Logic for Network Errors

Retry logic is appropriate for network errors (connection refused, DNS failure, timeout) but NOT for `service_unavailable` status from the API — VIES is down and retrying immediately will not help. Implement at most one retry with a 500ms delay for network-level errors only.

## The VIES Fallback Strategy

When `status === 'service_unavailable'`, you have three options ordered from safest to most convenient: (1) charge standard VAT and issue a credit note when VIES recovers; (2) store the VAT number as 'pending' and re-validate asynchronously before the next billing cycle; (3) apply zero-rate provisionally and document the 'good faith' attempt. For e-commerce one-time orders, option 1 is the only safe choice. For subscription billing, option 2 is standard practice.

## Monitoring VAT API Health

Track three metrics for VAT API calls: `service_unavailable` rate per hour (spikes indicate VIES outages), `format_invalid` rate (elevated rate may indicate a UX problem with your VAT input field), and p95 response time (should be under 100ms for cached results, under 3s for uncached). Alert on `service_unavailable` rate above 5% over a 15-minute window — that pattern usually indicates a specific EU member state is offline.

---

## VAT API .NET: ASP.NET Core Integration Guide
https://www.taxid.dev/blog/vat-api-dotnet-aspnet · 2026-06-12

Integrate EU VAT number validation into ASP.NET Core applications using IHttpClientFactory. Covers typed HttpClient, service registration, middleware, and xUnit tests.

ASP.NET Core's `IHttpClientFactory` is the recommended way to make HTTP calls from .NET services — it manages connection pooling, avoids socket exhaustion, and makes the HttpClient easy to mock in tests. This guide builds a typed `VatApiClient` class that wraps the TaxID API, registers it in the DI container, and wires it into a minimal API endpoint. For the use-case guide, see the [.NET VAT validation use case](/use-cases/dotnet-vat-validation).

## Response Model

## Typed HttpClient Service

## DI Registration in Program.cs

## xUnit Tests with Mocked HttpMessageHandler

---

## VAT API Ruby on Rails: Tax ID Validation for E-commerce
https://www.taxid.dev/blog/vat-api-ruby-on-rails · 2026-06-12

Integrate EU VAT number validation into Ruby on Rails applications. Covers Net::HTTP, a reusable service object, ActiveRecord storage, and RSpec test patterns.

Ruby on Rails handles the TaxID API call cleanly with either Net::HTTP from the standard library or the Faraday gem. This guide uses Net::HTTP so there are no additional dependencies. The pattern is a service object that is called from a controller concern — keeping the validation logic separate from your controller code and reusable across multiple controllers. For the use-case guide with step-by-step integration steps, see the [Ruby on Rails VAT validation use case](/use-cases/ruby-rails-vat-validation).

## VatValidationService

## Controller Concern

## Controller Usage

## RSpec Tests with WebMock

---

## E-commerce VAT Validation: Automate Tax ID Checks at Checkout
https://www.taxid.dev/blog/ecommerce-vat-validation-checkout · 2026-06-12

Add automated EU VAT number validation to e-commerce checkout flows. Covers B2B vs B2C detection, zero-rate application, VIES outage handling, and platform-specific patterns.

E-commerce platforms serving EU businesses must validate VAT numbers at checkout to legally apply zero-rate B2B exemptions. Unlike SaaS platforms that can re-validate on each invoice, e-commerce checkouts are one-shot transactions — the validation happens at the moment of purchase and the result determines the tax treatment on that specific order. Getting the checkout flow right the first time is therefore more critical than in a subscription billing context.

## B2B vs B2C Detection at Checkout

The first decision in any EU e-commerce checkout is whether the buyer is B2B or B2C. The simplest signal: is a VAT number provided? If yes, the buyer is claiming B2B status and you must validate the number. If no, treat as B2C and charge local VAT at the standard rate for the buyer's country.

## Checkout Flow for Custom E-commerce Backends

## Handling VIES Outages in E-commerce

> For e-commerce one-time orders (unlike subscriptions), you cannot issue a credit note if the VAT was wrongly charged. The safest approach when VIES is down: charge standard VAT, record the VAT number as 'pending revalidation', and contact the customer with a VAT credit note once VIES recovers and confirms the number.

## Platform-Specific Patterns

- Shopify: Use a Checkout UI Extension to add the VAT field; validate via a custom backend on checkout validation event. Store the result in customer metafields.
- WooCommerce: Use the woocommerce_checkout_process hook to validate the EU VAT field before order creation. Return a wc_add_notice error for invalid numbers.
- Magento 2: Create a custom observer on checkout_submit_before. Call the TaxID API from the observer and throw a LocalizedException for invalid numbers.
- Custom checkout: Call the TaxID API before persisting the order. Return a 422 with a user-facing error message for format_invalid and inactive; proceed with VAT applied for service_unavailable.

---

## Developer Guides: Integrating VAT Validation API into Your Stack
https://www.taxid.dev/blog/developer-guides-vat-api-integration · 2026-06-12

Index of all VAT validation API integration guides by language and framework: Node.js, Python, PHP, Go, Java, Ruby, React, Vue, Next.js, and more.

The TaxID VAT validation API uses a single REST endpoint that works from any language or framework. These guides show you the idiomatic pattern for each major stack — how to make the HTTP call, how to type the response, how to wire it into your framework's request/response lifecycle, and how to test it. All guides use the same API endpoint; only the language-specific wiring differs.

## Backend Languages

- [Node.js / TypeScript quick start](/blog/vat-api-nodejs-quickstart) — built-in fetch, Express route, TypeScript types
- [Node.js full tutorial](/blog/nodejs-eu-vat-validation-tutorial) — service class, Redis cache, Vitest tests
- [Python: Django & Flask](/blog/vat-api-python-django-flask) — httpx, DRF view, Flask blueprint, pytest
- [Python async guide](/blog/python-async-vat-validation) — asyncio, HTTPX async client, type annotations
- [PHP: Laravel & Symfony](/blog/vat-api-php-laravel-symfony) — Guzzle, service provider, DI service, PHPUnit
- [Go (Golang)](/blog/vat-api-go-high-performance) — net/http, sync.Map cache, HTTP handler
- [Java Spring Boot](/blog/vat-api-java-spring-boot) — RestTemplate, WebClient, Spring Cache, JUnit 5
- [Ruby on Rails](/blog/vat-api-ruby-on-rails) — Net::HTTP, service object, RSpec tests
- [.NET / C# ASP.NET Core](/blog/vat-api-dotnet-aspnet) — HttpClient, dependency injection, xUnit tests

## Frontend Frameworks

- [React: real-time B2B form validation](/blog/react-vat-validation-b2b-forms) — useVatValidation hook, debounce, company confirmation UI
- [Vue.js: Composition API](/use-cases/vue-vat-validation-guide) — composable, debounced input, server-side proxy
- [Next.js: App Router](/use-cases/nextjs-vat-api-server-client) — API route, Server Components, Server Actions

## Platform & Commerce Integrations

- [Stripe subscription billing](/blog/stripe-saas-vat-checkout-validation) — tax_exempt flag, webhook re-validation, audit trail
- [Stripe checkout (one-time)](/blog/stripe-eu-vat-validate-tax-ids) — validate before charge, credit note workflow
- [Shopify UK VAT](/use-cases/shopify-uk-vat) — checkout extension, webhook handler
- [WooCommerce EU VAT](/blog/woocommerce-eu-vat-validation) — checkout field, PHP integration

## Country-Specific Guides

- [UK VAT post-Brexit](/blog/uk-vat-api-post-brexit-guide) — HMRC validation, GB/XI prefixes
- [Australian ABN/GST](/blog/australian-abn-gst-validation-api) — ABR validation, GST registration
- [Norway MVA](/blog/norway-mva-vat-api-guide) — Brønnøysund register, MVA suffix
- [Switzerland UID](/blog/switzerland-uid-tax-id-api) — Federal Tax Administration, MWST registration
- [Germany](/blog/german-vat-number-validation), [France](/blog/french-vat-number-validation), [Italy](/blog/italian-vat-number-validation), [Spain](/blog/spanish-vat-number-validation), [Netherlands](/blog/netherlands-vat-number-validation), [Poland](/blog/polish-vat-number-validation)

## The Core API Call (Language-Agnostic)

All guides use the same endpoint. The country code is always the two-letter prefix at the start of the VAT number. The response always has the same four status values. The only thing that changes is how you make an HTTP GET request in your language of choice.

---

## Switzerland UID Validation API: Tax ID Checks for Swiss Businesses
https://www.taxid.dev/blog/switzerland-uid-tax-id-api · 2026-06-12

Validate Swiss UID (Unternehmens-Identifikationsnummer) numbers via the Federal Tax Administration using the TaxID API. Covers CHE format, MWST registration, and code examples.

Switzerland is not an EU member state and does not participate in VIES. Swiss businesses are identified by their UID (Unternehmens-Identifikationsnummer — business identification number), a 9-digit number prefixed with `CHE`. Swiss VAT is administered by the Federal Tax Administration (ESTV/AFC/AFC) and is called MWST/TVA/IVA depending on language. A business may have a UID without being MWST-registered — the TaxID API distinguishes between these cases.

## Swiss UID / MWST Format

## Validating a Swiss UID Number

## UID vs MWST Registration

Every Swiss company registered in the Commercial Register has a UID. Not every company with a UID is registered for MWST (Swiss VAT). A company only needs to register for MWST if their annual turnover exceeds CHF 100,000. The TaxID API returns `status: 'active'` only when the UID is active AND the company is registered for MWST. If the company has a valid UID but is not MWST-registered, it returns `status: 'inactive'`.

> Switzerland is not an EU member, so Swiss companies are third-country buyers for EU VAT purposes. EU reverse charge does not apply. If you sell goods to Swiss customers, apply your home country's export rules (typically zero-rate for goods, plus Swiss import VAT at the border). For digital services to Swiss B2C customers over CHF 100,000/year, you may need to register for Swiss VAT.

---

## Norway VAT Number (MVA) Validation API: Developer Guide
https://www.taxid.dev/blog/norway-mva-vat-api-guide · 2026-06-12

Validate Norwegian VAT numbers (MVA) via the Brønnøysund Register Centre using the TaxID API. Covers the NO format, MVA suffix, and code examples in Node.js and Python.

Norway is not an EU member state, so Norwegian VAT numbers are not part of the EU VIES system. They are registered with the Brønnøysund Register Centre (Brønnøysundregistrene) and are formally called MVA numbers (Merverdiavgiftsnummer). If your application accepts VAT numbers from B2B customers across Europe, you need a validation endpoint that handles `NO`-prefixed numbers separately from EU countries.

## Norwegian MVA Number Format

A Norwegian VAT number consists of an organisation number (9 digits) followed by the suffix `MVA`. The organisation number can be formatted with spaces (876 865 822) or without. When calling the TaxID API, pass the full number including the MVA suffix using the `NO` prefix.

## Validating a Norwegian VAT Number

## What the Response Means

`status: 'active'` means the organisation is registered for MVA in the Brønnøysund Register Centre. The `company_name` field returns the legal entity name from the register. For B2B transactions between a Norwegian business and an EU business, the Norwegian entity is treated as a third-country buyer and EU VAT rules for exports apply — Norwegian MVA validation is not the same as EU reverse charge.

> For EEA-related transactions: Norway is part of the European Economic Area (EEA) but not the EU. Norwegian businesses do not participate in EU VAT reverse charge. If you sell digital services to Norwegian consumers, you may need to register for Norwegian VAT under the VOEC scheme (Value Added Tax on Electronic Commerce) for sales over NOK 50,000/year.

---

## VAT API Java: Spring Boot Integration for Tax ID Validation
https://www.taxid.dev/blog/vat-api-java-spring-boot · 2026-06-12

Add EU VAT number validation to Spring Boot applications using RestTemplate or WebClient. Covers service layer, exception handling, caching with Spring Cache, and JUnit 5 tests.

Spring Boot applications have two options for calling the TaxID API: `RestTemplate` for synchronous, blocking calls in traditional MVC applications, and `WebClient` for reactive, non-blocking calls in Spring WebFlux projects. This guide covers both, along with Spring Cache integration to avoid redundant API calls and a JUnit 5 test suite. For the use-case guide with wiring steps, see the [Java Spring Boot VAT validation use case](/use-cases/java-spring-vat-validation).

## Response DTO

## VatValidationService with RestTemplate

## Spring Cache Configuration

## REST Controller

## JUnit 5 Tests with MockRestServiceServer

---

## VAT API Go (Golang): High-Performance Tax ID Validation
https://www.taxid.dev/blog/vat-api-go-high-performance · 2026-06-12

Integrate EU VAT number validation into Go applications. Covers net/http client, context timeouts, error handling, struct types, and a thread-safe cache using sync.Map.

Go's standard library handles HTTP calls without any third-party dependencies, making the TaxID API integration straightforward. The full implementation — struct types, HTTP client, context timeout, all error states, and a thread-safe in-memory cache — fits in a single file. For the use-case guide with step-by-step wiring, see the [Go VAT validation use case](/use-cases/go-vat-validation).

## Response Types

## HTTP Client

## Thread-Safe Cache with sync.Map

## HTTP Handler (net/http)

---

## Australian ABN Validation API: GST Number Verification Guide
https://www.taxid.dev/blog/australian-abn-gst-validation-api · 2026-06-12

Validate Australian ABN and GST numbers via the ABR (Australian Business Register) using the TaxID API. Covers ABN format, GST registration checks, and Node.js/Python code examples.

Australia does not use a VAT system — it uses GST (Goods and Services Tax) at a flat 10% rate. Australian businesses are identified by their ABN (Australian Business Number), an 11-digit number issued by the Australian Business Register (ABR). When a business registers for GST, their ABN becomes their GST identifier. To check whether an Australian business is GST-registered, you validate their ABN against the ABR — which is exactly what the TaxID API does for the `AU` country prefix.

## ABN Format

An ABN is always 11 digits. It is often displayed with spaces (51 824 753 556) or as a raw number (51824753556). Both formats are accepted by the TaxID API — spaces are stripped automatically. When building a form, validate that the input is 11 digits after removing spaces and non-numeric characters.

> When calling the TaxID API for Australian businesses, pass the `AU` prefix followed by the 11-digit ABN: `GET /validate/AU/AU51824753556`. The API handles spacing and formatting automatically.

## Validating an ABN in Node.js

## Validating an ABN in Python

## Understanding ABN Statuses

## ABN vs GST Registration: The Distinction

Not all businesses with an ABN are registered for GST. Businesses with annual turnover below AUD 75,000 are not required to register for GST (though they may do so voluntarily). A TaxID API response with `status: 'active'` confirms that the ABN is active AND the entity is registered for GST. If a business has an ABN but has not registered for GST, the API returns `status: 'inactive'` — in that case, you must charge GST on supplies to them, as they cannot claim it back.

## Storing Validation Results for Compliance

Australian tax law (A New Tax System (Goods and Services Tax) Act 1999) requires that you retain tax invoices and records supporting GST-free treatment. For B2B supplies, store the ABN, the validation result, and the `request_id` from the TaxID response alongside the invoice record. This is your evidence that the ABN was valid and GST-registered at the time of supply.

---

## UK VAT Validation API: Post-Brexit Tax ID Checks for Developers
https://www.taxid.dev/blog/uk-vat-api-post-brexit-guide · 2026-06-12

Validate UK VAT numbers (GB prefix) via HMRC after Brexit. Covers GB format, XI numbers for Northern Ireland, HMRC vs VIES differences, and code examples.

Before Brexit, UK VAT numbers were part of the EU VIES system and could be validated with the same SOAP call as any other EU country. Since 1 January 2021, UK VAT is administered by HMRC independently, and UK numbers no longer appear in VIES. If your code queries VIES for a `GB` number, it will return `format_invalid` or `service_unavailable`. You need a validation API that routes `GB` numbers to HMRC separately.

## UK VAT Number Format

UK VAT numbers follow the format `GB` followed by 9 digits. The 9-digit portion is structured as a 7-digit registration number followed by a 2-digit suffix. Branch traders also have a 3-digit branch identifier appended, giving 12 digits total. For most validation purposes, you only need the 9-digit version.

## The XI Prefix: Northern Ireland Special Case

Northern Ireland occupies a unique position post-Brexit: for trade in goods (not services), Northern Ireland businesses follow EU VAT rules and can be validated via a special `XI` prefix in VIES. This means a Northern Ireland company may have both a `GB` VAT number (for UK domestic trade and services) and an `XI` number (for intra-EU goods trade). When validating a Northern Ireland supplier or customer for EU goods transactions, use the `XI` number.

## Validating UK VAT Numbers via TaxID API

The TaxID API routes `GB` numbers to HMRC's VAT API and `XI` numbers to VIES automatically. The request format is identical to EU countries.

## What Changed After Brexit: VIES vs HMRC

## Making Tax Digital Compliance

HMRC's Making Tax Digital (MTD) for VAT programme requires businesses to keep digital records and submit VAT returns via compatible software. For B2B sellers, this means the VAT number used to justify a zero-rated supply must be recorded digitally in your VAT account. Storing the TaxID `request_id` alongside the transaction is best practice — it provides a digitally-traceable audit reference showing that validation occurred via an API call at a specific time.

> UK zero-rating for B2B supplies requires proof that the customer is a UK or EU VAT-registered business. For UK-to-UK supplies, the relevant rule is UK VAT Act 1994 s.30 and VAT Notice 700. For UK-to-EU supplies (goods), the export zero-rating rules under UK VAT Notice 703 apply.

---

## VAT API PHP: Tax ID Validation for Laravel & Symfony
https://www.taxid.dev/blog/vat-api-php-laravel-symfony · 2026-06-12

Integrate EU VAT number validation into PHP applications using Laravel service providers and Symfony services. Covers Guzzle, error handling, and PHPUnit test patterns.

This guide covers EU VAT number validation in PHP for two major frameworks: Laravel and Symfony. Both integrate the TaxID API using an HTTP client (Guzzle or Symfony HttpClient), but the wiring into the framework's service container and the patterns for using it in controllers differ. If you are using plain PHP without a framework, the standalone cURL function is the right starting point.

## Standalone PHP (No Framework)

## Laravel: Service Class and Provider

## Laravel Controller Usage

## Symfony: Dependency-Injected Service

## PHPUnit Tests

---

## VAT & Tax ID Validation API for Developers
https://www.taxid.dev/blog/vat-api-for-developers · 2026-06-12

Complete developer reference for the TaxID VAT validation API: endpoint format, authentication, response schema, all status codes, country coverage, and integration patterns.

The TaxID API validates VAT numbers, ABNs, and other tax IDs across 31+ countries via a single REST endpoint. This page is the quick-reference guide for developers: what the API accepts, what it returns, and how to handle every possible response. For step-by-step language-specific tutorials, see the Node.js, Python, PHP, and React guides linked at the bottom.

## Authentication

All requests require an API key passed in the `Authorization` header. Get your key from the [dashboard](/dashboard/keys) after signing up. There are two key types: live keys (`vat_live_...`) for production requests and test keys (`vat_test_...`) for development — test keys return predictable responses without consuming quota.

## Validate Endpoint

## Response Schema

## Status Code Reference

> All four statuses return HTTP 200. The `status` field in the body drives your application logic, not the HTTP status code. A 4xx or 5xx response indicates an API-level error (invalid key, malformed request, rate limit exceeded).

## Quick-Start Code

## Country Coverage

The API covers 31+ countries. EU countries are validated via VIES; non-EU countries via their respective national registries.

- EU (27 countries): AT, BE, BG, CY, CZ, DE, DK, EE, EL/GR, ES, FI, FR, HR, HU, IE, IT, LT, LU, LV, MT, NL, PL, PT, RO, SE, SI, SK
- United Kingdom: GB (HMRC) and XI (Northern Ireland)
- Australia: AU (Australian Business Register)
- Norway: NO (Brønnøysund Register Centre)
- Switzerland: CH (Federal Tax Administration UID)

## Rate Limits and Quotas

When you exceed the rate limit, the API returns HTTP 429. Cache results for 24 hours to reduce API calls — the TaxID API already caches at the infrastructure level, but caching in your own application reduces latency and protects your quota.

---

## Mastering EU VAT Compliance with a Real-time Validation API
https://www.taxid.dev/blog/eu-vat-compliance-realtime-api · 2026-06-12

How to use a real-time VAT validation API to meet EU VAT Directive requirements: validation at transaction time, audit trail, VIES downtime fallback, and record-keeping rules.

EU VAT Directive 2006/112/EC requires that a VAT number is valid at the time of supply for zero-rate treatment to apply. That phrase — 'at the time of supply' — is the reason 'validate at signup and cache forever' is legally insufficient. A company can be deregistered from VAT between their signup and their next invoice. If you apply zero-rate to that invoice without re-validating, the VAT liability falls on you, not your customer. A real-time validation API called at each transaction point is the correct architecture.

## What the EU VAT Directive Actually Requires

Article 138 of the Directive exempts intra-community supplies from VAT when the buyer is a taxable person — i.e., a business with a valid VAT number in another EU member state. Article 131 makes this conditional on the supplier having 'proof' that the conditions are met. Council Regulation 282/2011 Article 25 defines acceptable proof as including confirmation from VIES. This means a VIES query result, dated at or before the time of supply, is the document your tax authority will ask for in an audit.

> A VIES 'active' response is considered conclusive evidence of VAT registration under Article 31a of Council Regulation 282/2011. Store the `request_id` from every TaxID API call alongside your transaction record — this is your audit evidence.

## Validation Points in a SaaS Billing Lifecycle

## Real-time vs Cached Validation

For transaction-level compliance, 'real-time' means the validation result is fresh at the time of the invoice — not necessarily that you call the API at the millisecond the invoice is generated. A result from within the previous 24 hours is considered real-time for compliance purposes, because VIES itself does not update faster than that. This means you can cache validation results for up to 24 hours without compromising compliance, as long as the cached result was obtained at or before the time of supply.

## The Audit Trail Schema

Every validation call that results in a zero-rated invoice should produce an audit record. This is the database schema that satisfies most EU tax authority requirements:

## VIES Downtime and the 'Good Faith' Defence

When VIES returns `service_unavailable`, you have two compliant options: charge standard VAT and issue a credit note once VIES recovers, or apply zero-rate provisionally under the 'good faith' provisions of Article 138(1a) — which requires documenting that you attempted validation and the registry was unavailable. The TaxID API logs every `service_unavailable` response, and the `request_id` proves you attempted validation at a specific time.

> Log every `service_unavailable` response with timestamp, VAT number, and request_id. If you choose to apply zero-rate provisionally, this log is the evidence that your attempt was genuine and the unavailability was systemic, not a workaround.

---

## Stripe EU VAT: Seamless Validation for Your SaaS Checkout
https://www.taxid.dev/blog/stripe-saas-vat-checkout-validation · 2026-06-12

Integrate EU VAT validation into Stripe subscription billing. Covers zero-rate setup, tax_exempt flag, webhook re-validation, and handling VIES outages in SaaS checkout.

Stripe Tax handles VAT rate calculation and collection across 30+ countries automatically. What it does not do is check whether a customer's VAT number is real, currently registered, and belongs to the company that claims it. That gap creates a compliance liability: a buyer can enter any plausible-looking VAT number, and Stripe will zero-rate all their invoices without complaint. This guide shows how to close that gap with real-time VAT validation and wire it into Stripe's `tax_exempt` flag correctly for SaaS subscription billing.

> Applying reverse charge to an unverified VAT number creates a VAT liability that falls on your business, not the customer. If the number is invalid, you owe the full VAT amount on every zero-rated transaction. Validation is not optional.

## How Stripe Tax Exemption Works

Stripe's tax exemption model is simple: set `tax_exempt: 'reverse'` on the Stripe Customer object, and Stripe Tax will apply zero VAT to all invoices for that customer and add the 'Reverse charge' annotation required by EU invoice rules. Your job is to make sure this flag is only set when the VAT number has been independently validated.

## Checkout Flow for SaaS Subscriptions

For SaaS subscriptions, validate the VAT number before creating the Stripe Checkout session or before the first subscription invoice. Here is the full checkout flow with Stripe Checkout:

## Subscription Re-validation Job

VAT registrations change. Companies deregister, reorganise, or move jurisdictions. A number valid at signup may be invalid six months later. For subscription businesses, run a monthly background job that re-checks all customers with `tax_exempt: 'reverse'`.

## Handling VIES Outages at Checkout

> When VIES returns `service_unavailable`, charge standard VAT at checkout. Do not block the purchase. Store the VAT number in Stripe customer metadata with `vat_revalidate_needed: 'true'` and re-validate once VIES recovers. If the number is confirmed valid, issue a credit note for the VAT charged.

## Audit Trail Requirements

EU VAT compliance requires that you can prove a VAT number was valid at the time of each zero-rated invoice. Store the TaxID `request_id` in Stripe customer metadata — it uniquely identifies which API call validated the number and when. You can reference this ID if you are ever audited by a tax authority and need to prove the validation happened.

---

## Validate VAT Number API: How to Verify EU, UK, AU, CH, NO Tax IDs
https://www.taxid.dev/blog/validate-vat-number-api-eu-uk-au-ch-no · 2026-06-12

Complete guide to validating VAT and tax ID numbers across EU (all 27 countries), UK, Australia, Switzerland, and Norway using a single REST API endpoint.

Verifying a VAT or tax ID number across different countries means hitting a different national registry for each one: VIES for the EU, HMRC for the UK, the Australian Business Register for AU, the UID register for Switzerland, and the Brønnøysund Register Centre for Norway. The TaxID API provides a single endpoint with a consistent response format for all of them. This guide shows how to call it for each country and what to do with the result.

## The Universal Validation Endpoint

The endpoint structure is the same for every country. The `{country}` parameter is the two-letter prefix that appears at the start of the VAT number.

## EU: Validating All 27 Member States via VIES

All 27 EU member states are validated via VIES. The response includes the company name and address from the national tax authority. Use the country prefix from the VAT number itself — not the ISO country code, as Greece uses `EL` not `GR`.

## UK: Post-Brexit HMRC Validation

UK VAT numbers use the `GB` prefix followed by 9 digits. Since Brexit, they are validated against HMRC independently of VIES. Northern Ireland businesses trading in EU goods may have an `XI` prefix; these are also supported.

## Australia: ABN / GST Validation

Australian businesses use an ABN (Australian Business Number) — 11 digits. Use the `AU` prefix. An active ABN means the entity is registered with the Australian Business Register; GST registration is a separate status that is also returned in the response.

## Switzerland (UID) and Norway (MVA)

## Response Status Reference

## Multi-Country Validation Function

---

## VIES API Integration: A RESTful Guide for Developers
https://www.taxid.dev/blog/vies-api-integration-restful-guide · 2026-06-12

How to integrate EU VAT validation via VIES using a REST API instead of raw SOAP. Covers request format, response parsing, error handling, and production caching strategy.

VIES — the EU's VAT Information Exchange System — is the authoritative source for EU VAT number validation. It is operated by the European Commission and queries each EU member state's national tax authority in real time. The catch: VIES exposes a SOAP/XML interface that was designed in the early 2000s and has not been modernised. Parsing SOAP envelopes, handling XML namespaces, managing member-state-level outages, and building retry logic takes days of work. A REST wrapper like the TaxID API abstracts all of that into a single JSON endpoint.

## How the REST Wrapper Works

When you call `GET https://taxid.dev/api/v1/validate/DE/DE123456789`, the API does the following: it validates the format against the country's VAT number specification, checks an internal cache for a recent result, and if there is no cached result, it calls the VIES SOAP endpoint for the `DE` member state. The SOAP response is parsed, normalised into a consistent JSON structure, cached for up to 23 hours (matching the VIES cache window), and returned as JSON.

## Making Your First VIES Validation Call

## All 27 EU Member State Prefixes

> Greece uses the prefix `EL`, not `GR`. Sending `GR` will return `format_invalid`. The TaxID API accepts both `EL` and `GR` and normalises automatically, but if you are building your own routing logic, use `EL`.

## Handling VIES Status Codes

VIES can return different fault codes for different conditions. The TaxID REST wrapper normalises all of these into four clean status values:

## Caching Strategy for Production

VIES itself caches results for up to 23 hours — validated numbers do not change status within a day. The TaxID API mirrors this cache window. For production applications, add a second layer of caching in your own infrastructure to avoid re-calling the API for the same VAT number within a 24-hour window.

---

## Tax ID Validation API: Global Coverage Beyond EU VIES
https://www.taxid.dev/blog/tax-id-validation-api-global-coverage · 2026-06-12

Validate tax IDs across 31+ countries including EU (via VIES), UK (HMRC), Australia (ABR/ABN), Norway (MVA), and Switzerland (UID) with a single REST API.

Most VAT validation APIs only cover the EU via VIES. But if you sell SaaS globally, your B2B customers are not only in the EU — they are also UK businesses with GB VAT numbers, Australian companies with ABNs, Norwegian firms with MVA numbers, and Swiss companies with UID numbers. Building separate validation integrations for each country is expensive and hard to maintain. The TaxID API covers all of them through a single REST endpoint using the same request/response format.

## Country Coverage at a Glance

> Greece uses the prefix `EL` in VIES (not `GR`). The TaxID API handles this automatically — you can send either `EL` or `GR` and the API normalises it correctly.

## Single API Call for Any Country

The endpoint format is identical regardless of country. Extract the two-letter prefix from the VAT number, pass it as the country parameter, and the API routes the request to the correct registry automatically.

## EU VAT Numbers (27 Countries via VIES)

All 27 EU member states are validated via the VIES system operated by the European Commission. VIES returns the company name and address from the member state's national tax authority — this data is authoritative for invoice compliance. The `service_unavailable` status occurs when a member state's VIES node is temporarily offline, which happens for some countries more frequently than others.

## UK VAT Numbers (HMRC)

Since Brexit, UK VAT numbers are no longer part of VIES. They are validated against HMRC's API independently. UK VAT numbers follow the format `GB` + 9 digits. Northern Ireland businesses that trade in goods within the EU may also have `XI`-prefixed numbers for intra-EU supply purposes.

## Australian ABN / GST Numbers

Australian businesses are identified by their ABN (Australian Business Number) — an 11-digit number that also serves as their GST registration identifier. Use the prefix `AU` followed by the 11-digit ABN. The API validates against the Australian Business Register (ABR), which returns the entity's registered name and ABN status.

## Norway MVA and Switzerland UID

## Detecting Country from VAT Input

For UI forms that accept VAT numbers from customers in any country, detect the country from the input and show the correct format hint.

---

## React VAT Validation: Real-time Checks for B2B Forms
https://www.taxid.dev/blog/react-vat-validation-b2b-forms · 2026-06-12

Build real-time EU VAT validation into React B2B checkout forms. Custom hook, debounced input, company name confirmation, and server-side proxy pattern.

B2B checkout forms have a UI requirement that B2C forms do not: after a customer enters their VAT number, you need to show them the registered company name and address so they can confirm the number is correct before completing the purchase. This guide builds that exact pattern in React — a reusable `useVatValidation` hook, a debounced input component, and a company confirmation UI — backed by a server-side proxy so your TaxID API key never reaches the browser.

> Never call the TaxID API directly from browser JavaScript. Your API key would be visible in network requests. Always proxy through a backend endpoint — the server-side proxy section below shows how.

## Server-Side Proxy: Next.js API Route

Create a thin API route on your server that accepts the VAT number and calls TaxID. This keeps your API key server-side and gives you a place to add rate limiting or logging.

## useVatValidation Hook

The hook manages the three states a VAT field can be in: idle (user hasn't typed yet or cleared), loading (API call in flight), and resolved (a result is ready). It debounces the input by 600ms to avoid an API call on every keystroke.

## VatInput Component with Inline Feedback

The input component consumes the hook and renders appropriate inline feedback for each phase. The company name and address are shown on successful validation so the customer can verify the entry before submitting.

## Integrating Into a Checkout Form

> Reset `vatNumber` state to `null` if the user clears the VAT input after it was valid. Otherwise a partial edit leaves stale validated data attached to the order.

---

## VAT API Python: Integrating Tax ID Validation with Django & Flask
https://www.taxid.dev/blog/vat-api-python-django-flask · 2026-06-12

Add EU VAT number validation to Django REST Framework views and Flask blueprints using the TaxID API. Covers httpx, error handling, and pytest test patterns.

This guide covers two Python web frameworks: Django REST Framework for teams building API-first products, and Flask for lighter microservice or webhook-handler use cases. Both use the same TaxID API endpoint. The difference is how validation fits into your framework's request/response lifecycle. For the async-first Python implementation using asyncio and HTTPX, see the [Python async VAT validation guide](/blog/python-async-vat-validation).

## Setup: Install Dependencies and Configure API Key

## Base Validation Function

A standalone function that both Django and Flask can import. Returns a typed dict rather than raising exceptions for known error states — this keeps controller code clean and makes all outcomes explicit.

## Django REST Framework Integration

Add VAT validation to a Django REST Framework checkout or B2B signup view. The `VatValidationMixin` pattern keeps validation logic out of view methods and reusable across multiple endpoints.

## Flask Blueprint Integration

For Flask applications, register VAT validation as a blueprint. This keeps the route handler thin and testable independently.

## Async httpx Version for Django 4.1+ Async Views

## Testing with pytest

---

## VAT API Node.js: Quick Start Guide for Backend Developers
https://www.taxid.dev/blog/vat-api-nodejs-quickstart · 2026-06-12

Get your first EU VAT validation working in Node.js in under 5 minutes. Covers fetch, error states, Express route, and environment variable setup.

This guide gets you from zero to a working VAT number validation in Node.js as fast as possible. No new npm packages required on Node.js 18+ — built-in fetch handles the HTTP call. If you need the full production-ready implementation with caching, a service class, and a complete test suite, see the [Node.js EU VAT validation tutorial](/blog/nodejs-eu-vat-validation-tutorial). This guide is deliberately minimal: get the first call working, understand the response, then add the right error handling.

> You need a TaxID API key to follow this guide. Get one free at [taxid.dev/signup](/signup) — the free tier includes 100 validations/month, no credit card required.

## Step 1: Add Your API Key

Store your key as an environment variable. Never hardcode it in source files or commit it to version control — treat it like a database password.

## Step 2: Your First Validation Call

The TaxID API uses a simple REST pattern: `GET /api/v1/validate/:country/:vat`. The country code is the two-letter ISO prefix that appears at the start of every VAT number — for `DE123456789`, the country is `DE`.

## Step 3: Understanding the Response

Every validation response has the same shape. The `status` field is the one that drives all your application logic — not `valid`, which is just a boolean shorthand for `status === 'active'`.

## Step 4: Handle All Four Status Codes

There are exactly four status values. Each requires different application logic. The most common mistake is treating `service_unavailable` the same as `inactive` — do not zero-rate based on an unavailable response.

> When `status` is `service_unavailable`, never silently apply zero-rate VAT. The safest approach is to charge standard VAT and issue a credit note once VIES recovers and confirms the number is valid.

## Adding a Validation Endpoint in Express

In a typical Express.js application, expose VAT validation as a POST endpoint your frontend can call. Keep the API key on the server — never pass it to the browser.

## TypeScript Version

For TypeScript projects, add types to the response and the handler return value to get full IDE autocompletion and type safety throughout your application.

---

## Python Async VAT Validation with httpx and asyncio (FastAPI & Django Guide)
https://www.taxid.dev/blog/python-async-vat-validation · 2026-06-12

VIES latency averages 400ms–1.5s — blocking your FastAPI or Django async view. This guide shows how to validate EU VAT numbers asynchronously using httpx, asyncio.gather, and asyncio.Semaphore for concurrent bulk validation.

The synchronous requests library works fine for one-off VAT lookups, but it blocks the event loop when you use it inside an async Python application. VIES latency averages 400ms–1.5 seconds — during which your FastAPI or Django async view cannot process other requests. The solution is httpx.AsyncClient, which gives you the same interface as requests but with full asyncio support. This guide covers single validation, bulk concurrent validation, and integration patterns for FastAPI and Django.

## Installing httpx and setting up the client

> Do not create a new httpx.AsyncClient on every request. Connection setup adds 50–200ms overhead and exhausts file descriptors under load. Create the client once at application startup (or use a module-level singleton) and reuse it across requests. The get_client() function above handles this with a lazy singleton pattern.

## Single async validation

## FastAPI endpoint with async validation

## Bulk async validation with asyncio.gather

For bulk validation, use asyncio.gather with asyncio.Semaphore to limit concurrency. Without a semaphore, a large list will overwhelm the VIES backend and trigger rate limit responses.

## Django async view (Django 4.1+)

## Error handling: timeout, service unavailable, invalid

---

## VAT ID United Kingdom: Developer's 2026 Guide
https://www.taxid.dev/blog/vat-id-united-kingdom · 2026-06-11

A complete guide to the vat id united kingdom for developers. Learn formats, post-Brexit rules, verification methods, and robust validation for 2026.

---

## WooCommerce EU VAT Validation: Beyond Format Checks with Real VIES Validation
https://www.taxid.dev/blog/woocommerce-eu-vat-validation · 2026-06-11

WooCommerce's built-in VAT field validates format only — it never calls VIES. This guide shows how to add real VIES validation via PHP hooks, store audit records in order meta, and handle WooCommerce Subscriptions re-validation.

WooCommerce has built-in EU VAT number handling (via the EU VAT Number plugin or WooCommerce's own tax settings), but it only validates format — it checks whether the string looks like a German or French VAT number, without ever calling VIES. This means a customer can enter a syntactically valid but completely unregistered VAT number and receive zero-rate treatment. For EU businesses, this creates VAT liability. This guide shows how to add real VIES validation via PHP hooks, with correct error handling and audit records.

## Why WooCommerce's built-in VAT check is not enough

> The WooCommerce EU VAT Number plugin and WooCommerce's built-in EU tax settings perform format validation only — they do not call VIES. A customer who enters DE123456789 (a format-valid number that does not exist in VIES) will pass the built-in check and receive reverse-charge treatment. You are then liable for the VAT you did not charge.

The fix is to add a VIES validation call inside the woocommerce_checkout_process action hook, which fires before the order is created. If the validation fails, you add a checkout error notice and halt the order. The customer sees a clear message and can correct their VAT number.

## Adding real-time VIES validation via a hook

## Storing the validation record in order meta

Once the order is created, store the validation result in order meta. You will need this for audit purposes — specifically the company name (to verify it matches what the customer declared), and a request ID to prove that validation was performed.

## Re-validation for WooCommerce Subscriptions

For subscription-based WooCommerce stores using the WooCommerce Subscriptions plugin, you need to re-validate the VAT number before each renewal payment — a business can deregister between renewals, and applying reverse charge based on a stale validation creates liability.

## Testing your integration

- Valid active VAT number: use DE114111111 (a real test number from the German tax authority) — should pass and return status: active
- Invalid VAT number: use DE000000000 — should fail validation and show the checkout error notice
- Format-invalid number: use DE12 (too short) — should trigger format_invalid before hitting VIES
- Service unavailable scenario: temporarily use an incorrect API key to simulate an error response — verify that the order is allowed through (fail open)

---

## United Kingdom Sales Tax: A Guide for SaaS & Developers
https://www.taxid.dev/blog/united-kingdom-sales-tax · 2026-06-10

Your definitive guide to United Kingdom sales tax (VAT) for 2026. Learn about registration, rates, reverse charge, and how to automate compliance for SaaS.

---

## Bulk VAT Validation: Complete Developer Guide for ERP Imports and Re-validation Jobs
https://www.taxid.dev/blog/bulk-vat-validation-guide · 2026-06-10

Bulk VAT validation covers three patterns: CSV one-time import, recurring batch jobs, and streaming ERP sync. This guide shows all three with TypeScript, including concurrency control, error handling, and audit trail design.

Most VAT validation guides focus on single-number checkout validation. But teams handling ERP onboarding, migrating customer data, or running monthly compliance jobs need to validate thousands of VAT numbers at a time. Bulk validation has different requirements: rate limiting, concurrency control, partial-failure handling, and audit trail design at scale. This guide covers the three main bulk patterns with complete TypeScript examples.

## Three bulk validation patterns

## CSV import: normalizing before you validate

VAT numbers in customer data exports are rarely clean. You will find numbers with spaces, dashes, lowercase prefixes, duplicate entries, and numbers for non-EU countries mixed in. Normalize before querying — it saves API calls and catches obvious errors before they hit VIES.

## Calling the API in parallel with concurrency control

Sending all requests simultaneously will hit rate limits and overwhelm the VIES backend. Use a semaphore-based concurrency limiter to keep 5–10 requests in flight at once, which is the right balance between throughput and stability.

## Handling results: status × action

## The monthly re-validation job architecture

## Building the audit trail for bulk operations

In bulk validation, each individual validation still needs its own audit record — even though you ran them all in a batch. Store the request_id for every result where one was returned. For service_unavailable results, store the timestamp and schedule a retry. Your audit log should make it possible to answer: 'What was the validation status of customer X's VAT number on a specific date?' for any customer and any date.

> In bulk validation, service_unavailable results should not be re-queued immediately — they indicate the upstream VIES node for that country is down. Log them and retry in the next scheduled run (typically 24 hours later). Retrying immediately will return the same status and waste your quota.

---

## Validate VAT Numbers in 31 Countries: A Deep Dive into the TaxID API
https://www.taxid.dev/blog/validate-vat-numbers-31-countries · 2026-06-10

A complete guide to the TaxID API's 31-country VAT and Tax ID validation coverage — EU27, UK, Australia, Norway, and Switzerland. Understand what each registry validates, what data it returns, and how to use it in production.

Validating a VAT number sounds like a single operation, but it involves querying one of 31 different national registries — each with its own format rules, response fields, and reliability characteristics. The TaxID API abstracts this complexity behind a single REST endpoint: GET /api/v1/validate/:country/:vat. This guide explains what happens inside that call for each of the 31 supported countries, what data each registry actually returns, and the edge cases that cause silent failures if you do not know to look for them.

## The 27 EU Member States via VIES

All 27 EU member states are validated via VIES (VAT Information Exchange System), the European Commission's centralised routing layer. VIES does not maintain its own database — it routes each query to the national tax authority of the relevant member state and relays the response. This means that validation quality, response time, and available fields vary by country even though you use the same API endpoint.

The VIES company_name and address fields are returned by most — but not all — member states. Germany, France, Netherlands, Belgium, and most northern European states return full company name and registered address. Some southern and eastern European states (notably Romania and Bulgaria) return only valid/invalid status with no company details. The API response includes company_name: null and address: null in these cases — this is correct behaviour, not an error.

> Greece is the single most common integration gotcha: its VIES country code is EL, not GR. GR is the ISO 3166-1 alpha-2 code, but Greece registered under the name Ελλάδα in the VIES system. The TaxID API accepts both GR and EL and normalises to EL automatically.

## United Kingdom: HMRC VAT Validation

Post-Brexit, UK VAT numbers are no longer accessible through VIES. The TaxID API validates UK numbers via the HMRC VAT Registration Number API directly. UK VAT numbers use the GB prefix (9 digits) or the XI prefix for Northern Ireland businesses that remain in the EU VAT area under the Northern Ireland Protocol. XI numbers are validated via VIES, not HMRC.

HMRC returns company name and registered address for valid UK VAT numbers, making it one of the most complete data sources of the 31 supported registries. The HMRC API is RESTful (unlike VIES SOAP), generally faster (200–400ms), and has better uptime than most EU member state VIES nodes.

## Australia: ABN/ABR Validation

Australian businesses use ABNs (Australian Business Numbers) rather than VAT numbers. ABNs are 11-digit numbers validated via the Australian Business Register (ABR). The TaxID API uses the AU country code for ABN validation. The ABR returns business name, ABN status (active/cancelled), entity type (company, sole trader, trust, etc.), and the date of GST registration.

Australian GST (Goods and Services Tax) operates differently from EU VAT: there is no intra-country reverse charge, and GST applies to B2B and B2C supplies alike in most cases. ABN validation is primarily used for supplier onboarding (confirming a supplier is registered before including them in PAYG withholding calculations) and for B2B export invoices where the buyer needs to claim GST input tax credits.

## Norway: Brønnøysund/MVA Validation

Norwegian VAT numbers (MVA numbers) are validated via the Brønnøysund Register Centre. The format is a 9-digit organisation number followed by 'MVA' (e.g., 123456789MVA). The TaxID API uses the NO country code. Norway is part of the EEA but not the EU — its VAT system is not connected to VIES, so it requires a separate API call to the Norwegian Enhetsregisteret.

## Switzerland: UID Validation

Swiss businesses use UID numbers (Unternehmens-Identifikationsnummer). The standard VAT-relevant format is CHE-XXX.XXX.XXX MWST (French: TVA, Italian: IVA). Switzerland is not in the EU or EEA — its VAT system is managed by the ESTV (Swiss Federal Tax Administration) and is entirely separate from VIES. The TaxID API uses the CH country code for Swiss UID validation via the Zefix registry.

## The Single Endpoint Pattern

The major practical advantage of using an API that covers all 31 countries is that your integration code does not need country-specific conditional logic. The same endpoint, the same response shape, and the same status codes apply regardless of whether you are validating a German DE number via VIES, a UK GB number via HMRC, or an Australian AU ABN via the ABR.

For country-specific format details, example numbers, and per-country API documentation, see the individual country pages: [Germany](/vat-api/de), [France](/vat-api/fr), [United Kingdom](/vat-api/gb), [Italy](/vat-api/it), [Spain](/vat-api/es), [Netherlands](/vat-api/nl), [Australia](/vat-api/au), [Norway](/vat-api/no), and [Switzerland](/vat-api/ch). Each page includes the regex pattern, a live validation tool, and integration code in Node.js and Python.

## VIES Reliability Varies Significantly by Country

Even though all 27 EU member states are accessible through the same VIES endpoint, their reliability characteristics differ substantially. Germany, France, the Netherlands, and Belgium have well-maintained national VIES nodes with consistent sub-500ms response times and high availability. Some smaller member states — particularly Malta, Cyprus, and Luxembourg — have historically lower VIES uptime and slower response times. Romania and Bulgaria return only status (valid/invalid) without company name or address data, which affects use cases that need company identity verification.

The practical implication for your integration is that you cannot assume uniform behaviour across all 27 countries. A validation that takes 300ms for a German company may take 1,200ms for a Romanian company, and the Romanian response will not include a company name. Handle both cases: use a timeout that accommodates the slowest member states (5 seconds is safe), and do not treat a null company_name as an error — for some countries it is the expected response even for fully valid registrations. The TaxID API normalises these differences in its status taxonomy and documents per-country field availability.

---

## A Developer’s Guide to EU VAT Number Lookup
https://www.taxid.dev/blog/eu-vat-number-lookup · 2026-06-09

Learn how to build a resilient EU VAT number lookup system. This guide covers VIES, caching, error handling, and using a modern API for validation.

---

## EU VAT Invoice Requirements for SaaS: The 16-Field Article 226 Checklist
https://www.taxid.dev/blog/eu-vat-invoice-requirements-saas · 2026-06-09

EU law mandates 16 specific fields on VAT invoices under Article 226 of the VAT Directive. This guide lists every required field, shows which change based on customer type, and provides TypeScript code to generate compliant invoices.

An EU VAT invoice is not just a payment receipt. Under Article 226 of the EU VAT Directive (2006/112/EC), a VAT invoice must contain 16 specific items of information. Missing any one of them makes the invoice legally non-compliant — which can cause the buyer to lose their right to deduct input VAT and expose you to questions from tax authorities. For SaaS companies issuing hundreds or thousands of invoices per month, getting this right in code is essential.

## The 16 mandatory invoice fields under Article 226

> Missing even one of the 16 mandatory fields makes the invoice non-compliant under EU law. Buyers receiving a non-compliant invoice may lose their right to deduct the input VAT — which can create disputes and chargebacks even when the underlying supply was correct.

## Fields that change based on customer type

Fields 4, 10, 11, and 14 all change based on whether the customer is a B2B reverse-charge customer or a B2C customer. Getting these right is where most SaaS invoice implementations go wrong.

## Generating compliant invoices in code

## What Stripe, Paddle, and Chargebee handle automatically

Billing platforms vary significantly in how much Article 226 compliance they handle for you. Stripe Tax generates invoices with most required fields but requires you to supply the customer's VAT number and set tax_exempt correctly — it does not validate the number via VIES. Paddle (as a Merchant of Record) handles the entire VAT compliance chain including VIES validation, invoice generation, and OSS remittance. Chargebee generates compliant invoice PDFs when you supply the tax configuration and customer data correctly, but does not validate VAT numbers.

## Storing the validation record with the invoice

The link between the VIES validation and the invoice is critical for audit purposes. Store the request_id from the validation call alongside the invoice ID, and include the validation timestamp. If you are ever audited, this record demonstrates that you verified the customer's taxable status before applying zero-rate treatment.

---

## Choosing the Best VAT API: Comparison of Features and Pricing
https://www.taxid.dev/blog/best-vat-api-comparison · 2026-06-09

A side-by-side comparison of the leading VAT validation APIs — TaxID, Vatstack, Vatlayer, and Lookuptax — across country coverage, pricing, reliability, error handling, and developer experience.

The VAT validation API market has grown alongside the SaaS industry's expansion into EU markets. The main options — TaxID (taxid.dev), Vatstack, Vatlayer, and Lookuptax — all call the same underlying VIES registry but differ significantly in how they handle the hard parts: VIES downtime, status code granularity, pricing at scale, and global coverage beyond the EU. Choosing the wrong API for your use case means either building workarounds for missing features or paying for a Rolls-Royce when a simpler tool would do.

## Country Coverage

For pure EU B2B validation, all four providers cover the same 27 member states via VIES. The differentiation comes at the edges: UK (HMRC) validation post-Brexit, and non-EU markets like Australia and Norway that matter for SaaS companies with global customer bases. TaxID and Lookuptax lead here; Vatlayer is EU-only in practice.

## Error Handling and Status Codes

This is where APIs diverge most sharply — and where the choice matters most for production reliability. The critical distinction is between status: 'invalid' (the number does not exist) and status: 'service_unavailable' (VIES could not be reached). APIs that collapse both into a single 'not valid' response force developers to either block legitimate customers during VIES maintenance windows or silently zero-rate unverified numbers. Both outcomes are worse than handling the states correctly.

> Any API that returns a simple `valid: false` for both invalid numbers and VIES downtime events is unsuitable for production. You will either block real customers during EU maintenance windows or silently zero-rate unverified numbers during those windows. Test this specifically before choosing an API.

## Pricing Comparison

VAT API pricing varies significantly at scale. Most providers offer a free tier for development, but the pricing curves diverge sharply from 1,000 requests per month upward. Key factors: whether format validation errors consume quota (they should not — it penalises correct implementation), whether cached results have a different price from live VIES calls, and whether there is a flat monthly plan option for predictable billing.

The pricing comparison should be read alongside the format validation behaviour. If an API charges quota for format errors, your effective cost per successful validation is higher than the headline price suggests, particularly if your users have a high rate of typos or formatting variations. A checkout flow that validates on-blur (as the user types) rather than on-submit can generate 5–10 quota-consuming calls per successful validation if format errors are charged.

## Developer Experience

Developer experience is harder to quantify but matters in practice. Key indicators: whether the API has a sandbox mode for testing invalid and service_unavailable states without manipulating production data, whether the documentation includes code examples in your language, and whether the error messages are actionable rather than generic HTTP status codes.

## Recommendation by Use Case

For **EU-only SaaS checkout** with moderate volume (under 50k validations/month): TaxID or Vatstack. Both have correct error handling, adequate EU coverage, and reasonable pricing at this scale. TaxID edges ahead on status code granularity and format validation behaviour.

For **global SaaS** needing EU + UK + Australia + Norway + more: TaxID or Lookuptax. Vatlayer and Vatstack cover too few non-EU jurisdictions for global SaaS. Lookuptax has broader coverage but is priced at a premium.

For **high-volume marketplace or ERP validation** (100k+ validations/month): Evaluate the batch endpoint performance and pricing tiers specifically. At this volume, per-request pricing matters less than flat-rate plan availability and whether cached results are priced differently from live VIES calls.

For **compliance-critical use cases** (AML, KYC, DAC7): the company_name and address fields matter as much as the valid flag. TaxID and Lookuptax return full company details from VIES. Vatlayer in particular returns minimal company data, which is insufficient for KYC workflows that need to cross-reference the registered company name against the buyer's self-declared company name.

For a deeper comparison of TaxID specifically against Vatstack and Vatlayer, see the [Vatstack alternative](/compare/vatstack-alternative) and [Vatlayer alternative](/compare/vatlayer-alternative) pages. For implementation guidance regardless of provider, see [How to Integrate a VAT Number Check API into Your Checkout Flow](/blog/integrate-vat-api-checkout).

## What Is Not Worth Comparing

Some criteria that appear in VAT API marketing materials do not meaningfully differentiate providers in practice. Response time for live VIES calls is one: every provider calls the same underlying VIES infrastructure, so a live validation for a German VAT number will take roughly the same 200–800ms regardless of which API you use. The variance comes from each provider's caching layer, not from faster access to VIES. Compare cached response times, not claimed raw VIES times.

Uptime guarantees are another area where marketing claims outrun practical differences. All four providers depend on VIES, which is the weakest link in the chain. A provider can offer 99.9% uptime for their own infrastructure but cannot guarantee VIES availability — when Italy's VIES node goes down for scheduled maintenance, every provider returns service_unavailable for Italian VAT numbers, regardless of SLA. The meaningful comparison is not uptime but how each provider handles and communicates VIES outages: explicit status codes, documented fallback behaviour, and transparency about which member states are currently down.

Schema and data format are occasionally cited as differentiators but rarely matter in practice. All four providers return a validation result and a company name. The field names differ slightly (valid vs is_valid, company_name vs name) but the migration from one schema to another is an afternoon of work at most. The decision should be driven by coverage, pricing model, error handling correctness, and whether you need async webhooks — not by which JSON field names you prefer.

---

## VAT in Germany: A Developer's Guide to Billing & Checkout
https://www.taxid.dev/blog/vat-in-germany · 2026-06-08

A dev-focused guide to VAT in Germany. Learn about rates, reverse charge, VIES validation, and how to implement correct VAT handling in your SaaS checkout.

---

## How to Validate EU VAT Numbers with VIES API (and Why Most Teams Use a Wrapper)
https://www.taxid.dev/blog/how-to-validate-eu-vat-vies-api · 2026-06-08

VIES is the authoritative source for EU VAT validation, but its SOAP interface, ambiguous errors, and downtime make direct integration painful. This guide shows both approaches — raw VIES and a REST wrapper — with working code.

VIES (VAT Information Exchange System) is the European Commission's official system for validating EU VAT registration numbers in real time. It is the only legally authoritative source for EU VAT validation — when you call it and get a positive result, you have fulfilled your obligation to verify the buyer's taxable status under the EU VAT Directive. The problem is that calling it directly is painful: it uses SOAP/XML, returns one error for both 'invalid' and 'service unavailable', has no caching, and averages 1–4 seconds per request. This guide shows you both approaches.

## What VIES actually returns

VIES returns five fields. Not all of them are populated for all EU countries — some member states don't share company name and address data through VIES.

> Greece uses the prefix 'EL' in VIES, not the ISO 3166 code 'GR'. If you pass GR for a Greek VAT number, the call will either fail or return invalid — always use EL. This is the most common integration bug for teams building multi-country VAT validation.

## Option 1: Call VIES directly (SOAP)

The VIES SOAP endpoint is at `https://ec.europa.eu/taxation_customs/vies/services/checkVatService`. The following example uses the `node-soap` package. In production you would also need to handle WSDL caching, connection timeouts, XML parsing errors, and the MS_UNAVAILABLE fault code.

## Option 2: Use a REST wrapper (recommended)

A REST wrapper handles the SOAP complexity, caches responses, and returns machine-readable status codes that distinguish between all five outcomes. The following examples use the TaxID API.

## Handling all 5 status codes correctly

## Country format reference (10 most validated)

---

## Sales Tax in Norway: A Developer's Guide to MVA
https://www.taxid.dev/blog/sales-tax-in-norway · 2026-06-07

A complete guide to sales tax in Norway (VAT) for developers. Learn about MVA rates, registration, invoicing, and how to handle Norwegian VAT in your SaaS.

---

## EU VAT Rules for Digital Services: OSS, MOSS, and What Changed in 2021
https://www.taxid.dev/blog/eu-vat-rules-digital-services-oss · 2026-06-07

Since July 2021, MOSS became OSS and the rules for EU VAT on digital services changed significantly. This guide explains what applies to SaaS, when OSS kicks in, and how to implement the B2B/B2C routing in code.

If you sell digital services — SaaS subscriptions, API access, online courses, software licenses — to customers in the EU, you are subject to EU VAT rules regardless of where your company is incorporated. Since July 2021, the Mini One Stop Shop (MOSS) was replaced by the broader One Stop Shop (OSS), changing both the threshold rules and the registration options. This guide explains what the current rules are, which regime applies to your business, and how to implement the correct VAT routing in your billing code.

## What counts as a 'digital service' under EU VAT law

EU VAT law (Annex II to Directive 2006/112/EC) defines electronically supplied services as those 'delivered over the internet or an electronic network, the nature of which renders their supply essentially automated and involving minimal human intervention'. In practice, this covers virtually all software-as-a-service products.

- SaaS subscriptions (project management, CRM, design tools, etc.)
- API access (metered or subscription — any REST API sold as a product)
- Online courses and e-learning platforms
- Digital content streaming (video, music, podcasts)
- Software license downloads and activation keys
- Cloud storage and hosting services
- Online marketplaces that facilitate digital goods or services

> If a human is meaningfully involved in delivering the service (consultancy, custom development, coaching), it may not qualify as an electronically supplied service. When in doubt, consult a EU VAT specialist for your specific product.

## The B2B/B2C split: which regime applies

The most important thing to understand about EU VAT for digital services is that B2B and B2C transactions are governed by completely different rules. OSS and MOSS are strictly B2C mechanisms. Reverse charge is strictly a B2B mechanism. Both can apply to your business at the same time, for different customers.

## OSS registration: when and why

The €10,000 EU-wide threshold for B2C digital services means that until your total B2C digital services revenue across all EU countries (excluding your home member state) exceeds €10,000 in a calendar year, you can choose to apply your home country's VAT rate and remit it locally. Once you exceed this threshold, you must charge VAT at each customer's country rate and remit via OSS.

OSS registration is done in one EU member state (typically your home country or the country where you have a fixed establishment). From there, you submit a single quarterly return covering all EU B2C VAT, and the OSS system distributes it to each member state. This replaces the old requirement to register for VAT in each country where you had customers.

## What OSS does NOT cover

> OSS and reverse charge are separate regimes for separate customer types. OSS handles B2C VAT collection and remittance. Reverse charge handles B2B zero-rate supplies. A customer with a valid EU VAT number is never part of your OSS obligations — they account for VAT themselves via reverse charge.

## Decision flowchart: which regime applies to each transaction

## Developer implementation checklist

- Add a VAT number field to your checkout and account settings UI
- Validate the submitted VAT number in real time via the [TaxID API](/vat-validation-api) before completing the order
- Route the transaction: active VIES result → reverse charge; no number or invalid → OSS/B2C
- Store the validation result (status + request_id) with the customer record
- Generate invoices with the correct fields for the applicable treatment
- Run a monthly re-validation job on all B2B customers with status: active
- Register for OSS once your EU-wide B2C revenue approaches €10,000/year

## Frequently asked questions

- **If I'm outside the EU, do OSS rules still apply to me?** Yes. If you sell digital services to EU consumers, you are subject to EU VAT regardless of where your business is incorporated. Non-EU businesses can register for OSS via the Non-Union OSS scheme, which operates similarly to the EU OSS but has no €10k threshold.
- **What happened to MOSS?** MOSS (Mini One Stop Shop) was replaced by OSS in July 2021. OSS covers not just digital services (B2C) but also goods sold via distance selling. If you were registered for MOSS, you were automatically moved to OSS.
- **Does OSS registration affect my B2B reverse charge obligations?** No. OSS covers only B2C transactions. B2B reverse charge continues to operate independently under the same rules as before.

---

## VAT ID Checker API: A Developer's Guide for 2026
https://www.taxid.dev/blog/vat-id-checker · 2026-06-06

Build a production-ready VAT ID checker with our developer guide. Learn to use a modern API (Node.js/Python), handle errors, and integrate with Stripe.

---

## The Benefits of Real-time VAT Number Verification for SaaS Businesses
https://www.taxid.dev/blog/real-time-vat-verification-benefits-saas · 2026-06-06

Real-time VAT number verification eliminates manual finance work, reduces fraud, creates automatic audit trails, and removes VAT liability risk. Here's the business case with numbers.

Most SaaS companies that sell to EU businesses start with the same manual process: a customer submits a VAT number at signup, someone on the finance team logs into the EU VIES website, types in the number, and records the result in a spreadsheet. It takes 10–15 minutes per customer, creates gaps in the audit trail when someone forgets to do it, and fails entirely when VIES is slow or down. Real-time API-based verification eliminates all of these problems — and the business case is stronger than most teams expect.

## The 5 business benefits of real-time VAT verification

- **Eliminate VAT liability on reverse-charge invoices.** If you apply zero-rate reverse charge without a valid VIES confirmation at the time of supply, you are personally liable for the VAT amount. Real-time verification ensures every reverse-charge invoice has a timestamped, request-ID-linked validation record behind it.
- **Remove manual work from finance workflows.** At 10–15 minutes per customer, a team onboarding 200 B2B customers per month spends 33–50 hours per month on manual VAT lookups. API verification reduces that to zero.
- **Instant fraud detection via company name verification.** The VIES response includes the registered company name and address for most EU countries. When the name doesn't match what the customer claimed, or the address is in a completely different country, that's a signal worth investigating before you onboard them.
- **Automatic audit trail built on every transaction.** Every API call returns a unique request_id. Store it alongside the invoice and you have a timestamped, immutable record that the VAT number was validated — exactly what a tax audit requires.
- **Monthly re-validation catches deregistrations before they create liability.** A customer's VAT number that was valid at onboarding can become inactive at any time. A monthly re-validation job catches these before your next invoice run, so you never issue a reverse-charge invoice to a deregistered business.

## What real-time looks like in practice

The difference between manual and API-based verification isn't just speed — it's the completeness of the data captured and the reliability of the process. Manual verification depends on a person remembering to do it. API verification happens as a side effect of the normal checkout or onboarding flow.

## The service_unavailable problem: why real-time must be resilient

VIES is down approximately 2% of the time — roughly 14–15 hours per month. A naive implementation that rejects any customer whose validation fails will incorrectly block valid EU businesses during those windows. The correct approach is to distinguish between 'this number is invalid' and 'the service is currently unreachable', and to handle each differently.

> Never treat service_unavailable as invalid. VIES is unavailable ~2% of the time. If you reject customers when VIES is down, you will lose approximately 2% of your EU B2B signups unnecessarily — plus you will block re-activations of valid customers during outages.

## ROI calculation for a 500-customer SaaS

For a SaaS with 500 EU B2B customers, assume 30 new customers per month and a monthly re-validation job running on all 500. At 10 minutes per manual check, that's 300 minutes (5 hours) of new customer validation plus another 500 minutes (8.3 hours) of monthly re-validation — 13.3 hours of finance time per month, every month. At a fully-loaded cost of $50/hour, that's $665/month in labour cost, just for VAT number management. The TaxID API at scale pricing costs less than $80/month for this volume. Beyond cost, the API eliminates audit exposure: a single missed re-validation that results in a reverse-charge invoice to a deregistered business can trigger a tax authority assessment for the full VAT amount on every invoice since the deregistration.

## Frequently asked questions

- **Is real-time validation required or just recommended?** Required for zero-rate reverse charge. The EU VAT Directive requires you to verify the buyer's taxable status before applying zero-rate treatment. Real-time VIES validation is the standard way to satisfy this requirement.
- **What happens if the API is slow at checkout?** The TaxID API returns cached results in under 10ms for recently validated numbers. Cold VIES calls typically complete in 300–600ms. This is fast enough to include inline in a checkout flow without impacting conversion.
- **Can I batch validate a list of VAT numbers?** Yes — use concurrent API calls with a rate limiter. See the [bulk VAT validation guide](/blog/bulk-vat-validation-guide) for implementation patterns.

---

## Automating B2B Invoice VAT Validation for Global Sales
https://www.taxid.dev/blog/automate-b2b-vat-validation · 2026-06-06

Manual VAT number checks create bottlenecks, audit gaps, and billing errors. This guide shows how to automate B2B invoice VAT validation across EU, UK, and non-EU markets using the TaxID API.

In a manual B2B billing workflow, every new enterprise customer requires a finance team member to open the VIES portal, type in the VAT number, screenshot the result, and file it somewhere. For 10 customers a month, that is manageable. For 500 new B2B signups a month across 15 EU countries, plus UK, Australia, and Norway, it becomes a significant operational cost with a high error rate. Automation does not just save time — it creates a consistent, auditable record that a manual process cannot reliably produce.

## Where Automation Fits in the Invoice Lifecycle

B2B VAT validation automation has three distinct insertion points in the invoice lifecycle. First, at customer onboarding: validate the VAT number when the customer first provides it, before their account is activated for B2B pricing. Second, at invoice creation: re-validate before issuing any zero-rated invoice, particularly for invoice amounts above a threshold that warrants the extra verification step. Third, in the monthly subscription cycle: run a batch re-validation job for all reverse-charge customers before the billing date. Each insertion point catches a different failure mode.

## Automating Onboarding Validation

At onboarding, the customer submits a VAT number during account setup. Your server calls the TaxID API immediately. If status: 'active' is returned, activate the B2B account with reverse-charge treatment. If status: 'invalid', show an error asking for a correction. If status: 'service_unavailable', create the account with standard VAT treatment and queue the customer for re-validation within 24 hours. This prevents EU maintenance windows from blocking legitimate business customers from onboarding.

## Building the Monthly Re-Validation Job

The monthly batch re-validation job is the most important automation for subscription businesses. It catches two scenarios that onboarding validation misses entirely: businesses that deregister voluntarily after signing up, and businesses whose VAT registration is revoked by the tax authority. Both events happen regularly in the EU — restructurings, company dissolutions, and voluntary deregistrations each produce a formerly-valid number that returns inactive from the next VIES query.

## Automating ERP and Supplier Import Validation

Finance and procurement teams often manage lists of 500–5,000 supplier VAT numbers in spreadsheets or ERP exports. Importing these without validation creates a silent compliance risk: the list may contain invalid, inactive, or incorrectly transcribed numbers that have never been checked against VIES. Integrate a validation step into the import flow that runs the full list through the batch endpoint and flags any numbers returning non-active statuses before they enter your accounting system.

The [TaxID bulk validation feature](/use-cases/bulk-vat-import) covers the CSV import pattern with a web UI for non-developer finance team members, plus the API pattern for developers building it into automated ERP sync pipelines. The [ERP supplier validation use case](/use-cases/erp-supplier-validation) covers SAP, Oracle, and custom ERP integration patterns specifically.

## Audit Trail Requirements

Automation is only as good as its audit trail. EU tax authorities ask to see, for each zero-rated invoice: the VAT number validated, the name and address returned by VIES at the time of validation, and the date of validation. Store this at the invoice level, not just the customer level. A customer object with a single 'last validated' timestamp does not prove the number was valid on the date of the 8th monthly invoice if the customer deregistered between invoice 6 and invoice 8. The audit record must be immutable and time-stamped at the point of issuance.

> The TaxID API response includes a `request_id` that uniquely identifies the VIES query. Store this with every invoice. If a tax auditor challenges a specific invoice, the request_id lets you retrieve the exact validation response that was on file at the time.

## Handling Multiple Jurisdictions in a Single Workflow

A SaaS company with customers in EU countries, the UK, Australia, and Norway cannot build a single national-registry integration and call it done. Each jurisdiction has its own registry, its own format rules, and its own reliability characteristics. HMRC (UK) is a REST API with better uptime than VIES. The ABR (Australia) is also REST-based but has different field names. VIES is SOAP and the least reliable of the three. Building direct integrations with each registry means maintaining four separate clients, each with their own error taxonomy and downtime patterns.

The practical solution for multi-jurisdiction automation is a unified API that normalises all registries into a consistent interface — the same endpoint, the same response shape, the same status codes regardless of country. This is the architecture the TaxID API provides: your validation logic does not need to branch on country, handle SOAP for some cases and REST for others, or maintain separate error handling per jurisdiction. A single call to GET /api/v1/validate/:country/:vat works identically for DE, GB, AU, NO, and CH.

For automation workflows that process invoices from a global customer base, this uniformity matters operationally. Your monthly re-validation job, your onboarding gateway, and your pre-invoice check all use the same code path regardless of which country the customer is in. When a new jurisdiction needs to be supported — Norway was added to the TaxID API without requiring any customer code changes — existing automations inherit the new coverage automatically.

---

## VAT in Sweden: A 2026 Guide for SaaS & Devs
https://www.taxid.dev/blog/vat-in-sweden · 2026-06-05

Comprehensive guide to VAT in Sweden for SaaS & developers. Learn 2026 rates, registration, reverse-charge, and validation. Stay compliant.

---

## Reverse Charge VAT for SaaS: A Developer's Implementation Guide
https://www.taxid.dev/blog/reverse-charge-vat-saas-implementation · 2026-06-05

Implementing reverse charge VAT in a SaaS billing system has four discrete steps. This guide covers detection, VIES validation, invoice generation, and monthly re-validation — with working TypeScript examples.

Reverse charge VAT sounds simple: instead of you charging and remitting VAT, the buyer does. But implementing it in a SaaS billing system has four discrete steps, each with specific code requirements and compliance implications. Miss any one of them and you either create VAT liability or generate invoices that fail an audit. This guide covers all four steps with working TypeScript examples.

## When reverse charge applies: the 3 conditions

Reverse charge for cross-border digital services applies when all three of these conditions are met simultaneously. If any condition fails, you are in B2C territory and must apply the customer's country VAT rate via OSS.

- Both your business and the customer's business are VAT-registered in EU member states
- The customer is registered in a different member state from your seller entity
- The customer's VAT number is confirmed active in VIES at the time of supply

## Step 1: Detecting a reverse charge customer

Detection happens at two points: during account creation (when the customer first provides a VAT number) and before each invoice is generated (to catch deregistrations). The classifier below handles both entry points.

## Step 2: Validating before applying zero-rate

At checkout, validate in real time and store the full result — not just the boolean. You need the request_id for audit purposes and the company_name for invoice generation. If VIES is unavailable, allow the customer through but flag for re-validation.

> Never treat service_unavailable as invalid. VIES is down approximately 2% of the time. Rejecting a valid customer because VIES was temporarily unreachable creates churn and is legally unnecessary — you are not required to block the sale, only to validate when possible.

## Step 3: Generating the compliant invoice

A reverse-charge invoice must satisfy Article 226 of the EU VAT Directive. The most commonly omitted elements are the explicit 'reverse charge' text and the Article 196 reference. Without these, the invoice is non-compliant even if the underlying VAT number was correctly validated.

## Step 4: The monthly re-validation job

Businesses deregister. A VAT number that was valid at onboarding can become inactive at any time. Applying reverse charge based on a stale validation exposes you to the same liability as never validating — the obligation is to verify the status 'at the time of supply', which for subscriptions means each billing cycle.

## Stripe-specific: setting tax_exempt correctly

If you use Stripe for billing, set the customer's tax_exempt property to 'reverse' when reverse charge applies. This signals to Stripe Tax not to apply VAT and ensures the invoice exported from Stripe is annotated correctly. You still need to store your own validation record — Stripe does not perform VIES validation on your behalf.

---

## EU VAT Validation API: A Comprehensive Guide for B2B SaaS
https://www.taxid.dev/blog/eu-vat-validation-api-guide · 2026-06-05

Everything B2B SaaS developers need to know about integrating an EU VAT validation API — from the legal requirement to the code, rate limits, error states, and scaling to thousands of validations per day.

An EU VAT validation API translates a SOAP-based, unreliable, latency-sensitive EU government system into a clean REST/JSON endpoint your application can call in two lines of code. The underlying system — VIES, the EU's VAT Information Exchange System — has been operational since 1993 and was built for a different era of software. This guide explains how to integrate an EU VAT validation API for B2B SaaS: what the API abstracts, how to structure your integration, how to handle failure modes, and how to scale from a single checkout to thousands of validations per day.

## What the API Abstracts for You

VIES is a SOAP/XML API that routes validation requests to 27 individual national tax authority systems. Calling it directly from a modern application requires a SOAP client library, XML parsing, WSDL management, error handling for SOAP faults that are structurally different from HTTP errors, and retry logic for country-level outages that can last hours without notice. The response format, field names, and error codes vary between member states. Response times average 400ms–1.5 seconds for live calls.

A well-designed EU VAT validation API wraps all of this into a REST endpoint with consistent JSON responses, a predictable error taxonomy, Redis caching for repeated lookups, and explicit status codes for every possible outcome. You get the authoritative VIES answer without touching SOAP, and your validation endpoint stays under 100ms for cached results.

## The Complete Status Taxonomy

Building a correct integration requires handling all five possible status values, not just the happy path. Each has a different implication for your checkout and billing flow.

> The most dangerous mistake is collapsing `service_unavailable` and `invalid` into the same error path. Blocking a legitimate business customer because Italy's VIES node was down for an hour creates commercial damage. Not distinguishing between them on the zero-rate decision creates a compliance gap. Handle them separately.

## Integration Patterns by Use Case

The right integration pattern depends on your product's billing model. The three most common patterns are: real-time checkout validation, async onboarding validation, and recurring subscription re-validation.

**Real-time checkout validation** is the synchronous pattern: the buyer enters a VAT number, your server validates it before completing the order, and the result determines whether tax_exempt: 'reverse' is set on the Stripe customer. Latency matters here — keep the timeout to 5 seconds and display a loading state during the VIES call. For [Stripe integration](/blog/stripe-eu-vat-validate-tax-ids) this is the recommended pattern.

**Async onboarding validation** defers the check: the customer provides a VAT number at signup, you queue the validation for a background job, and you send a confirmation email once VIES confirms the registration. Use this pattern when your checkout is optimised for speed and you want to avoid VIES latency in the critical path. The trade-off is that the first invoice may need to be re-issued once validation completes.

**Recurring subscription re-validation** is a monthly background job that re-checks all customers with tax_exempt: 'reverse'. VAT registrations change — build this from day one, not as an afterthought when your first audit happens.

## Rate Limits and Caching

VIES imposes query rate limits at the EU and member-state level. The official limit is not published but is approximately 100 requests per hour per source IP for live queries. This becomes a problem for businesses doing bulk onboarding of existing supplier lists or re-validating large subscription bases. A VAT validation API with Redis caching resolves this: repeated lookups for the same VAT number within the cache window (typically 24 hours) are served from cache with sub-10ms latency and do not consume VIES quota.

For bulk validation use cases — importing a CSV of 5,000 supplier VAT numbers from your ERP, or monthly re-validation of a large subscriber base — use the batch endpoint rather than looping through the single-validate endpoint. The TaxID batch endpoint handles VIES rate limiting internally and processes lists of up to 500 numbers per request.

## Code Examples in Four Languages

## Scaling Beyond 10,000 Validations Per Day

At high validation volumes, the main constraints shift from VIES latency to API rate limits and cost per validation. At this scale, optimise your integration in three ways: (1) Add a local format check before every API call — format_invalid errors return instantly without consuming quota, and user input data is noisy enough that 20–30% of submissions may have formatting errors. (2) Cache validation results in your own database alongside the VIES cache. A customer's VAT number does not change between monthly invoices — serve from your cache for recurring billing, call the API only for the monthly re-validation job. (3) Use the batch endpoint for bulk operations instead of sequential single-validate calls. The batch endpoint processes up to 500 numbers per request with a single HTTP round-trip.

For country-specific validation details, format specifications, and per-country code examples, see the [VAT API country pages](/vat-api). The pages for [Germany](/vat-api/de), [France](/vat-api/fr), [United Kingdom](/vat-api/gb), [Italy](/vat-api/it), and [Spain](/vat-api/es) cover the most commonly validated markets in detail.

---

## The Sales Tax API Guide for Developers (2026)
https://www.taxid.dev/blog/sales-tax-api · 2026-06-04

A complete guide to understanding and integrating a sales tax API. Learn about components, workflows, code examples (Node.js/Python), and best practices.

---

## B2B vs B2C EU VAT for Digital Services: The Developer's Decision Guide
https://www.taxid.dev/blog/b2b-vs-b2c-eu-vat-digital-services · 2026-06-04

The B2B vs B2C distinction drives every EU VAT decision in your SaaS or digital product. Learn how to detect it, validate it, and implement the correct tax treatment in code.

Every EU VAT decision in your SaaS or digital product flows from one question: is this customer a business with a valid EU VAT number, or not? Get the answer right and you apply the correct tax treatment automatically. Get it wrong and you either overcharge legitimate B2B customers — losing the sale — or apply zero-rate reverse charge to someone who doesn't qualify, making yourself liable for the full VAT amount. This guide explains how to detect the distinction, validate it legally, and implement the correct treatment in code.

## What makes a customer B2B vs B2C under EU VAT law

Under EU VAT Directive 2006/112/EC, the B2B classification for cross-border digital services requires three things: both parties must be VAT-registered, they must be in different EU member states, and the buyer's VAT number must be valid in VIES at the time of supply. Meeting all three conditions entitles you to apply the reverse charge mechanism — the buyer accounts for VAT in their own country, and you invoice at 0%. If any condition fails, you are in B2C territory and must apply the VAT rate of the customer's country.

> You cannot rely on a customer's self-declaration that they are a business. Under Article 17 of EU Regulation 282/2011, the seller must take reasonable steps to verify the buyer's taxable status. VIES validation is that verification step — without it, the zero-rate treatment is legally unsupported.

## Detecting B2B status at checkout

The detection logic at checkout has two inputs: the country the customer selects, and whether they provide a VAT number that passes VIES validation. You cannot shortcut this with format-only validation — a syntactically correct VAT number that is not registered in VIES does not entitle the customer to reverse charge treatment.

## Why VAT validation is the legal gate — not a UX nicety

Some teams implement VAT number fields at checkout but only do format validation — checking that the string looks like a German or French VAT number — without calling VIES. This is legally insufficient. A format-valid but VIES-invalid number means the customer is either not registered or has been deregistered. Applying zero-rate reverse charge to such a customer makes you liable for the VAT you failed to charge, because you did not take the required 'reasonable steps' to verify taxable status.

## How the B2B/B2C decision affects your invoice fields

## Handling edge cases

- Customer in the same country as your seller entity: even with a valid VAT number, reverse charge does not apply to domestic supplies. Apply the standard domestic rate.
- Customer provides a VAT number but it's for a different country than their billing address: validate against the country in the VAT number prefix (e.g. DE123... → validate as DE), not the billing country. VIES validates by prefix.
- VIES returns service_unavailable at checkout: do not reject the customer. Allow the order, store the number as 'pending validation', and re-validate once VIES recovers. Document your service_unavailable handling policy for audit purposes.
- Customer provides an EU VAT number but is purchasing as a consumer: this happens with sole traders. If VIES confirms the number is active, you may treat it as B2B. If the customer disputes a reverse-charge invoice, the liability shifts to them per Article 17 of Regulation 282/2011.

## Frequently asked questions

- **Can I trust the customer's claim that they are a business without validating?** No. Article 17 of EU Regulation 282/2011 requires the seller to take reasonable steps to verify taxable status. VIES validation is the standard way to satisfy this requirement.
- **What if the customer gives a VAT number from a different EU country than their billing address?** Validate using the country code in the VAT number prefix. The billing address country is irrelevant for VIES lookup.
- **Should I re-validate on every invoice or just at signup?** At minimum, re-validate monthly. Businesses deregister, and a stale validation creates the same liability as no validation. For subscription billing, re-validate before each monthly invoice generation.

---

## Stripe EU VAT: How to Validate Tax IDs Before Charging Customers
https://www.taxid.dev/blog/stripe-eu-vat-validate-tax-ids · 2026-06-04

Stripe Tax does not verify that a VAT number is registered in VIES. Here is the correct two-step approach — validate first, then set tax_exempt — that keeps EU B2B billing compliant and audit-ready.

Stripe Tax is excellent at calculating which VAT rate applies to a given transaction. It handles jurisdiction detection, rate changes, and the mechanics of reverse charge. What it does not do is verify whether the VAT number your customer typed actually exists in the VIES registry. A buyer can enter any plausible-looking number — even a correctly-formatted one belonging to a different company — and Stripe will apply zero-rate treatment without complaint. If that number turns out to be invalid on audit, the VAT liability falls on you, not the customer.

> Stripe's documentation acknowledges this gap: 'Stripe does not verify that a Tax ID is valid. You are responsible for verifying that a Tax ID is accurate and belongs to the customer.' EU VAT Directive 2006/112/EC makes VIES verification your legal responsibility before applying zero-rate.

## The Two-Step Pattern: Validate First, Then Set tax_exempt

The correct pattern has two steps executed in sequence before any invoice is issued. First, call the TaxID API to check the VAT number against the live VIES registry. Second, only if the API returns status: 'active', update the Stripe customer with tax_exempt: 'reverse'. Never call stripe.customers.update with tax_exempt: 'reverse' based solely on the customer providing a correctly-formatted VAT number string.

## How Stripe Uses the tax_exempt Flag

When you set tax_exempt: 'reverse' on a Stripe customer, Stripe Tax suppresses VAT on all invoices for that customer and automatically adds the 'Reverse charge' annotation required by EU Invoice Directive Article 226. Critically, Stripe respects this flag regardless of how it was set — there is no validation step on Stripe's side. The flag means 'I, the seller, have verified this customer is reverse-charge eligible'. The burden of that verification is entirely yours.

## Storing the Validation Record in Stripe Metadata

Store the full validation result in Stripe customer metadata immediately after applying zero-rate. The metadata fields vat_number, vat_company_name, vat_address, vat_validated_at, and vat_request_id give your finance team a complete audit trail accessible from the Stripe dashboard without needing to cross-reference a separate database. The request_id from the TaxID API is particularly valuable — it uniquely identifies the VIES query and can be used to retrieve the original response if an auditor challenges a specific invoice.

## Handling VIES Downtime Gracefully

VIES has scheduled maintenance windows and per-country outages. When the TaxID API returns status: 'service_unavailable', do not block the checkout. Instead, proceed with standard VAT (tax_exempt: 'none') and add the customer to a re-validation queue. Once VIES recovers and confirms the number, update tax_exempt to 'reverse' and issue a VAT refund via Stripe's credit note feature. This approach is more commercially sound than blocking a legitimate business customer during an EU maintenance window.

## Subscription Re-Validation: The Monthly Check

For subscription businesses, VAT registrations can change between billing cycles. A company that was validly registered at signup may have deregistered six months later. Schedule a monthly background job that re-validates all customers with tax_exempt: 'reverse'. When a number that was previously active returns inactive or invalid, revert tax_exempt to 'none' and notify your finance team before the next invoice cycle. Issuing a zero-rated invoice to a deregistered business creates a VAT liability on the same terms as issuing one to an unverified number.

For the complete checkout integration pattern including frontend field design, server-side endpoint code, and the SQL audit schema, see [How to Integrate a VAT Number Check API into Your Checkout Flow](/blog/integrate-vat-api-checkout). For a use-case-specific implementation guide for Stripe, see the [Stripe EU VAT use case page](/use-cases/stripe-eu-vat).

## B2B vs B2C: How Stripe Determines the Tax Treatment

Stripe Tax determines whether to charge VAT based on two factors: the customer's location (billing address) and the tax_exempt flag on the customer object. For a customer with no tax_exempt flag (or tax_exempt: 'none'), Stripe charges VAT at the applicable destination-country rate — the standard B2C treatment. For a customer with tax_exempt: 'reverse', Stripe suppresses VAT entirely and adds the reverse-charge annotation. The key insight is that Stripe does not know whether the customer is a business or a consumer — that determination is yours to make, based on whether you have validated their VAT number.

In practice this means your checkout must implement the business/consumer split explicitly. The most robust pattern: show a 'Business purchase?' toggle, and when the customer activates it, show the VAT number field. If they provide a VAT number, validate it. If valid, set tax_exempt: 'reverse'. If they do not provide a VAT number (or leave the toggle off), leave tax_exempt at the default 'none' — Stripe charges standard VAT. Never rely on the customer selecting a business billing address as a proxy for B2B — residential streets in EU countries regularly appear as business billing addresses.

One edge case worth handling explicitly: a customer who enters a VAT number from a different country than their billing address. This is legitimate — a German company with a UK billing address for a branch office, for example — but it should trigger a manual check. In automated flows, the simplest approach is to accept the VAT number if VIES confirms it active, regardless of the billing country, but flag the mismatch in your CRM for your finance team to review before the first invoice is issued.

---

## Reliable UK VAT Number Check: Your Guide for 2026
https://www.taxid.dev/blog/uk-vat-number-check · 2026-06-03

Perform a reliable UK VAT number check. Validate manually, via HMRC/VIES, or integrate API for developers. Get accurate results for 2026.

---

## How to Integrate a VAT Number Check API into Your Checkout Flow
https://www.taxid.dev/blog/integrate-vat-api-checkout · 2026-06-03

Step-by-step guide to adding EU VAT number validation to your checkout. Covers frontend UX, server-side validation with Node.js, error handling, zero-rate application, and the Stripe/Paddle integration pattern.

Getting VAT validation right at checkout matters more than it looks. A developer who adds a VAT number field and skips server-side verification, or collapses 'VIES unavailable' and 'invalid number' into the same error, creates a compliance gap that does not show up in tests but becomes a tax liability during audit. This guide covers the complete flow: what to show the buyer, how to validate on the server, what to do when the registry is down, and how to connect the result to your billing provider.

## The Checkout VAT Flow: Four Steps

The correct checkout VAT flow has four distinct steps: (1) collect the VAT number from the buyer in the frontend, (2) validate it server-side via the TaxID API before the order is created, (3) apply zero-rate treatment in your billing provider if the validation returns active, and (4) store the validation result as an audit record attached to the invoice. Each step has specific failure modes that need handling.

## Step 1: The Frontend VAT Field

Show the VAT number field only when the customer selects a business billing type or enters a country that requires B2B tax handling. Displaying it to all customers increases form abandonment and produces noise from consumers who will enter invalid data. A good pattern: show a 'I am purchasing on behalf of a company' toggle in the billing address section, and reveal the VAT number field only when that toggle is on.

> Never validate the VAT number from the browser by calling the TaxID API directly. Your API key would be exposed in network requests. Always proxy through your own server endpoint.

## Step 2: Server-Side Validation Endpoint

Create a server endpoint that the frontend calls. This endpoint calls the TaxID API with your server-side API key, handles the three distinct response states (active, invalid, service_unavailable), and returns a clean status to the frontend.

## Step 3: Applying Zero-Rate in Stripe

When the validation returns active, update the Stripe customer object to set tax_exempt: 'reverse'. This causes Stripe Tax to suppress VAT on all subsequent invoices for that customer and adds the 'Reverse charge' annotation required by EU Invoice Directive 2006/112/EC Article 226.

## Step 4: Storing the Audit Record

EU record-keeping obligations require you to show, on audit, that the VAT number was valid at the time of every zero-rated invoice. The minimum audit record contains: the validated VAT number, the company name and address returned by VIES, the validation timestamp, and the request_id from the API response. Store these with the invoice, not just with the customer — VAT registrations can change between invoices.

## Handling the service_unavailable State

VIES has documented reliability issues. Some member-state nodes have scheduled maintenance windows without advance notice. When the API returns service_unavailable, you have two safe options: charge standard VAT and issue a credit note once VIES recovers, or queue the customer for re-validation and hold the zero-rate decision until confirmed. Never silently apply zero-rate to an unverified number — that is exactly the liability you are trying to avoid.

> Do not block checkout when VIES is unavailable. Blocking legitimate business customers during an EU maintenance window creates more commercial damage than the compliance risk of delaying zero-rate application by a few hours. Charge standard VAT, log the service_unavailable event, and process the adjustment once the registry recovers.

## Re-Validation for Subscriptions

One-time checkout validation is insufficient for subscription products. Add a background job that re-validates every customer with tax_exempt: 'reverse' at least monthly. The TaxID API supports batch validation for this use case. When a previously valid number returns inactive or invalid, flag it for your finance team before the next billing cycle and revert tax_exempt to none until the customer updates their registration.

For more on the legal requirements behind this integration, see [Ensuring EU VAT Compliance for SaaS Businesses](/blog/eu-vat-compliance-saas-guide). For Paddle-specific integration (which handles VAT differently from Stripe), the same server-side validation pattern applies but you use Paddle's API to set the tax override rather than Stripe's tax_exempt flag.

## Common Integration Mistakes to Avoid

Several integration patterns look correct in development but create compliance gaps in production. The most common is validating in the browser via a direct API call — this exposes your API key in network requests and can be easily bypassed by a determined user who simply removes the field from their form payload. Always proxy through your own server endpoint.

The second most common mistake is treating the VAT field as required. VAT numbers are optional — consumers do not have them, and many small businesses that have not yet crossed the VAT registration threshold do not have them either. Making the field required creates friction that causes abandonment, particularly from legitimate B2C customers. The field should always be optional, with checkout proceeding normally if it is left blank (standard VAT applies).

Third: storing only the valid/invalid result, not the full API response. An audit asks what the VIES registry said at the time of the transaction — not a boolean you computed from it. Store the complete response including status, company_name, address, and request_id. The request_id is particularly important: it is the unique identifier for the underlying VIES query and is the single piece of evidence that proves a live government registry was consulted.

## Testing Your VAT Integration

Use the TaxID API test numbers to verify that your integration handles all status codes correctly before going live. The test numbers are documented in the API reference: DE000000000 returns format_invalid (format check fails before VIES), DE999999999 returns invalid (VIES confirms no such registration), and DE888888888 returns service_unavailable (simulates a VIES downtime event). Testing the service_unavailable path is critical — most integrations only test the happy path and the invalid path, leaving the downtime handling untested until the first real VIES maintenance window hits production.

---

## Ultimate Guide: Vat Identification Number Uk for 2026
https://www.taxid.dev/blog/vat-identification-number-uk · 2026-06-02

Your complete guide to vat identification number uk for 2026. Learn its format, how to validate it via HMRC and APIs, and integrate it into your checkout flow.

---

## What is a VAT Validation API and Why Your SaaS Needs It
https://www.taxid.dev/blog/what-is-vat-validation-api · 2026-06-02

A VAT validation API connects your application to official government tax registries in real time. This guide explains how it works, what it returns, and when EU law requires you to use one.

A VAT validation API is a programmable interface that lets your application check whether a VAT (Value Added Tax) or Tax ID number is legitimately registered with a government tax authority — in real time, without manual lookup. You send a VAT number; the API returns a structured response telling you whether it is active, who it belongs to, and their registered address. The whole round-trip takes under two seconds.

For any SaaS company billing B2B customers across EU borders, this check is not optional. EU VAT Directive 2006/112/EC requires sellers to verify their buyer's VAT registration before applying zero-rate treatment (the reverse charge mechanism). Skip it and you become personally liable for the full VAT amount on every incorrectly zero-rated invoice — regardless of whether the buyer gave you a plausible-looking number.

## What Does a VAT Validation API Actually Do?

Under the hood, a VAT validation API does two things in sequence. First, it checks the format of the number you submitted against the country-specific pattern (Germany: DE + 9 digits; France: FR + 2 alphanumeric chars + 9 digits; Netherlands: NL + 9 digits + B + 2 digits). This catches most user input errors instantly with no network call. Second, it queries the live official registry — in the EU, that is VIES (the VAT Information Exchange System), operated by the European Commission. In the UK it is HMRC, in Australia it is the ABR, in Norway it is Brønnøysund.

VIES is a federation of 27 national databases — not a single registry. When you validate a German VAT number, VIES routes the query to Germany's BZST (Bundeszentralamt für Steuern) and relays the response. A French TVA number goes to the DGFiP. This architecture means individual country nodes can be temporarily unavailable without the whole system going down, but it also means response times and reliability vary by country. A good VAT API wraps this complexity: it handles SOAP-to-JSON translation, retries transient failures, caches results to reduce latency, and returns consistent status codes regardless of which country you are validating.

## The API Response: What You Get

> Never treat `status: service_unavailable` the same as `status: invalid`. A service_unavailable response means VIES could not be reached — the number may be perfectly valid. Charge standard VAT and refund once VIES recovers; do not silently zero-rate an unverified number.

## Why SaaS Companies Need This

SaaS companies selling to EU businesses face three compounding problems without automated VAT validation. First, EU VAT law creates direct financial liability: if a customer provides an invalid VAT number and you zero-rate their invoice, the VAT amount is owed by your company — not the customer. EU tax authorities run automated cross-checks between VIES and VAT returns. The bigger your zero-rated invoice volume, the higher your audit exposure.

Second, the problem does not go away at signup. VAT registrations change — businesses deregister voluntarily, get cancelled by tax authorities, or restructure across borders. A number that was valid when the customer signed up may be revoked on the day you issue your 12th monthly invoice. Subscription businesses need re-validation on a recurring schedule, not just at onboarding.

Third, the company name and address returned by the API are a free fraud-detection signal. When a customer claims to be a large German Mittelstand company but the VIES-registered address is a residential flat in a small town, that discrepancy is worth a manual review before extending credit terms or activating a high-volume plan.

## When Is VAT Validation Legally Required?

EU VAT Directive 2006/112/EC Article 138 makes VIES validation a prerequisite for applying zero-rate to intra-community B2B supplies. This applies whenever you sell to a business in a different EU member state and wish to apply reverse-charge. 'Reasonable steps' to verify the VAT number — meaning a VIES check, not just accepting the buyer's word — must be documented. Without that documentation, your zero-rated invoices are vulnerable to reclassification during audit.

For marketplace platforms, [DAC7 (EU Directive 2021/514)](/use-cases/marketplace-seller-onboarding) adds a separate layer. Platforms facilitating transactions between sellers and buyers must collect and verify seller VAT numbers if the seller earns over €2,000 or completes 30+ transactions per year, with annual reporting to national tax authorities.

Outside the EU: the UK requires VAT validation under HMRC rules for zero-rated UK-EU supplies post-Brexit. Australia's GST system, Norway's VAT system, and Singapore's GST system all have equivalent requirements for B2B cross-border supplies. The [TaxID API](/vat-api) covers 31 countries across these jurisdictions with a single endpoint.

## B2B vs B2C: Why It Only Matters for B2B

VAT validation is a B2B concern, not a B2C concern. If you sell to a consumer (someone without a VAT number), you charge VAT at the applicable rate in their country — no validation step needed. The reverse charge mechanism that makes zero-rating possible only applies to transactions between two VAT-registered businesses. This means your checkout flow only needs to trigger the validation API when the customer indicates they are a business and provides a VAT number. If they leave the VAT number field blank, treat them as a consumer and apply standard VAT.

## How to Choose a VAT Validation API

## Making Your First Request

For a complete integration walkthrough covering frontend UX, server-side validation, Stripe zero-rate application, and recurring re-validation, see [How to Integrate a VAT Number Check API into Your Checkout Flow](/blog/integrate-vat-api-checkout). For country-specific format details and regex patterns for all 27 EU member states plus UK and Australia, see the [VAT API country pages](/vat-api).

---

## Euro VAT Number: A Developer's Guide for 2026
https://www.taxid.dev/blog/euro-vat-number · 2026-06-01

A complete guide to the Euro VAT number for developers. Learn country formats, VIES validation, regex checks, and how to build a reliable system with an API.

---

## UK VAT Number Format: A Developer's Guide for 2026
https://www.taxid.dev/blog/uk-vat-number-format · 2026-05-31

A complete guide to the UK VAT number format for developers. Covers GB/XI prefixes, regex, validation rules, checksums, and API integration for checkouts.

---

## VAT Tax Switzerland: 2026 Guide for SaaS & Developers
https://www.taxid.dev/blog/vat-tax-switzerland · 2026-05-30

Master vat tax switzerland for SaaS & developers. Get 2026 rates, registration thresholds, B2B rules, and automate VAT number validation for compliance.

---

## VAT in Portugal: A Guide for SaaS & E-Commerce Teams
https://www.taxid.dev/blog/vat-in-portugal · 2026-05-29

A complete guide to VAT in Portugal for B2B SaaS and e-commerce. Learn rates, registration, reverse charge, invoicing, and how to reliably validate VAT IDs.

---

## SaaS VAT Compliance: A Developer's Complete Guide for EU Markets
https://www.taxid.dev/blog/saas-vat-compliance-guide · 2026-05-29

Complete developer guide to EU VAT compliance for SaaS products: B2B vs B2C rules, place of supply, OSS registration, checkout implementation, and invoice requirements.

If you sell a SaaS product to EU customers, you're subject to EU VAT rules. The good news is that the rules are logical once you understand the underlying framework. The bad news is that most developers encounter them in the middle of a billing implementation, without time to read EU directives. This guide gives you the practical framework without the legal theory.

## The Two Fundamental Rules

Everything in EU VAT for SaaS flows from two rules: (1) For B2B sales, VAT is accounted for by the buyer in their country (reverse charge). (2) For B2C sales, VAT is charged at the customer's country rate and reported by you. These two rules have very different implementation implications.

## Place of Supply for Digital Services

For digital services (SaaS, APIs, software downloads), the place of supply is always where the customer is located, not where you are. This means a German company selling SaaS to a French customer must apply French VAT rules — not German ones. This is different from physical goods, where origin-based rules often apply.

> If your annual B2C sales to all EU countries combined exceed €10,000, you must either register for VAT in each country individually or use the EU One Stop Shop (OSS) scheme to file a single quarterly return covering all EU sales.

## Implementing VAT in Your SaaS Checkout

## OSS Registration

The EU One Stop Shop (OSS) lets you file a single VAT return for all your B2C EU sales, rather than registering in each country separately. You register in your home country, then file quarterly returns reporting sales to each EU country at that country's rate. For non-EU businesses, the Import One Stop Shop (IOSS) handles B2C sales of goods.

## VAT Invoice Requirements

- Your legal company name and address
- Your VAT registration number
- Customer's legal name, address, and VAT number (B2B)
- Invoice date and a unique sequential invoice number
- Description of services supplied
- Net amount (ex-VAT), VAT rate, VAT amount, and total including VAT
- For reverse charge: explicit note citing Art. 196 EU VAT Directive
- For OSS sales: customer's country VAT rate applied

---

## EORI Number Lookup: A Developer's Guide to Validation
https://www.taxid.dev/blog/eori-number-lookup · 2026-05-28

Learn how to perform an EORI number lookup manually and with an API. This guide includes code examples in Node.js and Python for automated EORI validation.

---

## How to Use a VAT Rates API: Developer Integration Guide
https://www.taxid.dev/blog/vat-rates-api-integration · 2026-05-28

Step-by-step guide to integrating a VAT rates API into your application. Covers rate lookup, caching, error handling, and multi-country billing with JavaScript, Python, and cURL examples.

Hardcoding VAT rate tables is a maintenance liability. When Estonia raised its standard rate from 20% to 22% in January 2024, every application with a hardcoded rate table was suddenly billing incorrectly — without any failing tests to catch it. A VAT rates API solves this by making rate data a runtime lookup rather than a compile-time constant.

## Getting Started: Basic Rate Lookup

## Caching Strategy

VAT rates change rarely — typically once or twice per year at most, and always with advance notice. Cache rate responses for 24 hours. A stale-while-revalidate pattern works well: serve the cached rate immediately while refreshing it in the background.

> Monitor the last_updated field in API responses. If a rate's last_updated date is more recent than your cache, force-invalidate and refresh. This gives you near-instant rate updates without polling.

## Error Handling

- Always set a timeout (5 seconds recommended) — never let a rate lookup block checkout indefinitely
- Fall back to a cached rate if the API is temporarily unavailable
- Log all rate lookup errors with the country code and timestamp for debugging
- Never silently default to 0% on error — charge the standard rate as a safe fallback

---

## What Is the VAT Tax in Italy: 2026 Guide
https://www.taxid.dev/blog/what-is-the-vat-tax-in-italy · 2026-05-27

Discover what is the vat tax in italy, how it works for B2B/B2C sales. Our 2026 guide covers rates, reverse-charge, and validating VAT IDs.

---

## VAT for Developers: The Complete 2026 Implementation Guide
https://www.taxid.dev/blog/vat-guide-for-developers · 2026-05-27

Everything developers need to know about VAT implementation: rate lookup, validation, B2B vs B2C rules, checkout integration, and invoice requirements. With API code examples.

Value Added Tax (VAT) is a consumption tax levied on goods and services at each stage of production and distribution. For developers building billing systems, e-commerce platforms, or SaaS products that serve EU customers, VAT compliance means getting four things right: knowing the applicable rate, validating the customer's tax status, applying the correct tax treatment, and generating compliant invoices.

## What VAT Actually Means for Your Code

VAT is not just a percentage you multiply by the price. It's a legal determination that depends on: (1) the type of goods or services sold, (2) the location of the supplier, (3) the location of the customer, and (4) whether the customer is a business or a consumer. Getting any of these wrong creates compliance risk.

## VAT Rate Lookup vs VAT Number Validation

These are two separate API calls that serve different purposes. Rate lookup retrieves the applicable VAT percentage for a country and product category. VAT number validation checks whether a business customer has a valid EU VAT registration, which determines if reverse charge applies.

## B2B vs B2C: The Fundamental Split

The most important classification in EU VAT is whether you're selling to a business (B2B) or a consumer (B2C). For B2B sales with a valid VAT number, the reverse charge mechanism typically applies: the buyer accounts for VAT in their own country, and you issue a zero-rated invoice. For B2C sales, you must collect VAT at the customer's local rate.

> Never grant tax exemption based solely on a customer self-declaring as a business. Always validate the VAT number through VIES or an API. A checked checkbox is not compliance evidence.

## Implementing VAT in Checkout

- Collect customer country at checkout start, before showing price
- Show a VAT number field for business customers — make it optional but encourage it
- Validate the VAT number server-side before finalizing the order
- Compute tax treatment server-side — never trust client-side calculations for billing
- Store the validation result (valid/invalid, company name, timestamp) on the transaction
- Generate the invoice with the correct tax treatment note

## Invoice Requirements

Every VAT invoice must include: your VAT number, the customer's VAT number (B2B), the VAT amount, the VAT rate applied, and for reverse charge transactions, the note 'Reverse charge' or the equivalent in the customer's language. Missing any of these makes the invoice non-compliant.

---

## European Union VAT Identification Number: A Dev's Guide
https://www.taxid.dev/blog/european-union-vat-identification-number · 2026-05-26

Learn what a European Union VAT identification number is, its formats, and how to validate it. A complete guide for developers on VIES, regex, and using an API.

---

## France TVA Rates 2026: Complete Guide for Businesses and Developers
https://www.taxid.dev/blog/france-vat-rates · 2026-05-26

Complete guide to France TVA rates in 2026: 20% standard rate, 10%, 5.5%, and 2.1% reduced rates. Includes which categories qualify and developer API examples.

France applies four VAT rates (taxe sur la valeur ajoutée, TVA) under the Code général des impôts (CGI): a 20% standard rate, a 10% intermediate rate, a 5.5% reduced rate, and a 2.1% super-reduced rate. The complexity comes from knowing which products and services fall into each category.

## France TVA Rate Summary

> Digital services and SaaS subscriptions in France fall under the 20% standard TVA rate. The reduced rates apply to physical goods and specific regulated categories — not to software or API access.

## France TVA for Developers

For B2B sales to French businesses, validate the French TVA number (FR + 11 characters) to determine if reverse charge applies. For B2C sales to French consumers, always apply the relevant TVA rate. Use the TaxID API to validate French VAT numbers in real time.

---

## VAT Tax Germany: A Developer's Guide for 2026
https://www.taxid.dev/blog/vat-tax-germany · 2026-05-25

A developer's guide to VAT tax Germany. Learn how rates, reverse charge, validation, and invoicing rules impact your code, APIs, and checkout flows in 2026.

---

## Germany VAT Rates 2026: Standard, Reduced & Zero-Rated Explained
https://www.taxid.dev/blog/germany-vat-rates · 2026-05-25

Complete guide to Germany VAT rates in 2026: 19% standard rate (Normalsatz), 7% reduced rate (ermäßigter Steuersatz), zero-rated categories. Includes API code examples for developers.

Germany applies two VAT rates under the Umsatzsteuergesetz (UStG): a 19% standard rate (Normalsatz) on most goods and services, and a 7% reduced rate (ermäßigter Steuersatz) on food, books, newspapers, hotel stays, and selected cultural services. There is no super-reduced rate in Germany.

## Germany VAT Rate Summary

## Categories at the 7% Reduced Rate

- Food products (excluding alcohol and restaurant dining)
- Books, e-books, newspapers, and magazines
- Accommodation (short-term hotel stays)
- Admission to concerts, museums, cinemas, and zoos
- Local and regional public transport (up to 50 km)
- Agricultural products

> SaaS subscriptions and digital services almost always fall under the 19% standard rate. The 7% reduced rate does not apply to software, platform fees, or API access, even if the software processes or distributes books or cultural content.

## Germany VAT for Developers: API Integration

When building billing systems for German customers, the critical decision is whether Dutch B2B customers with a valid USt-IdNr. qualify for reverse charge (no German VAT). Use the TaxID API to validate German VAT numbers and determine the correct tax treatment.

---

## VAT in Denmark: A Developer's Guide to 2026 Rules
https://www.taxid.dev/blog/vat-in-denmark · 2026-05-24

A developer's guide to VAT in Denmark. Learn 2026 rates, registration, reverse-charge for SaaS, and how to validate Danish VAT numbers via API.

---

## EU VAT Rates by Country 2026: The Complete Guide
https://www.taxid.dev/blog/eu-vat-rates-by-country · 2026-05-24

Complete guide to EU VAT rates by country in 2026. Standard, reduced, and super-reduced rates for all 27 EU member states, with developer API examples.

VAT rates across the European Union are not uniform. Each member state sets its own rates within the limits defined by EU Directive 2006/112/EC. The standard rate must be at least 15%, but in practice ranges from 17% in Luxembourg to 27% in Hungary. Reduced rates, super-reduced rates, and parking rates add further complexity for developers building tax-compliant billing systems.

## EU VAT Rate Types Explained

## VAT Rates for All 27 EU Countries (2026)

## Look Up VAT Rates via API

Instead of hardcoding rate tables in your application, use the TaxID API to fetch current VAT rates at runtime. This ensures your billing logic always reflects the latest rates without code deployments.

> VAT rates rarely change, but when they do (e.g., Estonia raised its standard rate from 20% to 22% in January 2024), hardcoded values cause billing errors. Cache API responses for 24 hours and rebuild on cache miss.

---

## Dutch VAT Rate 2026: Your Complete Compliance Guide
https://www.taxid.dev/blog/dutch-vat-rate · 2026-05-23

Our 2026 guide clarifies the Dutch VAT rate, covering 21%, 9%, 0% rates, reverse-charge rules, and automating SaaS validation via Stripe & TaxID.

---

## Master European VAT Identification Number Validation
https://www.taxid.dev/blog/european-vat-identification-number · 2026-05-22

Developer guide to the European VAT identification number: formats, VIES validation, common errors, and building resilient compliance checks.

---

## VAT Percentage in France A Developer's Guide (2026)
https://www.taxid.dev/blog/vat-percentage-in-france · 2026-05-21

Learn the current VAT percentage in France for 2026. This guide covers rates, B2B/B2C rules, VIES validation, and developer tips for SaaS billing.

---

## EU VAT ID: A Developer's Guide to Validation (2026)
https://www.taxid.dev/blog/eu-vat-id · 2026-05-20

Learn what an EU VAT ID is, why it matters for B2B sales, and how to reliably validate numbers in your checkout flow. A complete guide for developers.

---

## VAT VIES Check: A Developer's Guide to EU VAT Validation
https://www.taxid.dev/blog/vat-vies-check · 2026-05-19

Learn how to perform a VAT VIES check correctly. This guide covers the VIES API, error handling, caching, and code examples for a resilient implementation.

---

## European VAT Numbers: A Developer's Guide for 2026
https://www.taxid.dev/blog/european-vat-numbers · 2026-05-18

A dev's guide to European VAT numbers. Learn formats, validation via VIES or API, and how to build resilient B2B SaaS billing systems for the EU market.

---

## How to Check Tax ID Numbers Reliably
https://www.taxid.dev/blog/how-to-check-tax-id-numbers · 2026-05-17

Learn how to check tax ID numbers reliably. Our guide covers local formats, VIES/IRS lookups, and using an API for billing and checkout.

---

## VAT Number Lookup: A Developer's Guide for 2026
https://www.taxid.dev/blog/vat-number-lookup · 2026-05-16

Learn to build a resilient VAT number lookup for your SaaS or e-commerce app. This guide covers VIES pitfalls, API integration (Node/Python), caching, and UX.

---

## How to Calculate VAT Tax: A Developer's Guide for 2026
https://www.taxid.dev/blog/how-to-calculate-vat-tax · 2026-05-15

Learn how to calculate VAT tax with formulas for exclusive/inclusive prices, reverse charge rules, and API examples. A practical guide for developers.

---

## EU VAT Validation in Node.js: Complete Tutorial with Error Handling
https://www.taxid.dev/blog/nodejs-eu-vat-validation-tutorial · 2026-05-14

Step-by-step Node.js / TypeScript tutorial for EU VAT validation. Reusable service class, all error states, caching strategy, and Jest test patterns.

This is a complete Node.js and TypeScript tutorial for EU VAT number validation using the TaxID API. It covers everything from the initial fetch call to a production-ready service class with proper error handling, caching, Express.js middleware, Next.js API route integration, and a full Vitest test suite. If you read the [complete EU VAT validation guide](/blog/eu-vat-validation-guide) first, this tutorial is the Node.js implementation of everything covered there.

## Prerequisites and Setup

You need a TaxID API key — the free tier (100 validations/month) is sufficient for this tutorial. Get one at taxid.dev/signup in under two minutes, no credit card required. Store your key in an environment variable: TAXID_API_KEY=vat_xxxx. Never hardcode it or commit it to version control.

## TypeScript Types for the API Response

Define the response type before writing any implementation code. Strong types make the rest of the implementation safer and give you IDE autocompletion throughout. The status field is the most important — it is a discriminated union that drives all downstream logic.

## Basic Validation Function

The minimal implementation: a single async function that validates one VAT number and returns a typed result. This is the building block for everything else in this tutorial.

## Handling All Error States

Every VAT validation call can return four distinct status values, each requiring different application logic. Getting this right is the difference between a robust integration and one that silently fails in production. Here is a complete handler for all four cases:

## Building a Reusable VATValidator Class

For larger applications, a class-based service is cleaner than standalone functions. The VATValidator class wraps the API call with in-memory caching, configurable timeout, and retry-on-network-error logic. Use this as a singleton across your application.

## Express.js Middleware

For Express.js applications, a VAT validation middleware that runs on order creation or B2B signup routes keeps validation logic out of your route handlers. The middleware attaches the validation result to req so downstream handlers can use it.

## Next.js API Route

For [Next.js applications](/use-cases/nodejs-vat-validation), use an App Router API route to expose VAT validation to your frontend without leaking the API key. The route validates the number server-side and returns the result.

## In-Memory vs Redis Caching

The VATValidator class above uses an in-memory Map for caching. This works well for single-instance applications but has two limitations: the cache is lost on process restart, and it does not share state across multiple application instances in a horizontally scaled deployment. For production applications with more than one instance, use Redis for the cache instead.

## Full Vitest Test Suite

Testing all four response states — active, inactive, format_invalid, service_unavailable — and the network error case ensures your integration is correct before it reaches production. Mock fetch at the module level so tests are deterministic and do not make real API calls.

## Integrating with Prisma and a Database

For full-stack applications that need to persist validation results for audit compliance, here is how to integrate the VATValidator with Prisma. The pattern stores every validation call with a timestamp and the full response fields — this is the audit trail you need for zero-rate invoice compliance. See the [complete EU VAT guide](/blog/eu-vat-validation-guide) for the storage schema rationale and GDPR considerations.

## Rate Limiting and Quota Management

Your TaxID plan has a monthly quota. Exceeding it results in 429 responses for the rest of the month. For most applications, the quota is straightforward to stay within — but for high-growth SaaS or batch import scenarios, you need to track your usage. The TaxID API does not expose a quota status endpoint, so track usage in your application by counting validation calls in your database.

The most effective quota management strategy is aggressive caching combined with deduplication. Before making an API call, check your database for a recent validation of the same VAT number (within 24 hours). If one exists and was not service_unavailable, return the cached result without an API call. This reduces your API call volume significantly for applications where the same customers validate repeatedly (for example, every time they log in or update billing details).

## Error Monitoring and Observability

Instrument your VAT validation code with logging and metrics from the start. The metrics you want: total validation calls per hour (to detect quota burn), service_unavailable rate per country (to detect VIES outages by member state), format_invalid rate (elevated rate may indicate a form input problem), and p95 response time (should be under 50ms for mostly-cached traffic). Send these to your existing observability stack — Datadog, Grafana, or a simple log aggregator.

For production incidents, the request_id in every TaxID API response is your trace identifier. Log it alongside your application's trace ID on every validation call. If a customer reports a billing issue that may be related to VAT validation, you can use the request_id to reconstruct exactly what the API returned at the time of the relevant checkout or invoice. This is also valuable for VAT audit purposes — you can prove to a tax authority what VIES said about a specific customer at a specific time.

## Validating VAT Numbers in Server Actions (Next.js 14)

Next.js 14 Server Actions let you call server-side code directly from client components without writing an API route. For VAT validation in a Next.js application, a Server Action is the cleanest approach — the validation logic runs on the server, the API key never reaches the client, and the result is returned directly to the form component.

## Common TypeScript Pitfalls

The most common TypeScript mistake when working with VAT validation is narrowing on the valid boolean instead of the status string. TypeScript does not know that status: 'service_unavailable' implies valid: false — it sees them as two independent fields. If you write if (!result.isValid) { blockUser() }, you will incorrectly block users during VIES downtime. The correct pattern is always to check status first and derive the action from it, not from the boolean alone.

A second common mistake is typing the VAT number input as string and forgetting that users can submit empty strings, null from a JSON body, or undefined from a missing form field. Always validate and sanitise the input before passing it to the validator. The TaxID API returns format_invalid for empty or null inputs, but catching them in your application code before making the API call is better practice — it saves an API call and gives you more control over the error message shown to the user.

For TypeScript projects using strict null checks (which you should be using), the company_name and address fields in the API response are typed as string | null. Some EU member states do not return address or company name through VIES. Always handle the null case in your code — do not assume these fields will be populated. For invoice generation specifically, you need a fallback when company_name is null: use the name the customer provided at signup rather than leaving the invoice field blank.

## Performance Considerations for High-Traffic Applications

For high-traffic applications where the same VAT numbers are validated many times (common in marketplaces where seller validation is checked on every API request), the in-memory cache in VatValidator can grow unboundedly if you instantiate a new instance per request rather than using a singleton. Always export a single VatValidator instance as a module-level singleton, as shown in the code above. In serverless environments (Vercel Edge Functions, AWS Lambda), module-level singletons persist across warm invocations of the same container but are lost on cold starts — size your cache expectations accordingly.

For serverless environments with frequent cold starts, the Redis caching variant (VatValidatorRedis) is more appropriate than the in-memory Map. Upstash Redis — which the TaxID infrastructure itself uses — has a Node.js HTTP client that works well in serverless environments without maintaining a persistent connection. The cache TTL should be set to 23 hours (slightly less than TaxID's own 24-hour cache) to ensure your application cache and TaxID's Redis cache refresh in sync.

If you are building an application where VAT validation is on the critical path for every request (for example, validating the authenticated user's VAT status on every API call), consider storing the validation result directly in your session token or JWT rather than re-querying on every request. A JWT claim like vatStatus: 'b2b' with a validatedAt timestamp lets your middleware skip the validation API call entirely for already-verified users, while flagging users whose validation has expired (last checked more than 24 hours ago) for re-validation on their next request.

## Handling Batch Validation in Node.js

Some workflows require validating many VAT numbers in bulk — importing a CSV of suppliers, migrating a customer database from another system, or running a quarterly re-validation sweep on all active B2B customers. Batch validation in Node.js requires a concurrency-limited queue to avoid overwhelming your API quota in a burst and to respect any per-second rate limits.

The key constraint for batch validation is your monthly quota. If you have 5,000 customer records to validate on the Starter plan (10,000 req/month), you are using half your monthly quota in one run. Plan batch jobs to run during quiet periods and track the number of API calls made. Use database deduplication (as shown in the vat-dedup.ts example above) to avoid re-validating numbers that were already checked recently — this can reduce a batch of 5,000 records to a few hundred actual API calls if most customers were validated in the last 24 hours.

The p-limit library provides concurrency control for Promise arrays — it runs up to N promises concurrently and queues the rest. With concurrency set to 5, you send 5 validation requests simultaneously, wait for any to complete, then start the next queued request. This provides good throughput without overwhelming the API or your database with simultaneous writes. For very large batches (10,000+ records), add a delay between batches and log progress to avoid silent failures going unnoticed.

## Putting It All Together: Production Checklist

Before shipping a Node.js EU VAT validation integration to production, verify these items are in place. Each point corresponds to a section in this tutorial or a linked guide.

- TypeScript types defined for VatApiResponse and VatValidationResult — prevents runtime errors from unhandled null fields.
- All four status values handled: active, inactive, format_invalid, service_unavailable — do not conflate unavailable with invalid.
- Timeout configured (5s for sync flows, 8-10s for async) — raw fetch without a timeout hangs indefinitely if VIES is slow.
- Network errors caught and treated as service_unavailable — a try/catch around the fetch call prevents uncaught promise rejections.
- Validation result stored to database with timestamp and request_id — required for zero-rate invoice audit compliance.
- In-memory or Redis cache in place — reduces API calls for repeat lookups and warms the cache before payment flows.
- Server-side validation only — API key is in process.env, never in client-side code or public repositories.
- Quarterly re-validation job scheduled — catches VAT deregistrations that happen after initial signup.
- Metrics and logging instrumented — track service_unavailable rate by country to detect VIES outages early.
- Vitest tests cover all four response states and the network timeout case — tests run without real API calls.

Node.js is the most common runtime for new backend services in 2026, and the patterns in this tutorial translate directly to Deno, Bun, and any other JavaScript runtime with a fetch-compatible HTTP client. The TypeScript types, the VatValidator class pattern, the Express middleware, the Vitest test suite, and the Redis caching approach all work with minimal changes across runtimes. If you are using a different language, see the [Python VAT validation guide](/use-cases/python-vat-validation) and [PHP Laravel VAT guide](/use-cases/php-vat-validation) for equivalent implementations in those ecosystems. The API endpoints, authentication scheme, and response format are identical regardless of which language you use to call them.

The patterns in this tutorial — typed responses, status-based branching, in-memory caching, Redis for distributed deployments, Express middleware, Next.js Server Actions, Vitest mocks, and batch processing with concurrency limits — represent a production-grade Node.js VAT validation integration. Each pattern addresses a specific failure mode observed in real production systems: the typed responses prevent silent boolean mishandling, the status branch covers the VIES downtime case that breaks unchecked integrations, the cache reduces API call volume and covers checkout flows during downtime windows, and the test suite ensures all four status codes are handled correctly before the code ships. Start with the basic validateVat function, add the VatValidator singleton for caching, add the database storage for compliance, and add the tests before you ship. The more complex patterns (circuit breaker, batch processing, Redis cache) can be added incrementally as your scale and reliability requirements grow.

---

## EU VAT Number Validation: The Complete Developer Guide (2026)
https://www.taxid.dev/blog/eu-vat-validation-guide · 2026-05-11

Everything a developer needs to know about EU VAT number validation — VIES, format checks, error handling, B2B vs B2C, and production code examples in Node.js, Python, and PHP.

If you sell SaaS, digital services, or goods to EU businesses, validating your customers' VAT numbers is a legal requirement — not a nice-to-have. Get it wrong and your company is personally liable for the full VAT amount on every zero-rated transaction. This guide walks through exactly how EU VAT validation works end-to-end: what a VAT number is, how the EU VIES system processes validation requests, how to handle its frequent downtime, how to store results for audit compliance, and how to implement the full flow correctly in Node.js, Python, and PHP.

> Official source: VAT number formats and validation rules are defined by the [EU Council Directive 2006/112/EC](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32006L0112) (the VAT Directive). Real-time validation is provided by [VIES — VAT Information Exchange System](https://ec.europa.eu/taxation_customs/vies/), operated by the European Commission.

## What is an EU VAT Number?

An EU VAT number (Value Added Tax identification number) is a unique identifier assigned to businesses registered for VAT in a European Union member state. It serves as proof that a business is registered in the EU tax system and is legally entitled to receive zero-rate treatment on intra-community B2B supplies. Without a valid VAT number, you cannot apply zero-rate — you must charge VAT at the applicable rate.

Each number starts with a two-letter country prefix followed by up to 12 characters. The exact format is country-specific and in some cases deceptively complex. [Germany](/validate-vat/de) uses DE + 9 digits. [France](/validate-vat/fr) uses FR + 2 alphanumeric characters + 9 digits. [Spain](/validate-vat/es) uses ES + a letter or digit + 7 digits + a letter or digit — making it one of the harder formats to validate by regex alone. The Netherlands uses NL + 9 digits + B + 2 digits (the B is mandatory, not a separator). Greece uses EL as its VAT prefix, not GR — a common gotcha that causes silent validation failures when developers use the ISO country code by mistake.

A valid-looking format does not guarantee the business is actually registered. A number can pass every regex test but still fail VIES lookup if the business has deregistered, was entered with a transposition error, or was never registered in the first place. This is why you need two layers of validation: format first (local, zero-latency, saves API quota), then VIES lookup (live, authoritative). The [TaxID API](/docs) handles both steps automatically — format errors return immediately without consuming your monthly quota.

For a complete list of all 27 EU member state formats, see the country-specific validation pages: [Austria](/validate-vat/at), [Belgium](/validate-vat/be), [Bulgaria](/validate-vat/bg), [Croatia](/validate-vat/hr), [Cyprus](/validate-vat/cy), [Czech Republic](/validate-vat/cz), [Denmark](/validate-vat/dk), [Estonia](/validate-vat/ee), [Finland](/validate-vat/fi), [France](/validate-vat/fr), [Germany](/validate-vat/de), [Greece](/validate-vat/el), [Hungary](/validate-vat/hu), [Ireland](/validate-vat/ie), [Italy](/validate-vat/it), [Latvia](/validate-vat/lv), [Lithuania](/validate-vat/lt), [Luxembourg](/validate-vat/lu), [Malta](/validate-vat/mt), [Netherlands](/validate-vat/nl), [Poland](/validate-vat/pl), [Portugal](/validate-vat/pt), [Romania](/validate-vat/ro), [Slovakia](/validate-vat/sk), [Slovenia](/validate-vat/si), [Spain](/validate-vat/es), [Sweden](/validate-vat/se). Each page includes the regex pattern, a valid example, and code examples for that country's specific format.

## The EU Legal Framework: Why Validation Is Mandatory

Under EU Council Directive 2006/112/EC (the VAT Directive), intra-community B2B supplies can be zero-rated — the seller does not charge VAT, and the buyer accounts for it via the reverse charge mechanism in their own country. This zero-rate only applies when the buyer provides a valid VAT registration number and the supplier has taken reasonable steps to verify it. 'Reasonable steps' means VIES validation, not just accepting whatever string the customer typed.

If you apply zero-rate treatment without verifying the customer's registration and an audit later reveals the number was invalid, your company — not the customer — becomes liable for the full VAT amount on that transaction, plus penalties and interest. EU tax authorities run systematic cross-checks between VAT returns and VIES data. The bigger your zero-rated invoice volume, the higher your audit risk. This is not a theoretical concern — tax authorities in Germany, France, and the Netherlands actively investigate discrepancies in intra-community supplies.

For marketplace platforms, [DAC7 (EU Directive 2021/514)](/use-cases/marketplace-seller-onboarding) adds a separate layer of obligation. Platforms that facilitate transactions between sellers and buyers must collect and validate seller VAT numbers for any seller earning above €2,000 or completing 30+ transactions per year. Annual DAC7 reporting to national tax authorities is mandatory. Failure to comply carries fines of up to 1% of affected transaction volume in some member states.

> Applying zero-rate VAT without VIES verification makes your company — not the buyer — liable for the full VAT amount. EU tax authorities run automated cross-checks. Validate before every zero-rated invoice.

## How VIES Works: The Technical Architecture

VIES (VAT Information Exchange System) is the EU's official gateway for cross-border VAT number verification, operated by the European Commission's Directorate-General for Taxation and Customs Union (DG TAXUD). It is not a database — it is a routing layer. Each of the 27 member states maintains its own national VAT registration database (Germany's is the BZST, France's is the DGFiP, and so on). When you submit a validation request to VIES, it routes your query to the appropriate national system, waits for a response, and returns the result to you.

The VIES web service is implemented as a SOAP/XML API — the same protocol dominant in enterprise software in the early 2000s. This is not an oversight; it reflects the age of the infrastructure. Calling VIES directly from a modern Node.js or Python application requires a SOAP client library, XML parsing, and tolerance for a response format that looks nothing like a REST API. Response times typically range from 200ms to 2 seconds depending on the target member state and server load. Some member states have VIES endpoints that regularly take 1.5 seconds even when fully operational.

VIES also has a well-documented reliability problem. Individual member state systems go offline for scheduled maintenance without advance notice to third parties. The central VIES gateway itself has scheduled downtime windows. Some member states (particularly smaller ones) have historically poor VIES uptime. Any production system that calls VIES directly must implement explicit downtime handling. See [VIES Downtime: How to Build a Resilient VAT Validation Flow](/blog/vies-downtime-resilience) for the full resilience strategy.

> The TaxID API wraps VIES in a REST/JSON interface with Redis caching, explicit service_unavailable status codes, and sub-10ms responses for cached results. You get the authoritative VIES answer without writing a SOAP client.

## Step 1: Format Validation Before the VIES Call

Always validate the format of a VAT number locally before making a network call to VIES. There are two reasons: first, a VIES call for a malformed number wastes your API quota (both your own monthly limit and the underlying VIES quota that affects all users). Second, VIES returns SOAP fault errors for malformed inputs that are harder to parse than a clean 422 response. Format validation is instant, free, and catches most user input errors before they become API calls.

Note the Greece entry: EL, not GR. This is the single most common format mistake developers make. Greece's ISO 3166-1 alpha-2 code is GR, but in the VIES system it is EL (from the Greek name Ελλάδα). If you submit GR12345678 to VIES, it will return a country_not_found error. Always normalise to the VIES country code before validation. The TaxID API accepts both GR and EL and normalises internally.

## Step 2: Making the API Request

The simplest way to call VIES from a modern application is through the [TaxID REST API](/docs). A single GET request with a Bearer token returns a JSON response in milliseconds for cached results and under 2 seconds for fresh VIES lookups. No SOAP client, no XML parsing, no retry logic for timeouts — the API handles all of that.

## Understanding Every Response Field

Each field in the response carries specific meaning. Misreading even one field — particularly the difference between valid: false due to an invalid number versus valid: false due to VIES being unavailable — causes silent compliance failures. Here is what every field means and how to use it:

The status field is the most important. If status is service_unavailable, the number may be perfectly valid — VIES simply could not be reached at the time of the request. Treating service_unavailable the same as inactive will block legitimate customers during EU maintenance windows. If status is inactive, the number exists in VIES but the business has deregistered. If status is format_invalid, the number failed local format validation before reaching VIES — it was never submitted to VIES at all, and no quota was consumed.

## Handling VIES Downtime

VIES goes offline regularly — scheduled maintenance, emergency patches, and individual member state outages all contribute to a real-world availability below 100%. Any checkout or onboarding flow that hard-fails on service_unavailable will block legitimate customers with valid VAT numbers. The full resilience strategy — including allow-and-re-validate patterns, circuit breakers, and Express.js middleware — is covered in [VIES Downtime: How to Build a Resilient VAT Validation Flow](/blog/vies-downtime-resilience). The short version: check for status === 'service_unavailable' explicitly and allow the transaction to proceed while queuing the number for background re-validation.

## Storing Validation Results for Audit Compliance

VIES validation is a point-in-time check. A number valid today may be deregistered next month. For audit purposes, you need to store not just whether a number was valid, but when you checked it, what VIES returned, and the full request context. EU tax authorities may ask for evidence that you verified a customer's registration before applying zero-rate treatment — a database record with a timestamp and request_id satisfies this requirement.

At minimum, store: the full VAT number as normalised by the API, the status returned (active, inactive, service_unavailable), the timestamp of the validation, the TaxID request_id for traceability, and the company_name and address if returned. If VIES returned service_unavailable, store the eventual re-validation result separately with its own timestamp. Never overwrite the original validation record — you need the full audit trail.

From a GDPR perspective, VAT numbers are business identifiers, not personal data — they are not subject to GDPR's right to erasure in the way personal data is. However, if you are storing company_name and address, these could be personal data if the business is a sole trader rather than a registered company. Consult your privacy policy. The safest approach is to treat them as potentially personal data, set a retention period aligned with your tax obligations (typically 7-10 years in most EU jurisdictions), and purge on request if the data subject is a sole trader.

## Re-validating Periodically

VAT registration status changes. A business that was validly registered at signup may deregister six months later. For SaaS subscriptions, this matters because you may be issuing zero-rate invoices to a customer who is no longer registered — creating a compliance gap in your VAT returns. The risk depends on your volume and the EU member states you serve, but it is real enough that any SaaS with significant B2B EU revenue should implement periodic re-validation.

The recommended re-validation schedule depends on your business model. For monthly subscriptions, re-validate at the start of each billing period before issuing the invoice. For annual plans, re-validate quarterly. For high-volume transaction platforms, re-validate every 30 days. Always re-validate immediately when a customer updates their billing details. Set up an alert if re-validation returns inactive for a customer who was previously active — you need to switch them to B2C billing and issue a corrected invoice.

> Re-validation is cheaper than a tax audit. At TaxID's Starter plan ($19/month, 10,000 validations), re-validating 5,000 B2B customers monthly costs less than €0.002 per customer per check. The cost of issuing a single uncorrected zero-rate invoice to a deregistered business in a German tax audit is orders of magnitude higher.

## B2B vs B2C — The Tax Treatment Decision

The core business logic that drives why you need VAT validation at all is the B2B/B2C distinction. For EU businesses selling digital services or goods across EU borders, the treatment is fundamentally different based on whether the buyer is a registered business or a consumer. Validation determines which category applies.

- [B2B intra-community supply](/use-cases/saas-billing-eu): seller in EU country A, buyer in EU country B, buyer provides a valid VAT number → zero-rate VAT applies. Buyer accounts for VAT in their own country via reverse charge. You must validate the VAT number before issuing the zero-rate invoice.
- B2C or invalid/missing VAT number: charge VAT at the buyer's country rate (if you are registered for OSS or have a local VAT registration in that country) or your own country's rate if below the pan-EU threshold. No validation needed — just charge VAT.
- Domestic sales (seller and buyer in same EU country): local VAT rules apply. A buyer having a valid VAT number does not trigger zero-rate on domestic transactions — only cross-border intra-community supplies are zero-ratable.
- Non-EU sales: outside EU VAT scope entirely. Do not charge EU VAT. Some non-EU countries (UK post-Brexit, Norway, Switzerland) have separate VAT systems — those require separate handling.

For [SaaS billing systems](/use-cases/saas-billing-eu), the practical implementation is: collect the VAT number at signup, validate via API, tag the customer as b2b or b2c in your billing engine (Stripe, Paddle, Lago, etc.), and apply the correct tax treatment to all subsequent invoices. For Stripe specifically, see [Validate EU VAT numbers in Stripe Checkout](/use-cases/stripe-eu-vat) for the full implementation — it covers applying the zero-rate exemption server-side before the payment intent is created, so tax is never charged to a verified B2B customer.

## Full Code Examples

### Node.js / TypeScript

See [EU VAT Validation in Node.js](/use-cases/nodejs-vat-validation) for the full tutorial including caching strategy and Jest test patterns. The minimal implementation:

### Python

### PHP

## Common Validation Mistakes

- Checking valid without checking status: if status is service_unavailable, valid is false — but the number may be perfectly valid. Always check status first.
- Using GR instead of EL for Greece: the VIES prefix for Greece is EL, not the ISO code GR. The TaxID API normalises both, but raw VIES calls will fail with GR.
- Skipping format validation: sending malformed inputs to VIES wastes quota. Validate format locally before making the API call.
- Not re-validating periodically: [VAT registration lapses](/pricing). A valid number at signup can become invalid in 6 months. Re-validate quarterly for active subscriptions.
- Storing only the boolean: store the full response including company_name, address, status, checkedAt, and request_id. You need this for audit trails.
- Validating in the frontend: VAT validation must be server-side. Exposing your API key to the browser creates a security risk and allows clients to bypass validation.
- Treating B2B and B2C the same: apply zero-rate only to confirmed active B2B customers in other EU countries. Never apply zero-rate to domestic sales regardless of VAT number status.
- Ignoring inactive status: if VIES returns inactive, the business has deregistered. Switch them to B2C billing immediately and stop issuing zero-rate invoices.

---

## Free EU VAT Validation APIs: Honest Comparison of Limits and Trade-offs
https://www.taxid.dev/blog/free-eu-vat-validation-apis · 2026-05-08

Comparing TaxID, Vatstack, Vatlayer, and VatCheckAPI free tiers. Volume limits, HTTPS support, latency, and what upgrading actually costs.

'Free' means different things across EU VAT validation APIs. Some impose very low request limits. Some restrict HTTPS to paid plans. Some are free indefinitely for low volume but have no path to production scale. And one option — calling VIES directly — is technically free but comes with enough operational complexity that the real cost is developer time, not money. This guide compares every genuinely free EU VAT validation option in 2026, including the trade-offs that are not always obvious from the pricing page.

## The Options at a Glance

## TaxID: 100 req/month, HTTPS, Full Feature Set

TaxID offers 100 validations per month on the free tier with no credit card required. The free tier includes HTTPS, returns company name and address when available, provides explicit VIES downtime status codes (service_unavailable), and has the same API interface as paid tiers — no feature degradation for free users. The 100-request limit resets monthly and does not roll over.

For context, 100 requests per month is enough for: validating 3-4 new B2B customers per working day during development, running a closed beta with 20-30 users plus re-validations, or handling a low-volume internal tool. It is not enough for a production SaaS with more than 50-100 B2B signups per month. The upgrade to the Starter plan ($19/month, 10,000 requests) is the clear path once you exceed the free tier — no custom pricing, no sales call.

TaxID's free tier is a genuine 'try the full product' experience rather than a crippled sample. The same API key, endpoint, and response format work on free and paid tiers. If you build your integration on the free tier, upgrading requires only a payment method — no code changes.

## VatCheckAPI: 500 req/month Free Tier

VatCheckAPI offers 500 requests per month on its free tier — the most generous by raw volume among the API-based options. It includes HTTPS, returns company name where available, and covers all 27 EU member states. The 500-request limit makes it suitable for a small production deployment: a SaaS with up to 50 B2B customers per month (assuming 10 validation touches per customer including re-validations) could operate on the free tier indefinitely.

The trade-offs: VatCheckAPI's paid plan caps at 5,000 validations per month before requiring custom pricing. If you need more than 5,000/month, you hit the same custom-pricing wall that Vatstack has. The error handling documentation is less detailed than TaxID's — VIES downtime is surfaced as a generic error rather than an explicit service_unavailable status code, which makes resilience logic harder to implement correctly. For a small internal tool or low-volume B2B application, the 500 free requests are a genuine advantage.

## Vatstack: 20 req/month — Tight for Development

Vatstack's free tier is 20 validations per month. That is one API call per working day, which runs out quickly during active development. It is adequate for testing a single integration path (does the request format work, does the response parse correctly) but not for running a prototype, testing error handling scenarios, or demoing the feature to your team. You will upgrade before you are done building.

Vatstack's paid tier starts at $9/month for 1,000 validations — the lowest entry price among the API options. If your use case is genuinely low volume (under 1,000 validations per month) and you need Vatstack's specific features (webhooks, team dashboard), the $9 entry price is a reasonable starting point. But the 1,000/month ceiling on the paid plan means you will hit custom pricing quickly if your product grows. See the [Vatstack vs TaxID comparison](/blog/vatstack-vs-taxid) for the full analysis.

## Vatlayer: HTTP-Only Free Tier

Vatlayer offers 100 requests per month on its free tier — matching TaxID on volume. The critical limitation: the free tier only supports HTTP, not HTTPS. In 2026, HTTP-only API access is functionally unusable for any production application. Your API key is transmitted in plaintext over HTTP requests, making it trivially interceptable on any network between your server and Vatlayer's endpoint. HTTPS is available on Vatlayer's paid tiers starting at $9.99/month.

This matters for development too, not just production. Modern development environments default to HTTPS-only security policies, and many reverse proxies and deployment platforms (Vercel, Render, Fly.io) reject outbound HTTP calls from application code by default. You can work around this in development with configuration changes, but it is operational friction that does not exist with any other option on this list. We recommend against Vatlayer's free tier for new integrations specifically because of the HTTP limitation.

## Calling VIES Directly: Free but Expensive in Time

VIES is operated by the European Commission and is accessible directly at no cost, with no request limits. If you need unlimited validations without a per-request cost, VIES direct is technically an option. The practical challenges: VIES uses SOAP/XML (not REST/JSON), requires a SOAP client library, has no caching infrastructure (every request is a live round-trip), has no normalised error codes for downtime handling, returns error messages in the language of the target member state's system, and goes offline for maintenance regularly with no programmatic status endpoint.

Building a production-grade EU VAT validation system on raw VIES requires implementing format validation for all 27 countries, a SOAP client, a caching layer, retry logic with exponential backoff, timeout handling, normalised error codes, and monitoring. The development time for this infrastructure, even at a conservative estimate of 3-5 engineering days, exceeds the cost of a year of TaxID's Starter plan. VIES direct makes sense for research, one-off scripts, or compliance audits where you need to verify the upstream source — it does not make sense as the foundation for a production validation system.

## What to Look for Beyond the Free Tier

The free tier comparison is the starting point, not the decision criterion. Before choosing a provider, evaluate these factors that only matter once you are in production:

- Explicit VIES downtime handling: does the API return a distinguishable status when VIES is unavailable, or does it return a generic error? Distinguishable status (service_unavailable) is essential for correct checkout logic. See [VIES Downtime: How to Build a Resilient Flow](/blog/vies-downtime-resilience).
- [Response caching](/docs): does the API cache validated results? For synchronous checkout validation, the difference between 10ms (cached) and 500ms (uncached VIES call) is visible to users.
- Scale path: what does validation cost at 10,000, 100,000, and 1,000,000 requests per month? Is it on a public pricing page or does it require a sales conversation?
- Format validation before quota: does the API consume your monthly request quota on malformed numbers? A well-designed API validates format locally and only counts VIES round-trips against quota.
- Migration cost: how hard is it to switch providers? An API with standard REST conventions and clear response schemas is easy to swap out. A proprietary SDK or unusual authentication scheme increases lock-in.
- SLA and uptime: what does the provider guarantee? A service with no published SLA is acceptable for development but not for production checkouts.

## The Hidden Cost of 'Free' VIES Calls

When evaluating free tier options, factor in the operational cost of each additional request beyond the free tier. For TaxID, the path from free (100/month) to the next tier (10,000/month, $19) is a simple self-service upgrade. For Vatlayer, the path from free (100/month, HTTP only) to the first paid tier (100/month, HTTPS included) requires entering payment details to get HTTPS — you are essentially paying to remove a security limitation. The practical free-tier value of Vatlayer is therefore near zero for production use.

The comparison also looks different when you factor in error handling and developer time. If you spend two hours debugging why your integration intermittently fails because VIES is down and the API returns a generic error with no distinguishable downtime status, the developer time cost exceeds any monthly API fee. An API with explicit service_unavailable handling saves hours of debugging and reduces production incidents. Factor this into the TCO comparison alongside the per-request price.

For teams starting with a free tier and expecting to upgrade within 6-12 months, choose the provider whose paid tiers are public and predictable. Spending 3 months on a Vatstack integration only to discover that upgrading beyond 1,000/month requires a sales conversation adds time and uncertainty to your growth planning. TaxID's entire public pricing ladder (free through 1,000,000/month) is on one page with no sales gate.

## Choosing the Right Free Tier for Your Use Case

For building and testing a new integration: TaxID or VatCheckAPI. Both offer HTTPS on the free tier and enough requests to build and verify a complete integration including error handling for all status codes. TaxID's explicit service_unavailable handling is particularly valuable during development — you can test your downtime logic without simulating infrastructure failures.

For a low-volume internal tool you intend to keep on the free tier permanently: VatCheckAPI's 500/month free tier has the most headroom. If your internal application validates fewer than 500 numbers per month (a team of 5 using a tool to check suppliers, for example), VatCheckAPI's free tier may cover you indefinitely. Verify the provider's reliability and response to downtime before committing to a zero-cost long-term dependency.

For prototyping before committing to a paid plan: both TaxID and VatCheckAPI are suitable. Avoid Vatlayer for prototyping because the HTTP-only limitation creates friction that is not representative of the production experience you would have on a paid tier. The free tier should prototype the same experience as the paid product — Vatlayer's does not.

## API Key Security on Free Tiers

On free tiers, API key security is just as important as on paid plans. Your free-tier API key has the same authentication authority as a paid-tier key — anyone with access to your key can use your quota (and cause you to hit your free tier limit unexpectedly) or make validation calls that appear in your audit logs. Never expose your API key in client-side JavaScript, public GitHub repositories, or environment variables committed to version control.

A common mistake with free-tier integrations is building quickly and committing the .env file to a repository. Even if you later remove it, the key is in your git history and needs to be rotated. Set up a .gitignore for .env files before writing a single line of integration code. Store API keys in your CI/CD platform's secret management (GitHub Actions secrets, Vercel environment variables, AWS Secrets Manager) rather than in files on disk. Rotate your key if you have any reason to believe it may have been exposed — TaxID key rotation is available from the dashboard.

For development environments shared between multiple developers (for example, a shared staging environment or a development VM), avoid putting a single shared API key in the environment configuration. Each developer should use their own TaxID account and API key for development purposes. This keeps development usage separate from production usage, prevents one developer's testing from exhausting the team's production quota, and makes it easier to audit who made which validation calls during debugging.

## Upgrading from Free to Paid: What Changes and What Does Not

When you upgrade from a free tier to a paid plan, the API endpoint, authentication method, response format, and error codes are identical. There are no code changes required. The only difference is the monthly quota and the billing details on your account. This is by design — the free tier is a full-feature trial of the production API, not a crippled version. You test exactly the code that will run in production.

The upgrade process for TaxID is self-service: add a payment method to your account and select a plan. No sales call, no contract review, no onboarding meeting. The new quota is available immediately after upgrading. If you need to upgrade mid-month because you hit your free tier limit earlier than expected, the new quota applies from the moment you upgrade — you do not need to wait until the start of the next month. This is particularly useful for teams running a marketing campaign or onboarding push that drives more B2B signups than anticipated.

The right free tier for your use case depends on your development timeline and expected production volume. Use TaxID for new integrations where you want a complete developer experience from day one and a clear upgrade path to scale.

---

## DAC7 Compliance for Marketplace Platforms: VAT Verification Requirements
https://www.taxid.dev/blog/dac7-marketplace-vat-compliance · 2026-05-01

EU DAC7 (Directive 2021/514) requires marketplace platforms to collect and validate seller VAT numbers. What you need to implement and by when.

DAC7 — EU Directive 2021/514 — came into force on 1 January 2023 and imposes mandatory data collection, VAT validation, and annual reporting obligations on digital marketplace platforms operating in the EU. If your platform facilitates transactions between sellers and buyers — whether property rentals, freelance services, product sales, or gig economy work — and you meet the reporting thresholds, you must collect and validate seller VAT numbers and submit an annual report to your national tax authority. This guide explains what DAC7 requires, which platforms are in scope, and how to implement the VAT validation component of the compliance workflow.

> DAC7 is the EU directive [2021/514](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021L0514) on administrative cooperation in taxation, extending reporting obligations to digital platform operators. Member states were required to transpose it by 31 December 2022, with first reporting due 31 January 2024.

## What is DAC7?

DAC7 is the seventh amendment to the EU Directive on Administrative Cooperation in tax matters (DAC). Its full title is Council Directive (EU) 2021/514 amending Directive 2011/16/EU. It extends automatic exchange of information between EU tax authorities to include income earned by sellers on digital marketplace platforms — the same type of data that the OECD's Model Rules for Reporting by Platform Operators (which DAC7 implements in EU law) requires globally.

The practical effect: if you operate a platform that connects sellers with buyers for property rentals, personal services, goods, and transportation, you must report seller income data to your EU member state's tax authority annually. That tax authority shares the data automatically with other EU member states. The data includes the seller's name, address, tax identification number, VAT number, total consideration earned, and the number of transactions. The goal is to ensure that gig economy income and marketplace sales are properly declared and taxed.

DAC7 went live for reporting periods starting 1 January 2023. The first annual reports were due by 31 January 2024. Platforms that began operating after 1 January 2023 must report from their first full calendar year of operation. Late or incomplete reports carry penalties that vary by member state — some impose per-record fines, others impose percentage-of-undeclared-income penalties.

## Which Platforms Are In Scope?

DAC7 applies to 'Platform Operators' — defined as entities that make available, by any means, a digital interface that allows sellers to be connected with users for the provision of relevant activities. Relevant activities include rental of immovable property (Airbnb-type rentals), personal services (Fiverr, Upwork-type platforms), sale of goods (eBay, Amazon Marketplace-type platforms), and rental of any mode of transport (car sharing, bike rental platforms).

The directive specifically excludes platforms where the platform itself is the seller (not merely a facilitator), platforms that only process payments without facilitating the transaction itself, and platforms that only list sellers without enabling transactions. There is also an exclusion for 'low-risk' platforms where the operator can demonstrate that all sellers are large enterprises (annual revenue above €1 billion with a significant EU presence).

Thresholds that trigger reporting for individual sellers: a seller must be reported if they earn more than €2,000 in consideration OR complete more than 30 transactions in the calendar year. This threshold is per seller, not per platform. A seller who earns €1,500 from your platform and €700 from a competitor's platform is over threshold on the combined figure — both platforms report their portion independently, and the tax authorities reconcile.

> The €2,000/30-transaction threshold determines which sellers you must report, but it does not determine which sellers you must collect VAT numbers from. Best practice is to collect VAT numbers from all sellers during onboarding and only use the threshold to determine inclusion in the annual report.

## What Data Must You Collect from Sellers?

DAC7 requires platforms to collect and verify a specific set of seller data at onboarding and to maintain it in a current, verified state throughout the seller's active period. The required data includes: full legal name (and trading name if different), primary address, date of birth (for individual sellers), national tax identification number or equivalent, VAT identification number where applicable, financial account identifier (bank account or payment platform account to which consideration is paid), and business registration number for corporate sellers.

The verification requirements are the most operationally significant part. It is not enough to collect the data — you must verify it. For VAT numbers, this means VIES validation. For national tax identification numbers, this typically means a self-certification from the seller (you are not expected to connect to 27 national tax registries for TIN verification). For addresses, verification can be by reference to government-issued documents or an existing due diligence process. For financial accounts, standard payment platform KYC suffices.

Re-verification is required: you must re-verify collected data at least every 3 years, or when you have reason to believe the data may have changed. A seller who updates their address or banking details triggers a re-verification cycle. For VAT numbers specifically, re-validate via VIES whenever the seller updates their tax details and as part of your annual data quality check before the reporting deadline.

## VAT Number Validation in the DAC7 Context

For DAC7 purposes, VAT number validation serves two functions: it verifies that the seller is a registered EU business (relevant for determining whether they are a reportable seller under DAC7 vs a non-EU seller), and it provides the VAT identification number that must appear in the annual report. Unlike validation in a checkout context, DAC7 VAT validation does not gate a transaction — it is part of the seller onboarding and data maintenance process.

Implement VAT validation at seller onboarding as a required step for any seller who declares themselves as a VAT-registered EU business. Store the validation result with a timestamp — you need to demonstrate in your compliance records that you validated the number and when. Use [TaxID's API](/docs) for the validation call and store the full response including company_name, address, status, request_id, and checkedAt. This record is your evidence of due diligence.

## Annual Reporting: What to Include

The DAC7 annual report must be submitted to your national tax authority by 31 January following the reporting year. It covers all reportable sellers — those who earned more than €2,000 or completed more than 30 transactions in the calendar year. For each reportable seller, the report includes all the data collected at onboarding plus the total consideration paid and number of transactions in each quarter of the year, broken down by the type of activity (property rental, services, goods, transport).

For VAT numbers specifically, the report must include the most recently verified VAT identification number. If a seller updated their VAT number during the year, include the current one. If a seller did not provide a VAT number, include the national tax identification number instead (or a note if neither is available). If you attempted to validate a VAT number and received service_unavailable, document the attempt with a timestamp — this demonstrates good faith in meeting the verification requirement even when the EU system was unavailable.

The report format is XML following the OECD Common Reporting Standard schema, adapted for DAC7. Each EU member state's tax authority provides technical specifications and a submission portal. You must submit to the authority of the EU member state where your platform is established (registered). If you are established outside the EU but have EU sellers, you must register in an EU member state of your choice (most platforms choose Ireland or Luxembourg for this purpose) and submit there.

## Penalties for Non-Compliance

DAC7 penalties are set by individual EU member states rather than at the EU level, so they vary. Germany imposes fines of up to €50,000 per report for late or incomplete submission. France can impose fines of €5,000 to €50,000 depending on the severity of non-compliance. Some member states (notably the Netherlands) include criminal liability provisions for wilful non-compliance. The directive requires member states to set 'effective, proportionate, and dissuasive' penalties, so no member state has a 0-penalty regime.

The reputational risk is arguably larger than the fine risk for most platforms. DAC7 non-compliance can trigger a full tax authority audit of the platform's own tax affairs — separate from the DAC7 reporting obligation. Platforms that demonstrate good data collection practices, including robust VAT validation with audit trails, are generally treated more favourably in compliance reviews than those that have minimal records.

## Technical Architecture for DAC7 Compliance

A DAC7-compliant data collection system has three main components: the seller onboarding flow (collecting and verifying data), the ongoing maintenance system (re-verifying data at the required intervals), and the annual report generation pipeline (aggregating transaction data per reportable seller and producing the XML report). Each component has distinct requirements, and the VAT validation API touches all three.

At onboarding, validate the VAT number in real time and store the full API response including the request_id for traceability. If VIES is unavailable, queue the number for re-validation and mark the seller record as pending_vat_verification. Block sellers from receiving payments until the VAT number is either confirmed or explicitly exempted (for sellers who are not VAT-registered). Requiring a valid VAT number before first payment is the most defensible compliance posture and simplifies the annual report — all payable sellers have verified tax data.

For the re-verification requirement (every 3 years minimum), run a quarterly sweep of all active sellers whose VAT validation is more than 30 days old or whose last re-verification was more than 2.5 years ago. The quarterly sweep provides a safety margin before the 3-year deadline and catches status changes early. If a re-validation returns inactive, flag the seller record for review, contact the seller to update their details, and suspend new payments until the situation is resolved. Log every re-validation with a timestamp — this is your evidence of compliance if an authority conducts a review.

The annual report requires aggregating transaction data per seller per quarter. Design your transaction schema with DAC7 reporting in mind from the start: store a seller_id on every transaction, store the consideration amount and transaction date, and index by (seller_id, year, quarter) for efficient aggregation. Generating the report should be a query, not a custom extraction job. If you are building the platform in 2026, the time to add these indexes is at schema design, not 3 months before the January 31 reporting deadline.

## Multi-Country Seller Considerations

Many marketplace sellers operate across multiple EU countries — a German freelancer selling services to French and Spanish buyers, or an Italian goods seller shipping to all 27 member states. For DAC7 purposes, the seller's VAT number is the key identifier, and it is tied to a single EU member state. A German seller has a DE-prefix VAT number regardless of where their buyers are located. Validate the seller's VAT number against the VIES entry for their registered country, not against the countries where their buyers are.

For sellers registered in multiple EU member states (which is unusual but legally possible for large companies with subsidiaries), they may provide VAT numbers from different countries at different times. Store each validated VAT number with its own validation record and timestamp. If a seller updates their VAT number from a DE prefix to a NL prefix, validate the new number and store it as an additional record — do not overwrite the historical record. The annual DAC7 report should reference the VAT number that was active during the reporting period.

Non-EU sellers present a specific challenge under DAC7. Sellers based outside the EU may not have an EU VAT number at all, but they may still be reportable if they sell goods to EU buyers or rent EU property. For non-EU sellers, DAC7 requires collection of the national tax identification number from their home country (if one exists). Your collection flow needs to handle both paths: EU sellers who have a VAT number to validate against VIES, and non-EU sellers who provide a national TIN that cannot be validated via VIES. Store non-EU TINs with a note indicating they could not be VIES-validated and include them in the report with an appropriate indicator.

DAC7 compliance is ultimately a data quality and process problem, not just a technical one. The VAT validation API call is straightforward — the hard part is building a reliable collection workflow, a re-verification schedule, and a reporting pipeline that runs on time every year. Start building these processes early, before you hit the reporting threshold, so that DAC7 compliance is a routine operation rather than an emergency scramble in January.

---

## German VAT Number Validation: USt-IdNr Format, VIES, and Common Errors
https://www.taxid.dev/blog/german-vat-number-validation · 2026-04-24

Complete guide to validating German VAT numbers (Umsatzsteuer-Identifikationsnummer) via API. Format, VIES integration, and common format mistakes.

Germany is the largest economy in the EU and the most common source of B2B customers for European SaaS and e-commerce platforms. Correctly validating German VAT numbers — the Umsatzsteuer-Identifikationsnummer, commonly abbreviated USt-IdNr — is a routine requirement for any developer handling EU compliance. This guide covers the exact format, the VIES validation flow specific to Germany, the common errors that cause silent failures, and complete code examples for Node.js, Python, and PHP.

> German VAT numbers (Umsatzsteuer-Identifikationsnummer, USt-IdNr.) are issued by the [Bundeszentralamt für Steuern (BZSt)](https://www.bzst.de/DE/Unternehmen/Umsatzsteuer/USt-IdNr/ustidnr_node.html). Validation via [VIES](https://ec.europa.eu/taxation_customs/vies/) queries the BZSt database in real time.

## The German VAT Number Format (USt-IdNr)

A German VAT number follows a strict format: the prefix DE followed by exactly 9 digits. There are no letters, no separators, and no variable length — it is always DE + 9 digits. A valid example is DE123456789. The German national tax authority that maintains VAT registrations is the Bundeszentralamt für Steuern (BZST), headquartered in Bonn. VIES routes all German validation requests to the BZST system, which is generally well-maintained but has scheduled maintenance windows on Sunday mornings (typically 01:00-07:00 CET).

The 9-digit number after the DE prefix is not entirely random — it has a check digit structure, but implementing check digit validation is generally not worth the effort unless you are building a form that provides immediate feedback before making an API call. The TaxID API performs both format validation (DE + exactly 9 digits) and check digit validation locally before making the VIES call, so format errors return immediately with format_invalid status without consuming your monthly quota.

One important distinction: the USt-IdNr is different from the Steuernummer (tax number). The Steuernummer is a national tax identification number used for domestic German tax purposes. It is not a VAT number and cannot be used for VIES validation or reverse charge purposes. German businesses often have both — the Steuernummer for domestic tax filings and the USt-IdNr for international trade. If a customer provides a Steuernummer instead of a USt-IdNr, format validation will catch it (Steuernummern have a different format and do not start with DE in the VIES sense).

## Common German VAT Format Errors

The most frequent input error with German VAT numbers is customers omitting the DE prefix and submitting just the 9-digit number. The correct response is to ask for the full number including prefix — do not silently prepend DE, because a 9-digit number without a country prefix could theoretically be from another country that uses the same digit count (though Germany is the most likely in practice).

- Missing prefix: '123456789' instead of 'DE123456789' — the most common error. Reject and ask for the full number.
- Wrong digit count: German numbers are always 9 digits after DE. '12345678' (8 digits) or '1234567890' (10 digits) are invalid.
- Spaces or dots: users copy-paste from invoices that may format the number as 'DE 123 456 789' or 'DE.123.456.789'. Strip all non-alphanumeric characters before validation.
- Lowercase prefix: 'de123456789' — normalise to uppercase before validation. The TaxID API accepts lowercase and normalises internally.
- Steuernummer submitted: German Steuernummern follow formats like '123/456/78901' — completely different from USt-IdNr. If a customer provides one, explain they need the USt-IdNr specifically.
- DE prefix repeated: 'DEDE123456789' — rare but happens when a system concatenates country code + number that already includes the prefix.

## German Company Types and VAT Registration

Not all German businesses are VAT-registered. Kleinunternehmer (small business owners) operating under §19 UStG are exempt from VAT registration and charge no VAT — they do not have a USt-IdNr. If a German B2B customer claims they are VAT-exempt, they cannot receive reverse charge treatment and you must charge the applicable VAT rate. This is a legitimate scenario, particularly for freelancers and small service businesses.

German companies that are VAT-registered include GmbH (Gesellschaft mit beschränkter Haftung), AG (Aktiengesellschaft), UG (Unternehmergesellschaft, a low-capital GmbH variant), GbR (Gesellschaft bürgerlichen Rechts) when above the threshold, and sole traders (Einzelunternehmer) above the Kleinunternehmer threshold. VIES will return the company name in the format registered with BZST, which is typically the legal trading name. For holding companies or subsidiaries, the company name returned may be the parent group name rather than the subsidiary's trading name.

Some German companies have multiple VAT numbers — for example, large companies with separate legal entities for different business units. Each entity has its own USt-IdNr. Validate the specific entity's number, not the group's. If a customer provides a parent company's VAT number for a subsidiary, VIES will return the parent company name, which will not match the entity named on the invoice. This discrepancy can cause audit issues for the customer.

## VIES and Germany's BZST: What to Expect

Germany's BZST system is one of the more reliable VIES member state endpoints, with uptime typically above 99% during business hours. The most predictable downtime window is Sunday morning maintenance, approximately 01:00-07:00 CET. During this window, all German VAT number validations will return service_unavailable regardless of whether the number is valid.

For German VAT numbers, VIES returns the company name and registered address in the majority of cases. Germany does not restrict sharing of company name and address data through VIES, unlike some member states (the Netherlands and Sweden occasionally return null for address). The company name is the name as registered with the BZST — for most GmbH and AG companies this is the full legal name including the legal form designation (e.g., 'Acme Software GmbH' rather than just 'Acme Software').

Response times for [German VAT validation](/validate-vat/de) via TaxID are under 10ms for cached results (numbers validated in the last 24 hours) and typically 200-600ms for uncached live VIES lookups. The TaxID API caches active German VAT numbers for 24 hours in Redis — the same number validated twice within 24 hours returns the cached result from the first call. Invalid and inactive numbers are cached for 1 hour.

## German VAT Rates

Germany applies a standard VAT rate of 19% (Umsatzsteuer) to most goods and services. A reduced rate of 7% applies to food, books, newspapers, cultural services, local public transport, and certain agricultural products. A temporary reduced rate of 7% was applied to restaurant meals following COVID policy changes and has been extended — check the [Germany VAT rates page](/vat-rates/de) for the current rates via API.

For SaaS and digital services sold to German consumers (B2C), you must charge 19% German VAT if you are above the EU-wide €10,000 OSS threshold. For German B2B customers with a valid USt-IdNr, zero-rate reverse charge applies. Germany participates fully in the EU One Stop Shop (OSS) scheme, so you can register for OSS in any EU member state and use it to account for German consumer VAT without a German VAT registration.

## Code Examples

### cURL

### Node.js / TypeScript

### Python

## Frequently Asked Questions

- Is DE always the VIES country code for Germany? Yes. Germany uses DE in VIES, matching its ISO 3166-1 alpha-2 code. Unlike Greece (which uses EL instead of GR), Germany's VIES code matches ISO.
- What is the difference between USt-IdNr and Steuernummer? The USt-IdNr (DE + 9 digits) is for international VAT identification and VIES validation. The Steuernummer is for domestic German tax filings and has a different format. Only the USt-IdNr is relevant for EU reverse charge.
- Does VIES return the company name for all German businesses? In most cases yes — Germany does not restrict sharing company name via VIES. Some holding companies or recently registered businesses may temporarily return null for company_name.
- How long does VIES take for German validations? [Cached German VAT numbers](/validate-vat/de) respond in under 10ms. Uncached live VIES lookups to BZST typically complete in 200-600ms outside maintenance windows.
- When does BZST take VIES offline? Typically Sunday mornings 01:00-07:00 CET. During this window, German validations return service_unavailable. Implement the allow-and-re-validate pattern for checkout flows.

## Validating German VAT Numbers at Scale

For applications that process large numbers of German B2B customers — ERP systems importing supplier data, marketplace platforms onboarding German sellers, or accounting software syncing customer records — batch or high-frequency validation requires some additional considerations. The TaxID API handles German VAT validation at up to 1,000,000 requests per month on published pricing tiers. For bulk imports, implement a rate limiter on your side to stay within your plan's monthly quota and avoid hitting per-minute rate limits.

For validating a large list of German VAT numbers (for example, migrating a database of 10,000 supplier records), process them in batches of 50-100 with a short delay between batches. Cache the results locally — if the same VAT number appears multiple times in your dataset, validate it once and reuse the result. Store the validation timestamp alongside the result: you need to know not just whether the number was valid, but when it was checked, for audit purposes.

For German numbers specifically, the BZST system has a lower tolerance for rapid sequential requests than some other member states' VIES endpoints. If you are sending many German validation requests in quick succession, you may see occasional slow responses or timeouts that are not typical of normal operation. TaxID handles this transparently — our caching layer means that repeated lookups for the same number do not create additional load on BZST, and our timeout handling returns service_unavailable rather than hanging.

## Using German VAT Data for Invoice Compliance

When VIES returns company_name and address for a German customer, use those values on your invoice rather than whatever the customer self-reported. The VIES-registered name and address are what German tax authorities check during B2B invoice audits. A mismatch between the invoice recipient's details and their VIES registration data can cause the customer to have their input VAT claim rejected — which is their problem, not yours, but it creates support issues and damages the customer relationship.

German GmbH and AG companies often have formal legal names that differ from their trading names. For example, a company trading as 'Acme Software' might be legally registered as 'Acme Software Solutions GmbH'. Use the legal name from VIES on the invoice, and optionally display the trading name in the subject line or invoice notes. If the VIES response returns null for company_name (rare for German companies but possible for very recently registered businesses), fall back to the name the customer provided and add a note in your records that VIES did not return a name at validation time.

## Integration Testing with German VAT Numbers

When writing integration tests for German VAT validation, you need a stable set of test numbers to validate against. The VIES system does not provide official test numbers, but you can use well-known German public institutions and organisations whose USt-IdNr are publicly registered. Alternatively, use the TaxID API's format_invalid response as your test case for malformed inputs — you do not need a real invalid number, you can just send a structurally incorrect string like 'DE12345' (too short) or 'DEXYZ123456' (non-numeric).

For CI/CD pipelines, mock the TaxID API response rather than making real API calls in automated tests. Real API calls in tests consume your monthly quota, are non-deterministic (VIES can be slow or unavailable during a test run), and add latency to your test suite. The Vitest mock pattern from the [Node.js VAT validation tutorial](/blog/nodejs-eu-vat-validation-tutorial) works well for German-specific tests — just include DE as the country_code in your mock responses.

For manual testing against the live API during development, use the official BZST-registered test number DE115235681 (Bundeszentralamt für Steuern itself) — it is a real, stable, active German VAT number that will always return a valid active response from VIES. This is documented in the TaxID API docs. For testing the inactive path, you need to find a deregistered number — the VIES web interface at ec.europa.eu/taxation_customs/vies can be used manually to identify numbers that return inactive status for specific countries.

German VAT validation is straightforward once you have the format right and BZST maintenance windows accounted for. The [TaxID validate-vat/de page](/validate-vat/de) has the complete format reference, code examples in four languages, and the full FAQ specific to German validation. Use it as a reference alongside this guide when building your integration.

Germany is the EU's largest economy and often the first country a developer needs to support when building EU VAT compliance. The format is simple, the VIES endpoint is reliable, and the data quality (company name and address returned) is among the best in the EU. Once you have German validation working correctly, extending to the other 26 member states is mostly a matter of handling the format variations — all of which are documented on the individual [validate-vat country pages](/validate-vat/de).

---

## Vatstack vs TaxID: Which EU VAT API Is Right for You?
https://www.taxid.dev/blog/vatstack-vs-taxid · 2026-04-17

Side-by-side comparison of Vatstack and TaxID for EU VAT validation in 2026. Free tier limits, pricing at scale, latency, webhook support, and migration guide.

If you are evaluating EU VAT validation APIs and Vatstack is on your list, this comparison will tell you exactly what you get, what you give up, and when each service is the right choice. We built TaxID, so this review is not neutral — but we link to Vatstack's own documentation for every claim so you can verify independently, and we are honest about where Vatstack is the better choice.

## Quick Verdict

For developers building B2B SaaS, e-commerce checkouts, or API integrations with 100-100,000 validations per month and no need for webhooks: TaxID is the better fit. Higher free tier (100 vs 20 req/month), lower latency (sub-10ms cached vs ~300ms), higher scale ceiling ($149/month for 100K vs Vatstack's paid max of 1,000/month), and transparent VIES downtime handling. For teams that need webhook callbacks when a VAT registration status changes asynchronously: Vatstack has this feature and TaxID does not currently support it.

## Free Tier: 100 vs 20 Requests per Month

Vatstack's free tier is 20 requests per month. At 20 requests, you can validate roughly one customer per working day. This is adequate for initial API exploration and verifying your integration works, but it is not enough to run a real prototype or demo the feature to prospective customers. You will hit the limit within a few days of actual development.

TaxID's free tier is 100 requests per month. That is enough to validate 3-4 customers per working day, run a small closed beta, or handle a low-volume MVP with real customers. It is not a large number, but it is 5 times more than Vatstack and sufficient for genuine early-stage usage. There is no credit card required for either service's free tier — both are genuinely free to start.

The practical implication: if you are starting a new integration and want to see how the API behaves under real conditions before committing to a paid plan, TaxID's free tier gives you five times the runway. For a SaaS with 50 B2B signups per month, TaxID's Starter plan ($19/month for 10,000 validations) covers 200 monthly onboardings with periodic re-validations — Vatstack's entry tier maxes out at 1,000 total validations per month.

## Pricing at Scale: The Real Difference

The free tier comparison undersells the pricing gap because Vatstack's paid plan caps at 1,000 validations per month. If your application needs more than 1,000 validations per month — which happens quickly once you factor in re-validations, bulk imports, and high-growth B2B signups — Vatstack requires contacting their sales team for a custom quote. TaxID's public pricing covers up to 1,000,000 validations per month across four published tiers without any sales interaction.

The unpublished pricing issue matters beyond cost. If you cannot get a price without a sales call, you cannot put VAT validation into your cost model, justify the line item to your CFO, or plan for growth. TaxID's public pricing page lets you build the integration knowing exactly what you will pay at 10x, 100x, or 1,000x current volume without any sales interaction.

## Latency and Caching Architecture

TaxID caches validated active VAT numbers in Upstash Redis for 24 hours. For repeat lookups — the same VAT number validated within the last 24 hours — the API responds in under 10 milliseconds. This matters for checkout UX: a 10ms validation call is invisible to the user. A 300ms validation call is perceptible. At 1-2 seconds (raw VIES latency for some countries), users notice and some abandon the form.

Vatstack's documentation describes a REST JSON API that wraps VIES but does not describe a caching layer for validated results. Response times for Vatstack are typically in the 200-400ms range based on community reports — consistent with an API that calls VIES on every request without caching active results. For low-volume applications or background jobs, this latency difference is irrelevant. For synchronous checkout validation where a user is waiting, 10ms vs 300ms is a material UX difference.

## VIES Downtime Handling

VIES goes offline regularly — see [VIES Downtime: How to Build a Resilient Validation Flow](/blog/vies-downtime-resilience) for the full picture. The key difference in downtime handling: TaxID returns an explicit service_unavailable status code that your application can catch and handle gracefully. You know exactly why the validation failed and can implement the appropriate fallback (allow through, queue for re-validation, show soft error UI).

Vatstack does not document a specific service_unavailable status equivalent. VIES errors appear to surface as generic error responses, which means your application has to guess whether a failed validation is because the number is invalid or because VIES is unreachable. Getting this distinction wrong in either direction causes problems — blocking valid customers or silently approving invalid ones during outages.

## Where Vatstack Wins

Vatstack has one feature TaxID does not currently support: webhooks. If your workflow requires async callbacks when a VAT registration status changes — for example, you want to be notified automatically when one of your customers deregisters their VAT number — Vatstack supports this natively. TaxID is a synchronous REST API only. Each validation request returns an immediate result; there is no subscription mechanism for status change notifications.

Vatstack also has a non-EU VAT validation dashboard and team workflow features that are more developed than TaxID's dashboard. If your primary use case involves a non-developer team reviewing validation history, approving exceptions, or managing a shared account, Vatstack's UI may be better suited. TaxID is built for developer-driven integrations where the application handles all validation logic programmatically.

## Migration Guide: Switching from Vatstack to TaxID

Migrating from Vatstack to TaxID requires two changes to your application code: the endpoint URL and the authentication header. Everything else — the response structure around valid, company_name, and address — is compatible with minimal field mapping.

The main structural difference is that TaxID uses RESTful path parameters (/validate/DE/DE123456789) while Vatstack uses a query string (?query=DE123456789). The response fields valid, company_name, and address are compatible. TaxID adds a status field (active, inactive, format_invalid, service_unavailable) that Vatstack does not have — you should add handling for service_unavailable if you are migrating from a Vatstack integration that only checks the boolean valid field.

## Common Migration Questions

- Do I need to re-validate existing customers? No — if you have validated customer VAT numbers with Vatstack and stored them, those validations remain valid. You only need to re-validate if your periodic re-validation cycle is due.
- [Can I run both APIs in parallel?](/docs) Yes — TaxID and Vatstack can run simultaneously during a migration. You can send the same validation request to both, compare results, and cut over when confident.
- What about Vatstack's tax rate lookups? TaxID has a separate /api/v1/rates/{country} endpoint for VAT rates. See the [VAT rates pages](/vat-rates/de) for the data. It is a separate call, not bundled into the validation response.
- Do I need to update my webhook handlers? Only if you are using Vatstack webhooks — TaxID does not have webhook equivalents. You would need to implement polling or scheduled re-validation instead.

## Developer Experience Comparison

TaxID's API uses standard RESTful path parameters: GET /api/v1/validate/{country}/{vat_number}. Authentication uses the standard HTTP Authorization: Bearer token pattern. Error responses use Stripe-style machine-readable status codes (service_unavailable, format_invalid, inactive) that map cleanly to application logic. The API is designed so you can start making requests with a two-line cURL command and has no required SDK or client library.

Vatstack uses a query string parameter approach: GET /v1/validations?query=DE123456789 with authentication via a non-standard X-API-KEY header. Both work fine, but the path parameter approach is more idiomatic REST and integrates more naturally with URL-based routing and logging infrastructure. The authentication header difference means you need to update your header configuration when migrating, but the actual code change is a one-liner.

Both services provide documentation that covers authentication, the main validation endpoint, and response fields. TaxID's documentation includes explicit guidance on handling service_unavailable — the downtime case — which is the most important edge case for production checkout flows. If the documentation of a VAT API does not mention VIES downtime handling, it is a signal that the API surfaces it as a generic error rather than a distinguishable status code.

## Which Should You Choose?

The decision comes down to two questions. First: do you need webhooks for asynchronous VAT status change notifications? If yes, Vatstack has this feature and TaxID does not. This is a genuine product difference, not a gap that can be worked around easily. If webhooks are essential to your workflow, Vatstack is currently the only option among commercial EU VAT APIs that offers them.

Second: what is your expected validation volume? If you need more than 1,000 validations per month on a published pricing tier without a sales conversation, TaxID is the only option with public pricing at that scale. At 10,000 validations per month, TaxID is $19 with a published price. At the same volume with Vatstack, you are in a custom pricing conversation with no public benchmark to evaluate against. For teams that need to forecast costs, plan infrastructure budgets, or justify spend to a CFO, predictable public pricing matters.

For most developers building B2B SaaS checkouts, marketplace onboarding flows, or ERP integrations — where the primary need is fast, reliable VAT validation with clear error handling and growth headroom — TaxID is the better fit at most volume tiers. For teams with specific webhook requirements or those deeply integrated into the Vatstack ecosystem who have not hit the scaling ceiling, staying with Vatstack is a reasonable choice.

## Real Cost at Different Company Stages

The right pricing tier comparison depends on where you are in your company's lifecycle. At early stage (0-50 B2B customers, under 500 validations per month), both TaxID and Vatstack are free or near-free. The free tier differences matter less than the developer experience, documentation quality, and how easy it is to test error scenarios. Use the free tier of both if you want to compare integration quality directly before committing.

At growth stage (50-500 B2B customers, 500-5,000 validations per month including re-validations and API calls from other features), TaxID's Starter plan ($19/month, 10,000 validations) covers this range comfortably. Vatstack's paid entry tier ($9/month) caps at 1,000 validations — you will need to contact their team for pricing if you are above that. The $10 monthly difference between the plans is immaterial; the difference in what you get (10,000 vs 1,000) is significant.

At scale (500+ B2B customers, 10,000+ validations per month), TaxID's Growth ($49/month, 50,000 validations) and Business ($149/month, 100,000 validations) plans have published prices. Vatstack's pricing at this volume is opaque. For finance and operations teams that need predictable cost modelling — essential for Series A and later companies — TaxID's public pricing ladder is a material advantage. The total cost of switching to a provider that requires sales conversations at scale is not just the API fee; it is the time cost of procurement and negotiation.

For non-EU companies integrating EU VAT validation as part of a global tax compliance stack, consider whether you need a specialist EU VAT API or a broader global tax platform. If EU VAT is one of many tax regimes you need to handle, a platform like Avalara or LookupTax may be more appropriate despite being more expensive. If EU VAT is your primary or only tax validation requirement, a specialist like TaxID is lower cost, lower complexity, and faster to integrate. The [free EU VAT API comparison](/blog/free-eu-vat-validation-apis) covers more of the landscape.

One final consideration: support quality. When you have a billing issue related to VAT validation, you need to be able to get a fast answer. TaxID's support is developer-focused — the request_id in every API response is your trace identifier for any support ticket. Vatstack has a similar support model. For both services, the support quality at the free tier is primarily self-service documentation; paid tiers typically include email support with SLA. Evaluate the documentation quality of each provider before committing to an integration — good documentation means fewer support tickets in the first place.

Regardless of which provider you choose, the integration pattern is the same: validate on signup, store the result with a timestamp, apply the correct tax treatment to every invoice, re-validate quarterly. The API you use to power that pattern should be reliable, well-documented, and priced predictably for your expected volume. Both TaxID and Vatstack meet the baseline bar for production use.

---

## B2B VAT Exemption in EU SaaS: What Your Billing System Must Do
https://www.taxid.dev/blog/eu-saas-b2b-vat-exemption · 2026-04-10

How to implement EU VAT reverse charge correctly in a SaaS billing system. Covers VAT collection, VIES validation, zero-rate logic, and compliant invoice generation.

Building a SaaS product that sells to EU businesses means navigating a tax rule that is simple in principle and surprisingly complicated in practice: the EU reverse charge mechanism. The rule says that when a registered EU business buys from another EU business across borders, the seller does not charge VAT — the buyer accounts for it in their own country instead. But applying zero-rate treatment without correctly validating the buyer's VAT registration is a compliance failure, not a simplification. This guide walks through the complete billing implementation: how to collect VAT numbers, validate them, apply the correct tax treatment in your billing engine, generate compliant invoices, and handle the edge cases that trip up most engineering teams.

> The B2B reverse charge mechanism is established under [EU VAT Directive 2006/112/EC, Articles 44 and 196](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32006L0112). Each EU member state has implemented it into national law — rules may vary in detail by country.

## The EU Reverse Charge Mechanism: What It Actually Means

The reverse charge mechanism is an EU VAT rule that shifts the responsibility for accounting for VAT from the seller to the buyer in cross-border B2B transactions. When you (a German SaaS company) sell to a French company with a valid VAT number, you do not charge 19% German VAT on the invoice. Instead, you issue a zero-rate invoice and the French company accounts for the equivalent French VAT in their own VAT return — they both add it as output tax and deduct it as input tax, netting to zero. This is called 'self-accounting' or 'the buyer accounts for the tax'.

The mechanism exists to simplify cross-border VAT administration and prevent double taxation. Without it, EU businesses selling across borders would need to register for VAT in every country they sell to. With reverse charge, the seller can issue zero-rate invoices to verified B2B customers across all 27 EU member states without any additional VAT registration (unless they also have B2C sales above the OSS threshold of €10,000 per year). From a cash flow perspective, it is also advantageous — you are not floating VAT on behalf of your customer between invoice and payment.

The critical condition that unlocks reverse charge treatment is a valid VAT registration number. Without a valid number confirmed by VIES, the transaction is treated as B2C — you must charge VAT at the applicable rate for the buyer's country (under OSS rules) or your own country's rate if you are below the pan-EU threshold. There is no middle ground: either the buyer has a valid VAT registration that you have verified, or you charge VAT. Getting this wrong in either direction creates compliance exposure.

> Applying zero-rate without VIES verification makes your company liable for the VAT. Charging VAT to a customer who provided a valid VAT number is also incorrect — it creates overpayment issues and potential VAT fraud liability in some jurisdictions. Validate every time.

## Step 1: Collecting the VAT Number at Signup

The right time to collect a VAT number is at the billing details step of your signup flow — not after payment confirmation, not during the first invoice run. Collecting it at signup gives you the opportunity to validate it in real time and display the company name back to the user as confirmation, which significantly reduces input errors. Users who see 'Acme GmbH, Musterstraße 1, Berlin' displayed after entering their VAT number know immediately that the number is correct.

Make the VAT number field optional, not required. Not every business customer has a VAT registration — sole traders below the registration threshold, non-EU businesses, and companies in certain sectors may not be VAT-registered. Making it optional and validating only when provided is the correct UX pattern. Add a label that explains the field: 'EU VAT number (optional — for zero-rate B2B treatment)'. This reduces support tickets and sets the right expectation.

From a technical perspective, collect the VAT number as a plain text input and strip whitespace before validation. Users copy-paste VAT numbers from invoices and often include spaces, dots, or dashes. The TaxID API accepts numbers with or without spaces and normalises them internally, but cleaning on your side before submission is good practice. Store the number exactly as the API returns it in the vat field of the response — this is the normalised, canonical form.

## Step 2: Server-Side VAT Validation

Client-side validation (the React component above) is for UX feedback only — it is never authoritative for billing purposes. The real validation must happen server-side before you apply zero-rate treatment to any invoice. Never trust the client to tell you whether a VAT number is valid; validate it yourself from your backend using your own API key.

Create a server-side API route that validates the VAT number and returns the result. This route is called both from the signup component in real time and from your billing system before each invoice generation. The route should validate the number, store the result (see the [complete validation guide](/blog/eu-vat-validation-guide) for the storage schema), and return a clean response to the caller. Do not expose the TaxID API key to the frontend.

## Step 3: Applying Zero-Rate in Your Billing Engine

Once you have a confirmed valid VAT number, you need to tell your billing engine to apply zero-rate treatment to this customer's invoices. The exact implementation depends on your billing provider. For [Stripe Checkout integration](/use-cases/stripe-eu-vat), you update the customer's tax_exempt status and apply a tax ID. For Paddle, you set the customer's country and business flag. For custom billing systems, you store the tax_class field and apply the correct logic in your invoice generation code.

The key principle: the zero-rate applies to the customer account permanently (until their VAT registration changes), not just to the first transaction. Once you have validated a customer as B2B, tag their account in your database with vatStatus: 'b2b', vatNumber, vatValidatedAt, and companyName. Every subsequent invoice generation should read this status rather than re-calling the validation API on every invoice — but you should re-validate quarterly to catch deregistrations.

## Step 4: Generating Compliant Invoices

A zero-rate B2B invoice must include specific elements to be legally compliant under EU VAT law. Missing any of these can invalidate the invoice for your customer's accounting purposes and expose you to audit risk. The required elements for a reverse charge invoice: your VAT registration number, the buyer's VAT registration number, a statement that reverse charge applies (the exact wording varies by country but 'Reverse charge — VAT to be accounted for by the customer' is accepted across all EU member states), and the net amount without VAT. Do not include a VAT line at all — even with 0% — as this can be misinterpreted.

Store all of these values at invoice generation time, not at payment time. Invoice data must be immutable once issued. If a customer's VAT status changes after you issue an invoice, the original invoice remains valid as-is — you issue a corrective invoice for subsequent periods, not a retroactive amendment. This is why storing the validation timestamp and the company name at the time of invoice generation matters: it proves the number was valid when the invoice was issued.

For the buyer's address on zero-rate invoices, use the registered address returned by VIES (the address field in the API response) rather than the shipping or billing address the customer entered. The VIES-registered address is the legally relevant one for reverse charge purposes. Some EU countries' tax authorities specifically check that the address on a zero-rate invoice matches the VIES registration data during audits.

## Edge Cases Your Billing System Must Handle

### Deregistration After Signup

A B2B customer who was validly registered at signup may deregister their VAT number months later — they close the business, restructure, or voluntarily deregister because they fell below the threshold. If you continue issuing zero-rate invoices to a deregistered customer, those invoices are incorrect and your company is liable for the VAT on them. This is why periodic re-validation matters: at minimum, re-validate all active B2B customers at the start of each billing quarter. If a re-validation returns inactive, switch the customer to B2C billing immediately for the next invoice cycle and notify them.

### VIES Unavailable at Invoice Time

If VIES is unavailable when you attempt to re-validate before generating a quarterly invoice, do not block the invoice run. Use the last successful validation result if it is less than 30 days old — the risk of a business deregistering in a short window while VIES happens to be down is low and acceptable. If the last validation is more than 30 days old and VIES is unavailable, generate the invoice with a note in your system to re-validate and issue a correction if needed once VIES recovers. See [VIES Downtime: How to Build a Resilient VAT Validation Flow](/blog/vies-downtime-resilience) for the full resilience strategy.

### Customers Without a VAT Number

Not all business customers are VAT-registered. Small businesses below the national registration threshold, businesses in certain exempt sectors, and new businesses that have not yet received their VAT number are all valid B2B customers without a VAT number. For these customers, apply the standard B2C VAT treatment — charge VAT at the applicable rate. You cannot give them reverse charge treatment without a valid VAT number, regardless of their business status. Some SaaS companies offer a manual exception process for large enterprise customers pending VAT registration, but this requires legal review and explicit documentation.

## Common B2B VAT Billing Mistakes

- Applying zero-rate based on self-reported business status rather than VIES validation: a customer saying 'I am a business' is not sufficient. You need a validated VAT number.
- Not storing the validated VAT number on the invoice: the customer's VAT number must appear on each zero-rate invoice for it to be legally valid for their accounting.
- Forgetting the reverse charge statement on the invoice: 'Reverse charge — VAT to be accounted for by the customer' or equivalent must appear on zero-rate invoices.
- Re-validating on every invoice rather than quarterly: unnecessary API calls. Validate at signup, then quarterly. Re-validate immediately on billing detail changes.
- Not handling deregistration: implement a quarterly re-validation job that checks all active B2B customers and switches deregistered ones to B2C billing.
- Applying zero-rate to same-country transactions: reverse charge only applies to cross-border EU transactions. If your company and the customer are in the same EU country, normal domestic VAT rules apply regardless of B2B status.
- Using the customer's reported address instead of the VIES address on invoices: always use the VIES-registered address on zero-rate invoices to pass audit verification.

## OSS Registration and Cross-Border B2C Sales

The One Stop Shop (OSS) is the EU's mechanism for simplifying VAT compliance on cross-border B2C digital services. If your SaaS has both B2B customers (zero-rated via reverse charge) and B2C customers (consumers without VAT numbers), you need to handle both regimes correctly. For B2C sales above €10,000 per year across all EU member states combined, you must either register for OSS in one EU country or register for VAT separately in each country where you have customers.

OSS does not change the B2B reverse charge rules — it only affects B2C. If a customer provides a valid VAT number, it is always B2B treatment regardless of your OSS registration status. If they do not provide one (or it is invalid), and the total cross-border B2C revenue exceeds €10,000 per year, OSS applies. The practical implementation for a SaaS billing system: classify each customer as B2B (valid VAT number confirmed via VIES) or B2C (no valid VAT number) at signup, and apply the appropriate regime to every invoice for that customer. The classification can change if a B2C customer later provides a valid VAT number — update their billing profile and apply B2B treatment from the next invoice cycle.

The €10,000 OSS threshold applies to the sum of all cross-border B2C sales to all 27 EU member states combined. It is not per-country. If you have €8,000 in German B2C sales and €3,000 in French B2C sales, you are over the threshold even though neither country individually exceeds it. Once over, all cross-border B2C sales require OSS or local registration — you cannot selectively apply it only to the countries where you have exceeded a local sub-threshold.

## Implementation Checklist

- Add optional VAT number field to your billing/signup flow with clear label explaining its purpose.
- Validate the VAT number server-side via TaxID API on submission — never trust client-side validation alone.
- Store the full validation response (status, company_name, address, request_id, checkedAt) for audit compliance.
- Tag the customer record as b2b or b2c based on validation result — handle service_unavailable as pending with re-validation queued.
- Configure your billing engine (Stripe, Paddle, custom) to apply zero-rate for b2b customers in other EU countries.
- Include the customer's validated VAT number and 'Reverse charge' statement on every zero-rate invoice.
- Run a quarterly re-validation job for all active B2B customers to catch deregistrations.
- Monitor the re-validation job output — switch deregistered customers to B2C billing and notify them.
- Document your validation process for tax audit readiness — retain validation records for the legally required period (7-10 years in most EU jurisdictions).

---

## VIES Downtime: How to Build a Resilient VAT Validation Flow
https://www.taxid.dev/blog/vies-downtime-resilience · 2026-04-03

VIES goes down regularly. Learn how to build EU VAT validation that handles service_unavailable gracefully — with allow-and-re-validate, cached fallbacks, and Express.js middleware patterns.

VIES — the EU's official VAT Information Exchange System — is the only authoritative source for validating EU VAT numbers in real time. It is also a SOAP service built on early-2000s infrastructure that goes offline several times per month, sometimes for hours at a time. Every production checkout or onboarding flow that validates EU VAT numbers will eventually receive a service_unavailable response. How you handle it determines whether legitimate customers with valid VAT numbers get blocked or sail through. This post covers every strategy in detail, with production-ready code for Express.js, background re-validation jobs, circuit breakers, and test patterns.

> VIES is operated by the European Commission. Official documentation and the SOAP endpoint are available at [ec.europa.eu/taxation_customs/vies/](https://ec.europa.eu/taxation_customs/vies/). The Commission publishes planned maintenance windows on the VIES portal.

## Why VIES Goes Down: The Architecture Behind the Outages

VIES is not a single monolithic database. It is a federation of 27 separate national tax authority systems connected through a central routing gateway operated by the European Commission. When you submit a validation request, VIES routes it to the national system of the target country — Germany's Bundeszentralamt für Steuern (BZST), France's DGFiP, Spain's AEAT, and so on. Each national system is maintained by a different government agency on its own infrastructure and maintenance schedule.

This federated architecture means VIES can be unavailable in several distinct ways. The central gateway itself can be down — this makes all 27 countries unreachable simultaneously. Individual member state systems can be down — [Germany](/validate-vat/de) might be unavailable while [France](/validate-vat/fr) works fine. A specific country can return errors for some number prefixes but not others. And the gateway can be reachable but extremely slow, causing timeouts that look like outages from the client side.

Scheduled maintenance is the most predictable form of downtime. Germany typically takes BZST offline for several hours on Sunday mornings (Central European Time). France has quarterly DGFiP maintenance windows that are announced internally but not publicised externally. The VIES central gateway has its own maintenance schedule. Unscheduled outages — caused by infrastructure failures, DDoS events, or unexpected load spikes during tax season — are harder to predict and can last from minutes to several hours.

> A hard-fail on service_unavailable blocks a legitimate customer with a perfectly valid VAT number because their government's tax authority happened to be doing weekend maintenance. This is a UX failure, an audit risk (you have no re-validation record), and a revenue problem. Build the fallback from day one.

## The service_unavailable Response: What It Means and What It Does Not

The TaxID API returns a structured service_unavailable status when VIES cannot be reached for the requested country, rather than a generic 500 error or a timeout. This explicit status code is the key to building correct resilience logic. The response looks identical in structure to a successful validation — same fields, same format — but with status: 'service_unavailable' and valid: false. Critically, valid: false here does not mean the VAT number is invalid. It means 'we could not determine validity at this time'.

The difference between these two responses should drive entirely different code paths in your application. An inactive number means the business is not registered — block the transaction and ask the customer to correct their VAT number. A service_unavailable means you cannot check right now — allow the transaction, store the number, and re-validate later. If your code only checks the valid boolean, you will conflate these two very different situations and block legitimate customers every time Germany does maintenance.

Note also the cached field. The [TaxID API](/docs) caches validated active numbers in Redis for 24 hours. If a German customer was validated successfully 3 hours ago and VIES goes down, the next validation request for the same number returns cached: true with status: active — no service_unavailable, because the response comes from cache, not from VIES. The service_unavailable case only arises for numbers that have not been recently validated. This is why validating at signup (not just at payment) is a useful resilience strategy — it warms the cache for the payment flow.

## Strategy 1: Allow and Re-validate Async (Recommended for SaaS)

The most robust approach for [SaaS billing systems](/use-cases/saas-billing-eu) and subscription platforms: when you receive service_unavailable, allow the transaction to proceed, store the VAT number with a pending_revalidation flag, and run a background job to re-validate once VIES recovers. If the eventual re-validation returns invalid, you can then switch the customer to B2C billing for the next invoice and notify them. This pattern handles downtime completely transparently for the customer and maintains a clean audit trail.

The implementation has two parts: the checkout handler that catches service_unavailable and allows through, and the background job that processes the re-validation queue. The checkout handler should be written to create a complete audit record even for unavailable responses — you need to record that you attempted validation at a specific time, received service_unavailable, and queued the number for re-validation. That record demonstrates due diligence even if VIES was down.

## Strategy 2: Use the Cached Result

TaxID caches validated active VAT numbers in Upstash Redis for 24 hours. If a customer's VAT number was confirmed active 4 hours ago and VIES goes down 10 minutes before they complete checkout, the API returns the cached active result — status: active, valid: true, cached: true. From your application's perspective, the request succeeded normally. The service_unavailable case never surfaces.

You can leverage this by validating VAT numbers eagerly — at the time the customer enters them, not only at payment. In a typical SaaS signup flow, the customer enters their VAT number on the billing details step. Validate it immediately via an API call and display the result (company name, address) as a confirmation. This warms the cache so that by the time payment is processed — potentially minutes or hours later — the result is served from cache regardless of VIES status. Even if the customer comes back the next day, 24 hours of cache coverage means most repeat checkouts will be unaffected by downtime.

> Validate eagerly at input time, not just at payment. An immediate validation call when the customer types their VAT number improves UX (shows company name as confirmation), warms the Redis cache for the payment flow, and reduces the window where downtime can affect the checkout.

## Strategy 3: Soft Error UI

For low-volume workflows, manual order processes, or B2B sales with longer payment cycles, you can surface the unavailability directly to the customer: 'EU VAT validation is temporarily unavailable due to an EU system issue. Your VAT number has been saved and will be verified automatically. You can complete your order now — we will apply the correct tax treatment once validation is confirmed.' This approach is honest, non-blocking, and maintains an explicit audit trail.

The soft error approach is most appropriate when (a) you have a human review step before finalising invoices, (b) your order volume is low enough that a delayed tax classification does not create operational complexity, or (c) you are implementing validation for an internal tool rather than a customer-facing checkout. For high-volume automated billing, the allow-and-re-validate async strategy is more appropriate.

## Production Express.js Middleware with Timeout

A production VAT validation middleware needs to handle not just service_unavailable but also network errors and timeouts. VIES sometimes responds slowly enough to trigger connection timeouts even when it is nominally up. Treat timeouts and network errors the same as service_unavailable — allow through and queue for re-validation.

## Circuit Breaker Pattern for High-Volume APIs

If you are processing hundreds of VAT validations per minute and VIES goes down, continuing to make outbound API calls during an outage wastes resources and adds latency to every request. A circuit breaker pattern solves this: after a threshold of consecutive failures, the circuit 'opens' and subsequent calls fail immediately (returning service_unavailable) without making the outbound call. After a cooldown period, it enters a 'half-open' state and allows one probe request. If that succeeds, the circuit closes and normal operation resumes.

## Background Re-validation Job

The allow-and-re-validate strategy requires a background job that processes the pending queue once VIES recovers. Run it on a cron schedule — every 30 minutes is a good starting point. Implement exponential back-off for persistent failures: if a number fails re-validation because VIES is still down, double the retry interval up to a maximum of 4 hours.

## Testing Your Downtime Handling

The most important invariant to test is: your checkout must not block when VAT validation returns service_unavailable. Mock the API at the fetch level with Vitest or Jest to simulate all four response states: active, inactive, format_invalid, and service_unavailable. Verify that each state triggers the correct business logic path.

## Monitoring: What to Track and When to Alert

VIES downtime monitoring gives you visibility into which member states are having problems, how often your customers are affected, and whether your re-validation queue is clearing correctly. Track these metrics in your application monitoring (Datadog, Grafana, or even a simple Postgres table with a daily cron query).

- service_unavailable rate by country_code: a sudden spike for DE means BZST is down. Persistent elevation for a specific country indicates a prolonged outage. Baseline rate should be below 2% on a normal day.
- Pending re-validation queue depth: if the queue grows faster than your cron processes it, either VIES has been down for more than one cron cycle or your cron job has a bug. Alert if queue depth exceeds 500.
- Re-validation success rate: what percentage of pending records eventually resolve to active vs inactive? A high inactive rate might indicate fraudulent VAT number submissions, not VIES issues.
- Circuit breaker state changes: log every open/close event with a timestamp. This gives you a history of VIES outage start and end times.
- Checkout pass-through rate during downtime: what percentage of unavailable responses resulted in completed purchases? If it is significantly below your normal conversion rate, customers may be confused by your soft error UI.

## Timeout Configuration: How Long to Wait for VIES

Timeout configuration is a critical and often overlooked part of VIES resilience. Set your timeout too high and a slow VIES response blocks your checkout for 10+ seconds — long enough that most users abandon the page. Set it too low and you trigger unnecessary service_unavailable responses for countries (like Italy) that are genuinely slow but functional. The right balance depends on your use case.

For synchronous checkout flows — where the user is waiting — a 4-second timeout is the practical maximum. Beyond 4 seconds, user experience degrades significantly and cart abandonment rises. For asynchronous flows — background re-validation jobs or server-side order processing where the user is not waiting — you can afford 8-10 seconds, which catches most slow-but-functional VIES responses and reduces false service_unavailable reports.

Connect timeout (time to establish the TCP connection to the TaxID API) and read timeout (time to receive the full response body) should be configured separately where your HTTP client supports it. A 2-second connect timeout with a 4-second read timeout is a sensible starting point. The TaxID API itself has its own internal timeout for the VIES SOAP call — if VIES does not respond within the internal limit, the API returns service_unavailable rather than leaving your connection hanging indefinitely.

## VIES Scheduled Maintenance: When to Expect Downtime

Scheduled VIES maintenance is announced on the European Commission's taxation portal (ec.europa.eu/taxation_customs/vies), but these announcements are often posted with little advance notice and may not cover all member state maintenance windows. The most reliable way to stay informed is to monitor your own service_unavailable rate and correlate spikes with the day and time.

Based on historical patterns, these windows carry elevated downtime risk: Sunday mornings between 01:00-07:00 CET (German BZST maintenance); last Sunday of each quarter, 02:00-06:00 CET (French DGFiP quarterly releases); first Tuesday of each month, 22:00-02:00 CET (VIES gateway maintenance); major EU public holidays when staff are unavailable to respond to incidents. None of these windows are guaranteed — maintenance can be cancelled, extended, or rescheduled without notice.

The practical takeaway: if you are planning to onboard a large batch of B2B customers (CSV import, bulk migration, or a marketing campaign that will drive signups), schedule it for Tuesday through Thursday during business hours in the target member state's timezone. Avoid Sunday morning CET for German-heavy customer bases. And always have your re-validation queue running so that customers who hit a downtime window during signup are automatically validated once VIES recovers — no manual intervention required.

---

## Netherlands VAT Number Validation: BTW-nummer Format, VIES, and Code Examples
https://www.taxid.dev/blog/netherlands-vat-number-validation · 2026-03-27

Complete developer guide to validating Dutch VAT numbers (BTW-identificatienummer) via API. The unique NL...B.. format, VIES privacy behaviour, and code examples.

The Netherlands is one of the EU's most significant business hubs — home to a large number of EU headquarters, holding companies, and tech companies. Dutch VAT numbers (BTW-identificatienummer, shortened to BTW-nummer or BTW-nr) have a unique format that catches developers by surprise: the literal letter B embedded in the middle of the number is not a separator, it is a mandatory structural component. Omitting the B is the single most common Dutch VAT format error. This guide covers the exact format, what the B and the trailing digits mean, privacy-related VIES behaviour, and complete code examples.

> Dutch VAT numbers (BTW-identificatienummer) are issued and managed by the [Belastingdienst](https://www.belastingdienst.nl/) (Dutch Tax and Customs Administration). VIES routes Dutch validation requests to the Belastingdienst system in real time.

## The Dutch VAT Number Format (BTW-identificatienummer)

A Dutch VAT number consists of the prefix NL followed by 9 digits, then the literal letter B, then 2 more digits — 14 characters in total. The format is always NL[9 digits]B[2 digits]. A valid example is NL123456789B01. The B is always uppercase, always a literal B, and always present — there is no variation. A number like NL123456789 (missing B and 2 digits) is structurally invalid.

The 9-digit block is derived from the RSIN (Rechtspersonen en Samenwerkingsverbanden Identificatienummer) — the Dutch legal entity identification number maintained by the KvK (Kamer van Koophandel, the Dutch Chamber of Commerce). The 2 digits after B indicate the entity's fiscal unit number within the RSIN — for most standalone BV or NV companies the suffix is 01, but holding structures with multiple fiscal units may have 02, 03, etc. This means that a business group with a parent holding company (NL123456789B01) and a subsidiary fiscal unit (NL123456789B02) share the same RSIN base number but have different BTW numbers.

Dutch businesses often write their BTW number with a dot and spaces for readability — 'NL 123.456.789 B01' or 'NL123.456.789B01'. Strip all dots, spaces, and non-alphanumeric characters except the B before validation. The canonical form is NL followed immediately by 9 digits then B then 2 digits with no separators.

## Common Dutch VAT Format Errors

- Missing the B: 'NL123456789' or 'NL12345678901' — the B is mandatory. Without it the number is 11 characters instead of 14 and will fail format validation.
- Dots not stripped: 'NL123.456.789B01' — strip dots before validation. Dutch invoices commonly format the 9-digit block with dots.
- Lowercase B: 'NL123456789b01' — normalise to uppercase. The TaxID API handles this, but strip client-side for consistency.
- Only submitting the RSIN without B suffix: some Dutch company databases store just the 9-digit RSIN. Add B01 when constructing the BTW number from an RSIN. Verify this with the customer — their BTW suffix may be 01 or higher.
- Confusing BTW-nummer with KvK-nummer: the KvK number (Kamer van Koophandel) is an 8-digit Chamber of Commerce registration number, not a VAT number. Format is entirely different.
- Confusing BTW with BSN: the BSN (Burgerservicenummer) is an 8 or 9-digit personal citizen service number. Never a VAT number.

## Dutch Company Types and VAT Registration

The most common Dutch legal forms for B2B customers are BV (besloten vennootschap — private limited company, equivalent to a GmbH or Ltd, the most common form for Dutch SMEs and EU subsidiaries), NV (naamloze vennootschap — public limited company for listed entities), eenmanszaak (sole trader / self-employed), and VOF (vennootschap onder firma — general partnership). The Netherlands is a very popular jurisdiction for EU holding companies and regional headquarters, so you may frequently encounter Dutch-registered entities that are actually the EU presence of non-Dutch groups.

Dutch fiscal unity (fiscale eenheid) deserves special mention. Multiple BV entities under common control can form a fiscal unity for VAT purposes, sharing a single BTW number. If a Dutch customer provides a BTW number that validates correctly via VIES but the company name returned does not match the entity named on the invoice, the invoice entity may be a member of a fiscal unity filing under the parent's BTW number. This is a legitimate Dutch VAT arrangement. Validate the number as provided — the responsibility for correct fiscal unity membership lies with the customer.

## VIES and Netherlands' Belastingdienst: Privacy Behaviour

The Netherlands' Belastingdienst VIES endpoint is generally reliable with good uptime. Response times for live lookups are typically 200-500ms. The notable behaviour specific to the Netherlands is privacy-related: Dutch VIES responses frequently return null for the address field even when the number is valid and active. This is by design — the Belastingdienst applies privacy protections that limit which data is shared via VIES. The company name is usually returned, but address is often withheld.

Do not treat a null address from a Dutch VIES response as a validation problem. For Dutch numbers, a response of valid: true, status: active, company_name: 'Acme BV', address: null is normal and correct. Store the null address with a note indicating the Netherlands withholds address data via VIES — do not re-validate the number in an attempt to retrieve the address. For address verification of Dutch companies, use the [KvK online register](https://www.kvk.nl/) manually, or ask the customer to provide their registered address directly. [Dutch VAT validation](/validate-vat/nl) via TaxID caches results for 24 hours.

## Dutch VAT Rates

The Netherlands applies a standard VAT rate of 21% (BTW — Belasting over de Toegevoegde Waarde) to most goods and services. A reduced rate of 9% applies to food and beverages for human consumption, medicines and medical aids, books (print and digital), newspapers, passenger transport, hotel accommodation, and admission to cultural events (museums, concerts, sports). The Netherlands does not have a super-reduced rate or a zero rate for domestic supplies (other than the standard EU zero-rate for qualifying intra-EU B2B supplies).

For SaaS and digital services sold to Dutch consumers (B2C), the applicable rate is 21%. For Dutch B2B customers with a valid BTW-nummer that validates active via VIES, zero-rate reverse charge applies. The Netherlands participates in the EU OSS scheme for B2C digital services.

## Code Examples

### cURL

### Node.js / TypeScript

### Python

## Frequently Asked Questions

- Why is there a 'B' in the Dutch VAT number? The B separates the RSIN (9-digit entity identifier) from the fiscal unit suffix (2 digits). It is a structural part of the number, not a separator. It has always been part of the format.
- What does the 2-digit suffix after B mean? It indicates the fiscal unit within the company group. Most standalone companies use B01. Dutch fiscal unity structures (multiple BV entities under one VAT registration) may use B02, B03, etc. for subsidiary entities.
- Why does Dutch VIES return null for the address? The Belastingdienst applies privacy protections that limit address data shared via VIES. A null address is normal and correct for Dutch validations. Do not treat it as a validation failure.
- What is the difference between BTW-nummer and KvK-nummer? The BTW-nummer (NL + 9 digits + B + 2 digits) is the VAT registration number used for VIES. The KvK-nummer is the 8-digit Chamber of Commerce registration number used for company identification. They are derived from different registries.
- How long does VIES take for Dutch validations? [Cached Dutch numbers](/validate-vat/nl) respond in under 10ms. Uncached live Belastingdienst lookups typically complete in 200-500ms. The Dutch endpoint is one of the more reliable in the EU.

## Validating Dutch VAT Numbers at Scale

The Netherlands is a top-three EU B2B market for many European platforms, particularly given its role as a hub for EU subsidiaries of non-EU companies. Dutch numbers have the longest format in the EU (14 characters) and the most distinctive structure — the B is a reliable distinguishing feature that makes Dutch numbers easy to identify in a mixed-country database. At scale, normalise all Dutch numbers by stripping dots before storage. Null addresses are expected and should not trigger re-validation or customer support workflows. Store the request_id from each API response. For the complete format reference and live validator, see [validate-vat/nl](/validate-vat/nl).

---

## Polish VAT Number Validation: NIP Format, VIES, and Code Examples
https://www.taxid.dev/blog/polish-vat-number-validation · 2026-03-20

Complete developer guide to validating Polish VAT numbers (NIP) via API. Format, check digit, VIES integration, and copy-paste code examples.

Poland is one of the EU's largest and fastest-growing economies, and an increasingly significant source of B2B customers for European SaaS platforms — particularly in software development, manufacturing, and business services. Polish VAT numbers, the NIP (Numer Identyfikacji Podatkowej), follow a clean numeric format of PL + 10 digits with a check digit. The main integration gotcha is that Polish invoices and business documents almost always format the NIP with hyphens, which must be stripped before validation. This guide covers the format, check digit, common errors, VIES behaviour, and complete code examples.

> Polish VAT numbers (NIP — Numer Identyfikacji Podatkowej) are issued and managed by the [Krajowa Administracja Skarbowa (KAS)](https://www.podatki.gov.pl/). VIES routes Polish validation requests to the KAS system in real time.

## The Polish VAT Number Format (NIP)

A Polish VAT number consists of the prefix PL followed by exactly 10 digits — 12 characters in total. There are no letters after the prefix and no separators in the canonical form. A valid example is PL1234567890. The 10th digit is a check digit computed from the first 9 digits using a weighted sum algorithm with the weights [6, 5, 7, 2, 3, 4, 5, 6, 7], modulo 11.

On Polish invoices and business documents, the NIP is typically formatted with hyphens as XXX-XXX-XX-XX (e.g., 123-456-78-90) or occasionally as XXX-XX-XX-XXX. Both formats represent the same 10-digit number. Always strip hyphens, spaces, and all other non-alphanumeric characters before validation. The TaxID API accepts numbers with hyphens and strips them internally, but stripping client-side before the API call is good practice.

## Common Polish VAT Format Errors

- Hyphens not stripped: '123-456-78-90' submitted instead of '1234567890' — the most common error. Polish invoices always format NIP with hyphens. Strip before validation.
- Missing PL prefix: '1234567890' without the PL country code. Unlike Germany where you should not silently add the prefix, Poland's 10-digit format is fairly distinctive — but always ask for the full VIES-format number.
- Submitting REGON instead of NIP: REGON (Rejestr Gospodarki Narodowej) is a 9-digit or 14-digit statistical identifier, not a VAT number. If a customer submits a 9-digit or 14-digit number, they may have submitted their REGON.
- Wrong digit count: Polish NIP is always 10 digits after PL. A 9-digit number (common mistake by customers who omit a digit) fails format validation.
- Lowercase: 'pl1234567890' — normalise to uppercase before validation.
- Check digit failure: a customer who mistyped one digit in their NIP will pass the basic format check (PL + 10 digits) but fail check digit validation. The TaxID API catches this locally before the VIES call.

## Polish Company Types and VAT Registration

The most common Polish legal forms for B2B customers are sp. z o.o. (spółka z ograniczoną odpowiedzialnością — equivalent to a GmbH or LLC, the most common form for Polish SMEs and startups), S.A. (spółka akcyjna — public company for larger corporations), and JDG (jednoosobowa działalność gospodarcza — sole trader / self-employed individual). Polish tech companies and agencies almost universally use the sp. z o.o. form. JDG sole traders who are VAT-registered have a NIP derived from their personal PESEL number.

Polish businesses with annual taxable revenue below PLN 200,000 (~€45,000) can opt for VAT exemption (zwolnienie podmiotowe). These businesses have a NIP for income tax purposes but are not registered for VAT and cannot receive reverse charge treatment. If a Polish customer claims they have a NIP but are not VAT-registered, they are likely on the zwolnienie podmiotowe exemption. VIES will typically return inactive or not_registered for their NIP. Charge the applicable VAT rate for such customers — they are not VAT-exempt for reverse charge purposes.

## VIES and Poland's KAS: What to Expect

Poland's KAS VIES endpoint is generally reliable and well-maintained. Response times for live VIES lookups are typically 200-600ms. Poland introduced additional VAT enforcement measures (the Split Payment Mechanism — mechanizm podzielonej płatności) in 2019, which has motivated KAS to maintain a high-quality VAT registration database. VIES data for Polish companies is generally accurate and up to date.

Poland returns company name and registered address via VIES in most cases. The company name is the official KRS (Krajowy Rejestr Sądowy — National Court Register) registered name for companies, or the individual's name and trading name for JDG sole traders. [Polish VAT validation](/validate-vat/pl) via TaxID caches active results for 24 hours. For the allow-and-re-validate pattern during KAS maintenance windows, see [VIES Downtime: Building a Resilient Validation Flow](/blog/vies-downtime-resilience).

## Polish VAT Rates

Poland applies a standard VAT rate of 23% to most goods and services — one of the highest standard rates in the EU. An 8% reduced rate applies to food products for human consumption, medical devices, hotel accommodation, and passenger transport. A 5% reduced rate applies to basic food staples (bread, meat, dairy, processed foods), books and e-books, and certain agricultural products. A 0% rate applies to intra-EU B2B supplies with reverse charge, certain financial services, and some exports.

For SaaS and digital services sold to Polish consumers (B2C), the applicable rate is 23%. For Polish B2B customers with a valid NIP that validates active via VIES, zero-rate reverse charge applies. Poland fully participates in the EU OSS scheme for B2C digital services.

## Code Examples

### cURL

### Node.js / TypeScript

### Python

## Frequently Asked Questions

- Is PL always the VIES code for Poland? Yes. Poland uses PL as its ISO code and VIES prefix.
- What is the difference between NIP, REGON, and KRS? NIP is the tax identification number (used for VIES). REGON is a 9 or 14-digit statistical identifier for the Central Statistical Office. KRS is the National Court Register number for registered companies. Only NIP is relevant for EU VAT validation.
- Why is the Polish NIP always formatted with hyphens on invoices? Polish tax law requires NIP to be displayed with hyphens in the format XXX-XXX-XX-XX on invoices and documents. This is a display convention only — the underlying number is 10 digits without separators. Always strip hyphens before API calls.
- Can a Polish sole trader (JDG) receive reverse charge treatment? Yes. Polish JDG sole traders who are VAT-registered have a valid NIP and can receive zero-rate reverse charge treatment. Confirm active VIES status before applying zero rate.
- What does zwolnienie podmiotowe mean? It is the Polish VAT exemption for businesses below PLN 200,000 annual revenue. These businesses have a NIP for income tax but are not VAT-registered — their NIP will typically not be active in VIES.

## Validating Polish VAT Numbers at Scale

Poland's KAS system is one of the more reliable VIES endpoints, making bulk validation straightforward. For ERP systems importing Polish supplier records or platforms onboarding Polish sellers, the main pre-processing step is stripping hyphens from NIP values. TaxID caches active Polish VAT results for 24 hours — repeated validations of the same NIP within 24 hours return the cached result instantly. Store the request_id from each response for audit traceability. For the complete format reference and live validator, see [validate-vat/pl](/validate-vat/pl).

---

## Spanish VAT Number Validation: NIF Format, VIES, and Code Examples
https://www.taxid.dev/blog/spanish-vat-number-validation · 2026-03-13

Complete developer guide to validating Spanish VAT numbers (NIF/CIF) via API. One of the most complex EU formats — format rules, VIES quirks, and copy-paste code examples.

Spain is the EU's fourth-largest economy and one of the most challenging EU VAT number formats to validate correctly. The Spanish NIF (Número de Identificación Fiscal) — also referred to as CIF for company entities — uses a variable-character format where the first and last positions can be letters or digits, and the leading letter encodes the type of legal entity. This makes Spain one of the few EU countries where format validation alone cannot determine the entity type without parsing the structure. This guide covers the complete format, what the leading character means, the VIES behaviour specific to Spain, and complete code examples.

> Spanish VAT numbers (Número de Identificación Fiscal — NIF) are issued and managed by the [Agencia Tributaria (AEAT)](https://www.agenciatributaria.es/). VIES routes Spanish validation requests to the AEAT system in real time. Spain participates fully in the EU VIES system.

## The Spanish VAT Number Format (NIF)

A Spanish VAT number consists of the prefix ES followed by 9 characters: one character (letter or digit), then exactly 7 digits, then one final character (letter or digit) — 11 characters in total. The simplified regex is ^ES[0-9A-Z][0-9]{7}[0-9A-Z]$. Valid examples include ESA12345678 (a corporation), ESX1234567T (a foreign entity with NIE), and ES12345678Z (a sole trader).

The first character after ES encodes the legal entity type. For Spanish corporations (sociedades), it is always a letter from a specific set: A = Sociedad Anónima (S.A.), B = Sociedad de Responsabilidad Limitada (S.L.), C = Sociedad Colectiva, D = Sociedad Comanditaria, E = Comunidad de Bienes, F = Sociedad Cooperativa, G = Asociación, H = Comunidad de Propietarios, J = Sociedad Civil, N = Non-resident entity, P = Local body, Q = State or public body, R = Congregation or religious entity, S = State administration body, V = Other entity types, W = Permanent establishment of non-resident. For individual Spanish entrepreneurs (autónomos), the first character is a digit (the first digit of their DNI/NIF personal number). For foreign individuals with a NIE, the prefix is X, Y, or Z.

The final character is always a check character — either a digit or a letter depending on the entity type. For entities with a leading letter (corporations), the last character is a letter. For entities with a leading digit (individuals and autónomos), the last character is also a digit. The check character is computed algorithmically from the 7-digit middle section. The TaxID API performs full check character validation before making the VIES call.

## Common Spanish VAT Format Errors

- Missing ES prefix: 'A12345678' instead of 'ESA12345678' — the most common error.
- Submitting the DNI instead of NIF: the DNI (Documento Nacional de Identidad) is a personal identity document number, not a VAT number in isolation. Autónomos use their DNI-based NIF as their VAT number, but it must have the ES prefix.
- Submitting the NIE without prefix: NIE numbers (for foreigners) start with X, Y, or Z followed by 7 digits and a letter. These are valid Spanish VAT numbers but need the ES prefix: ESX1234567T.
- Wrong check character: the final character is computed. A number with the correct structure but wrong check character fails check digit validation at the TaxID API level before consuming quota.
- Lowercase: 'esa12345678' — normalise to uppercase before validation.
- Spaces or separators: some invoices format as 'ES A-1234567-8' — strip all non-alphanumeric characters.
- Canary Islands / Ceuta / Melilla: businesses based in these territories use the IGIC (Canarias) or IPSI systems, not standard Spanish VAT. They do not have EU VAT numbers and cannot be validated via VIES.

## Spanish Company Types and VAT Registration

The dominant legal forms for Spanish B2B customers are S.L. (Sociedad de Responsabilidad Limitada — the most common form for SMEs and startups, equivalent to a GmbH or LLC, NIF starts with B), S.A. (Sociedad Anónima — public company, NIF starts with A), and autónomo (self-employed sole trader, NIF is their personal DNI-based number starting with a digit). Spanish startups almost universally use the S.L. form. NIF numbers starting with B (S.L.) are the most common you will encounter from Spanish B2B SaaS customers.

Spanish autónomos (freelancers) are fully VAT-registered unlike French auto-entrepreneurs — there is no revenue threshold exemption. An autónomo with a VAT number can receive reverse charge treatment. However, some autónomos apply for a simplified VAT regime (recargo de equivalencia) if they sell goods to final consumers — these businesses charge higher VAT rates to their B2C customers and cannot reclaim input VAT. This is irrelevant for B2B reverse charge purchases you make from them, but affects invoices they issue to final consumers.

## VIES and Spain's AEAT: What to Expect

Spain's AEAT VIES endpoint is one of the less reliable in the EU, with above-average downtime and slower response times compared to Germany or France. AEAT system maintenance is common on weekends and Spanish public holidays (which are numerous — each region also has regional holidays). Response times for live lookups typically range from 400ms to over 1 second. During peak periods like quarterly VAT filing deadlines (last business day of January, April, July, October), AEAT response times degrade significantly.

Spain generally returns company name via VIES for corporate entities. Address data is returned less consistently. For autónomo (individual) NIF numbers, VIES typically returns the individual's name rather than a business name. Use the returned name on invoices for compliance, but note that autónomo VAT numbers will show the individual's personal name rather than any trading name they may use. [Spanish VAT validation](/validate-vat/es) via TaxID caches active results for 24 hours and handles the allow-and-re-validate pattern automatically for service_unavailable responses.

## Spanish VAT Rates

Spain applies a standard VAT rate of 21% (IVA — Impuesto sobre el Valor Añadido) to most goods and services. A 10% reduced rate applies to food and beverages for human consumption, passenger transport, hotel accommodation, and certain construction services. A super-reduced rate of 4% applies to essential food staples (bread, milk, eggs, cheese, fruit, vegetables), books and newspapers, pharmaceuticals, and certain social and educational services. Spain also applies a 0% rate to specific categories including some financial services.

For SaaS and digital services sold to Spanish consumers (B2C), the applicable rate is 21%. For Spanish B2B customers with a valid NIF, zero-rate reverse charge applies. Note that Canary Islands businesses use IGIC (Impuesto General Indirecto Canario) at 7% standard rate, not IVA — they do not have EU VAT numbers, so VIES validation is not applicable for Canarian customers.

## Code Examples

### cURL

### Node.js / TypeScript

### Python

## Frequently Asked Questions

- What is the difference between NIF and CIF? CIF (Código de Identificación Fiscal) was the old name for the Spanish company VAT number. It was renamed NIF in 2008. They are the same number — CIF is still commonly used colloquially for company VAT numbers.
- Is ES always the VIES code for Spain? Yes. Spain uses ES as its ISO code and VIES prefix.
- Can a Spanish autónomo receive reverse charge treatment? Yes. Spanish autónomos are fully VAT-registered (no exemption threshold unlike France). They can receive zero-rate reverse charge treatment if their NIF validates successfully via VIES.
- What if a customer says they are in the Canary Islands? Canary Islands businesses are not in the EU VAT area. They use IGIC, not IVA, and do not have EU VAT numbers. You cannot validate them via VIES and should charge at the applicable rate based on your B2C obligations.
- Why does Spain's VIES take longer? The AEAT system is one of the slower VIES endpoints. Use a timeout of at least 8 seconds for Spanish validations and always implement service_unavailable handling — AEAT downtime is more frequent than most EU members.

## Validating Spanish VAT Numbers at Scale

Spain's above-average VIES unreliability makes the caching and allow-and-re-validate patterns particularly important at scale. For platforms with significant Spanish B2B customer bases, consider increasing your re-validation interval — re-validating Spanish numbers more frequently than every 90 days adds little compliance value given the AEAT's consistency. Store the request_id from each API response. For the complete format reference and live validator, see [validate-vat/es](/validate-vat/es).

---

## Italian VAT Number Validation: Partita IVA Format, VIES, and Code Examples
https://www.taxid.dev/blog/italian-vat-number-validation · 2026-03-06

Complete developer guide to validating Italian VAT numbers (Partita IVA) via API. Format specification, VIES integration, check digit, and code examples.

Italy is the EU's third-largest economy and a significant source of B2B customers for European platforms — particularly in manufacturing, fashion, food, and professional services. Validating Italian VAT numbers, the Partita IVA (abbreviated P.IVA or codice IVA), follows a simple numeric format, but Italy's VIES endpoint has historically been one of the less reliable in the EU, with higher downtime frequency than Germany or France. This guide covers the format, check digit structure, common errors, VIES behaviour specific to Italy, and complete code examples.

> Italian VAT numbers (Partita IVA) are issued and managed by the [Agenzia delle Entrate](https://www.agenziaentrate.gov.it/). VIES routes Italian validation requests to the Agenzia delle Entrate system in real time. Italy participates fully in the EU VIES system.

## The Italian VAT Number Format (Partita IVA)

An Italian VAT number consists of the prefix IT followed by exactly 11 digits — 13 characters in total. There are no letters after the prefix, no separators, and no variable length. A valid example is IT12345678901. The 11-digit number is entirely numeric and includes a check digit as the final (11th) character.

The check digit is computed using a variant of the Luhn algorithm applied to the first 10 digits. Implementing check digit validation client-side provides immediate feedback on structurally invalid numbers before making an API call. The TaxID API performs both format validation and check digit validation locally before making the VIES call — numbers with a failing check digit return format_invalid immediately without consuming your monthly quota.

One important distinction: the Partita IVA (for businesses) is different from the Codice Fiscale (for individuals). The Codice Fiscale is an alphanumeric personal tax code of 16 characters (letters and digits) and is not a VAT number. Italian sole traders (ditte individuali) have both a Codice Fiscale and a Partita IVA — the Partita IVA is what you need for VIES validation. If a customer provides a 16-character alphanumeric code, they have submitted their Codice Fiscale rather than their P.IVA.

## Common Italian VAT Format Errors

- Codice Fiscale submitted instead of P.IVA: the Codice Fiscale is 16 alphanumeric characters (e.g., RSSMRA80A01H501T). If you receive a 16-char alphanumeric string, ask the customer for their Partita IVA instead.
- Missing IT prefix: '12345678901' instead of 'IT12345678901' — the most common input error.
- Wrong digit count: Italian numbers are always 11 digits after IT. '1234567890' (10 digits) or '123456789012' (12 digits) are invalid.
- Spaces or dots: inputs like 'IT 123 456 789 01' — strip all non-alphanumeric characters before validation.
- Lowercase: 'it12345678901' — normalise to uppercase. The TaxID API handles this automatically.
- P.IVA used for personal transactions: some Italian customers provide their personal Codice Fiscale for invoicing. Explain that only the Partita IVA (starting with IT + 11 digits) is valid for B2B reverse charge.

## Italian Company Types and VAT Registration

The most common Italian legal forms for B2B customers are S.r.l. (Società a responsabilità limitata — equivalent to a GmbH or LLC), S.p.A. (Società per azioni — public company), S.a.s. (Società in accomandita semplice — limited partnership), S.n.c. (Società in nome collettivo — general partnership), and ditta individuale (sole trader). All VAT-registered entities, including sole traders operating above the forfettario (flat-rate) threshold, have a Partita IVA.

Italian sole traders and freelancers (liberi professionisti) operating under the regime forfettario — a flat-rate simplified tax regime with a revenue threshold of €85,000 in 2026 — are VAT-exempt and do not charge or reclaim VAT. They do have a Partita IVA for identification purposes, but it operates differently from an ordinary VAT registration. If a forfettario customer provides their P.IVA for reverse charge, VIES may return a result but their invoices to you will include a note stating they are not subject to VAT. Validate the number via VIES, but be aware that the reverse charge mechanism may not apply in the same way as for ordinarily registered businesses.

## VIES and Italy's Agenzia delle Entrate: What to Expect

Italy's VIES endpoint has historically been one of the less reliable in the EU. The Agenzia delle Entrate system experiences unannounced downtime more frequently than the German BZST or French DGFiP systems, particularly around tax filing periods (end of quarter), August (when Italy effectively shuts down for the Ferragosto holiday period), and around the year-end reporting deadline. During these periods, service_unavailable responses for Italian validations are not unusual.

Italy generally returns company name via VIES, but address data is returned less consistently than Germany or France. For recently registered businesses or newly issued Partita IVA numbers, VIES may return valid: true but null for company_name while the registration propagates through the system. Wait 24-48 hours before concluding that a genuine Italian VAT number has no name data. [Italian VAT validation](/validate-vat/it) via TaxID caches active results for 24 hours and inactive results for 1 hour.

> Italy's VIES endpoint has above-average downtime frequency. For checkout flows accepting Italian B2B customers, the allow-and-re-validate pattern is especially important: allow the transaction when service_unavailable is returned and re-validate asynchronously within 24 hours. Blocking Italian customers at checkout due to VIES unavailability is a recurring pain point.

## Italian VAT Rates

Italy applies a standard VAT rate of 22% to most goods and services. A 10% reduced rate applies to food and beverages for human consumption supplied by restaurants and catering, hotel accommodation, passenger transport, and certain construction services. A 5% reduced rate applies to specific social services, certain food products, and some agricultural goods. A super-reduced rate of 4% applies to essential food staples, books and newspapers, and certain accessibility equipment. Italy also applies specific exemptions to financial and insurance services.

For SaaS and digital services sold to Italian consumers (B2C), the applicable rate is 22%. For Italian B2B customers with a valid Partita IVA, zero-rate reverse charge applies. Italy fully participates in the EU OSS scheme — if your B2C EU revenue exceeds €10,000, use OSS rather than individual Italian VAT registration.

## Code Examples

### cURL

### Node.js / TypeScript

### Python

## Frequently Asked Questions

- What is the difference between Partita IVA and Codice Fiscale? The Codice Fiscale is a 16-character alphanumeric personal tax code for individuals. The Partita IVA is the business VAT number (IT + 11 digits) used for VIES and reverse charge. Sole traders have both; only the Partita IVA is relevant for EU VAT validation.
- Is IT always the VIES code for Italy? Yes. Italy uses IT as its ISO code and VIES prefix — no mismatch.
- Does Italy's VIES always return company name and address? Company name is returned in most cases. Address is returned less consistently than in Germany or France. Newly registered numbers may have null company_name for 24-48 hours while registration propagates.
- Why does Italy's VIES take longer than other countries? The Agenzia delle Entrate system is one of the slower and less reliable VIES endpoints. Response times of 600-1200ms are not unusual, and downtime is more frequent around Italian public holidays and tax filing periods.
- What happens during Ferragosto (August)? August sees elevated VIES downtime for Italy specifically. Implement the allow-and-re-validate pattern and expect higher service_unavailable rates during the first three weeks of August.

## Validating Italian VAT Numbers at Scale

Italy's VIES unreliability makes caching especially important at scale. TaxID caches active Italian VAT results for 24 hours, so repeated lookups for the same P.IVA number — common in B2B SaaS where the same customer triggers validation at signup, at each invoice, and at renewal — hit the cache rather than the Agenzia delle Entrate system. For bulk validation of Italian supplier records, run in off-peak hours (early morning CET) to avoid peak Agenzia delle Entrate load. Store the request_id from each API response as an audit trail. For the complete format reference and live validator, see [validate-vat/it](/validate-vat/it).

---

## French VAT Number Validation: TVA Intracommunautaire Format, VIES, and Code Examples
https://www.taxid.dev/blog/french-vat-number-validation · 2026-02-27

Complete developer guide to validating French VAT numbers (TVA intracommunautaire) — format, regex, VIES integration, and copy-paste code examples.

France is the EU's second-largest economy and one of the top sources of B2B customers for European SaaS, e-commerce, and professional services platforms. Validating French VAT numbers — the numéro de TVA intracommunautaire — is straightforward once you know the format, but the two-character alphanumeric component after the FR prefix makes it subtly different from most EU countries and a frequent source of integration bugs. This guide covers the exact format, the VIES flow specific to France, common errors, and complete code examples.

> French VAT numbers (TVA intracommunautaire) are issued and managed by the [Direction Générale des Finances Publiques (DGFiP)](https://www.impots.gouv.fr/). VIES queries the DGFiP system in real time. France participates fully in the EU VIES system.

## The French VAT Number Format (TVA Intracommunautaire)

A French VAT number consists of the prefix FR followed by exactly two alphanumeric characters, followed by exactly nine digits — 13 characters in total. The two-character 'key' can be any combination of uppercase digits and letters, with one restriction: the letters O and I are excluded to avoid confusion with the digits 0 and 1. Valid characters in positions 3 and 4 are therefore 0-9 and A-H, J-N, P-Z. Valid examples include FR12345678901, FRXX345678901, and FR0A345678901.

The 9-digit block at the end is derived from the SIREN — the French national business identifier maintained by INSEE. Every French legal entity has a SIREN, and the TVA key is computed from the SIREN using a modular arithmetic algorithm. In practice, local format validation (FR + 2 alphanumeric + 9 digits) is sufficient before sending to VIES. Full check digit validation against the SIREN is performed internally by the TaxID API.

French businesses commonly write their TVA number with spaces — 'FR 12 345678901' or 'FR12 345678901'. Some accounting software outputs 'FR-12-345678901'. Strip all spaces, hyphens, and non-alphanumeric characters before validation. The canonical form for API calls is always FR followed immediately by 11 characters with no separators.

## Common French VAT Format Errors

- Submitting the SIREN instead of TVA: French businesses often confuse their 9-digit SIREN with the TVA number. A SIREN like '345678901' is not a valid TVA — it lacks the FR prefix and the 2-character key.
- Submitting the SIRET: the SIRET is SIREN + a 5-digit establishment code (14 digits total). Not a VAT number.
- Missing FR prefix: '12345678901' instead of 'FR12345678901' — the most common customer input error.
- Letters O or I in the key: 'FRO1345678901' contains O in position 3 — structurally invalid.
- Spaces and separators: 'FR 12 345 678 901' or 'FR.12.345678901' — strip all non-alphanumeric characters before validation.
- Lowercase: 'fr12345678901' — normalise to uppercase. The TaxID API accepts and normalises lowercase automatically.

## French Company Types and VAT Registration

The most common French legal forms for B2B customers are SARL (Société à responsabilité limitée — equivalent to a GmbH or LLC), SAS (Société par actions simplifiée — popular for French startups and tech companies), SA (Société anonyme — public company), and the auto-entrepreneur or micro-entreprise regime for sole traders. All these forms can be VAT-registered and have a TVA intracommunautaire number.

Auto-entrepreneurs and micro-enterprises operating below the franchise en base de TVA threshold — €36,800 for services and €91,900 for goods in 2026 — are VAT-exempt and do not have a TVA number. This is a common, legitimate scenario for French freelancers and small service providers. A French customer without a TVA number is not necessarily avoiding VAT — they may simply be below threshold. You must charge French VAT at the applicable rate on supplies to unregistered French customers.

## VIES and France's DGFiP: What to Expect

France's VIES integration via DGFiP is generally reliable but experiences slowdowns during high-traffic periods — particularly around French public holidays, month-end, and VAT filing deadlines (the 20th of each month). Unlike Germany's BZST, DGFiP does not publish a regular maintenance window; downtime is typically unannounced and load-related. Response times for live VIES lookups range from 300 to 800ms in normal conditions.

France usually returns both company name and registered address via VIES. The name is the official DGFiP-registered denomination, which may differ from the trading name. For SAS companies with a simple brand name, VIES returns the full legal name including the legal form designation (e.g., 'Acme SAS'). Use the VIES-returned name on invoices rather than the customer's self-reported name — French tax authorities verify invoice recipient details against DGFiP records during audits.

[French VAT validation](/validate-vat/fr) via TaxID caches results in Redis for 24 hours. A previously validated French number returns in under 10ms; an uncached live lookup typically completes in 400-700ms. If DGFiP is temporarily unavailable, TaxID returns service_unavailable rather than a false negative. For checkout flows, implement the allow-and-re-validate pattern. See [VIES Downtime: Building a Resilient Validation Flow](/blog/vies-downtime-resilience).

## French VAT Rates

France applies a standard VAT rate of 20% to most goods and services. A 10% reduced rate applies to restaurant meals, hotel accommodation, passenger transport, and home renovation work. A 5.5% reduced rate applies to most food products, books (print and digital), and certain energy subscriptions. A super-reduced rate of 2.1% applies to pharmaceutical products reimbursed by social security and certain press publications. For SaaS sold to French B2C customers the rate is 20%. For French B2B customers with a valid TVA intracommunautaire, zero-rate reverse charge applies.

## Code Examples

### cURL

### Node.js / TypeScript

### Python

## Frequently Asked Questions

- Is FR always the VIES code for France? Yes. France uses FR as both its ISO 3166-1 alpha-2 code and its VIES prefix — no mismatch like Greece (EL vs GR).
- What is the difference between SIREN, SIRET, and TVA number? SIREN is a 9-digit national business identifier. SIRET is SIREN + 5-digit establishment code (14 digits). The TVA number is FR + 2-char key + 9-digit SIREN. They share data but are not interchangeable.
- Can a French auto-entrepreneur have a TVA number? Only if they have exceeded the franchise en base de TVA threshold and opted for ordinary VAT registration. Auto-entrepreneurs below threshold have no TVA number and cannot receive zero-rate reverse charge.
- Does VIES return the company name for French businesses? In most cases yes. The name is the official DGFiP denomination, which may differ from the trading name. Use the VIES name on invoices for compliance.
- How long does VIES take for French validations? [Cached French numbers](/validate-vat/fr) respond in under 10ms. Uncached live DGFiP lookups typically complete in 400-700ms. VAT filing periods (around the 20th of each month) can add latency.

## Validating French VAT Numbers at Scale

France is typically a top-three source of EU B2B customers alongside Germany and the Netherlands for European-facing platforms. At high validation volumes, TaxID's caching layer ensures repeated lookups for the same French number within 24 hours do not create additional DGFiP load. For bulk validation of a supplier or CRM database, process in batches of 50-100 with a short delay between batches, and store the request_id from each response as an audit trail. For the complete format reference and a live validator, see [validate-vat/fr](/validate-vat/fr).