ED13 - Tarea: Escanear y procesar justificantes de invitación

Desencadenante: Ha tenido lugar una invitación por motivo de negocio; el establecimiento de restauración ha emitido una factura (restaurante). Los gastos deben deducirse como gasto de explotación; para ello debe aportarse la prueba legal (§ 4 Abs. 5 Satz 1 Nr. 2 EStG).

Lo que exige la ley

§ 4 Abs. 5 Satz 1 Nr. 2 EStG: el 70 % de los gastos son deducibles siempre que sean adecuados y se hayan demostrado su importe y su vinculación empresarial. Para la prueba deben indicarse por escrito: lugar, fecha, participantes, motivo de la invitación, así como el importe de los gastos. Si la invitación ha tenido lugar en un restaurante, bastan los datos sobre motivo y participantes; debe adjuntarse la factura. Además, los gastos de invitación deben registrarse individualmente y por separado (§ 4 Abs. 7 EStG).
Escrito del BMF de 19.11.2025 (IV C 6 - S 2145/00026/005/033, sustituye al de 30.6.2021): el justificante propio puede crearse digitalmente; la autorización se realiza mediante firma electrónica o aprobación electrónica (no se necesita firma cualificada). Se requieren la creación oportuna, la fecha y hora de creación y de firma en el documento, una vinculación biunívoca entre el justificante y el justificante propio (p. ej., referencia/índice), así como la conformidad con GoBD incl. documentación del procedimiento (BMF 28.11.2019).

La tarea en cinco pasos

Escanear — El justificante en papel/del restaurante se fotografía/escanea y se guarda como Ur-Doc (p. ej., PDF) en el directorio de justificantes.
Captura OCR — a partir del justificante se determina el texto interpretable (ocr.txt) y se documenta con su calidad/confianza (TrustVector-BitVector, inicio 0x0001 = machine-unverified).
Reconocer el tipo de justificante — a partir del texto OCR se determina, mediante reglas, el tipo de justificante: aquí BUSINESS_MEAL_RECEIPT (justificante de invitación; reconocido por „Bewirtungsaufwendungen", „Bewirtete Personen", „Anlass der Bewirtung").
Incorporar al proceso de firma — se genera un *.gcsig.md (artefacto de firma, clase GCSIG) que contiene el justificante propio digital: los datos exigidos legalmente como content integrado (esquema business-meal-receipt-1.0), la procedencia OCR (ocr), el bloque sidecar integrado (source) y el bloque de firma (signature) con facsímil de la persona firmante.
Presentar y firmar — el artefacto se establece en presented, se presenta a la persona (HITL) para su firma y, tras la aprobación, se establece en accepted → signed. El ancla de la firma es el SHA-256 del Ur-Doc.

El artefacto: justificante y firma en un solo documento

Para los justificantes que se incorporan al proceso de firma, no se necesita un .gc.md separado: el *.gcsig.md asume por completo la función sidecar (regla "función sidecar/transición": del .gc.md surge el .gcsig.md, sin pérdida de información, sin sidecars competidores). A partir del esquema gcsig-1.4, contiene:

Bloque	Contenido
`subject` / `sha256`	el Ur-Doc (PDF) con su SHA-256 como ancla de prueba
`content`	los datos del justificante propio (`business-meal-receipt-1.0`)
`ocr`	texto completo OCR + TrustVector (procedencia)
`source`	metadatos sidecar integrados: taxonomía V7GUID, tenant/categoría, esfera, ubicaciones de almacenamiento, etiquetas, finalidad, FZul, referencias GCPN
`signature`	firmante, procedimiento (§ 126b BGB), referencia de facsímil
`phases`	ciclo de vida como BitVector de 32 bits: `draft → presented → accepted → signed` (ortogonal `verified`)

Seguridad de auditoría — cumplimiento nativo de Git

El ancla es inalterable: el SHA-256 del Ur-Doc. Nunca cambia; cada cambio de contenido genera un nuevo estado del Ur-Doc.
El *.gcsig.md (como el GCPN) es un contenedor mutable cuyos cambios de estado (fases) se convierten en un registro de auditoría mediante commits de Git firmados con GPG. El historial puro de Git no basta para ello (posible force-push) — por eso la firma sobre el commit/el GCSIG.
Los cambios en el contenido del justificante propio son, por tanto, rastreables; el estado firmado en cada caso se conserva en el historial.

Ejemplo (serie: organización ficticia KMU)

El director general de KMU invita a comer, tras una feria sectorial, a un representante de una editorial especializada para hablar de una posible publicación. El justificante del restaurante por 59,80 € se escanea; mediante OCR se reconoce el tipo de justificante BUSINESS_MEAL_RECEIPT. El justificante propio se genera como *.gcsig.md (participantes, motivo "Feria sectorial — posible publicación", importe, esfera ideell, sin deducción del IVA soportado, contabilización como reembolso de gastos) y se presenta al director general para su firma.

Herramientas

Herramienta	Tarea
`gc-sidecar scan`	Registrar el Ur-Doc (SHA-256), determinar texto OCR + confianza
`gc-sidecar detect`	Detectar el tipo de justificante a partir del texto OCR (basado en reglas)
`gc-docsign gcsig`	Crear/integrar *`.gcsig.md`** (`--content`, `--ocr`, `--source`, `--facsimile`) y establecer fases

Referencia

Fundamentos jurídicos: § 4 Abs. 5 Satz 1 Nr. 2 y Abs. 7 EStG; R 4.10 EStR; BMF 19.11.2025; GoBD (BMF 28.11.2019).
Firma/sidecar: véase GCBoK, Parte VI (Digital Signage) — GCSIG y la transición .gc.md → .gcsig.md.
Ordenación de justificantes: ED06.