Skip to content
Viesproof
VIES · requester-qualified · Art. 138

A VAT check has three answers. Most integrations handle two.

Valid, invalid, and nobody answered. Collapse the third into the first and you have zero-rated a sale you cannot defend. Collapse it into the second and you turn away real customers whenever a national system has an outage. Viesproof keeps all three apart and keeps the evidence.

500 checks a month on the free tier. No card.

POST /api/v1/verify

DE143454214

VALID

Registered in the member state's register

decision
ACCEPT_ZERO_RATED
consultationNumber
WAPIAAAAXjIuMzQ1NzY4OQ==
receipt.digest
a3f1c8…written either way

VIES answered, the number is registered, and it issued a consultation number. That number is the evidence — it is what a tax authority can look up years later.

Three answers, never two. The third is the one that decides whether your integration is honest.

Why it matters

The VAT number is not the evidence. The consultation is.

Since Directive (EU) 2018/1910, a valid VAT identification number checked in VIES is a substantive condition for exempting an intra-Community supply, not a formality. If the number turns out to have been invalid, the supplier carries the VAT — and the defence is being able to show that the register was consulted at the time of supply.

“We check VAT numbers” is not that showing. A row in your own database saying valid: true is a claim about your own software, which is exactly the thing under question.

What VIES gives you, and only for a requester-qualified consultation, is a number the Commission itself can confirm. Capturing it, keeping it, and being able to prove the record has not been edited since is the whole job.

How it works

One call at checkout. One receipt, kept forever.

01

Add your own VAT number

Supplying it is what makes a check requester-qualified. Without it VIES answers, but issues no consultation number — and a claim to have checked with nothing to point at is not evidence.

02

Call verify at checkout

One synchronous POST. Syntax is checked locally first, a recent valid answer is reused, and only then does the call reach Brussels. You get a decision, not a raw verdict.

03

Keep the receipt

Every consultation — including the ones that failed — is written into a per-organisation hash chain. Any later edit, deletion or reordering breaks verification and says where.

POST /api/v1/verify200 OK
curl -X POST https://viesproof.altixcode.com/api/v1/verify \
  -H "Authorization: Bearer vp_live_..." \
  -d '{"vatNumber":"DE143454214","clientReference":"order_9001"}'

{
  "decision": "ACCEPT_ZERO_RATED",
  "live": true,
  "check": {
    "status": "VALID",
    "consultationNumber": "WAPIAAAAXjIuMzQ1NzY4OQ==",
    "trader": { "name": "Example GmbH", "address": "..." },
    "receipt": { "digest": "a3f1c8…", "previousDigest": "7b20e4…" }
  }
}

What makes it evidence

A record you cannot quietly improve later.

The consultation number is the point

VIES only issues one for a requester-qualified check. It is the number a tax authority can look up to confirm that you consulted the register on a given day. A check without it is a log line; a check with it is evidence.

Failed checks are recorded too

An archive that only holds successes proves nothing about diligence. When a member state is down, that consultation is chained like any other, with the reason VIES gave.

The chain catches deletion, not just edits

A per-row hash would leave every surviving row internally consistent after an inconvenient one is removed. Each receipt commits to its predecessor, so a gap is visible and verification names the index it broke at.

Signed, so a database writer cannot forge it

Digests are HMAC-signed with a key held only by the server. Someone who can write rows can recompute a digest; without the key they cannot produce a signature that verifies.

Where this stands

New service. Adversarially tested. Not tax advice.

The receipt scheme is tested the way an attacker would use it: the suite flips verdicts, invents consultation numbers, deletes rows, reorders the chain and forges signatures, and asserts that verification catches each one and names where it broke. Concurrency is tested too — twenty simultaneous checkouts, with the chain still intact afterwards.

What we will not claim: that a valid check makes a supply exempt. It is one of several substantive conditions, and the others — that the goods left the member state, that the recapitulative statement is filed — are yours. We make the VIES part provable; we do not make it sufficient.