Retaining e-invoices: periods, GoBD and formats

Three questions keep getting stirred into one: how long, what exactly, and in what form. The second is the one that trips people up.

Three separate questions get stirred into one whenever e-invoice retention comes up: how long, what exactly, and in what form. The second is the one that trips people up in practice — and for a hybrid invoice it has a surprisingly clean answer.

This is orientation, not tax advice. Retention periods depend on the individual case, the legal form and what else sits in the same file. The figures below are correct; whether they apply to you is for your tax adviser.

How long: eight years, with exceptions

Germany’s Fourth Bureaucracy Relief Act cut the retention period for invoices and accounting vouchers from ten years to eight — in § 147 of the Fiscal Code and § 14b of the VAT Act. The shorter period applies to all invoices whose retention period had not expired by 31 December 2024.

RecordPeriod
Invoices and accounting vouchers8 years
Commercial books, inventories, annual accounts10 years
Records under § 22 of the VAT Act10 years
Accounting vouchers at credit institutions, insurers and securities firms10 years

The last row is new and easily missed: for the financial sector the reduction was reversed — by the act on modernising and digitalising the fight against undeclared work, passed by the Bundestag on 13 November 2025 and approved by the Bundesrat on 19 December 2025. Anyone working there still counts to ten.

Across the rest of the EU the range runs roughly from six to ten years depending on country and record type. What decides is where you are established, not where you invoice to.

What exactly has to be kept

Here is the mistake that happens most often and surfaces latest: what must be kept is the structured part, the XML — not a printout and not a nice PDF copy of it.

The reason is the same as everywhere in e-invoicing: the German finance ministry’s ruling of 15 October 2025 makes clear that in hybrid formats the structured part governs. What governs must also be what sits in the archive. Printing the invoice, scanning it and filing the result destroys the record without anyone noticing.

And this is where the hybrid format becomes an advantage: in a ZUGFeRD file the readable page and the XML sit in one document. There is no structured part that could be separated and lost, and no pair of files whose belonging together has to be guaranteed through file names — see PDF/A-3.

GoBD: what is actually required

The GoBD are the German tax administration’s principles for keeping and retaining books, records and documents in electronic form. For e-invoices they come down to four requirements.

Four requirements around the stored invoice: unalterable, machine-readable, findable and exportable, and described in process documentation
The fourth requirement is the one most often missing — and the only one that has nothing to do with technology.
  1. Unalterability. Nothing changes after filing. Corrections and deletions must be logged completely, and the original version must survive. A folder on a drive where anyone can overwrite files does not meet this.
  2. Machine readability. The original XML must be preserved in its original form and remain evaluable for the whole period — not merely displayable.
  3. Findability and data access. On request during an audit, documents must be locatable and exportable within a reasonable time. Access types Z1, Z2 and Z3 stand side by side; the auditor chooses.
  4. Process documentation. It must be written down how your archive works: how invoices get in, how they are named and filed, who may access them, how backups run. Understandable to a qualified third party — and itself retained across the period, in its versions.

Point 4 is the most common gap. The archive works, the files are in the right place, and yet the one document explaining how it works is missing. For a small business that is two pages — but they have to exist before anyone asks for them.

What an archive has to be able to do

  • The format stays readable without special software. PDF/A-3 is built for exactly that: embedded fonts, its own colour profile, no external dependencies.
  • The original gets filed, not a conversion of it. Any post-processing — stamping, merging, compressing — can destroy PDF/A conformance and strip the declaration of the XML attachment.
  • Protection against accidental change. Versioning, or storage that does not allow overwriting.
  • Backups separate from the live system. A backup sitting in the same directory is not one.
  • Incoming invoices too. The duty catches both sides: whoever receives an e-invoice keeps it exactly as they keep the ones they issue.

What this service stores — and what it does not

E-Rechnung Pro generates and validates documents. It is not an archive, and it does not try to be one. Files stay exactly as long as collecting them takes:

FileHow long it stays
generated PDF and XML files24 hours, then deleted from the server
PDF uploaded for conversion6 hours
file in the validation queue1 hour

The history entry remains: the document list still shows what was created and when, even once the file itself is gone. Download the files and put them in your own archive — the retention duty sits with the business that issued or received the invoice, not with the tool that built it.

Where the data sits while it sits

  • Transport is encrypted. Everything between your browser and the service runs over TLS.
  • Processing happens in Germany. The servers are at Hetzner in Falkenstein; documents do not leave the EU.
  • Files are reachable only from your own account, through a download route that checks ownership — never through a guessable direct link.
  • A public check leaves nothing behind. The file is used for the check only; no copy is kept.

The last point is the design decision behind all the others: where no long-term archive is kept, there is no store of data to protect.

Frequently asked questions

Is filing the invoice as a PDF enough?

Only if that PDF is the e-invoice itself, still carrying the embedded XML. A printed, scanned or newly generated PDF is not the same document — the structured part is missing from it.

Do I have to store the XML separately as well?

Not if you keep the hybrid file unchanged: the XML is inside it. Storing it separately does no harm but creates the obligation to keep the two parts together.

Eight years or ten — which applies to me?

Eight for invoices and accounting vouchers. Ten remain for commercial books, inventories, annual accounts, records under § 22 of the VAT Act and for accounting vouchers in the financial sector.

May I scan paper invoices and destroy the originals?

Substitutive scanning is permitted but requires a described and observed procedure — precisely the part that belongs in the process documentation. For e-invoices the question does not arise: there is no paper original.

How long do I keep incoming invoices?

Exactly as long as outgoing ones. The period attaches to the record, not to the direction.

What if my archive system no longer exists in ten years?

That is precisely why the format matters more than the system. A PDF/A-3 stays readable even when the software that filed it is long gone — that is the point of an archiving format.

Does E-Rechnung Pro store my invoices for me?

No, deliberately not. Generated files are deleted after 24 hours. You keep the archive.

In short

  • Eight years for invoices and accounting vouchers; ten for books, annual accounts, § 22 records and the financial sector.
  • What must be kept is the structured part — the XML, not a printout of it.
  • A hybrid file solves that by itself: page and data live in one document.
  • GoBD asks for four things: unalterability, machine readability, findability, process documentation.
  • The process documentation is missing most often — and it is the only point no software does for you.
  • This service is not an archive. What it generates is deleted after 24 hours; download it and file it yourself.

Want to check, before filing, that the file really is a valid PDF/A-3 with embedded XML? Upload it without signing up — the container layer answers exactly that question.