ED05 - GoBD Basics: Traceability, Verifiability, Immutability
Problem
An entrepreneur starts keeping books - and faces the question: What does GoBD specifically require, and how do I comply without expensive specialized software?
Current practice in the SME sector:
- GoBD as a book with seven seals - the GoBD (BMF letter, 146 pages) are abstract, legally worded, and hardly accessible to laypeople
- "The tax advisor does that" - many entrepreneurs delegate GoBD to the tax advisor (StB) without understanding themselves what is required - and pay for it
- Isolated solutions - payroll software, bookkeeping, and document archive each separate, without end-to-end GoBD compliance
- PDF as "electronic" - many believe a PDF on a hard drive satisfies GoBD - but GoBD requires machine evaluability (§ 147 Abs. 6 AO), not just storage
- No procedural documentation - GoBD Rz. 64–91 requires procedural documentation, but who in an SME has one?
- Subsequent changes - postings are "corrected" without the change being traceable - GoBD Rz. 146 requires immutability
Core Statement
GoBD requires three core principles that Git fulfills by design:
- Traceability (GoBD Rz. 146) - every entry must be traceable (Who? When? What? Why?)
- Verifiability (GoBD Rz. 147) - the bookkeeping must be verifiable (retrograde/progressive traceability)
- Immutability (GoBD Rz. 146) - after posting, data must not be changed (corrections as new entries)
Git fulfills all three structurally - not through subsequent controls, but through the architecture itself:
Rz. 146"] G --> P["Nachprüfbarkeit
Rz. 147"] G --> U["Unveränderbarkeit
Rz. 146"] N --> GN["Git: Commit-Autor
+ Zeitstempel
+ Commit-Message"] P --> GP["Git: V7GUID + SHA-256
retrograd/progressiv
auflösbar"] U --> GU["Git: Tags + Protected Branches
+ Obsoleszenz-Markierung
Korrekturen als neue Commits"] style G fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style N fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style P fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style U fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GN fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GP fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GU fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
Compliance by Design: GoBD compliance does not arise through subsequent auditing, but through the choice of medium. Those who work in Git repos fulfill traceability, verifiability, and immutability structurally - not through additional controls.
GoBD - Origin and Applicability
The GoBD (Principles for the proper keeping and retention of books, records, and documents in electronic form as well as for data access) are a BMF letter dated 28.11.2019 (BStBl I S. 1269), last amended on 14.07.2025 (BStBl I S. 1502).
| Property | Value |
|---|---|
| Publisher | Federal Ministry of Finance (BMF) |
| Legal character | Administrative instruction (not a law, but binding for tax offices) |
| Basis | § 146 AO (regulatory rules), § 147 AO (retention), HGB (§§ 238–241) |
| Applicability | For all entrepreneurs who keep books electronically (practically: all) |
| Scope | 146 marginal numbers (Rz.) |
Important: GoBD are not a "recommendation" - they are the administrative instruction according to which tax offices audit. Anyone who does not comply with GoBD risks estimation (§ 162 AO), late-payment surcharges (§ 152 AO) and in the worst case criminal tax proceedings (§ 370 AO).
The Three Core GoBD Principles in Detail
1. Traceability (GoBD Rz. 146)
GoBD Rz. 146: "The bookkeeping must be designed so that an expert third party can gain an overview of the business transactions and the situation of the company in a reasonable time."
This means: an auditor (or tax advisor, or tax official) must be able to trace in a reasonable time what happened.
| GoBD Requirement | How Git Fulfills It |
|---|---|
| Who posted? | git log --author shows every commit author |
| When was it posted? | uuidV7 contains a 48-bit timestamp (RFC 9562 §5.7) |
| What was posted? | Commit diff shows exactly what was added/changed |
| Why was it posted? | Commit message documents the reason |
| In what role? | role field in the JSON artifact (GF, accountant, R&D lead) |
Wer? Wann? Was?"] P --> SH["git show
Commit-Details"] P --> DF["git diff
Was hat sich geändert?"] P --> V7["uuidV7 decode
Exakte Erfassungszeit"] GL --> R["Nachvollziehbarkeit
in angemessener Zeit"] SH --> R DF --> R V7 --> R style P fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SH fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style DF fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style V7 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
2. Verifiability (GoBD Rz. 147)
GoBD Rz. 147: "The bookkeeping must be designed so that it is verifiable."
This means: the bookkeeping must be traceable both retrograde and progressive (see ED03):
- Retrograde: from posting record → voucher → journal entry → V7GUID
- Progressive: from voucher → posting record → Grundbuch → opening balance sheet
| GoBD Requirement | How Git Fulfills It |
|---|---|
| Retrograde traceability | source_sha256 in the journal entry → voucher |
| Progressive traceability | V7GUID in the voucher → journal entry → Grundbuch |
| Machine evaluability (§ 147 Abs. 6 AO) | JSON schema first - structured data, no PDF |
| Completeness | Pre-commit hook checks that every Grundbuch entry has source_sha256 |
3. Immutability (GoBD Rz. 146)
GoBD Rz. 146: "Entries must not be changed in a way that makes the original content no longer ascertainable."
This means: after posting, data must not be changed. Corrections must be made as new entries with a reason.
| GoBD Requirement | How Git Fulfills It |
|---|---|
| No subsequent change | Git commits are immutable (SHA-256 hash) |
| Corrections as new entries | New commits with obsolescence: superseded_by |
| Traceable correction | git log shows original + correction + reason |
| Protected branches | main branch protected, no force pushes |
| Tags as release markers | Tags mark released states (immutable) |
Commit 1"] B --> TAG["Tag v1.0
freigegeben"] K["Korrektur nötig"] K --> C["Korrektur-Buchung
Commit 2"] C --> OBS["obsolescence:
status: superseded
superseded_by: Commit 2"] B --> OBS style B fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style TAG fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style K fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style C fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style OBS fill:#E5E7EB,stroke:#6B7280,color:#0F1B33
Important: Git technically allows
git rebaseandgit commit --amend
- but only linear history without rewriting is GoBD-compliant. The pre-commit hook checks that no force pushes to
mainoccur and that corrections are made as new commits with an obsolescence marker.
GoBD and AO - the Legal Basis
Ordnungsvorschriften
für Buchführung"] AO --> S147["§ 147 AO
Aufbewahrung
von Unterlagen"] S146 --> GoBD["GoBD
(BMF-Schreiben)
Konkretisierung
für elektronische Systeme"] S147 --> GoBD GoBD --> R146["Rz. 146
Nachvollziehbarkeit
Unveränderbarkeit"] GoBD --> R147["Rz. 147
Nachprüfbarkeit"] GoBD --> R64["Rz. 64–91
Verfahrensdokumentation"] GoBD --> R152["Rz. 152
Aufbewahrungsfristen"] style AO fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style S146 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S147 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GoBD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style R146 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R147 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R64 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R152 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
| Legal Source | Content | GoBD Reference |
|---|---|---|
| § 146 Abs. 1 AO | Postings "individually, completely, correctly, in a timely manner and in an orderly fashion" | Rz. 146 (traceability) |
| § 146 Abs. 4 AO | No change that makes the original content unrecognizable | Rz. 146 (immutability) |
| § 146 Abs. 5 AO | "available at any time and readable without delay" | Rz. 152 (availability) |
| § 147 Abs. 2 AO | "can be evaluated by machine" | Rz. 147 (verifiability) |
| § 147 Abs. 3 AO | Retention periods (10/8/6 years) | Rz. 152 (retention) |
| § 147 Abs. 6 AO | Data access during external audit (Z1/Z2/Z3) | Rz. 147 (data access) |
GoBD Data Access (Z1, Z2, Z3)
The GoBD define three types of access that the tax administration can use during an external audit:
| Access Type | Description | How Git Supports It |
|---|---|---|
| Z1 (direct access) | Auditor uses the entrepreneur's system | git log, git show, git grep directly in the repo |
| Z2 (indirect access) | Auditor provides specifications, entrepreneur evaluates | git log --since, git grep, JSON export |
| Z3 (data carrier handover) | Entrepreneur hands over data on a data carrier | git bundle as a self-contained archive |
Z3 is Git's strength: A
git bundlecontains the entire repo (history, commits, tags) in a single file - self-contained, no cloud account, no software license. The auditor can reconstruct the repo on their system withgit cloneand perform all Z1/Z2 operations. That is GoBD-compliant Z3 export "by design".
GitCover Extension: Static Web as Auditor Access (Z3+)
Beyond git bundle, the GitCover Tools (if installed
and used) can generate a browser-navigable static website from the Tenant Evidence Package
as part of a period close. This website contains:
- All DMS documents (vouchers, invoices, contracts) as HTML/PDF
- Cross-period contracts and long-running documents
- Evaluations (Grundbuch, journal, BWA, balance sheet)
- Procedural rules (procedural documentation, chart of accounts)
- Sidecars (
.gc.mdwith V7GUID, SHA-256, taxonomy) - Integrity proofs (manifest with checksums)
(Periodenabschluss)"] EP --> GB["git bundle
(Z3-Basis)"] EP --> SW["Static-Web-Generator
(GitCover Tool)"] GB --> CL["git clone
(Prüfer rekonstruiert Repo)"] SW --> FS["Filesystem-Based-Web
(HTML + PDF + JSON)"] FS --> BR["Browser
(Prüfer navigiert)"] FS --> IDX["Index-Seiten
(nach Datum, Belegart, V7GUID)"] FS --> NAV["Navigation
(retrograd/progressiv)"] FS --> SRH["Suche
(Volltext, SHA-256, V7GUID)"] style EP fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GB fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SW fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style CL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style FS fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style BR fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style IDX fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style NAV fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style SRH fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
The most secure method of all: A filesystem-based web requires no IAM system, no server infrastructure, no database, no network connection. The auditor opens the
index.htmlin their browser - offline, local, without authentication. Integrity is ensured by the manifest with SHA-256 checksums, not by access rights. This is the most secure form of auditor access, because there is no attack surface.
| Property | git bundle (Z3) | Static Web (Z3+) |
|---|---|---|
| Auditor needs | Git installed | Only a browser |
| Navigation | CLI (git log, git show) |
Browser (click, search) |
| Evaluations | Manually via git grep |
Pre-generated index pages |
| DMS documents | In the repo (PDF, XML) | Embedded as HTML/PDF |
| Procedural doc | Markdown in the repo | Rendered as HTML |
| Integrity | Git SHA-256 | Manifest + SHA-256 per file |
| IAM required | No | No |
| Network required | No | No |
| Attack surface | Minimal | Minimal (filesystem only) |
Practical example: The entrepreneur (
E1) creates the period close for FY2026. The GitCover Tool generates a Tenant Evidence Package withgit bundle(for technically proficient auditors) and a static website (for auditors who want to use only a browser). Both are handed over on a USB stick - self-contained, offline, without IAM. The auditor chooses whether to rungit cloneor openindex.html.
Risk Leverage
| Today (cheap) | Tomorrow (audit-proof) | Risk reduced |
|---|---|---|
| Git repo as bookkeeping medium | GoBD Rz. 146/147 fulfilled by design | Estimation § 162 AO |
git log as evidence |
Traceability in reasonable time | Challenge to proper bookkeeping |
| V7GUID + SHA-256 per entry | Retrograde/progressive traceability | Downgrading of evidentiary value |
| Tags + protected branches | Immutability after release | GoBD violation through subsequent change |
git bundle as Z3 export |
Data carrier handover without cloud account | GoBD violation through unavailable legacy systems |
| Obsolescence marker | Traceable corrections | Concealed changes |
| Static web as Z3+ (period close) | Auditor access without IAM, browser only | **GoBD violation through inaccessible/auditor-unfriendly data ** |
Harness Requirement (Preview)
Derivable from ED05:
| ID | Requirement | Priority |
|---|---|---|
| FA-6.1 | Procedural documentation as a versioned Git artifact | MUST |
| FA-6.2 | Grundbuch (journal) as JSON with V7GUID + SHA-256 per entry | MUST |
| FA-6.5 | 10-year retention via evidence packages (Git bundles) | MUST |
| FA-6.6 | Immutability after release (tags, protected branches) | MUST |
| FA-6.7 | Static web generator for period close (Z3+): browser-navigable website from Tenant Evidence Package, without IAM, filesystem-based | SHOULD |
| TA-2.1 | Pre-commit: JSON schema validation | MUST |
| TA-2.4 | Pre-commit: obsolescence status check (no commit on obsolete) |
SHOULD |
The complete requirements list is in Harness-Anforderungen.md.
Sources
- GoBD (BMF letter dated 28.11.2019, BStBl I S. 1269, last amended 14.07.2025, BStBl I S. 1502)
- AO (§ 146 - regulatory rules, § 147 - retention, § 162 - estimation, § 152 - late-payment surcharge)
- HGB (§§ 238–241 - bookkeeping obligation)
E1/agents/(anonymized) - SSoT concept with GoBD-compliant Git usageGitCover.Ledger/docs/02-Tenant-Evidence-Package.md- Tenant Evidence Package concept (period close, repo roles, completeness rules)GitCover.Toolbox- GitCover toolset (analysis, V7GUID, UI components)
Source Topology and CDN Reference Links
| Role | Location | Purpose |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Canonical repository (GPG-signed, versioned) |
| Public OSS Mirror / CDN | codeberg.org/gitcover-commons | Read-only mirror; FLOSS discovery |
| Community Hub | github.com/gitcover-commons | Issues & Discussions; source code reference on Codeberg |
Note: This assignment of sources, mirror, and community hub reflects the current state and may change. Please check the respective canonical source on gitcover.org for the current state.