GoBD: what they require for retaining e-invoices

What this is about

The GoBD — the principles for the proper keeping and retention of books, records and documents in electronic form, and for data access — are an administrative instruction. They invent no new duties; they describe how the tax administration applies existing ones to electronic processes.

For e-invoicing four principles matter: traceability, unalterability, completeness and availability.

The sentence most often overlooked

What you retain is the original in its native format.

That sounds harmless and has concrete consequences:

🔴 What is not sufficient: a printout of the XRechnung, a PDF view generated from the XML, or — with ZUGFeRD — only the extracted XML without its PDF.

The second case is the insidious one, because it feels like progress: a program reads the XRechnung, renders a handsome PDF view, and that goes into the archive. For the human that is an improvement. For retention it is a derivative that does not replace the original.

The four principles, read practically

Traceability. A third party must be able to follow a document's path — from arrival to posting. That is why the process description exists.

Unalterability. A later change must not be possible unnoticed. The technical implementation is free: an archive system with logging satisfies it, a folder on a file server without further measures does not.

Completeness. All documents, without gaps. For e-invoices that also means the intake channel must be reliable. A personal mailbox somebody tidies up is a risk.

Availability. Legible and machine-analysable for the whole retention period. The second half is the more interesting one for e-invoices — it is the reason the structured original counts and not an image of it.

The process description

The term is off-putting; the thing is manageable. What is required is a description of your flow:

• How do invoices arrive? At which address, in which formats?
• What happens to them? Who checks, who approves, who books?
• Where do they end up? In which system, for how long, who has access?
• What happens on failure? Who notices that an invoice did not arrive?

💡 The document need not be long. It must be current and describe the flow as it is actually lived — a beautiful description of a procedure nobody follows is worse in an audit than a terse one that is accurate.

What e-invoicing makes easier

The GoBD apply regardless of format — they applied to paper and they apply to XML. With e-invoices, though, one step falls away that used to cause most of the friction: digitising the document.

A scanned sheet raises questions an XRechnung never does: is the scan complete? legible? may the paper be destroyed? With an e-invoice the original is digital and structured from the start.

🔵 That shifts the effort: less capture, more care in retention and traceability. On balance it is a good trade — but it is a trade, not a saving.

And the archive

Archiving is the part a generation or validation service does not do for you. Producing or validating an e-invoice says nothing about its retention.

The current state of our own archive API is on the roadmap; until then, audit-proof long-term retention stays your responsibility.