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

Problème

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

• « Qu'est-ce qu'une documentation des procédures ? » - la plupart des entrepreneurs ne connaissent pas le terme, et encore moins son contenu
• « C'est le conseiller fiscal qui s'en occupe » - beaucoup pensent que le StB établit la documentation des procédures - mais il ne peut que donner des directives ; l'entrepreneur doit l'établir et la tenir à jour lui-même
• Document Word dans le tiroir - 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
• Aucune gestion des versions - les modifications de la documentation des procédures ne sont pas documentées de manière traçable - or les GoBD Rz. 83 exigent actualité et traçabilité
• Aucune validation - la documentation des procédures n'est jamais « validée » - or les GoBD exigent que l'état au moment du contrôle soit clairement établi
• Changement de système non documenté - lors d'une migration vers un nouveau logiciel, la documentation des procédures n'est pas tenue à jour - les GoBD Rz. 146–150 l'exigent expressément

Message clé

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

1. La documentation des procédures est un artefact Git versionné - non pas 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 documentés en continu - 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 le processus, .gitcover/schemas/ montre les structures de données, les Git-Hooks montrent les contrôles

Compliance by Design : la documentation des procédures n'est pas un exercice rétrospectif - elle naît de l'utilisation de Git. Quiconque travaille avec des dépôts Git documente automatiquement son processus au moyen de commits, de diffs et de tags. La documentation formelle des procédures complète cela par la description lisible par l'humain.

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/                    # Structures de données (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       # Identité du tenant
├── docs/
│   └── verfahrensdokumentation/
│       ├── README.md               # Introduction + vue d'ensemble
│       ├── 01-verfahren.md         # Processus comptable (Rz. 64–71)
│       ├── 02-systemumgebung.md    # Logiciel/Matériel (Rz. 72–76)
│       ├── 03-organisation.md      # Responsabilités (Rz. 77–80)
│       ├── 04-kontrollen.md        # Contrôles internes (Rz. 81–85)
│       └── 05-daten.md             # Structures de données (Rz. 86–91)
└── .githooks/
    ├── pre-commit                  # Contrôles (Rz. 81–85)
    └── post-commit                 # Génération de l'index

La documentation des procédures comme artefact JSON

La documentation des procédures elle-même est 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>",
  "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"]
}

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 est contenu dans la uuidV7.

Gestion des versions et validation

Important - les tags comme marqueurs de validation : un tag Git est immuable - il marque un état de commit exact qui ne peut pas être modifié a posteriori. Cela correspond aux GoBD Rz. 146 (immuabilité). Le vérificateur peut reconstituer avec git show vd-v1.0-2026 l'état exact de la documentation des procédures au moment du contrôle.

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

Les GoBD Rz. 146–150 exigent en cas de changement de système :

1. Maintenir disponibles les données de l'ancien système - git bundle comme archive self-contained (aucun compte cloud nécessaire, voir ED05 Z3)
2. Tenir à 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 en cloud vers GitCover. Il crée un git bundle des anciennes données, met à jour la documentation des procédures (nouveau commit avec le message de commit « Migration vers GitCover, 260815, rôle : GF »), marque l'ancienne version comme superseded et taggue la nouvelle version vd-v2.0-2027. Le vérificateur peut retracer 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 le processus, git config montre l'environnement système, les Git-Hooks montrent les contrôles, les schémas montrent les structures de données. La documentation formelle des procédures (Markdown dans docs/verfahrensdokumentation/) complète cela par la description lisible par l'humain - mais la source faisant autorité est le dépôt lui-même.

Levier de risques

Exigences Harness (aperçu)

Déductible de ED07 :

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

Sources

• GoBD (lettre du BMF, Rz. 64–91 - documentation des procédures, Rz. 146–150 - changement de système, Rz. 83 - actualité)
• AO (§ 146 - règles de forme, § 147 - conservation)
• AFJD/agents/ (anonymisé) - concept SSoT avec la documentation des procédures comme artefact Git

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

Remarque : cette répartition entre sources, miroir et hub communautaire reflète l'état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour connaître l'état actuel.