ED06 - Verfahrensdokumentation GoBD: Pflichtfelder, Versionierung, Freigabe

Problem

GoBD Rz. 64–91 verlangt eine Verfahrensdokumentation - aber im KMU-Bereich ist sie die große Ausnahme:

• "Was ist eine Verfahrensdokumentation?" - die meisten Unternehmer kennen den Begriff nicht, geschweige denn den Inhalt
• "Das macht der Steuerberater" - viele glauben, der StB erstellt die Verfahrensdoku - aber er kann nur anleiten, der Unternehmer muss sie selbst erstellen und pflegen
• Word-Dokument im Schreibtisch - wenn es eine Verfahrensdoku gibt, ist sie ein statisches Word-Dokument, das bei Systemwechsel nicht aktualisiert wird - GoBD-Verstoß
• Keine Versionierung - Änderungen an der Verfahrensdoku werden nicht nachvollziehbar dokumentiert - aber GoBD Rz. 83 verlangt Aktualität und Nachvollziehbarkeit
• Keine Freigabe - die Verfahrensdoku wird nie "freigegeben" - aber GoBD verlangt, dass der Stand zum Prüfungszeitpunkt klar ist
• Systemwechsel nicht dokumentiert - bei Migration zu neuer Software wird die Verfahrensdoku nicht fortgeschrieben - GoBD Rz. 146–150 verlangt das ausdrücklich

Kernaussage

Eine GoBD-konforme Verfahrensdokumentation im Git-Repo bedeutet:

1. Die Verfahrensdoku ist ein versioniertes Git-Artefakt - nicht ein Word-Dokument, sondern Markdown + JSON im Repo
2. Jede Änderung ist nachvollziehbar - git log zeigt Wer, Wann, Was, Warum (Commit-Autor, uuidV7-Zeitstempel, Diff, Commit-Message)
3. Freigabe durch Tags - ein Git-Tag markiert den freigegebenen Stand der Verfahrensdoku (z. B. vd-v1.0-2026)
4. Systemwechsel werden fortgeschrieben - bei Migration wird ein neuer Commit mit Begründung erstellt, die alte Version bleibt nachvollziehbar
5. Das Repo selbst ist Teil der Verfahrensdoku - git log zeigt das Verfahren, .gitcover/schemas/ zeigt die Datenstrukturen, Git-Hooks zeigen die Kontrollen

Compliance by Design: Die Verfahrensdokumentation ist nicht nachträglich - sie entsteht durch die Nutzung von Git. Wer mit Git-Repositories arbeitet, dokumentiert sein Verfahren automatisch durch Commits, Diffs und Tags. Die formelle Verfahrensdoku ergänzt dies um die menschenlesbare Beschreibung.

Was ist eine Verfahrensdokumentation?

Pflichtfelder der Verfahrensdokumentation

Struktur im 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

Verfahrensdoku als JSON-Artefakt

Die Verfahrensdoku selbst ist ein versioniertes Artefakt mit V7GUID (Class) und uuidV7 (Object ID als 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"]
}

Hinweis: Die uuidV7 ist die DocID der Verfahrensdoku. Der Composite Key V7GUID:uuidV7 dient der Ablage-Organisation und DB-Query. Kein separates datetime/date-Feld - die Zeit steckt in der uuidV7.

Versionierung und Freigabe

Wichtig - Tags als Freigabe-Marker: Ein Git-Tag ist unveränderbar

• er markiert einen exakten Commit-Stand, der nicht nachträglich geändert werden kann. Das entspricht GoBD Rz. 146 (Unveränderbarkeit). Der Prüfer kann mit git show vd-v1.0-2026 den exakten Stand der Verfahrensdoku zum Prüfungszeitpunkt rekonstruieren.

Systemwechsel und Migration (GoBD Rz. 146–150)

GoBD Rz. 146–150 verlangt bei Systemwechsel:

1. Daten des alten Systems verfügbar halten - git bundle als self-contained Archiv (kein Cloud-Account nötig, siehe ED04 Z3)
2. Verfahrensdokumentation fortgeschreiben - neuer Commit mit Begründung: "Migration von Cloud-Lohn zu GitCover, Datum, Rolle"
3. Übergangszeit dokumentieren - welche Daten wurden wie migriert, welche Prüfungen wurden durchgeführt
4. Alte Version als obsolet markieren - obsolescence: superseded_by im alten Verfahrensdoku-Artefakt

Praxis-Beispiel: Der Unternehmer (E1) migriert von einer Cloud-Lohnsoftware zu GitCover. Er erstellt einen git bundle der alten Daten, schreibt die Verfahrensdoku fort (neuer Commit mit Commit-Message "Migration zu GitCover, 260815, Rolle: GF"), markiert die alte Version als superseded und taggt die neue Version als vd-v2.0-2027. Der Prüfer kann beide Versionen nachvollziehen.

Das Repo selbst als Verfahrensdokumentation

Die zentrale Einsicht: Ein Git-Repo ist selbst eine Verfahrensdokumentation - git log zeigt das Verfahren, git config zeigt die Systemumgebung, Git-Hooks zeigen die Kontrollen, Schemata zeigen die Datenstrukturen. Die formelle Verfahrensdoku (Markdown in docs/verfahrensdokumentation/) ergänzt dies um die menschenlesbare Beschreibung - aber die autoritative Quelle ist das Repo selbst.

Risiko-Leverage

Harness-Anforderung (Vorschau)

Aus ED06 ableitbar:

Die vollständige Anforderungsliste in Harness-Anforderungen.md.

Quellen

• GoBD (BMF-Schreiben, Rz. 64–91 - Verfahrensdokumentation, Rz. 146–150 - Systemwechsel, Rz. 83 - Aktualität)
• AO (§ 146 - Ordnungsvorschriften, § 147 - Aufbewahrung)
• AFJD/agents/ (anonymisiert) - SSoT-Konzept mit Verfahrensdoku als Git-Artefakt

Quellen-Topologie und CDN-Referenz-Links

Hinweis: Diese Zuordnung von Quellen, Mirror und Community-Hub spiegelt den aktuellen Stand wider und kann sich ändern. Bitte prüfen Sie die jeweilige kanonische Quelle auf gitcover.org für den aktuellen Zustand.