Laden...
Sales & Revenue
Projects & Team
AI & Communication
Automation & Integrations
Projects & Work
Finance & Invoicing
ERP Alternatives
Scheduling
Laden...
GoBD compliance is not a property software brings with it — it emerges from how program, process and documentation work together. Here is what is required, which retention periods apply and where it usually breaks down in practice.
GoBD stands for the German "Principles for the proper management and retention of books, records and documents in electronic form and for data access". It is not a statute but a Ministry of Finance circular setting out how the tax authorities interpret the bookkeeping duties in the Fiscal Code and Commercial Code. Six requirements are at its core: traceability, completeness, accuracy, timely recording, order and immutability. Accounting documents must be retained for eight years, books and annual financial statements for ten. There is no official GoBD certification for software.
The GoBD are a circular from the German Federal Ministry of Finance, not a law of their own. The authoritative version is dated 28 November 2019, amended by the ministry letters of 11 March 2024 and 14 July 2025. They describe how the tax authorities interpret the existing duties under the Fiscal Code and the Commercial Code once bookkeeping and documents are created or stored electronically. In practice that touches nearly every business — including cash-basis filers and small businesses, as soon as they issue or receive invoices digitally. One point is regularly missed: GoBD compliance is not a product feature. It only arises from the interplay of software, the process you actually follow, and procedural documentation describing how documents are created, checked, posted and archived in your business.
This is where audits most often stumble — and the part no software can deliver on its own. What is required is a traceable description of a document’s entire path: how it enters the business, who checks and approves it, how it is posted and where it is archived, which systems are involved and how changes are logged. Access rights and data backup belong in it too. Without this documentation the bookkeeping can be challenged on formal grounds, even when everything is substantively correct.
Six principles every electronic bookkeeping system is measured against:
A knowledgeable third party must be able to review the bookkeeping within a reasonable time. Every document must be traceable to its entry and back again — the document function.
Every transaction must be recorded individually and without gaps, factually correct and with all mandatory details. No batch entries without individual evidence.
Cash transactions must be recorded daily, non-cash ones promptly — as a rule within ten days. Documents must be filed systematically and be findable.
Once posted, a record may not be changed without a trace. Corrections are permitted but must remain identifiable as such, and the original content must stay determinable.
Under § 147 (6) of the Fiscal Code the tax authorities have three access routes: direct access to your system (Z1), indirect access through reports you produce (Z2), and handover of data on a medium in a machine-readable format (Z3). Z3 is the usual choice in practice. What then gets examined is typically the completeness of invoice number ranges, whether entries were altered after the fact, whether change logs exist, whether electronically received documents are held in their original format — and whether procedural documentation exists. One rule matters: a document received electronically must also be retained electronically. Printing it and deleting the file is a breach.
The Fourth Bureaucracy Relief Act shortened this from ten to eight years as of 1 January 2025 (§ 147 (3) Fiscal Code, § 257 (4) Commercial Code). It applies to all documents whose period was still running at that date. For banks and insurers the reduction takes effect from 2026.
Commercial books, inventories, opening balance sheets, annual financial statements, management reports and the working instructions needed to understand them stay at ten years.
Received commercial and business letters, and copies of those sent, must be kept for six years — including when they exist as email.
Every period starts at the end of the calendar year in which the document was created or the last entry was made. An invoice from March 2026 therefore starts running on 31 December 2026.
The part software can cover — process and procedural documentation stay with you.
Approved invoices cannot be silently overwritten. Corrections run as a traceable operation with timestamp and author, and the original state remains determinable.
Invoice numbers are issued consecutively and without gaps — one of the first things an audit notices.
Documents and posting data export in machine-readable form, for your tax advisor as well as for a Z3 data handover.
It means your electronic bookkeeping meets the six principles of the ministry circular: traceability, completeness, accuracy, timely recording, order and immutability — evidenced by procedural documentation. The term describes a state of your entire workflow, not a feature of a single program.
"Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff" — principles for the proper management and retention of books, records and documents in electronic form and for data access. It replaced the earlier GDPdU and GoBS rules in 2015.
No. The GoBD are a Federal Ministry of Finance circular and formally bind only the tax administration. They interpret how existing duties under the Fiscal Code and Commercial Code apply to electronic bookkeeping. In practice they act like binding rules, because every tax audit is conducted against them.
No. The circular states explicitly that the tax authorities issue no approvals or certificates for bookkeeping software — neither for programs nor for individual functions. Where a vendor advertises being "GoBD-certified", that attestation comes from a private auditor. It can be useful, but it replaces neither your procedural documentation nor a case-by-case assessment.
Not on its own. A spreadsheet can be changed at any time without a trace and therefore fails the immutability requirement — nothing logs which cell was changed, when or by whom. As a tool for side calculations Excel is unproblematic; as the leading system for entries and documents it is vulnerable in an audit.
These programs are built so that you can work in a GoBD-compliant way with them — they log changes, issue consecutive numbers and archive in an audit-proof manner. The same holds for cashwerk. But it is your operation that becomes compliant, not the product: without sound processes and procedural documentation the best software achieves nothing. The tax authorities issue no official confirmation that any given program is "GoBD-compliant".
A PDF can be part of a GoBD-compliant archive but is not enough on its own. What matters is that it is retained unchanged in its original format, systematically findable and linked to the posting. A PDF sitting in a mailbox where it can be deleted or overwritten does not meet the requirements.
Plain cloud storage is not sufficient. Immutability is missing: files can be replaced, renamed or deleted without producing an auditable log. Linking to the posting, searchability and procedural documentation are missing too. Archiving needs a system with audit-proof storage — or an audit-proof archive alongside the drive.
Storage in which documents remain immutable, complete, systematically ordered, findable at any time and machine-readable throughout the retention period. Documents received electronically must be preserved in their original format — an e-invoice in XML therefore as XML, not as a printout or a converted PDF.
Accounting documents and invoices for eight years — the Fourth Bureaucracy Relief Act shortened this from ten as of 1 January 2025. Books, inventories, opening balance sheets and annual accounts stay at ten years, received commercial and business letters at six. Every period starts at the end of the calendar year in which the document arose.
Anything relevant for taxation that arises or arrives electronically: incoming and outgoing invoices, bank statements, contracts, till data, delivery notes with a document function, and business emails where they carry such a function. An email that merely transports an invoice is treated like an envelope — it is the attachment that must be retained.
Not by overwriting it. A posted or sent invoice is not edited but replaced by a cancellation or corrected invoice referring to the original. Both documents are kept. If the original content is silently overwritten, immutability is breached and the bookkeeping becomes formally challengeable.
Yes in principle — but its scope may match your business. For a sole trader with a handful of documents a month, a few pages describing how invoices arise, where they are filed and who has access are usually enough. What matters is that a third party can follow the path of a document.
Formal defects can lead the tax authorities to reject the bookkeeping as not properly kept. The practical consequence is an estimate of the tax base under § 162 of the Fiscal Code — which as a rule does not go in your favour. Missing procedural documentation alone rarely triggers rejection, but combined with other defects it certainly can.
They apply in parallel and do not replace one another. The e-invoicing mandate governs the format in which invoices are exchanged between businesses. The GoBD govern how those invoices must be recorded and retained. An XRechnung therefore has to be archived unchanged as a structured file in its original form — details are on our e-invoicing page.
This page reflects the position as of August 2026 and does not constitute legal or tax advice. Whether your business meets the GoBD depends on the individual case — discuss it with your tax advisor.
In cashwerk approved invoices stay immutable, number ranges stay gap-free and changes stay traceable — exportable for your tax advisor and for a tax audit.
See invoicing