ED01 - Motivation: Warum ein Unternehmer sein Tagebuch in Git führt

Problem

Ein Unternehmer gründet eine Organisation - und steht vor einem unklaren Bild künftig auftretender Risiken. Welche Pflichten entstehen wann? Welche Belege müssen wie lange aufbewahrt werden? Welche Fristen drohen zu versäumen? Welche Behörden melden sich wann zu welcher Prüfung an?

Die heutige Praxis im KMU-Bereich ist geprägt von:

• Zettelwirtschaft und lokalen Excel-Listen - nicht nachvollziehbar, nicht revisionsicher
• PDF- und E-Mail-Chaos bei Prüfungen - Unterlagen werden ad-hoc zusammengeklappt
• Insellösungen (Lohnsoftware hier, Buchhaltung dort, Belegarchiv woanders) - ohne durchgängige Nachweiskette
• Open-Source-Lücken bei besonderen Pflichten (FZul/BSFZ, Gemeinnützigkeit, Arbeitszeit, BEM) - hier gibt es so gut wie keine freie Unterstützung
• Risiko-Stau - Pflichten werden heute cheap ignoriert, bis sie morgen als Bußgelder, Verspätungszuschläge oder Aberkennungen teuer werden

Kernaussage

Nicht nur Dokumente müssen revisionssicher sein - auch Entscheidungen, Fristen und Belegreferenzen müssen nachvollziehbar, reproduzierbar und auditierbar sein. Ein Git-natives Tagebuch macht genau das: es wandelt heute cheap (preiswert) erfasste Fakten (ein JSON-Eintrag mit V7GUID + SHA-256-Belegreferenz) in künftige revisionssichere Nachweise um. Compliance wird zum Hebel, nicht zur Bremse.

Compliance by Design: Das "unklare Bild" künftiger Risiken wird durch GitCover-Techniken (OSCAL, OPA, V7GUID, Git-Hooks) von Anfang an gemindert, nicht erst, wenn der Prüfer klingelt.

Genese: Die SV-Prüfung als praktischer Auslöser

Die GitCover-Idee wurde nicht im Elfenbeinturm geboren, sondern aus konkreten Praxiserfahrungen: zuletzt aus einer SV-Betriebsprüfung bei einer Kleinst-UG (hier anonymisiert als ORG-V für "Vorläufer-Organisation") für den Zeitraum 2021–2023; stattgefunden im Zeitraum 02/2024–03/2025. Die Prüfung offenbarte Schmerzpunkte, die GitCover-Techniken adressieren.

Timeline der SV-Prüfung

Was geschah?

Finanzielles Ergebnis (netto)

Schmerzpunkte - was die Prüfung offenbarte

