What Happens When You Reverse-Charge an Invalid VAT Number
11 September 2026

What Happens When You Reverse-Charge an Invalid VAT Number
Short answer: the exposure lands on the seller. If you issue a zero-rated, reverse-charge invoice because the buyer gave you a VAT number, and that number turns out to have been invalid at the time of supply, a tax authority can reassess the transaction as a normal domestic one. You didn't charge VAT. Now you're the one who owes it — plus interest, plus whatever penalty regime applies where you're established.
That's the mechanical answer. The more useful one is where the actual risk sits, because it usually isn't "the number happened to be bad." It's not validating at all, validating in a way you can't reproduce later, or being unable to produce the evidence when someone asks for it. This post separates those two stories, because they get conflated constantly and that leads to bad decisions — treating every later deregistration as a crisis, or treating a validated-but-informal check as good enough.
Reverse charge is a services mechanism, not a goods one
Worth being precise here, because the term gets used loosely. In the strict, technical sense, "reverse charge" is Article 44 (place of supply) and Article 196 (customer liable) of Directive 2006/112/EC — and it applies to services. The customer, not the supplier, is the person liable for the VAT.
The goods equivalent looks similar in effect — no VAT on the invoice — but it isn't the same mechanism. A cross-border intra-EU supply of goods is a zero-rated exempt supply under Article 138, paired with the buyer's intra-Community acquisition under Article 20. There's no "customer liable" flip; the exemption and the acquisition are two separate legal events. Calling that "goods reverse charge" is common shorthand, but it isn't the technical term, and conflating the two conditions can cost you the exemption on one side while you're checking the wrong box on the other.
This post is scoped to the services case — Article 196. If you're dealing with the goods side, the reverse-charge concept guide covers both mechanisms properly, and by-country invoice wording is the reference for what to print on the invoice either way.
One reason the distinction matters here:
- Since 1 January 2020 (the "quick fixes" under Council Directive (EU) 2018/1910), a VIES-valid customer VAT number stopped being a merely formal condition of the Article 138 goods exemption and became a substantive one. Before that, Plöckl (C-24/15) treated a missing or wrong VAT number as something that shouldn't defeat the exemption on its own if the substance was there; since 2020, a bad number can defeat it directly.
- Article 138(1a) makes the exemption conditional on correctly reporting the supply on the recapitulative statement (EC Sales List) — a valid number isn't enough if the transaction isn't reported right.
Both are goods-side rules. They raise the stakes generally, and they're the reason "just eyeball the number" was never a great practice even before the services case, which never had the pre-2020 formal/substantive distinction to begin with — Article 196 liability has always turned on the buyer actually being a taxable person, valid number or not.
What "invalid" actually costs the seller
This is general information about how EU VAT rules and CJEU case law generally operate. It is not tax or legal advice, and it isn't individualized to your facts. If you've already issued an invoice against a number that turned out to be invalid, talk to a qualified adviser in the relevant jurisdiction before you decide how to fix it.
If a services supply didn't qualify for reverse charge — because the buyer wasn't a taxable person, or the VAT number given was never valid — the seller is the one exposed. The tax authority in the seller's member state can assess the supply as domestic, meaning the seller owes the VAT that should have been charged in the first place. On top of the principal amount, expect interest for the period the VAT went unpaid, and a penalty. National law sets both the interest rate and the penalty percentage, and they vary by member state — there's no single EU-wide figure to quote here, and treat any source that gives you one flat number as wrong. Assessment and limitation periods are national law too, which is part of why the evidence question below matters: you may need to defend a supply years after you made it.
None of that is contingent on intent. A seller who genuinely believed the number was valid can still end up assessed — the good-faith question (next section) is about whether that assessment is the end of the story or whether there's a viable defence against it. They're different questions.
The good-faith defence — and its limits
CJEU case law gives suppliers real protection here, but it's a defence you have to make out on the facts, not an automatic pass. Teleos (C-409/04), Netto Supermarkt (C-271/06), and Euro Tyre (C-21/16) collectively establish that a supplier who took every reasonable measure available and had no part in fraud can generally keep an exemption even where the evidence later turns out to be false. Be precise about their reach, though: these were decided on the goods exemption (Article 138) and the export exemption (Article 146), not on Article 196 services liability. Applying the same reasonable-measures, good-faith principle to the services case is an extension by analogy of general EU-law principles the Court has applied consistently across VAT provisions — not a services-specific holding. It's a meaningful protection either way, but it's built on "reasonable measures" and "no involvement in fraud" — both fact questions a tax authority or court has to be satisfied of, not a checkbox.
Where this gets specifically relevant to invalid numbers: the fact pattern of "we checked, it was valid, it was deregistered afterward" doesn't have a CJEU ruling squarely on point that says a validated-then-later-deregistered number is automatically covered. The reasonable inference from Teleos and the line of cases after it is that a genuine, dated, requester-qualified check at the time of supply is the kind of "reasonable measure" the case law is talking about — but that's an inference from the general principle, not a decided rule for this exact scenario. If it matters for a real supply you've made, that's a question for an adviser who knows your jurisdiction, not a blog post.
This is also where the two risk stories diverge:
- The number was invalid at the time of supply. You didn't meet the condition. The good-faith defence might still apply depending on what checks you ran, but you're starting from a failed condition and arguing your way out of liability.
- The number was valid at the time of supply and deregistered afterward. You met the condition when it mattered. The implementation checklist puts it plainly: that's not your problem at the moment of supply, provided the validation was genuine at the time — the audit position is "valid when checked," not "still valid today." Keep the original evidence; don't let a later status change rewrite what you knew when you issued the invoice.
Those are not the same conversation, and treating the second as if it were the first is how teams end up either panicking over routine churn or, worse, assuming no check is ever really "safe" and giving up on validating at all.
Format-valid is not the same as registered
A VAT number can pass a regex and checksum and still not be registered, or no longer be registered. Format validation tells you the string is shaped correctly — it says nothing about whether the business behind it is VAT-registered right now. VIES is the system that answers that question — a real-time search over the national tax databases of each member state; the Commission doesn't operate those databases itself, and VIES has downtime, particularly on specific national nodes. A VIES-valid result is a snapshot: it proves the number was valid at the moment you asked, nothing further forward or backward in time.
That snapshot nature is precisely why a dated, requester-qualified check matters more than an undated one. A requester-qualified VIES lookup returns a consultationNumber — a reference VIES itself issues, tying the check to a specific number, requester, and timestamp. It's evidence you ran the check, not a guarantee the underlying transaction was correct, and it's only present on requester-qualified lookups — a plain check or a national-fallback result won't carry one. The business case for keeping it is covered in the consultation number for finance teams; it's not unique to any one provider, and no provider's internal ID is a substitute for it. You can generate that same requester-qualified check yourself by calling VIES's checkVatApprox operation directly — build vs buy is the honest accounting of what maintaining that path actually costs.
Country coverage adds another wrinkle, and it's easy to get wrong. When VIES is unreachable for a member state, some checks can fall through to a genuine national fallback — a tax authority's own VAT register that can independently confirm a number. Others have only a company registry, which vatnode does not treat as a validity fallback at all: a business can be active and in good standing in a company registry without being VAT-registered for intra-EU purposes, so registry presence can't stand in for a VAT verdict. Where only a company registry exists, a VIES outage surfaces as an error, not a substitute "valid." And even where a real fallback answers, a fallback "valid" is not equivalent to a VIES-valid result for the condition reverse charge actually needs. Which countries fall in which bucket changes over time — see current coverage rather than assuming a fixed list.
What an invalid result actually looks like — and why it's useful
A GET /v1/vat/:vatId call against a number that isn't registered doesn't error. It returns HTTP 200 with valid: false, and it still carries the source, timestamp, and check ID (the consultationNumber below is populated because the account has a requester VAT set):
{
"valid": false,
"vatId": "DE123456788",
"countryCode": "DE",
"source": "VIES",
"verifiedAt": "2026-09-04T10:22:31Z",
"checkId": "01926a3e-9f4c-7c2e-8b1a-3d7e6a2f9c11",
"consultationNumber": "WAPIAAAAX9999999"
}
That's a definitive negative, not a failure state, and it's protective — it's the artefact that lets you correctly decline to zero-rate the invoice in real time, before the supply happens, rather than finding out during an audit two years later. Contrast that with a VIES outage: VIES_UNAVAILABLE (HTTP 503) or a national MS_UNAVAILABLE doesn't mean invalid, it means the check didn't run — see handling VIES downtime and the error reference for how to handle it without either blocking the customer or silently charging VAT on a transient outage.
Where the actual exposure comes from
The real risk isn't "a customer's VAT number went bad." It's one of these:
- Never validating. Taking the number at face value because it's the right length and shape.
- Validating without a reproducible, dated, requester-qualified check. An undated internal note or an ad-hoc lookup with no requester attached gives you a weaker evidentiary position than a check that VIES itself timestamped.
- Not being able to produce the evidence later. A check you ran but didn't store — or stored without linking it to the invoice it supports — is functionally the same as not having checked, from an auditor's point of view. When to validate a customer's VAT number covers the triggers; the full audit trail covers what to keep and for how long.
The practical defence against all three is the same: validate at the point where the treatment is decided, keep the dated evidence next to the invoice, and re-check periodically rather than assuming a signup-time validation holds forever. Bulk re-validating a customer base is the mechanism for that — a backfill pass plus an ongoing cadence, so a deregistration shows up as a flagged number on a known date instead of a surprise during an audit. That's the mitigation story, and it's a genuinely different conversation from the liability one above.
If you're building the invoicing logic itself — the decision function, the country-comparison rule, what to render on the invoice — that's the reverse-charge implementation checklist. This post is the risk case for getting a step in that checklist wrong; it isn't a second version of the checklist.
This is general information about EU VAT rules and CJEU case law, not tax or legal advice for a specific transaction. If you're dealing with an actual supply made against an invalid number, get a qualified adviser in the relevant jurisdiction involved before deciding how to fix it.
FAQ
Who owes the VAT if the buyer's number turns out to be invalid?
In the reverse-charge mechanism for services, the buyer is liable under Article 196 only when the conditions actually hold. If the number was invalid, one of those conditions failed, and a tax authority can reassess the supply as a normal domestic one — with the seller assessed for the VAT that was never charged, plus interest and penalties that vary by country. This is general information, not tax advice for a specific case.
We validated at invoice time and the number was deregistered later — are we exposed?
That is a materially different fact pattern from never checking. If the check was genuine, requester-qualified, and dated to the time of supply, you have a documented basis for the treatment you applied at that moment — case law generally protects a supplier who took reasonable measures and was not party to fraud, though outcomes are fact-dependent and no single ruling guarantees a result. Keep the evidence and talk to a local adviser if this applies to a real supply you've already made.
Does a VIES outage mean the buyer's VAT number is invalid?
No. VIES_UNAVAILABLE (or a national MS_UNAVAILABLE) is a transport failure, not a negative result. It tells you the check didn't run, not that the number is bad. Treat it as "retry" evidence and keep a record of the attempt.
Is a VIES screenshot enough evidence if this gets audited later?
A screenshot is self-produced and hard to date convincingly on its own. A requester-qualified VIES check that returns a consultation number is stronger, because VIES itself issues and timestamps that reference. Neither one proves the underlying supply qualified for the treatment — they prove you checked, not that the transaction was correct.
Know before you invoice, not after an audit
vatnode runs requester-qualified VIES checks — set your EU VAT number once in Settings, and every VIES check returns a definitive valid: true/false with the consultation number, source, and timestamp. So a bad number shows up before you zero-rate the invoice, not during a review two years later. Free plan, 100 requests/month.
Get a free API key · VIES API · Bulk re-validate a customer base