GoBD

The six core principles of the GoBD

The GoBD rest on six principles of proper bookkeeping that are made precise for electronic systems. Traceability and verifiability require that a knowledgeable third party – such as a tax auditor – can gain an overview of the business transactions and the company's situation within a reasonable time; every transaction must be traceable without gaps, from the document through the posting to the report (document function and progressive/retrograde verifiability).

Completeness means that all business transactions subject to recording are captured, without omission. Correctness demands that facts are reflected accurately in substance. Timely posting requires prompt capture – cash transactions generally daily, non-cash transactions within a reasonable period – so that no concealment is possible. Order means systematic, clear and unambiguous filing.

The most important principle for IT systems is immutability: once captured, data must not be changed in a way that makes the original content no longer identifiable. Corrections must be logged as such, so that both the old and the new state remain visible. This requirement is the heart of audit-proof storage.

Immutability and audit-proof storage

Audit-proof storage is the umbrella term for the technical and organisational implementation of immutability. A system is audit-proof when tax-relevant records can no longer be overwritten, deleted or manipulated unnoticed after they have been committed. Changes are only permitted as a traceable, logged correction posting – the original posting is retained.

In practice this is achieved through an immutable journal and a complete audit trail: every entry, change and cancellation is recorded with a timestamp, user ID and transaction reference. Plain text files, freely editable spreadsheets or a bookkeeping system without commitment generally do not meet this requirement, because contents can be altered without a trace. The path from an upstream system (e.g. inventory management or a POS) into financial accounting must likewise be immutable and traceable.

Documents, retention and retention periods

Every posting is based on a document – "no posting without a document". Electronic documents such as incoming invoices as PDFs or e-invoices must be retained in the format in which they were received; they must not be converted into a merely pictorial format and thereby lose their machine readability. If paper documents are scanned ("replacement scanning"), the digitisation must be documented and the process described in the process documentation.

The commercial and tax retention periods apply to storage. Accounting documents, books, inventories, annual financial statements and the associated process documentation must generally be retained for ten years; incoming and outgoing commercial or business letters and other documents of tax relevance for six years as a rule. Throughout the entire period the data must remain machine-analysable and be available to the tax office within the scope of data access (Z1/Z2/Z3). The specific period in an individual case should be agreed with the tax advisor.

Process documentation as a mandatory element

The process documentation 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 comprises a general description, a user documentation, a technical system documentation and an operational documentation, and makes the processes used traceable for third parties.

If a process documentation is missing or inadequate, the tax authorities may question the propriety of the bookkeeping. A formal defect does not automatically lead to the bookkeeping being rejected, but it can reduce its evidentiary value and – in the case of serious defects – trigger an estimated assessment. The documentation should be kept up to date, versioned and archived itself over the retention period.

What the GoBD mean for ERP systems

For ERP and accounting software, the GoBD translate into concrete functional requirements. Central to these are an immutable journal with commitment, a complete audit trail over all relevant transactions, audit-proof number ranges (such as sequential invoice numbers without gaps or duplicates) and a role-based authorisation concept that makes it traceable who changed what.

Export is equally important: the systems must be able to provide the data in the scope and format required by the tax office, classically via a DATEV interface or the standardised GDPdU/GoBD data export. Anyone assessing whether a specific solution meets these requirements looks for a commitment function, cancellation logic instead of deletion and documented archiving. Systems frequently cited as examples in the DACH region can be found under "Related systems"; actual GoBD compliance, however, always depends on the configuration, processes and process documentation in the individual company.

Relationship to DATEV and the tax advisor

In practice, ERP systems and tax advisors in Germany mostly work together via DATEV: postings, documents and master data are handed over from the ERP to the firm, which uses them to prepare financial accounting and the annual accounts. For this path to remain GoBD-compliant, the exported data must be handed over completely, immutably and with a document reference – ideally including digital documents (e.g. "Belege online").

The GoBD themselves do not establish any certification: there is no official "GoBD certification" of software that guarantees proper bookkeeping. Responsibility always remains with the company. This article gives a general overview and is not legal or tax advice; for a binding assessment of the individual case, a tax advisor or auditor should be consulted.