ED01 - Motivation: Why an entrepreneur keeps his 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 documents must be retained for how long? Which deadlines are in danger of being missed? Which authorities get in touch when, and for which audit?
Today's practice in the SME sector is characterized by:
- Paper-scrap management 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, 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, non-profit status) - there is almost no free support here
- Risk backlog - obligations are ignored cheaply 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["Tomorrow expensive
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
Key message
Not only documents must be audit-proof - decisions, deadlines and document 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 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 through GitCover techniques (OSCAL, OPA, V7GUID, Git hooks) from the very beginning, not only when the auditor rings the bell.
Genesis: The SV audit as the practical trigger
The GitCover idea was not born in an ivory tower, but out of
concrete practical experience: most recently from an SV audit at a micro-UG
(anonymized here as ORG-V for "predecessor organization") covering 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?
| Date | Event | Status |
|---|---|---|
| 02/2024 | DRV announces an audit under § 28p SGB IV | ⏳ |
| 12/2024 | DRV requests audit documents (payroll accounts 2021–2023, questionnaire, cover letter) | ⏳ |
| 12/2024 | Documents are cobbled together as PDF/ZIP and sent by email | ✅ |
| 02/2025 | DRV transmits audit results (hearing § 24 SGB X, total summary sheet, attachments HEK/Minijob-Zentrale) | ✅ |
| 02/2025 | Acceptance without objections; refund application submitted to the KK | ✅ |
| 03/2025 | SV audit completed - GitCover idea born | ✅ |
Financial result (net)
| Item | Amount |
|---|---|
| Refund of overpaid U1 contributions | +121 EUR |
| Additional demand for KV flat-rate contributions | −30 EUR |
| Net refund | +91 EUR |
| Service provider costs | >100 EUR |
| Effort | several days of manual compilation |
Pain points - what the audit revealed
Audit only by email"] P2["Document authenticity unclear
PDFs without cryptographic anchoring"] P3["No chain of evidence
Payroll accounts/SV/refund in different places"] P4["Deadlines ad hoc
maintained manually in calendar"] P5["Audit export missing
euBP/eXTra, Z3 only with special software"] P6["Payroll account paused
after employee departure
Extra costs > refund"] 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 an audit had to be handled purely by email with PDF and ZIP files. The tools did not exist for this micro case.
- Document authenticity unclear - PDFs by email have no cryptographic anchoring. Who changed what, when? The evidentiary value existed only through manual traceability.
- No end-to-end chain of evidence - payroll accounts, SV reports, contribution records and refund documents were located in different places, without cross-references. Every follow-up query required searching all over again.
- Ad hoc deadline management - hearing deadlines, refund 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 a cloud account running pointlessly and at a cost when the reason no longer exists (employee departed, no more 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 "refund" at the end of the audit.
- Reactivation of old backups with an old software version - to make the
payroll accounts for 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
ensure technically 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 a cost. Exactly 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 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 (Principles for the proper keeping and retention of books, records and documents in electronic form as well as for data access, BMF letter).
AO § 146 Abs. 5 - Availability during the retention period
"Where books and the other required records are kept on data carriers, it must be ensured in particular that during the retention period the data are 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 are available at any time and legible without delay. A paused cloud account that is only reactivated 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 the 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, provided 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 evaluated by machine."
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 expense of the taxpayer
"Anyone who submits 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, those aids that are required to make the documents legible."
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 legible. Exactly this was the practical problem in the genesis case: old backups, old software version, no aids available anymore.
AO § 147 Abs. 6 - Data access during an external audit
"If the documents according to paragraph 1 have been created with the help of a data processing system, the tax authority may, in the context of an external audit [...], demand that the data be made available in machine-evaluable form in accordance with its specifications."
In an external 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 - Process documentation and system changes
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 remain 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 the event of a violation
AO § 146/147 + GoBD"] V --> K1["Late-filing surcharge
§ 152 AO
up to 25,000 EUR"] V --> K2["Estimated assessment
§ 162 AO
if data cannot be evaluated"] V --> K3["Delay penalty
§ 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) |
| Estimated assessment of the tax bases | § 162 AO | FA estimates when data cannot be evaluated - often to the detriment of the entrepreneur |
| Delay penalty | § 146 Abs. 2c AO | 2,500–250,000 EUR (in case of outsourcing without approval) |
| Reversal of 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 (in case of intentional tax evasion) |
Practical context: In the genesis case, the SV audit was accepted without objections - no consequences followed. 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 by 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 is authoritative (BMF FAQ question 12a). The PDF image is no longer leading.
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 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 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-invoice 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 "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 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 media discontinuity.
Direct derivations in GitCover
| Pain point | GitCover concept | Series article |
|---|---|---|
| Document authenticity unclear | SHA-256 + V7GUID + sidecar .v7g.md per document |
ED03, ED08 |
| No chain of evidence | 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 wB, document, report | 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 enterprises taking on staff for the first time. GitCover deliberately addresses 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 by Design suitable for compliance:
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 artifact 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, independent of file names"] HOOKS --> CHECK["Schema, spheres,
obsolescence checked"] ART --> SIG["Temporal signature
SHA-256 document 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 artifact types and entries - JSON-Schema-First, sidecar obligation,
temporal signature
{YYMMDD HHmm}, SHA-256 document references
Core principle of temporal traceability: The capture 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 preset time mark (notnow()) via the GitCover helper (UuidV7Gen), with the remainder filled with randomness. This cryptographically links the capture time to the identity of the artifact 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 epoch (1970-01-01T00:00:00Z), 48 bits, value range 0 … 2⁴⁸−1 (range up to approx. year 10889). The V7GUID specification is normatively stored 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 preset time mark 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 time mark in the data or in the file name) - while simultaneously documenting the temporal requirements of the GoBD (timely capture, traceability). The 48-bit value is the only factor in the TenantId derivation and can, instead of the system time, be an explicitly preset point in time (e.g., from a time mark 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 preset time mark/48-bit timestamp anchored in the GUIDv7g_taxonomy[].v7guid- Object ID of the classified documentsha256- identity of the classified original document — the proof of originality, always and everywhere (even when the document moves: path/name-independent, computed from the content)Thus not only is the document uniquely identified (via its SHA-256), but also the act of classification itself - including the point in time (in
uuidV7), who classified and in which role. No separatedatetimefield.
Risk Leverage - what is inexpensive (cheap) 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 "leverages" 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 at FA/SV audit | Downgrading of evidentiary value |
| Deadline check file | Missed deadlines avoided | Late-filing surcharges § 152 AO |
| Sphere tag per entry | Non-profit status defensible | Revocation § 51 AO |
| FZul hours-evidence diary | BSFZ certificate obtainable | FZul loss (up to 1 million EUR) |
Sidecar .v7g.md per document |
Document 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 his 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.
DSGVO note: All person/company references in this series are fictional or anonymized. Any resemblance to real organizations is 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 uuidV7 (RFC 9562 §5.7) |
MUST |
| FA-1.3 | uuidV7 generated from a preset time mark (not now()) via helper |
MUST |
| FA-2.1 | SHA-256 as document 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 document 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 - 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 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) - DSGVO (obligation to anonymize upon publication)
Source topology and CDN reference links
| Role | Location | Purpose |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Canonical storage (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.