ED01 - Motivation: Why an entrepreneur keeps their diary in Git

Problem

An entrepreneur founds an organization - and faces an unclear picture of future risks. Which obligations arise when? Which records must be retained for how long? Which deadlines are at risk of being missed? Which authorities announce themselves for which audit and when?

Today's practice in the SME sector is characterized by:

• Paper chaos and local Excel lists - not traceable, not audit-proof
• PDF and email chaos during audits - documents are assembled ad hoc
• Isolated solutions (payroll software here, accounting there, document archive elsewhere) - without a continuous chain of evidence
• Open-source gaps for special obligations (FZul/BSFZ, non-profit status, working time, BEM) - there is virtually no free support here
• Risk backlog - obligations are ignored today as cheap, until they become expensive tomorrow as fines, late surcharges or revocations

Core message

Not only documents must be audit-proof - decisions, deadlines and record references must also be traceable, reproducible and auditable. A Git-native diary does exactly that: it transforms facts captured today cheap (inexpensively) (a JSON entry with V7GUID + SHA-256 record reference) into future audit-proof evidence. Compliance becomes a lever, not a brake.

Compliance by Design: The "unclear picture" of future risks is mitigated from the very beginning through GitCover techniques (OSCAL, OPA, V7GUID, Git hooks), not only when the auditor knocks.

Genesis: The SV audit as a practical trigger

The GitCover idea was not born in an ivory tower, but from concrete practical experience: most recently from a SV audit at a micro-UG (anonymized here as ORG-V for "predecessor organization") for the period 2021-2023; took place in the period 02/2024-03/2025. The audit revealed pain points that GitCover techniques address.

Timeline of the SV audit

What happened?

Financial result (net)

Pain points - what the audit revealed

1. No office operation, no fax, no employee - and still had to handle an audit purely via email with PDF and ZIP files. The tools did not exist for this micro-case.
2. Record authenticity unclear - PDFs via email have no cryptographic anchoring. Who changed what and when? The evidentiary value was only given through manual traceability.
3. No continuous chain of evidence - payroll accounts, SV reports, contribution proofs and refund records were stored in different places, without cross-references. Every inquiry required renewed search.
4. Deadline management ad hoc - hearing deadlines, refund deadlines, objection deadlines were maintained manually in the calendar. No warning when deadlines were at risk of expiring.
5. Audit export missing - the DRV requested data in euBP format (eXTra V3.4.0); the FA would have required a Z3 data carrier. Both were only possible with special software or manual preparation.
6. Departure of the employee → payroll account paused - after the departure of the then employee, the payroll accounting account with the service provider was paused. Who keeps a cloud account pointlessly incurring costs when the reason no longer exists (employee departed, no more payroll necessary)? However, assembling the document package for the audit then required additional extra costs from the service provider, which in the end were higher than the small "refund" at the end of the audit.
7. Reactivation of old backups with old software version - to make the payroll accounts 2021-2023 accessible again, the old backups had to be reactivated with the old software version - a significant practical problem. This is formally a rule violation against the GoBD requirement, also technically ensuring that access is always possible during the long retention period (10 years). In practice, this obligation conflicts with the business pressure not to keep unused cloud accounts incurring costs. This tension is a core motive for GitCover: Git bundles are self-contained - they do not need cloud accounts, no service provider contracts, no software versions. A git clone is sufficient, and the retention obligation is technically fulfilled.

Legal basis: AO § 146, § 147 and GoBD

The "rule violation against the GoBD requirement" mentioned in point 7 has a clear legal basis - in the Abgabenordnung (AO) and in the GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff, BMF letter).

AO § 146 Abs. 5 - Availability during the retention period

"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."

This is the core provision: anyone who keeps electronic books must ensure during the entire retention period (10 years for books/records, 8 years for booking records, § 147 Abs. 3 AO) that the data is available at any time and immediately readable. A paused cloud account that is only reactivated for extra costs violates this obligation - the data is not "available at any time", but only against payment and with delay.

AO § 147 Abs. 2 - Retention on data carriers

"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."

Again: "available at any time", "immediately readable", "machine-evaluable". An old software version that first has to be reactivated does not fulfill "immediately".

AO § 147 Abs. 5 - Aids at the taxpayer's expense

"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."

This means: if the service provider no longer maintains the old system, the entrepreneur must themselves provide the aids (software, licenses, hardware) to make the data readable. That was exactly the practical problem in the genesis case: old backups, old software version, no aids available anymore.

AO § 147 Abs. 6 - Data access during field audit

"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."

During a field audit, the entrepreneur must make the data available in machine-evaluable form - not as a PDF printout, but as structured data. A paused cloud account that only offers PDF export is not sufficient.

GoBD - procedural documentation and system change

The GoBD concretize these AO provisions for electronic systems. Central requirements:

