ED01 - Motivación: Por qué un empresario lleva su diario en Git

Problema

Un empresario funda una organización y se enfrenta a 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 se corre el riesgo de incumplir? ¿Qué autoridades se anuncian, cuándo y para qué inspección?

La práctica actual en el ámbito de las KMU se caracteriza por:

• Gestión de papeles y listas locales de Excel: no trazable, no a prueba de auditoría
• Caos de PDF y correos electrónicos en las inspecciones: la documentación se arma de forma ad hoc
• Soluciones aisladas (software de nóminas aquí, contabilidad allá, archivo de comprobantes en otro lugar): sin cadena de prueba continua
• Lagunas de código abierto en obligaciones especiales (tiempo de trabajo, gastos de viaje, complementos, BEM, FZul/BSFZ, utilidad pública): aquí casi no existe apoyo libre
• Acumulación de riesgos: las obligaciones se ignoran hoy de forma barata hasta que mañana se vuelven caras en forma de multas, recargos por presentación tardía o revocaciones

Afirmación central

No solo los documentos deben ser a prueba de auditoría; también las decisiones, los plazos y las referencias de comprobantes deben ser trazables, reproducibles y auditables. Un diario nativo de Git hace exactamente eso: convierte hechos registrados hoy de forma barata (cheap) (una entrada JSON con V7GUID + referencia de comprobante SHA-256) en futuras pruebas a prueba de auditoría. El cumplimiento se convierte en palanca, no en freno.

Compliance by Design: la "imagen poco clara" de los riesgos futuros se mitiga mediante técnicas GitCover (OSCAL, OPA, V7GUID, Git-Hooks) desde el principio, no solo cuando el auditor llama a la puerta.

El diario como agenda de trabajo empresarial

El diario no es un cuaderno privado ni un calendario de tiempo de trabajo llevado a posteriori. Es la SSoT temporal del trabajo: la agenda muestra qué prestación, decisión o aclaración surgió y cuándo, y a qué comprobante, contrato o expediente se remonta. Así, una misma prueba de trabajo puede servir a distintos objetivos sin construir una historia nueva para cada inspección:

• BSFZ/FZulG: los proyectos de I+D, el tiempo de prestación y la delimitación se documentan de forma oportuna.
• FA/EStG/EÜR: la motivación empresarial y las partes privadas/empresariales siguen siendo trazables.
• USt: el periodo de prestación, el cumplimiento contractual y la referencia a la factura se pueden vincular.
• GoBD/AO: el comprobante, la decisión, la aprobación y el cambio forman una cadena retrógrada/progresiva.
• Riesgo y portabilidad: la empresa no depende de la memoria de una sola persona ni de un portal del fabricante; los hechos residen en artefactos Git abiertos y versionados.

La regla es sencilla: el diario describe la agenda; los repositorios conservan la prueba. Un agente solo puede derivar del diario lo que sostienen los documentos originales vinculados y los sidecars. Así, el cumplimiento no se trata como trabajo adicional posterior, sino como un flujo de trabajo normal.

Génesis: La inspección de la seguridad social como desencadenante práctico

La idea de GitCover no nació en una torre de marfil, sino de experiencias prácticas concretas: la última, de una inspección de la seguridad social en una UG mínima (aquí anonimizada como ORG-V por "organización predecesora") para el periodo 2021–2023; realizada en el periodo 02/2024–03/2025. La inspección reveló puntos de dolor que abordan las técnicas GitCover.

Cronología de la inspección SV

¿Qué ocurrió?

Resultado financiero (neto)

Puntos de dolor: lo que reveló la inspección

1. Sin oficina, sin fax, sin empleados, y aun así tener que tramitar una inspección de la seguridad social exclusivamente por correo electrónico con archivos PDF y ZIP. Las herramientas no existían para este caso mínimo.
2. Autenticidad de los comprobantes poco clara: los PDF enviados por correo electrónico no tienen anclaje criptográfico. ¿Quién cambió qué y cuándo? La fuerza probatoria solo se sostenía mediante trazabilidad manual.
3. Sin cadena de prueba continua: las cuentas de nómina, las declaraciones a la seguridad social, los justificantes de cotización y los comprobantes de reembolso estaban en lugares distintos, sin referencias cruzadas. Cada consulta exigía una nueva búsqueda.
4. Gestión de plazos ad hoc: los plazos de audiencia, de reembolso y de recurso se mantenían manualmente en el calendario. Sin aviso ante el vencimiento inminente.
5. Faltaba la exportación para auditoría: la DRV exigía datos en formato euBP (eXTra V3.4.0); la autoridad fiscal habría requerido un soporte de datos Z3. Ambas cosas solo eran posibles con software especializado o preparación manual.
6. Salida del empleado → cuenta de nóminas en pausa: tras la salida del entonces empleado, la cuenta de liquidación de nóminas en el proveedor de servicios quedó en pausa. ¿Quién mantiene innecesariamente una cuenta en la nube generando costes cuando el motivo ya no existe (empleado salido, no hacen falta más liquidaciones)? Sin embargo, la preparación del paquete de documentos para la inspección exigió entonces costes adicionales extraordinarios en el proveedor de servicios, que al final fueron superiores al pequeño "reembolso" al término de la inspección.
7. Reactivación de copias de seguridad antiguas con una versión de software antigua: para volver a hacer accesibles las cuentas de nómina 2021–2023, hubo que reactivar las copias de seguridad antiguas con la versión de software antigua, un problema práctico considerable. Formalmente, esto es una infracción de la obligación GoBD de garantizar también técnicamente que se pueda acceder en todo momento durante el largo plazo de conservación (10 años). En la práctica, esta obligación entra en conflicto con la presión económica de no mantener cuentas en la nube sin uso generando costes. Precisamente esta tensión es un motivo central de GitCover: los Git-Bundles son autocontenidos; 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 cumplido técnicamente.

