ED07 - Documentation des procédures GoBD : champs obligatoires, versionnement, validation

Problème

GoBD Rz. 64–91 exige une documentation des procédures - mais dans le secteur des PME, elle constitue la grande exception :

• « Qu’est-ce qu’une documentation des procédures ? » - la plupart des entrepreneurs ne connaissent pas le terme, encore moins son contenu
• « C’est le conseiller fiscal qui le fait » - beaucoup pensent que le StB établit la documentation des procédures - mais il ne peut que guider, l’entrepreneur doit lui-même la créer et l’entretenir
• Document Word sur le bureau - s’il existe une documentation des procédures, c’est un document Word statique, qui n’est pas actualisé lors d’un changement de système - violation des GoBD
• Aucun versionnement - les modifications de la documentation des procédures ne sont pas documentées de manière traçable - mais GoBD Rz. 83 exige l’actualisation et la traçabilité
• Aucune validation - la documentation des procédures n’est jamais « validée » - mais GoBD exige que l’état au moment de l’audit soit clair
• Changement de système non documenté - lors d’une migration vers un nouveau logiciel, la documentation des procédures n’est pas mise à jour - GoBD Rz. 146–150 l’exige expressément

Message clé

Une documentation des procédures conforme aux GoBD dans un dépôt Git signifie :

1. La documentation des procédures est un artefact Git versionné - non un document Word, mais Markdown + JSON dans le dépôt
2. Chaque modification est traçable - git log montre qui, quand, quoi, pourquoi (auteur du commit, horodatage uuidV7, diff, message de commit)
3. Validation par tags - un tag Git marque l’état validé de la documentation des procédures (p. ex. vd-v1.0-2026)
4. Les changements de système sont consignés - lors d’une migration, un nouveau commit avec justification est créé, l’ancienne version reste traçable
5. Le dépôt lui-même fait partie de la documentation des procédures - git log montre la procédure, .gitcover/schemas/ montre les structures de données, les hooks Git montrent les contrôles

Compliance by Design : La documentation des procédures n’est pas ajoutée après coup - elle naît de l’utilisation de Git. Ceux qui travaillent avec des dépôts Git documentent leur procédure automatiquement par des commits, des diffs et des tags. La documentation formelle des procédures la complète par la description lisible par l’homme.

Qu’est-ce qu’une documentation des procédures ?

Champs obligatoires de la documentation des procédures

Structure dans le dépôt Git

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

Documentation des procédures comme artefact JSON

La documentation des procédures est elle-même un artefact versionné avec V7GUID (Class) et uuidV7 (Object ID comme 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"]
}

Remarque : La uuidV7 est la DocID de la documentation des procédures. La clé composite V7GUID:uuidV7 sert à l’organisation du stockage et aux requêtes DB. Pas de champ datetime/date séparé - le temps se trouve dans la uuidV7.

Versionnement et validation

Important - les tags comme marqueurs de validation : Un tag Git est immuable

• il marque un état exact de commit, qui ne peut pas être modifié après coup. Cela correspond à GoBD Rz. 146 (immuabilité). L’auditeur peut avec git show vd-v1.0-2026 reconstruire l’état exact de la documentation des procédures au moment de l’audit.

Changement de système et migration (GoBD Rz. 146–150)

GoBD Rz. 146–150 exige lors d’un changement de système :

1. Maintenir les données de l’ancien système disponibles - git bundle comme archive autonome (aucun compte cloud nécessaire, voir ED05 Z3)
2. Mettre à jour la documentation des procédures - nouveau commit avec justification : « Migration de Cloud-Lohn vers GitCover, date, rôle »
3. Documenter la période de transition - quelles données ont été migrées et comment, quels contrôles ont été effectués
4. Marquer l’ancienne version comme obsolète - obsolescence: superseded_by dans l’ancien artefact de documentation des procédures

Exemple pratique : L’entrepreneur (E1) migre d’un logiciel de paie cloud vers GitCover. Il crée un git bundle des anciennes données, met à jour la documentation des procédures (nouveau commit avec message de commit « Migration vers GitCover, 260815, rôle : GF »), marque l’ancienne version comme superseded et tague la nouvelle version comme vd-v2.0-2027. L’auditeur peut reconstituer les deux versions.

Le dépôt lui-même comme documentation des procédures

L’idée centrale : Un dépôt Git est lui-même une documentation des procédures - git log montre la procédure, git config montre l’environnement système, les hooks Git montrent les contrôles, les schémas montrent les structures de données. La documentation formelle des procédures (Markdown dans docs/verfahrensdokumentation/) la complète par la description lisible par l’homme

• mais la source faisant autorité est le dépôt lui-même.

Levier de risque

Exigence de harness (aperçu)

Déductible de ED07 :

La liste complète des exigences se trouve dans Harness-Anforderungen.md.

Sources

• GoBD (circulaire BMF, Rz. 64–91 - documentation des procédures, Rz. 146–150 - changement de système, Rz. 83 - actualisation)
• AO (§ 146 - prescriptions d’ordre, § 147 - conservation)
• E1/agents/ (anonymisé) - concept SSoT avec documentation des procédures comme artefact Git

Topologie des sources et liens de référence CDN

Remarque : Cette attribution des sources, du miroir et du community hub reflète l’état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour l’état actuel.