• Procedural documentation (GoBD Rz. 64-91): Every electronic accounting system must have a procedural documentation that describes the procedure, the system environment, the organizational measures and the internal controls. In case of system change, the procedural documentation must be updated.
• System change/migration (GoBD Rz. 146-150): In case of a system change, it must be ensured that the data of the old system remains available, readable and machine-evaluable. The procedural documentation must document the change.
• Immutability (GoBD Rz. 146): After booking, the data must not be changed. Corrections must be made as new entries with justification.

Theoretical consequences in case of violation

Practical assessment: In the genesis case, the SV audit was accepted without objections - there were no consequences. But that was luck: had the DRV not accepted the data as PDF, but insisted on machine evaluation (§ 147 Abs. 6 AO), the entrepreneur would have been in explanatory difficulties. GoBD-compliant retention is not a theoretical obligation - it becomes real during every field audit.

Why Git solves the problem

Git fulfills the AO/GoBD requirements by design:

E-invoice: XML formats are original documents in the AO

Since 1 January 2025, the e-invoice is mandatory for transactions between domestic companies (§ 14 UStG, Wachstumschancengesetz). An e-invoice only exists if it is issued, transmitted and received in a structured electronic format and enables electronic processing (§ 14 Abs. 1 sentence 3 UStG). A simple PDF document no longer falls under this - since 2025 it is an "other invoice".

XML is the original document - not the PDF

The decisive point for retention: For an e-invoice, the structured part (XML) is the original document within the meaning of the AO, not any attached PDF or a human-readable image. The BMF clarifies (FAQ on e-invoices, question 13):

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

This means:

• XRechnung (XML-based, EN 16931): The XML file is the original document. It must be retained unchanged. A PDF visualization is only an auxiliary display - it does not replace the XML.
• ZUGFeRD (hybrid: PDF + embedded XML): In case of deviations between the XML part and the image part, the structured (XML) part is authoritative since 2025 (BMF FAQ question 12a). The PDF image is no longer leading.

AO § 147 - E-invoice as booking record

E-invoices are booking records within the meaning of § 147 Abs. 1 Nr. 4 AO and therefore must be retained for eight years (§ 147 Abs. 3 AO). As electronic records, the AO/GoBD requirements apply:

• Available at any time (§ 147 Abs. 2): The XML file must be accessible during the entire retention period.
• Immediately readable (§ 147 Abs. 2): An XML viewer or ELSTER e-invoice viewer (www.e-rechnung.elster.de) makes the file readable - but the XML itself is plain text and therefore also readable without special software.
• Machine-evaluable (§ 147 Abs. 6): XML is by definition machine-readable
  • ideal for § 147 Abs. 6 (data access during field audit).
• Intact (§ 14b Abs. 1 UStG): The XML file must not be changed. Git fulfills this through immutability after commit (SHA-256 hash).

EU-wide regulations: EN 16931 and Directive 2014/55/EU

The e-invoice is based on EU law:

• Directive 2014/55/EU - obliges public contracting authorities to receive and process electronic invoices (B2G).
• EN 16931 (European standards series) - defines the semantic data model for e-invoices (CEN/TC 434). XRechnung and ZUGFeRD are national implementations of this EN standard.
• ViDA (VAT in the Digital Age) - planned EU-wide expansion of the e-invoice obligation and introduction of a reporting system for transaction data. The German e-invoice obligation prepares for ViDA.

Why Git is ideal for e-invoices

Practical tip: A Git repo can retain e-invoices (XML) and other invoices (PDF) in parallel - with clear separation by record type in the sidecar (v7g_taxonomy). The pre-commit hook checks whether e-invoices have a valid XML structure (XRechnung/ZUGFeRD schema). This bridges the transition period 2025-2027 without media discontinuity.

Direct derivations in GitCover

Note - micro-entrepreneur obligations from the 1st employee: Even micro-entrepreneurs are often subject to such obligations from the 1st employee - working time recording (ArbZG), minimum wage documentation (MiLoG), vacation/sickness/BEM (BUrlG/EFZG/SGB IX), social insurance registration (SGB IV). The obligations from the 1st employee covered in Part IV are therefore not large enterprise special topics, but apply precisely to micro and small businesses that hire staff for the first time. GitCover deliberately targets this threshold - the transition from solo entrepreneur to employer is the critical moment when compliance obligations increase sharply. Obligations from business registration (sphere classification, VBG exemption, flat rates) are already covered in Part II - they arise without employees.

Why Git as a diary medium?

Git is originally a version control system - but it brings three properties that make it by design suitable for compliance:

1. Immutability after release - Tags and Protected Branches guarantee that released diary entries are not subsequently changed (GoBD Rz. 146). Corrections are made as new commits with obsolescence marking.
2. Traceability - every commit carries author, timestamp and cryptographic integrity. The entire history is reproducible.
3. Decentralization - Git bundles and GCEP (Advisory Locks) allow distributed storage (Multi-Site, Off-Site backup) without a central Single-Point-of-Failure.

Compliance by Design - the GitCover techniques

