Stripe EU VAT: Validate Tax IDs Before Charging Customers

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.