ED04 - GoBD Fundamentals: Traceability, Auditability, Immutability
Problem
An entrepreneur starts with bookkeeping - and faces the question: What exactly does GoBD require, and how do I fulfil it without expensive specialist software?
Today's practice in the SME sector:
- GoBD as a book with seven seals - the GoBD (BMF letter, 146 pages) are abstract, legally formulated, hardly accessible to lay people
- "The tax advisor does that" - many entrepreneurs delegate GoBD to the StB without understanding themselves what is demanded - and pay for it
- Island solutions - payroll software, accounting, document archive each separately, without end-to-end GoBD conformity
- PDF as "electronic" - many believe a PDF on a hard drive fulfils GoBD - but GoBD requires machine evaluability (§ 147 Abs. 6 AO), not just filing
- No procedural documentation - GoBD Rz. 64-91 requires a procedural doc, but who in an SME has one?
- Subsequent changes - bookings are "corrected" without the change being traceable - GoBD Rz. 146 requires immutability
Core Statement
GoBD demands three core principles that Git fulfils by Design:
- Traceability (GoBD Rz. 146) - every entry must be traceable (Who? When? What? Why?)
- Auditability (GoBD Rz. 147) - the bookkeeping must be auditable (retrograde/progressive traceability)
- Immutability (GoBD Rz. 146) - after booking, data may not be changed (corrections as new entries)
Git fulfils 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 conformity does not arise through subsequent audit, but through the choice of medium. Anyone working in Git repos fulfils traceability, auditability and immutability structurally - not through additional controls.
GoBD - Origin and Validity
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 of 28.11.2019 (BStBl I S. 1269), last amended on 14.07.2025 (BStBl I S. 1502).
| Property | Value |
|---|---|
| Publisher | Bundesministerium der Finanzen (BMF) |
| Legal character | Administrative instruction (not a law, but binding for tax offices) |
| Basis | § 146 AO (order regulations), § 147 AO (retention), HGB (§§ 238-241) |
| Scope | All entrepreneurs who keep electronic books (practically: all) |
| Extent | 146 margin numbers (Rz.) |
Important: GoBD are not a "recommendation" - they are the administrative instruction by which tax offices audit. Anyone who does not fulfil GoBD risks estimation (§ 162 AO), late 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 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 trace in a reasonable time what happened.
| GoBD Requirement | How Git fulfils it |
|---|---|
| Who booked? | git log --author shows every commit author |
| When was it booked? | uuidV7 contains 48-bit timestamp (RFC 9562 §5.7) |
| What was booked? | Commit diff shows exactly what was added/changed |
| Why was it booked? | Commit message documents the justification |
| In which role? | role field in the JSON artefact (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. Auditability (GoBD Rz. 147)
GoBD Rz. 147: "The bookkeeping must be such that it is auditable."
This means: the bookkeeping must be retrogradely and progressively traceable (see ED03):
- Retrograde: from the booking record → document → diary entry → V7GUID
- Progressive: from the document → booking record → ledger → opening balance
| GoBD Requirement | How Git fulfils it |
|---|---|
| Retrograde traceability | source_sha256 in the diary entry → document |
| Progressive traceability | V7GUID in the document → diary entry → ledger |
| Machine evaluability (§ 147 Abs. 6 AO) | JSON-Schema-First - structured data, no PDF |
| Completeness | Pre-Commit hook checks that every ledger entry has source_sha256 |
3. Immutability (GoBD Rz. 146)
GoBD Rz. 146: "Entries may not be changed in such a way that the original content can no longer be determined."
This means: after booking, data may not be changed. Corrections must be made as new entries with justification.
| GoBD Requirement | How Git fulfils 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 + 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
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 GoBD-conformant is only linear history without rewriting. The Pre-Commit hook checks that no force pushes occur onmainand that corrections are made as new commits with obsolescence marking.
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 | Bookings "individually, completely, correctly, timely and ordered" | Rz. 146 (traceability) |
| § 146 Abs. 4 AO | No change that obscures the original content | Rz. 146 (immutability) |
| § 146 Abs. 5 AO | "available at any time and immediately readable" | Rz. 152 (availability) |
| § 147 Abs. 2 AO | "can be machine-evaluated" | Rz. 147 (auditability) |
| § 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 access types 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 gives instructions, entrepreneur evaluates | git log --since, git grep, JSON export |
| Z3 (data carrier delivery) | Entrepreneur hands over data on a data carrier | git bundle as 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 licence. The auditor can reconstruct the repo on their system withgit cloneand perform all Z1/Z2 operations. This is GoBD-conformant Z3 export "by Design".
GitCover Extension: Static Web as Auditor Access (Z3+)
Beyond git bundle, the GitCover tools (if installed and used) can,
as part of a period close, generate a browser-navigable static
website from the Tenant Evidence Package. This website contains:
- All DMS documents (vouchers, invoices, contracts) as HTML/PDF
- Cross-period contracts and long-running documents
- Evaluations (ledger, journal, BWA, balance sheet)
- Procedural regulations (procedural 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 safest method of all: A filesystem-based web needs 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 ensured by the manifest with SHA-256 checksums, not by access rights. This is the safest form of auditor access, because there is no attack surface.
| Property | git bundle (Z3) | Static Web (Z3+) |
|---|---|---|
| Auditor needs | Git installed | Only browser |
| Navigation | CLI (git log, git show) |
Browser (click, search) |
| Evaluations | Manual 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 needed | No | No |
| Network needed | 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 versed 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 togit cloneor openindex.html.
Risk Leverage
| Today (cheap) | Tomorrow (auditable) | Risk mitigated |
|---|---|---|
| Git repo as bookkeeping medium | GoBD Rz. 146/147 fulfilled by Design | Estimation § 162 AO |
git log as evidence |
Traceability in reasonable time | Dispute of orderliness |
| 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 delivery without cloud account | GoBD violation through unavailable legacy systems |
| Obsolescence marking | Corrections traceable | Hidden changes |
| Static Web as Z3+ (period close) | Auditor access without IAM, only browser | GoBD violation through inaccessible/auditor-unfriendly data |
Harness Requirements (Preview)
Derivable from ED04:
| ID | Requirement | Priority |
|---|---|---|
| FA-6.1 | Procedural documentation as versioned Git artefact | 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 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 full requirements list 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 - estimation, § 152 - late surcharge)
- HGB (§§ 238-241 - bookkeeping obligation)
AFJD/agents/(anonymised) - SSoT concept with GoBD-conformant Git useGitCover.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 storage (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.