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

Problem

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

Today's 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, dependency on the service provider)
• Emails with PDF attachments — not archived (an email inbox is not an archive), no document authenticity, no evidence chain
• 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; posting records have no document reference
• (Often) No retrograde traceability — from the posting record, the auditor cannot resolve to the document because the reference is missing
• (Often) No progressive traceability — from the document, it is not possible to resolve to the posting record because the cross-references are missing

Key statement

GoBD-compliant document filing means:

1. Every document has a unique identity (DocID) — the uuidV7 (Object ID) is already on its own the unique identity of the document, regardless of the file name. In addition, every document receives a SHA-256 hash as cryptographic integrity verification. The composite key V7GUID:uuidV7 serves filing organization (e.g., by document type) and DB queries (e.g., with EF Core in a Vertical App) — not identity itself.
2. Every document has a sidecar — .gc.md with classification (V7GUID), object identity (uuidV7), taxonomy, obsolescence status, capture time (in uuidV7 as a 48-bit timestamp). Exception (from 261011): documents that are transferred into a signature process (digital Eigenbeleg, e.g., entertainment receipt) carry their sidecar metadata entirely in *.gcsig.md (integrated source block, schema gcsig-1.4); a separate .gc.md is omitted — no competing sidecars.
3. Every posting record references its document — source_sha256 in the journal entry → document
4. Retrograde traceability — resolvable from posting record → document → journal entry → uuidV7
5. Progressive traceability — resolvable from document → posting record → 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 through subsequent sorting, but through structural mandatory fields (SHA-256, V7GUID, sidecar) and pre-commit hooks that check every posting record for a document reference.

Document types and their GoBD specifics

Important — e-invoicing since 2025: Since January 1, 2025, e-invoicing has 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-invoicing: XML formats are original documents in 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.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 per document (mandatory)

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

• uuidV7 (Object ID) — is already on its own 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 for 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 filing organization and query — the identity of the document is the uuidV7 alone
• No separate datetime field — the time is contained in uuidV7

Retrograde and progressive traceability

GoBD reference: Retrograde traceability corresponds to GoBD Rz. 146 (traceability — "a knowledgeable 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.

Findability: docUid instead of name/path (261026)

Every document reference in an invoice carries the docUid of the original document, not the name or path: in XML as cac:AdditionalDocumentReference/cbc:ID (uuidV7), in the sidecar/GCPN as docUid. The DMS registry adopts the same docUid as object_id — it does not invent a second identity. A document is therefore uniquely findable by docUid, even if it is renamed or moved.

The action that creates or stores a document is maintained as a pgid (process gateway, V7GUID class): produced_by_pgid for creation (e.g., invoice creation 180), stored_by_pgid for DMS registration (e.g., 183). Catalog: GCUV/TOP/compliance/process_gateways.json; normative 8-bit values: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

Single-file GCPN: For every invoice there is one .gcpn.md that lists the XML (original doc) and PDF (view) in documents[], contains the workflow create→pdf→present→accept→sign→register as well as events and relations (contract/expense documents). XML/PDF remain separate files; a separate .gc.md is omitted. Progressively (Rz. 147), one reads from the GCPN to the documents; in retrograde (Rz. 146), from the docUid in the DMS via the GCPN to the documents.

Promote rule: After repo scan and sidecar creation, a .gc.md can be enriched into the GCPN; the sidecar JSON data is embedded (GCPN = superset, .gc.md = subset). After that, the separate .gc.md is redundant and can be removed; the Git history remains the GoBD evidence, the GCPN is SSoT.

Invoice identity: invoice_id is a uuidV7 (ordering/reference criterion); invoice_no is only text. Seller/buyer are referenced via their party uuidV7 (creditor/vendor or debitor/customer), not via real names (PII).

E-invoice: XML is the original document

XRechnung vs. ZUGFeRD

Important — ZUGFeRD since 2025: In case of deviations 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 leading. The sidecar must reference the XML as the original document, not the PDF.

Pre-commit hook for e-invoices

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

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 — that is a GoBD violation.

Practical tip: A Git repo 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 every EML has a sidecar and every attachment is classified separately.

Document completeness (pre-commit hook)

Risk leverage

Harness requirement (preview)

Derivable from ED06:

The complete list of requirements 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 — accounting 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)
• E1/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.