ED06 - Justificatifs, DMS, facture électronique : ordre, traçabilité rétrograde/progressive

Problème

Un entrepreneur commence à archiver ses justificatifs - et se trouve confronté à la question : comment classer les justificatifs de manière conforme GoBD, et comment les rendre traçables ?

La pratique actuelle dans les PME :

• Justificatifs papier dans des classeurs - non électroniques, non exploitables par machine, non traçables de manière rétrograde/progressive
• PDF dans des comptes cloud - non conformes GoBD (pas d'immutabilité, pas d'exploitabilité par machine, dépendance vis-à-vis du prestataire)
• E-mails avec pièces jointes PDF - non archivés (la boîte mail n'est pas une archive), pas d'authenticité du justificatif, pas de chaîne de preuve
• Factures électroniques (XML) non comprises - beaucoup d'entrepreneurs ne savent pas que, depuis 2025, le fichier XML est le document original, et non le PDF
• (Souvent) Aucun ordre - les justificatifs sont classés par date, pas par opération ; les écritures comptables n'ont pas de référence de justificatif
• (Souvent) Aucune traçabilité rétrograde - à partir de l'écriture comptable, le vérificateur 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 manquent

Message clé

Un archivage des justificatifs conforme GoBD signifie :

1. Chaque justificatif a une identité unique (DocID) - l'uuidV7 (Object ID) constitue déjà à elle seule l'identité unique du justificatif, indépendamment du nom de fichier. En outre, chaque justificatif reçoit un hash SHA-256 comme contrôle d'intégrité cryptographique. La clé composite V7GUID:uuidV7 sert à l'organisation de l'archivage (par ex. par type de justificatif) et aux requêtes DB (par ex. avec EF Core dans une Vertical App) - pas à l'identité elle-même.
2. Chaque justificatif a un sidecar - .gc.md avec classification (V7GUID), identité d'objet (uuidV7), taxonomie, statut d'obsolescence, horodatage d'enregistrement (dans uuidV7 comme horodatage 48 bits). Exception (à partir de 261011) : les justificatifs intégrés dans une procédure de signature (justificatif interne numérique, par ex. justificatif de représentation) portent leurs métadonnées de sidecar intégralement dans le *.gcsig.md (bloc source intégré, schéma gcsig-1.4) ; un .gc.md séparé disparaît — aucun sidecar concurrent.
3. Chaque écriture comptable référence son justificatif - source_sha256 dans l'entrée de journal → justificatif
4. Traçabilité rétrograde - de l'écriture comptable → justificatif → entrée de journal → uuidV7
5. Traçabilité progressive - du justificatif → écriture comptable → grand livre → bilan d'ouverture
6. Facture électronique : le XML est le document original - pas le PDF (depuis 2025, § 14 UStG, EN 16931)

Compliance by Design : l'ordre des justificatifs ne résulte pas d'un tri a posteriori, mais de champs obligatoires structurels (SHA-256, V7GUID, sidecar) et de hooks pre-commit qui vérifient la référence de justificatif de chaque écriture comptable.

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 transactions B2B entre entreprises nationales (§ 14 UStG). Un simple PDF n'est plus 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.gc.md  # Sidecar
│   │   └── rechnung_002.pdf      # Sonstige Rechnung (PDF)
│   │   └── rechnung_002.pdf.gc.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 .gc.md avec la clé composite V7GUID:uuidV7 :

{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-2.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 de l'archivage et requête :

• uuidV7 (Object ID) - constitue déjà à elle seule l'identité unique (DocID) du justificatif, générée avec un horodatage prédéfini, horodatage 48 bits ancré dans le GUID
• V7GUID (Class) - classifie le type de justificatif issu du registre .gitcover (type de justificatif, organisation de l'archivage, requête DB dans une Vertical App avec EF Core)
• v7g_taxonomy[].v7guid - Object ID du justificatif classifié
• gcpn.prima_nota_ref / journal_entry_ref - renvoi vers le grand livre/journal (traçabilité progressive)
• La clé composite V7GUID:uuidV7 sert à l'organisation de l'archivage et aux requêtes - l'identité du justificatif est l'uuidV7 seule
• Pas de champ datetime séparé - le temps est contenu dans uuidV7

Traçabilité rétrograde et progressive

Référence GoBD : la traçabilité rétrograde correspond à GoBD Rz. 146 (traçabilité - « un tiers expert dans un délai raisonnable »). La traçabilité progressive correspond à GoBD Rz. 147 (vérifiabilité). Les deux sont garanties by Design par SHA-256 + V7GUID + sidecar - et non par des renvois manuels.

Repérabilité : docUid au lieu du nom/chemin (261026)

Chaque référence de justificatif dans une facture porte le docUid du justificatif d'origine, pas le nom ni le chemin : dans le XML comme cac:AdditionalDocumentReference/cbc:ID (uuidV7), dans le sidecar/GCPN comme docUid. Le registre DMS reprend le même docUid comme object_id - il n'invente pas une seconde identité. Un justificatif est ainsi repérable de manière univoque par docUid, même s'il est renommé ou déplacé.

L'action qui crée ou stocke un justificatif est gérée comme pgid (Process Gateway, classe V7GUID) : produced_by_pgid pour la création (par ex. création de facture 180), stored_by_pgid pour l'enregistrement DMS (par ex. 183). Catalogue : GCUV/TOP/compliance/process_gateways.json ; valeurs normatives 8 bits : OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

GCPN en un seul fichier : pour chaque facture, il existe un .gcpn.md qui contient le XML (document original) et le PDF (vue) dans documents[], ainsi que le workflow create→pdf→present→accept→sign→register et les events et relations (contrat/justificatifs de coûts). XML/PDF restent des fichiers séparés ; un .gc.md séparé disparaît. Progressivement (Rz. 147), on lit du GCPN vers les documents ; rétrogradement (Rz. 146), du docUid dans le DMS via le GCPN vers les justificatifs.

Règle de promotion : après le scan du dépôt et la création du sidecar, un .gc.md peut être enrichi dans le GCPN ; les données JSON du sidecar sont intégrées (GCPN = sur-ensemble, .gc.md = sous-ensemble). Ensuite, le .gc.md séparé est redondant et peut être supprimé ; l'historique Git reste la preuve GoBD, le GCPN est la SSoT.

Identité de facture : invoice_id est une uuidV7 (critère d'ordre/de référence) ; invoice_no n'est que du texte. Seller/Buyer sont référencés via leur Party-uuidV7 (creditor/vendor respectivement debitor/customer), pas via leur nom réel (PII).

Facture électronique : le XML est le document original

XRechnung vs. ZUGFeRD

Important - ZUGFeRD depuis 2025 : en cas de divergence entre la partie XML et la partie image PDF, c'est depuis 2025 la partie structurée (XML) qui est déterminante (BMF FAQ question 12a). L'image PDF n'est plus prépondérante. Le sidecar doit référencer le XML comme document original, pas le PDF.

Hook pre-commit pour les factures électroniques

Le hook pre-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. Beaucoup d'entrepreneurs n'archivent pas les 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 pre-commit vérifie que chaque EML a un sidecar et que chaque pièce jointe est classifiée séparément.

Complétude des justificatifs (hook pre-commit)

Levier de risque

Exigence du harness (aperçu)

Déductible d'ED06 :

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

Sources

• GoBD (lettre BMF, Rz. 146 - traçabilité, Rz. 147 - vérifiabilité)
• AO (§ 147 Abs. 1 Nr. 2/3 - lettres commerciales, § 147 Abs. 1 Nr. 4 - justificatifs d'écriture, § 147 Abs. 2 - exploitable par machine, § 147 Abs. 3 - délais de conservation)
• UStG (§ 14 - facture électronique, § 14b - conservation)
• FAQ BMF sur la facture électronique (état mars 2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• E1/agents/ (anonymisé) - concept SSoT avec archive de justificatifs, sidecars

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

Remarque : cette attribution des sources, du miroir et du Community Hub reflète l'état actuel et peut changer. Veuillez vérifier la source canonique correspondante sur gitcover.org pour connaître l'état actuel.