ED05 - Fondamentaux GoBD : traçabilité, vérifiabilité, immutabilité
Problème
Un entrepreneur commence à tenir sa comptabilité - et se trouve face à la question : Que exige concrètement la GoBD, et comment y satisfaire sans logiciel spécialisé coûteux ?
La pratique actuelle dans les PME :
- La GoBD comme un livre scellé de sept sceaux - la GoBD (lettre du BMF, 146 pages) est abstraite, formulée en langage juridique, difficilement accessible aux non-initiés
- « C'est l'expert-comptable qui s'en charge » - beaucoup d'entrepreneurs délèguent la GoBD à leur expert-comptable (StB) sans comprendre eux-mêmes ce qui est exigé - et paient pour cela
- Des solutions isolées - logiciel de paie, comptabilité, archivage des justificatifs chacun séparément, sans conformité GoBD de bout en bout
- Le PDF comme « électronique » - beaucoup pensent qu'un PDF sur un disque dur satisfait à la GoBD - mais la GoBD exige une exploitabilité machine (§ 147 Abs. 6 AO), pas seulement un stockage
- Aucune documentation procédurale - GoBD Rz. 64–91 exige une documentation procédurale, mais qui en a une dans une PME ?
- Modifications a posteriori - des écritures sont « corrigées » sans que la modification soit traçable - GoBD Rz. 146 exige l'immutabilité
Message clé
La GoBD exige trois principes fondamentaux que Git satisfait par conception :
- Traçabilité (GoBD Rz. 146) - chaque entrée doit être traçable (Qui ? Quand ? Quoi ? Pourquoi ?)
- Vérifiabilité (GoBD Rz. 147) - la comptabilité doit être vérifiable (traçabilité rétrograde/progressive)
- Immutabilité (GoBD Rz. 146) - après l'écriture, les données ne doivent pas être modifiées (corrections sous forme de nouvelles entrées)
Git satisfait aux trois structurellement - non par des contrôles a posteriori, mais par l'architecture elle-même :
Rz. 146"] G --> P["Nachprüfbarkeit
Rz. 147"] G --> U["Unveränderbarkeit
Rz. 146"] N --> GN["Git: Commit-Autor
+ Zeitstempel
+ Commit-Message"] P --> GP["Git: V7GUID + SHA-256
retrograd/progressiv
auflösbar"] U --> GU["Git: Tags + Protected Branches
+ Obsoleszenz-Markierung
Korrekturen als neue Commits"] style G fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style N fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style P fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style U fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GN fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GP fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GU fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
Compliance by Design : la conformité GoBD ne naît pas d'un contrôle a posteriori, mais du choix du support. Qui travaille dans des dépôts Git satisfait à la traçabilité, à la vérifiabilité et à l'immutabilité structurellement - non par des contrôles supplémentaires.
GoBD - origine et portée
Les GoBD (principes pour la tenue régulière et la conservation de livres, registres et documents sous forme électronique ainsi que pour l'accès aux données) sont une lettre du BMF du 28.11.2019 (BStBl I S. 1269), modifiée en dernier lieu le 14.07.2025 (BStBl I S. 1502).
| Propriété | Valeur |
|---|---|
| Éditeur | Bundesministerium der Finanzen (BMF) |
| Nature juridique | Instruction administrative (pas une loi, mais contraignante pour les administrations fiscales) |
| Base | § 146 AO (règles d'ordre), § 147 AO (conservation), HGB (§§ 238–241) |
| Portée | Pour tous les entrepreneurs qui tiennent leur comptabilité par voie électronique (en pratique : tous) |
| Étendue | 146 numéros marginaux (Rz.) |
Important : les GoBD ne sont pas une « recommandation » - elles sont l'instruction administrative selon laquelle les administrations fiscales contrôlent. Qui ne satisfait pas à la GoBD risque une estimation d'office (§ 162 AO), des majorations de retard (§ 152 AO) et, dans le pire des cas, une procédure pénale fiscale (§ 370 AO).
Les trois principes fondamentaux de la GoBD en détail
1. Traçabilité (GoBD Rz. 146)
GoBD Rz. 146 : « La comptabilité doit être conçue de telle manière qu'un tiers expert puisse, en un temps raisonnable, obtenir une vue d'ensemble des opérations commerciales et de la situation de l'entreprise. »
Cela signifie : un vérificateur (ou un expert-comptable, ou un agent des impôts) doit pouvoir comprendre en un temps raisonnable ce qui s'est passé.
| Exigence GoBD | Comment Git y satisfait |
|---|---|
| Qui a comptabilisé ? | git log --author affiche chaque auteur de commit |
| Quand a-t-on comptabilisé ? | uuidV7 contient un horodatage de 48 bits (RFC 9562 §5.7) |
| Qu'a-t-on comptabilisé ? | Le diff de commit montre exactement ce qui a été ajouté/modifié |
| Pourquoi a-t-on comptabilisé ? | Le message de commit documente la justification |
| Dans quel rôle ? | Champ role dans l'artefact JSON (gérant, comptable, responsable R&D) |
Wer? Wann? Was?"] P --> SH["git show
Commit-Details"] P --> DF["git diff
Was hat sich geändert?"] P --> V7["uuidV7 decode
Exakte Erfassungszeit"] GL --> R["Nachvollziehbarkeit
in angemessener Zeit"] SH --> R DF --> R V7 --> R style P fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SH fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style DF fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style V7 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
2. Vérifiabilité (GoBD Rz. 147)
GoBD Rz. 147 : « La comptabilité doit être conçue de telle manière qu'elle soit vérifiable. »
Cela signifie : la comptabilité doit être traçable de manière rétrograde et progressive (voir ED03) :
- Rétrograde : de l'écriture comptable → la pièce justificative → l'écriture du journal → V7GUID
- Progressive : de la pièce justificative → l'écriture comptable → le livre journal → le bilan d'ouverture
| Exigence GoBD | Comment Git y satisfait |
|---|---|
| Traçabilité rétrograde | source_sha256 dans l'écriture du journal → pièce justificative |
| Traçabilité progressive | V7GUID dans la pièce justificative → écriture du journal → livre journal |
| Exploitabilité machine (§ 147 Abs. 6 AO) | JSON-Schema-First - données structurées, pas de PDF |
| Exhaustivité | Le hook pré-commit vérifie que chaque écriture du livre journal possède source_sha256 |
3. Immutabilité (GoBD Rz. 146)
GoBD Rz. 146 : « Les inscriptions ne doivent pas être modifiées d'une manière telle que le contenu d'origine ne soit plus constatable. »
Cela signifie : après l'écriture, les données ne doivent pas être modifiées. Les corrections doivent intervenir sous forme de nouvelles entrées avec justification.
| Exigence GoBD | Comment Git y satisfait |
|---|---|
| Aucune modification a posteriori | Les commits Git sont immuables (hash SHA-256) |
| Corrections sous forme de nouvelles entrées | Nouveaux commits avec obsolescence: superseded_by |
| Correction traçable | git log affiche l'original + la correction + la justification |
| Branches protégées | Branche main protégée, pas de force-push |
| Tags comme marqueurs de validation | Les tags marquent les états validés (immuables) |
Commit 1"] B --> TAG["Tag v1.0
freigegeben"] K["Korrektur nötig"] K --> C["Korrektur-Buchung
Commit 2"] C --> OBS["obsolescence:
status: superseded
superseded_by: Commit 2"] B --> OBS style B fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style TAG fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style K fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style C fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style OBS fill:#E5E7EB,stroke:#6B7280,color:#0F1B33
Important : Git permet techniquement
git rebaseetgit commit --amend
- mais seule une historique linéaire sans réécriture est conforme à la GoBD. Le hook pré-commit vérifie qu'aucun force-push n'est effectué sur
mainet que les corrections se font sous forme de nouveaux commits avec marquage d'obsolescence.
GoBD et AO - la base juridique
Ordnungsvorschriften
für Buchführung"] AO --> S147["§ 147 AO
Aufbewahrung
von Unterlagen"] S146 --> GoBD["GoBD
(BMF-Schreiben)
Konkretisierung
für elektronische Systeme"] S147 --> GoBD GoBD --> R146["Rz. 146
Nachvollziehbarkeit
Unveränderbarkeit"] GoBD --> R147["Rz. 147
Nachprüfbarkeit"] GoBD --> R64["Rz. 64–91
Verfahrensdokumentation"] GoBD --> R152["Rz. 152
Aufbewahrungsfristen"] style AO fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style S146 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S147 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GoBD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style R146 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R147 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R64 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R152 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
| Source juridique | Contenu | Lien avec la GoBD |
|---|---|---|
| § 146 Abs. 1 AO | Écritures « isolément, complètement, correctement, en temps utile et de manière ordonnée » | Rz. 146 (traçabilité) |
| § 146 Abs. 4 AO | Aucune modification rendant le contenu d'origine méconnaissable | Rz. 146 (immutabilité) |
| § 146 Abs. 5 AO | « disponible à tout moment et lisible sans délai » | Rz. 152 (disponibilité) |
| § 147 Abs. 2 AO | « pouvoir être exploitées par machine » | Rz. 147 (vérifiabilité) |
| § 147 Abs. 3 AO | Délais de conservation (10/8/6 ans) | Rz. 152 (conservation) |
| § 147 Abs. 6 AO | Accès aux données lors d'un contrôle externe (Z1/Z2/Z3) | Rz. 147 (accès aux données) |
Accès aux données GoBD (Z1, Z2, Z3)
La GoBD définit trois types d'accès que l'administration fiscale peut utiliser lors d'un contrôle externe :
| Type d'accès | Description | Comment Git le prend en charge |
|---|---|---|
| Z1 (accès direct) | Le vérificateur utilise le système de l'entrepreneur | git log, git show, git grep directement dans le dépôt |
| Z2 (accès indirect) | Le vérificateur donne des spécifications, l'entrepreneur effectue l'exploitation | git log --since, git grep, export JSON |
| Z3 (remise de support de données) | L'entrepreneur remet les données sur un support | git bundle comme archive autonome |
Z3 est la force de Git : un
git bundlecontient l'intégralité du dépôt (historique, commits, tags) dans un seul fichier - autonome, sans compte cloud, sans licence logicielle. Le vérificateur peut reconstruire le dépôt sur son système avecgit cloneet effectuer toutes les opérations Z1/Z2. C'est un export Z3 conforme à la GoBD « by Design ».
Extension GitCover : le web statique comme accès pour le vérificateur (Z3+)
Au-delà de git bundle, les outils GitCover (pour autant qu'ils soient installés
et utilisés) peuvent, dans le cadre d'une clôture de période, générer
à partir du Tenant Evidence Package un site web statique navigable dans un navigateur.
Ce site contient :
- Tous les documents DMS (justificatifs, factures, contrats) en HTML/PDF
- Contrats couvrant plusieurs périodes et documents de longue durée
- Évaluations (livre journal, journal, BWA, bilan)
- Prescriptions procédurales (documentation procédurale, plan de comptes)
- Sidecars (
.gc.mdavec V7GUID, SHA-256, taxonomie) - Preuves d'intégrité (manifeste avec sommes de contrôle)
(Periodenabschluss)"] EP --> GB["git bundle
(Z3-Basis)"] EP --> SW["Static-Web-Generator
(GitCover Tool)"] GB --> CL["git clone
(Prüfer rekonstruiert Repo)"] SW --> FS["Filesystem-Based-Web
(HTML + PDF + JSON)"] FS --> BR["Browser
(Prüfer navigiert)"] FS --> IDX["Index-Seiten
(nach Datum, Belegart, V7GUID)"] FS --> NAV["Navigation
(retrograd/progressiv)"] FS --> SRH["Suche
(Volltext, SHA-256, V7GUID)"] style EP fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GB fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SW fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style CL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style FS fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style BR fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style IDX fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style NAV fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style SRH fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
La méthode la plus sûre de toutes : un web basé sur le système de fichiers ne nécessite aucun système IAM, aucune infrastructure serveur, aucune base de données, aucune connexion réseau. Le vérificateur ouvre
index.htmldans son navigateur - hors ligne, localement, sans authentification. L'intégrité est garantie par le manifeste avec sommes de contrôle SHA-256, non par des droits d'accès. C'est la forme la plus sûre d'accès pour le vérificateur, car il n'y a aucune surface d'attaque.
| Propriété | git bundle (Z3) | Web statique (Z3+) |
|---|---|---|
| Le vérificateur a besoin de | Git installé | Un navigateur uniquement |
| Navigation | CLI (git log, git show) |
Navigateur (clic, recherche) |
| Évaluations | Manuellement via git grep |
Pages d'index pré-générées |
| Documents DMS | Dans le dépôt (PDF, XML) | Intégrés en HTML/PDF |
| Documentation procédurale | Markdown dans le dépôt | Rendu en HTML |
| Intégrité | SHA-256 Git | Manifeste + SHA-256 par fichier |
| IAM nécessaire | Non | Non |
| Réseau nécessaire | Non | Non |
| Surface d'attaque | Minimale | Minimale (système de fichiers uniquement) |
Exemple pratique : l'entrepreneur (
E1) crée la clôture de période pour FY2026. L'outil GitCover génère un Tenant Evidence Package avecgit bundle(pour les vérificateurs techniquement avertis) et un site web statique (pour les vérificateurs qui veulent seulement utiliser un navigateur). Les deux sont remis sur une clé USB - autonomes, hors ligne, sans IAM. Le vérificateur choisit lui-même s'il ouvregit cloneouindex.html.
Levier de risque
| Aujourd'hui (économique) | Demain (à l'épreuve de l'audit) | Risque réduit |
|---|---|---|
| Dépôt Git comme support de comptabilité | GoBD Rz. 146/147 satisfaites par conception | Estimation d'office § 162 AO |
git log comme preuve |
Traçabilité en un temps raisonnable | Contestation du caractère régulier |
| V7GUID + SHA-256 par entrée | Traçabilité rétrograde/progressive | Déclassement de la valeur probante |
| Tags + branches protégées | Immutabilité après validation | Non-conformité GoBD par modification a posteriori |
git bundle comme export Z3 |
Remise de support de données sans compte cloud | Non-conformité GoBD par systèmes anciens indisponibles |
| Marquage d'obsolescence | Corrections traçables | Modifications dissimulées |
| Web statique comme Z3+ (clôture de période) | Accès vérificateur sans IAM, navigateur uniquement | **Non-conformité GoBD par données inaccessibles/peu conviviales pour le vérificateur ** |
Exigence du harness (aperçu)
Déductible de ED05 :
| ID | Exigence | Priorité |
|---|---|---|
| FA-6.1 | Documentation procédurale comme artefact Git versionné | MUST |
| FA-6.2 | Livre journal (Journal) en JSON avec V7GUID + SHA-256 par entrée | MUST |
| FA-6.5 | Conservation sur 10 ans via des Evidence-Packages (Git-Bundles) | MUST |
| FA-6.6 | Immutabilité après validation (tags, branches protégées) | MUST |
| FA-6.7 | Générateur de web statique pour la clôture de période (Z3+) : site web navigable dans un navigateur à partir du Tenant Evidence Package, sans IAM, basé sur le système de fichiers | SHOULD |
| TA-2.1 | Pré-commit : validation du schéma JSON | MUST |
| TA-2.4 | Pré-commit : vérification du statut d'obsolescence (aucun commit sur obsolete) |
SHOULD |
La liste complète des exigences se trouve dans Harness-Anforderungen.md.
Sources
- GoBD (lettre du BMF du 28.11.2019, BStBl I S. 1269, modifiée en dernier lieu le 14.07.2025, BStBl I S. 1502)
- AO (§ 146 - règles d'ordre, § 147 - conservation, § 162 - estimation d'office, § 152 - majoration de retard)
- HGB (§§ 238–241 - obligation de tenir une comptabilité)
E1/agents/(anonymisé) - concept SSoT avec utilisation de Git conforme à la GoBDGitCover.Ledger/docs/02-Tenant-Evidence-Package.md- concept de Tenant Evidence Package (clôture de période, rôles du dépôt, règles d'exhaustivité)GitCover.Toolbox- ensemble d'outils GitCover (analyse, V7GUID, composants UI)
Topologie des sources et liens de référence CDN
| Rôle | Lieu | Objectif |
|---|---|---|
| Primaire / SSoT | git.gitcover.org/GCC | Dépôt canonique (signé GPG, versionné) |
| Miroir OSS public / CDN | codeberg.org/gitcover-commons | Miroir en lecture seule ; découverte FLOSS |
| Hub communautaire | github.com/gitcover-commons | Issues & Discussions ; référence du code source sur Codeberg |
Remarque : cette attribution des sources, du miroir et du hub communautaire reflète l'état actuel et peut changer. Veuillez vérifier la source canonique respective sur gitcover.org pour l'état actuel.