VAT validation is not a lookup. It is a control.

TL;DR. A VAT lookup tells you whether a number is valid. A VAT control decides what should happen next: warn, block, allow, re-check, or record evidence. That difference matters because VAT-relevant decisions happen inside ERP and CRM workflows, not in standalone lookup tools.

The lookup framing has a ceiling

In most systems, VAT validation is treated as a simple lookup: send a VAT number to a registry, get back a status, and store the result somewhere.

That is useful, but it is only the technical primitive. It is not the finance control.

The finance problem is that VAT status matters at specific moments: when a sales rep creates a new B2B account, when finance approves a quote for a cross-border customer, when an order is released for shipment, when an invoice is posted, when a credit memo is issued, or when a dormant customer is reactivated. In each of those moments there is a decision, and the decision depends on whether the counterparty's tax identity is currently trustworthy.

A lookup on its own does not enforce anything. It tells you what the answer is. It does not tell you what to do with it. And it does not stop the wrong thing from happening if nobody is watching the result.

What "lookup thinking" produces

When VAT validation is treated as a lookup, organisations end up with a familiar pattern:

• Someone runs a bulk check quarterly, exports the results to a spreadsheet, and either fixes the flagged records manually or accepts them into the audit trail as-is.
• The AR team validates a customer at onboarding, records the result in a note field on the customer record, and never revisits it.
• Finance discovers on the day of invoice posting that a large customer's VAT number is invalid, holds the invoice, sends an email, and hopes the counterparty responds before month-end.
• The auditor asks for evidence that VAT numbers were verified before zero-rating decisions, and the team assembles a mixture of Excel exports, screenshots, and ERP log entries that reconstruct the past.

None of that is negligence. It is the natural end state of tools that stop at "was this VAT number valid at the moment you asked?" without engaging with the harder question: what should the system do about it?

A short scenario that makes the gap concrete

A sales team creates a German B2B account in Salesforce. The counterparty's VAT number is valid on the day the account is created, the tick appears in the CRM record, and the opportunity moves forward. Six months later, finance posts the first large invoice from the ERP. The customer record still shows "valid," but nobody knows whether that status is still current, what source confirmed it originally, or whether the tax treatment on this specific invoice was checked at posting time.

The lookup that ran six months ago did its job. The audit trail can show that a lookup happened. What it cannot show is that a posting-time control was applied, because there was no such control.

What a control does differently

A control layer starts with three questions the lookup framing skips.

1. Where in the workflow does this matter? VAT status matters at customer creation, at quote approval, at invoice posting, at credit-memo issuance, at bulk re-verification. The control layer participates in each of those events.
2. What should happen when the answer is not "valid"? Sometimes block. Sometimes warn. Sometimes allow with an override and a reason logged. The right choice depends on the transaction type, the counterparty context, and the organisation's policy, not on a single default from a vendor.
3. How do we prove later that the decision was made correctly? Every check produces evidence. Every override produces evidence. Every policy enforcement produces evidence. The evidence has to survive the next audit, not just the current one.

A control layer answers these three questions structurally, not through discipline. Discipline is not a compliance strategy at scale.

Where controls have to live

Controls only work if they are present at the moment of the decision. That means they cannot live outside the systems where the work happens.

The two systems where VAT-relevant decisions are made are the ERP (where invoices, orders, credit memos, and postings occur) and the CRM (where new accounts are created, opportunities are qualified, quotes are approved, and contract signatures are collected). In practice this means:

• The customer master data record in the ERP needs to carry a live validation status, a "last checked" timestamp, and a policy decision so that any posting-time process can act on it.
• The account object in the CRM needs to carry the same signal so that a sales rep sees the risk before a quote is committed, not after finance rejects it.
• The two systems need to agree on the underlying evidence, not just the status flag, so that an audit trail is continuous rather than reconstructed after the fact.

Standalone web-based VAT checkers can produce accurate lookups, but they cannot enforce anything. The check happens in a different tool, on a different screen, at a different time from the actual decision. By the time the answer reaches the person who needed it, the moment has passed.

Four moments where controls change outcomes

Here are four practical moments where a control layer produces a different outcome than a lookup:

Customer onboarding. A new B2B account is created in the CRM. A lookup can tell the sales rep "VAT number valid." A control can flag "VAT valid, but partner country does not match VAT prefix; verify the legal entity before setting up billing." That difference determines whether a bad master data record is caught in five minutes or in five months.

