Originally published at vatnode.dev. The version on vatnode.dev is the canonical source — refer to it for the latest content.

When to Validate a Customer's VAT Number

Most people asking "when should I validate a customer's VAT number?" already know how to check one — paste it into VIES, get a yes or no. The harder question is timing: at what points in the customer relationship does the check actually matter, and what happens to the answer between those points. A VAT number you validated at signup can be cancelled the following week, and the check you ran then says nothing about the invoice you issue six months later.

This guide walks through the moments that trigger a validation, why each one matters, and what to keep afterwards. The scope is the EU-27 plus XI (Northern Ireland) — the area VIES covers. It is general information about EU VAT, not tax advice.

Why timing matters more than the check itself

A VAT validation is a snapshot. It tells you the number's status at the instant the query ran, against the relevant national database, and nothing more. It is not a standing certificate, and it does not renew itself. Registrations get cancelled, businesses deregister, and companies restructure — none of which sends you a notification.

That is the whole reason timing is the interesting part. Running the check is trivial; running it at the right moments and keeping the results is what turns a lookup into evidence you can rely on. The rest of this guide is four moments where the check earns its keep, plus what to store each time.

One thing to hold onto throughout: a correct format is not the same as a registered number. A string can match a country's pattern perfectly and still not be an active VAT ID — only a live check against VIES or a national source confirms registration. If you want the background on that distinction, what a VAT ID is covers it.

Trigger 1 — at onboarding / first B2B sale

The first natural checkpoint is when a business becomes your customer and gives you a VAT number — at signup, at account creation, or when they first ask to be invoiced without VAT.

Validating here does two things. It catches typos and plainly wrong numbers while the customer is still in front of you and can fix them, which is far cheaper than discovering a bad number on an invoice already issued. And it establishes a baseline: you now know the number was registered as of that date, which is the starting point for everything downstream.

Onboarding is also where the temptation to over-engineer shows up. You do not have to block signup on a VAT check, and in most cases you should not — a VIES outage or a slow national node shouldn't stop someone becoming a customer. The pattern that works is to validate in the background and record the result, not to gate the front door on it. We wrote that up separately in validate at signup without blocking.

Trigger 2 — before applying reverse charge or zero-rating on an invoice

This is the trigger that carries the real compliance weight, and goods and services behave differently — worth being precise about.

For an intra-Community supply of goods, the picture changed with the 2020 Quick Fixes (Council Directive (EU) 2018/1910, in force since 1 January 2020). The customer's valid VAT ID in another member state, communicated to you, is now a substantive condition for zero-rating the supply under Article 138 — not a mere formality. So is a correct recapitulative statement (your EC Sales List). Important caveat: these are conditions among several. You also need proof of intra-Community transport and correct invoicing. A valid VAT ID alone does not secure zero-rating; it is one required piece, and the check is how you build that piece into something you can show.

For cross-border B2B services, the mechanism is different. The place of supply is generally where the customer belongs (Article 44 of Directive 2006/112/EC), and liability shifts to the customer under the reverse charge (Article 196). The customer's VAT ID supports applying that treatment. The reverse charge rules go into how that plays out on the invoice.

Either way, the point stands: the check that matters for a given invoice is the one that reflects the customer's status around the time of that supply. A validation from onboarding supports invoices near that date. It does not stretch indefinitely to cover a supply a year later, which is exactly why the next trigger exists.

Trigger 3 — ongoing / periodic revalidation

Because registrations change and your onboarding check ages, you re-validate on a cadence. A customer who was registered when they signed up may have deregistered since; if you keep issuing zero-VAT or reverse-charge invoices on the strength of a stale check, the gap is yours to explain.

Here is the caveat that matters most, and where a lot of online advice goes wrong: there is no statutory "every N days" re-validation interval. EU VAT law does not mandate that you re-check monthly, quarterly, or on any fixed clock. Anyone quoting a hard legal interval is inventing it. What you actually have is a risk decision — how often is proportionate given your volume, your customers, and your tax adviser's view. A common, defensible pattern is to re-validate periodically and to re-check before a supply you're about to rely on, but the specific rhythm is yours to set, not the directive's.

Practically, this is a batch job, not a manual chore. You take your active B2B customers and re-run their numbers on whatever schedule you've settled on, flagging any that have flipped from valid to invalid so a human can look before the next invoice. Bulk revalidate existing customers covers how to run that across a whole base without checking numbers one at a time. To remove the manual cadence entirely, continuous VAT monitoring re-checks stored numbers on a schedule and notifies you when one changes.

Trigger 4 — on demand / before an audit

