ED01 - Motivation : pourquoi un entrepreneur tient son journal dans Git
Problème
Un entrepreneur fonde une organisation - et se trouve confronté à un tableau flou des risques qui surviendront à l'avenir. Quelles obligations naissent, et quand ? Quels justificatifs faut-il conserver, et pendant combien de temps ? Quels délais risquent d'être manqués ? Quelles autorités s'annoncent, quand et pour quel contrôle ?
La pratique actuelle dans le secteur des PME est marquée par :
- Papierasserie et listes Excel locales - ni traçables, ni à l'épreuve des audits
- Chaos PDF et e-mails lors des contrôles - les documents sont assemblés ad hoc à la hâte
- Solutions en silos (logiciel de paie ici, comptabilité là, archive de justificatifs ailleurs) - sans chaîne de preuves continue
- Lacunes open source pour les obligations particulières (temps de travail, frais de déplacement, primes, BEM, FZul/BSFZ, utilité publique) - il n'existe ici pratiquement aucun soutien libre
- Accumulation de risques - les obligations sont aujourd'hui ignorées cheap, pour devenir demain coûteuses sous forme d'amendes, de majorations pour retard ou de retraits
Tag 0"] --> B["Pflichten
unklar"] B --> C["Heute cheap
ignoriert"] C --> D["Morgen teuer
Bußgeld/Aberkennung"] D --> E["Risiko
realisiert"] style A fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style B fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style C fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style D fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#FF3333,stroke:#0F1B33,color:#FBFAF7
Message clé
Non seulement les documents doivent être à l'épreuve des audits - les décisions, les délais et les références de justificatifs doivent aussi être traçables, reproductibles et auditables. Un journal natif Git fait exactement cela : il transforme des faits saisis aujourd'hui de manière cheap (peu coûteuse) (une entrée JSON avec V7GUID + référence de justificatif SHA-256) en futures preuves à l'épreuve des audits. La conformité devient un levier, pas un frein.
Compliance by Design : le « tableau flou » des risques futurs est atténué dès le départ par les techniques GitCover (OSCAL, OPA, V7GUID, Git-Hooks), et non seulement quand le contrôleur sonne.
Genèse : le contrôle SV comme déclencheur pratique
L'idée GitCover n'est pas née dans une tour d'ivoire, mais d'expériences pratiques concrètes : en dernier lieu, d'un contrôle d'entreprise SV auprès d'une micro-UG (anonymisée ici sous ORG-V pour « organisation précurseur ») portant sur la période 2021–2023 ; déroulé sur la période 02/2024–03/2025. Le contrôle a révélé des points sensibles que les techniques GitCover adressent.
Chronologie du contrôle SV
Que s'est-il passé ?
| Date | Événement | Statut |
|---|---|---|
| 02/2024 | La DRV annonce un contrôle d'entreprise selon § 28p SGB IV | ⏳ |
| 12/2024 | La DRV demande les documents de contrôle (comptes de salaires 2021–2023, questionnaire, lettre d'accompagnement) | ⏳ |
| 12/2024 | Les documents sont assemblés en PDF/ZIP et envoyés par e-mail | ✅ |
| 02/2025 | La DRV transmet les résultats du contrôle (audition § 24 SGB X, tableau des totaux globaux, annexes HEK/Minijob-Zentrale) | ✅ |
| 02/2025 | Acceptation sans réserves ; demande de remboursement déposée auprès de la caisse d'assurance maladie | ✅ |
| 03/2025 | Contrôle SV terminé - idée GitCover née | ✅ |
Résultat financier (net)
| Poste | Montant |
|---|---|
| Remboursement des cotisations U1 versées en trop | +121 EUR |
| Réclamation de cotisations forfaitaires d'assurance maladie | −30 EUR |
| Remboursement net | +91 EUR |
| Coûts du prestataire | >100 EUR |
| Effort | plusieurs jours d'assemblage manuel |
Points sensibles - ce que le contrôle a révélé
Prüfung nur per E-Mail"] P2["Beleg-Echtheit unklar
PDFs ohne kryptographische Verankerung"] P3["Keine Nachweiskette
Lohnkonten/SV/Erstattung an verschiedenen Orten"] P4["Fristen ad-hoc
manuell im Kalender gepflegt"] P5["Audit-Export fehlt
euBP/eXTra, Z3 nur mit Spezialsoftware"] P6["Lohn-Account pausiert
nach Mitarbeiter-Ausscheiden
Extra-Kosten > Erstattung"] P7["Alte Sicherungen
alter Software-Stand
GoBD-Auflage verletzt"] P1 --> G["GitCover-Idee
geboren"] P2 --> G P3 --> G P4 --> G P5 --> G P6 --> G P7 --> G G --> S["GitCover-Lösungen
SHA-256+V7GUID, Hooks, Fristen-Check
Evidence-Packages, Git-Bundles self-contained"] style P1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P7 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style G fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
- Pas de bureau, pas de fax, pas de salarié - et pourtant il a fallu traiter un contrôle d'entreprise purement par e-mail avec des fichiers PDF et ZIP. Les outils n'existaient pas pour ce cas minimal.
- Authenticité des justificatifs incertaine - les PDF par e-mail n'ont aucun ancrage cryptographique. Qui a modifié quoi, et quand ? La force probante n'était garantie que par une traçabilité manuelle.
- Aucune chaîne de preuves continue - comptes de salaires, déclarations SV, justificatifs de cotisations et justificatifs de remboursement se trouvaient à des endroits différents, sans renvois croisés. Chaque demande d'information exigeait de nouvelles recherches.
- Gestion des délais ad hoc - délais d'audition, délais de remboursement, délais de recours étaient gérés manuellement dans le calendrier. Aucun avertissement en cas d'expiration imminente.
- Export d'audit manquant - la DRV exigeait des données au format euBP (eXTra V3.4.0) ; l'administration fiscale aurait exigé un support de données Z3. Les deux n'étaient possibles qu'avec un logiciel spécialisé ou une préparation manuelle.
- Départ du salarié → compte de paie suspendu - après le départ du salarié de l'époque, le compte de paie auprès du prestataire a été suspendu. Qui maintient inutilement, source de coûts, un compte cloud lorsque la raison n'existe plus (salarié parti, plus aucune paie à établir) ? Mais la constitution du paquet de documents pour le contrôle a alors entraîné des coûts supplémentaires auprès du prestataire, qui se sont révélés à la fin plus élevés que le petit « remboursement » à l'issue du contrôle.
- Réactivation d'anciennes sauvegardes avec une ancienne version logicielle - pour rendre à nouveau accessibles les comptes de salaires 2021–2023, les anciennes sauvegardes ont dû être réactivées avec l'ancienne version logicielle - un problème pratique considérable. C'est formellement une violation de l'exigence GoBD que de ne pas garantir techniquement un accès permanent pendant la longue période de conservation (10 ans). En pratique, cette obligation entre en conflit avec la pression de gestion consistant à ne pas maintenir des comptes cloud inutilisés, sources de coûts. C'est précisément cette tension qui est un motif central de GitCover : les Git-Bundles sont self-contained - ils n'ont besoin ni de comptes cloud, ni de contrats de prestataires, ni de versions logicielles. Un
git clonesuffit, et le délai de conservation est techniquement rempli.
Bases juridiques : AO § 146, § 147 et GoBD
La « violation de l'exigence GoBD » évoquée au point 7 a une base juridique claire - dans l'Abgabenordnung (AO) et dans les GoBD (principes relatifs à la tenue et à la conservation conformes des livres, des enregistrements et des documents sous forme électronique ainsi qu'à l'accès aux données, lettre-circulaire BMF).
AO § 146 Abs. 5 - Disponibilité pendant le délai de conservation
« Lors de la tenue des livres et des autres enregistrements nécessaires sur des supports de données, il doit notamment être garanti que pendant toute la durée du délai de conservation, les données sont disponibles à tout moment et peuvent être rendues lisibles sans délai. »
C'est la disposition centrale : quiconque comptabilise électroniquement doit garantir pendant toute la durée du délai de conservation (10 ans pour les livres/enregistrements, 8 ans pour les justificatifs comptables, § 147 Abs. 3 AO) que les données sont disponibles à tout moment et lisibles sans délai. Un compte cloud suspendu, qui n'est réactivé que contre des coûts supplémentaires, viole cette obligation - les données ne sont pas « disponibles à tout moment », mais seulement contre paiement et avec retard.
AO § 147 Abs. 2 - Conservation sur supports de données
« À l'exception des comptes annuels [...], les documents énumérés au paragraphe 1 peuvent également être conservés sous forme de reproduction sur un support d'image ou sur d'autres supports de données, à condition que cela soit conforme aux principes d'une comptabilité régulière et qu'il soit garanti que la reproduction ou les données [...] soient disponibles à tout moment, puissent être rendues lisibles sans délai et exploitées automatiquement pendant toute la durée du délai de conservation. »
Encore : « disponibles à tout moment », « lisibles sans délai », « exploitables automatiquement ». Une ancienne version logicielle qui doit d'abord être réactivée ne satisfait pas au « sans délai ».
AO § 147 Abs. 5 - Moyens aux frais du contribuable
« Quiconque présente des documents à conserver sous forme de reproduction sur un support d'image ou sur d'autres supports de données est tenu de mettre à disposition, à ses frais, les moyens nécessaires pour rendre les documents lisibles. »
Cela signifie : si le prestataire ne maintient plus l'ancien système, l'entrepreneur doit lui-même fournir les moyens (logiciels, licences, matériel) pour rendre les données lisibles. C'est exactement le problème pratique du cas de genèse : anciennes sauvegardes, ancienne version logicielle, plus aucun moyen disponible.
AO § 147 Abs. 6 - Accès aux données lors d'un contrôle externe
« Si les documents visés au paragraphe 1 ont été établis à l'aide d'un système de traitement de données, l'administration fiscale peut, dans le cadre d'un contrôle externe [...], exiger que les données soient mises à disposition sous une forme exploitable automatiquement selon ses spécifications. »
Lors d'un contrôle externe, l'entrepreneur doit mettre les données à disposition sous une forme exploitable automatiquement - non pas sous forme d'impression PDF, mais comme données structurées. Un compte cloud suspendu qui n'offre qu'un export PDF ne suffit pas.
GoBD - Documentation des procédures et changement de système
Les GoBD concrétisent ces dispositions de l'AO pour les systèmes électroniques. Exigences centrales :
- Documentation des procédures (GoBD Rz. 64–91) : chaque système comptable électronique doit disposer d'une documentation des procédures décrivant le processus, l'environnement système, les mesures organisationnelles et les contrôles internes. En cas de changement de système, la documentation des procédures doit être mise à jour.
- Changement de système/migration (GoBD Rz. 146–150) : lors d'un changement de système, il faut garantir que les données de l'ancien système restent disponibles, lisibles et exploitables automatiquement. La documentation des procédures doit documenter le changement.
- Immuabilité (GoBD Rz. 146) : après la comptabilisation, les données ne doivent pas être modifiées. Les corrections doivent s'effectuer sous forme de nouvelles entrées avec justification.
Conséquences théoriques en cas de violation
AO § 146/147 + GoBD"] V --> K1["Verspätungszuschlag
§ 152 AO
bis 25.000 EUR"] V --> K2["Schätzung
§ 162 AO
bei nicht verwertbaren Daten"] V --> K3["Verzögerungsgeld
§ 146 Abs. 2c AO
2.500–250.000 EUR"] V --> K4["Beweislastumkehr
FA schätzt, Unternehmer
muss widerlegen"] V --> K5["Ordnungswidrigkeit
§ 379 AO
Bußgeld bis 50.000 EUR"] V --> K6["Steuerstrafverfahren
§ 370 AO
bei vorsätzlicher Verkürzung"] style V fill:#FF1A1A,stroke:#0F1B33,color:#FBFAF7 style K1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33
| Conséquence | Base juridique | Montant/risque |
|---|---|---|
| Majoration pour retard | § 152 AO | jusqu'à 25 000 EUR (cas par cas) |
| Estimation des bases d'imposition | § 162 AO | l'administration fiscale estime lorsque les données ne sont pas exploitables - souvent au détriment de l'entrepreneur |
| Amende pour retardement | § 146 Abs. 2c AO | 2 500–250 000 EUR (en cas d'externalisation sans autorisation) |
| Inversion de la charge de la preuve | § 162 AO, § 90 AO | l'entrepreneur doit réfuter l'estimation - quasi impossible en l'absence de données |
| Contravention | § 379 AO | amende jusqu'à 50 000 EUR (intentionnellement ou par négligence) |
| Procédure pénale fiscale | § 370 AO | emprisonnement jusqu'à 5 ans (en cas de fraude fiscale intentionnelle) |
Mise en perspective pratique : dans le cas de genèse, le contrôle SV a été accepté sans réserves - aucune conséquence n'en est résultée. Mais c'était une chance : si la DRV n'avait pas accepté les données en PDF mais avait insisté sur une exploitation automatique (§ 147 Abs. 6 AO), l'entrepreneur se serait retrouvé en mauvaise posture pour s'expliquer. La conservation conforme aux GoBD n'est pas une obligation théorique - elle devient réalité à chaque contrôle externe.
Pourquoi Git résout le problème
Git satisfait les exigences AO/GoBD by Design :
| Exigence AO/GoBD | Comment Git y répond |
|---|---|
| « disponible à tout moment » (§ 146 Abs. 5) | git clone possible à tout moment - pas de compte cloud, pas de licence |
| « lisible sans délai » (§ 147 Abs. 2) | fichiers en texte clair (Markdown, JSON) - aucune version logicielle nécessaire |
| « exploitable automatiquement » (§ 147 Abs. 6) | JSON-Schema-First - données structurées, aucun export PDF nécessaire |
| « moyens aux frais de l'entrepreneur » (§ 147 Abs. 5) | Git est OSS, gratuit - aucun coût de prestataire |
| Immuabilité (GoBD Rz. 146) | Tags, Protected Branches, marquage d'obsolescence |
| Documentation des procédures (GoBD Rz. 64–91) | le repo lui-même est la documentation des procédures - git log montre le processus |
| Changement de système/migration (GoBD Rz. 146–150) | Git est indépendant des versions - git clone sur chaque système |
Facture électronique : les formats XML sont des documents originaux au sens de l'AO
Depuis le 1er janvier 2025, la facture électronique est obligatoire pour les opérations entre entreprises nationales (§ 14 UStG, Wachstumschancengesetz). Une facture électronique n'existe que si elle est émise, transmise et reçue dans un format électronique structuré et si elle permet un traitement électronique (§ 14 Abs. 1 Satz 3 UStG). Un simple document PDF n'y entre plus - il constitue depuis 2025 une « autre facture ».
vor 2025"] --> U["Übergang
2025–2027"] PDF["PDF per E-Mail
vor 2025 'elektronisch'"] --> U U --> E["E-Rechnung
ab 2025 verpflichtend
strukturiert, maschinenlesbar"] E --> X["XRechnung
XML-basiert
EN 16931"] E --> Z["ZUGFeRD
hybrid: PDF + XML
ab v2.0.1"] style P fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style PDF fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style U fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style X fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Z fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
XML est le document original - pas le PDF
Le point décisif pour la conservation : pour une facture électronique, c'est la partie structurée (XML) qui constitue le document original au sens de l'AO, et non un éventuel PDF joint ou une image lisible par l'humain. Le BMF précise (FAQ sur la facture électronique, question 13) :
« Pour une facture électronique, du moins sa partie structurée doit être conservée de telle sorte qu'elle soit intacte dans sa forme d'origine. »
Cela signifie :
- XRechnung (basée sur XML, EN 16931) : le fichier XML est le document original. Il doit être conservé sans modification. Une visualisation PDF n'est qu'un affichage auxiliaire - elle ne remplace pas le XML.
- ZUGFeRD (hybride : PDF + XML intégré) : en cas de divergences entre la partie XML et la partie image, c'est depuis 2025 la partie structurée (XML) qui fait foi (BMF FAQ question 12a). L'image PDF n'est plus déterminante.
AO § 147 - La facture électronique comme justificatif comptable
Les factures électroniques sont des justificatifs comptables au sens du § 147 Abs. 1 Nr. 4 AO et doivent à ce titre être conservées huit ans (§ 147 Abs. 3 AO). En tant que documents électroniques, les exigences AO/GoBD s'appliquent :
- Disponible à tout moment (§ 147 Abs. 2) : le fichier XML doit être accessible pendant toute la durée du délai de conservation.
- Lisible sans délai (§ 147 Abs. 2) : une visionneuse XML ou la visionneuse ELSTER pour factures électroniques (
www.e-rechnung.elster.de) rend le fichier lisible - mais le XML lui-même est en texte clair et donc lisible même sans logiciel spécialisé. - Exploitable automatiquement (§ 147 Abs. 6) : le XML est par définition lisible par machine - idéal pour § 147 Abs. 6 (accès aux données lors d'un contrôle externe).
- Intact (§ 14b Abs. 1 UStG) : le fichier XML ne doit pas être modifié. Git le garantit par l'immuabilité après commit (hachage SHA-256).
Règles à l'échelle de l'UE : EN 16931 et Directive 2014/55/UE
La facture électronique repose sur le droit de l'UE :
- Directive 2014/55/UE - oblige les pouvoirs adjudicateurs à recevoir et à traiter des factures électroniques (B2G).
- EN 16931 (série de normes européennes) - définit le modèle de données sémantique pour les factures électroniques (CEN/TC 434). XRechnung et ZUGFeRD sont des mises en œuvre nationales de cette norme EN.
- ViDA (VAT in the Digital Age) - extension prévue à l'échelle de l'UE de l'obligation de facture électronique et introduction d'un système de déclaration pour les données de transactions. L'obligation allemande de facture électronique prépare ViDA.
Pourquoi Git est idéal pour les factures électroniques
| Exigence facture électronique | Comment Git y répond |
|---|---|
| XML comme document original | le fichier XML est stocké inchangé dans le repo - git diff ne montre aucun changement |
| Intact (§ 14b UStG) | hachage SHA-256 par commit - toute modification serait visible |
| Conserver 8 ans (§ 147 Abs. 3) | Git-Bundle comme archive self-contained - aucun compte cloud nécessaire |
| Exploitable automatiquement (§ 147 Abs. 6) | le XML est par définition lisible par machine - git grep suffit |
| Validation EN 16931 | le Pre-Commit-Hook peut appeler le validateur XRechnung/ZUGFeRD |
| Visualisation (BMF FAQ 12a) | XML + Sidecar Markdown lisible par l'humain - les deux dans le repo |
| Période transitoire 2025–2027 | le repo peut conserver en parallèle les « autres factures » (PDF) et les factures électroniques (XML) |
Conseil pratique : un repo Git peut conserver en parallèle des factures électroniques (XML) et des autres factures (PDF) - avec une séparation claire par type de justificatif dans le Sidecar (
v7g_taxonomy). Le Pre-Commit-Hook vérifie si les factures électroniques ont une structure XML valide (sch