Two obligations arrive in the same project and are almost never handled by the same people.
One says: issue a structured invoice, transmit it through a defined channel, report data about it, and keep the whole arrangement provable for years. The other says: you may only process personal data where you have a basis, only for as long as the basis holds, and only with appropriate arrangements wherever somebody else touches it.
Both are law. They point in different directions on almost every design decision, and the reconciliation is not difficult — it is just work that has to be done deliberately, and in most implementations nobody is assigned to do it.
Yes, it is personal data
The first objection is always that invoices are business documents. It does not survive contact with the actual data.
An invoice to a sole trader identifies a natural person by name and address, frequently by a tax identifier that is the person's own. An invoice to a limited company usually carries a contact name, a purchase order raised by a named individual, a delivery accepted by one. Around the document sits the transmission record: who submitted it, when, and what happened to it. And in accounts payable there is an approval trail attaching individuals to decisions.
So the mandate does not merely touch personal data occasionally. It creates a continuous flow of it, transmits it through third parties, delivers copies to an administration, and requires the whole thing retained past the point where anybody has an operational reason to keep it.
What each act needs a basis for
The useful discipline is to stop talking about "invoice data" as one thing and to separate the acts.
| The processing | What it is for | What supports it | What determines when it stops |
|---|---|---|---|
| Creating the invoice with the required particulars | Complying with the invoicing rules | The legal obligation to issue an invoice with those particulars | The retention obligation attaching to the document |
| Transmitting it through a network or platform | Complying with a mandate, or performing the contract | The mandate where one applies; otherwise the contractual necessity | Delivery, plus whatever evidence of delivery has to be retained |
| Reporting data to an administration | Complying with a reporting requirement | The reporting obligation itself | Set by the reporting rule, not by you |
| Retaining the document and its evidence | Complying with retention rules and defending the position | The retention obligation, and the establishment of legal claims | Expiry of the longest applicable retention period |
| Keeping contact and relationship records alongside | Running the commercial relationship | Not the tax obligation; a separate basis is needed | The commercial purpose, which usually ends much sooner |
That last row is the whole essay in one line, and the mistake it names is the common one. Because the invoice must be kept for years, the entire record around it gets kept for years — the correspondence, the contact history, the notes, the transmission logs beyond what evidences the transaction. None of that is required by the tax rule. All of it is inside the same folder, so all of it inherits a retention period that was never justified for it.
The provider is a processor
A service provider carrying your invoices is handling personal data on your instructions for your purposes. That makes them a processor, and the relationship requires a written arrangement with specific content: what they process, for how long, on what instructions, what happens on termination, what security applies, and what they may and may not do with sub-processors.
This is routinely skipped, because the contract is negotiated by procurement against a commercial checklist and the data protection annexe is assumed to be boilerplate. It is worth reading, for one reason: the sub-processor clause and the termination clause together determine where your invoices actually live and what happens to them when you leave.
That question overlaps almost exactly with the archiving question. Where the archive sits, who can reach it, and what comes back on exit are simultaneously a retention design decision and a data protection one, and they get better answers when treated as the same conversation. It is also one of the axes on which the in-house or provider decision turns out to be less about cost than it first appears.
An administration receiving data under a mandate is in a different position. It is not acting on your instructions; it is exercising a power. Your responsibility runs to what you transmit and to transmitting it properly. What happens to it inside the administration is governed by the rules applying to that administration.
Transfers, and the quiet ones
Where the archive or the platform sits outside the Union, transfer rules apply and require an appropriate mechanism. That much is well known and usually addressed.
The quiet ones are less well handled: engineers outside the Union accessing production data to diagnose a problem; a disaster recovery site in another jurisdiction; a sub-processor added under a clause permitting it with notice. Each is a transfer, none appears in the architecture diagram, and all are discovered during a review rather than at design time.
The practical control is unglamorous: ask the provider, in writing, where the data rests, where it can be accessed from, and who else touches it. The answer is a fact about their operation, they know it, and it takes one email.
In several Member States a sole trader's tax identifier is the same number as their national identity number. Where that is so, an invoice carries an identifier with a much wider significance than an accounting reference — it is a strong identifier that can be used to impersonate. That is a reason to be careful about who sees supplier master data and where extracts of it end up, and it is a specific instance of a general point about identifiers and the schemes they belong to.
The retention tension, resolved on paper
The apparent conflict is that tax law requires keeping and data protection requires not keeping. It is only apparent, and the resolution takes a paragraph.
The retention obligation is the purpose. It justifies holding the personal data in the invoice, and the evidence supporting it, for exactly as long as the obligation runs. When it expires, the purpose expires. Continued storage then needs a different justification — an actual one, such as a live dispute — or the data is deleted.
What makes this fail in practice is not the reasoning. It is that no deletion happens, because deletion is a project nobody funds and an archive with no expiry process is easier to operate than one with. An organisation that can articulate the reasoning and has never deleted anything has documented a policy it does not follow, which is a worse position than not having written it down.
The mechanics of the floor — which rule sets the period, and why it is usually longer than the tax minimum — are set out in retention periods across Europe. The point here is only that there is a ceiling as well, and that both edges have to be operable.
Access requests, and what they do not reach
A person whose data appears on an invoice can ask what is held about them. That right is real and it is narrower here than people fear, because the retention obligation is a legitimate ground for continuing to hold the data and the right to erasure yields to a legal obligation to retain.
Where it bites is in the surrounding material — the relationship records, the correspondence, the notes — which is precisely the material that had no independent basis for being kept as long as it has been. A business that separated the invoice record from the relationship record answers such a request in an afternoon. A business that kept everything together answers it by reviewing years of mixed material under a deadline.
That is the practical argument for doing the separation early, and it is the same argument as the retention one arriving from a different direction: the discipline of knowing which data is held under which obligation is what makes both the evidence requirements and the privacy requirements answerable without a project.
