ED05 - Fondamentaux de la GoBD : traçabilité, vérifiabilité, inaltérabilité
Problème
Un entrepreneur se lance dans la tenue de la comptabilité et se pose la question : Que exige concrètement la GoBD, et comment y répondre sans logiciel spécialisé coûteux ?
La pratique actuelle dans le secteur des PME :
- La GoBD comme un livre aux sept sceaux - la GoBD (lettre du BMF, 146 pages) est abstraite, formulée en termes juridiques, difficilement accessible aux non-initiés
- « C’est l’affaire du conseiller fiscal » - de nombreux entrepreneurs délèguent la GoBD au StB, sans comprendre eux-mêmes ce qui est exigé - et le paient pour cela
- Solutions isolées - le logiciel de paie, la comptabilité et l’archivage des pièces justificatives sont gérés séparément, sans conformité GoBD de bout en bout
- Le PDF comme « électronique » - de nombreux pensent qu’un PDF sur un disque dur satisfait la GoBD - mais la GoBD exige une exploitabilité machine (§ 147 Abs. 6 AO), et pas seulement un stockage
- Absence de documentation des procédures - les GoBD Rz. 64–91 exigent une documentation des procédures, mais qui en dispose dans les PME ?
- Modifications a posteriori - les écritures sont « corrigées » sans que la modification soit traçable - les GoBD Rz. 146 exigent l’inaltérabilité
Message clé
La GoBD exige trois principes fondamentaux, que Git respecte 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 (suivi rétrograde/progressif)
- Inaltérabilité (GoBD Rz. 146) - après l’écriture, les données ne peuvent pas être modifiées (corrections sous forme de nouvelles entrées)
Git respecte les trois de manière structurelle - 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
Conformité par conception : la conformité GoBD ne résulte pas d’un contrôle a posteriori, mais du choix du support. Quiconque travaille dans des dépôts Git respecte la traçabilité, la vérifiabilité et l’inaltérabilité de manière structurelle - non grâce à des contrôles supplémentaires.
GoBD - Origine et champ d’application
La GoBD (principes relatifs à la tenue et à la conservation régulières des livres, des enregistrements et des documents sous forme électronique, ainsi qu’à l’accès aux données) est une lettre du BMF du 28.11.2019 (BStBl I S. 1269), dernièrement modifiée le 14.07.2025 (BStBl I S. 1502).
| Propriété | Valeur |
|---|---|
| Émetteur | Ministère fédéral des Finances (BMF) |
| Nature juridique | Instruction administrative (pas une loi, mais contraignante pour les services des impôts) |
| Base | § 146 AO (règles d’organisation), § 147 AO (conservation), HGB (§§ 238–241) |
| Champ d’application | Pour tous les entrepreneurs qui enregistrent leurs opérations de manière électronique (en pratique : tous) |
| Étendue | 146 points marginaux (Rz.) |
Important : la GoBD n’est pas une « recommandation » - elle constitue l’instruction administrative sur la base de laquelle les services des impôts contrôlent. Quiconque ne respecte pas la GoBD s’expose à une taxation d’office (§ 162 AO), à des majorations pour retard (§ 152 AO) et, dans le pire des cas, à des poursuites pénales fiscales (§ 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 établie de telle sorte qu’un tiers compétent puisse, dans un délai raisonnable, se faire une idée des opérations commerciales et de la situation de l’entreprise. »
Cela signifie : un auditeur (ou un conseiller fiscal, ou un agent fiscal) doit pouvoir reconstituer, dans un délai raisonnable, ce qui s’est passé.
| Exigence de la GoBD | Comment Git y répond |
|---|---|
| Qui a enregistré l’écriture ? | git log --author affiche l’auteur de chaque commit |
| Quand l’écriture a-t-elle été passée ? | uuidV7 contient un horodatage sur 48 bits (RFC 9562 §5.7) |
| Qu’est-ce qui a été enregistré ? | Le diff du commit montre exactement ce qui a été ajouté ou modifié |
| Pourquoi l’écriture a-t-elle été passée ? | Le message du commit documente la justification |
| Dans quel rôle ? | Le champ role de l’artefact JSON (GF, 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 établie de telle sorte qu’elle soit vérifiable. »
Cela signifie : la comptabilité doit pouvoir être suivie de manière rétrograde et progressive (voir ED03) :
- Rétrograde : de l’écriture comptable → de la pièce justificative → de l’écriture dans le journal → de la V7GUID
- Progressive : de la pièce justificative → de l’écriture comptable → du registre → du bilan d’ouverture
| Exigence de la GoBD | Comment Git y répond |
|---|---|
| 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 → registre |
| Exploitabilité machine (§ 147 Abs. 6 AO) | JSON-Schema-First - données structurées, pas de PDF |
| Exhaustivité | Le hook pre-commit vérifie que chaque entrée du registre comporte source_sha256 |
3. Inaltérabilité (GoBD Rz. 146)
GoBD Rz. 146 : « Les écritures ne doivent pas être modifiées d’une manière telle que le contenu initial ne puisse plus être déterminé. »
Cela signifie : après l’écriture, les données ne peuvent pas être modifiées. Les corrections doivent être effectuées sous forme de nouvelles entrées assorties d’une justification.
| Exigence de la GoBD | Comment Git y répond |
|---|---|
| Aucune modification a posteriori | Les commits Git sont inaltérables (hash SHA-256) |
| Corrections sous forme de nouvelles entrées | De nouveaux commits avec obsolescence: superseded_by |
| Correction traçable | git log affiche l’original + la correction + la justification |
| Branches protégées | La branche main est protégée, aucun push forcé |
| Tags comme marqueurs de validation | Les tags marquent les états validés (inaltérables) |
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 seul un historique linéaire sans réécriture est conforme à la GoBD. Le hook pre-commit vérifie qu’aucun push forcé n’est effectué sur
mainet que les corrections sont effectuées sous forme de nouveaux commits avec une marque 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 "séparément, intégralement, correctement, en temps utile et de manière ordonnée" | Rz. 146 (traçabilité) |
| § 146 Abs. 4 AO | Aucune modification rendant le contenu initial méconnaissable | Rz. 146 (inaltérabilité) |
| § 146 Abs. 5 AO | "disponibles à tout moment et immédiatement lisibles" | Rz. 152 (disponibilité) |
| § 147 Abs. 2 AO | "puissent être exploités de manière 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 audit 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 audit externe :
| Type d’accès | Description | Prise en charge par Git |
|---|---|---|
| Z1 (accès direct) | L’auditeur utilise le système de l’entrepreneur | git log, git show, git grep directement dans le dépôt |
| Z2 (accès indirect) | L’auditeur fournit des consignes, l’entrepreneur réalise l’exploitation | git log --since, git grep, export JSON |
| Z3 (remise du support de données) | L’entrepreneur remet les données sur un support | git bundle comme archive autonome |
Z3 est le point fort de Git : un
git bundlecontient l’ensemble du dépôt (historique, commits, tags) dans un seul fichier - autonome, aucun compte cloud, aucune licence logicielle. L’auditeur peut reconstruire le dépôt sur son système à l’aide degit cloneet effectuer toutes les opérations Z1/Z2. Il s’agit d’un export Z3 conforme à la GoBD "par conception".
Extension GitCover : site web statique comme accès pour l’auditeur (Z3+)
Au-delà de git bundle, les outils GitCover (s’ils sont installés et utilisés)
peuvent, dans le cadre d’une clôture de période, générer un site web
statique navigable dans un navigateur à partir du Tenant Evidence Package.
Ce site contient :
- Tous les documents du DMS (pièces justificatives, factures, contrats) en HTML/PDF
- Les contrats couvrant plusieurs périodes et les documents de longue durée
- Les analyses (registre, journal, BWA, bilan)
- Les règles de procédure (documentation des procédures, plan comptable)
- Les Sidecars (
.v7g.mdavec V7GUID, SHA-256, taxonomie) - Les 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 site web basé sur le système de fichiers ne nécessite aucun système IAM, aucune infrastructure serveur, aucune base de données et aucune connexion réseau. L’auditeur ouvre le fichier
index.htmldans son navigateur - hors ligne, en local, sans authentification. C’est le manifeste avec les sommes de contrôle SHA-256 qui garantit l’intégrité, et non les droits d’accès. Il s’agit de la forme la plus sûre d’accès pour l’auditeur, car il n’existe aucune surface d’attaque.
| Propriété | git bundle (Z3) | Static-Web (Z3+) |
|---|---|---|
| L’auditeur a besoin de | Git installé | Uniquement un navigateur |
| Navigation | CLI (git log, git show) |
Navigateur (clic, recherche) |
| Analyses | Manuellement via git grep |
Pages d’index pré-générées |
| Documents du DMS | Dans le dépôt (PDF, XML) | Intégrés en HTML/PDF |
| Documentation des procédures | Markdown dans le dépôt | Rendue en HTML |
| Intégrité | SHA-256 de 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) établit la clôture de période pour FY2026. L’outil GitCover génère un Tenant Evidence Package contenantgit bundle(pour les auditeurs techniquement avertis) et un site web statique (pour les auditeurs qui ne souhaitent utiliser qu’un navigateur). Les deux sont remis sur une clé USB - autonome, hors ligne, sans IAM. L’auditeur choisit lui-même s’il utilisegit cloneou s’il ouvreindex.html.
Levier de réduction des risques
| Aujourd’hui (peu coûteux) | Demain (résistant aux révisions) | Risque réduit |
|---|---|---|
| Dépôt Git comme support comptable | Exigences GoBD Rz. 146/147 respectées par conception | Taxation d’office (§ 162 AO) |
git log comme justificatif |
Traçabilité dans un délai raisonnable | Contestation de la régularité |
| V7GUID + SHA-256 par entrée | Traçabilité rétrograde/progressive | Dépréciation de la valeur probante |
| Tags + branches protégées | Inaltérabilité après validation | Violation de la GoBD par une modification a posteriori |
git bundle comme export Z3 |
Remise d’un support de données sans compte cloud | Violation de la GoBD par des anciens systèmes indisponibles |
| Marque d’obsolescence | Corrections traçables | Modifications dissimulées |
| Site statique comme Z3+ (clôture de période) | Accès de l’auditeur sans IAM, navigateur uniquement | **Violation de la GoBD par des données inaccessibles ou peu adaptées à l’auditeur ** |
Exigence du harness (aperçu)
Déductible d’ED05 :
| ID | Exigence | Priorité |
|---|---|---|
| FA-6.1 | Documentation des procédures comme artefact Git versionné | MUST |
| FA-6.2 | Registre (journal) au format JSON avec V7GUID + SHA-256 par entrée | MUST |
| FA-6.5 | Conservation pendant 10 ans via Evidence-Packages (Git-Bundles) | MUST |
| FA-6.6 | Inaltérabilité après validation (tags, branches protégées) | MUST |
| FA-6.7 | Générateur de site 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 | Pre-Commit : validation du schéma JSON | MUST |
| TA-2.4 | Pre-Commit : contrôle du statut d’obsolescence (aucun commit sur obsolete) |
SHOULD |
La liste complète des exigences figure dans Harness-Anforderungen.md.
Sources
- GoBD (lettre du BMF du 28.11.2019, BStBl I S. 1269, dernière modification le 14.07.2025, BStBl I S. 1502)
- AO (§ 146 - règles d’organisation, § 147 - conservation, § 162 - taxation d’office, § 152 - majoration pour retard)
- HGB (§§ 238–241 - obligation de tenir une comptabilité)
E1/agents/(anonymisé) - concept SSoT avec une 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- boîte à outils GitCover (analyse, V7GUID, composants d’interface utilisateur)
Topologie des sources et liens de référence CDN
| Rôle | Emplacement | Finalité |
|---|---|---|
| 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 |
| Community Hub | github.com/gitcover-commons | Issues & Discussions ; référence du code source sur Codeberg |
Remarque : cette attribution des sources, du miroir et du Community Hub reflète l’état actuel et peut changer. Veuillez vérifier l’état actuel de la source canonique correspondante sur gitcover.org.