ED01 - Motivation: Why an entrepreneur keeps their diary in Git
Problem
An entrepreneur founds an organization - and faces an unclear picture of the risks that will arise. Which obligations arise when? Which receipts must be retained for how long? Which deadlines are at risk of being missed? Which authorities announce themselves when for which audit?
Today's practice in the SME sector is characterized by:
- Paper-scrap chaos and local Excel lists - not traceable, not audit-proof
- PDF and email chaos during audits - documents are cobbled together ad hoc
- Siloed solutions (payroll software here, accounting there, receipt archive elsewhere) - without an end-to-end evidence chain
- Open-source gaps for special obligations (working time, travel expenses, allowances, BEM, FZul/BSFZ, non-profit status) - there is almost no free support here
- Risk backlog - obligations are cheaply ignored today until they become expensive tomorrow as fines, late-filing surcharges or revocations
Day 0"] --> B["Obligations
unclear"] B --> C["Cheaply ignored
today"] C --> D["Expensive tomorrow
fine/revocation"] D --> E["Risk
realized"] style A fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style B fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style C fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style D fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#FF3333,stroke:#0F1B33,color:#FBFAF7
Core message
Not only documents must be audit-proof - decisions, deadlines and receipt 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 receipt 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 comes knocking.
Genesis: The SV audit as the practical trigger
The GitCover idea was not born in an ivory tower, but from concrete practical experience: most recently from an SV company audit at a micro-UG (anonymized here as ORG-V for 'Vorläufer-Organisation') 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 SV audit
What happened?
| Date | Event | Status |
|---|---|---|
| 02/2024 | DRV announces a company audit under § 28p SGB IV | ⏳ |
| 12/2024 | DRV requests the audit documents (payroll accounts 2021–2023, questionnaire, cover letter) | ⏳ |
| 12/2024 | Documents are cobbled together as PDF/ZIP and sent via email | ✅ |
| 02/2025 | DRV transmits the audit results (hearing § 24 SGB X, total summary sheet, annexes HEK/Minijob-Zentrale) | ✅ |
| 02/2025 | Accepted without objections; reimbursement application submitted to the KK | ✅ |
| 03/2025 | SV audit completed - GitCover idea born | ✅ |
Financial result (net)
| Item | Amount |
|---|---|
| Reimbursement of overpaid U1 contributions | +121 EUR |
| Additional demand for KV flat-rate contributions | −30 EUR |
| Net reimbursement | +91 EUR |
| Service provider costs | >100 EUR |
| Effort | several days of manual compilation |
Pain points - what the audit revealed
audit only via email"] P2["Receipt authenticity unclear
PDFs without cryptographic anchoring"] P3["No evidence chain
payroll accounts/SV/reimbursement in different places"] P4["Deadlines ad hoc
maintained manually in the calendar"] P5["Audit export missing
euBP/eXTra, Z3 only with special software"] P6["Payroll account paused
after employee departure
extra costs > reimbursement"] P7["Old backups
old software version
GoBD requirement violated"] P1 --> G["GitCover idea
born"] P2 --> G P3 --> G P4 --> G P5 --> G P6 --> G P7 --> G G --> S["GitCover solutions
SHA-256+V7GUID, hooks, deadline check
Evidence Packages, Git bundles self-contained"] style P1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P7 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style G fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
- No office operation, no fax, no employee - and yet a company audit had to be handled purely via email with PDF and ZIP files. The tools did not exist for this micro case.
- Receipt authenticity unclear - PDFs sent by email have no cryptographic anchoring. Who changed what, when? The evidentiary value existed only through manual traceability.
- No end-to-end evidence chain - payroll accounts, SV reports, contribution records and reimbursement receipts were stored in different places, without cross-references. Every follow-up query required a renewed search.
- Ad hoc deadline management - hearing deadlines, reimbursement deadlines and objection deadlines were maintained manually in the calendar. No warning of imminent expiry.
- Audit export missing - the DRV requested data in euBP format (eXTra V3.4.0); the FA would have demanded a Z3 data carrier. Both were only possible with special software or manual preparation.
- Employee departure → payroll account paused - after the departure of the then employee, the payroll accounting account with the service provider was paused. Who keeps an unnecessary cloud account running at incurring cost when the reason no longer exists (employee has left, no more payroll accounting needed)? Yet compiling the document package for the audit then required additional extra costs with the service provider, which in the end were higher than the small 'reimbursement' at the end of the audit.
- Reactivating 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 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 keep unused cloud accounts running at incurring cost. This tension is precisely a core motivation for GitCover: Git bundles are self-contained - they need no cloud accounts, no service provider contracts, no software versions. A
git clonesuffices, and the retention period is technically fulfilled.
Legal basis: AO § 146, § 147 and GoBD
The 'violation of the GoBD requirement' addressed 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-Schreiben).
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 is available at any time and can be made legible without delay."
This is the core provision: anyone who does their bookkeeping electronically must ensure throughout the entire retention period (10 years for books/records, 8 years for accounting vouchers, § 147 Abs. 3 AO) that the data is available at any time and legible without delay. A paused cloud account that is only reactivated against 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
"With the exception of the annual financial statements [...], the documents listed in paragraph 1 may also be retained as a reproduction on a visual medium or on other data carriers, provided that this complies with the principles of proper bookkeeping and it is ensured that the reproduction or the data [...] are available at any time during the retention period, can be made legible without delay and can be machine-evaluated."
Again: 'available at any time', 'legible 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 submits documents to be retained in the form of a reproduction on a visual medium or on other data carriers is obliged to provide at their own expense those aids that are necessary to make the documents legible."
This means: if the service provider no longer maintains the old system, the entrepreneur must provide the aids (software, licenses, hardware) themselves to make the data legible. This was precisely the practical problem in the genesis case: old backups, old software version, no aids available any more.
AO § 147 Abs. 6 - Data access during an external audit
"If the documents under paragraph 1 have been created with the aid of a data processing system, the tax authority may, within the framework of an external audit [...], demand that the data be made available machine-evaluated according to its specifications."
In 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 does not suffice.
GoBD - Process documentation and system change
The GoBD concretize these AO provisions for electronic systems. Central requirements:
- Process documentation (GoBD Rz. 64–91): Every electronic bookkeeping system must have process documentation describing the procedure, the system environment, the organizational measures and the internal controls. In the event of a system change, the process 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 remains available, legible and machine-evaluable. The process documentation must document the change.
- Immutability (GoBD Rz. 146): After posting, the data must not be altered. Corrections must be made as new entries with a justification.
Theoretical consequences in case of violation
AO § 146/147 + GoBD"] V --> K1["Late-filing surcharge
§ 152 AO
up to 25,000 EUR"] V --> K2["Estimate
§ 162 AO
if data is not usable"] V --> K3["Delay fine
§ 146 Abs. 2c AO
2,500–250,000 EUR"] V --> K4["Reversal of burden of proof
FA estimates, entrepreneur
must rebut"] V --> K5["Administrative offense
§ 379 AO
fine up to 50,000 EUR"] V --> K6["Tax criminal proceedings
§ 370 AO
in case of intentional evasion"] style V fill:#FF1A1A,stroke:#0F1B33,color:#FBFAF7 style K1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33
| Consequence | Legal basis | Amount/Risk |
|---|---|---|
| Late-filing surcharge | § 152 AO | up to 25,000 EUR (individual case) |
| Estimation of tax bases | § 162 AO | FA estimates when data is not usable - often to the disadvantage of the entrepreneur |
| Delay fine | § 146 Abs. 2c AO | 2,500–250,000 EUR (for outsourcing without approval) |
| Reversal of the burden of proof | § 162 AO, § 90 AO | Entrepreneur must rebut the estimate - hardly possible with missing data |
| Administrative offense | § 379 AO | fine up to 50,000 EUR (intentional or negligent) |
| Tax criminal proceedings | § 370 AO | imprisonment up to 5 years (for intentional tax evasion) |
Practical assessment: In the genesis case, the SV audit was accepted without objections - no consequences ensued. 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 hard pressed to explain. GoBD-compliant retention is not a theoretical obligation - it becomes real at every external audit.
Why Git solves the problem
Git fulfills the AO/GoBD requirements by Design:
| AO/GoBD requirement | How Git fulfills it |
|---|---|
| 'available at any time' (§ 146 Abs. 5) | git clone possible at any time - no cloud account, no license |
| 'legible without delay' (§ 147 Abs. 2) | plain-text files (Markdown, JSON) - no software version needed |
| 'machine-evaluable' (§ 147 Abs. 6) | JSON-Schema-First - structured data, no PDF export needed |
| 'aids at the entrepreneur's expense' (§ 147 Abs. 5) | Git is OSS, free of charge - no service provider costs |
| Immutability (GoBD Rz. 146) | Tags, Protected Branches, obsolescence marking |
| Process documentation (GoBD Rz. 64–91) | the repo itself is the process documentation - git log shows the procedure |
| System change/migration (GoBD Rz. 146–150) | Git is version-independent - git clone on any system |
E-invoicing: XML formats are the original documents under the AO
Since 1 January 2025, e-invoicing has been mandatory for transactions between domestic companies (§ 14 UStG, Wachstumschancengesetz). 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 does not fall under this any more - since 2025 it is an 'other invoice'.
before 2025"] --> U["Transition
2025–2027"] PDF["PDF via email
before 2025 'electronic'"] --> U U --> E["E-invoice
mandatory from 2025
structured, machine-readable"] E --> X["XRechnung
XML-based
EN 16931"] E --> Z["ZUGFeRD
hybrid: PDF + XML
from v2.0.1"] style P fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style PDF fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style U fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style X fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Z fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
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 an optionally attached PDF or a human-readable image. The BMF makes this clear (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 present intact in its original form."
This means:
- XRechnung (XML-based, EN 16931): The XML file is the original document. It must be retained unaltered. 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 prevails (BMF FAQ question 12a). The PDF image no longer prevails.
AO § 147 - E-invoice as an accounting voucher
E-invoices are accounting vouchers 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 throughout the entire retention period.
- Legible without delay (§ 147 Abs. 2): An XML viewer or the ELSTER e-invoice viewer (
www.e-rechnung.elster.de) makes the file legible - but the XML itself is plain text and thus legible even without special software. - Machine-evaluable (§ 147 Abs. 6): XML is machine-readable by definition - ideal for § 147 Abs. 6 (data access during an external audit).
- Intact (§ 14b Abs. 1 UStG): The XML file must not be altered. Git fulfills this through immutability after commit (SHA-256 hash).
EU-wide provisions: 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 standard 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 extension 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
| E-invoicing requirement | How Git fulfills it |
|---|---|
| XML as the original document | XML file is stored unaltered in the repo - git diff shows no change |
| Intact (§ 14b UStG) | SHA-256 hash per commit - any alteration would be visible |
| Retain for 8 years (§ 147 Abs. 3) | Git bundle as a self-contained archive - no cloud account needed |
| Machine-evaluable (§ 147 Abs. 6) | XML is machine-readable by definition - git grep suffices |
| EN 16931 validation | pre-commit hook can invoke the XRechnung/ZUGFeRD validator |
| Visualization (BMF FAQ 12a) | XML + human-readable Markdown sidecar - both in the repo |
| Transition period 2025–2027 | the repo can retain both 'other invoices' (PDF) and e-invoices (XML) in parallel |
Practical tip: A Git repo can retain e-invoices (XML) and other invoices (PDF) in parallel - with a clear separation by receipt 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
| Pain point | GitCover concept | Series articles |
|---|---|---|
| Receipt authenticity unclear | SHA-256 + V7GUID + sidecar .v7g.md per receipt |
ED03, ED08 |
| No evidence chain | Git repo with functionally dedicated hooks, land register as JSON | ED06, ED07 |
| Deadlines ad hoc | checks/FRISTEN_CHECK.md + auto warning |
ED09 |
| Audit export missing | GoBDExport (Z3), EuBPExport (eXTra), Evidence Packages | ED08, ED35 |
| Payroll account paused, extra costs | Git bundles self-contained, no cloud accounts | ED08, ED09 |
| Old backups/old software version, GoBD violation | Git repo as a self-contained retention medium, git clone suffices |
ED08, ED09 |
| Who stands behind the company? | Transparency register: identify, document, report beneficial owners (wB) | ED04, ED12, ED17, ED18 |
| No OSS for special cases | GitCover covers FZul/BSFZ, non-profit status, working time, BEM | ED25–ED34 |
Note - micro-entrepreneur obligations from the 1st employee: Often, micro-entrepreneurs themselves are already subject to such obligations from the 1st employee onwards - 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 treated in Part IV are therefore not large-enterprise special topics, but apply precisely to micro and small businesses taking on staff for the first time. GitCover deliberately targets this threshold - the transition from solo entrepreneur to employer is the critical moment at which compliance obligations rise sharply. Obligations from business registration (sphere classification, VBG exemption, flat rates) are already treated in Part II - they arise without employees.
Why Git as a diary medium?
Git is originally a version control system - but it comes with three properties that make it suitable for compliance by Design:
diary medium"] G --> U["Immutability
after release
(Tags, Protected Branches)"] G --> N["Traceability
author + timestamp
+ cryptographic integrity"] G --> D["Decentralization
Git bundles + GCEP
multi-site, off-site"] U --> GoBD["GoBD Rz. 146
compliant"] N --> Audit["Audit-ready
reproducible"] D --> Backup["No SPOF
distributed"] style G fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style U fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style N fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style D fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GoBD fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Audit fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Backup fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
- Immutability after release - Tags and Protected Branches guarantee that released diary entries are not subsequently altered (GoBD Rz. 146). Corrections are made as new commits with an obsolescence marking.
- Traceability - every commit carries author, timestamp and cryptographic integrity. The entire history is reproducible.
- 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:
machine-readable
compliance statements"] CBD --> OPA["OPA/Rego
Policy as Code
automated checking"] CBD --> V7["V7GUID Uniqueness
time-stable
unique IDs"] CBD --> HOOKS["Git hooks
functionally dedicated
Pre/Post-Commit"] CBD --> ART["Code artefact types
JSON-Schema-First
sidecar obligation"] OSCAL --> ZERT["Certification readiness
ISO 27001, AI Act, BSI GS++"] OPA --> POLICY["Spheres, deadlines,
contribution group plausibility"] V7 --> UNIQ["Collision-free,
sortable, filename-independent"] HOOKS --> CHECK["Schema, spheres,
obsolescence checked"] ART --> SIG["Temporal signature
SHA-256 receipt references"] style CBD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style OSCAL fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style OPA fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style V7 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style HOOKS fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style ART fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style ZERT fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style POLICY fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style UNIQ fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style CHECK fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SIG fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33
- 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/subject-matter 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 receipt references
Core principle of temporal traceability: The recording time is not a separate field, but is anchored in the
uuidV7itself, as a 48-bit timestamp according to RFC 9562 §5.7. TheuuidV7is generated from a predetermined timestamp (notnow()) via the GitCover helper (UuidV7Gen), with the remainder filled with randomness. This cryptographically links the recording time to the identity of the artefact and makes it unalterable afterwards. A separatedatetime/datestring representation is redundant and is not maintained in the facts - string representation for DTO/HTMX is the Harness's responsibility.
RFC reference: The 48-bit timestamp component of the
uuidV7corresponds to RFC 9562 §5.7 (UUIDv7) - Unix milliseconds since the epoch (1970-01-01T00:00:00Z), 48 bits, value range 0 … 2⁴⁸−1 (range up to approx. the year 10889). The V7GUID specification is stored normatively inwork/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 auuidV7viaGuid.CreateVersion7()(.NET) (with a predetermined timestamp if needed, not onlynow()) and returns label, UUID and the decoded ISO timestamp.decode- extracts the 48-bit timestamp component from a givenuuidV7and returns it as an ISO-8601 timestamp.These helpers are crucial for creating a valid
uuidV7key from foreign keys (e.g., a timestamp in the data or in the file name) - while simultaneously documenting the temporal requirements of the GoBD (prompt recording, traceability). The 48-bit value is the only factor of the TenantId derivation and can, instead of the system time, be an explicitly predetermined point in time (e.g., from a timestamp of an ELSTER certificate, the date of a receipt with TSE, etc.) - the interpretation follows the process documentation.
Sidecar principle (
.v7g.md): Every sidecar carries a Composite KeyV7GUID:uuidV7:
V7GUID(Class Identifier) - classifies the sidecar according to the.gitcoverregistry (what/which type)uuidV7(Object ID) - identity of the sidecar itself, generated with a predetermined timestamp/48-bit timestamp anchored in the GUIDv7g_taxonomy[].v7guid- Object ID of the classified documentThus not only is the document uniquely identified, but also the classification act itself - including the point in time (in the
uuidV7), who classified and in which role. No separatedatetimefield.
Risk leverage - what is cheap (inexpensive) today and becomes audit-proof tomorrow
Risk leverage: Facts captured today at minimal cost (minutes, or mere moments via 'agents') become future audit-proof evidence (hours of auditing). The entrepreneur 'levers' a burden-of-proof position - compliance as a lever.
| Today (cheap, ~minutes/seconds) | Tomorrow (audit-proof, ~hours of auditing) | Risk mitigated |
|---|---|---|
| JSON diary entry with V7GUID + SHA-256 | GoBD-compliant evidence (10 years) | retention period violation |
source field per fact |
burden of proof in FA/SV audits | downgrading of evidentiary value |
| Deadline check file | missed deadlines avoided | late-filing surcharges § 152 AO |
| Sphere tag per entry | non-profit status defended | revocation § 51 AO |
| FZul hours-record diary | BSFZ certificate obtainable | loss of FZul (up to 1 million EUR) |
Sidecar .v7g.md per receipt |
receipt authenticity provable | contestation of evidentiary value |
| Working-time JSON per day | ArbZG compliance provable | fine § 22 ArbZG |
| Git bundle instead of cloud account | retention without service provider costs | GoBD access loss after account pause |
git clone instead of software-version reactivation |
self-contained retention, no version dependency | GoBD violation through non-reactivatable legacy systems |
What this series shows
The series follows a fictional entrepreneur (E1) who runs an organization KMU (placeholder, open as to legal form) and keeps their diary in a Git repo. The structure is modeled on a real SSoT concept, but is fully anonymized - all person, company, HRB, IBAN and tax number data are replaced by placeholders.
GDPR note: All person/company references in this series are fictional or anonymized. Similarities with real organizations are coincidental and not intended.
Preview of the series
Fundamentals
ED01–ED04"] II["Part II
GoBD, AO, tax office
+ obligations from business registration
ED05–ED12"] III["Part III
Authorities & associations
ED13–ED19"] IV["Part IV
Employees & payroll
+ obligations from the 1st employee
ED20–ED27"] I --> II --> III --> IV style I fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style II fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style III fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style IV fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33
Special challenges
FZul/BSFZ, non-profit status
ED28–ED31"] VI["Part VI
Harness requirements
ED32–ED35"] VII["Part VII
Appendix
ED36–ED37"] V --> VI --> VII style V fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style VI fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style VII fill:#E5E7EB,stroke:#6B7280,color:#0F1B33
| Part | Topic | Articles |
|---|---|---|
| I | Fundamentals (this article) | ED01–ED03 |
| II | Business management: GoBD, AO, tax office + obligations from business registration (spheres, VBG, flat rates) | ED05–ED11 |
| III | Authorities & associations | ED13–ED19 |
| IV | Employees & payroll + obligations from the 1st employee (working time, MiLoG, vacation/sickness/BEM) | ED20–ED27 |
| V | Special challenges (FZul/BSFZ, non-profit status) | ED28–ED31 |
| VI | Harness requirements | ED32–ED35 |
| VII | Appendix (glossary, sources) | ED36–ED37 |
Harness requirement (preview)
Derivable from ED01:
| ID | Requirement | Priority |
|---|---|---|
| FA-1.1 | Diary entries as JSON artifacts (Schema-First) | MUST |
| FA-1.2 | Composite Key V7GUID (Class) : uuidV7 (Object) - no separate datetime/date field; time in the uuidV7 (RFC 9562 §5.7) |
MUST |
| FA-1.3 | uuidV7 generated from a predetermined timestamp (not now()) via helper |
MUST |
| FA-2.1 | SHA-256 as receipt ID | MUST |
| FA-2.2 | .v7g.md sidecar obligation |
MUST |
| FA-4.1 | Deadline check file | MUST |
| TA-2.1 | Pre-commit: JSON schema validation | MUST |
The complete requirements list in Harness-Anforderungen.md.
Sources
- Genesis receipt of the SV audit (anonymized):
AFJD/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.mdsection 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-invoicing, § 14b - retention)
- BMF FAQ on e-invoicing (as of March 2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
- EN 16931 (European standard 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 routinesgen/decode) - GDPR (obligation to anonymize upon publication)
Source topology and CDN reference links
| Role | Location | Purpose |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Canonical repository (GPG-signed, versioned) |
| Public OSS Mirror / CDN | codeberg.org/gitcover-commons | Read-only mirror; FLOSS discovery |
| Community Hub | github.com/gitcover-commons | Issues & Discussions; source code reference to Codeberg |
Note: This assignment of sources, mirror and community hub reflects the current state and may change. Please check the respective canonical source under
git.gitcover.org/GCCfor the current state. canonical source on gitcover.org for the current state.