ED04 - GoBD-Grundlagen: Nachvollziehbarkeit, Nachprüfbarkeit, Unveränderbarkeit
Problem
Ein Unternehmer beginnt mit der Buchführung - und steht vor der Frage: Was verlangt GoBD konkret, und wie erfülle ich es ohne teure Spezialsoftware?
Die heutige Praxis im KMU-Bereich:
- GoBD als Buch mit sieben Siegeln - die GoBD (BMF-Schreiben, 146 Seiten) sind abstrakt, juristisch formuliert, für Laien kaum zugänglich
- "Das macht der Steuerberater" - viele Unternehmer delegieren GoBD an StB, ohne selbst zu verstehen, was gefordert ist - und bezahlen dafür
- Insellösungen - Lohnsoftware, Buchhaltung, Belegarchiv jeweils separat, ohne durchgängige GoBD-Konformität
- PDF als "elektronisch" - viele glauben, ein PDF auf einer Festplatte erfüllt GoBD - aber GoBD verlangt maschinelle Auswertbarkeit (§ 147 Abs. 6 AO), nicht nur Ablage
- Keine Verfahrensdokumentation - GoBD Rz. 64–91 verlangt eine Verfahrensdoku, aber wer im KMU hat eine?
- Nachträgliche Änderungen - Buchungen werden "korrigiert", ohne dass die Änderung nachvollziehbar ist - GoBD Rz. 146 verlangt Unveränderbarkeit
Kernaussage
GoBD fordert drei Kernprinzipien, die Git by Design erfüllt:
- Nachvollziehbarkeit (GoBD Rz. 146) - jeder Eintrag muss nachvollziehbar sein (Wer? Wann? Was? Warum?)
- Nachprüfbarkeit (GoBD Rz. 147) - die Buchführung muss nachprüfbar sein (retrograde/progressive Nachverfolgbarkeit)
- Unveränderbarkeit (GoBD Rz. 146) - nach der Buchung dürfen Daten nicht verändert werden (Korrekturen als neue Einträge)
Git erfüllt alle drei strukturell - nicht durch nachträgliche Kontrollen, sondern durch die Architektur selbst:
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-Konformität entsteht nicht durch nachträgliche Prüfung, sondern durch die Wahl des Mediums. Wer in Git-Repos arbeitet, erfüllt Nachvollziehbarkeit, Nachprüfbarkeit und Unveränderbarkeit strukturell - nicht durch zusätzliche Controls.
GoBD - Herkunft und Geltung
Die GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) sind ein BMF-Schreiben vom 28.11.2019 (BStBl I S. 1269), zuletzt geändert am 14.07.2025 (BStBl I S. 1502).
| Eigenschaft | Wert |
|---|---|
| Herausgeber | Bundesministerium der Finanzen (BMF) |
| Rechtscharakter | Verwaltungsanweisung (kein Gesetz, aber bindend für Finanzämter) |
| Basis | § 146 AO (Ordnungsvorschriften), § 147 AO (Aufbewahrung), HGB (§§ 238–241) |
| Geltung | Für alle Unternehmer, die elektronisch buchen (praktisch: alle) |
| Umfang | 146 Randziffern (Rz.) |
Wichtig: GoBD sind keine "Empfehlung" - sie sind die Verwaltungsanweisung, nach der Finanzämter prüfen. Wer GoBD nicht erfüllt, riskiert Schätzung (§ 162 AO), Verspätungszuschläge (§ 152 AO) und im schlimmsten Fall Steuerstrafverfahren (§ 370 AO).
Die drei GoBD-Kernprinzipien im Detail
1. Nachvollziehbarkeit (GoBD Rz. 146)
GoBD Rz. 146: "Die Buchführung muss so beschaffen sein, dass ein sachverständiger Dritter in angemessener Zeit den Überblick über die Geschäftsvorfälle und die Lage des Unternehmens gewinnen kann."
Das bedeutet: Ein Prüfer (oder Steuerberater, oder Finanzbeamter) muss in angemessener Zeit nachvollziehen können, was passiert ist.
| GoBD-Anforderung | Wie Git es erfüllt |
|---|---|
| Wer hat gebucht? | git log --author zeigt jeden Commit-Autor |
| Wann wurde gebucht? | uuidV7 enthält 48-Bit-Zeitstempel (RFC 9562 §5.7) |
| Was wurde gebucht? | Commit-Diff zeigt exakt, was hinzugefügt/geändert wurde |
| Warum wurde gebucht? | Commit-Message dokumentiert die Begründung |
| In welcher Rolle? | role-Feld im JSON-Artefakt (GF, Buchhalter, F&E-Leiter) |
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. Nachprüfbarkeit (GoBD Rz. 147)
GoBD Rz. 147: "Die Buchführung muss so beschaffen sein, dass sie nachprüfbar ist."
Das bedeutet: Die Buchführung muss retrograd und progressiv nachverfolgbar sein (siehe ED03):
- Retrograd: vom Buchungssatz → Beleg → Tagebucheintrag → V7GUID
- Progressiv: vom Beleg → Buchungssatz → Grundbuch → Eröffnungsbilanz
| GoBD-Anforderung | Wie Git es erfüllt |
|---|---|
| Retrograde Nachverfolgbarkeit | source_sha256 im Tagebucheintrag → Beleg |
| Progressive Nachverfolgbarkeit | V7GUID im Beleg → Tagebucheintrag → Grundbuch |
| Maschinelle Auswertbarkeit (§ 147 Abs. 6 AO) | JSON-Schema-First - strukturierte Daten, kein PDF |
| Vollständigkeit | Pre-Commit-Hook prüft, dass jeder Grundbuch-Eintrag source_sha256 hat |
3. Unveränderbarkeit (GoBD Rz. 146)
GoBD Rz. 146: "Eintragungen dürfen nicht in einer Weise verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist."
Das bedeutet: Nach der Buchung dürfen Daten nicht verändert werden. Korrekturen müssen als neue Einträge mit Begründung erfolgen.
| GoBD-Anforderung | Wie Git es erfüllt |
|---|---|
| Keine nachträgliche Änderung | Git-Commits sind unveränderlich (SHA-256-Hash) |
| Korrekturen als neue Einträge | Neue Commits mit obsolescence: superseded_by |
| Nachvollziehbare Korrektur | git log zeigt Original + Korrektur + Begründung |
| Protected Branches | main-Branch geschützt, keine Force-Pushes |
| Tags als Freigabe-Marker | Tags markieren freigegebene Stände (unveränderbar) |
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
Wichtig: Git erlaubt technisch
git rebaseundgit commit --amend
- aber GoBD-konform ist nur lineare Historie ohne Umschreibung. Der Pre-Commit-Hook prüft, dass keine Force-Pushes auf
mainerfolgen und dass Korrekturen als neue Commits mit Obsoleszenz-Markierung erfolgen.
GoBD und AO - die rechtliche 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
| Rechtsquelle | Inhalt | GoBD-Bezug |
|---|---|---|
| § 146 Abs. 1 AO | Buchungen "einzeln, vollständig, richtig, zeitgerecht und geordnet" | Rz. 146 (Nachvollziehbarkeit) |
| § 146 Abs. 4 AO | Keine Veränderung, die ursprünglichen Inhalt unkenntlich macht | Rz. 146 (Unveränderbarkeit) |
| § 146 Abs. 5 AO | "jederzeit verfügbar und unverzüglich lesbar" | Rz. 152 (Verfügbarkeit) |
| § 147 Abs. 2 AO | "maschinell ausgewertet werden können" | Rz. 147 (Nachprüfbarkeit) |
| § 147 Abs. 3 AO | Aufbewahrungsfristen (10/8/6 Jahre) | Rz. 152 (Aufbewahrung) |
| § 147 Abs. 6 AO | Datenzugriff bei Außenprüfung (Z1/Z2/Z3) | Rz. 147 (Datenzugriff) |
GoBD-Datenzugriff (Z1, Z2, Z3)
Die GoBD definieren drei Zugriffsarten, die die Finanzverwaltung bei einer Außenprüfung nutzen kann:
| Zugriffsart | Beschreibung | Wie Git es unterstützt |
|---|---|---|
| Z1 (unmittelbarer Zugriff) | Prüfer nutzt das System des Unternehmers | git log, git show, git grep direkt im Repo |
| Z2 (mittelbarer Zugriff) | Prüfer gibt Vorgaben, Unternehmer wertet aus | git log --since, git grep, JSON-Export |
| Z3 (Datenträgerüberlassung) | Unternehmer übergibt Daten auf Datenträger | git bundle als self-contained Archiv |
Z3 ist die Stärke von Git: Ein
git bundleenthält das gesamte Repo (Historie, Commits, Tags) in einer einzigen Datei - self-contained, kein Cloud-Account, keine Software-Lizenz. Der Prüfer kann mitgit clonedas Repo auf seinem System rekonstruieren und alle Z1/Z2-Operationen durchführen. Das ist GoBD-konformer Z3-Export "by Design".
GitCover-Erweiterung: Static-Web als Prüfer-Zugang (Z3+)
Über git bundle hinaus können die GitCover Tools (sofern installiert
und genutzt) im Rahmen eines Periodenabschlusses eine
browser-navigierbare Static-Website aus dem Tenant Evidence Package
generieren. Diese Website enthält:
- Alle DMS-Dokumente (Belege, Rechnungen, Verträge) als HTML/PDF
- Periodenübergreifende Verträge und langlaufende Dokumente
- Auswertungen (Grundbuch, Journal, BWA, Bilanz)
- Verfahrensvorschriften (Verfahrensdokumentation, Kontenplan)
- Sidecars (
.v7g.mdmit V7GUID, SHA-256, Taxonomie) - Integritätsnachweise (Manifest mit Checksummen)
(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
Die sicherste Methode überhaupt: Ein Filesystem-Based-Web benötigt kein IAM-System, keine Server-Infrastruktur, keine Datenbank, keine Netzwerkverbindung. Der Prüfer öffnet die
index.htmlin seinem Browser - offline, lokal, ohne Authentifizierung. Die Integrität wird durch das Manifest mit SHA-256-Checksummen gewährleistet, nicht durch Zugriffsrechte. Das ist die sicherste Form des Prüfer-Zugangs, weil es keine Angriffsfläche gibt.
| Eigenschaft | git bundle (Z3) | Static-Web (Z3+) |
|---|---|---|
| Prüfer benötigt | Git installiert | Nur Browser |
| Navigation | CLI (git log, git show) |
Browser (Klick, Suche) |
| Auswertungen | Manuell via git grep |
Vorgenerierte Index-Seiten |
| DMS-Dokumente | Im Repo (PDF, XML) | Als HTML/PDF eingebettet |
| Verfahrensdoku | Markdown im Repo | Als HTML gerendert |
| Integrität | Git-SHA-256 | Manifest + SHA-256 pro Datei |
| IAM nötig | Nein | Nein |
| Netzwerk nötig | Nein | Nein |
| Angriffsfläche | Minimal | Minimal (Filesystem only) |
Praxis-Beispiel: Der Unternehmer (
E1) erstellt den Periodenabschluss für FY2026. Das GitCover Tool generiert ein Tenant Evidence Package mitgit bundle(für technisch versierte Prüfer) und eine Static-Website (für Prüfer, die nur einen Browser nutzen wollen). Beides wird auf einem USB-Stick übergeben - self-contained, offline, ohne IAM. Der Prüfer wählt selbst, ob ergit cloneoderindex.htmlöffnet.
Risiko-Leverage
| Heute (cheap) | Morgen (revisionssicher) | Risiko gemindert |
|---|---|---|
| Git-Repo als Buchführungsmedium | GoBD Rz. 146/147 by Design erfüllt | Schätzung § 162 AO |
git log als Nachweis |
Nachvollziehbarkeit in angemessener Zeit | Bestreitung der Ordnungsmäßigkeit |
| V7GUID + SHA-256 pro Eintrag | Retrograde/progressive Nachverfolgbarkeit | Beweiswertrückstufung |
| Tags + Protected Branches | Unveränderbarkeit nach Freigabe | GoBD-Verstoß durch nachträgliche Änderung |
git bundle als Z3-Export |
Datenträgerüberlassung ohne Cloud-Account | GoBD-Verstoß durch nicht verfügbare Alt-Systeme |
| Obsoleszenz-Markierung | Korrekturen nachvollziehbar | Verdeckte Änderungen |
| Static-Web als Z3+ (Periodenabschluss) | Prüfer-Zugang ohne IAM, nur Browser | **GoBD-Verstoß durch unzugängliche/prüfer-unfreundliche Daten ** |
Harness-Anforderung (Vorschau)
Aus ED04 ableitbar:
| ID | Anforderung | Priorität |
|---|---|---|
| FA-6.1 | Verfahrensdokumentation als versioniertes Git-Artefakt | MUST |
| FA-6.2 | Grundbuch (Journal) als JSON mit V7GUID + SHA-256 pro Eintrag | MUST |
| FA-6.5 | 10-Jahres-Aufbewahrung via Evidence-Packages (Git-Bundles) | MUST |
| FA-6.6 | Unveränderbarkeit nach Freigabe (Tags, Protected Branches) | MUST |
| FA-6.7 | Static-Web-Generator für Periodenabschluss (Z3+): browser-navigierbare Website aus Tenant Evidence Package, ohne IAM, Filesystem-Based | SHOULD |
| TA-2.1 | Pre-Commit: JSON-Schema-Validierung | MUST |
| TA-2.4 | Pre-Commit: Obsoleszenz-Status-Prüfung (kein Commit auf obsolete) |
SHOULD |
Die vollständige Anforderungsliste in Harness-Anforderungen.md.
Quellen
- GoBD (BMF-Schreiben vom 28.11.2019, BStBl I S. 1269, zuletzt geändert 14.07.2025, BStBl I S. 1502)
- AO (§ 146 - Ordnungsvorschriften, § 147 - Aufbewahrung, § 162 - Schätzung, § 152 - Verspätungszuschlag)
- HGB (§§ 238–241 - Buchführungspflicht)
AFJD/agents/(anonymisiert) - SSoT-Konzept mit GoBD-konformer Git-NutzungGitCover.Ledger/docs/02-Tenant-Evidence-Package.md- Tenant Evidence Package-Konzept (Periodenabschluss, Repo-Rollen, Vollständigkeitsregeln)GitCover.Toolbox- GitCover-Toolset (Analyse, V7GUID, UI-Komponenten)
Quellen-Topologie und CDN-Referenz-Links
| Rolle | Ort | Zweck |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Kanonische Ablage (GPG-signiert, versioniert) |
| Public OSS Mirror / CDN | codeberg.org/gitcover-commons | Read-only-Spiegel; FLOSS-Discovery |
| Community Hub | github.com/gitcover-commons | Issues & Discussions; Quell-Code-Referenz auf Codeberg |
Hinweis: Diese Zuordnung von Quellen, Mirror und Community-Hub spiegelt den aktuellen Stand wider und kann sich ändern. Bitte prüfen Sie die jeweilige kanonische Quelle auf gitcover.org für den aktuellen Zustand.