ED06 - Pièces justificatives, DMS, facture électronique : classement, traçabilité rétrograde/progressive

Problème

Un entrepreneur se lance dans le classement de ses pièces justificatives - et se trouve face à la question : Comment classer mes pièces justificatives conformément à la GoBD, et comment les rendre traçables ?

La pratique actuelle dans le secteur des PME :

• Pièces papier dans des dossiers - pas électroniques, pas exploitables par machine, pas traçables rétrogradement/progressivement
• PDF dans des comptes cloud - non conformes à la GoBD (pas d'inaltérabilité, pas d'exploitabilité par machine, dépendance au prestataire)
• E-mails avec pièces jointes PDF - non archivés (la boîte mail n'est pas une archive), pas d'authenticité des pièces, pas de chaîne de preuve
• Factures électroniques (XML) incomprises - beaucoup d'entrepreneurs ne savent pas que depuis 2025, le fichier XML est le document original, pas le PDF
• (Souvent) Aucun classement - les pièces sont rangées par date, pas par opération ; les écritures comptables n'ont pas de référence de pièce
• (Souvent) Pas de traçabilité rétrograde - le vérificateur ne peut pas remonter de l'écriture comptable à la pièce, car la référence manque
• (Souvent) Pas de traçabilité progressive - impossible de passer de la pièce à l'écriture comptable, car les références croisées manquent

Message clé

Un classement des pièces justificatives conforme à la GoBD signifie :

1. Chaque pièce justificative possède une identité unique (DocID) - la uuidV7 (Object ID) est déjà à elle seule l'identité unique de la pièce, indépendamment du nom de fichier. En outre, chaque pièce reçoit un hachage SHA-256 comme contrôle d'intégrité cryptographique. La Composite Key V7GUID:uuidV7 sert à l'organisation du classement (p. ex. par type de pièce) et aux DB-Queries (p. ex. avec EF Core dans une Vertical App) - pas à l'identité elle-même.
2. Chaque pièce possède un Sidecar - .v7g.md avec classification (V7GUID), identité d'objet (uuidV7), taxonomie, statut d'obsolescence, heure de saisie (dans uuidV7 comme horodatage 48 bits)
3. Chaque écriture comptable référence sa pièce - source_sha256 dans l'entrée de journal → pièce
4. Traçabilité rétrograde - de l'écriture comptable → pièce → entrée de journal → uuidV7 résoluble
5. Traçabilité progressive - de la pièce → écriture comptable → livre journal → bilan d'ouverture résoluble
6. Facture électronique : le XML est le document original - pas le PDF (depuis 2025, § 14 UStG, EN 16931)

Compliance by Design : le classement des pièces ne naît pas d'un tri a posteriori, mais de champs obligatoires structurels (SHA-256, V7GUID, Sidecar) et de Pre-Commit-Hooks qui vérifient chaque écriture comptable pour sa référence de pièce.

Types de pièces justificatives et leurs spécificités GoBD

Important - facture électronique depuis 2025 : depuis le 1er janvier 2025, la facture électronique est obligatoire pour les opérations B2B entre entreprises nationales (§ 14 UStG). Un simple PDF n'est plus une facture électronique - c'est une « autre facture ». Une 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 les documents originaux au sens de l'AO ».

Classification des pièces justificatives 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 pièce justificative (obligatoire)

Chaque pièce justificative reçoit un Sidecar .v7g.md avec la Composite Key V7GUID:uuidV7 :

{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "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
  }
}

Composite Key V7GUID:uuidV7 - organisation du classement et requêtes :

• uuidV7 (Object ID) - constitue déjà à elle seule l'identité unique (DocID) de la pièce, générée avec une marque temporelle prédéfinie, horodatage 48 bits ancré dans le GUID
• V7GUID (Class) - classifie le type de pièce à partir de la Registry .gitcover (type de pièce, organisation du classement, DB-Query pour une Vertical App avec EF Core)
• v7g_taxonomy[].v7guid - Object ID de la pièce classifiée
• gcpn.prima_nota_ref / journal_entry_ref - référence croisée vers livre journal/journal (traçabilité progressive)
• La Composite Key V7GUID:uuidV7 sert à l'organisation du classement et aux requêtes - l'identité de la pièce est la 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 à la GoBD Rz. 146 (compréhensibilité - « tiers compétent dans un délai raisonnable »). La traçabilité progressive correspond à la GoBD Rz. 147 (vérifiabilité). Toutes deux sont garanties by Design par SHA-256 + V7GUID + Sidecar - et non par des références croisées manuelles.

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 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, pas le PDF.

Pre-Commit-Hook pour les factures électroniques

Le Pre-Commit-Hook 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 à ce titre être conservés 6 ans. Beaucoup d'entrepreneurs n'archivent pas les e-mails - c'est une violation de la 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 pièce dans le Sidecar (v7g_taxonomy). Le Pre-Commit-Hook vérifie que chaque EML possède un Sidecar et que chaque pièce jointe est classifiée séparément.

Complétude des pièces justificatives (Pre-Commit-Hook)

Risiko-Leverage

Exigence Harness (aperçu)

Dérivable de ED06 :

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

Sources

• GoBD (circulaire du BMF, Rz. 146 - compréhensibilité, Rz. 147 - vérifiabilité)
• AO (§ 147 Abs. 1 Nr. 2/3 - lettres commerciales, § 147 Abs. 1 Nr. 4 - pièces comptables, § 147 Abs. 2 - exploitable par machine, § 147 Abs. 3 - délais de conservation)
• UStG (§ 14 - facture électronique, § 14b - conservation)
• FAQ du BMF sur la facture électronique (état : mars 2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• AFJD/agents/ (anonymisé) - concept SSoT avec archive de pièces justificatives, 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 respective sur gitcover.org pour connaître l'état actuel.