Fundamentos jurídicos: AO § 146, § 147 y GoBD

La "infracción de la obligación GoBD" mencionada en el punto 7 tiene una base jurídica clara: en la Abgabenordnung (AO) y en los GoBD (principios para el llevado y conservación ordenados de libros, registros y documentos en forma electrónica, así como para el acceso a los datos, escrito del BMF).

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 garantizarse 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 garantizar durante todo el plazo de conservación (10 años para libros/registros, 8 años para comprobantes de contabilización, § 147 Abs. 3 AO) que los datos estén disponibles en todo momento y legibles sin demora. Una cuenta en la nube en pausa que solo se reactiva pagando costes adicionales infringe esta obligación: los datos no están "disponibles en todo momento", sino solo mediante pago y con retraso.

AO § 147 Abs. 2 - Conservación en soportes de datos

"Con excepción de los balances 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, si ello corresponde a los principios de una contabilidad ordenada y está garantizado que la reproducción o los datos [...] están disponibles en todo momento, pueden hacerse legibles sin demora y pueden evaluarse por medios automáticos durante todo el plazo de conservación."

De nuevo: "disponibles en todo momento", "legibles sin demora", "evaluables por medios automáticos". Una versión antigua de software que primero debe reactivarse no cumple "sin demora".

AO § 147 Abs. 5 - Medios auxiliares a cargo 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 su costa los medios auxiliares necesarios para hacer legibles los documentos."

Esto significa que, 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. Ese fue exactamente el problema práctico en el caso de génesis: copias de seguridad antiguas, versión de software antigua, medios auxiliares ya no disponibles.

AO § 147 Abs. 6 - Acceso a los datos en la inspección tributaria

"Si los documentos del apartado 1 se han creado con ayuda de un sistema de procesamiento de datos, la autoridad financiera puede exigir, en el marco de una inspección tributaria [...], que los datos se pongan a disposición para su evaluación automática conforme a sus especificaciones."

En una inspección tributaria, el empresario debe poner los datos a disposición de forma que puedan evaluarse automáticamente, no como impresión PDF, sino como datos estructurados. Una cuenta en la nube en pausa que solo ofrece exportación a PDF no basta.

GoBD - Documentación del procedimiento y cambio de sistema

Los GoBD concretan estas disposiciones de la AO para sistemas electrónicos. Requisitos centrales:

• Documentación del procedimiento (GoBD Rz. 64–91): todo sistema electrónico de contabilidad debe disponer de una documentación del procedimiento que describa el proceso, 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 garantizarse que los datos del sistema antiguo sigan disponibles, legibles y evaluables automáticamente. La documentación del procedimiento debe documentar el cambio.
• Inmutabilidad (GoBD Rz. 146): tras la contabilización, los datos no pueden modificarse. Las correcciones deben realizarse como nuevas entradas con justificación.

Consecuencias teóricas en caso de infracción

Clasificación práctica: en el caso de génesis, la inspección SV se aceptó sin objeciones y no hubo consecuencias. Pero eso fue suerte: si la DRV no hubiera aceptado los datos como PDF y hubiera insistido en una evaluación automática (§ 147 Abs. 6 AO), el empresario se habría visto en apuros para explicar. La conservación conforme a GoBD no es una obligación teórica: se vuelve real en cada inspección tributaria.

Por qué Git resuelve el problema

Git cumple los requisitos AO/GoBD by Design:

Factura electrónica: los formatos XML son documentos originales en la AO

