Your billing job runs at 02:00, VIES times out, and a customer from another EU member state is waiting on an invoice with reverse charge applied. The response you get from VAT validation is not a permanent record you can trust forever. It is a point in time compliance signal tied to one service call, one tax ID, and one moment.
That distinction matters in production.
A VAT validation response answers a narrow operational question. Was this VAT number considered valid when the check was made, and did the authority return enough data to support your invoicing decision? It does not guarantee that the registration will still be valid tomorrow, that the legal name will match your CRM exactly, or that every member state's upstream service is healthy when your checkout runs.
Teams usually get into trouble when they treat validation as static master data. They store one successful lookup, mark the account as verified, and never check again. That works until a registration changes, an authority sync lags behind, or an auditor asks what evidence existed at the time the invoice was issued.
A safer implementation stores the full response, the checked VAT number, the request timestamp in UTC, the member state, the result status, and any correlation or consultation reference returned by the service. Cache successful validations for a defined period that matches your risk tolerance and billing model. For a one off B2B invoice, a short cache may be enough. For subscription renewals, revalidation before tax critical events is usually the better trade off.
Outages need a separate path. VIES and national systems do fail, sometimes briefly, sometimes during the exact window when invoices are generated in bulk. In that case, the system should not pretend the number is invalid. It should mark the result as unavailable, keep the order or invoice in a reviewable state, retry with backoff, and record why tax treatment was deferred or applied provisionally.
In practice, I use three states in billing flows: valid, invalid, and unavailable. "Unavailable" prevents a technical outage from becoming a tax decision. That one choice avoids a lot of bad automation.
Retries also need limits. Immediate retries can help with transient network faults. Repeated retries against an upstream outage just create noise, slow your workers, and make incident handling worse. Use bounded retries, jitter, and a queue that can resume checks after the dependency recovers. For high volume SaaS billing, that is more useful than chasing perfect real time validation on every request.