ED05 - GoBD Basics: Traceability, Verifiability, Immutability
Problem
A business owner starts keeping books - and faces the question: What exactly does GoBD require, and how can I comply without expensive specialized software?
Current practice in the SME sector:
- GoBD as a book with seven seals - the GoBD (BMF circular, 146 pages) are abstract and legally worded, making them barely accessible to laypeople
- "That's the tax advisor's job" - many business owners delegate GoBD matters to StB without first understanding what is required - and pay for it
- Stand-alone solutions - payroll software, accounting and document archive are each separate, without end-to-end GoBD compliance
- PDF as "electronic" - many believe that a PDF on a hard drive fulfills GoBD - but GoBD requires machine evaluability (§ 147 Abs. 6 AO), not merely storage
- No process documentation - GoBD Rz. 64–91 requires a process documentation, but who in an SME has one?
- Subsequent changes - entries are "corrected" without the change being traceable - GoBD Rz. 146 requires immutability
Core Statement
GoBD requires three core principles, which Git by Design fulfills:
- Traceability (GoBD Rz. 146) - every entry must be traceable (Who? When? What? Why?)
- Verifiability (GoBD Rz. 147) - the bookkeeping must be verifiable (backward/forward traceability)
- Immutability (GoBD Rz. 146) - after the posting, data must not be changed (corrections as new entries)
Git fulfills all three structurally - not through subsequent checks, 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
backward/forward
resolvable"] U --> GU["Git: Tags + Protected Branches
+ obsolescence marker
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 a subsequent audit, but through the choice of medium. Anyone working in Git repositories structurally fulfills traceability, verifiability and immutability - not through additional controls.
GoBD - Origin and Scope
The GoBD (Principles for the proper management and retention of books, records and documents in electronic form and for data access) are set out in a BMF circular 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 statute, but binding for tax offices) |
| Basis | § 146 AO (record-keeping rules), § 147 AO (retention), HGB (§§ 238–241) |
| Applicability | For all business owners who keep books electronically (in practice: all) |
| Scope | 146 marginal numbers (Rz.) |
Important: The GoBD are not a "recommendation" - they are the administrative instruction according to which tax offices conduct audits. Anyone who does not comply with the GoBD risks an assessment by estimate (§ 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 an expert third party can obtain an overview of the business transactions and the company's situation within a reasonable time."
This means: An auditor (or tax advisor or tax official) must be able to trace what happened within a reasonable time.
| GoBD requirement | How Git fulfills it |
|---|---|
| Who made the entry? | git log --author shows every commit author |
| When was the entry made? | uuidV7 contains a 48-bit timestamp (RFC 9562 §5.7) |
| What was entered? | The commit diff shows exactly what was added/changed |
| Why was the entry made? | The commit message documents the reason |
| In what role? | role field in the JSON artifact (managing director, bookkeeper, R&D manager) |
Who? When? What?"] P --> SH["git show
Commit details"] P --> DF["git diff
What changed?"] P --> V7["uuidV7 decode
Exact capture 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 of such a nature that it is verifiable."
This means: The bookkeeping must be traceable both backward and forward (see ED03):
- Backward: from the accounting entry → document → journal entry → V7GUID
- Forward: from the document → accounting entry → general ledger → opening balance sheet
| GoBD requirement | How Git fulfills it |
|---|---|
| Backward traceability | source_sha256 in the journal entry → document |
| Forward traceability | V7GUID in the document → journal entry → general ledger |
| Machine evaluability (§ 147 Abs. 6 AO) | JSON-schema-first - structured data, not PDF |
| Completeness | The pre-commit hook checks that every general ledger 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 posting, data must not be changed. Corrections must be made as new entries with a reason.
| 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 the original + correction + reason |
| Protected Branches | The main branch is protected, with no force pushes |
| Tags as approval markers | Tags mark approved versions (immutable) |
Commit 1"] B --> TAG["Tag v1.0
approved"] K["Correction required"] K --> C["Correcting posting
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 permits
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 marker.
GoBD and AO - The Legal Basis
Record-keeping rules
for bookkeeping"] AO --> S147["§ 147 AO
Retention
of documents"] S146 --> GoBD["GoBD
(BMF circular)
Detailed provisions
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 | Bookkeeping entries "individually, completely, correctly, timely and in an orderly manner" | Rz. 146 (traceability) |
| § 146 Abs. 4 AO | No modification that makes the original content unknowable | 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:
| Type of access | Description | How Git supports it |
|---|---|---|
| Z1 (direct access) | The auditor uses the business owner's system | git log, git show, git grep directly in the repo |
| Z2 (indirect access) | The auditor specifies parameters, and the business owner evaluates them | git log --since, git grep, JSON export |
| Z3 (data media transfer) | The business owner hands over data on a storage medium | 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 usegit cloneto reconstruct the repo on their system and perform all Z1/Z2 operations. This is a 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 (source documents, invoices, contracts) as HTML/PDF
- Contracts spanning multiple periods and long-term documents
- Reports (general ledger, journal, BWA, balance sheet)
- Process rules (process documentation, chart of accounts)
- Sidecars (
.v7g.mdwith V7GUID, SHA-256, taxonomy) - Integrity evidence (manifest with checksums)
(period close)"] 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
(backward/forward)"] 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 safest method of all: A Filesystem-Based Web requires no IAM system, no server infrastructure, no database and no network connection. The auditor opens the
index.htmlfile in 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 | 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 business owner (
E1) prepares the period close for FY2026. The GitCover Tool generates a Tenant Evidence Package withgit bundle(for technically experienced 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 a bookkeeping medium | GoBD Rz. 146/147 fulfilled by Design | Assessment by estimate § 162 AO |
git log as evidence |
Traceability within a reasonable time | Challenge to proper bookkeeping |
| V7GUID + SHA-256 per entry | Backward/forward traceability | Downgrading of evidentiary value |
| Tags + Protected Branches | Immutability after approval | GoBD violation due to subsequent changes |
git bundle as a Z3 export |
Data media transfer without a cloud account | GoBD violation due to unavailable legacy systems |
| Obsolescence marker | Traceable corrections | Concealed changes |
| Static Web as Z3+ (period close) | Auditor access without IAM, browser only | **GoBD violation due to inaccessible/auditor-unfriendly data ** |
Harness Requirement (Preview)
Derived from ED05:
| ID | Requirement | Priority |
|---|---|---|
| FA-6.1 | Process documentation as a versioned Git artifact | MUST |
| FA-6.2 | General 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 approval (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 to obsolete) |
SHOULD |
The complete list of requirements in Harness-Anforderungen.md.
Sources
- GoBD (BMF circular 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 - assessment by estimate, § 152 - late-filing surcharge)
- HGB (§§ 238–241 - bookkeeping obligation)
E1/agents/(anonymized) - SSoT concept with GoBD-compliant use of GitGitCover.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.