ED05 - Belege, DMS, e-Rechnung: Ordnung, retrograde/progressive Nachverfolgbarkeit

Problem

Ein Unternehmer beginnt mit der Belegablage - und steht vor der Frage: Wie ordne ich Belege GoBD-konform, und wie mache ich sie nachverfolgbar?

Die heutige Praxis im KMU-Bereich:

• Papierbelege in Ordnern - nicht elektronisch, nicht maschinell auswertbar, nicht retrograd/progressiv nachverfolgbar
• PDFs in Cloud-Accounts - nicht GoBD-konform (keine Unveränderbarkeit, keine maschinelle Auswertbarkeit, Abhängigkeit vom Dienstleister)
• E-Mails mit PDF-Anhängen - nicht archiviert (E-Mail-Postfach ist kein Archiv), keine Beleg-Echtheit, keine Nachweiskette
• e-Rechnungen (XML) nicht verstanden - viele Unternehmer wissen nicht, dass seit 2025 die XML-Datei das Ur-Dokument ist, nicht das PDF
• (Oft) Keine Ordnung - Belege liegen nach Datum, nicht nach Vorgang; Buchungssätze haben keine Belegreferenz
• (Oft) Keine retrograde Nachverfolgbarkeit - vom Buchungssatz kann der Prüfer nicht zum Beleg auflösen, weil die Referenz fehlt
• (Oft) Keine progressive Nachverfolgbarkeit - vom Beleg kann nicht zum Buchungssatz aufgelöst werden, weil die Querverweise fehlen

Kernaussage

GoBD-konforme Belegablage bedeutet:

1. Jeder Beleg hat eine eindeutige Identität (DocID) - die uuidV7 (Object ID) ist bereits allein die eindeutige Identität des Belegs, unabhängig vom Dateinamen. Zusätzlich erhält jeder Beleg einen SHA-256-Hash als kryptographische Integritätsprüfung. Der Composite Key V7GUID:uuidV7 dient der Ablage-Organisation (z. B. nach Belegart) und DB-Queries (z. B. bei EF Core in einer Vertical App) - nicht der Identität selbst.
2. Jeder Beleg hat einen Sidecar - .v7g.md mit Klassifizierung (V7GUID), Objekt-Identität (uuidV7), Taxonomie, Obsoleszenz-Status, Erfassungszeit (in uuidV7 als 48-Bit-Zeitstempel)
3. Jeder Buchungssatz referenziert seinen Beleg - source_sha256 im Tagebucheintrag → Beleg
4. Retrograde Nachverfolgbarkeit - vom Buchungssatz → Beleg → Tagebucheintrag → uuidV7 auflösbar
5. Progressive Nachverfolgbarkeit - vom Beleg → Buchungssatz → Grundbuch → Eröffnungsbilanz auflösbar
6. E-Rechnung: XML ist das Ur-Dokument - nicht das PDF (seit 2025, § 14 UStG, EN 16931)

Compliance by Design: Beleg-Ordnung entsteht nicht durch nachträgliche Sortierung, sondern durch strukturelle Pflichtfelder (SHA-256, V7GUID, Sidecar) und Pre-Commit-Hooks, die jeden Buchungssatz auf Belegreferenz prüfen.

Beleg-Typen und ihre GoBD-Besonderheiten

Wichtig - E-Rechnung seit 2025: Seit dem 1. Januar 2025 ist die E-Rechnung für B2B-Umsätze zwischen inländischen Unternehmen verpflichtend (§ 14 UStG). Ein einfaches PDF ist nicht mehr eine E-Rechnung - es ist eine "sonstige Rechnung". Die E-Rechnung liegt nur dann vor, wenn sie in einem strukturierten elektronischen Format (XML, EN 16931) ausgestellt, übermittelt und empfangen wird. Siehe ED01 "E-Rechnung: XML-Formate sind Ur-Dokumente in der AO".

Beleg-Klassifizierung im Git-Repo

Verzeichnisstruktur

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 pro Beleg (Pflicht)

