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

Problem

An entrepreneur founds an organization - and faces an unclear picture of future risks. Which obligations arise when? Which documents 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 cobbled together ad-hoc
• isolated solutions (payroll software here, accounting there, document 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 cheaply ignored today until they become expensive tomorrow as fines, late payment penalties or revocations

Key statement

Not only documents must be audit-proof - also decisions, deadlines and document references must be traceable, reproducible and auditable. A Git-native diary does exactly that: it turns facts captured cheaply today (a JSON entry with V7GUID + SHA-256 document 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 bell.

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 document, contract or process it traces back. As a result, the same work record 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: document, 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 lie 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 carry. Thus compliance is not managed 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; taking 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 yet 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. Document authenticity unclear - PDFs by email have no cryptographic anchoring. Who changed what and when? Evidentiary value was only given through manual traceability.
3. No end-to-end chain of evidence - payroll accounts, social insurance reports, contribution statements 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 expiry was imminent.
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 only possible with specialized 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 keeps an unnecessary cloud account cost-incurring when the reason no longer exists (employee left, no more payroll needed)? However, the compilation of 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 old software version - in order 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. This is formally a violation of 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 maintain unused cloud accounts in a cost-incurring way. 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 "violation of 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 keeping books and other required records on data carriers, it must in particular be ensured that during the retention period the data are available at any time and can be made readable immediately."

This is the core provision: anyone who books electronically must ensure during the entire retention period (10 years for books/records, 8 years for accounting documents, § 147 Abs. 3 AO) that the data are available at any time and immediately readable. A paused cloud account that is reactivated only against extra costs violates this obligation - the data are not "available at any time", 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 reproductions on an image carrier or on other data carriers if this complies with the principles of proper accounting and it is ensured that the reproduction or the data [...] are available at any time during the retention period, can be made immediately readable and can be evaluated by machine."

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 - Auxiliary means 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 his own expense the auxiliary means required to make the documents readable."

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

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

"If the documents referred to in paragraph 1 were created with the aid 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 according to 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 only offers 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 accounting system must have procedural documentation describing 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 must 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: had the DRV not accepted the data as PDF but 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):

"For 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 deviations between the XML part and the image part, since 2025 the structured (XML) part is authoritative (BMF FAQ Question 12a). The PDF image is no longer leading.

AO § 147 - E-invoice as accounting document

E-invoices are accounting documents 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 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 thus also readable without specialized software.
• Machine-evaluable (§ 147 Abs. 6): XML is by definition machine-readable - ideal for § 147 Abs. 6 (data access during external 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

E-invoicing 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-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 transitional period 2025–2027 without a media break.

Direct derivations in GitCover

Note - micro-entrepreneur obligations from 1 employee: Often even micro-entrepreneurs are 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 1 employee covered in Part IV are therefore not large-company special topics, but specifically affect 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 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 suitable for compliance by design:

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 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 reduce 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 artifact types and entries - JSON schema-first, mandatory sidecar, temporal signature {YYMMDD HHmm}, SHA-256 document 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 timestamp (not now()) via GitCover helper (UuidV7Gen), with the rest filled with randomness. Thus the capture time is cryptographically linked to the identity of the artifact and cannot be changed subsequently. 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 the 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 the 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/TOP/tools/UuidV7Gen/ there is an OSS helper that provides two central operations:

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

Sidecar principle (.v7g.md): Each 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 timestamp/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: path-/name-independent, calculated from the content)

Thus not only the document is uniquely identified (via its SHA-256), but also the classification act itself - including time (in uuidV7), who classified 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, mere moments through 'agents') become future audit-proof evidence (hours of review). The entrepreneur "raises" a burden-of-proof 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 his 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 note: 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 evidence social insurance audit (anonymized): E1/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md Section J
• GoBD (BMF letter of 28.11.2019, BStBl I S. 1269, last amended 14.07.2025, BStBl I S. 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)
• Directive 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 UuidV7Gen - work/OSS/TOP/tools/UuidV7Gen/ (helper routines gen/decode)
• GDPR (anonymization obligation upon publication)

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.