Automating VIES VAT ID Checks for SaaS Teams
A mishandled VAT ID (USt-IdNr.) causes problems well beyond the customer's master data. It changes the tax status of an invoice, can trigger reverse charge where it does not apply, and raises questions during the month-end close. If you want to automate VIES checks, you need more than a form field with a green check mark. You need a controlled process that runs from checkout or the CRM to the invoice, the ledger, and evidence that holds up in an audit.
Why VIES matters in the billing stack
VIES is the European Commission's VAT Information Exchange System. It lets you check whether a VAT ID issued by an EU member state is valid at the time of the query. For cross-border B2B transactions, this check is a core input for the tax treatment.
For a SaaS company, the complexity shows as soon as revenue models move. A customer changes its country, adds a VAT ID after signing the contract, switches from monthly to annual billing, or buys additional seats. With usage-based billing, invoices are generated automatically from usage events. If the tax decision sits outside the billing system, in a CRM export or an Excel list, the process is not under control.
Operationally, knowing whether a number is valid is only part of the answer. You also need to know which tax status applied to a specific invoice, based on which data, at what time, and with which documented check result. That link decides whether Finance can trace a close and whether Engineering can make changes without touching tax logic.
Automating VIES checks: when to run them
A single check at onboarding is rarely enough. VAT IDs can change, customer data can be corrected, and VIES can temporarily fail to respond. Reliable automation therefore runs the check at several trigger points.
When a customer profile is created or updated, first normalize the syntax of the number, with clear handling of the country prefix, spaces, special characters, and format errors. Then start the VIES query. Store the result as a versioned entry in the customer's tax profile. An unstructured comment in the CRM is the wrong place for it.
A second decision comes before the invoice is released. If there is valid and sufficiently recent evidence, and the country of supply, customer country, type of service, and tax rule fit together, the invoice can be created with the intended reverse charge or VAT treatment. If the evidence is missing or the result is unclear, the system must not silently take the same path it would take for a validated B2B customer.
For recurring contracts, a risk-based recheck makes sense. The right interval depends on transaction volume, countries, internal policies, and tax advice. High invoice totals, changes to the billing address, or a new VAT ID justify closer checks than an unchanged account with a low monthly fee.
A VIES response is one input to the tax decision
VIES does not give a full tax assessment of a transaction. A valid result is relevant evidence that you should document, but on its own it does not settle questions about the place of supply, a permanent establishment, the line between B2B and B2C, or special rules. Depending on the member state, the company name or address returned may also be missing or differ.
The tax engine should therefore work with explicit states. For operations, valid, invalid, unavailable, pending_review, and expired work much better than a single boolean field. Above all, unavailable must never be reinterpreted as invalid, because an outage of the external service is no evidence that the number is invalid.
The workflow: from customer profile to auditable invoice
A clean process keeps data capture, validation, the tax decision, and the record of evidence apart. That separation prevents a UI validation at checkout from being misread later as final approval for the invoice.
First, the customer profile captures the legally relevant attributes: billing country, company name, VAT ID, any differing service or delivery details, and the status of the customer's tax classification. Changes should be recorded as events, so you can trace when an attribute changed and which downstream processes followed from it.
Next, an asynchronous validation service calls VIES. At a minimum, it stores the country prefix and number, the query time in UTC, the result status, any reference data returned, technical error messages, and the rule version used. Each response must be clearly linked to the customer profile and to the invoice issued later. For audits and incident analysis, knowing only the current status is not enough.
During the invoice preview, the tax engine checks the current status against a defined freshness policy. If an invoice is created on April 1, for example, it must be clear whether a check result from January is acceptable for it. This rule is a business and compliance decision. It should not be left to whatever cache lifetime happens to be set in the code.
Only then are the tax amount, the tax note, and the invoice lines finalized. For reverse charge, the invoice text has to fit the specific service and the legal situation, and one generic text template for all countries and cases cannot replace proper rule modeling. The resulting invoice document, the tax decision, and the VIES evidence together form the traceable record behind the invoice.
Design for outages, retries, and manual approvals
VIES is an external service. It is sometimes unavailable, and its responses vary by country. If you run the check synchronously in checkout, your conversion depends on a government integration. If you ignore it completely, the risk moves to Finance. The practical approach is asynchronous processing with clear blocking logic before the invoice is issued in its final tax form.
Retries need backoff, a limited number of attempts, and queues you can monitor. On unavailable, the system should retry automatically and also open a case for manual handling once a configured period has passed. In high-volume billing, a dead-letter queue status is a finance operations signal as much as a technical one. Which invoices cannot be released, how much MRR is affected, and who decides what happens next?
A manual approval must not overwrite the automated evidence without leaving a trace. Record who handled it, the timestamp, the reason, the supporting documents, and a new check where needed. That keeps exceptions visible and stops them from turning into a hidden second set of books.
Keep the evidence findable from the ledger
In many billing stacks, the weak spot is between the invoice and accounting. The invoice shows reverse charge, the VAT ID is in the CRM, the check result sits in a logging system, and the DATEV export contains only journal entries. When a question comes in, someone has to pull data together from four systems.
A better setup is an immutable evidence record that links the VIES query to the customer version, invoice ID, tax rule, invoice number, and ledger posting. It cuts audit effort, and it keeps later master data changes from distorting the historical context of old invoices.
Data minimization still applies. Store only the data you need for validation, tax documentation, and internal control, and define retention and access policies. A debug log that anyone can open, with full customer addresses in it, does nothing for compliance.
What Engineering and Finance should decide together
Implementations often fail on decisions left open between teams, and less often on the VIES interface itself. Finance defines tax rules and escalations. Engineering models states, idempotency, and fault tolerance. Revenue Operations monitors exceptions and their revenue impact. Without shared ownership, every discrepancy ends up in Excel during the month-end close.
In practice, teams should agree on when a result counts as outdated, when an invoice gets blocked, which cases go to manual review, and how a later correction is processed. They also need to settle whether invoices already issued must be canceled and reissued, or whether a corrective document is required. That depends on the facts of the case and the applicable rules.
Kontier connects these steps in a European billing infrastructure. Customer and tax profiles, VIES status, reverse charge rules, invoice documents, and ledger data that accounting can use all stay part of the same workflow. Price changes without a deployment are of no use if someone has to recheck the tax decision by hand after every change.
A well-built automated VIES check stays invisible in normal cases and lets the team act right away when an exception comes up. The goal is an invoice whose tax treatment can still be explained weeks later, without Excel, without reconstructing what happened, and without room for interpretation.