The series shows how the following techniques mitigate the "unclear picture" of future risks from the very beginning:

• OSCAL - machine-readable compliance statements (certification readiness for ISO 27001, AI Act, BSI GS++)
• OPA/Rego - Policy as Code, automated policy checking (sphere separation, deadlines, contribution group plausibility)
• V7GUID Uniqueness - time-stable, unique identifiers beyond file names (UUIDv7-based, sortable, collision-free)
• Git hooks (functional/substantively dedicated) - Pre-Commit checks sphere separation, schema conformity, obsolescence status; Post-Commit generates indices and updates deadlines
• Code-Artefact types and entries - JSON-Schema-First, sidecar obligation, temporal signature {YYMMDD HHmm}, SHA-256 record references

Core principle of temporal traceability: The capture time is not a separate field, but is anchored in the uuidV7 itself, as a 48-bit timestamp according to RFC 9562 §5.7. The uuidV7 is generated from a specified time marker (not now()) via GitCover Helper (UuidV7Gen), the rest is filled with randomness. This links the capture time cryptographically to the identity of the artifact and makes it non-modifiable after the fact. A separate datetime/date string representation is redundant and is not kept in the facts - string representation for DTO/HTMX is harness responsibility.

RFC reference: The 48-bit timestamp component of the uuidV7 corresponds to RFC 9562 §5.7 (UUIDv7) - Unix milliseconds since epoch (1970-01-01T00:00:00Z), 48 bit, value range 0 … 2⁴⁸−1 (range up to approx. year 10889). The V7GUID specification is normatively stored in work/OSS/TOP/.gitcover/specs/v7guid/; the associated patent is DPMA Az. 10 2025 003 091.6.

Helper routines (GitCover OSS Tools): In work/OSS/TOP/tools/UuidV7Gen/ there is an OSS helper that provides two central operations:

• gen - generates a uuidV7 via Guid.CreateVersion7() (.NET) with specified time marker (not now()) and returns label, UUID and decoded ISO timestamp.
• decode - extracts the 48-bit timestamp component from a given uuidV7 and returns it as an ISO-8601 timestamp.

These helpers are crucial for creating a valid uuidV7 key from foreign keys (e.g. a time marker in the data or in the file name) - and at the same time documenting the temporal requirements of the GoBD (timely capture, traceability of capture time). The 48-bit value is the sole factor of TenantId derivation and can be an explicitly specified point in time instead of the system time (e.g. founding date of a tenant)

• the interpretation follows the procedural documentation.

Sidecar principle (.v7g.md): Every sidecar carries a Composite Key V7GUID:uuidV7:

• V7GUID (Class Identifier) - classifies the sidecar based on the .gitcover registry (what/which type)
• uuidV7 (Object ID) - identity of the sidecar itself, generated with specified time marker (when was it classified?), 48-bit timestamp anchored in the GUID
• v7g_taxonomy[].v7guid - Object ID of the classified document

This means not only the document is uniquely identified, but also the classification act itself - including time (in uuidV7), who classified and in which role. No separate datetime field.

Risk leverage - what is inexpensive (cheap) today becomes audit-proof tomorrow

Risk leverage: Facts captured today with minimal cost (minutes) become future audit-proof evidence (hours of audit). The entrepreneur "leverages" a burden-of-proof position - compliance as a lever.

What this series shows

The series follows a fictional entrepreneur (E1) who runs an organization KMU (placeholder, legal-form-open) and keeps their diary in a Git repo. The structure is based on a real SSoT concept, but is fully anonymized - all personal, company, HRB, IBAN, tax number data are replaced by placeholders.

GDPR notice: All personal/company references in this series are fictional or anonymized. Similarities to real organizations are coincidental and not intended.

Preview of the series

Harness requirement (preview)

Derivable from ED01:

The complete requirements list in Harness-Anforderungen.md.

Sources

• Genesis record SV audit (anonymized): AFJD/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md section J
• GoBD (BMF letter dated 28.11.2019, BStBl I S. 1269, last changed 14.07.2025, BStBl I S. 1502)
• AO (§§ 146, 147, 152, 162, 370, 379)
• SGB IV (§ 28p - audit)
• UStG (§ 14 - e-invoice, § 14b - retention)
• BMF FAQ on e-invoices (as of March 2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
• EN 16931 (European standards series, CEN/TC 434)
• Directive 2014/55/EU (e-invoice B2G)
• RFC 9562 §5.7 (UUIDv7) - 48-bit Unix-ms timestamp
• V7GUID specification - work/OSS/TOP/.gitcover/specs/v7guid/ (normative)
• DPMA Az. 10 2025 003 091.6 - V7GUID patent (main claim 2, claims 5-8)
• GitCover OSS Tool UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (helper routines gen/decode)
• GDPR (anonymization obligation upon publication)

Source topology and CDN reference links

Note: This assignment of sources, mirror and community hub reflects the current state and may change. Please check the respective canonical source at git.gitcover.org/GCC for the current state.