GoBD-Compliant
GoBD-compliant means that a system or process captures, processes and retains tax-relevant data in a way that meets the requirements of the GoBD – above all traceable, complete, accurate, timely, orderly and unalterable.
GoBD-compliant is a characteristic of software and processes: a system, a set of accounts or a single workflow is GoBD-compliant when it satisfies the "Principles for the proper keeping and retention of books, records and documents in electronic form and for data access" (GoBD). This covers the six core principles of traceability, completeness, accuracy, timely posting, order and – crucial for IT systems – the unalterability of data once it has been recorded.
The perspective matters: GoBD-compliant always refers to the overall system of software, organisation and people, not the program alone. Software can create the technical conditions (such as an unalterable journal), but the bookkeeping only becomes compliant through correct configuration, disciplined use and complete process documentation. That is why the frequently heard claim "this software is GoBD-certified" is, strictly speaking, misleading – there is no official GoBD certification.
At a glance
- A property of both the system AND the process – not the software alone
- Core ERP requirement: unalterability and a complete audit trail
- Process documentation is a mandatory part of compliance
- There is no official GoBD certification – only private attestations
- Responsibility always stays with the company, not the software vendor
What "GoBD-compliant" specifically requires
GoBD-compliant is a state, not a product. It is reached when a tax audit can trace every business transaction – from the document through the posting to the reporting – seamlessly and within a reasonable time. This translates into very concrete requirements for software and workflows.
First, unalterability: once records are committed, they may no longer be overwritten or deleted without trace; corrections are only permitted as a logged reversal or correction posting. Second, traceability via an audit trail that records every entry, change and reversal with a timestamp, user and transaction reference. Third, timely and complete capture of all transactions subject to recording – cash sales generally on a daily basis. Fourth, orderly, machine-readable retention throughout the full retention period, together with data access (Z1/Z2/Z3) for the tax office.
The myth of "GoBD-certified"
Neither the Federal Ministry of Finance nor the tax authorities issue a GoBD certificate or an official approval for software. An auditor can object to or accept a specific set of accounts in an individual case, but there is no general clearance "for the future". When vendors advertise with "GoBD-compliant" or "GoBD-certified", they usually mean that their software creates the technical conditions – not that every use is automatically compliant.
GoBD-compliant in the ERP system
In an ERP system, tax-relevant data arises not only in financial accounting but already in the upstream systems: in inventory management, order processing, invoicing or at the point of sale. An ERP is only GoBD-compliant when this entire data flow – from the upstream system through to the general ledger – remains unalterable and traceable. An invoice that can still be freely edited after it has been sent, or a stock level without a documented movement history, are typical weak points.
Technically, ERP systems implement this through record commitment, unalterable document numbers (sequential and gap-free), an audit-proof journal and a fine-grained roles-and-rights concept. Audit-proof archiving of incoming documents is just as important: e-invoices and PDF invoices must be retained in their original format and in machine-readable form, not merely as an image. When paper documents are digitised through "replacement scanning", the digitisation process must be documented.
What configuration and use contribute
Even a fundamentally suitable system can be operated in a way that breaches the GoBD – for example if record commitment is disabled, document number ranges have gaps, or users with admin rights change data after the fact. Compliance arises from correct settings, a clean authorisation concept and trained users. The export for the digital tax audit should be tested in advance so that the data can be handed over in full if an audit occurs.
Process documentation as an obligation
Without process documentation, a set of accounts is not fully GoBD-compliant. It describes how tax-relevant data is created, captured, processed, output and retained – from receipt of the document through processing in the ERP to archiving. It typically has four components: a general description, user documentation, technical system documentation and operational documentation.
If the documentation is missing or outdated, the tax authorities may question the propriety of the accounts. A formal defect does not automatically lead to the accounts being rejected, but it reduces their evidential value and, in the case of serious defects, can result in an estimated assessment. The process documentation should be versioned, kept up to date and itself archived over the retention period.
Distinction: GoBD-compliant, GoBD and audit-proof
The three terms are often mixed up. The GoBD are the administrative directive itself – the BMF rulebook. GoBD-compliant is the property of a system or process of satisfying that rulebook. Audit-proofness, in turn, describes only one – albeit central – aspect: the technical and organisational implementation of the unalterability of records.
A system can therefore archive in an audit-proof manner and still not be fully GoBD-compliant if, for instance, the process documentation is missing or documents are not captured in a timely fashion. Conversely, audit-proofness is a necessary precondition for compliance. The e-invoice should also be distinguished: its obligation follows from VAT law, but its audit-proof retention in the original format is in turn a GoBD requirement.
Private attestations instead of official approval
Instead of an official approval, there are voluntary audits by public accountants, for example under the IDW PS 880 standard (software attestation). Such an attestation confirms that the software supports the GoBD requirements when used properly. It is an indicator of quality, but it replaces neither the company's own process documentation nor its responsibility for compliant operation.
Why GoBD compliance matters
GoBD compliance is not an end in itself; it protects against tangible risks. If a tax audit finds serious defects, it can reject the accounts and estimate the tax base (estimated assessment) – usually to the company's disadvantage. Added to this are possible tax-criminal consequences and back payments. Especially in retail and e-commerce, with high document volumes and many automated processes, formal errors add up quickly.
Conversely, a consistently compliant workflow brings security in the event of an audit, cleaner data and less manual effort. Anyone who factors compliance into ERP selection and implementation from the outset avoids costly rework. The specific assessment in an individual case, however, always belongs in the hands of a tax adviser or public accountant.
Example
In practice: an online retailer in a tax audit
A mid-sized online retailer sells through a shop and marketplaces and handles orders in an ERP system. Invoices are generated there automatically, passed to financial accounting via an interface and exported to DATEV. When the tax office announces a digital audit, the auditor requests data access to the journal, documents and master-data changes.
Because the ERP keeps committed documents unalterable, logs every change and has current process documentation in place, the tax adviser can provide the data in full and in an orderly form. It would have become critical if invoices had still been editable after the fact or if the document numbers had shown gaps – the auditor could then have questioned the propriety of the accounts and resorted to an estimate.
Frequently asked questions
Matching ERP systems
Related services
Sources
Questions about GoBD-Compliant in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.