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 which audit 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 compiled ad hoc
• isolated solutions (payroll software here, accounting there, record archive elsewhere) - without an end-to-end chain of evidence
• open-source gaps for special obligations (working time, travel expenses, allowances, BEM, FZul/BSFZ, nonprofit status) - there is virtually no free support here
• risk backlog - obligations are ignored cheaply today until they become expensive tomorrow as fines, late payment surcharges or revocations

Key statement

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 cheaply (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 by GitCover techniques (OSCAL, OPA, V7GUID, Git hooks) from the outset, not only when the auditor rings the doorbell.

The diary as an entrepreneurial work agenda

The diary is not a private notebook and not a retrospectively maintained working time calendar. It is the temporal SSoT of work: The agenda shows which service, decision or clarification arose when and to which record, contract or process it traces back. As a result, the same proof of work can serve different purposes without building a new story for each audit:

• BSFZ/FZulG: R&D projects, service time and delineation are documented promptly.
• FA/EStG/EÜR: business causation and private/business shares remain traceable.
• USt: service period, contract performance and invoice reference can be linked.
• GoBD/AO: record, decision, approval and change form a retrograde/progressive chain.
• Risk and portability: The business does not depend on one person's memory or on a vendor portal; the facts are in open, versioned Git artifacts.

The rule is simple: The diary describes the agenda; the repositories preserve the proof. An agent may derive from the diary only what the linked original docs and sidecars support. Thus compliance is not treated as later additional work, but as a normal workflow.

Genesis: The social insurance audit as a practical trigger

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

Timeline of the social insurance audit

What happened?

Financial result (net)

Pain points - what the audit revealed

1. No office operation, no fax, no employee - and nevertheless a company audit had to be handled purely by email with PDF and ZIP files. The tools did not exist for this micro case.
2. Record authenticity unclear - PDFs by email have no cryptographic anchoring. Who changed what and when? Evidentiary value was given only through manual traceability.
3. No end-to-end chain of evidence - payroll accounts, social insurance notifications, contribution records and refund documents were in different places, without cross-references. Every follow-up question required a new search.
4. Deadline management ad hoc - hearing deadlines, refund deadlines, objection deadlines were maintained manually in the calendar. No warning when they were about to expire.
5. Audit export was missing - the DRV requested data in euBP format (eXTra V3.4.0); the tax office would have required a Z3 data carrier. Both were possible only with special software or manual preparation.
6. Employee departure → payroll account paused - after the departure of the then employee, the payroll accounting account at the service provider was paused. Who would unnecessarily keep a cloud account running at cost when the reason no longer exists (employee left, no more payroll accounting needed)? However, compiling the document package for the audit then required additional extra costs at 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 an 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 considerable practical problem. Formally, this is a rule violation against the GoBD requirement to also technically ensure 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 running at cost. Precisely this tension is a core motive for GitCover: Git bundles are self-contained - they need no cloud accounts, no service provider contracts, no software versions. A git clone is enough, and the retention period is technically fulfilled.

Legal bases: AO § 146, § 147 and GoBD

The "rule violation against the GoBD requirement" mentioned in point 7 has a clear legal basis - in the Fiscal Code (AO) and in the GoBD (Principles for the proper keeping and retention of books, records and documents in electronic form and for data access, BMF letter).

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

"When books and other required records are kept on data carriers, it must in particular be ensured that during the retention period the data are available at all times and can be made readable without delay."

This is the core provision: Anyone who books electronically must ensure, throughout the entire retention period (10 years for books/records, 8 years for accounting records, § 147 Abs. 3 AO), that the data are available at all times and readable without delay. A paused cloud account that is reactivated only against extra costs violates this obligation - the data are not "available at all times", but only against payment and with delay.

AO § 147 Abs. 2 - Retention on data carriers

"With the exception of annual financial statements [...] the documents listed in paragraph 1 may also be retained as a reproduction on an image carrier or on other data carriers if this complies with the principles of proper bookkeeping and it is ensured that the reproduction or the data [...] are available at all times during the retention period, can be made readable without delay and can be evaluated by machine."

Again: "available at all times", "readable without delay", "machine-evaluable". An old software version that first has to be reactivated does not fulfill "without delay".

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

"Anyone who presents documents to be retained in the form of a reproduction on an image carrier or on other data carriers is obliged to provide, at their own expense, the aids that are necessary to make the documents readable."

This means: If the service provider no longer maintains the old system, the entrepreneur must provide the aids (software, licenses, hardware) themselves in order 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 external audit

"If the documents referred to in paragraph 1 were created with the help of a data processing system, the tax authority may, in the context of an external audit [...] require that the data be made available for machine evaluation in accordance with its specifications."

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

GoBD - Procedural documentation and system change

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

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

Theoretical consequences of violation

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

Why Git solves the problem

Git fulfills the AO/GoBD requirements by design:

E-invoicing: XML formats are original documents under the AO

Since January 1, 2025, e-invoicing has been mandatory for transactions between domestic companies (§ 14 UStG, Growth Opportunities Act). An e-invoice exists only if it is issued, transmitted and received in a structured electronic format and enables electronic processing (§ 14 Abs. 1 Satz 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: In 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-invoicing, question 13):

"In the case of an e-invoice, at least its structured part must be retained in such a way that it is available intact in its original form."

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 discrepancies between the XML part and the image part, since 2025 the structured (XML) part is decisive (BMF FAQ question 12a). The PDF image is no longer authoritative.

AO § 147 - E-invoice as accounting record

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

• Available at all times (§ 147 Abs. 2): The XML file must be accessible during the entire retention period.
• Readable without delay (§ 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 machine-readable by definition - ideal for § 147 Abs. 6 (data access during external audit).
• Intact (§ 14b Abs. 1 UStG): The XML file may not be changed. Git fulfills this through immutability after commit (SHA-256 hash).

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

E-invoicing is based on EU law:

• Richtlinie 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-invoicing obligation and introduction of a reporting system for transaction data. The German e-invoicing 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 document 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 a media break.

Direct derivations in GitCover

Note - Micro-entrepreneur obligations from the 1st employee: Often even micro-entrepreneurs are subject to such obligations from the 1st employee onward - 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 discussed in Part IV are therefore not large-company special topics, but affect precisely 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 in which compliance obligations rise abruptly. Obligations from business registration (sphere classification, VBG exemption, flat rates) are already discussed 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 suitable by design for compliance:

1. Immutability after approval - tags and protected branches guarantee that approved diary entries are not subsequently changed (GoBD Rz. 146). Corrections are made as new commits with an obsolescence marker.
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 outset:

• 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 (functionally/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 anchored in the uuidV7 itself, as a 48-bit timestamp according to RFC 9562 §5.7. The uuidV7 is generated from a specified time mark (not now()) via the GitCover helper (gc-v7guid), with the rest filled with randomness. This cryptographically links the capture time to the identity of the artifact and makes it unchangeable afterward. A separate datetime/date string representation is redundant and is not kept in the facts - string representation for DTO/HTMX is the harness's responsibility.

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

Helper routines (GitCover OSS Tools): In work/OSS/gc-v7guid there is an OSS helper that provides two central operations:

• gen - generates a uuidV7 via Guid.CreateVersion7() (.NET) (with a specified time mark when needed, not only 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 mark in the data or in the file name) - and at the same time documenting the temporal requirements of the GoBD (prompt capture, traceability). The 48-bit value is the only factor in the TenantId derivation and can be an explicitly specified point in time instead of the system time (e.g., from a time mark of an ELSTER certificate, date of a receipt with TSE, etc.) - the interpretation follows the procedural documentation.

Sidecar principle (.gc.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 a specified time mark/48-bit timestamp anchored in the GUID
• v7g_taxonomy[].v7guid - object ID of the classified document
• sha256 - identity of the classified original document — the proof of originality, always and everywhere (even if the document moves: independent of path/name, calculated from the content)

Thus not only is the document uniquely identified (via its SHA-256), but also the classification act itself - including the point in time (in uuidV7), who classified it and in what role. No separate datetime field.

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

Risk leverage: Facts captured today at minimal cost (minutes, by 'agents' only moments) become future audit-proof evidence (hours of audit). The entrepreneur "raises" an evidentiary burden position - compliance as leverage.

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.

DSGVO note: All personal/company references in this series are fictitious or anonymized. Similarities to real organizations are accidental and not intended.

Preview of the series

Harness requirement (preview)

Derivable from ED01:

The complete requirements list is in Harness-Anforderungen.md.

Sources

• Genesis record SV audit (anonymized): E1/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md section J
• GoBD (BMF letter dated 28.11.2019, BStBl I p. 1269, last amended 14.07.2025, BStBl I p. 1502)
• AO (§§ 146, 147, 152, 162, 370, 379)
• SGB IV (§ 28p - company audit)
• UStG (§ 14 - e-invoice, § 14b - retention)
• BMF FAQ on e-invoicing (as of March 2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
• EN 16931 (European standards series, CEN/TC 434)
• Richtlinie 2014/55/EU (e-invoicing 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 application (main claim 2, claims 5–8)
• GitCover OSS tool gc-v7guid - work/OSS/gc-v7guid (helper routines gen/decode)
• DSGVO (anonymization obligation for publications)

Source topology and CDN reference links

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