Archiving, integrity and retention: the obligation that outlives the project

The invoice is issued, cleared, delivered. The project celebrates and moves on. And then, quietly, the longest obligation in the whole regime begins: you now have to keep that invoice — readable, authentic and unaltered — for years, and be able to produce it on demand long after the team that built the integration has disbanded. Archiving is the least glamorous part of an e-invoicing programme and the most expensive to bolt on afterwards. Here is how to design it once, at the start.

1. Three obligations hiding in one word

"Archiving" bundles three separate duties that people tend to collapse into "we'll keep a copy". They are distinct, and each has its own rules:

• Retention — keeping the document for a defined period.
• Integrity and authenticity — being able to show it has not changed and that it really came from the stated supplier.
• Availability and legibility — being able to find it and render it in a human-readable form throughout the retention period.

A folder of XML files on a share drive satisfies none of these properly. It has no integrity guarantee, no legibility story, and usually no retention discipline. Treat the three as separate requirements with separate designs.

2. Retention: how long, from when

Retention periods for invoices are long and vary by country — very commonly in the range of six to eleven years, and set by national tax and commercial law rather than by the e-invoicing mandate itself. Two details matter more than the headline number:

• When the clock starts. Retention typically runs from the end of the tax year or financial year in which the invoice was issued, not from the invoice date — which can add most of a year to the real horizon.
• Which law sets it. The same document can be caught by more than one retention rule (VAT law, commercial/accounting law, sector rules). When they differ, the longest one governs your storage design.

3. Where the archive may live

Storage location is the requirement most often missed, because in a cloud-first world nobody thinks to ask. Some jurisdictions restrict where invoices may physically be stored, or require you to notify the authority if the archive sits abroad, or demand that it remain accessible online from within the country. Cross-border cloud storage — the default for most modern systems — can quietly breach a local rule.

The questions to answer per country, from the primary source, before you pick a bucket region:

• May the archive be held outside the country at all, and if so is there a notification or authorisation step?
• Must it be retrievable online, immediately, from within the jurisdiction on request?
• Are there data-residency or sovereignty rules that interact with the tax rule?

4. Integrity: signature or audit trail

Integrity and authenticity can usually be met in more than one way, and the choice is a legal decision with an engineering consequence — so it should be made deliberately, not defaulted. In the EU, for example, the VAT Directive lets a taxable person ensure integrity and authenticity by any business controls that create a reliable audit trail between the invoice and the supply — and names, as examples of specific technologies, a qualified electronic signature/seal or EDI with appropriate agreements. Other regimes are more prescriptive and simply require a signature or seal.

The long-term-validation point is the one that surprises teams. A signature that verifies today may not verify in eight years once its certificate has expired or the issuing authority has changed — so where you rely on signatures, you need a preservation format (timestamps, LTV) that keeps them checkable for the whole retention window. Decide this at design time; it is nearly impossible to add to documents after the fact.

5. What exactly gets archived

"The invoice" is ambiguous, and archiving the wrong artefact is a common and quiet failure. Depending on the regime you may need to keep several things, each tied to the same transaction:

• The structured file — the XML that is the legal invoice, not a PDF derived from it.
• The human-readable rendering, where a specific presentation is itself mandated or where legibility must be demonstrable.
• The response artefacts — the clearance identifier, the authority's acknowledgement, the network delivery receipt, any buyer acceptance or rejection.
• The integrity evidence — the signature and its validation material, or the audit-trail records.

Archive the structured original and its proofs, not a PDF of what it looked like. The XML is the invoice; the PDF is a photograph of it.

6. Designing it in

The pattern that survives a decade and an audit is boring by design:

1. Store the original and its proofs together, keyed by the transaction, from the moment of issue — the structured file, the response artefacts and the integrity evidence as one retrievable unit.
2. Make retention data-driven per jurisdiction, with the clock anchored to the correct start event, and a retention/disposal policy that will not delete something a longer rule still requires.
3. Preserve signatures for the long term where you rely on them, or capture and retain the audit-trail evidence where you rely on that.
4. Pin the storage location deliberately against each country's residency and access rules — do not let a default cloud region decide compliance.
5. Prove retrieval, not just storage. Periodically fetch and render an old document. An archive you have never read back is a liability you have not tested.

This is the seldom-scoped work behind question six — archiving, signature and integrity — in our guide to reading a new country mandate. It costs little to build alongside the send path and a great deal to retrofit once years of invoices already sit in the wrong place, in the wrong form, without their proofs.