Archiving E-Invoices Correctly: What Self-Employed People in Germany Need to Know in 2026

A few weeks ago an invoice landed in my inbox. A service provider had created it with SevDesk and attached it as a PDF. It looked like any other invoice: logo, line items, total. But it was not an ordinary PDF. It was an e-invoice in the ZUGFeRD format, with an invisible XML data record inside. And that raises a question many self-employed people in Germany have never consciously asked themselves: where do I put this file so that it still counts as an e-invoice in three years, when a tax audit comes around?

The short answer: in a place that keeps the file exactly as it arrived, bit for bit. The long answer, why that matters so much and how easily you can break it without noticing, is this article.

What an e-invoice actually is

Since January 1, 2025, every business in Germany has been required to be able to receive e-invoices, including freelancers and small businesses. An e-invoice is not simply "an invoice as a PDF". The law means an invoice in a structured electronic format following the European standard EN 16931: machine-readable data that accounting software can process without anyone retyping it.

In practice you will encounter two formats. XRechnung is pure XML, a data file with no visual layout, common mainly with public-sector clients. ZUGFeRD is the hybrid: a perfectly normal, viewable PDF with an XML file embedded inside it, usually named zugferd-invoice.xml. You see the PDF; your tax advisor's software reads the XML. This is exactly the format that tools like SevDesk or Lexware send by default.

The important part: in a ZUGFeRD invoice, the structured XML is the actual invoice content. The visible PDF is just the human-friendly view on top.

The mistake that turns an e-invoice into an ordinary PDF

The embedded XML is invisible. You can open, read, forward, and file a ZUGFeRD invoice without ever noticing it exists. And just as unnoticed, you can destroy it.

If you print the invoice and file the paper, the XML is gone; paper cannot embed data. If you open the PDF and re-save it via "Print to PDF" or an export function, your software creates a new file and usually discards the embedded attachments silently. And if you upload the invoice to a tool that re-renders, compresses, or stamps documents on import, the same thing happens: the file looks identical on screen, but its e-invoice character is lost.

The treacherous part: you cannot tell by looking at the file. Whether the XML is still inside is only visible if you actively look for it, for example in the attachments panel of your PDF reader.

What GoBD requires for storage

The GoBD, Germany's administrative principles for keeping tax-relevant records in digital form, turn this into a concrete compliance issue. They require you to keep an electronically received invoice in the format in which it arrived: unchanged, complete, findable, and readable for the entire retention period. For invoices that period has been eight years since 2025.

For e-invoices this means: the original is the file with the XML. A printout is not a substitute, and neither is a re-saved PDF without the XML. If all you can present in an audit is the broken version, you have not kept your original. The email itself, by the way, usually does not need to be kept if it was just the envelope; the document is the attachment.

How GoBD-compliant archiving works in general, including for scanned paper receipts, is covered in a separate article. For e-invoices, one requirement applies in its strictest form: not a single byte of the file may change. Keeping e-invoices means freezing the original, not maintaining a nice-looking copy.

The test: forward, download, compare

Paperarchive is built for exactly the path this invoice would take: forward the email, forget about it, find it again when needed. So I wanted to know for certain: does a real ZUGFeRD invoice survive this path untouched?

The test is simple and anyone can reproduce it. I forwarded the SevDesk invoice from my inbox to my Paperarchive address, downloaded the archived document again, and compared both files with SHA-256. SHA-256 is a cryptographic checksum: if even a single bit of the file changes, the checksum changes completely. An identical checksum therefore means an identical file, with no exceptions.

The result: both checksums were identical. The downloaded file was bit for bit the same as the original from the email. The embedded zugferd-invoice.xml was fully intact, structured according to EN 16931 and conforming to the XRechnung 3.0 profile. That is not a marketing claim; it is a test you can repeat with any invoice of your own. On macOS and Linux you compare with the command shasum -a 256, on Windows with certutil -hashfile.

The reason for the result is unspectacular: Paperarchive stores the original file unchanged and runs text recognition and categorization on a copy. In the interest of honesty: Paperarchive does not currently read the structured data out of the XML. Amount, sender, and date are recognized from the visible PDF. For archiving purposes that makes no difference, since the original stays fully intact. Actively evaluating the XML is an obvious next step.

Conclusion: one fixed path for every incoming invoice

Archiving e-invoices is not a question of the right folder structure. It comes down to a single rule: the received file stays untouched. Concretely, that means:

• Forward incoming invoices straight from your inbox into your archive instead of printing, converting, or re-saving them.
• Check once whether your filing tool keeps files unchanged. The hash comparison above takes two minutes.
• Treat the PDF with its XML as what it is: the original, which has to survive eight years unchanged.

If you do not have a fixed place for this yet, you can try Paperarchive for free; you get your own email address for forwarding right when you start. And if you do not want to take my word for it that your invoice stays unchanged: measure it. That is exactly why I described the test.