ED06 - Documents, DMS, E-Invoice: Organization, Backward/Forward Traceability

Problem

A business owner starts with document filing - and faces the question: How do I file documents in a GoBD-compliant manner, and how do I make them traceable?

Current practice in the SME sector:

• Paper documents in folders - not electronic, not machine-readable, not backward/forward traceable
• PDFs in cloud accounts - not GoBD-compliant (no immutability, no machine readability, dependence 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 business owners do not know that since 2025 the XML file is the original document, not the PDF
• (Often) No organization - documents are arranged by date, not by transaction; journal entries have no document reference
• (Often) No backward traceability - the auditor cannot trace the journal entry to the document because the reference is missing
• (Often) No forward traceability - the document cannot be traced to the journal entry because the cross-references are missing

Core 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, regardless of the filename. Additionally, every document receives a SHA-256 hash as a cryptographic integrity check. The Composite Key V7GUID:uuidV7 is used for filing organization (e.g. by document type) and DB queries (e.g. with EF Core in a vertical application) - not for the identity itself.
2. Every document has a sidecar - .v7g.md with classification (V7GUID), object identity (uuidV7), taxonomy, obsolescence status, and capture time (in uuidV7 as a 48-bit timestamp). Exception (from 261011): documents that are incorporated into a signing process (digital self-issued document, e.g. meal receipt) carry their sidecar metadata entirely in the *.gcsig.md (integrated source block, schema gcsig-1.4); a separate .v7g.md is omitted — no competing sidecars.
3. Every journal entry references its document - source_sha256 in the journal record → document
4. Backward traceability - the journal entry → document → journal record → uuidV7 path can be resolved
5. Forward traceability - the document → journal entry → general ledger → opening balance sheet path can be resolved
6. E-invoice: XML is the original document - not the PDF (since 2025, § 14 UStG, EN 16931)

Compliance by Design: Document organization is not created through retrospective sorting, but through mandatory structural fields (SHA-256, V7GUID, sidecar) and pre-commit hooks that check every journal entry for a document reference.

Document Types and Their GoBD-Specific Features

Important - E-invoices since 2025: Since 1 January 2025, e-invoices have been 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 exists only if it is issued, transmitted and received in a structured electronic format (XML, EN 16931). See ED01 "E-invoice: XML Formats Are Original Documents in the AO".

Document Classification in the Git Repository

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>",
  "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 - Filing Organization and Query:

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

Backward and Forward Traceability

GoBD reference: Backward traceability corresponds to GoBD Rz. 146 (traceability - "qualified third party within a reasonable period of time"). Forward 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 no longer takes precedence. The sidecar must reference the XML as the original document, not the PDF.

Pre-Commit Hook for E-Invoices

The pre-commit hook checks e-invoices for the following:

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 business owners do not archive emails - that is a GoBD violation.

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

Document Completeness (Pre-Commit Hook)

Risk Leverage

Harness Requirement (Preview)

Derivable from ED06:

The complete requirements list is 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-readable, § 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)
• E1/agents/ (anonymized) - SSoT concept with document archive and 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 status.