GDPR and Customer VAT Data: What You're Actually Storing

You called a VAT validation API, got back a JSON object with a dozen-odd fields, and wrote the whole thing to a row in your database. That’s the normal path. This post is about a narrower question: which of those fields are personal data under GDPR, and how do you think about minimizing and retaining them without either over-collecting or deleting evidence you need.

This is general information about GDPR and VAT data, not legal advice. How data-protection law applies to your specific storage and retention is a question for qualified counsel – nothing here is a substitute for that.

What a check actually returns

A VAT validation response carries more than a valid/invalid flag. Depending on the source that answered, a typical response includes, among other fields: valid, vatId, countryCode, countryName, companyName, companyAddress, checkId, verifiedAt, source, and a nullable consultationNumber – what that field is and why it’s nullable is its own topic; here it matters only as one more field in the row you’re storing. National fallback lookups – tax authority and company registry APIs, not VIES – can add registration date, legal form, activity description, registry codes, a commercial or trade name distinct from the legal name, and an operational status.

One field is easy to miss and worth calling out: registryPrivacy, a boolean some national registers set when the record itself has been flagged as restricted from publication at the registrant’s own request – the French non-diffusible marker and the Dutch afscherming setting are the two concrete examples of this mechanism. vatnode’s API returns the full record to the caller even when registryPrivacy is true; only vatnode’s own public /check pages mask it. That distinction matters for what comes next: the registry itself has already decided this record deserves handling, and what you do with it downstream is a decision you own, not one the API makes for you.

None of this is a certification. Format validity doesn’t mean a company is registered or active, and VIES doesn’t certify or guarantee anything about the counterparty – it answers the specific question it was asked.

Which fields can be personal data

A VAT number tied to an incorporated company is generally not personal data – it identifies a legal entity, not a natural person. The line moves when the number identifies an individual. In several EU member states, a self-employed person or sole trader holds a VAT number linked to them as a natural person, not to a separate corporate entity.

The Netherlands is a concrete, citable example of how directly that link can run. Until 1 January 2020, Dutch sole-trader VAT numbers embedded the holder’s BSN (the citizen service number) – the Dutch data protection authority found no legal basis for that construction, and the Dutch tax authority moved sole traders to a separate randomized btw-id instead. That’s one jurisdiction’s history, not a rule that generalizes to all 27 member states, and this post doesn’t attempt to list which ones structure sole-trader VAT numbers the same way.

The practical takeaway: where a VAT number, name, or address relates to an identifiable natural person – a sole trader or other individual – that data may constitute personal data. The companyName and companyAddress fields your check returns are exactly where this shows up. For an incorporated company those fields describe the entity. For a sole trader, they can be the person’s own name and address, returned to you by a registry or VIES rather than provided directly by the individual – which raises a transparency question (what the individual was told, and by whom, about that data reaching you) that this post flags without resolving.

Whether the counterparty in front of you falls on one side of that line or the other is part of your own analysis, case by case.

Data minimization

Minimizing what you store doesn’t conflict with keeping an audit trail – the two apply to different things. Minimize what you collect and expose; retain what your invoice and audit trail actually needs. An append-only check log, as covered in storing VAT IDs in PostgreSQL, is immutable within a bounded retention window – that’s a durability property, not a promise to keep every field forever. A cached result is a different layer again: caching VIES responses without losing compliance evidence walks through why a fast Redis-layer cache and the durable evidence row are not the same thing and shouldn’t be minimized the same way.

registryPrivacy is the concrete case where this earns its keep. If a national register has flagged a record as restricted from publication, that’s a signal worth acting on in your own exposure surface – who can see companyName and companyAddress in your dashboard, your customer-facing pages, your support tooling – even though the API itself still returns the full record to you as the caller. What you store because you need it for evidence and what you display or forward to other systems are two separate decisions.

The same logic applies to fields you don’t need at all. If your business process only ever checks that a number is currently valid and doesn’t use registration date or activity description, there’s no minimization reason to persist those fields just because the API returned them.

Lawful basis