1. Kein Bürobetrieb, kein Fax, kein Mitarbeiter - und trotzdem eine Betriebsprüfung rein per E-Mail mit PDF- und ZIP-Dateien abwickeln müssen. Die Werkzeuge existierten nicht für diesen Kleinstfall.
2. Beleg-Echtheit unklar - PDFs per E-Mail haben keine kryptographische Verankerung. Wer hat wann was geändert? Die Beweiskraft war nur durch manuelle Nachvollziehbarkeit gegeben.
3. Keine durchgängige Nachweiskette - Lohnkonten, SV-Meldungen, Beitragsnachweise und Erstattungsbelege lagen an verschiedenen Orten, ohne Querverweise. Jede Rückfrage erforderte erneute Suche.
4. Fristen-Management ad-hoc - Anhörungsfristen, Erstattungsfristen, Widerspruchsfristen wurden manuell im Kalender gepflegt. Keine Warnung bei drohendem Verstreichen.
5. Audit-Export fehlte - die DRV forderte Daten im euBP-Format (eXTra V3.4.0); das FA hätte einen Z3-Datenträger verlangt. Beides war nur mit Spezialsoftware oder manueller Aufbereitung möglich.
6. Ausscheiden des Mitarbeiters → Lohn-Account pausiert - nach dem Ausscheiden des damaligen Mitarbeiters wurde das Lohn-Abrechnungs-Account beim Dienstleister pausiert. Wer hält unnütz ein Cloud-Account kostenverursachend aufrecht, wenn der Grund nicht mehr vorhanden ist (Arbeitnehmer ausgeschieden, keine Abrechnungen mehr nötig)? Die Zusammenstellung des Unterlagenpakets für die Prüfung erforderte dann aber zusätzliche Extra-Kosten beim Dienstleister, die am Ende höher waren als die kleine "Erstattung" am Ende der Prüfung.
7. Reaktivierung alter Sicherungen mit altem Software-Stand - um die Lohnkonten 2021–2023 wieder zugänglich zu machen, mussten die alten Sicherungen mit dem alten Software-Stand reaktiviert werden - ein erhebliches praktisches Problem. Das ist formal ein Regelverstoß gegen die GoBD-Auflage, auch technisch dafür zu sorgen, dass in der langen Aufbewahrungszeit (10 Jahre) immer zugegriffen werden kann. In der Praxis steht diese Pflicht im Konflikt mit dem betriebswirtschaftlichen Druck, ungenutzte Cloud-Accounts nicht kostenverursachend aufrechtzuerhalten. Genau diese Spannung ist ein Kernmotiv für GitCover: Git-Bundles sind self-contained - sie brauchen keine Cloud-Accounts, keine Dienstleister-Verträge, keine Software-Stände. Ein git clone reicht, und die Aufbewahrungsfrist ist technisch erfüllt.

Rechtsgrundlagen: AO § 146, § 147 und GoBD

Der in Punkt 7 angesprochene "Regelverstoß gegen die GoBD-Auflage" hat eine klare rechtliche Grundlage - in der Abgabenordnung (AO) und in den GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff, BMF-Schreiben).

AO § 146 Abs. 5 - Verfügbarkeit während der Aufbewahrungsfrist

"Bei der Führung der Bücher und der sonst erforderlichen Aufzeichnungen auf Datenträgern muss insbesondere sichergestellt sein, dass während der Dauer der Aufbewahrungsfrist die Daten jederzeit verfügbar sind und unverzüglich lesbar gemacht werden können."

Das ist die Kernvorschrift: Wer elektronisch bucht, muss während der gesamten Aufbewahrungsfrist (10 Jahre für Bücher/Aufzeichnungen, 8 Jahre für Buchungsbelege, § 147 Abs. 3 AO) sicherstellen, dass die Daten jederzeit verfügbar und unverzüglich lesbar sind. Ein pausiertes Cloud-Account, das nur gegen Extra-Kosten reaktiviert wird, verletzt diese Pflicht - die Daten sind nicht "jederzeit verfügbar", sondern nur gegen Zahlung und mit Verzögerung.

AO § 147 Abs. 2 - Aufbewahrung auf Datenträgern

"Mit Ausnahme der Jahresabschlüsse [...] können die in Absatz 1 aufgeführten Unterlagen auch als Wiedergabe auf einem Bildträger oder auf anderen Datenträgern aufbewahrt werden, wenn dies den Grundsätzen ordnungsmäßiger Buchführung entspricht und sichergestellt ist, dass die Wiedergabe oder die Daten [...] während der Dauer der Aufbewahrungsfrist jederzeit verfügbar sind, unverzüglich lesbar gemacht und maschinell ausgewertet werden können."

Wieder: "jederzeit verfügbar", "unverzüglich lesbar", "maschinell auswertbar". Eine alte Software-Version, die erst reaktiviert werden muss, erfüllt "unverzüglich" nicht.

AO § 147 Abs. 5 - Hilfsmittel auf Kosten des Steuerpflichtigen

"Wer aufzubewahrende Unterlagen in der Form einer Wiedergabe auf einem Bildträger oder auf anderen Datenträgern vorlegt, ist verpflichtet, auf seine Kosten diejenigen Hilfsmittel zur Verfügung zu stellen, die erforderlich sind, um die Unterlagen lesbar zu machen."

