ED06 - Justificatifs, DMS, facture électronique : classement, traçabilité régressive/progressive

Problème

Un entrepreneur commence à organiser l’archivage des justificatifs et se pose la question : Comment classer des justificatifs de manière conforme aux GoBD, et comment les rendre traçables ?

La pratique actuelle dans les PME :

• Justificatifs papier dans des dossiers - non électroniques, non exploitables automatiquement, sans traçabilité régressive/progressive
• PDF dans des comptes cloud - non conformes aux GoBD (pas d’immuabilité, pas d’exploitabilité automatique, dépendance au prestataire de services)
• E-mails avec pièces jointes PDF - non archivés (une boîte de réception n’est pas une archive), aucune authenticité du justificatif, aucune chaîne de preuves
• Factures électroniques (XML) mal comprises - de nombreux entrepreneurs ignorent que, depuis 2025, le fichier XML est le document original, et non le PDF
• (Souvent) Aucun classement - les justificatifs sont classés par date, et non par opération ; les écritures comptables n’ont pas de référence de justificatif
• (Souvent) Aucune traçabilité régressive - à partir de l’écriture comptable, l’inspecteur ne peut pas remonter au justificatif, car la référence manque
• (Souvent) Aucune traçabilité progressive - à partir du justificatif, on ne peut pas remonter à l’écriture comptable, car les renvois croisés manquent

Kernaussage

Un archivage des justificatifs conforme aux GoBD signifie :

1. Chaque justificatif a une identité unique (DocID) - le uuidV7 (Object ID) constitue à lui seul l’identité unique du justificatif, indépendamment du nom de fichier. De plus, chaque justificatif reçoit une empreinte SHA-256 comme contrôle d’intégrité cryptographique. La clé composite V7GUID:uuidV7 sert à l’organisation du classement (p. ex. par type de justificatif) et aux requêtes BDD (p. ex. dans une application verticale avec EF Core) - et non à l’identité elle-même.
2. Chaque justificatif possède un sidecar - .v7g.md avec classification (V7GUID), identité d’objet (uuidV7), taxonomie, statut d’obsolescence, horodatage de saisie (dans uuidV7 sous forme d’horodatage 48 bits). Exception (à partir de 261011) : les justificatifs repris dans un processus de signature (justificatif numérique interne, p. ex. justificatif de frais de restauration) portent l’intégralité de leurs métadonnées de sidecar dans le *.gcsig.md (bloc source intégré, schéma gcsig-1.4) ; aucun .v7g.md distinct n’est nécessaire — pas de sidecars concurrents.
3. Chaque écriture comptable référence son justificatif - source_sha256 dans l’écriture du journal → justificatif
4. Traçabilité régressive - à partir de l’écriture comptable → justificatif → écriture du journal → uuidV7, la résolution est possible
5. Traçabilité progressive - à partir du justificatif → écriture comptable → grand livre → bilan d’ouverture, la résolution est possible
6. Facture électronique : le XML est le document original - pas le PDF (depuis 2025, § 14 UStG, EN 16931)

Conformité par conception : Le classement des justificatifs ne résulte pas d’un tri a posteriori, mais de champs structuraux obligatoires (SHA-256, V7GUID, Sidecar) et de hooks de pré-commit qui vérifient que chaque écriture comptable comporte une référence de justificatif.

Types de justificatifs et leurs particularités GoBD

Important - facture électronique depuis 2025 : Depuis le 1er janvier 2025, la facture électronique est obligatoire pour les opérations B2B entre des entreprises établies en Allemagne (§ 14 UStG). Un PDF simple n’est pas une facture électronique - c’est une « autre facture ». La facture électronique n’existe que si elle est émise, transmise et reçue dans un format électronique structuré (XML, EN 16931). Voir ED01 « Facture électronique : les formats XML sont des documents originaux dans l’AO ».

Classification des justificatifs dans le dépôt Git

Structure des répertoires

ORG-1/sources/                    # Belegarchiv (Tenant: ORG-1)
├── eingangsrechnungen/           # Eingangsrechnungen (Lieferanten)
│   ├── 260815/                   # Nach Datum (YYMMDD)
│   │   ├── rechnung_001.xml      # E-Rechnung (XRechnung)
│   │   ├── rechnung_001.xml.v7g.md  # Sidecar
│   │   └── rechnung_002.pdf      # Sonstige Rechnung (PDF)
│   │   └── rechnung_002.pdf.v7g.md  # Sidecar
├── ausgangsrechnungen/           # Ausgangsrechnungen (Kunden)
├── lohnbelege/                   # Lohnabrechnungen
├── sv-bescheide/                 # SV-Bescheide, VBG-Bescheide
├── vertraege/                    # Verträge (periodenübergreifend)
├── korrespondenz/                # E-Mails, Briefe
└── sonstige/                     # Sonstige Belege

