ED06 - Comprobantes, DMS, e-factura: orden, trazabilidad retrógrada/progresiva

Problema

Un empresario comienza con el archivado de comprobantes - y se enfrenta a la pregunta: ¿Cómo organizo los comprobantes conforme a GoBD y cómo los hago trazables?

La práctica actual en el ámbito de las pymes:

• Comprobantes en papel en carpetas - no electrónicos, no evaluables automáticamente, no trazables de forma retrógrada/progresiva
• PDF en cuentas en la nube - no conforme a GoBD (sin inmutabilidad, sin posibilidad de evaluación automática, dependencia del proveedor de servicios)
• Correos electrónicos con adjuntos PDF - no archivados (el buzón de correo no es un archivo), sin autenticidad del comprobante, sin cadena de prueba
• e-facturas (XML) no comprendidas - muchos empresarios no saben que desde 2025 el archivo XML es el documento original, no el PDF
• (A menudo) Falta orden - los comprobantes se archivan por fecha, no por operación; los asientos contables no tienen referencia al comprobante
• (A menudo) Falta trazabilidad retrógrada - desde el asiento contable, el auditor no puede llegar al comprobante porque falta la referencia
• (A menudo) Falta trazabilidad progresiva - desde el comprobante no se puede llegar al asiento contable porque faltan las referencias cruzadas

Idea central

Un archivado de comprobantes conforme a GoBD significa:

1. Cada comprobante tiene una identidad única (DocID) - la uuidV7 (Object ID) ya es por sí sola la identidad única del comprobante, independientemente del nombre de archivo. Además, cada comprobante recibe un hash SHA-256 como verificación criptográfica de integridad. La Composite Key V7GUID:uuidV7 sirve para la organización del archivado (p. ej., por tipo de comprobante) y para las DB-Queries (p. ej., con EF Core en una Vertical App) - no para la identidad misma.
2. Cada comprobante tiene un Sidecar - .v7g.md con clasificación (V7GUID), identidad del objeto (uuidV7), taxonomía, estado de obsolescencia, momento de captura (en uuidV7 como marca de tiempo de 48 bits)
3. Cada asiento contable referencia su comprobante - source_sha256 en la entrada de diario → comprobante
4. Trazabilidad retrógrada - desde el asiento contable → comprobante → entrada de diario → uuidV7 se puede resolver
5. Trazabilidad progresiva - desde el comprobante → asiento contable → libro diario → balance de apertura se puede resolver
6. e-factura: el XML es el documento original - no el PDF (desde 2025, § 14 UStG, EN 16931)

Compliance by Design: el orden de los comprobantes no surge de una clasificación posterior, sino de campos obligatorios estructurales (SHA-256, V7GUID, Sidecar) y de Pre-Commit-Hooks que verifican cada asiento contable respecto a su referencia al comprobante.

Tipos de comprobantes y sus particularidades conforme a GoBD

Importante - e-factura desde 2025: desde el 1 de enero de 2025, la e-factura es obligatoria para las operaciones B2B entre empresas nacionales (§ 14 UStG). Un PDF simple ya no es una e-factura - es una "otra factura". Solo existe una e-factura cuando se emite, transmite y recibe en un formato electrónico estructurado (XML, EN 16931). Véase ED01 "e-factura: los formatos XML son documentos originales en la AO".

Clasificación de comprobantes en el repositorio Git

Estructura de directorios

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 por comprobante (obligatorio)

Cada comprobante recibe un Sidecar .v7g.md con la 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 - organización del archivado y Query:

• uuidV7 (Object ID) - ya es por sí sola la identidad única (DocID) del comprobante, generada con una marca de tiempo predefinida, con la marca de tiempo de 48 bits anclada en la GUID
• V7GUID (Class) - clasifica el tipo de comprobante a partir del Registry .gitcover (tipo de comprobante, organización del archivado, DB-Query en Vertical App con EF Core)
• v7g_taxonomy[].v7guid - Object ID del comprobante clasificado
• gcpn.prima_nota_ref / journal_entry_ref - referencia cruzada al libro diario/journal (trazabilidad progresiva)
• El Composite Key V7GUID:uuidV7 sirve para la organización del archivado y el Query - la identidad del comprobante es la uuidV7 sola
• Sin campo datetime separado - el tiempo está contenido en uuidV7

Trazabilidad retrógrada y progresiva

Referencia GoBD: la trazabilidad retrógrada corresponde a GoBD Rz. 146 (comprensibilidad - "tercero experto en un plazo razonable"). La trazabilidad progresiva corresponde a GoBD Rz. 147 (verificabilidad). Ambas están garantizadas by Design mediante SHA-256 + V7GUID + Sidecar - no mediante referencias cruzadas manuales.

e-factura: el XML es el documento original

XRechnung vs. ZUGFeRD

Importante - ZUGFeRD desde 2025: en caso de discrepancias entre la parte XML y la parte de imagen PDF, desde 2025 prevalece la parte estructurada (XML) (BMF FAQ pregunta 12a). La imagen PDF ya no es la determinante. El Sidecar debe referenciar el XML como documento original, no el PDF.

Pre-Commit-Hook para e-facturas

El Pre-Commit-Hook verifica en las e-facturas:

Archivado de correos electrónicos

Los correos electrónicos son cartas comerciales o de negocios en el sentido del § 147 Abs. 1 Nr. 2/3 AO y, por tanto, deben conservarse durante 6 años. Muchos empresarios no archivan los correos electrónicos - eso constituye una infracción de GoBD.

Consejo práctico: un repositorio Git puede archivar en paralelo correos electrónicos (EML/MBOX) y adjuntos (PDF, XML) - con una separación clara por tipo de comprobante en el Sidecar (v7g_taxonomy). El Pre-Commit-Hook verifica que cada EML tenga un Sidecar y que cada adjunto esté clasificado por separado.

Completitud de los comprobantes (Pre-Commit-Hook)

Apalancamiento de riesgo

Requisitos del Harness (vista previa)

Derivables de ED06:

La lista completa de requisitos en Harness-Anforderungen.md.

Fuentes

• GoBD (escrito del BMF, Rz. 146 - comprensibilidad, Rz. 147 - verificabilidad)
• AO (§ 147 Abs. 1 Nr. 2/3 - cartas comerciales, § 147 Abs. 1 Nr. 4 - justificantes de asiento, § 147 Abs. 2 - evaluable automáticamente, § 147 Abs. 3 - plazos de conservación)
• UStG (§ 14 - e-factura, § 14b - conservación)
• BMF-FAQ sobre la e-factura (a marzo de 2026)
• EN 16931 (CEN/TC 434 - XRechnung, ZUGFeRD)
• AFJD/agents/ (anonimizado) - concepto SSoT con archivo de comprobantes, Sidecars

Topología de fuentes y enlaces de referencia CDN

Nota: esta asignación de fuentes, Mirror y Community Hub refleja el estado actual y puede cambiar. Por favor, compruebe la fuente canónica correspondiente en gitcover.org para conocer el estado actual.