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

Problema

Un empresario empieza con el archivo de comprobantes y se enfrenta a la pregunta: ¿Cómo ordeno los comprobantes de forma conforme a GoBD y cómo los hago trazables?

La práctica actual en 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 conformes a GoBD (sin inmutabilidad, sin evaluabilidad automática, dependencia del proveedor de servicios)
• Correos electrónicos con adjuntos PDF: no archivados (el buzón de correo electrónico no es un archivo), sin autenticidad del comprobante, sin cadena de prueba
• Facturas electrónicas (XML) no comprendidas: muchos empresarios no saben que, desde 2025, el archivo XML es el documento original, no el PDF
• (A menudo) Sin orden: los comprobantes se ordenan por fecha, no por operación; los asientos contables no tienen referencia de comprobante
• (A menudo) Sin trazabilidad retrógrada: desde el asiento contable, el auditor no puede llegar al comprobante porque falta la referencia
• (A menudo) Sin trazabilidad progresiva: desde el comprobante no se puede llegar al asiento contable porque faltan las referencias cruzadas

Afirmación central

El archivo de comprobantes conforme a GoBD significa:

1. Cada comprobante tiene una identidad inequívoca (DocID): la uuidV7 (Object ID) ya es por sí sola la identidad inequívoca del comprobante, independientemente del nombre del archivo. Además, cada comprobante recibe un hash SHA-256 como comprobación criptográfica de integridad. La clave compuesta V7GUID:uuidV7 sirve para la organización del archivo (p. ej., por tipo de comprobante) y para las consultas de BD (p. ej., con EF Core en una Vertical App), no para la identidad en sí.
2. Cada comprobante tiene un sidecar: .gc.md con clasificación (V7GUID), identidad del objeto (uuidV7), taxonomía, estado de obsolescencia, momento de registro (en uuidV7 como marca de tiempo de 48 bits). Excepción (a partir de 261011): los comprobantes que se incorporan a un proceso de firma (digital comprobante propio, p. ej., comprobante de restauración) llevan sus metadatos de sidecar completamente en *.gcsig.md (bloque source integrado, esquema gcsig-1.4); se elimina un .gc.md separado — sin sidecars en conflicto.
3. Cada asiento contable referencia su comprobante: source_sha256 en la entrada del diario → comprobante
4. Trazabilidad retrógrada: desde el asiento contable → comprobante → entrada del diario → uuidV7 se puede resolver
5. Trazabilidad progresiva: desde el comprobante → asiento contable → libro mayor → balance de apertura se puede resolver
6. Factura electrónica: 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 mediante una clasificación posterior, sino mediante campos obligatorios estructurales (SHA-256, V7GUID, sidecar) y pre-commit hooks que comprueban cada asiento contable en busca de referencia de comprobante.

Tipos de comprobante y sus particularidades GoBD

Importante: factura electrónica desde 2025: Desde el 1 de enero de 2025, la factura electrónica es obligatoria para las operaciones B2B entre empresas nacionales (§ 14 UStG). Un PDF simple ya no es una factura electrónica: es una «otra factura». Solo existe factura electrónica cuando se emite, transmite y recibe en un formato electrónico estructurado (XML, EN 16931). Véase ED01 «Factura electrónica: 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.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 por comprobante (obligatorio)

Cada comprobante recibe un sidecar .gc.md con la clave compuesta 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
  }
}

Clave compuesta V7GUID:uuidV7: organización del archivo y consulta:

• 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 el GUID
• V7GUID (Class): clasifica el tipo de comprobante desde el registro de .gitcover (tipo de comprobante, organización del archivo, consulta de BD en la Vertical App con EF Core)
• v7g_taxonomy[].v7guid: Object ID del comprobante clasificado
• gcpn.prima_nota_ref / journal_entry_ref: referencia cruzada al libro mayor/diario (trazabilidad progresiva)
• La clave compuesta V7GUID:uuidV7 sirve para la organización del archivo y la consulta; la identidad del comprobante es la uuidV7 por sí sola
• No hay un campo datetime separado: el tiempo está en uuidV7

Trazabilidad retrógrada y progresiva

Referencia GoBD: La trazabilidad retrógrada corresponde a GoBD Rz. 146 (trazabilidad: «un tercero experto en un tiempo 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.

Localización: docUid en lugar de nombre/ruta (261026)

Cada referencia de comprobante en una factura contiene la docUid del comprobante original, no el nombre ni la ruta: en el XML como cac:AdditionalDocumentReference/cbc:ID (uuidV7), en el sidecar/GCPN como docUid. El registro DMS adopta la misma docUid como object_id; no inventa una segunda identidad. Así, un comprobante se puede localizar de forma inequívoca mediante la docUid, aunque se renombre o se mueva.

La Action que crea o almacena un comprobante se gestiona como pgid (puerta de enlace de proceso, clase V7GUID): produced_by_pgid para la creación (p. ej., creación de factura 180), stored_by_pgid para el registro DMS (p. ej., 183). Catálogo: GCUV/TOP/compliance/process_gateways.json; valores normativos de 8 bits: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

GCPN de un solo archivo: Para cada factura existe un .gcpn.md, que contiene el XML (documento original) y el PDF (vista) en documents[], el flujo de trabajo create→pdf→present→accept→sign→register, así como events y relations (contrato/comprobantes de costes). XML/PDF siguen siendo archivos separados; se elimina un .gc.md separado. De forma progresiva (Rz. 147) se lee desde el GCPN hacia los documentos; de forma retrógrada (Rz. 146), desde la docUid en el DMS, pasando por el GCPN, hasta los comprobantes.

Regla de promoción: Tras el escaneo del repositorio y la creación del sidecar, un .gc.md puede enriquecerse en el GCPN; los datos JSON del sidecar se incorporan (GCPN = superconjunto, .gc.md = subconjunto). Después, el .gc.md separado es redundante y puede eliminarse; la historia de Git sigue siendo la prueba GoBD, el GCPN es la SSoT.

Identidad de factura: invoice_id es una uuidV7 (criterio de ordenación/referencia); invoice_no es solo texto. Seller/Buyer se referencian mediante su Party-uuidV7 (creditor/vendor o debitor/customer), no mediante nombres reales (PII).

Factura electrónica: 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 es determinante la parte estructurada (XML) (BMF FAQ Frage 12a). La imagen PDF ya no es la que prevalece. El sidecar debe referenciar el XML como documento original, no el PDF.

Pre-Commit-Hook para facturas electrónicas

El pre-commit hook comprueba en las facturas electrónicas:

Archivado de correo electrónico

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

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

Integridad de comprobantes (pre-commit hook)

Leverage de riesgo

Requisito de Harness (vista previa)

Derivable de ED06:

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

Fuentes

• GoBD (BMF-Schreiben, Rz. 146: trazabilidad, Rz. 147: verificabilidad)
• AO (§ 147 Abs. 1 Nr. 2/3: cartas comerciales, § 147 Abs. 1 Nr. 4: comprobantes de contabilización, § 147 Abs. 2: evaluable automáticamente, § 147 Abs. 3: plazos de conservación)
• UStG (§ 14: factura electrónica, § 14b: conservación)
• BMF-FAQ sobre la factura electrónica (estado: marzo de 2026)
• EN 16931 (CEN/TC 434: XRechnung, ZUGFeRD)
• E1/agents/ (anonimizado): concepto SSoT con archivo de comprobantes, sidecars

Topología de fuentes y enlaces de referencia CDN

Nota: Esta asignación de fuentes, espejo y Community Hub refleja el estado actual y puede cambiar. Consulte la fuente canónica correspondiente en gitcover.org para conocer el estado actual.