ED04 - GoBD Fundamentals: Traceability, Verifiability, Immutability
Problem
An entrepreneur starts doing their bookkeeping - and is faced with the question: What exactly does GoBD require, and how do I comply with it 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, formulated in legal language, and barely accessible to laypeople
- "The tax advisor does that" - many entrepreneurs delegate GoBD to their tax advisors without understanding themselves what is required - and pay for it
- Siloed solutions - payroll software, accounting, and document archive each separate, without end-to-end GoBD compliance
- PDF as "electronic" - many believe that a PDF on a hard drive satisfies GoBD - but GoBD requires machine-evaluability (§ 147 Abs. 6 AO), not just filing
- No process documentation - GoBD Rz. 64–91 requires process documentation, but who in an SME has one?
- Subsequent modifications - bookings are "corrected" without the change being traceable - GoBD Rz. 146 requires immutability
Key message
GoBD demands 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 a booking, data must not be altered (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 come about through subsequent inspection, but through the choice of medium. Anyone working in Git repos fulfills traceability, verifiability, and immutability structurally - not through additional controls.
GoBD - Origin and scope
The GoBD (Principles for the Proper Keeping and Retention of Books, Records, and Documents in Electronic Form as well as on 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 nature | Administrative directive (not a law, but binding on tax offices) |
| Basis | § 146 AO (record-keeping rules), § 147 AO (retention), HGB (§§ 238–241) |
| Applicability | For all entrepreneurs who keep electronic books (in practice: everyone) |
| Scope | 146 margin numbers (Rz.) |
Important: The GoBD are not a "recommendation" - they are the administrative directive according to which tax offices conduct audits. Anyone who fails to comply with the GoBD risks an estimated assessment (§ 162 AO), late-filing surcharges (§ 152 AO) and, in the worst case, criminal tax proceedings (§ 370 AO).
The three GoBD core principles in detail
1. Traceability (GoBD Rz. 146)
GoBD Rz. 146: "The bookkeeping must be of such a nature that a knowledgeable third party can gain an overview of the business transactions and the position of the enterprise within a reasonable time."
This means: An auditor (or tax advisor, or tax official) must be able to retrace what happened within a reasonable time.
| GoBD requirement | How Git fulfills it |
|---|---|
| Who made the booking? | git log --author shows every commit author |
| When was it booked? | uuidV7 contains a 48-bit timestamp (RFC 9562 §5.7) |
| What was booked? | The commit diff shows exactly what was added/changed |
| Why was it booked? | The commit message documents the rationale |
| In what role? | role field in the JSON artifact (managing director, accountant, head of R&D) |
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 of such a nature that it is verifiable."
This means: The bookkeeping must offer retrograde and progressive traceability (see ED03):
- Retrograde: from accounting entry → receipt → journal entry → V7GUID
- Progressive: from receipt → accounting entry → ledger → opening balance sheet
| GoBD requirement | How Git fulfills it |
|---|---|
| Retrograde traceability | source_sha256 in the journal entry → receipt |
| Progressive traceability | V7GUID in the receipt → journal entry → ledger |
| Machine-evaluability (§ 147 Abs. 6 AO) | JSON-schema-first - structured data, not PDF |
| Completeness | The pre-commit hook checks that every ledger entry has source_sha256 |
3. Immutability (GoBD Rz. 146)
GoBD Rz. 146: "Entries must not be altered in any way that makes the original content no longer ascertainable."
This means: After a booking, data must not be altered. Corrections must be made as new entries with a rationale.
| GoBD requirement | How Git fulfills it |
|---|---|
| No subsequent modification | Git commits are immutable (SHA-256 hash) |
| Corrections as new entries | New commits with obsolescence: superseded_by |
| Traceable correction | git log shows original + correction + rationale |
| 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 a linear history without rewriting is GoBD-compliant. The pre-commit hook checks that no force-pushes tomainoccur and that corrections are made as new commits with an obsolescence marking.
GoBD and the 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 | Bookings "individually, completely, correctly, in a timely manner, and in an orderly fashion" | Rz. 146 (traceability) |
| § 146 Abs. 4 AO | No alteration that renders the original content unrecognizable | Rz. 146 (immutability) |
| § 146 Abs. 5 AO | "available at any time and immediately readable" | 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 an 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) | The auditor uses the entrepreneur's system | git log, git show, git grep directly in the repo |
| Z2 (indirect access) | The auditor specifies requirements, the entrepreneur evaluates | git log --since, git grep, JSON export |
| Z3 (data carrier handover) | The 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. Usinggit clone, the auditor can reconstruct the repo on their system and 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 (receipts, invoices, contracts) as HTML/PDF
- Contracts spanning multiple periods and long-running documents
- Reports (ledger, journal, BWA, balance sheet)
- Procedural rules (process documentation, chart of accounts)
- Sidecars (
.v7g.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, locally, without authentication. Integrity is guaranteed 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 requires | Git installed | Only a browser |
| Navigation | CLI (git log, git show) |
Browser (click, search) |
| Reports | Manually via git grep |
Pre-generated index pages |
| DMS documents | In the repo (PDF, XML) | Embedded as HTML/PDF |
| Process documentation | 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 only want to use 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 mitigated |
|---|---|---|
| Git repo as bookkeeping medium | GoBD Rz. 146/147 fulfilled by design | Estimated assessment § 162 AO |
git log as evidence |
Traceability within a reasonable time | Dispute over the properness of the bookkeeping |
| V7GUID + SHA-256 per entry | Retrograde/progressive traceability | Downgrading of evidentiary value |
| Tags + protected branches | Immutability after release | GoBD violation through subsequent modification |
git bundle as Z3 export |
Data carrier handover without a cloud account | GoBD violation due to unavailable legacy systems |
| Obsolescence marking | Traceable corrections | Concealed modifications |
| Static web as Z3+ (period close) | Auditor access without IAM, browser only | GoBD violation due to inaccessible/auditor-unfriendly data |
Harness requirements (preview)
Derivable from ED04:
| ID | Requirement | Priority |
|---|---|---|
| FA-6.1 | Process documentation as a versioned Git artifact | MUST |
| FA-6.2 | Ledger (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 the period close (Z3+): browser-navigable website from the 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 list of requirements can be found 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 - record-keeping rules, § 147 - retention, § 162 - estimated assessment, § 152 - late-filing surcharge)
- HGB (§§ 238–241 - bookkeeping obligation)
AFJD/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 to 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.