← Back to all articles

RFC 3161 timestamps: what they are, why they matter, and when they are legally required

SealDoc Team · · 6 min read

Imagine you hand someone a letter, they dispute when it was written, and you have no way to prove the date other than your own word. A notary solves that problem by witnessing the document and stamping it with a date they are legally responsible for. RFC 3161 is the cryptographic equivalent: a trusted third party attests, in a way that is mathematically verifiable, that a specific document existed at a specific moment in time and has not been modified since.

This matters for EU e-invoicing because tax law does not just require you to keep invoices. It requires you to keep them in a way that makes tampering detectable. An RFC 3161 timestamp is one of the strongest mechanisms available to meet that requirement.

How a trusted timestamp works

The basic mechanism has four steps:

  1. Hash the document. A cryptographic hash function (SHA-256 or SHA-512 in modern implementations) is applied to your document. The result is a fixed-length fingerprint. Any change to the document, even a single bit, produces a completely different fingerprint.
  2. Submit the hash to a Timestamp Authority. You send only the hash, not the document itself, to a trusted server called a Timestamp Authority (TSA). The TSA never sees your document content.
  3. The TSA signs the response. The TSA creates a signed token that binds your hash to the TSA’s current time, signed with the TSA’s private key. This token is the timestamp. It contains: the hash of your document, the time, and the TSA’s digital signature.
  4. You store the token alongside the document. Later, anyone can verify that your document’s hash matches the hash in the token, and that the token’s signature was issued by the TSA at the stated time.

The security guarantee is simple: if someone tampers with your document after the timestamp, the hash will no longer match the one in the token. If the TSA’s private key is trusted (which is the legal and technical question that qualified TSAs answer), then the timestamp is accepted as evidence of the document’s existence and integrity at that moment.

RFC 3161: the standard

RFC 3161 is the IETF standard that defines the protocol for requesting and receiving timestamps. Published in 2001 and still current, it specifies the message format for the hash submission, the structure of the signed token, and the cryptographic algorithms involved.

An RFC 3161 token is self-contained. It does not rely on the TSA’s servers remaining online. You can verify a 10-year-old timestamp offline by checking the TSA’s certificate chain, which is separately archived. This is important for legal archival: the evidence you file today must be verifiable in 2035, regardless of whether the TSA you used is still in business.

Qualified vs. basic TSAs

Not all Timestamp Authorities are equal under EU law.

A basic TSA operates an RFC 3161 service, but makes no specific legal commitments about its time source, audit procedures, or key management practices. Basic timestamps are technically valid but carry no special legal presumption.

A qualified TSA is accredited under Regulation (EU) No 910/2014, known as eIDAS. A qualified TSA:

  • Uses a time source traceable to UTC via national metrology institutes
  • Operates under audited security procedures
  • Is listed on a national trusted list maintained by the relevant supervisory body
  • Issues timestamps that carry a legal presumption of accuracy under eIDAS Article 41

Under eIDAS, a qualified electronic timestamp enjoys a presumption of accuracy as to the date and time it indicates, and the integrity of the data to which the date and time are bound. In plain terms, this means a court cannot easily dismiss it.

For most EU e-invoicing archival requirements, a qualified timestamp is the gold standard. For many business-to-business scenarios, a basic RFC 3161 timestamp from a reputable TSA is still valuable evidence even without the qualified status.

When timestamps are legally required

The requirement varies by country, sector, and document type. Here is a practical overview:

Electronic signatures under eIDAS. A qualified electronic signature (QES) is legally equivalent to a handwritten signature across the EU. Timestamps are not mandatory on every signed document, but a timestamp bound to a signature at the moment of signing prevents later dispute about whether the signature was valid at that time (relevant if the signing certificate expires or is revoked after signing).

Invoice archival (all EU member states). EU VAT Directive 2006/112/EC requires that invoices are stored in a way that guarantees the authenticity of their origin and integrity of their content throughout the retention period (typically 7 to 10 years depending on national law). A timestamp plus a hash manifest is a recognised technical implementation of this requirement.

German GoBD (Principles of proper bookkeeping). German tax law explicitly requires that digitally stored documents are protected against undetected alteration. An RFC 3161 timestamp satisfies this requirement.

Dutch Archiefwet. Dutch archival law for government bodies requires timestamps on archived digital documents. Private businesses are expected to follow equivalent standards for records that may be requested by tax authorities.

Regulated sectors. Financial services, healthcare, legal, and pharmaceutical sectors in the EU have additional document retention requirements that frequently mandate timestamping beyond what general tax law requires.

B2G invoicing. Several EU countries require qualified timestamps or equivalent protection for invoices submitted to government entities.

What happens without a timestamp

Without a timestamp, you can assert that an invoice was created on a particular date, but you cannot prove it. If a tax authority or court challenges the date, or disputes whether the document was altered after the fact, your position rests entirely on your own records, which are not independent evidence.

More specifically:

  • An undated PDF can in principle be backdated. A court may require additional corroboration to accept the claimed date.
  • An invoice that was modified after archival with no tamper-detection mechanism cannot be distinguished from one that was not modified.
  • In a VAT audit, the burden of proof that an invoice is authentic and unaltered rests with the business. A timestamp is the strongest single piece of evidence you can provide.

How SealDoc implements RFC 3161 timestamps

Every document processed by SealDoc carries an RFC 3161 timestamp by default from the Starter plan onwards. Here is what we do:

  1. We generate or convert your document (PDF/A-3, Factur-X, or both).
  2. We compute a SHA-256 hash of the output file.
  3. We submit the hash to a trusted TSA and receive a signed token.
  4. We embed the token in the PDF’s document metadata and include it in the evidence pack.
  5. We record the timestamp in our chain of custody log, which is separately tamper-evident.

The evidence pack we return contains the RFC 3161 token as a standalone .tsr file, which can be verified with any RFC 3161-compliant verification tool independently of our servers. The manifest hash file in the same evidence pack ties the original document, the converted document, and the timestamp together so the complete chain is verifiable offline.

For invoices where qualified timestamps are required (typically high-value or regulated-sector documents), we use a qualified TSA from the EU trusted list. The TSA we use is 100% EU-based.

If you want to understand the full compliance picture for your specific country and invoice type, our legal compliance page maps each EU mandate to the technical requirements, including which timestamp level is sufficient and which is required.

For immediate verification of an existing document, our Validator tool checks whether a file carries a valid RFC 3161 token and reports the timestamp details alongside the PDF/A and Factur-X compliance checks.


← Back to all articles