Das bedeutet: Wenn der Dienstleister das alte System nicht mehr vorhält, muss der Unternehmer selbst die Hilfsmittel (Software, Lizenzen, Hardware) stellen, um die Daten lesbar zu machen. Genau das war das praktische Problem im Genese-Fall: alte Sicherungen, alter Software-Stand, keine Hilfsmittel mehr verfügbar.

AO § 147 Abs. 6 - Datenzugriff bei Außenprüfung

"Sind die Unterlagen nach Absatz 1 mit Hilfe eines Datenverarbeitungssystems erstellt worden, kann die Finanzbehörde im Rahmen einer Außenprüfung [...] verlangen, dass die Daten nach ihren Vorgaben maschinell ausgewertet zur Verfügung gestellt werden."

Bei einer Außenprüfung muss der Unternehmer die Daten maschinell auswertbar zur Verfügung stellen - nicht als PDF-Ausdruck, sondern als strukturierte Daten. Ein pausiertes Cloud-Account, das nur PDF-Export anbietet, reicht nicht.

GoBD - Verfahrensdokumentation und Systemwechsel

Die GoBD konkretisieren diese AO-Vorschriften für elektronische Systeme. Zentrale Anforderungen:

• Verfahrensdokumentation (GoBD Rz. 64–91): Jedes elektronische Buchführungssystem muss eine Verfahrensdokumentation haben, die das Verfahren, die Systemumgebung, die organisatorischen Maßnahmen und die internen Kontrollen beschreibt. Bei Systemwechsel muss die Verfahrensdokumentation fortgeschrieben werden.
• Systemwechsel/Migration (GoBD Rz. 146–150): Bei einem Systemwechsel muss sichergestellt werden, dass die Daten des alten Systems weiterhin verfügbar, lesbar und maschinell auswertbar bleiben. Die Verfahrensdokumentation muss den Wechsel dokumentieren.
• Unveränderbarkeit (GoBD Rz. 146): Nach der Buchung dürfen die Daten nicht verändert werden. Korrekturen müssen als neue Einträge mit Begründung erfolgen.

Theoretische Konsequenzen bei Verstoß

Praxis-Einordnung: Im Genese-Fall wurde die SV-Prüfung ohne Einwände akzeptiert - es kam zu keiner Konsequenz. Aber das war Glück: Hätte die DRV die Daten nicht als PDF akzeptiert, sondern auf maschineller Auswertung bestanden (§ 147 Abs. 6 AO), wäre der Unternehmer in Erklärungsnot geraten. Die GoBD-konforme Aufbewahrung ist keine theoretische Pflicht - sie wird bei jeder Außenprüfung real.

Warum Git das Problem löst

Git erfüllt die AO/GoBD-Anforderungen by Design:

E-Rechnung: XML-Formate sind Ur-Dokumente in der AO

Seit dem 1. Januar 2025 ist die E-Rechnung für Umsätze zwischen inländischen Unternehmen verpflichtend (§ 14 UStG, Wachstumschancengesetz). Eine E-Rechnung liegt nur dann vor, wenn sie in einem strukturierten elektronischen Format ausgestellt, übermittelt und empfangen wird und eine elektronische Verarbeitung ermöglicht (§ 14 Abs. 1 Satz 3 UStG). Ein einfaches PDF-Dokument fällt nicht mehr darunter - es ist seit 2025 eine "sonstige Rechnung".

XML ist das Ur-Dokument - nicht das PDF

Der entscheidende Punkt für die Aufbewahrung: Bei einer E-Rechnung ist der strukturierte Teil (XML) das Ur-Dokument im Sinne der AO, nicht ein eventuell beigefügtes PDF oder ein menschenlesbares Bild. Das BMF stellt klar (FAQ zur E-Rechnung, Frage 13):

"Bei einer E-Rechnung ist zumindest deren strukturierter Teil so aufzubewahren, dass er unversehrt in seiner ursprünglichen Form vorliegt."

Das bedeutet:

