ED05 - Documents, DMS, e-invoicing: Order, retrograde/progressive traceability

Problem

An entrepreneur begins filing documents - and faces the question: How do I organize documents in a GoBD-compliant way, and how do I make them traceable?

Current practice in the SME sector:

• Paper documents in folders - not electronic, not machine-evaluable, not retrograde/progressively traceable
• PDFs in cloud accounts - not GoBD-compliant (no immutability, no machine evaluability, dependence on the service provider)
• Emails with PDF attachments - not archived (an email mailbox is not an archive), no document authenticity, no chain of evidence
• E-invoices (XML) not understood - many entrepreneurs do not know that since 2025 the XML file is the original document, not the PDF
• (Often) No order - documents are filed by date, not by transaction; journal entries have no document reference
• (Often) No retrograde traceability - the auditor cannot resolve from the journal entry to the document because the reference is missing
• (Often) No progressive traceability - the document cannot be resolved to the journal entry because the cross-references are missing

Key message

GoBD-compliant document filing means:

1. Every document has a unique identity (DocID) - the uuidV7 (Object ID) is already by itself the unique identity of the document, independent of the file name. In addition, every document receives a SHA-256 hash as a cryptographic integrity check. The Composite Key V7GUID:uuidV7 serves the filing organization (e.g., by document type) and DB queries (e.g., with EF Core in a vertical app) - not the identity itself.
2. Every document has a sidecar - .v7g.md with classification (V7GUID), object identity (uuidV7), taxonomy, obsolescence status, capture time (in uuidV7 as a 48-bit timestamp)
3. Every journal entry references its document - source_sha256 in the daybook entry → document
4. Retrograde traceability - resolvable from journal entry → document → daybook entry → uuidV7
5. Progressive traceability - resolvable from document → journal entry → general ledger → opening balance sheet
6. E-invoice: XML is the original document - not the PDF (since 2025, § 14 UStG, EN 16931)

Compliance by Design: Document order does not arise from subsequent sorting, but from structural mandatory fields (SHA-256, V7GUID, sidecar) and pre-commit hooks that check every journal entry for a document reference.

Document types and their GoBD specifics

Important - e-invoicing since 2025: Since 1 January 2025, the e-invoice has been mandatory for B2B transactions between domestic businesses (§ 14 UStG). A simple PDF is no longer an e-invoice - it is an "other invoice". An e-invoice only exists if it is issued, transmitted and received in a structured electronic format (XML, EN 16931). See ED01 "E-invoicing: XML formats are original documents under the AO".

Document classification in the Git repo

Directory structure

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 per document (mandatory)

Every document receives a .v7g.md sidecar with the 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 - filing organization and query:

• uuidV7 (Object ID) - is already by itself the unique identity (DocID) of the document, generated with a predefined timestamp, 48-bit timestamp anchored in the GUID
• V7GUID (Class) - classifies the document type from the .gitcover registry (document type, filing organization, DB query in a vertical app with EF Core)
• v7g_taxonomy[].v7guid - Object ID of the classified document
• gcpn.prima_nota_ref / journal_entry_ref - cross-reference to general ledger/journal (progressive traceability)
• The Composite Key V7GUID:uuidV7 serves the filing organization and query - the identity of the document is the uuidV7 alone
• No separate datetime field - the time is embedded in uuidV7

Retrograde and progressive traceability

GoBD reference: Retrograde traceability corresponds to GoBD Rz. 146 (traceability - "knowledgeable third party within a reasonable time"). Progressive traceability corresponds to GoBD Rz. 147 (verifiability). Both are by design guaranteed through SHA-256 + V7GUID + sidecar - not through manual cross-references.

E-invoicing: XML is the original document

XRechnung vs. ZUGFeRD

Important - ZUGFeRD since 2025: In the event of deviations between the XML part and the PDF image part, the structured (XML) part has been authoritative since 2025 (BMF FAQ question 12a). The PDF image is no longer the leading version. The sidecar must reference the XML as the original document, not the PDF.

Pre-commit hook for e-invoices

For e-invoices, the pre-commit hook checks:

Email archiving

Emails are commercial or business letters within the meaning of § 147 Abs. 1 Nr. 2/3 AO and must therefore be retained for 6 years. Many entrepreneurs do not archive emails - this is a GoBD violation.

Practical tip: A Git repo can archive emails (EML/MBOX) and attachments (PDF, XML) in parallel - with a clear separation by document type in the sidecar (v7g_taxonomy). The pre-commit hook checks that every EML has a sidecar and that every attachment is classified separately.

Document completeness (pre-commit hook)

Risk leverage

Harness requirement (preview)

Derivable from ED05:

The complete list of requirements in Harness-Anforderungen.md.

Sources

• GoBD (BMF letter, Rz. 146 - traceability, Rz. 147 - verifiability)
• AO (§ 147 Abs. 1 Nr. 2/3 - commercial letters, § 147 Abs. 1 Nr. 4 - booking documents, § 147 Abs. 2 - machine-evaluable, § 147 Abs. 3 - retention periods)
• UStG (§ 14 - e-invoice, § 14b - retention)
• BMF FAQ on e-invoicing (as of March 2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• AFJD/agents/ (anonymized) - SSoT concept with document archive, sidecars

Source topology and CDN reference links

Note: This assignment of sources, mirror, and community hub reflects the current state and may change. Please check the respective canonical source on gitcover.org for the current state.