Chain of custody for digital documents: what auditors and tax authorities actually require
Physical evidence has a chain of custody: a log of every person who handled it, when, and why. The chain proves the evidence has not been tampered with between collection and presentation. Courts refuse to admit physical evidence without it.
Digital documents have the same problem, and in most EU jurisdictions, the same requirement. The question is not whether your document is stored somewhere. The question is whether you can prove what happened to it between creation and today.
What chain of custody means for a document
Chain of custody for a digital document means being able to demonstrate:
- The document was created at a specific time
- Each subsequent modification, processing step, conversion, or transmission was recorded
- Each step is attributable to a specific actor (person, system, service)
- No step was omitted or altered after the fact
- The document presented today is the same document that went through those steps
For a physical object, custody is established by physical handoffs. For a digital document, it is established by cryptographic evidence: hashes, timestamps, and signed audit entries.
What EU tax authorities require
The requirements vary by country but share a common structure.
Germany (GoBD): The Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern defines that electronically archived documents must be protected against alteration, must be findable, and the original state must be reconstructable. The key phrase is “Unveränderbarkeit” (immutability): documents must be archived in a way that subsequent changes are technically prevented or at least detectable. GoBD also requires that the process of archiving itself be documented, meaning the chain from the original document to the archive must be traceable.
France (DGFiP): The Direction Générale des Finances Publiques requires that electronic invoices be stored in their original form, with integrity guaranteed by a technical means. For invoices received in PDF or hybrid format, the integrity guarantee must cover the entire retention period (six years for accounting documents, ten years for contracts).
Netherlands (Belastingdienst): The requirement is seven-year retention with verifiability. The Belastingdienst guidance on electronic archiving explicitly states that a document must be reproducible in a readable form and that the integrity of the document must be demonstrable.
Belgium: The FPS Finance aligns with EU Directive 2006/112/EC: authenticity of origin, integrity of content, and legibility must be guaranteed. The technical means (EDI, electronic signature, or audit trail) must be documented.
The common thread: archiving the document is not enough. You must also archive the evidence of integrity.
What auditors actually look for
When an auditor requests a document, they typically want to establish:
- The document is genuine (not fabricated after the fact)
- The document has not been altered since it was created or received
- The document was processed in a way that is consistent with your stated procedures
For tax audits, the first two are central. For compliance audits (GDPR, NIS2, sector-specific), the third is often equally important.
Auditors do not, in general, accept “trust me” answers. They look for technical controls that make fabrication or alteration detectable. The controls that satisfy them are:
Immutable timestamps from a trusted third party. A timestamp you generated yourself is not independent evidence. A timestamp from a trusted authority (an RFC 3161 qualified TSA) is. See RFC 3161 timestamps explained for how this works in practice.
Audit logs that cannot be retroactively modified. A log file on your own server that only you can access is not independent evidence. An audit trail where each entry is cryptographically linked to the previous one (a hash chain) means any modification to a past entry invalidates all subsequent entries. An auditor can verify this locally.
Format compliance documentation. If you claim an invoice was compliant with EN16931 on the date it was sent, you need the validation report from that date, not a validation you ran today. The report must be stored alongside the document.
The hash chain mechanism
A hash chain implements a tamper-evident audit trail. Each entry contains:
- The event data (what happened, who, when)
- The hash of the document at that point in time
- The hash of the previous entry
Entry 1: {event: "created", actor: "api:tenant-1", time: "2026-03-01T09:00:00Z",
docHash: "sha256:a3f...", prevHash: "0000...0000"}
entryHash: sha256(Entry 1 data) = "sha256:7c2..."
Entry 2: {event: "validated", actor: "system", time: "2026-03-01T09:00:01Z",
docHash: "sha256:a3f...", prevHash: "sha256:7c2..."}
entryHash: sha256(Entry 2 data) = "sha256:b19..."
Entry 3: {event: "timestamped", actor: "tsa:qualified-eu", time: "2026-03-01T09:00:02Z",
docHash: "sha256:a3f...", prevHash: "sha256:b19..."}
entryHash: sha256(Entry 3 data) = "sha256:f44..."If someone alters Entry 2 (for example, to change the actor or the time), the hash of Entry 2 changes. The prevHash in Entry 3 no longer matches. The chain is broken. An auditor computing the chain from Entry 1 will detect the inconsistency.
This is the same principle used in blockchain, but applied to document audit trails without the overhead of a distributed ledger. The chain is linear, deterministic, and verifiable with a SHA-256 implementation.
The gap between “stored” and “evidenced”
Most document management systems provide storage with access controls. Some provide version history. Few provide evidence.
The gap is: a system where only you control the audit log does not provide independent evidence of that audit log’s integrity. If you can delete or edit log entries, a skeptical auditor cannot rely on the log.
The mechanisms that close the gap are external anchoring (a qualified RFC 3161 timestamp from a TSA you do not operate), hash chain integrity (so that log modification is detectable), and format-level archival (PDF/A-3 so the document does not degrade or render differently over time).
These are the components of a Legal Evidence Pack. The pack is the unit of evidence you produce when an auditor asks to see a document.
Retention periods by document type (EU overview)
| Document type | Retention period | Key jurisdiction |
|---|---|---|
| VAT invoices | 7 years | Germany (GoBD), Netherlands |
| VAT invoices | 10 years | France, Belgium |
| Contracts | 10 years (commercial) | Most EU member states |
| Employment records | Duration of employment + 5-10 years | Varies by country |
| Accounting records | 10 years | Most EU member states |
| Medical records | 10-30 years | Varies significantly |
| Public procurement | 5-10 years after contract close | EU Directive 2014/24/EU |
Retention period starts at different points depending on document type and jurisdiction. For invoices, it typically starts from the end of the fiscal year in which the invoice was issued, not from the invoice date.
SealDoc and chain of custody
SealDoc records a hash-chained audit trail for every document that passes through its pipeline. The chain starts at document creation, includes every processing step (validation, conversion, signing, archiving), and is anchored with an RFC 3161 timestamp from a qualified EU TSA.
The audit trail is exported as part of the Legal Evidence Pack. Each entry is machine-verifiable independently of SealDoc’s systems. If your organization retains documents for ten years and SealDoc no longer exists in year eight, the evidence pack remains independently verifiable: the chain is computed from the document hashes, and the RFC 3161 timestamp is verified against the TSA’s public certificate, which is public record.
That independence is the point. Evidence that depends on the evidence-issuer’s continued operation is not reliable long-term evidence.