Desde el 1 de enero de 2025, la factura electrónica es obligatoria para operaciones entre empresas nacionales (§ 14 UStG, Ley de oportunidades de crecimiento). Solo existe factura electrónica cuando se emite, transmite y recibe en un formato electrónico estructurado y permite el procesamiento electrónico (§ 14 Abs. 1 Satz 3 UStG). Un simple documento PDF ya no se incluye en esta categoría: desde 2025 es una "otra factura".

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 que eventualmente se adjunte ni una imagen legible por personas. 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 esté intacta en su forma original."

Esto significa:

• XRechnung (basada en XML, EN 16931): el archivo XML es el documento original. Debe conservarse sin modificaciones. Una visualización PDF es solo una representación auxiliar: no sustituye al XML.
• ZUGFeRD (híbrido: PDF + XML incrustado): en caso de divergencias entre la parte XML y la parte de imagen, desde 2025 prevalece la parte estructurada (XML) (FAQ del BMF, pregunta 12a). La imagen PDF ya no es determinante.

AO § 147 - La factura electrónica como comprobante de contabilización

Las facturas electrónicas son comprobantes de contabilización 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 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 en sí es texto claro y, por tanto, también es legible sin software especializado.
• Evaluable automáticamente (§ 147 Abs. 6): el XML es legible por máquina por definición, ideal para § 147 Abs. 6 (acceso a datos en la inspección tributaria).
• Intacta (§ 14b Abs. 1 UStG): el archivo XML no puede modificarse. Git lo cumple mediante la inmutabilidad tras el commit (hash SHA-256).

Normas de la UE: EN 16931 y Directiva 2014/55/EU

La factura electrónica se basa en derecho de la UE:

• Directiva 2014/55/EU: obliga a los poderes adjudicadores públicos a recibir y procesar facturas electrónicas (B2G).
• EN 16931 (serie de normas europeas): define el modelo de datos semántico para facturas electrónicas (CEN/TC 434). XRechnung y ZUGFeRD son implementaciones nacionales de esta norma EN.
• ViDA (VAT in the Digital Age): ampliación prevista en toda la UE de la obligación de factura electrónica e introducción de un sistema de comunicación de datos de transacciones. La obligación alemana de factura electrónica prepara ViDA.

Por qué Git es ideal para facturas electrónicas

Consejo práctico: un repositorio Git puede conservar en paralelo facturas electrónicas (XML) y otras facturas (PDF), con una separación clara por tipo de comprobante en el sidecar (v7g_taxonomy). El hook de pre-commit comprueba si las facturas electrónicas tienen una estructura XML válida (esquema XRechnung/ZUGFeRD). Así se supera el periodo transitorio 2025–2027 sin ruptura de medio.

Derivaciones directas en GitCover

Aviso: obligaciones de microempresarios a partir de 1 empleado: a menudo, incluso los microempresarios ya están sujetos desde el 1 empleado a obligaciones como el registro del tiempo de trabajo (ArbZG), la documentación del salario mínimo (MiLoG), vacaciones/enfermedad/BEM (BUrlG/EFZG/SGB IX) y la afiliación a la seguridad social (SGB IV). Por tanto, las obligaciones tratadas en la Parte IV a partir de 1 empleado no son temas especiales de grandes empresas, sino que afectan precisamente a microempresas y pequeñas empresas que contratan personal por primera vez. GitCover se dirige conscientemente a ese umbral: la transición de empresario individual a empleador es el momento crítico en el que las obligaciones de cumplimiento aumentan de golpe. Las obligaciones desde el alta de la actividad (clasificación de esferas, exención VBG, importes a tanto alzado) ya se tratan en la Parte II; surgen sin empleados.

¿Por qué Git como medio de diario?

Git es originalmente un sistema de control de versiones, pero aporta tres propiedades que lo hacen by Design adecuado para el cumplimiento:

1. Inmutabilidad tras la aprobación: los tags y las protected branches garantizan que las entradas de diario aprobadas no se modifiquen a posteriori (GoBD Rz. 146). Las correcciones se realizan como nuevos commits con marcado de obsolescencia.
2. Trazabilidad: cada commit lleva autor, marca de tiempo e integridad criptográfica. Toda la historia es reproducible.
3. Descentralización: los Git-Bundles y GCEP (Advisory Locks) permiten un almacenamiento distribuido (multi-site, copia de seguridad off-site) sin un único punto de fallo central.

Compliance by Design: las técnicas GitCover

La serie muestra cómo las siguientes técnicas mitigan la "imagen poco clara" de los riesgos futuros desde el principio:

