ED06 - GoBD Procedure Documentation: Mandatory Fields, Versioning, Release

Problem

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

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

Core Statement

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

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

Compliance by Design: The procedure documentation is not retroactive - it emerges through the use of Git. Anyone working with Git repositories documents their procedure automatically through commits, diffs and tags. The formal procedure documentation complements this with the human-readable description.

What is a procedure documentation?

Mandatory fields of the procedure documentation

Structure in the Git repo

ORG-1/
├── .gitcover/
│   ├── schemas/                    # Data structures (Rz. 86-91)
│   │   ├── diary-entry-1.0.schema.json
│   │   ├── v7g-sidecar-1.0.schema.json
│   │   └── timesheet-1.0.schema.json
│   ├── dictionaries/               # Classifications (Rz. 86-91)
│   │   ├── spheres.json
│   │   ├── roles.json
│   │   └── beleg-types.json
│   └── LEGAL_ENTITY.v7g.json       # Tenant identity
├── docs/
│   └── verfahrensdokumentation/
│       ├── README.md               # Entry + overview
│       ├── 01-verfahren.md         # Accounting procedure (Rz. 64-71)
│       ├── 02-systemumgebung.md    # Software/hardware (Rz. 72-76)
│       ├── 03-organisation.md      # Responsibilities (Rz. 77-80)
│       ├── 04-kontrollen.md        # Internal controls (Rz. 81-85)
│       └── 05-daten.md             # Data structures (Rz. 86-91)
└── .githooks/
    ├── pre-commit                  # Controls (Rz. 81-85)
    └── post-commit                 # Index generation

Procedure documentation as JSON artifact

The procedure 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 procedure documentation. The composite key V7GUID:uuidV7 serves the storage organization and DB query. No separate datetime/date field - the time is contained in the uuidV7.

Versioning and release

Important - tags as release markers: A Git tag is immutable

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

System change and migration (GoBD Rz. 146-150)

GoBD Rz. 146-150 requires on system change:

1. Keep data of the old system available - git bundle as self-contained archive (no cloud account needed, see ED04 Z3)
2. Continue procedure documentation - new commit with justification: "Migration from cloud payroll to GitCover, date, role"
3. Document transition period - which data was migrated how, which checks were performed
4. Mark old version as obsolete - obsolescence: superseded_by in the old procedure documentation artifact

Practical example: The entrepreneur (E1) migrates from a cloud payroll software to GitCover. He creates a git bundle of the old data, continues the procedure 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 procedure documentation

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

Risk-Leverage

Harness requirement (preview)

Derivable from ED06:

The complete requirement list in Harness-Anforderungen.md.

Sources

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