• XRechnung (XML-basiert, EN 16931): Die XML-Datei ist das Ur-Dokument. Sie muss unverändert aufbewahrt werden. Eine PDF-Visualisierung ist nur eine Hilfsanzeige - sie ersetzt nicht das XML.
• ZUGFeRD (hybrid: PDF + eingebettetes XML): Bei Abweichungen zwischen XML-Teil und Bildteil ist seit 2025 der strukturierte (XML-)Teil maßgebend (BMF FAQ Frage 12a). Das PDF-Bild ist nicht mehr führend.

AO § 147 - E-Rechnung als Buchungsbeleg

E-Rechnungen sind Buchungsbelege im Sinne des § 147 Abs. 1 Nr. 4 AO und damit acht Jahre aufzubewahren (§ 147 Abs. 3 AO). Als elektronische Unterlagen gelten die AO/GoBD-Anforderungen:

• Jederzeit verfügbar (§ 147 Abs. 2): Die XML-Datei muss während der gesamten Aufbewahrungsfrist zugänglich sein.
• Unverzüglich lesbar (§ 147 Abs. 2): Ein XML-Viewer oder ELSTER-E-Rechnungsviewer (www.e-rechnung.elster.de) macht die Datei lesbar - aber das XML selbst ist Klartext und damit auch ohne Spezialsoftware lesbar.
• Maschinell auswertbar (§ 147 Abs. 6): XML ist per Definition maschinenlesbar - ideal für § 147 Abs. 6 (Datenzugriff bei Außenprüfung).
• Unversehrt (§ 14b Abs. 1 UStG): Die XML-Datei darf nicht verändert werden. Git erfüllt das durch Unveränderbarkeit nach Commit (SHA-256-Hash).

EU-weite Vorschriften: EN 16931 und Richtlinie 2014/55/EU

Die E-Rechnung beruht auf EU-Recht:

• Richtlinie 2014/55/EU - verpflichtet öffentliche Auftraggeber zum Empfang und zur Verarbeitung elektronischer Rechnungen (B2G).
• EN 16931 (Europäische Normenreihe) - definiert das semantische Datenmodell für E-Rechnungen (CEN/TC 434). XRechnung und ZUGFeRD sind nationale Umsetzungen dieser EN-Norm.
• ViDA (VAT in the Digital Age) - geplante EU-weite Ausweitung der E-Rechnungspflicht und Einführung eines Meldesystems für Transaktionsdaten. Die deutsche E-Rechnungspflicht bereitet ViDA vor.

Warum Git ideal für E-Rechnungen ist

Praxis-Tipp: Ein Git-Repo kann E-Rechnungen (XML) und sonstige Rechnungen (PDF) parallel aufbewahren - mit klarer Trennung durch Beleg-Typ im Sidecar (v7g_taxonomy). Der Pre-Commit-Hook prüft, ob E-Rechnungen eine gültige XML-Struktur haben (XRechnung/ZUGFeRD-Schema). So wird die Übergangsfrist 2025–2027 ohne Medienbruch überbrückt.

Direkte Ableitungen in GitCover

Hinweis - Kleinstunternehmer-Pflichten ab 1. Mitarbeiter: Oft selbst Kleinstunternehmer unterliegen bereits ab dem 1. Mitarbeiter solchen Pflichten - Arbeitszeit-Erfassung (ArbZG), Mindestlohn-Dokumentation (MiLoG), Urlaub/Krank/BEM (BUrlG/EFZG/SGB IX), Sozialversicherungs-Anmeldung (SGB IV). Die in Teil IV behandelten Pflichten ab 1. Mitarbeiter sind also keine Großunternehmen-Sonderthemen, sondern treffen gerade auf Kleinst- und Kleinbetriebe zu, die erstmals Personal aufnehmen. GitCover richtet sich bewusst an diese Schwelle - der Übergang vom Solo-Unternehmer zum Arbeitgeber ist der kritische Moment, in dem Compliance-Pflichten sprunghaft ansteigen. Pflichten ab Gewerbeanmeldung (Sphären-Einordnung, VBG-Freistellung, Pauschalen) werden bereits in Teil II behandelt - sie entstehen ohne Mitarbeiter.