Quote and contract approval. A large opportunity is progressing toward contract signature. A lookup, if it runs at all, only shows a green tick. A control checks whether the counterparty's VAT number was checked recently enough under the organisation's policy, and whether the counterparty country is consistent with the pricing and tax treatment on the quote. Where the control finds a gap, the approval step surfaces it before contract signature, not after.

Invoice posting. Often the most expensive place to catch a VAT error. A lookup that ran at customer creation may be six months stale. A control enforces re-verification within a defined age window, blocks postings that fall outside it, and either forces the AR team to run the check again or records an explicit override with a business reason.

Bulk re-verification. Every organisation has a long tail of dormant customers and vendors whose VAT status was checked once and never revisited. A lookup approach means someone runs the batch when they remember to. A control means the schedule is defined by policy, the results are processed against decision rules, and the exceptions land in an actionable review queue rather than a static report nobody reads.

Five characteristics that separate a control from a lookup

If you strip away the marketing language, a VAT validation control has five structural characteristics a lookup does not:

1. It is embedded inside the systems where decisions happen (ERP and CRM), not in a separate portal or spreadsheet.
2. It is triggered by the events that matter (record creation, posting, approval, scheduled re-verification), not by a human remembering to run it.
3. It produces a policy decision, not just a data value (block, warn, allow with reason), parameterised by the organisation's own rules.
4. It records evidence in a tamper-evident form: timestamp, source registry, request identifier, response payload, and a cryptographic hash that makes later modification detectable.
5. It is consistent across systems: the same policy, the same evidence, the same audit trail whether the trigger came from the CRM side or the ERP side.

Each of those properties can be built. None of them appear for free just because you have an API to a registry.

Frequently asked questions

What is the difference between a VAT lookup and a VAT control?

A lookup answers a single question (is this VAT number currently valid?) and returns a status. A control is a system that decides what should happen because of the answer: whether to block a posting, warn a user, allow with a logged reason, or trigger a re-verification. Controls are embedded in ERP and CRM workflows; lookups are typically standalone.

Why is a standalone VAT checker not enough for B2B tax compliance?

Standalone checkers produce accurate answers at the moment they are run. They cannot enforce a policy at the moment a decision is made in another system. The gap between checker and workflow is where errors accumulate: stale statuses, missed re-verifications, and postings that go through despite a known invalid VAT number because nobody on the AR team saw the flag in time.

Where should VAT validation logic live: in the ERP or in the CRM?

Both, but not duplicated. The validation decision itself should be a shared service that both systems consume. The trigger points differ (CRM at account creation and quote approval, ERP at posting time), but the evidence layer and the policy configuration should be consistent. Otherwise the audit trail is split across two systems that disagree.

What does "audit-ready" mean in the context of VAT validation as a control?

Audit-ready means each control decision produces a durable record: the input (the VAT number and context), the source that was queried, the response received, the policy decision (block, warn, or allow), the reason if it was an override, the user who acted, and a cryptographic hash that makes later tampering with the record detectable. That record has to survive at the retention horizon of the relevant audit or regulatory review.

Can a VAT control layer be built on top of an existing ERP?

Yes. In modern ERP and CRM environments (Business Central, Salesforce, SAP, and the integrations between them), extension architectures usually make this possible. A control layer can participate in posting events, master data changes, and scheduled processes without modifying the core system. The value is in the design of the control, not in owning the surrounding platform.

How do we make the control layer consistent across ERP and CRM?

By making the evidence layer shared: the same validation service, the same audit-log format, the same request identifiers, the same policy configuration. That way an account validated at CRM onboarding produces evidence that the ERP can reference at posting time, and vice versa. The result is one continuous audit trail across two systems rather than two parallel logs that disagree.

Where Vatidator fits

Vatidator builds VAT validation as a control layer for ERP and CRM workflows, with a shared validation service, policy engine, and audit-evidence backend.

The VAT Compliance Suite for Business Central is the first implementation: it embeds validation, posting-time policy controls, and tamper-evident audit evidence directly in the ERP workflow. The same architecture is being extended toward CRM workflows next, starting with Salesforce, with SAP planned as a later enterprise ERP integration. The Business Central extension is currently in the Microsoft AppSource review process.

The goal is not to create another standalone VAT checker. The goal is to make counterparty verification available at the moments where business decisions are actually made: customer setup, quote approval, contract review, invoice posting, and audit review.

If this is the kind of control your finance and IT teams are trying to build, we would welcome a conversation.

Published 3 July 2026 by Dávid Majzik, Founder, Vatidator OÜ. Corrections and disagreements welcome at [email protected].