ED05 - GoBD Fundamentals: Traceability, Verifiability, Immutability
Problem
An entrepreneur begins bookkeeping - and faces the question: What does GoBD specifically require, and how do I fulfill 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, hardly accessible to laypeople
- "The tax advisor does that" - many entrepreneurs delegate GoBD to tax advisors without understanding themselves what is required - and pay for it
- Siloed solutions - payroll software, accounting, document archive each separate, without end-to-end GoBD compliance
- PDF as "electronic" - many believe a PDF on a hard drive fulfills 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 changes - 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 the 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["Verifiability
Rz. 147"] G --> U["Immutability
Rz. 146"] N --> GN["Git: commit author
+ timestamp
+ commit message"] P --> GP["Git: V7GUID + SHA-256
retrograde/progressive
resolvable"] U --> GU["Git: tags + protected branches
+ obsolescence marking
corrections as new 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 review, 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 scope
The GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) 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 instruction (not a law, but binding for tax offices) |
| Basis | § 146 AO (order regulations), § 147 AO (retention), HGB (§§ 238–241) |
| Applicability | For all entrepreneurs who book electronically (practically: all) |
| Scope | 146 marginal numbers (Rz.) |
Important: The GoBD are not a "recommendation" - they are the administrative instruction according to which tax offices audit. Those who do not fulfill the GoBD risk an estimated assessment (§ 162 AO), late-filing surcharges (§ 152 AO) and, in the worst case, tax criminal proceedings (§ 370 AO).
The three GoBD core principles in detail
1. Traceability (GoBD Rz. 146)
GoBD Rz. 146: "The bookkeeping must be such that an expert third party can gain an overview of the business transactions and the situation of the company within a reasonable period of time."
This means: An auditor (or tax advisor, or tax official) must be able to trace what happened within a reasonable period of time.
| GoBD requirement | How Git fulfills it |
|---|---|
| Who booked? | git log --author shows every commit author |
| When was the booking made? | 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 justification |
| In which role? | role field in the JSON artifact (CEO, accountant, head of R&D) |
Who? When? What?"] P --> SH["git show
Commit details"] P --> DF["git diff
What has changed?"] P --> V7["uuidV7 decode
Exact recording time"] GL --> R["Traceability
within a reasonable time"] 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 such that it is verifiable."
This means: The bookkeeping must be retrogradely and progressively traceable (see ED03):
- Retrograde: from accounting entry → document → daybook entry → V7GUID
- Progressive: from document → accounting entry → Grundbuch → opening balance sheet
| GoBD requirement | How Git fulfills it |
|---|---|
| Retrograde traceability | source_sha256 in the daybook entry → document |
| Progressive traceability | V7GUID in the document → daybook 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 altered in such a way that the original content can no longer be determined."
This means: After the booking, data must not be altered. Corrections must be made as new entries with a justification.
| GoBD requirement | How Git fulfills it |
|---|---|
| No subsequent alteration | Git commits are immutable (SHA-256 hash) |
| Corrections as new entries | New commits with obsolescence: superseded_by |
| Traceable correction | git log shows original + correction + justification |
| Protected branches | main branch protected, no force pushes |
| Tags as release markers | Tags mark released states (immutable) |
Commit 1"] B --> TAG["Tag v1.0
released"] K["Correction needed"] K --> C["Correction booking
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 to
mainoccur and that corrections are made as new commits with an obsolescence marking.
GoBD and AO - the legal basis
Order regulations
for bookkeeping"] AO --> S147["§ 147 AO
Retention
of documents"] S146 --> GoBD["GoBD
(BMF letter)
Concretization
for electronic systems"] S147 --> GoBD GoBD --> R146["Rz. 146
Traceability
Immutability"] GoBD --> R147["Rz. 147
Verifiability"] GoBD --> R64["Rz. 64–91
Process documentation"] GoBD --> R152["Rz. 152
Retention periods"] 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, timely and in an orderly manner" | 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 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 transfer) | The entrepreneur hands over data on data carriers | 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. This 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-end closing. This
website contains:
- All DMS documents (receipts, invoices, contracts) as HTML/PDF
- Cross-period contracts and long-running documents
- Reports (Grundbuch, journal, BWA, balance sheet)
- Procedural rules (process documentation, chart of accounts)
- Sidecars (
.v7g.mdwith V7GUID, SHA-256, taxonomy) - Integrity evidence (manifest with checksums)
(period-end closing)"] EP --> GB["git bundle
(Z3 basis)"] EP --> SW["Static web generator
(GitCover Tool)"] GB --> CL["git clone
(auditor reconstructs repo)"] SW --> FS["Filesystem-Based Web
(HTML + PDF + JSON)"] FS --> BR["Browser
(auditor navigates)"] FS --> IDX["Index pages
(by date, document type, V7GUID)"] FS --> NAV["Navigation
(retrograde/progressive)"] FS --> SRH["Search
(full text, 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 | Browser only |
| 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-end closing 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 for themselves 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 proof |
Traceability within a reasonable time | Dispute over properness |
| V7GUID + SHA-256 per entry | Retrograde/progressive traceability | Downgrading of evidentiary value |
| Tags + protected branches | Immutability after release | GoBD violation through subsequent alteration |
git bundle as Z3 export |
Data carrier transfer without a cloud account | GoBD violation through unavailable legacy systems |
| Obsolescence marking | Traceable corrections | Concealed changes |
| Static web as Z3+ (period-end closing) | 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 | Process 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-end closing (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 in Harness-Anforderungen.md.
Sources
- GoBD (BMF letter of 28.11.2019, BStBl I S. 1269, last amended 14.07.2025, BStBl I S. 1502)
- AO (§ 146 - order regulations, § 147 - retention, § 162 - estimated assessment, § 152 - late-filing surcharge)
- HGB (§§ 238–241 - obligation to keep books)
AFJD/agents/(anonymized) - SSoT concept with GoBD-compliant Git usageGitCover.Ledger/docs/02-Tenant-Evidence-Package.md- Tenant Evidence Package concept (period-end closing, 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.