Warum Git als Tagebuch-Medium?

Git ist ursprünglich ein Versionskontrollsystem - aber es bringt drei Eigenschaften mit, die es by Design für Compliance geeignet machen:

1. Unveränderbarkeit nach Freigabe - Tags und Protected Branches garantieren, dass freigegebene Tagebucheinträge nicht nachträglich geändert werden (GoBD Rz. 146). Korrekturen erfolgen als neue Commits mit Obsoleszenz-Markierung.
2. Nachvollziehbarkeit - jeder Commit trägt Autor, Zeitstempel und kryptographische Integrität. Die gesamte Historie ist reproduzierbar.
3. Dezentralität - Git-Bundles und GCEP (Advisory Locks) erlauben verteilte Ablage (Multi-Site, Off-Site-Backup) ohne zentralen Single-Point-of-Failure.

Compliance by Design - die GitCover-Techniken

Die Serie zeigt, wie folgende Techniken das "unklare Bild" künftiger Risiken von Anfang an mindern:

• OSCAL - maschinenlesbare Compliance-Statements (Zertifizierungsreife für ISO 27001, AI Act, BSI GS++)
• OPA/Rego - Policy as Code, automatisierte Richtlinienprüfung (Sphären-Trennung, Fristen, Beitragsgruppen-Plausibilität)
• V7GUID Uniqueness - zeitstabile, eindeutige Identifikatoren jenseits von Dateinamen (UUIDv7-basiert, sortierbar, kollisionsfrei)
• Git-Hooks (funktional/sachlich dediziert) - Pre-Commit prüft Sphären-Trennung, Schema-Konformität, Obsoleszenz-Status; Post-Commit generiert Indices und aktualisiert Fristen
• Code-Artefact-Typen und Einträge - JSON-Schema-First, Sidecar-Pflicht, temporale Signatur {YYMMDD HHmm}, SHA-256-Belegreferenzen

Kernprinzip der temporalen Nachvollziehbarkeit: Die Erfassungszeit ist kein separates Feld, sondern in der uuidV7 selbst verankert, als 48-Bit-Zeitstempel gemäß RFC 9562 §5.7. Die uuidV7 wird aus einer vorgegebenen Zeitmarke (nicht now()) via GitCover Helper (UuidV7Gen) generiert, der Rest mit Zufall aufgefüllt. Damit ist die Erfassungszeit kryptographisch mit der Identität des Artefakts verknüpft und nicht nachträglich änderbar. Eine separate datetime/date-String-Darstellung ist redundant und wird nicht in den Fakten geführt - String-Darstellung für DTO/HTMX ist Harness-Verantwortung.

RFC-Bezug: Die 48-Bit-Zeitstempel-Komponente der uuidV7 entspricht RFC 9562 §5.7 (UUIDv7) - Unix-Millisekunden seit Epoch (1970-01-01T00:00:00Z), 48 Bit, Wertebereich 0 … 2⁴⁸−1 (Reichweite bis ca. Jahr 10889). Die V7GUID-Spezifikation ist in work/OSS/TOP/.gitcover/specs/v7guid/ normativ abgelegt; das zugehörige Patent ist DPMA Az. 10 2025 003 091.6.

Helper-Routinen (GitCover OSS Tools): In work/OSS/TOP/tools/UuidV7Gen/ befindet sich ein OSS-Helper, der zwei zentrale Operationen bereitstellt:

• gen - erzeugt eine uuidV7 via Guid.CreateVersion7() (.NET) mit vorgegebener Zeitmarke (nicht now()) und gibt Label, UUID und dekodierten ISO-Zeitstempel zurück.
• decode - extrahiert die 48-Bit-Zeitstempel-Komponente aus einer gegebenen uuidV7 und gibt sie als ISO-8601-Zeitstempel zurück.

