ED07 - GoBD Process Documentation: Mandatory Fields, Versioning, Approval

Problem

GoBD Rz. 64–91 requires process documentation - but in the SME sector it is the exception rather than the rule:

• "What is process documentation?" - most entrepreneurs do not know the term, let alone its content
• "The tax advisor handles that" - many believe the tax advisor creates the process doc - but they can only advise; the entrepreneur must create and maintain it themselves
• Word document on the desktop - if process documentation exists, it is a static Word document that is not updated during a system change - GoBD violation
• No versioning - changes to the process doc are not documented in a traceable manner - but GoBD Rz. 83 requires currency and traceability
• No approval - the process doc is never "approved" - but GoBD requires the state at the time of the audit to be clear
• System change not documented - when migrating to new software, the process doc is not updated - GoBD Rz. 146–150 expressly requires this

Key Statement

GoBD-compliant process documentation in a Git repo means:

1. The process doc is a versioned Git artifact - not a Word document, but Markdown + JSON in the repo
2. Every change is traceable - git log shows who, when, what, why (commit author, uuidV7 timestamp, diff, commit message)
3. Approval via tags - a Git tag marks the approved state of the process doc (e.g. vd-v1.0-2026)
4. System changes are continued in the documentation - during a migration, a new commit is created with a rationale; the old version remains traceable
5. The repo itself is part of the process documentation - git log shows the procedure, .gitcover/schemas/ shows the data structures, Git hooks show the controls

Compliance by Design: Process documentation is not an afterthought - it is created through the use of Git. Anyone who works with Git repositories automatically documents their process through commits, diffs and tags. The formal process documentation complements this with the human-readable description.

What Is Process Documentation?

Mandatory Fields of the Process Documentation

Structure in the Git Repo

ORG-1/
├── .gitcover/
│   ├── schemas/                    # Datenstrukturen (Rz. 86–91)
│   │   ├── diary-entry-1.0.schema.json
│   │   ├── v7g-sidecar-1.0.schema.json
│   │   └── timesheet-1.0.schema.json
│   ├── dictionaries/               # Klassifizierungen (Rz. 86–91)
│   │   ├── spheres.json
│   │   ├── roles.json
│   │   └── beleg-types.json
│   └── LEGAL_ENTITY.v7g.json       # Tenant-Identität
├── docs/
│   └── verfahrensdokumentation/
│       ├── README.md               # Einstieg + Übersicht
│       ├── 01-verfahren.md         # Buchführungsverfahren (Rz. 64–71)
│       ├── 02-systemumgebung.md    # Software/Hardware (Rz. 72–76)
│       ├── 03-organisation.md      # Zuständigkeiten (Rz. 77–80)
│       ├── 04-kontrollen.md        # Internen Kontrollen (Rz. 81–85)
│       └── 05-daten.md             # Datenstrukturen (Rz. 86–91)
└── .githooks/
    ├── pre-commit                  # Kontrollen (Rz. 81–85)
    └── post-commit                 # Index-Generierung

Process Doc as a JSON Artifact

The process documentation itself is a versioned artifact with V7GUID (class) and uuidV7 (object ID as DocID):

{
  "$schema": "https://gitcover.org/schemas/verfahrensdoku-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "docUid": "<uuidV7-Object-mit-vorgegebener-Zeitmarke>",
  "author": "E1",
  "role": "GF",
  "tenant": "ORG-1",
  "sphere": "wirtschaftlich",
  "source": "E1",
  "version": "1.0",
  "status": "released",
  "sections": ["01-verfahren", "02-systemumgebung", "03-organisation", "04-kontrollen", "05-daten"]
}

Note: The uuidV7 is the DocID of the process documentation. The composite key V7GUID:uuidV7 is used for storage organization and DB queries. There is no separate datetime/date field - the time is embedded in the uuidV7.

Versioning and Approval

Important - Tags as approval markers: A Git tag is immutable

• it marks an exact commit state that cannot be changed afterward. This corresponds to GoBD Rz. 146 (immutability). The auditor can use git show vd-v1.0-2026 to reconstruct the exact state of the process documentation at the time of the audit.

System Change and Migration (GoBD Rz. 146–150)

GoBD Rz. 146–150 requires the following for a system change:

1. Keep the old system's data available - git bundle as a self-contained archive (no cloud account required, see ED05 Z3)
2. Update the process documentation - new commit with a rationale: "Migration from Cloud-Lohn to GitCover, date, role"
3. Document the transition period - which data was migrated and how, which checks were performed
4. Mark the old version as obsolete - obsolescence: superseded_by in the old process documentation artifact

Practical example: The entrepreneur (E1) migrates from Cloud-Lohn software to GitCover. They create a git bundle of the old data, update the process documentation (a new commit with commit message "Migration to GitCover, 260815, role: GF"), mark the old version as superseded and tag the new version as vd-v2.0-2027. The auditor can trace both versions.

The Repo Itself as Process Documentation

The key insight: A Git repo is itself process documentation - git log shows the procedure, git config shows the system environment, Git hooks show the controls, and schemas show the data structures. The formal process documentation (Markdown in docs/verfahrensdokumentation/) adds the human-readable description to this - but the authoritative source is the repo itself.

Risk Leverage

Harness Requirements (Preview)

Derived from ED07:

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

Sources

• GoBD (BMF letter, Rz. 64–91 - process documentation, Rz. 146–150 - system change, Rz. 83 - currency)
• AO (§ 146 - administrative provisions, § 147 - retention)
• E1/agents/ (anonymized) - SSoT concept with process documentation as a Git artifact

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 on gitcover.org for the current state.