Vatidator
TL;DR. Microsoft's own documentation states that Business Central's built-in EU VAT validation service connects to VIES over HTTP without encryption. Business Central does keep a VAT Registration Log, but that log is a standard application record, not a tamper-evident cryptographic audit trail. Whether that gap matters depends on your specific audit and compliance context. This post walks through what the documentation actually says, what it means in practice, and three practical ways to close the gap.
What most teams miss in the documentation
Business Central makes EU VAT number validation easy. You enable the EU VAT Reg. No. Validation Service, enter a customer or vendor VAT number, and BC checks it against VIES, the VAT Information Exchange System provided by the European Commission.
That convenience is real and valuable. But there is one detail worth reading closely. Microsoft's documentation for the VIES VAT Number Validation service states that the service uses the HTTP protocol and that data transferred through the service is not encrypted.
This is not a Business Central bug in the usual sense. It is how the built-in Business Central service connection is documented to work. The practical point for BC users is simple: the default integration path described by Microsoft uses HTTP.
What actually travels over that connection
Before you decide whether to act on this, it helps to be precise about what data moves through the unencrypted transport:
- The VAT number you are validating (for example
DE811569869) - The requester country code (usually the country your BC tenant is established in)
- The response from VIES: name of the registered company, registered address, validation status, and a request identifier
For a single ad-hoc customer lookup, the exposure is limited. For a scheduled Job Queue running recurring validation across a large customer or vendor base, the picture is different: VAT identifiers and, where returned, company names and addresses may become part of a recurring unencrypted data flow.
That does not mean Business Central is non-compliant. It means this specific data flow should be an explicit risk-assessment decision by finance, IT security, and the DPO, rather than an assumption hidden inside a default ERP configuration.
Why this matters (without panic)
GDPR Article 32(1)(b) requires controllers to implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk, including the ability to ensure ongoing confidentiality and integrity of processing systems and services. Whether unencrypted HTTP transport of B2B VAT identifiers meets that "appropriate" bar for your specific organisation is a judgement your DPO and IT security team should make explicitly.
Similarly, ISO 27001 (2022) Annex A control 8.15 on logging and log protection expects organisations to keep log integrity assured against tampering. Your BC administrator answering "yes, we log validations" is a good start; the follow-up question ("and can you demonstrate the log has not been altered since?") is where many out-of-the-box configurations are weaker.
The right response to this is not to replace your ERP overnight. It is to name the gap, decide how much it matters for your organisation, and either accept the residual risk formally or close it.
The audit-evidence gap is not just about encryption
Transport encryption is only half of the picture. The second half is what evidence Business Central retains after the validation actually happens.
Business Central does keep a VAT Registration Log. It records validation history and includes a Request Identifier where VIES returns one. For day-to-day operational use ("did we check this customer's VAT?"), that is genuinely useful.
The limitation is that this is still a standard application log, not a tamper-evident evidence layer. The log lives in a regular table. An administrator with UPDATE or DELETE permissions on that table can alter or remove entries, and there is no cryptographic mechanism to detect after-the-fact modifications.
For a routine internal check, this is fine. For an audit context where the log itself is the evidence, whether that is zero-rating on cross-border B2B invoices, a compliance framework that expects tamper-evident logging (SOC 2 CC7.2, ISO 27001 2022 8.15), or an adjacent regulatory process where contemporaneous counterparty evidence matters, an application log is a weaker piece of evidence than a hash-chained one.
The difference is:
- Application log: "we recorded that we checked this VAT number on this date"
- Tamper-evident log: "we recorded that we checked this VAT number on this date, and we can make later modification detectable through cryptographic evidence"
Both are useful. The second is a stronger audit posture.
Three practical ways to close the gap
Option 1: DIY inside your BC tenant
If you have BC development capacity, you can:
- Wrap the outbound VIES call in your own HTTPS proxy. VIES exposes an HTTPS endpoint alongside the HTTP one, and a per-tenant extension can route through the encrypted transport instead of the default HTTP one.
- Add a per-validation log table that captures request payload, response payload, timestamp, requester, and source endpoint on every call.
- Add a hash-chain column: each row stores
SHA-256(previous_row_hash || current_row_payload). Any tampering with a middle row breaks the chain and is detectable. - Restrict UPDATE and DELETE permissions on the log table so operational users can only INSERT.
What you get: meaningful improvements in transport encryption and audit-evidence integrity, all self-hosted.
Realistic cost: 3–5 developer-weeks for the initial build, plus ongoing maintenance whenever Microsoft touches the underlying VAT Registration Log schema or VIES changes its SOAP contract. You will also need to build monitoring for VIES availability windows, and separate coverage for non-EU registries like UK's HMRC, Norway's Brreg, and Switzerland's UID Register, which VIES does not include.
Option 2: ISV compliance middleware
Several Business Central extensions and compliance middleware products address parts of this gap by adding HTTPS transport, per-validation audit logging, or cross-registry coverage. Vatidator's VAT Compliance Suite is one. Full disclosure: Vatidator is the author of this blog, and the extension is a Business Central add-on currently in the Microsoft AppSource review process. Other extensions in this category include Visiondata VAT ID Check, Astapor VAT Checker, and a handful of specialist vendors.
The trade-off is a monthly subscription, often at a price point that is materially lower than a full-service tax platform, in exchange for not needing to build and maintain the encryption + audit-log + registry-coverage stack yourself.
If your finance team's primary concern is stronger audit evidence on individual VAT lookups plus posting-time controls (block, warn, or allow invalid or missing VAT postings by policy), this tier is usually the fastest path.
Option 3: Full-service tax compliance
If your VAT complexity extends well beyond validation (OSS/IOSS filing obligations, e-invoicing mandates, US-and-EU footprint, or significant tax determination logic), the enterprise tax platforms (Avalara AvaTax, Sovos, Taxmarc) address the broader problem. These are usually priced as enterprise tax software rather than a lightweight BC add-on, and the value is end-to-end tax determination and filing rather than just VAT number validation.
The right option depends on how complex your VAT footprint really is.
A short self-assessment checklist
Regardless of which option fits, here is a checklist you can hand to your finance, IT, and compliance teams to make the current state of your BC VAT validation explicit:
- Is the connection from BC to VIES over HTTPS or over HTTP, and does anyone in the organisation currently own that decision?
- Does your VAT Registration Log contain the evidence your auditor expects: timestamp, result, Request Identifier where available, and enough context to reconstruct what was checked?
- Can an administrator with UPDATE or DELETE permissions modify the VAT Registration Log without detection?
- If a VAT number for a UK, Norwegian, or Swiss counterparty needs validation, does your process handle it, or does it fall back to a manual step?
- Are you running Job Queue bulk validation across the whole customer or vendor base, and if so, at what interval?
- How long are validation logs retained, and is the retention documented for auditors?
- Has your DPO signed off on the current data flow, including the unencrypted transport hop, as part of the documented risk register?
- For any regulatory process where counterparty verification evidence matters, will your current evidence format meet the reviewer's expectations?
If the answer to any of the first four items is "I am not sure," that is the honest starting point. Handing this checklist to your CFO, DPO, and BC administrator is more useful than any single tooling decision.
Frequently asked questions
Does Business Central's built-in VIES integration use encryption?
According to Microsoft's product documentation, the EU VAT Reg. No. Validation Service uses the HTTP protocol, and data transferred through the service is not encrypted. This is a documented characteristic of the built-in service.
Is Business Central VAT validation GDPR-compliant?
Business Central is not GDPR-compliant or non-compliant on its own. GDPR compliance is a property of how a controller uses the system. GDPR Article 32 requires appropriate technical and organisational measures for the confidentiality and integrity of processing. The unencrypted transport of B2B VAT identifiers is a documented factor that your DPO should include in the risk assessment for the specific processing activity. It does not automatically make your organisation non-compliant.
Does Business Central keep any log of VAT validations?
Yes. Business Central maintains a VAT Registration Log with validation history and, where VIES returns one, a Request Identifier. This is a standard application log. It is useful for day-to-day operational review, and it can serve as basic evidence that a validation occurred. It is not a tamper-evident cryptographic audit trail by default.
What does "audit-ready" mean for VAT validation?
There is no single formal definition. In practical audit contexts, teams usually mean each validation event produces a timestamped record, the source registry and Request Identifier, the response payload, and a mechanism (typically a cryptographic hash or hash-chain) that makes later tampering detectable. This is stronger evidence than a standard application log.
Can the BC VAT Registration Log be used as audit evidence?
Yes, for basic evidence. An auditor can accept a VAT Registration Log entry as evidence that a validation event was recorded on a specific date with a specific result. The limitation is that the log is a standard editable table without cryptographic tamper-evidence, so it is a weaker piece of evidence than a hash-chained log for frameworks that specifically expect log-integrity guarantees (SOC 2 CC7.2, ISO 27001 2022 8.15).
Is VIES itself unencrypted, or is it only Business Central's integration?
VIES exposes both HTTP and HTTPS endpoints. Business Central's built-in integration uses the HTTP endpoint per Microsoft's product documentation. A middleware layer or a custom extension can route requests through the HTTPS endpoint instead, closing the transport-encryption part of the gap for Business Central customers.
How do I close the gap without replacing my ERP?
Three practical paths, in order of build cost: build an internal extension that wraps VIES calls in HTTPS with your own audit log; subscribe to a compliance middleware or Business Central extension that provides HTTPS transport plus tamper-evident logging; or move VAT determination into a full-service tax platform like Avalara or Sovos. The right choice depends on the complexity of your VAT footprint and the budget available.
Where Vatidator fits
Full disclosure: this blog is published by Vatidator OÜ, and Vatidator builds the middleware option described above.
The VAT Compliance Suite is a Business Central extension that routes VAT validation through HTTPS to VIES and to additional national registries (UK HMRC, Norway's Brreg, Switzerland's UID Register), keeps a per-validation hash-chained audit log, and adds posting-time policy controls (allow, warn, or block invalid or missing VAT postings). Country-mismatch detection and configurable high-value thresholds are also part of the standard configuration. The extension is currently in the Microsoft AppSource review process, and technical documentation is available in the Docs section. Our public Information Security Policy and sub-processor disclosure is available for procurement and IT security review.
If Vatidator is not the right fit for your context, we hope the checklist above helps the conversation with your finance, IT, and compliance teams.
Published 2026-07-02 by Dávid Majzik, Founder, Vatidator OÜ. Corrections and disagreements welcome at [email protected].