The last trigger is reactive: something prompts a check outside your normal cadence. A tax authority opens an enquiry. A customer disputes an invoice's VAT treatment. Your finance team is closing a period and wants to confirm the reverse-charge invoices it's about to file are backed by real registrations. A customer tells you their VAT details have changed.

An audit rarely asks "is this number valid today?" It asks "was this number valid when you issued that invoice, and can you show it?" That is a question about your records, not about a fresh lookup. If you kept the evidence from Triggers 1–3, answering is a matter of retrieval. If you didn't, a check run today doesn't reconstruct what your position was at the time of supply — it only tells you about now.

So the on-demand trigger is really two motions: retrieve the historical evidence for the supply in question, and, separately, run a current check if you need to know today's status. Don't confuse the two.

"Must" vs good practice (not legal advice)

Separate what the law makes a condition from what is simply sensible.

On the "condition" side: for intra-Community supplies of goods, the customer's valid VAT ID and a correct recapitulative statement are substantive conditions for zero-rating under the Quick Fixes — among several, as above. That is not optional if you want the zero rate to hold.

On the "good practice" side sits most of the timing: validating at onboarding, re-validating periodically, keeping a dated record of each check. The law does not hand you a schedule for these, but they are how you make sure the substantive conditions are actually met when it counts, and how you demonstrate reasonable care if anyone asks.

This is general information about EU VAT, not tax advice. Whether a specific supply qualifies for
zero-rating, exemption, or reverse charge depends on facts we can't assess here — confirm your own
case with a qualified tax adviser.

What to keep as evidence each time

Every check, whichever trigger fired it, should leave the same small record behind. The individual query is disposable; the record is the point. For each validation, store:

• The VAT ID you checked — exactly as queried, prefix included.
• The result — valid or not, and any trader name and address the source returned.
• When it ran — a timestamp, because the whole value of the record is that it fixes a point in time.
• Which source answered — VIES, or a national source if you used a fallback. A "valid" from a national company registry is not the same signal as a VIES "valid"; note which one you got.
• The VIES consultation number, where one was issued. It's the requester-qualified reference that lets you show you ran the check, on that date, against VIES — the strongest single artefact to keep. The consultation number for finance explains what it is and why finance teams care.

Stored together, those fields are a reproducible record — you can show, per invoice, what you knew and when. Keep it for as long as the underlying invoice's retention period, which member states set individually (commonly several years). What to keep for audit goes deeper on the trail.

How to automate the triggers instead of doing it by hand

Doing all of this manually works until it doesn't — one number in a checker is fine, thousands of customers across four triggers is not. Each trigger maps cleanly onto something a program can do for you:

• Onboarding — validate in the background when the customer submits a VAT ID, store the result, don't block the flow.
• Before invoice — re-run the decision at invoice time and attach the evidence to that invoice, so the record travels with the document.
• Periodic — a scheduled job walks your active B2B base and flags status changes.
• On demand — retrieval, mostly: you're reading records you already kept.

In code, the shared piece is a single call that validates a number and hands back a structured result you can persist:

result = validateVat(customerVatId)   // one call, wherever the trigger fires
store(result.vatId, result.valid, result.checkedAt,
      result.source, result.consultationNumber)

The important design choice is that the same call feeds every trigger — the check doesn't know or care whether it was fired at signup, at invoice time, or by a nightly batch. That's what keeps your evidence consistent across all four. You can wire this against the VIES validation API and get a free free API key to try it from your own code.

FAQ

Do I legally have to validate a customer's VAT number?

It depends on your jurisdiction and the transaction. For an intra-Community supply of goods, the customer's valid VAT ID is a substantive condition for zero-rating, so validating it is how you build the evidence you rely on — but it is one condition among several. This is general information, not tax advice.

When should I re-check a VAT number I already validated?

Periodically, and again before you rely on it — registrations get cancelled over time. There is no single legally mandated interval; the cadence is a risk decision for you and your tax adviser.

Does validating at signup cover me for reverse charge?

Only if you keep the evidence tied to the relevant supply. A check is valid as of its timestamp, so a signup-time check supports invoices around that date, not indefinitely.

What evidence should I keep from each check?

The VAT ID checked, the result, when it ran, which source answered, and the VIES consultation number where one was issued. Stored together, that is a reproducible record you can show on audit.

Validate on every trigger, from your own code

The four triggers all reduce to one call: validate a VAT ID against VIES and keep the result. Get a free API key and wire the VIES validation API into onboarding, invoicing, and your periodic revalidation — free plan, 100 requests/month. Official references: the VIES service on Your Europe.