ED13 - Tarea: escanear y procesar comprobantes de gastos de representación
Disparador: Ha tenido lugar una consumición con fines comerciales; el establecimiento de hostelería ha emitido una factura (restaurante). Los gastos deben registrarse como gasto de explotación — para ello debe aportarse la prueba exigida por la ley (§ 4 Abs. 5 Satz 1 Nr. 2 EStG).
Qué exige la ley
- § 4 Abs. 5 Satz 1 Nr. 2 EStG: el 70 % de los gastos es deducible siempre que sean razonables y se acredite su importe y su finalidad empresarial. Para la prueba deben indicarse por escrito: lugar, fecha, participantes, motivo de la consumición e importe de los gastos. Si la consumición ha tenido lugar en un restaurante, bastará indicar el motivo y los participantes; la factura debe adjuntarse. Además, los gastos de representación deben registrarse de forma individual y separada (§ 4 Abs. 7 EStG).
- Comunicación del BMF del 19.11.2025 (IV C 6 - S 2145/00026/005/033, sustituye 30.6.2021): el recibo propio puede crearse digitalmente; la autorización se efectúa mediante firma electrónica o aprobación electrónica (no se requiere una firma cualificada). Son necesarios una creación sin demora, la marca temporal de creación y de firma en el documento, una vinculación inequívoca entre el comprobante y el recibo propio (p. ej., referencia/índice) así como la conformidad con GoBD, incluida la documentación del procedimiento (BMF 28.11.2019).
La tarea en cinco pasos
- Escanear — el comprobante en papel o de restaurante se fotografía o escanea y se almacena como documento original (p. ej., PDF) en el directorio de comprobantes.
- Captación por OCR — a partir del comprobante se determina el texto
interpretable (
ocr.txt) y se documenta con su calidad/confianza (TrustVector-BitVector, inicio0x0001=machine-unverified). - Reconocer el tipo de comprobante — a partir del texto del OCR, el tipo de
comprobante se determina de forma basada en reglas: en este caso,
BUSINESS_MEAL_RECEIPT(comprobante de gastos de representación; reconocido por „Bewirtungsaufwendungen“, „Bewirtete Personen“, „Anlass der Bewirtung“). - Incorporar al proceso de firma — se genera un
*.gcsig.md(artefacto de firma, claseGCSIG) que transporta el recibo propio digital: los datos exigidos por la ley en uncontentintegrado (esquemabusiness-meal-receipt-1.0), la procedencia del OCR (ocr), el bloque Sidecar integrado (source) y el bloque de firma (signature) con el facsímil de la persona firmante. - Presentar y firmar — el artefacto se marca como
presented, se presenta a la persona (HITL) para que firme y, tras la aprobación, se marca comoaccepted→signed. El ancla de la firma es el SHA-256 del documento original.
El artefacto: comprobante y firma en un solo documento
Para los comprobantes que se incorporan al proceso de firma, no es necesario un
.v7g.md independiente: el *.gcsig.md asume íntegramente la función de
Sidecar (regla «Función Sidecar/transición»: el .v7g.md se transforma en el
.gcsig.md, sin pérdida de información y sin Sidecars concurrentes). A partir
del esquema gcsig-1.4 contiene:
| Bloque | Contenido |
|---|---|
subject / sha256 |
el documento original (PDF) con su SHA-256 como ancla de prueba |
content |
los datos del recibo propio (business-meal-receipt-1.0) |
ocr |
texto completo del OCR + TrustVector (procedencia) |
source |
metadatos Sidecar integrados: taxonomía V7GUID, tenant/categoría, esfera, ubicaciones de almacenamiento, etiquetas, finalidad, FZul, referencias de GCPN |
signature |
firmante, procedimiento (§ 126b BGB), referencia del facsímil |
phases |
ciclo de vida como vector de bits de 32 bits: draft → presented → accepted → signed (verified ortogonal) |
Seguridad ante revisiones — Cumplimiento nativo de Git
- El ancla es inmutable: el SHA-256 del documento original. Nunca cambia; cada modificación de contenido genera una nueva versión del documento original.
- El
*.gcsig.md(como el GCPN) es un contenedor mutable, cuyos cambios de estado (fases) se convierten, mediante commits de Git firmados con GPG, en un registro de auditoría. El historial de Git por sí solo no basta (es posible hacer force-push) — por ello, la firma del commit/del GCSIG. - Los cambios en el contenido del recibo propio son, por tanto, trazables; la versión firmada en cada momento se conserva en el historial.
Ejemplo (serie: organización ficticia KMU)
El gerente de KMU ofrece una consumición a un representante de una editorial
técnica después de una feria sectorial para hablar de una posible publicación.
Se escanea el recibo del restaurante por 59,80 €; mediante OCR se identifica el
tipo de comprobante BUSINESS_MEAL_RECEIPT. El recibo propio se crea como
*.gcsig.md (participantes, motivo „Feria sectorial — posible publicación“,
importe, esfera ideell, sin deducción de impuestos indirectos, contabilización
como reembolso de gastos) y se presenta al gerente para su firma.
Herramientas
| Herramienta | Tarea |
|---|---|
gc-sidecar scan |
capturar el documento original (SHA-256), determinar el texto del OCR y el nivel de confianza |
gc-sidecar detect |
reconocer el tipo de comprobante a partir del texto del OCR (basado en reglas) |
gc-docsign gcsig |
generar/incrustar *.gcsig.md (--content, --ocr, --source, --facsimile) y establecer las fases |
Referencias
- Bases legales: § 4 Abs. 5 Satz 1 Nr. 2 und 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
.v7g.md→.gcsig.md. - Ordenación de comprobantes: ED06.