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

Problem

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

• "What is process documentation?" - most entrepreneurs are not familiar with the term, let alone its content
• "The tax advisor does that" - many believe the tax advisor creates the process documentation - but he can only provide guidance; the entrepreneur must create and maintain it themselves
• Word document in the desk drawer - if process documentation exists at all, it is a static Word document that is not updated when the system changes - a GoBD violation
• No versioning - changes to the process documentation are not traceably documented - but GoBD Rz. 83 requires currency and traceability
• No approval - the process documentation is never "approved" - but GoBD requires that the state at the time of the audit be clear
• System changes not documented - when migrating to new software, the process documentation is not carried forward - GoBD Rz. 146–150 expressly requires this

Key Message

A GoBD-compliant process documentation in the Git repo means:

1. The process documentation 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 documentation (e.g., vd-v1.0-2026)
4. System changes are carried forward - during a migration, a new commit with a rationale is created; the old version remains traceable
5. The repo itself is part of the process documentation - git log shows the process, .gitcover/schemas/ shows the data structures, Git hooks show the controls

Compliance by Design: Process documentation is not created after the fact - it emerges from the use of Git. Anyone working with Git repositories automatically documents their process through commits, diffs, and tags. The formal process documentation supplements 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 Documentation 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>",
  "uuidV7": "<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 serves storage organization and DB queries. 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 afterwards. 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 Changes and Migration (GoBD Rz. 146–150)

GoBD Rz. 146–150 requires the following in the event of a system change:

1. Keep the data of the old system available - git bundle as a self-contained archive (no cloud account required, see ED04 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 payroll software to GitCover. He creates a git bundle of the old data, updates the process documentation (new commit with the commit message "Migration to GitCover, 260815, role: GF"), marks the old version as superseded, and tags the new version as vd-v2.0-2027. The auditor can trace both versions.

The Repo Itself as Process Documentation

The Central Insight: A Git repo is itself a process documentation - git log shows the process, git config shows the system environment, Git hooks show the controls, schemas show the data structures. The formal process documentation (Markdown in docs/verfahrensdokumentation/) supplements this with the human-readable description - but the authoritative source is the repo itself.

Risk Leverage

Harness Requirement (Preview)

Derivable from ED06:

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

Sources

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

Source Topology and CDN Reference Links

Note: This assignment 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.