Jeder Beleg erhält einen .v7g.md-Sidecar mit dem 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 - Ablage-Organisation und Query:

• uuidV7 (Object ID) - ist bereits allein die eindeutige Identität (DocID) des Belegs, generiert mit vorgegebener Zeitmarke, 48-Bit- Zeitstempel in der GUID verankert
• V7GUID (Class) - klassifiziert den Beleg-Typ aus .gitcover Registry (Belegart, Ablage-Organisation, DB-Query bei Vertical App mit EF Core)
• v7g_taxonomy[].v7guid - Object ID des klassifizierten Belegs
• gcpn.prima_nota_ref / journal_entry_ref - Querverweis auf Grundbuch/Journal (progressive Nachverfolgbarkeit)
• Der Composite Key V7GUID:uuidV7 dient Ablage-Organisation und Query - die Identität des Belegs ist die uuidV7 allein
• Kein separates datetime-Feld - die Zeit steckt in uuidV7

Retrograde und progressive Nachverfolgbarkeit

GoBD-Bezug: Die retrograde Nachverfolgbarkeit entspricht GoBD Rz. 146 (Nachvollziehbarkeit - "sachverständiger Dritter in angemessener Zeit"). Die progressive Nachverfolgbarkeit entspricht GoBD Rz. 147 (Nachprüfbarkeit). Beide sind by Design durch SHA-256 + V7GUID + Sidecar gewährleistet - nicht durch manuelle Querverweise.

E-Rechnung: XML ist das Ur-Dokument

XRechnung vs. ZUGFeRD

Wichtig - ZUGFeRD seit 2025: Bei Abweichungen zwischen XML-Teil und PDF-Bildteil ist seit 2025 der strukturierte (XML-)Teil maßgebend (BMF FAQ Frage 12a). Das PDF-Bild ist nicht mehr führend. Der Sidecar muss das XML als Ur-Dokument referenzieren, nicht das PDF.

Pre-Commit-Hook für E-Rechnungen

Der Pre-Commit-Hook prüft bei E-Rechnungen:

E-Mail-Archivierung

E-Mails sind Handels- oder Geschäftsbriefe im Sinne des § 147 Abs. 1 Nr. 2/3 AO und damit 6 Jahre aufzubewahren. Viele Unternehmer archivieren E-Mails nicht - das ist ein GoBD-Verstoß.

Praxis-Tipp: Ein Git-Repo kann E-Mails (EML) und Anhänge (PDF, XML) parallel archivieren - mit klarer Trennung durch Beleg-Typ im Sidecar (v7g_taxonomy). Der Pre-Commit-Hook prüft, dass jede EML einen Sidecar hat und jeder Anhang separat klassifiziert ist.

Beleg-Vollständigkeit (Pre-Commit-Hook)

Risiko-Leverage

Harness-Anforderung (Vorschau)

Aus ED05 ableitbar:

Die vollständige Anforderungsliste in Harness-Anforderungen.md.

Quellen

• GoBD (BMF-Schreiben, Rz. 146 - Nachvollziehbarkeit, Rz. 147 - Nachprüfbarkeit)
• AO (§ 147 Abs. 1 Nr. 2/3 - Handelsbriefe, § 147 Abs. 1 Nr. 4 - Buchungsbelege, § 147 Abs. 2 - maschinell auswertbar, § 147 Abs. 3 - Aufbewahrungsfristen)
• UStG (§ 14 - E-Rechnung, § 14b - Aufbewahrung)
• BMF-FAQ zur E-Rechnung (Stand März 2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• AFJD/agents/ (anonymisiert) - SSoT-Konzept mit Belegarchiv, Sidecars

Quellen-Topologie und CDN-Referenz-Links

Hinweis: Diese Zuordnung von Quellen, Mirror und Community-Hub spiegelt den aktuellen Stand wider und kann sich ändern. Bitte prüfen Sie die jeweilige kanonische Quelle auf gitcover.org für den aktuellen Zustand.