Archiving E-Invoices in Germany: Why the XML Is the Record
How to archive a German e-invoice: keep the structured XML unchanged and machine-readable for 8 years, and why a stored PDF alone may not be enough.
A German e-invoice has to be kept for eight years, in its original structured form, unaltered and machine-readable. The XML data is the invoice, so a stored PDF image of it is not enough on its own. Where the invoice arrived as a ZUGFeRD file, the XML is inside the PDF. Keep that file as it came. Where it arrived as XRechnung, the XML is the whole invoice, and the readable version is only a rendering of it.
This page is for the accountant or finance lead who wants to know what to keep, and for how long. It does not help you choose archive software. The rules come from the VAT act and from the Federal Ministry of Finance (BMF) letter of 15 October 2025, which is guidance rather than law, as the professional bodies summarise it. It is not tax advice. GoRoute is a certified Peppol Access Point and SMP (POP000991). For German sellers it sends EN 16931 invoices, including XRechnung, over Peppol, and a ZUGFeRD PDF where the buyer is not on the network.
How long must a German e-invoice be kept?
Eight years. That is the period in section 14b(1) of the VAT act (Umsatzsteuergesetz, UStG), which the BStBK and Haufe both give. It applies to the issuer and to the recipient, since both have to keep the invoice.
We have not listed other periods for books and business letters here. Those come from other laws, and which one applies to a given document is a question for your adviser.
Why is the XML the record?
Because under section 14(1) UStG an e-invoice is one issued, sent and received in a structured electronic format. The data in that format is the invoice. The summaries of the 2025 letter say all details the VAT act requires must be in the structured part, and that attachments outside the XML, or links to external pages, do not make up for details that are missing from it.
For the archive, that has a plain consequence. If you keep only a PDF print of an XRechnung, you have kept a picture of the invoice, not the invoice. For the tax authority the original structured data is what counts.
Which format are you keeping?
| Format | What the invoice is | What to keep |
|---|---|---|
| XRechnung | An XML file | The XML file, unaltered |
| ZUGFeRD or Factur-X | A PDF/A-3 with the XML embedded | The whole file, unaltered, with the XML inside |
| PDF, Word, scan | An "other invoice", not an e-invoice | The file, as before. If an e-invoice was required, see the errors page below |
A pure PDF can still be a valid invoice in the transition years. It is not an e-invoice, and different questions apply to it.
What does "unaltered and machine-readable" mean?
The structured part must be stored in its original form, and the tax authority must be able to read it by machine. Both come from the summaries of the letter by Haufe and the BStBK, and both are about the result, not the product.
- Unaltered. Do not edit, convert or re-save the XML in place. If you extract data into your accounting system, that copy is yours. The original stays as received.
- Machine-readable. A readable view of the data is useful for people, but it is not the same thing. Keep the XML so that the authority can process it.
- Complete and findable. The invoice needs to be retrievable for the whole period. That also means keeping the format version it was written in, and a way to open it later.
Where can the archive be stored?
In Germany, or in another EU member state with full access for the tax authority. Section 146(2a) of the tax code (Abgabenordnung, AO) allows electronic books and records to be kept in another EU member state without an application, provided full data access is possible. Section 146(2b) AO requires an application and approval for storage outside the EU, and section 146(2c) AO sets a delay fine of EUR 2,500 to EUR 250,000 for unapproved relocation or denied access.
In practice, check where your cloud archive actually runs before you rely on it.
What if the PDF and the XML disagree?
The XML leads. Haufe and the BStBK both report that in a hybrid invoice the structured data takes precedence over the image part, and that a divergent image part can count as a second invoice with its own consequences. Sending the same invoice twice with identical content is harmless.
What to do is our reading, not the letter's. First, treat the XML as the invoice and find out which version is right. Second, keep both versions in the archive, since both were sent. Third, if the data was wrong, correct it as the summaries describe: the correction of a wrongly formatted invoice must itself be an e-invoice that refers to the original. Credit notes and self-billing under German e-invoicing covers how.
What about received invoices?
The same rule holds, and it started earlier. Since 1 January 2025 every business must be able to receive and archive e-invoices, including a Kleinunternehmer and a business making only exempt supplies. No consent is needed. An ordinary email inbox suffices to receive one, according to Haufe's summary. Whether it is a good place to keep it for eight years is a separate question.
If you receive an XRechnung and your system shows only the readable version, make sure the XML is stored somewhere too. This is often the gap. The PDF gets filed, and the XML stays in the mail client.
What to do next
- Find the XML. For each e-invoice you issue and receive, check that the original file is kept.
- Check where the archive is hosted, and whether the tax authority could have full access to it.
- Do not convert in place. Keep originals separate from any readable or exported copies.
- Check which invoices are in scope before you plan the archive. See which German invoices need not be e-invoices in 2027.
- Check invoices before they are sent. A document that fails the standard is a different problem, covered in German e-invoices with errors.
- To talk about sending German e-invoices over Peppol, book a demo. If you sell through a shop, see WooCommerce e-invoicing in Germany or Wix e-invoicing. The Germany page, the tutorials and the developer documentation cover the rest.
Related reading
- E-invoicing in Germany, the country page.
- Germany B2B e-invoicing 2025 to 2028: XRechnung and ZUGFeRD
- Does your German online shop have to send e-invoices?
- What is a UBL invoice?
Sources, read in October and November 2026: Umsatzsteuergesetz, section 14 and section 14b; Abgabenordnung, section 146; Bundessteuerberaterkammer, FAQ E-Rechnung (3 March 2026); Haufe, weiteres BMF-Schreiben zur E-Rechnung and BMF-Schreiben vom 15.10.2025. The Federal Ministry of Finance letters were not available to us directly; where this page describes them it relies on these summaries. Translations from the German are ours.
Primary source: Federal Ministry of Finance (BMF) and the VAT act, section 14b, which set Germany's e-invoicing rules.
Frequently asked questions
- How long must a German e-invoice be kept?
- Eight years. Section 14b(1) of the VAT act (UStG) sets the period, as the BStBK and Haufe summaries of the ministry's letter state it. The Federal Ministry of Finance's letter of 15 October 2025 is guidance on how to apply it.
- Is it enough to archive the PDF of a ZUGFeRD invoice?
- Not on its own. The summaries of the ministry's 2025 letter say the structured data must be kept unchanged, in its original form and machine-readable for the tax authority. In a ZUGFeRD file the XML is inside the PDF/A-3, so archiving the whole file keeps it. A flattened printout does not.
- Can I convert the XML to another format and keep that?
- The summaries say the structured part must be kept in its original form. Keep the original and, if you want a readable copy, keep that as well. Do not replace the original with a converted one.
- Where can the archive be stored?
- In Germany, or in another EU member state if the tax authority has full access to the data. Storage outside the EU needs the tax authority's approval under section 146(2b) of the tax code (AO).
- What if the PDF and the XML of a hybrid invoice differ?
- The summaries say the XML takes precedence and that a differing image part can count as a second invoice with its own consequences. Keep both, find out which is right, and correct with an e-invoice that refers to the original.
- Does the invoice have to be stored in an e-invoice system?
- No specific software is named. The requirement is on the result: complete, unaltered, readable and available for the retention period. An ordinary inbox is enough to receive an e-invoice, but it is rarely a good archive.
About Dr. Syed Raza
Dr. Syed Raza is an IT Enterprise Architect at ClayDesk LLC and leads the GoRoute platform. He works across Peppol Access Point and SMP infrastructure, PINT jurisdictions (Oman, AU/NZ, EU, JP, MY, SG), and national CTC regimes, translating regulatory detail into production-grade e-invoicing systems.
Building on Peppol?
GoRoute is a certified Peppol Access Point & SMP. Book a demo or read the docs to get started.