ED06 - Documents, DMS, e-invoices: Order, retrograde/progressive traceability

Problem

An entrepreneur starts 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 traceable retrogradely/progressively
• PDFs in cloud accounts - not GoBD-compliant (no immutability, no machine evaluability, dependency on the service provider)
• Emails with PDF attachments - not archived (an email inbox 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; booking entries have no document reference
• (Often) No retrograde traceability - from the booking entry, the auditor cannot resolve to the document because the reference is missing
• (Often) No progressive traceability - from the document, it cannot be resolved to the booking entry because the cross-references are missing

Core statement

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, regardless 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 booking entry references its document - source_sha256 in the journal entry → document
4. Retrograde traceability - resolvable from the booking entry → document → journal entry → uuidV7
5. Progressive traceability - resolvable from the document → booking entry → Grundbuch → 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 retrospective sorting, but from structural mandatory fields (SHA-256, V7GUID, sidecar) and pre-commit hooks that check every booking entry for a document reference.

Document types and their GoBD specifics

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

Document classification in the Git repo

Directory structure

ORG-1/sources/                    # document archive (Tenant: ORG-1)
├── eingangsrechnungen/           # incoming invoices (suppliers)
│   ├── 260815/                   # by date (YYMMDD)
│   │   ├── rechnung_001.xml      # e-invoice (XRechnung)
│   │   ├── rechnung_001.xml.v7g.md  # sidecar
│   │   └── rechnung_002.pdf      # other invoice (PDF)
│   │   └── rechnung_002.pdf.v7g.md  # sidecar
├── ausgangsrechnungen/           # outgoing invoices (customers)
├── lohnbelege/                   # payroll statements
├── sv-bescheide/                 # SV notices, VBG notices
├── vertraege/                    # contracts (cross-period)
├── korrespondenz/                # emails, letters
└── sonstige/                     # other documents

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-from-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": "Primary storage location"
    }
  ],
  "v7g_taxonomy": [
    {
      "v7guid": "019f2c6f-0900-7000-8000-000000000000",
      "taxonomy": "ORG-1/Eingangsrechnung",
      "valid_from": "260815",
      "valid_to": null,
      "note": "Tenant: ORG-1, Category: Eingangsrechnung, Sphere: economic"
    }
  ],
  "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 preset 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 Grundbuch/journal (progressive traceability)
• The Composite Key V7GUID:uuidV7 serves 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 (comprehensibility - "expert third party within a reasonable time"). Progressive traceability corresponds to GoBD Rz. 147 (verifiability). Both are guaranteed by design through SHA-256 + V7GUID + sidecar - not through manual cross-references.

e-invoice: XML is the original document

XRechnung vs. ZUGFeRD

Important - ZUGFeRD since 2025: In the event of discrepancies between the XML part and the PDF image part, the structured (XML) part is 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 ED06:

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

Sources

• GoBD (BMF letter, Rz. 146 - comprehensibility, 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-invoices (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 mapping 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.