ED01 - Motivación: por qué un empresario lleva su diario en Git
Problema
Un empresario funda una organización - y se encuentra ante una imagen poco clara de los riesgos que surgirán en el futuro. ¿Qué obligaciones surgen y cuándo? ¿Qué comprobantes deben conservarse y durante cuánto tiempo? ¿Qué plazos amenazan con incumplirse? ¿Qué autoridades se anuncian, cuándo y para qué inspección?
La práctica actual en el ámbito de las pymes está marcada por:
- Papeleo y listas locales de Excel - sin trazabilidad, no a prueba de auditoría
- Caos de PDF y correos electrónicos en las inspecciones - la documentación se ensambla ad-hoc
- Soluciones aisladas (software de nóminas aquí, contabilidad allí, archivo de comprobantes en otro lugar) - sin una cadena de evidencias continua
- Lagunas en el código abierto en obligaciones especiales (tiempo de trabajo, gastos de viaje, subvenciones, BEM, FZul/BSFZ, utilidad pública) - aquí apenas existe apoyo libre
- Atasco de riesgos - las obligaciones se ignoran hoy de forma cheap, hasta que mañana se vuelven caras en forma de multas, recargos por demora o revocaciones
Tag 0"] --> B["Pflichten
unklar"] B --> C["Heute cheap
ignoriert"] C --> D["Morgen teuer
Bußgeld/Aberkennung"] D --> E["Risiko
realisiert"] style A fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style B fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style C fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style D fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#FF3333,stroke:#0F1B33,color:#FBFAF7
Idea central
No solo los documentos deben ser a prueba de auditoría - también las decisiones, los plazos y las referencias a comprobantes deben ser trazables, reproducibles y auditables. Un diario nativo de Git hace exactamente eso: convierte hechos registrados hoy de forma cheap (barata) (una entrada JSON con V7GUID + referencia de comprobante SHA-256) en futuras evidencias a prueba de auditoría. El cumplimiento se convierte en una palanca, no en un freno.
Compliance by Design: la "imagen poco clara" de los riesgos futuros se mitiga mediante técnicas de GitCover (OSCAL, OPA, V7GUID, Git-Hooks) desde el principio, y no solo cuando el inspector llama a la puerta.
Génesis: la inspección SV como detonante práctico
La idea de GitCover no nació en una torre de marfil, sino de
experiencias prácticas concretas: más recientemente, de una inspección de empresa SV en una micro-UG
(anonimizada aquí como ORG-V para "organización precursora") correspondiente al periodo
2021–2023; realizada en el periodo 02/2024–03/2025. La inspección reveló puntos de dolor que las técnicas de GitCover abordan.
Cronología de la inspección SV
¿Qué ocurrió?
| Fecha | Acontecimiento | Estado |
|---|---|---|
| 02/2024 | La DRV anuncia una inspección de empresa según § 28p SGB IV | ⏳ |
| 12/2024 | La DRV solicita la documentación de inspección (cuentas de nómina 2021–2023, cuestionario, carta de acompañamiento) | ⏳ |
| 12/2024 | La documentación se ensambla y envía por correo electrónico como PDF/ZIP | ✅ |
| 02/2025 | La DRV transmite los resultados de la inspección (audiencia § 24 SGB X, hoja de totales, anexos HEK/Minijob-Zentrale) | ✅ |
| 02/2025 | Aceptación sin objeciones; solicitud de reembolso presentada ante la KK | ✅ |
| 03/2025 | Inspección SV finalizada - nace la idea GitCover | ✅ |
Resultado financiero (neto)
| Concepto | Importe |
|---|---|
| Reembolso de cotizaciones U1 pagadas de más | +121 EUR |
| Requerimiento de cotizaciones fijas KV | −30 EUR |
| Reembolso neto | +91 EUR |
| Costes del proveedor de servicios | >100 EUR |
| Esfuerzo | varios días de recopilación manual |
Puntos de dolor - lo que reveló la inspección
Prüfung nur per E-Mail"] P2["Beleg-Echtheit unklar
PDFs ohne kryptographische Verankerung"] P3["Keine Nachweiskette
Lohnkonten/SV/Erstattung an verschiedenen Orten"] P4["Fristen ad-hoc
manuell im Kalender gepflegt"] P5["Audit-Export fehlt
euBP/eXTra, Z3 nur mit Spezialsoftware"] P6["Lohn-Account pausiert
nach Mitarbeiter-Ausscheiden
Extra-Kosten > Erstattung"] P7["Alte Sicherungen
alter Software-Stand
GoBD-Auflage verletzt"] P1 --> G["GitCover-Idee
geboren"] P2 --> G P3 --> G P4 --> G P5 --> G P6 --> G P7 --> G G --> S["GitCover-Lösungen
SHA-256+V7GUID, Hooks, Fristen-Check
Evidence-Packages, Git-Bundles self-contained"] style P1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P7 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style G fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
- Sin oficina operativa, sin fax, sin empleados - y aun así hubo que tramitar una inspección de empresa exclusivamente por correo electrónico con archivos PDF y ZIP. Las herramientas no existían para este caso mínimo.
- Autenticidad de los comprobantes poco clara - los PDF por correo electrónico no tienen anclaje criptográfico. ¿Quién cambió qué y cuándo? La fuerza probatoria solo existía gracias a la trazabilidad manual.
- Sin cadena de evidencias continua - las cuentas de nómina, las comunicaciones SV, los justificantes de cotizaciones y los comprobantes de reembolso se encontraban en lugares distintos, sin referencias cruzadas. Cada consulta exigía buscar de nuevo.
- Gestión de plazos ad-hoc - los plazos de audiencia, de reembolso y de impugnación se gestionaban manualmente en el calendario. Sin aviso ante un vencimiento inminente.
- Faltaba la exportación para auditoría - la DRV exigía los datos en formato euBP (eXTra V3.4.0); el FA habría requerido un soporte de datos Z3. Ambas cosas solo era posible con software especializado o con una preparación manual.
- Baja del empleado → cuenta de nómina pausada - tras la baja del empleado de entonces, la cuenta de liquidación de nóminas se pausó en el proveedor de servicios. ¿Quién mantiene inútilmente una cuenta en la nube generando costes cuando el motivo ya no existe (empleado dado de baja, sin necesidad de más liquidaciones)? La recopilación del paquete de documentación para la inspección requirió entonces costes adicionales en el proveedor de servicios, que al final fueron mayores que el pequeño "reembolso" al término de la inspección.
- Reactivación de copias de seguridad antiguas con una versión antigua del software - para volver a hacer
accesibles las cuentas de nómina 2021–2023, hubo que reactivar las antiguas
copias de seguridad con la versión antigua del software - un
problema práctico considerable. Esto es formalmente una infracción del requisito de la
GoBD, que también exige velar técnicamente por que durante el largo
plazo de conservación (10 años) siempre se pueda acceder. En la práctica,
esta obligación entra en conflicto con la presión económico-empresarial
de no mantener cuentas en la nube sin uso que generen costes.
Precisamente esta tensión es un motivo central de GitCover: los Git-Bundles son
self-contained - no necesitan cuentas en la nube, ni
contratos con proveedores de servicios, ni versiones de software. Basta un
git clone, y el plazo de conservación queda técnicamente cumplido.
Fundamentos jurídicos: AO § 146, § 147 y GoBD
La "infracción del requisito de la GoBD" mencionada en el punto 7 tiene una base jurídica clara - en la Abgabenordnung (AO) y en las GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff, BMF-Schreiben).
AO § 146 Abs. 5 - Disponibilidad durante el plazo de conservación
"Al llevar los libros y los demás registros necesarios en soportes de datos debe asegurarse en particular que durante todo el plazo de conservación los datos estén disponibles en todo momento y puedan hacerse legibles sin demora."
Esta es la norma central: quien contabiliza electrónicamente debe asegurar durante todo el plazo de conservación (10 años para libros/registros, 8 años para comprobantes contables, § 147 Abs. 3 AO) que los datos estén disponibles en todo momento y sean legibles sin demora. Una cuenta en la nube pausada, que solo se reactiva a cambio de costes adicionales, infringe esta obligación - los datos no están "disponibles en todo momento", sino solo previo pago y con retraso.
AO § 147 Abs. 2 - Conservación en soportes de datos
"Salvo las cuentas anuales [...] los documentos enumerados en el apartado 1 también pueden conservarse como reproducción en un soporte de imagen o en otros soportes de datos, siempre que ello se corresponda con los principios de contabilidad correcta y esté asegurado que la reproducción o los datos [...] durante todo el plazo de conservación estén disponibles en todo momento, puedan hacerse legibles sin demora y evaluarse mecánicamente."
De nuevo: "disponible en todo momento", "legible sin demora", "evaluable mecánicamente". Una versión antigua del software que primero debe reactivarse no cumple lo de "sin demora".
AO § 147 Abs. 5 - Medios auxiliares a costa del obligado tributario
"Quien presente documentos que deban conservarse en forma de reproducción en un soporte de imagen o en otros soportes de datos está obligado a poner a disposición, a su costa, los medios auxiliares necesarios para hacer legibles los documentos."
Esto significa: si el proveedor de servicios ya no mantiene el sistema antiguo, el empresario debe proporcionar él mismo los medios auxiliares (software, licencias, hardware) para hacer legibles los datos. Exactamente ese fue el problema práctico del caso de la génesis: copias de seguridad antiguas, versión antigua del software, sin medios auxiliares disponibles.
AO § 147 Abs. 6 - Acceso a los datos en la inspección externa
"Si los documentos conforme al apartado 1 se han elaborado con ayuda de un sistema de procesamiento de datos, la autoridad fiscal puede, en el marco de una inspección externa [...], exigir que los datos se pongan a disposición evaluados mecánicamente conforme a sus especificaciones."
En una inspección externa, el empresario debe poner los datos a disposición en forma evaluable mecánicamente - no como impresión PDF, sino como datos estructurados. Una cuenta en la nube pausada que solo ofrece exportación PDF no basta.
GoBD - Documentación del procedimiento y cambio de sistema
Las GoBD concretan estas normas de la AO para sistemas electrónicos. Requisitos centrales:
- Documentación del procedimiento (GoBD Rz. 64–91): todo sistema electrónico de contabilidad debe tener una documentación del procedimiento que describa el procedimiento, el entorno del sistema, las medidas organizativas y los controles internos. En caso de cambio de sistema, la documentación del procedimiento debe actualizarse.
- Cambio de sistema/migración (GoBD Rz. 146–150): en un cambio de sistema debe asegurarse que los datos del sistema antiguo sigan disponibles, legibles y evaluables mecánicamente. La documentación del procedimiento debe documentar el cambio.
- Inmutabilidad (GoBD Rz. 146): tras el asiento contable, los datos no pueden modificarse. Las correcciones deben realizarse como nuevas entradas con justificación.
Consecuencias teóricas en caso de infracción
AO § 146/147 + GoBD"] V --> K1["Verspätungszuschlag
§ 152 AO
bis 25.000 EUR"] V --> K2["Schätzung
§ 162 AO
bei nicht verwertbaren Daten"] V --> K3["Verzögerungsgeld
§ 146 Abs. 2c AO
2.500–250.000 EUR"] V --> K4["Beweislastumkehr
FA schätzt, Unternehmer
muss widerlegen"] V --> K5["Ordnungswidrigkeit
§ 379 AO
Bußgeld bis 50.000 EUR"] V --> K6["Steuerstrafverfahren
§ 370 AO
bei vorsätzlicher Verkürzung"] style V fill:#FF1A1A,stroke:#0F1B33,color:#FBFAF7 style K1 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K3 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K4 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K5 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style K6 fill:#FDBA74,stroke:#C2410C,color:#0F1B33
| Consecuencia | Fundamento jurídico | Cuantía/riesgo |
|---|---|---|
| Recargo por demora | § 152 AO | hasta 25.000 EUR (caso individual) |
| Estimación de las bases imponibles | § 162 AO | FA estima cuando los datos no son aprovechables - a menudo en perjuicio del empresario |
| Multa por retraso | § 146 Abs. 2c AO | 2.500–250.000 EUR (en caso de externalización sin autorización) |
| Inversión de la carga de la prueba | § 162 AO, § 90 AO | el empresario debe refutar la estimación - con datos faltantes apenas es posible |
| Infracción administrativa | § 379 AO | multa hasta 50.000 EUR (por dolo o negligencia) |
| Procedimiento penal fiscal | § 370 AO | pena de prisión hasta 5 años (en caso de defraudación fiscal intencionada) |
Valoración práctica: en el caso de la génesis, la inspección SV se aceptó sin objeciones
- no hubo ninguna consecuencia. Pero eso fue suerte: si la DRV no hubiera aceptado los datos como PDF, sino que hubiera insistido en la evaluación mecánica (§ 147 Abs. 6 AO), el empresario habría quedado en apuros explicativos. La conservación conforme a GoBD no es una obligación teórica - se vuelve real en cada inspección externa.
Por qué Git resuelve el problema
Git cumple los requisitos de AO/GoBD by Design:
| Requisito AO/GoBD | Cómo lo cumple Git |
|---|---|
| "disponible en todo momento" (§ 146 Abs. 5) | git clone posible en todo momento - sin cuenta en la nube, sin licencia |
| "legible sin demora" (§ 147 Abs. 2) | archivos en texto plano (Markdown, JSON) - sin necesidad de versión de software |
| "evaluable mecánicamente" (§ 147 Abs. 6) | JSON-Schema-First - datos estructurados, sin necesidad de exportación a PDF |
| "medios auxiliares a costa del empresario" (§ 147 Abs. 5) | Git es OSS, gratuito - sin costes de proveedor de servicios |
| Inmutabilidad (GoBD Rz. 146) | Tags, Protected Branches, marcado de obsolescencia |
| Documentación del procedimiento (GoBD Rz. 64–91) | el propio repo es la documentación del procedimiento - git log muestra el procedimiento |
| Cambio de sistema/migración (GoBD Rz. 146–150) | Git es independiente de la versión - git clone en cualquier sistema |
Factura electrónica: los formatos XML son documentos originales según la AO
Desde el 1 de enero de 2025, la factura electrónica es obligatoria para las operaciones entre empresas nacionales (§ 14 UStG, Wachstumschancengesetz). Solo existe factura electrónica cuando se emite, transmite y recibe en un formato electrónico estructurado y permite un procesamiento electrónico (§ 14 Abs. 1 Satz 3 UStG). Un simple documento PDF ya no entra en esta categoría - desde 2025 es una "factura de otro tipo".
vor 2025"] --> U["Übergang
2025–2027"] PDF["PDF per E-Mail
vor 2025 'elektronisch'"] --> U U --> E["E-Rechnung
ab 2025 verpflichtend
strukturiert, maschinenlesbar"] E --> X["XRechnung
XML-basiert
EN 16931"] E --> Z["ZUGFeRD
hybrid: PDF + XML
ab v2.0.1"] style P fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style PDF fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style U fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style X fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Z fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
El XML es el documento original - no el PDF
El punto decisivo para la conservación: en una factura electrónica, la parte estructurada (XML) es el documento original en el sentido de la AO, no un PDF eventualmente adjunto ni una imagen legible por humanos. El BMF lo aclara (FAQ sobre la factura electrónica, pregunta 13):
"En una factura electrónica, al menos su parte estructurada debe conservarse de modo que se encuentre íntegra en su forma original."
Esto significa:
- XRechnung (basada en XML, EN 16931): el archivo XML es el documento original. Debe conservarse sin cambios. Una visualización PDF es solo una vista auxiliar - no sustituye al XML.
- ZUGFeRD (híbrida: PDF + XML incrustado): en caso de discrepancias entre la parte XML y la parte de imagen, desde 2025 prevalece la parte estructurada (XML) (BMF FAQ pregunta 12a). La imagen PDF ya no es la determinante.
AO § 147 - la factura electrónica como comprobante contable
Las facturas electrónicas son comprobantes contables en el sentido del § 147 Abs. 1 Nr. 4 AO y por tanto deben conservarse ocho años (§ 147 Abs. 3 AO). Como documentos electrónicos se aplican los requisitos de AO/GoBD:
- Disponible en todo momento (§ 147 Abs. 2): el archivo XML debe ser accesible durante todo el plazo de conservación.
- Legible sin demora (§ 147 Abs. 2): un visor XML o
el visor de facturas electrónicas de ELSTER (
www.e-rechnung.elster.de) hace legible el archivo- pero el XML mismo es texto plano y por tanto legible también sin software especializado.
- Evaluable mecánicamente (§ 147 Abs. 6): el XML es por definición legible por máquina - ideal para el § 147 Abs. 6 (acceso a los datos en la inspección externa).
- Íntegra (§ 14b Abs. 1 UStG): el archivo XML no puede modificarse. Git lo garantiza mediante la inmutabilidad tras el commit (hash SHA-256).
Normativa a escala de la UE: EN 16931 y Directiva 2014/55/EU
La factura electrónica se basa en el derecho de la UE:
- Directiva 2014/55/EU - obliga a los poderes adjudicadores a recibir y procesar facturas electrónicas (B2G).
- EN 16931 (serie de normas europeas) - define el modelo de datos semántico para las facturas electrónicas (CEN/TC 434). XRechnung y ZUGFeRD son implementaciones nacionales de esta norma EN.
- ViDA (VAT in the Digital Age) - prevista ampliación a escala de la UE de la obligación de factura electrónica e introducción de un sistema de notificación para datos de transacciones. La obligación alemana de factura electrónica prepara ViDA.
Por qué Git es ideal para las facturas electrónicas
| Requisito de factura electrónica | Cómo lo cumple Git |
|---|---|
| XML como documento original | el archivo XML se almacena sin cambios en el repo - git diff no muestra ningún cambio |
| Íntegra (§ 14b UStG) | hash SHA-256 por commit - cualquier cambio sería visible |
| Conservar 8 años (§ 147 Abs. 3) | Git-Bundle como archivo self-contained - sin necesidad de cuenta en la nube |
| Evaluable mecánicamente (§ 147 Abs. 6) | el XML es por definición legible por máquina - basta git grep |
| Validación EN 16931 | el hook Pre-Commit puede invocar el validador XRechnung/ZUGFeRD |
| Visualización (BMF FAQ 12a) | XML + sidecar Markdown legible por humanos - ambos en el repo |
| Periodo transitorio 2025–2027 | el repo puede conservar en paralelo tanto "facturas de otro tipo" (PDF) como facturas electrónicas (XML) |
Consejo práctico: un repo Git puede conservar en paralelo facturas electrónicas (XML) y facturas de otro tipo (PDF) - con una separación clara por tipo de comprobante en el sidecar (
v7g_taxonomy). El hook Pre-Commit comprueba si las facturas electrónicas tienen una estructura XML válida (esquema XRechnung/ZUGFeRD). Así se salva el periodo transitorio 2025–2027 sin cambio de soporte.
Deducciones directas en GitCover
| Punto de dolor | Concepto GitCover | Artículos de la serie |
|---|---|---|
| Autenticidad del comprobante poco clara | SHA-256 + V7GUID + sidecar .v7g.md por comprobante |
ED03, ED08 |
| Sin cadena de evidencias | repo Git con hooks dedicados funcionalmente, Grundbuch como JSON | ED06, ED07 |
| Plazos ad-hoc | checks/FRISTEN_CHECK.md + advertencia automática |
ED09 |
| Falta exportación de auditoría | GoBDExport (Z3), EuBPExport (eXTra), Evidence-Packages | ED08, ED35 |
| Cuenta de nómina pausada, costes adicionales | Git-Bundles self-contained, sin cuentas en la nube | ED08, ED09 |
| Copias antiguas/versión de software antigua, infracción GoBD | repo Git como medio de conservación self-contained, basta git clone |
ED08, ED09 |
| ¿Quién está detrás de la sociedad? | Transparenzregister: identificar, documentar y declarar los wB | ED04, ED12, ED17, ED18 |
| Sin OSS para casos especiales | GitCover cubre FZul/BSFZ, utilidad pública, tiempo de trabajo, BEM | ED25–ED34 |
Nota - obligaciones de los microempresarios desde el 1.er empleado: a menudo, los propios microempresarios ya quedan sujetos a tales obligaciones desde el 1.er empleado - registro del tiempo de trabajo (ArbZG), documentación del salario mínimo (MiLoG), vacaciones/enfermedad/BEM (BUrlG/EFZG/SGB IX), alta en la seguridad social (SGB IV). Las obligaciones desde el 1.er empleado tratadas en la Parte IV no son, pues, temas especiales de grandes empresas, sino que afectan precisamente a las microempresas y pequeñas empresas que contratan personal por primera vez. GitCover se dirige conscientemente a este umbral - el paso del empresario en solitario al empleador es el momento crítico en el que las obligaciones de cumplimiento aumentan bruscamente. Las obligaciones desde el alta de actividad comercial (clasificación en esferas, exención VBG, tarifas fijas) ya se tratan en la Parte II - surgen sin empleados.
¿Por qué Git como medio de diario?
Git es en origen un sistema de control de versiones - pero incorpora tres propiedades que lo hacen adecuado by Design para el cumplimiento:
Tagebuch-Medium"] G --> U["Unveränderbarkeit
nach Freigabe
(Tags, Protected Branches)"] G --> N["Nachvollziehbarkeit
Autor + Zeitstempel
+ kryptographische Integrität"] G --> D["Dezentralität
Git-Bundles + GCEP
Multi-Site, Off-Site"] U --> GoBD["GoBD Rz. 146
konform"] N --> Audit["Audit-Ready
reproduzierbar"] D --> Backup["Kein SPOF
verteilt"] style G fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style U fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style N fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style D fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GoBD fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Audit fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style Backup fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
- Inmutabilidad tras la aprobación - los Tags y Protected Branches garantizan que las entradas del diario aprobadas no se modifiquen posteriormente (GoBD Rz. 146). Las correcciones se realizan como nuevos commits con marcado de obsolescencia.
- Trazabilidad - cada commit lleva autor, marca de tiempo e integridad criptográfica. Todo el historial es reproducible.
- Descentralización - los Git-Bundles y GCEP (Advisory Locks) permiten un almacenamiento distribuido (Multi-Site, copia de seguridad Off-Site) sin un Single-Point-of-Failure central.
Compliance by Design - las técnicas de GitCover
La serie muestra cómo las siguientes técnicas mitigan la "imagen poco clara" de los riesgos futuros desde el principio:
maschinenlesbare
Compliance-Statements"] CBD --> OPA["OPA/Rego
Policy as Code
automatisierte Prüfung"] CBD --> V7["V7GUID Uniqueness
zeitstabile
eindeutige IDs"] CBD --> HOOKS["Git-Hooks
funktional dediziert
Pre/Post-Commit"] CBD --> ART["Code-Artefact-Typen
JSON-Schema-First
Sidecar-Pflicht"] OSCAL --> ZERT["Zertifizierungsreife
ISO 27001, AI Act, BSI GS++"] OPA --> POLICY["Sphären, Fristen,
Beitragsgruppen-Plausibilität"] V7 --> UNIQ["Kollisionsfrei,
sortierbar, dateiname-unabhängig"] HOOKS --> CHECK["Schema, Sphären,
Obsoleszenz geprüft"] ART --> SIG["Temporale Signatur
SHA-256-Belegreferenzen"] style CBD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style OSCAL fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style OPA fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style V7 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style HOOKS fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style ART fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style ZERT fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style POLICY fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style UNIQ fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style CHECK fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SIG fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33
- OSCAL - declaraciones de cumplimiento legibles por máquina (madurez de certificación para ISO 27001, AI Act, BSI GS++)
- OPA/Rego - Policy as Code, verificación automatizada de políticas (separación de esferas, plazos, plausibilidad de los grupos de cotización)
- V7GUID Uniqueness - identificadores únicos y estables en el tiempo más allá de los nombres de archivo (basados en UUIDv7, ordenables, sin colisiones)
- Git-Hooks (dedicados funcional/temáticamente) - Pre-Commit comprueba la separación de esferas, la conformidad del esquema y el estado de obsolescencia; Post-Commit genera índices y actualiza los plazos
- Tipos de artefactos de código y entradas - JSON-Schema-First, obligación de sidecar,
firma temporal
{YYMMDD HHmm}, referencias de comprobante SHA-256
Principio central de la trazabilidad temporal: el momento de registro no es un campo separado, sino que está anclado en la propia
uuidV7, como marca de tiempo de 48 bits según RFC 9562 §5.7. LauuidV7se genera a partir de una marca temporal predefinida (nonow()) mediante el helper de GitCover (UuidV7Gen), y el resto se rellena con aleatoriedad. Así, el momento de registro queda vinculado criptográficamente a la identidad del artefacto y no es modificable posteriormente. Una representación separada como cadenadatetime/datees redundante y no se mantiene en los hechos - la representación como cadena para DTO/HTMX es responsabilidad del Harness.
Referencia RFC: el componente de marca de tiempo de 48 bits de la
uuidV7corresponde a RFC 9562 §5.7 (UUIDv7) - milisegundos Unix desde Epoch (1970-01-01T00:00:00Z), 48 bits, rango de valores 0 … 2⁴⁸−1 (alcance hasta aprox. el año 10889). La especificación V7GUID está depositada con carácter normativo enwork/OSS/TOP/.gitcover/specs/v7guid/; la solicitud de patente asociada es DPMA Az. 10 2025 003 091.6.
Rutinas Helper (herramientas OSS de GitCover): en
work/OSS/TOP/tools/UuidV7Gen/se encuentra un helper OSS que proporciona dos operaciones centrales:
gen- genera unauuidV7medianteGuid.CreateVersion7()(.NET) (con marca temporal predefinida si es necesario, no solonow()) y devuelve Label, UUID y la marca de tiempo ISO decodificada.decode- extrae el componente de marca de tiempo de 48 bits de unauuidV7dada y lo devuelve como marca de tiempo ISO-8601.Estos helpers son decisivos para crear una clave
uuidV7válida a partir de claves externas (p. ej., una marca temporal en los datos o en el nombre de archivo) - y al mismo tiempo documentar los requisitos temporales de la GoBD (registro inmediato, trazabilidad). El valor de 48 bits es el único factor de la derivación de la TenantId y puede ser, en lugar de la hora del sistema, un momento explícitamente predefinido (p. ej., a partir de una marca temporal de un certificado ELSTER, la fecha de un recibo con TSE, etc.) - la interpretación sigue la documentación del procedimiento.
Principio del sidecar (
.v7g.md): cada sidecar lleva un Composite KeyV7GUID:uuidV7:
V7GUID(Class Identifier) - clasifica el sidecar según la Registry.gitcover(qué/qué tipo)uuidV7(Object ID) - identidad del propio sidecar, generado con marca temporal predefinida/marca de tiempo de 48 bits anclada en la GUIDv7g_taxonomy[].v7guid- Object ID del documento clasificadoAsí no solo queda identificado de forma única el documento, sino también el acto de clasificación mismo - incluido el momento (en
uuidV7), quién clasificó y en qué rol. Sin campodatetimeseparado.
Risiko-Leverage - lo que hoy es barato (cheap) y mañana será a prueba de auditoría
Risiko-Leverage: los hechos registrados hoy con costes mínimos (minutos, con 'agentes' solo instantes) se convierten en futuras evidencias a prueba de auditoría (horas de inspección). El empresario "apalanca" una posición de carga de la prueba - el cumplimiento como palanca.
| Hoy (cheap, ~minutos/segundos) | Mañana (a prueba de auditoría, ~horas de inspección) | Riesgo mitigado |
|---|---|---|
| Entrada de diario JSON con V7GUID + SHA-256 | Evidencia conforme a GoBD (10 años) | Infracción del plazo de conservación |
Campo source por hecho |
Carga de la prueba en inspección FA/SV | Degradación del valor probatorio |
| Archivo de verificación de plazos | Incumplimiento de plazos evitado | Recargos por demora § 152 AO |
| Etiqueta de esfera por entrada | Estatus de utilidad pública defendido | Revocación § 51 AO |
| Diario de justificación de horas FZul | Certificado BSFZ obtenible | Pérdida de FZul (hasta 1 mill. EUR) |
Sidecar .v7g.md por comprobante |
Autenticidad del comprobante demostrable | Impugnación de la fuerza probatoria |
| JSON de tiempo de trabajo por día | Conformidad con ArbZG demostrable | Multa § 22 ArbZG |
| Git-Bundle en lugar de cuenta en la nube | Conservación sin costes de proveedor de servicios | Pérdida de acceso GoBD tras la pausa de la cuenta |
git clone en lugar de reactivación de la versión del software |
Conservación self-contained, sin dependencia de versiones | Infracción GoBD por sistemas antiguos no reactivables |
Lo que muestra esta serie
La serie sigue a un empresario ficticio (E1) que gestiona una organización
KMU (marcador de posición, abierto en cuanto a la forma jurídica) y lleva su diario en un repo Git.
La estructura se basa en un concepto SSoT real, pero está
completamente anonimizada - todos los datos de personas, empresas, HRB, IBAN y
números fiscales se sustituyen por marcadores de posición.
Nota DSGVO: todas las referencias a personas/empresas en esta serie son ficticias o anonimizadas. Cualquier parecido con organizaciones reales es casual y no intencionado.
Avance de la serie
Grundlagen
ED01–ED04"] II["Teil II
GoBD, AO, Finanzamt
+ Pflichten ab Gewerbeanmeldung
ED05–ED12"] III["Teil III
Behörden & Verbände
ED13–ED19"] IV["Teil IV
Mitarbeiter & Lohn
+ Pflichten ab 1. Mitarbeiter
ED20–ED27"] I --> II --> III --> IV style I fill:#E5E7EB,stroke:#6B7280,color:#0F1B33 style II fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style III fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style IV fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33
Besondere Herausforderungen
FZul/BSFZ, Gemeinnützigkeit
ED28–ED31"] VI["Teil VI
Harness-Anforderungen
ED32–ED35"] VII["Teil VII
Anhang
ED36–ED37"] V --> VI --> VII style V fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style VI fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style VII fill:#E5E7EB,stroke:#6B7280,color:#0F1B33
| Parte | Tema | Artículos |
|---|---|---|
| I | Fundamentos (este artículo) | ED01–ED03 |
| II | Gestión empresarial: GoBD, AO, Finanzamt + obligaciones desde el alta de actividad comercial (esferas, VBG, tarifas fijas) | ED05–ED11 |
| III | Autoridades y asociaciones | ED13–ED19 |
| IV | Empleados y nóminas + obligaciones desde el 1.er empleado (tiempo de trabajo, MiLoG, vacaciones/enfermedad/BEM) | ED20–ED27 |
| V | Desafíos especiales (FZul/BSFZ, utilidad pública) | ED28–ED31 |
| VI | Requisitos del Harness | ED32–ED35 |
| VII | Anexo (glosario, fuentes) | ED36–ED37 |
Requisito del Harness (avance)
Deducible de ED01:
| ID | Requisito | Prioridad |
|---|---|---|
| FA-1.1 | Entradas del diario como artefactos JSON (Schema-First) | MUST |
| FA-1.2 | Composite Key V7GUID (Class) : uuidV7 (Object) - sin campo datetime/date separado; el tiempo en uuidV7 (RFC 9562 §5.7) |
MUST |
| FA-1.3 | uuidV7 generado a partir de una marca temporal predefinida (no now()) mediante Helper |
MUST |
| FA-2.1 | SHA-256 como ID de comprobante | MUST |
| FA-2.2 | Obligación de sidecar .v7g.md |
MUST |
| FA-4.1 | Archivo de verificación de plazos | MUST |
| TA-2.1 | Pre-Commit: validación de JSON-Schema | MUST |
La lista completa de requisitos en Harness-Anforderungen.md.
Fuentes
- Comprobante de la génesis de la inspección SV (anonimizado):
AFJD/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.mdsección J - GoBD (BMF-Schreiben del 28.11.2019, BStBl I S. 1269, última modificación 14.07.2025, BStBl I S. 1502)
- AO (§§ 146, 147, 152, 162, 370, 379)
- SGB IV (§ 28p - inspección de empresa)
- UStG (§ 14 - factura electrónica, § 14b - conservación)
- FAQ del BMF sobre factura electrónica (versión de marzo de 2026, bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html)
- EN 16931 (serie de normas europeas, CEN/TC 434)
- Directiva 2014/55/EU (factura electrónica B2G)
- RFC 9562 §5.7 (UUIDv7) - marca de tiempo Unix-ms de 48 bits
- Especificación V7GUID -
work/OSS/TOP/.gitcover/specs/v7guid/(normativa) - DPMA Az. 10 2025 003 091.6 - solicitud de patente V7GUID (reivindicación principal 2, reivindicaciones 5–8)
- Herramienta OSS de GitCover
UuidV7Gen-work/OSS/TOP/tools/UuidV7Gen/(rutinas Helpergen/decode) - DSGVO (obligación de anonimización al publicar)
Topología de fuentes y enlaces de referencia CDN
| Rol | Lugar | Propósito |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Depósito canónico (firmado con GPG, versionado) |
| Public OSS Mirror / CDN | codeberg.org/gitcover-commons | Espejo de solo lectura; descubrimiento FLOSS |
| Community Hub | github.com/gitcover-commons | Issues y Discussions; referencia del código fuente en Codeberg |
Nota: esta asignación de fuentes, mirror y community hub refleja el estado actual y puede cambiar. Por favor, compruebe la fuente canónica respectiva en
git.gitcover.org/GCCpara conocer el estado actual. fuente canónica en gitcover.org para el estado actual.