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

Problem

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

• "What is procedural documentation?" - most entrepreneurs do not know the term, let alone its content
• "The tax advisor does that" - many believe the tax advisor creates the procedural documentation - but he can only guide; the entrepreneur must create and maintain it himself
• Word document on the desk - if procedural documentation exists, it is a static Word document that is not updated when systems change - GoBD violation
• No versioning - changes to procedural documentation are not documented traceably - but GoBD Rz. 83 requires currency and traceability
• No approval - procedural documentation is never "approved" - but GoBD requires that the status at audit time is clear
• System changes not documented - when migrating to new software, procedural documentation is not updated - GoBD Rz. 146–150 expressly requires this

Key Statement

GoBD-compliant procedural documentation in a Git repo means:

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

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

What Is Procedural Documentation?

Mandatory Fields of Procedural Documentation

Structure in the Git Repo

ORG-1/
├── .gitcover/
│   ├── schemas/                    # Datenstrukturen (Rz. 86–91)
│   │   ├── diary-entry-1.0.schema.json
│   │   ├── v7g-sidecar-2.0.schema.json
│   │   └── timesheet-1.0.schema.json
│   ├── dictionaries/               # Klassifizierungen (Rz. 86–91)
│   │   ├── spheres.json
│   │   ├── roles.json
│   │   └── beleg-types.json
│   └── LEGAL_ENTITY.gc.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

Procedural Documentation as a JSON Artifact

The procedural 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 procedural documentation. The composite key V7GUID:uuidV7 serves storage organization and DB query. No separate datetime/date field - the time is contained 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 retroactively. This corresponds to GoBD Rz. 146 (immutability). With git show vd-v1.0-2026, the auditor can reconstruct the exact state of the procedural documentation at the time of the audit.

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

GoBD Rz. 146–150 requires the following when changing systems:

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

Practical Example: The entrepreneur (E1) migrates from cloud payroll software to GitCover. He creates a git bundle of the old data, updates the procedural documentation (new commit with 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 Procedural Documentation

The central insight: A Git repo is itself procedural documentation - git log shows the procedure, git config shows the system environment, Git hooks show the controls, schemas show the data structures. The formal procedural 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 ED07:

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

Sources

• GoBD (BMF letter, Rz. 64–91 - procedural documentation, Rz. 146–150 - system changes, Rz. 83 - currency)
• AO (§ 146 - organizational regulations, § 147 - retention)
• E1/agents/ (anonymized) - SSoT concept with procedural documentation as 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.