GoBD sounds like bureaucracy — but at its core is simple
GoBD stands for the “principles for the proper keeping and retention of books, records and documents in electronic form and for data access”. A monster of a word, set out in the Federal Ministry of Finance letter of 28 November 2019.
Behind it is a simple idea: whoever posts digitally should keep their documents so that an auditor can trace years later what happened — complete, unchanged, legible. At its core that is all. The complexity only arises when you try to do that with a mailbox and a folder on the server.
The five basic requirements at a glance
You can boil the GoBD down to five load-bearing pillars. Completeness: no document is missing, nothing is left out. Unalterability: what is filed cannot be changed unnoticed. Traceability: every step is seamlessly recognizable for an expert third party. Machine evaluability: structured data stay structured and evaluable. And retention over the legal period, without a gap.
Sounds abstract? It gets concrete in a moment. Exactly at these five points it is decided whether an e-invoice filing holds or not.
Unalterability: where folder filing fails
Most violations happen not from malice but from convenience. An XRechnung lands in the “Intake 2026” folder. Someone renames it. Someone moves it. Someone overwrites it accidentally.
Exactly that the GoBD forbid. A document must be protected against change after intake — or every change must be seamlessly logged. A normal file system or mailbox does not do that. Both can be changed and nobody notices. That is why “we save it on the server” is not GoBD-compliant archiving, even if it feels like it.
Traceability and the audit trail
An auditor does not just want to see the invoice. They want to see what happened to it: when did it arrive? Who checked it? Who approved it? When was it handed to accounting?
This seamless trail is called the audit trail. It is not technical luxury but part of traceability. If you can only shrug at the question “who approved this invoice?”, a piece of orderliness is missing — even if the invoice itself is perfectly correct.
Machine evaluability: why the XML must stay
This is the point that makes e-invoices especially delicate. The GoBD require that machine-evaluable data also stay machine-evaluable.
Concretely: if you receive an XRechnung, you may not simply generate a PDF from it and throw the XML away. With that you would have turned evaluable data into a picture — exactly what the GoBD forbid. The structured original must remain, retrievable and evaluable, over the whole retention period. An additional readable view? Gladly. Instead of the original? No.
Procedural documentation — the forgotten mandatory document
Almost no one has it, almost every auditor asks for it: the procedural documentation. It describes how your process works — how invoices arrive, are checked, approved, archived and deleted.
The point behind it: a third party should understand the process without you sitting next to them explaining. It does not have to be a novel. But it has to exist, be current and match the lived practice. A documentation claiming something other than what actually happens is worse than none.
GoBD check in ten minutes
You do not have to commission an expert opinion for a first assessment. Honestly go through these points:
- Is the structured original (XML) present for every received e-invoice — not just a PDF?
- Is the filing secured so no one can change or delete a file unnoticed?
- Can you say for every invoice when it arrived, who checked and approved it?
- Do the data stay retrievable and evaluable over eight (partly ten) years?
- Is there a current procedural documentation matching the actual practice?