• OSCAL: declaraciones de cumplimiento legibles por máquina (preparación para certificación ISO 27001, AI Act, BSI GS++)
• OPA/Rego: Policy as Code, verificación automatizada de directrices (separación de esferas, plazos, plausibilidad de 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 y materialmente): el pre-commit comprueba la separación de esferas, la conformidad con el esquema y el estado de obsolescencia; el post-commit genera índices y actualiza plazos
• Tipos de artefactos de código y entradas: esquema JSON primero, sidecar obligatorio, 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. La uuidV7 se genera a partir de una marca de tiempo predefinida (no now()) mediante el helper de GitCover (gc-v7guid), y el resto se rellena con aleatoriedad. Así, el momento de registro queda vinculado criptográficamente a la identidad del artefacto y no puede modificarse a posteriori. Una representación separada de datetime/date como cadena es redundante y no se incluye 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 uuidV7 corresponde a RFC 9562 §5.7 (UUIDv7): milisegundos Unix desde la época (1970-01-01T00:00:00Z), 48 bits, rango de valores 0 … 2⁴⁸−1 (alcance hasta aproximadamente el año 10889). La especificación V7GUID está depositada de forma normativa en work/OSS/TOP/.gitcover/specs/v7guid/; la solicitud de patente correspondiente es DPMA Az. 10 2025 003 091.6.

Rutinas auxiliares (GitCover OSS Tools): en work/OSS/gc-v7guid hay un helper OSS que proporciona dos operaciones centrales:

• gen: genera una uuidV7 mediante Guid.CreateVersion7() (.NET) (con marca de tiempo predefinida cuando sea necesario, no solo now()) y devuelve etiqueta, UUID y la marca de tiempo ISO decodificada.
• decode: extrae el componente de marca de tiempo de 48 bits de una uuidV7 dada y lo devuelve como marca de tiempo ISO-8601.

Estos helpers son decisivos para crear una clave uuidV7 válida a partir de claves externas (p. ej., una marca de tiempo en los datos o en el nombre del archivo) y, al mismo tiempo, documentar los requisitos temporales de GoBD (registro oportuno, trazabilidad). El valor de 48 bits es el único factor de la derivación de TenantId y, en lugar de la hora del sistema, también puede ser un momento explícitamente predefinido (p. ej., a partir de una marca de tiempo de un certificado ELSTER, la fecha de un recibo con TSE, etc.); la interpretación sigue la documentación del procedimiento.

Principio de sidecar (.gc.md): cada sidecar lleva una clave compuesta V7GUID:uuidV7:

• V7GUID (Class Identifier): clasifica el sidecar según el registro .gitcover (qué/tipo)
• uuidV7 (Object ID): identidad del propio sidecar, generada con marca de tiempo predefinida/marca de tiempo de 48 bits anclada en el GUID
• v7g_taxonomy[].v7guid: Object ID del documento clasificado
• sha256: identidad del documento original clasificado, la prueba de originalidad, siempre y en todas partes (incluso cuando el documento se desplaza: independiente de ruta/nombre, calculada a partir del contenido)

Así no solo queda identificado unívocamente el documento (mediante su SHA-256), sino también el acto de clasificación mismo, incluido el momento (en uuidV7), quién clasificó y en qué rol. Sin campo datetime separado.

Apalancamiento de riesgo: lo que hoy es barato (cheap) y mañana será a prueba de auditoría

Apalancamiento de riesgo: los hechos registrados hoy con costes mínimos (minutos, con 'agentes' solo instantes) se convierten en futuras pruebas a prueba de auditoría (horas de revisión). El empresario "eleva" una posición de carga de la prueba: el cumplimiento como palanca.

Qué muestra esta serie

La serie sigue a un empresario ficticio (E1) que dirige una organización KMU (marcador de posición, de forma jurídica abierta) y lleva su diario en un repositorio Git. La estructura se inspira en un concepto real de SSoT, pero está completamente anonimizada: todos los datos de personas, empresas, HRB, IBAN y números fiscales se sustituyen por marcadores de posición.

Aviso RGPD: todas las referencias a personas y empresas en esta serie son ficticias o están anonimizadas. Cualquier parecido con organizaciones reales es casual y no intencionado.

Vista previa de la serie

Requisito del harness (vista previa)

Derivable de ED01:

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

Fuentes

• Comprobante de génesis de la inspección SV (anonimizado): E1/FY2025/BSFZ/Nachweise/00_BELEG_INVENTAR.md sección J
• GoBD (escrito del BMF de 28.11.2019, BStBl I S. 1269, modificado por última vez el 14.07.2025, BStBl I S. 1502)
• AO (§§ 146, 147, 152, 162, 370, 379)
• SGB IV (§ 28p - inspección de la seguridad social)
• UStG (§ 14 - factura electrónica, § 14b - conservación)
• FAQ del BMF sobre la factura electrónica (estado: 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 en 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 GitCover gc-v7guid - work/OSS/gc-v7guid (rutinas auxiliares gen/decode)
• RGPD (obligación de anonimización en publicaciones)

Topología de fuentes y enlaces de referencia CDN

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