ED06 - Documentos justificantes, DMS, factura electrónica: organización, trazabilidad retrogresiva/progresiva

Problema

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

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

• Documentos justificantes en papel, en carpetas: no son electrónicos, no se pueden evaluar mecánicamente y no permiten una trazabilidad retrogresiva/progresiva
• PDF en cuentas en la nube: no conformes con GoBD (sin inmutabilidad, sin evaluabilidad mecánica, dependencia del prestador de servicios)
• Correos electrónicos con adjuntos PDF: no se archivan (un buzón de correo electrónico no es un archivo), no existe autenticidad del documento justificante ni cadena de prueba
• No se entienden las facturas electrónicas (XML): muchos empresarios no saben que, desde 2025, el archivo XML es el documento original, no el PDF
• (A menudo) No hay organización: los documentos justificantes están ordenados por fecha, no por operación; los asientos contables no tienen referencia del documento justificante
• (A menudo) No hay trazabilidad retrogresiva: desde el asiento contable, el auditor no puede resolver hasta el documento justificante porque falta la referencia
• (A menudo) No hay trazabilidad progresiva: desde el documento justificante no se puede resolver hasta el asiento contable porque faltan las referencias cruzadas

Mensaje clave

El archivo de documentos justificantes conforme a GoBD significa:

1. Cada documento justificante tiene una identidad única (DocID): la uuidV7 (ID de objeto) ya es por sí sola la identidad única del documento justificante, con independencia del nombre del archivo. Además, cada documento justificante recibe un hash SHA-256 como comprobación criptográfica de integridad. La clave compuesta V7GUID:uuidV7 sirve para la organización del almacenamiento (p. ej., por tipo de documento justificante) y las consultas de BD (p. ej., en EF Core en una aplicación vertical), no como identidad en sí misma.
2. Cada documento justificante tiene un sidecar: .v7g.md con la clasificación (V7GUID), la identidad del objeto (uuidV7), la taxonomía, el estado de obsolescencia y el momento de captura (en uuidV7, como marca temporal de 48 bits). Excepción (a partir del 261011): los documentos justificantes que se transfieren a un proceso de firma (documento justificante digital propio, p. ej., justificante de gastos de representación) contienen todos sus metadatos sidecar en el *.gcsig.md (bloque source integrado, esquema gcsig-1.4); se prescinde de un .v7g.md independiente: sin sidecars concurrentes.
3. Cada asiento contable hace referencia a su documento justificante: source_sha256 en el asiento del libro diario → documento justificante
4. Trazabilidad retrogresiva: se puede rastrear desde el asiento contable → documento justificante → asiento del libro diario → uuidV7
5. Trazabilidad progresiva: se puede rastrear desde el documento justificante → asiento contable → libro mayor → balance de apertura
6. Factura electrónica: el XML es el documento original, no el PDF (desde 2025, § 14 UStG, EN 16931)

Cumplimiento por diseño: la organización de los documentos justificantes no se obtiene mediante una reordenación posterior, sino mediante campos obligatorios estructurales (SHA-256, V7GUID, sidecar) y Pre-Commit-Hooks que comprueban que cada asiento contable tenga una referencia de documento justificante.

Tipos de documentos justificantes y sus particularidades conforme a GoBD

Importante: factura electrónica desde 2025: desde el 1 de enero de 2025, la factura electrónica es obligatoria para operaciones B2B entre empresas nacionales (§ 14 UStG). Un PDF simple ya no es una factura electrónica: es una "otra factura". Solo existe una factura electrónica si 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 documentos justificantes 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 documento justificante (obligatorio)

Cada documento justificante recibe un sidecar .v7g.md con la clave compuesta 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
  }
}

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

• uuidV7 (ID de objeto): ya es por sí sola la identidad única (DocID) del documento justificante, generada con una marca de tiempo predefinida, con una marca temporal de 48 bits anclada en el GUID
• V7GUID (clase): clasifica el tipo de documento justificante a partir del registro .gitcover (tipo de documento justificante, organización del almacenamiento, consulta de BD en una aplicación vertical con EF Core)
• v7g_taxonomy[].v7guid: ID de objeto del documento justificante 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 almacenamiento y las consultas: la identidad del documento justificante es únicamente uuidV7
• No hay un campo datetime independiente: el tiempo está contenido en uuidV7

Trazabilidad retrogresiva y progresiva

Referencia GoBD: la trazabilidad retrogresiva corresponde a GoBD Rz. 146 (trazabilidad: "un tercero experto en un plazo razonable"). La trazabilidad progresiva corresponde a GoBD Rz. 147 (verificabilidad). Ambas están garantizadas por diseño mediante SHA-256 + V7GUID + sidecar, no mediante referencias cruzadas manuales.

Factura electrónica: el XML es el documento original

XRechnung frente a ZUGFeRD

Importante: ZUGFeRD desde 2025: en caso de discrepancias entre la parte XML y la imagen PDF, desde 2025 la parte estructurada (XML) es determinante (BMF FAQ, pregunta 12a). La imagen PDF ya no 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 correos electrónicos

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: esto infringe 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 mediante el tipo de documento justificante 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 los documentos justificantes (Pre-Commit-Hook)

Palancas de reducción de riesgos

Requisito del harness (vista previa)

Derivables de ED06:

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

Fuentes

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

Topología de fuentes y enlaces de referencia al CDN

Nota: esta asignación de fuentes, espejo y centro comunitario refleja el estado actual y puede cambiar. Consulte la fuente canónica respectiva en gitcover.org para conocer el estado actual.