ED07 - Plazos de conservación e inmutabilidad: Git-Hooks, Paquetes de evidencia

Problema

GoBD y AO exigen conservación a largo plazo, pero la práctica falla en la implementación:

"¿10 años? Eso lo resuelve la nube." - muchos empresarios creen que el software en la nube gestiona la conservación automáticamente - pero al cancelar la cuenta, los datos a menudo ya no están disponibles (véase ED01 punto de dolor 6-7)
Cuenta en la nube cancelada, datos perdidos - la cuenta de nómina fue pausada, las antiguas cuentas salariales solo pueden reactivarse con costes adicionales - incumplimiento de GoBD (§ 146 Abs. 5 AO)
Versiones antiguas de software no reactivables - las copias de seguridad requieren la versión antigua del software, que ya no es instalable
- incumplimiento de GoBD (§ 147 Abs. 2 AO: "legible de inmediato")
Sin inmutabilidad - asientos contables modificados a posteriori sin trazabilidad - incumplimiento de GoBD (Rz. 146)
Sin paquetes de evidencia - en una auditoría externa, el auditor no puede ser provisto con un soporte de datos (Z3) - incumplimiento de GoBD (§ 147 Abs. 6 AO)
Plazos de conservación desconocidos - ¿10 años? ¿8 años? ¿6 años? Muchos empresarios no conocen los plazos para sus documentos

Afirmación central

La conservación conforme a GoBD con Git significa:

Los Git-Bundles son autocontenidos - sin cuenta en la nube, sin licencia de software, sin proveedor de servicios - basta con git clone
Los plazos de conservación se documentan en el repositorio - cada artefacto lleva su plazo en el Sidecar (obsolescence + fecha del plazo)
Inmutabilidad mediante Tags y Ramas Protegidas - las versiones aprobadas son criptográficamente inmutables
Paquetes de evidencia para cierres de período - git bundle + Static-Web (Z3+) para el auditor (véase ED04)
Verificación de plazos como artefacto Git - checks/FRISTEN_CHECK.md advierte sobre plazos inminentes

Cumplimiento por diseño: la conservación no es algo posterior - se genera mediante la elección del medio. Los Git-Bundles son autocontenidos y sobreviven a cualquier bloqueo de la nube, a cualquier cambio de versión de software, a cualquier cancelación de proveedor.

Plazos de conservación según AO § 147

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD AO["AO § 147
Plazos de conservación"] AO --> J10["10 años
§ 147 Abs. 1 Nr. 1"] AO --> J8["8 años
§ 147 Abs. 1 Nr. 4"] AO --> J6["6 años
§ 147 Abs. 1 Nr. 2/3/5"] J10 --> D10["Libros, registros
Inventarios, balances anuales
Balance de apertura
Instrucciones de trabajo"] J8 --> D8["Documentos de soporte contable
Facturas electrónicas (XML)
Documentos de nómina"] J6 --> D6["Correspondencia comercial
E-mails (EML)
Otros documentos"] style AO fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style J10 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style J8 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style J6 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style D10 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style D8 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style D6 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Plazo	Tipo de documento	Base legal	Ejemplos
10 años	Libros, registros, inventarios, balances anuales, balance de apertura, instrucciones de trabajo	§ 147 Abs. 1 Nr. 1 AO	Libro mayor (JSON), documentación de procedimientos, plan de cuentas
8 años	Documentos de soporte contable	§ 147 Abs. 1 Nr. 4 AO	Facturas electrónicas (XML), liquidaciones de nómina, resoluciones de la seguridad social
6 años	Correspondencia comercial, otros documentos	§ 147 Abs. 1 Nr. 2/3/5 AO	E-mails (EML), correspondencia, notas

Importante - inicio del plazo: El plazo comienza con el cierre del año calendario en que se realizó la última anotación, se elaboró el balance anual, se recibió el documento de soporte o se realizó el registro (§ 147 Abs. 4 AO). Un asiento del 15.08.2026 inicia el plazo el 31.12.2026 - 10 años terminan el 31.12.2036.

Inmutabilidad mediante Git

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD B["Asiento contable
Commit"] B --> H["Hash SHA-256
del Commit"] H --> T["Tag
(Marcador de aprobación)"] T --> P["Rama Protegida
(sin Force-Push)"] P --> U["Inmutabilidad
GoBD Rz. 146"] K["Corrección necesaria"] K --> NC["Nuevo Commit
+ Marcación de obsolescencia"] NC --> O["El original permanece
trazable"] style B fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style H fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style T fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style P fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style U fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style K fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style NC fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style O fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Mecanismo	Funcionalidad Git	Referencia GoBD
Hash del Commit	Hash SHA-256 por Commit - cada cambio genera un nuevo hash	Rz. 146 (Inmutabilidad)
Tags	Marcadores inmutables para versiones aprobadas	Rz. 146 (Aprobación)
Ramas Protegidas	`main` protegida, sin Force-Push, sin Rebase	Rz. 146 (sin reescritura)
Obsolescencia	Correcciones como nuevos Commits con `superseded_by`	Rz. 146 (Trazabilidad)
Firma GPG	Commits firmados - autenticidad demostrable	Rz. 146 (Autoría)

Importante - historia lineal: Conforme a GoBD solo es válida la historia lineal sin reescritura. git rebase, git commit --amend y git push --force sobre main están prohibidos. El Pre-Commit-Hook verifica que no se realicen Force-Pushes y que las correcciones se realicen como nuevos Commits con marcación de obsolescencia.

Paquetes de evidencia para la conservación

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD FY["Ejercicio fiscal
p. ej. FY2026"] FY --> EP["Tenant Evidence Package
(Cierre de período)"] EP --> GB["git bundle
Archivo autocontenido"] EP --> SW["Static-Web
(Z3+ Navegador)"] EP --> MF["Manifiesto
+ Sumas de verificación SHA-256"] GB --> USB["Memoria USB
o copia de seguridad externa"] SW --> USB MF --> USB USB --> PR["Auditor
git clone o index.html
sin conexión, sin IAM"] style FY fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style EP fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style GB fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SW fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style MF fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style USB fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style PR fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Un Tenant Evidence Package (véase ED04 Z3+) para un ejercicio fiscal contiene:

Componente	Contenido	Referencia GoBD
git bundle	Repositorio completo (historia, Commits, Tags)	§ 147 Abs. 6 AO (Soporte de datos Z3)
Static-Web	Sitio web navegable por navegador (HTML/PDF/JSON)	Z3+ (Acceso del auditor sin IAM)
Manifiesto	Sumas de verificación SHA-256 por archivo, índice V7GUID	Rz. 146 (Integridad)
Documentación de procedimientos	Renderizada como HTML	Rz. 64-91 (Documentación de procedimientos)
Documentos DMS	Todos los documentos de soporte (PDF, XML, EML)	§ 147 Abs. 1 (Conservación)
Contratos	Documentos que trascienden el período	§ 147 Abs. 1 Nr. 2/3 (Correspondencia comercial)

La conservación más segura: Una memoria USB con git bundle + Static-Web + Manifiesto es autocontenida, sin conexión, sin IAM, sin cuenta en la nube, sin licencia de software. Sobrevive a cualquier cancelación de proveedor, a cualquier cambio de versión de software, a cualquier bloqueo de la nube. Esta es la forma más segura de conservación conforme a GoBD - porque no hay dependencias.

Naturalmente, se debe prestar atención a la seguridad física de la memoria USB (caja fuerte, protección contra incendios, copia de seguridad externa).

Gestión de plazos en el repositorio

`checks/FRISTEN_CHECK.md`

# Verificación de plazos

## Antelación (hasta