ED06 - 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 - .gc.md mit Klassifizierung (V7GUID), Objekt-Identität (uuidV7), Taxonomie, Obsoleszenz-Status, Erfassungszeit (in uuidV7 als 48-Bit-Zeitstempel). Ausnahme (ab 261011): Belege, die in einen Signaturvorgang übernommen werden (digitaler Eigenbeleg, z. B. Bewirtungsbeleg), tragen ihre Sidecar-Metadaten vollständig im *.gcsig.md (integrierter source-Block, Schema gcsig-1.4); ein separates .gc.md entfällt — keine konkurrierenden Sidecars.
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.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 pro Beleg (Pflicht)

Jeder Beleg erhält einen .gc.md-Sidecar mit dem Composite Key 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
  }
}

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.

Auffindbarkeit: docUid statt Name/Pfad (261026)

Jede Belegreferenz in einer Rechnung führt die docUid des Ur-Belegs, nicht Name oder Pfad: im XML als cac:AdditionalDocumentReference/cbc:ID (uuidV7), im Sidecar/GCPN als docUid. Die DMS-Registry übernimmt dieselbe docUid als object_id - sie erfindet keine zweite Identität. Ein Beleg ist damit eindeutig per docUid auffindbar, auch wenn er umbenannt oder verschoben wird.

Die Action, die einen Beleg erzeugt bzw. speichert, wird als pgid (Prozess-Gateway, V7GUID-Klasse) geführt: produced_by_pgid für die Erzeugung (z. B. Rechnungserstellung 180), stored_by_pgid für die DMS-Registrierung (z. B. 183). Katalog: GCUV/TOP/compliance/process_gateways.json; normative 8-Bit-Werte: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

Ein-Datei-GCPN: Für jede Rechnung liegt ein .gcpn.md vor, das XML (Ur-Doc) und PDF (Ansicht) in documents[] führt, den Workflow create→pdf→present→accept→sign→register sowie events und relations (Vertrag/Kostenbelege) enthält. XML/PDF bleiben separate Dateien; ein separates .gc.md entfällt. Progressiv (Rz. 147) liest man vom GCPN zu den Dokumenten, retrograd (Rz. 146) vom docUid im DMS über den GCPN zu den Belegen.

Promote-Regel: Nach Repo-Scan und Sidecar-Erstellung kann ein .gc.md in den GCPN angereichert werden; die Sidecar-JSON-Daten werden eingebettet (GCPN = Obermenge, .gc.md = Subset). Danach ist die separate .gc.md redundant und kann entfernt werden; die Git-Historie bleibt der GoBD-Nachweis, der GCPN ist SSoT.

Rechnungs-Identität: invoice_id ist eine uuidV7 (Ordnungs-/Referenzkriterium); invoice_no ist nur Text. Seller/Buyer werden über ihre Party-uuidV7 referenziert (creditor/vendor bzw. debitor/customer), nicht über Klarnamen (PII).

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/MBOX) 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 ED06 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)
• E1/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.