Sidecar par justificatif (obligatoire)

Chaque justificatif reçoit un sidecar .v7g.md avec la clé composite V7GUID:uuidV7 :

{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "docUid": "019f2c6f-0900-7001-8000-000000000001",
  "sha256": "ab94670c0dd8499c27ef2feddd1d9c5925977d55a52150a6fca0f6567d2e5e79",
  "title": "260815_Rechnung_001.xml",
  "original_filename": "Rechnung_001.xml",
  "locations": [
    {
      "unc_path": "./ORG-1/sources/eingangsrechnungen/260815/rechnung_001.xml",
      "from": "260815",
      "to": null,
      "note": "Primärspeicherort"
    }
  ],
  "v7g_taxonomy": [
    {
      "v7guid": "019f2c6f-0900-7000-8000-000000000000",
      "taxonomy": "ORG-1/Eingangsrechnung",
      "valid_from": "260815",
      "valid_to": null,
      "note": "Tenant: ORG-1, Category: Eingangsrechnung, Sphäre: wirtschaftlich"
    }
  ],
  "gcpn": {
    "prima_nota_ref": "GB-2026-08-001",
    "journal_entry_ref": "J-2026-08-001"
  },
  "obsolescence": {
    "status": "active",
    "superseded_by": null,
    "superseded_at": null
  }
}

Clé composite V7GUID:uuidV7 - organisation du classement et requête :

• uuidV7 (Object ID) - constitue à lui seul l’identité unique (DocID) du justificatif, généré avec un repère temporel prédéfini, un horodatage 48 bits étant ancré dans le GUID
• V7GUID (Class) - classifie le type de justificatif à partir du registre .gitcover (type de justificatif, organisation du classement, requête BDD dans une application verticale avec EF Core)
• v7g_taxonomy[].v7guid - Object ID du justificatif classifié
• gcpn.prima_nota_ref / journal_entry_ref - renvoi croisé vers le grand livre/journal (traçabilité progressive)
• La clé composite V7GUID:uuidV7 sert à l’organisation du classement et à la requête - l’identité du justificatif est la seule uuidV7
• Aucun champ datetime distinct - l’heure est intégrée à uuidV7

Traçabilité régressive et progressive

Référence aux GoBD : La traçabilité régressive correspond à GoBD Rz. 146 (reconstituabilité - « un tiers expert dans un délai raisonnable »). La traçabilité progressive correspond à GoBD Rz. 147 (vérifiabilité). Les deux sont garanties par conception grâce au SHA-256 + V7GUID + sidecar, et non par des renvois croisés manuels.

Facture électronique : le XML est le document original

XRechnung vs. ZUGFeRD

Important - ZUGFeRD depuis 2025 : En cas de divergence entre la partie XML et l’image PDF, depuis 2025, la partie structurée (XML) fait foi (BMF FAQ Frage 12a). L’image PDF n’est plus déterminante. Le sidecar doit référencer le XML comme document original, et non le PDF.

Hook de pré-commit pour les factures électroniques

Le hook de pré-commit vérifie, pour les factures électroniques :

Archivage des e-mails

Les e-mails sont des lettres commerciales ou d’affaires au sens du § 147 Abs. 1 Nr. 2/3 AO et doivent donc être conservés 6 ans. De nombreux entrepreneurs n’archivent pas leurs e-mails - c’est une violation des GoBD.

Conseil pratique : Un dépôt Git peut archiver en parallèle les e-mails (EML/MBOX) et les pièces jointes (PDF, XML)

• avec une séparation claire par type de justificatif dans le sidecar (v7g_taxonomy). Le hook de pré-commit vérifie que chaque EML possède un sidecar et que chaque pièce jointe est classée séparément.

Complétude des justificatifs (hook de pré-commit)

Leviers de réduction des risques

Exigences du harnais (aperçu)

Déductibles d’ED06 :

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

Sources

• GoBD (lettre du BMF, Rz. 146 - reconstituabilité, Rz. 147 - vérifiabilité)
• AO (§ 147 Abs. 1 Nr. 2/3 - lettres commerciales, § 147 Abs. 1 Nr. 4 - pièces justificatives comptables, § 147 Abs. 2 - exploitable automatiquement, § 147 Abs. 3 - durées de conservation)
• UStG (§ 14 - facture électronique, § 14b - conservation)
• FAQ du BMF sur la facture électronique (version de mars 2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• E1/agents/ (anonymisé) - concept SSoT avec archive des justificatifs, sidecars

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

Remarque : Cette correspondance entre les sources, le miroir et le hub communautaire reflète l’état actuel et peut évoluer. Veuillez vérifier la source canonique correspondante sur gitcover.org pour connaître l’état actuel.