Storing personal data under GDPR requires a lawful basis – Article 6 sets out the closed list. Which basis applies to a given case – a B2B onboarding check, an invoice you’re required to keep, a recurring subscription revalidation – is part of your own analysis of your specific processing, not something a blog post can assign on your behalf. The basis you land on can also shape how long you can justify holding the data, which is the next question.

Retention: floor and ceiling

Two obligations pull in different directions, and reconciling them is jurisdiction-specific.

Tax and invoice record-keeping law sets a floor. Council Directive 2006/112/EC Article 247(1) leaves the storage period to each EU member state rather than fixing one EU-wide number – there is no single figure to cite. As a schema-level default, storing VAT IDs in PostgreSQL notes that invoice retention commonly runs around 6–10 years, jurisdiction-dependent; confirm the period that applies to you before writing a deletion policy.

GDPR’s storage-limitation principle (Article 5(1)(e)) sets a ceiling principle – data shouldn’t be kept longer than necessary for the purpose it was collected for – without attaching a number of its own. In practice, that ceiling is usually satisfied by aligning your retention period with the invoice obligation that gave you the floor: you keep the record for as long as the tax law requires it as evidence, and no explicit further period beyond that. How exactly the floor and ceiling reconcile in a given member state, for a given record type, is a question for qualified counsel, not a formula this post can supply.

Erasure vs. immutable evidence

A sole trader may ask you to erase their data while a record-keeping or evidence obligation may point the other way. GDPR anticipates that tension – erasure rights under Article 17 are not absolute, and record-keeping obligations are one of the recognized grounds that can limit them. How that resolves for a specific record, in a specific country, for a specific request, is a question for qualified counsel, not something this post can tell you to refuse or to honour. What you can control ahead of time is the design: an audit trail built from append-only check records makes it possible to identify exactly which record an erasure request touches, rather than facing an undifferentiated pile of data when the request arrives.

Controller and processor

Working out who is the controller and who, if anyone, is a processor for a given piece of stored VAT data is a question tied to your own setup – your contracts, your data flows, who determines the purpose and means of processing. It’s not something this post resolves in the abstract, and it’s not something to assume applies uniformly to every vendor in your stack.

Cross-border transfers are a related but separate question, out of scope here.

What this means in practice

A short, informational checklist – not a compliance procedure:

• Know which fields in your check response can carry personal data for a sole trader (companyName, companyAddress, the VAT number itself) versus fields that only ever describe an incorporated entity.
• Restrict who sees a record flagged registryPrivacy in your own systems, even though the API returns it in full.
• Store only the fields your invoice and audit process actually uses; don’t persist the rest by default.
• Align your check-record retention with your invoice retention obligation for your jurisdiction, and revisit it if either the tax rule or your legal read of the GDPR ceiling changes.
• Treat an erasure request against an evidence row as a case to route to counsel, not one to resolve unilaterally either way.

None of this is a substitute for advice specific to your data, your jurisdiction, and your contracts. This is general information about GDPR and VAT data, not legal advice – how it applies to your storage and retention is a question for qualified counsel.

FAQ

Is a VAT number personal data under GDPR?

It depends on who it identifies. A VAT number tied to an incorporated company is generally not personal data, but where the number identifies an individual – a sole trader or freelancer whose VAT ID is linked to their own name – it may constitute personal data under GDPR Article 4(1). Treat the classification as conditional, not a blanket yes or no. This is general information, not legal advice.

Is the company name and address a VIES check returns personal data?

The same distinction applies. A registered company’s name and address are typically not personal data, but a sole trader’s returned name and address can be their own, in which case they may qualify. A safe default is to treat those fields as potentially personal until you know the counterparty is an incorporated entity. This is general information, not legal advice.

How long should we keep VAT check records?

A common approach is to align retention with your invoice record-keeping obligation, which each EU member state sets itself rather than a single EU-wide figure – commonly several years, jurisdiction-dependent. GDPR’s storage-limitation principle points the other way, so the period is one to confirm with qualified counsel for your jurisdiction, not a number to copy from a blog post. This is general information, not legal advice.

Do a checkId, verifiedAt timestamp, and consultation number add GDPR exposure?

On their own these are usually low-risk metadata rather than personal data, but the same minimization principle applies – keep only what your audit trail actually needs, and store it next to the transaction it supports. This is general information, not legal advice.