Diese Helper sind entscheidend, um aus Fremd-Keys (z. B. eine Zeitmarke in den Daten oder im Dateinamen) einen gültigen uuidV7-Schlüssel zu erstellen - und gleichzeitig die temporalen Anforderungen der GoBD (zeitnahe Erfassung, Nachvollziehbarkeit der Erfassungszeit) zu dokumentieren. Der 48-Bit-Wert ist der einzige Faktor der TenantId-Ableitung und kann statt der Systemzeit auch ein explizit vorgegebener Zeitpunkt sein (z. B. Gründungsdatum eines Tenants) - die Interpretation folgt der Verfahrensdokumentation.

Sidecar-Prinzip (.v7g.md): Jeder Sidecar trägt einen Composite Key V7GUID:uuidV7:

• V7GUID (Class Identifier) - klassifiziert den Sidecar anhand der .gitcover Registry (was/welcher Typ)
• uuidV7 (Object ID) - Identität des Sidecars selbst, generiert mit vorgegebener Zeitmarke (wann wurde klassifiziert?), 48-Bit-Zeitstempel in der GUID verankert
• v7g_taxonomy[].v7guid - Object ID des klassifizierten Dokuments

So ist nicht nur das Dokument eindeutig identifiziert, sondern auch der Klassifizierungsakt selbst - inklusive Zeitpunkt (in uuidV7), wer klassifiziert hat und in welcher Rolle. Kein separates datetime-Feld.

Risiko-Leverage - was heute preiswert (cheap) ist, morgen revisionssicher wird

Risiko-Leverage: Heute mit minimalen Kosten (Minuten) erfasste Fakten werden zu künftigen revisionssicheren Nachweisen (Stunden Prüfung). Der Unternehmer "hebt" eine Beweislast-Position - Compliance als Hebel.

Was diese Serie zeigt

Die Serie folgt einem fiktiven Unternehmer (E1), der eine Organisation KMU (Platzhalter, rechtsformoffen) führt und sein Tagebuch in einem Git-Repo führt. Die Struktur lehnt sich an ein reales SSoT-Konzept an, ist aber vollständig anonymisiert - alle Personen-, Firmen-, HRB-, IBAN-, Steuernummer-Daten werden durch Platzhalter ersetzt.

DSGVO-Hinweis: Alle Personen-/Firmenbezüge in dieser Serie sind fiktiv oder anonymisiert. Ähnlichkeiten mit realen Organisationen sind zufällig und nicht beabsichtigt.

Vorschau auf die Serie

Harness-Anforderung (Vorschau)

Aus ED01 ableitbar:

Die vollständige Anforderungsliste in Harness-Anforderungen.md.

Quellen

• Genese-Beleg SV-Prüfung (anonymisiert): AFJD/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md Abschnitt J
• GoBD (BMF-Schreiben vom 28.11.2019, BStBl I S. 1269, zuletzt geändert 14.07.2025, BStBl I S. 1502)
• AO (§§ 146, 147, 152, 162, 370, 379)
• SGB IV (§ 28p - Betriebsprüfung)
• UStG (§ 14 - E-Rechnung, § 14b - Aufbewahrung)
• BMF-FAQ zur E-Rechnung (Stand März 2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
• EN 16931 (Europäische Normenreihe, CEN/TC 434)
• Richtlinie 2014/55/EU (E-Rechnung B2G)
• RFC 9562 §5.7 (UUIDv7) - 48-Bit Unix-ms-Zeitstempel
• V7GUID-Spezifikation - work/OSS/TOP/.gitcover/specs/v7guid/ (normativ)
• DPMA Az. 10 2025 003 091.6 - V7GUID-Patent (Hauptanspruch 2, Ansprüche 5–8)
• GitCover OSS Tool UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (Helper-Routinen gen/decode)
• DSGVO (Anonymisierungspflicht bei Publikation)

Quellen-Topologie und CDN-Referenz-Links

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 unter git.gitcover.org/GCC für den aktuellen Stand. kanonische Quelle auf gitcover.org für den aktuellen Zustand.