GoBD-Compliant With Your ERP: The Checklist

Straight up: an ERP system does not automatically make you GoBD-compliant – but without the right system it becomes almost impossible. The GoBD (the German principles for the proper keeping and retention of books, records and documents in electronic form, and for data access) require that all tax-relevant data in your ERP is retained in a way that is immutable, traceable, complete and machine-analysable. What matters is not only the software, but also how you use and document it. This checklist shows you what counts during a tax audit and which functions your system needs to bring to the table.

What the GoBD demand from your ERP

The GoBD are not a law but a decree from the German Federal Ministry of Finance (BMF) that puts the requirements of the Commercial Code (HGB) and the Fiscal Code (AO) into concrete terms for digital bookkeeping. They apply to every company that captures tax-relevant data electronically – in practice, to every ERP user. The core boils down to a few principles:

• Traceability and verifiability: an expert third party must be able to follow every business transaction seamlessly, from the source document to the posting (and back).
• Completeness, accuracy, timely posting and order: no gaps, no double entries, prompt recording.
• Immutability: once a posting or document has been captured, it must not be altered or deleted without an audit trail.

You have to meet these principles technically and organisationally. That is exactly why buying a "GoBD-compliant" system is not enough – you also have to operate it compliantly and prove it.

Immutability: the toughest audit point

One of the most common causes of objections during tax audits is a lack of immutability. A posting that can be changed retroactively without a trace devalues the entire bookkeeping – and in the worst case the tax office resorts to an estimate.

What that means technically

Your ERP has to ensure that finalised postings can no longer be overwritten. Corrections are made exclusively via reversal postings or supplementary documents that preserve the original transaction. This also applies to documents in the sub-ledger, invoices, delivery notes and point-of-sale data. A simple Excel journal that anyone can overwrite does not meet this requirement.

Audit trail and change history

Every change must be logged: who changed what, and when? A seamless audit trail is the technical answer. It documents all relevant actions with a timestamp and user, making it verifiable that no one tampered with the data after the fact. This is complemented by a clean roles and permissions concept that governs who is even allowed to post, reverse or change master data.

Audit-proof storage and retention

Audit-proof storage means more than "cannot be overwritten". It covers tamper-proof, complete and permanently legible storage across the entire statutory period.

Retention periods – watch out for the new rules

The retention obligation differs by document type. Important: the Fourth Bureaucracy Relief Act (BEG IV) shortened the period for accounting vouchers.

The shortened 8-year period for accounting vouchers applies to documents whose regular 10-year period had not yet expired on 31 December 2024. When in doubt: the longer period beats the shorter one, and your tax advisor classifies the individual case.

Format and legibility

Documents received electronically – such as an e-invoice in the EN 16931 format – must be kept in their original format. A printout does not replace the structured original. Your system should keep the document machine-analysable and reproducible across the entire period. A regular, tested backup is mandatory here, not a nice-to-have.

Data access Z1, Z2, Z3 during the audit

During a field audit, the tax office has three access modes under Section 147 AO – the old GDPdU logic lives on in the GoBD. Your ERP must be able to serve all three:

• Z1 – direct access: the auditor works directly (read-only) in the system, using reports and filters. For this you need an auditor user account with read-only rights.
• Z2 – indirect access: your staff run analyses in the system according to the auditor's instructions and present the results.
• Z3 – handover on a data medium: you export the tax-relevant data in an analysable format for handover.

For Z3, GDPdU data access via a standardised export (classically the GDPdU/IDEA format with a description file) is decisive. Before buying, check whether your system can produce such an export – without it the audit becomes tedious for both sides. This also applies when switching systems: tax-relevant data from the legacy system must remain accessible in an analysable form, not just as a PDF printout – a point you should plan for in every data migration.

Procedural documentation: the part almost everyone forgets

The best software is useless if you do not document how you use it. The procedural documentation is explicitly a GoBD obligation – and the point where most SMEs fail. It describes, in a traceable way, how tax-relevant data is created, captured, processed, retained and made retrievable again.

A usable procedural documentation typically contains four building blocks:

• General description: an overview of the company, the systems in use and the data flows.
• User documentation: how employees actually operate the ERP (capturing documents, approvals, reversals).
• Technical system documentation: architecture, interfaces, data formats, permissions.
• Operating documentation: data backup, access protection, change management, contingency plan.

Versioning matters too: if a process changes, the documentation has to grow with it in a traceable way. The auditor wants to see which version applied when.

Checklist for the tax audit

You should tick these points off before the auditor arrives – ideally as early as the ERP selection:

• Finalised postings are technically immutable; corrections only via reversal/supplementary document.
• A seamless audit trail with user and timestamp is active and analysable.
• The roles and permissions concept is documented and actually implemented.
• Documents are stored audit-proof in their original format (including structured e-invoices).
• Retention periods (8/10/6 years) are correctly configured in the system.
• A Z1 auditor account with read rights can be set up; the Z3 export (GDPdU/IDEA) works and has been tested.
• The procedural documentation is complete, current and versioned.
• A regular, tested backup including proof of recovery is in place.
• For cash transactions: KassenSichV/TSE requirements met and point-of-sale data immutable.
• For a DATEV connection: export formats and document handover checked.

Anyone who works through this list heads into the audit far more relaxed. When implementing it in a project, a structured ERP consultancy that factors in compliance requirements from the outset helps – rather than retrofitting them expensively later.

Conclusion

"GoBD ERP" is not a software feature you buy off the shelf, but the interplay of the right system, clean operation and seamless documentation. When selecting a system, look specifically for immutability, an audit trail, audit-proof storage and a working Z3 export – and invest the time in a proper procedural documentation. Which systems cover these requirements is something you can research in the ERP directory and via the comparison. When in doubt on any detailed tax question, the rule holds: coordinate with your tax advisor before the audit comes.