An invoice used to be a thing you could put in a box. The box was the archive, the retention rule said how long to keep it, and legibility was a property of paper nobody had to design for.
A structured invoice inverts all three. There is no artefact that is self-evidently the document; there is a file whose meaning depends on a schema. Retention is not a matter of storage but of continued interpretability. And legibility, which used to be free, is now a capability that has to be maintained for as long as the retention period lasts.
Most archiving projects address the first of those and assume the other two look after themselves.
What is actually being retained
Start with the awkward question: what is the invoice?
If a structured document was issued and received, that document is the invoice. A rendered representation of it — a PDF produced from the XML for a human to look at — is a derived view. Keeping the view and discarding the original discards the thing the obligation attaches to, and it also discards the ability to demonstrate integrity, because the rendering cannot show whether the underlying data changed.
The safe formulation, and the one worth designing to, is that the archive holds the document as issued, plus whatever is needed to establish what it says and that it has not changed.
That "whatever is needed" is where the list gets longer than people expect.
| What | Why it is needed | Who holds it in practice |
|---|---|---|
| The structured document as issued | It is the invoice; everything else is derived from it | You, or your provider under contract |
| The schema or profile version it was valid against | Without it, nobody can say later what the file was supposed to mean | Nobody, usually — this is the commonest omission |
| A rendering route or a rendered copy | Legibility, which is a requirement rather than a convenience | You, if anybody |
| Transmission and receipt evidence | Establishes what was issued and when, independently of your own systems | The network provider or the clearance platform |
| Any seal, plus the means to validate it later | A seal nobody can validate proves nothing at the end of the period | You, plus a preservation arrangement |
| The identifiers linking to order, delivery and payment | The audit trail is only followable if its joins survive | Other systems, with their own retention rules |
The second row is the one that costs the most and is noticed the least. A file validated against a profile version that is later revised, stored with no record of which version applied, is a document whose conformance can no longer be assessed. It is still readable. It is no longer checkable.
Where the archive may live
Cross-border storage is permitted in principle and conditioned in practice, and the conditions are national rather than European. Several Member States attach requirements to storage outside their territory — typically full online access, the ability to download, and inspection without delay — and some distinguish between storage inside the Union and outside it.
The practical consequence is that "we use a cloud archive" is not an answer to the question. The answer has to be given per jurisdiction, and it has to survive the fact that a cloud provider's storage region can change without anyone in finance being told. Where the obligation includes immediate access on request, an arrangement that involves a support ticket and a restore from cold storage may satisfy the letter and fail the request.
Whose archive it is
A service provider that carries your invoices will normally offer to keep them. That is convenient, and it introduces a dependency that deserves examining before rather than after signing.
The obligation remains with the taxable person. A provider holding the documents is discharging a task on your behalf; if they lose them or change their retention terms, the obligation is still yours and the documents are not. So the questions that matter are contractual: how long they hold them, in what form, what happens at termination, and whether what you get back includes the receipts and metadata or only the invoice files.
That last distinction matters. A bulk export of XML documents is not an archive. An archive is those documents plus the evidence of what happened to them, and that evidence is the part a provider is least likely to export by default, because it lives in their operational systems rather than in your account. This is one of the axes on which choosing an access point is really an archiving decision wearing a transmission decision's clothing.
Format obsolescence is a real risk, not a theoretical one
Retention periods run into years, and years is long enough for the technical landscape to move. A syntax version falls out of use. A rendering application is discontinued. The stylesheet that turned a document into something readable was on a server decommissioned during a migration nobody connected to the archive.
None of that is exotic. All of it happens on ordinary timescales, and each of them attacks legibility rather than integrity — which is why an organisation with excellent cryptographic hygiene can still fail the simplest possible request.
There are two defensible responses. Preserve the rendering capability as part of the archive, treating the schema and stylesheet as archival objects rather than as infrastructure. Or keep a rendered representation alongside the structured one and accept the duplication, which is precisely the pragmatic argument for hybrid documents that carry both a readable file and structured data. Neither is elegant. Both work, and doing neither is the common case.
The deeper point is that the syntax choice made at implementation has a retention tail. A document written in one of the two syntax bindings will still be that syntax in year eight, whatever the market has moved to, and the archive is where that decision is finally paid for.
Moving an archive — new provider, new storage, format conversion, a corporate reorganisation — puts every document through a process that could alter it. Afterwards, the only assurance that nothing changed is the record kept of the migration itself: what was moved, how it was verified, what the counts and checksums were, who signed it off. Businesses that document this are fine. Businesses that treat it as routine infrastructure work have broken the chain at exactly the point where nobody thinks to look.
The retention clock is not one clock
How long any of this has to be kept is not a single number and not a European one. The VAT period is set nationally, and it is frequently not the longest obligation attaching to the same document — commercial law, sectoral rules and limitation periods all have their own, and the binding one is whichever runs longest. Working that out for a given entity is a separate exercise, set out in retention periods across Europe.
Two consequences for archive design follow. The archive has to be capable of holding to the longest applicable period rather than to the tax minimum. And it has to be capable of deleting when that period ends, because the other side of the obligation is a data protection principle that does not permit keeping personal data indefinitely for want of a process. How those two pull against each other, and how the tension is resolved on paper, is worked through in invoice data as personal data.
What good looks like
Unremarkable, and written down. The documents as issued, with their schema versions and receipts. A rendering path somebody has actually tested this year rather than assumed. A retention schedule reflecting the longest applicable rule, and a deletion process that runs when it expires. A migration record for every move the archive has made.
The test is not whether the archive would survive a disaster. It is whether somebody who joins the company in six years, handed a request for an invoice from today, can produce it, read it, and say what it was validated against. If the answer depends on a person who still works there, it is not an archive. It is a memory, and the whole point of assuring the three properties is to have something better than one.
