ED08 - Plazos de conservación e inmutabilidad: hooks de Git, paquetes de evidencia

Problema

GoBD y AO exigen conservación a largo plazo, pero su aplicación práctica fracasa:

"¿10 años? Eso lo regula la nube." - muchos empresarios creen que el software en la nube regula la conservación automáticamente, pero al cancelar la cuenta los datos suelen dejar de estar disponibles (véase ED01, puntos de dolor 6–7)
"Cuenta en la nube cancelada, datos perdidos" - la cuenta de nóminas se pausó y las cuentas de nóminas antiguas solo se pueden reactivar con costes adicionales - incumplimiento de GoBD (§ 146 Abs. 5 AO)
"Las versiones antiguas del software no se pueden reactivar" - las copias de seguridad requieren la versión antigua del software, que ya no se puede instalar - incumplimiento de GoBD (§ 147 Abs. 2 AO: "legible de inmediato")
"Falta de inmutabilidad" - asientos modificados a posteriori sin trazabilidad - incumplimiento de GoBD (Rz. 146)
"No hay paquetes de evidencia" - en una auditoría externa, el auditor no puede recibir un soporte de datos (Z3) - incumplimiento de GoBD (§ 147 Abs. 6 AO)
"No se conocen los plazos de conservación" - ¿10 años? ¿8 años? ¿6 años? Muchos empresarios no conocen los plazos aplicables a sus documentos

Mensaje principal

La conservación conforme con GoBD mediante Git significa:

Los Git bundles son autocontenidos - sin cuenta en la nube, sin licencia de software ni proveedor de servicios - git clone basta
Los plazos de conservación se documentan en el repositorio - cada artefacto lleva su plazo en el sidecar (obsolescence + fecha de vencimiento)
Inmutabilidad mediante tags y Protected Branches - las versiones aprobadas son criptográficamente inmutables
Paquetes de evidencia para cierres de ejercicio - git bundle + Static-Web (Z3+) para auditores (véase ED05)
Comprobación de plazos como artefacto de Git - checks/FRISTEN_CHECK.md avisa de plazos inminentes

Cumplimiento por diseño: La conservación no se realiza a posteriori - surge de la elección del soporte. Los Git bundles son autocontenidos y sobreviven a todo bloqueo de la nube, todo cambio de versión del software y toda cancelación del proveedor de servicios.

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
Aufbewahrungsfristen"] AO --> J10["10 Jahre
§ 147 Abs. 1 Nr. 1"] AO --> J8["8 Jahre
§ 147 Abs. 1 Nr. 4"] AO --> J6["6 Jahre
§ 147 Abs. 1 Nr. 2/3/5"] J10 --> D10["Bücher, Aufzeichnungen
Inventare, Jahresabschlüsse
Eröffnungsbilanz
Arbeitsanweisungen"] J8 --> D8["Buchungsbelege
E-Rechnungen (XML)
Lohnbelege"] J6 --> D6["Handels- / Geschäftsbriefe
E-Mails (EML)
Sonstige Unterlagen"] 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	Fundamento jurídico	Ejemplos
10 años	Libros contables, registros, inventarios, cuentas 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	Justificantes de asientos	§ 147 Abs. 1 Nr. 4 AO	Facturas electrónicas (XML), liquidaciones de nómina, notificaciones de la SV
6 años	Correspondencia comercial / de negocios, otros documentos	§ 147 Abs. 1 Nr. 2/3/5 AO	Correos electrónicos (EML), correspondencia, notas

Importante: inicio del plazo: El plazo comienza al finalizar el ejercicio natural en el que se realizó la última anotación, se elaboraron las cuentas anuales, se recibió el justificante o se efectuó el registro (§ 147 Abs. 4 AO). Un asiento del 15.08.2026 inicia el plazo el 31.12.2026; los 10 años finalizan el 31.12.2036.

Inmutabilidad mediante Git

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD B["Buchung
Commit"] B --> H["SHA-256-Hash
des Commits"] H --> T["Tag
(Freigabe-Marker)"] T --> P["Protected Branch
(kein Force-Push)"] P --> U["Unveränderbarkeit
GoBD Rz. 146"] K["Korrektur nötig"] K --> NC["Neuer Commit
+ Obsoleszenz-Markierung"] NC --> O["Original bleibt
nachvollziehbar"] 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	Función de Git	Relación con GoBD
Hash del commit	Hash SHA-256 por commit - cada cambio genera un hash nuevo	Rz. 146 (inmutabilidad)
Tags	Marcadores inmutables para versiones aprobadas	Rz. 146 (aprobación)
Protected Branches	`main` protegido, sin force push ni rebase	Rz. 146 (sin reescritura)
Obsolescencia	Correcciones como nuevos commits con `superseded_by`	Rz. 146 (trazabilidad)
Firma GPG	Commits firmados - la autenticidad puede demostrarse	Rz. 146 (autoría)

Importante: historial lineal: Solo un historial lineal sin reescritura es conforme con GoBD. git rebase, git commit --amend y git push --force en main están prohibidos. El hook de pre-commit comprueba que no se realiza ningún force push y que las correcciones se realizan como nuevos commits con marca de obsolescencia.

Paquetes de evidencia para la conservación

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD FY["Geschäftsjahr
z. B. FY2026"] FY --> EP["Tenant Evidence Package
(Periodenabschluss)"] EP --> GB["git bundle
self-contained Archiv"] EP --> SW["Static-Web
(Z3+ Browser)"] EP --> MF["Manifest
+ SHA-256-Checksummen"] GB --> USB["USB-Stick
oder Off-Site-Backup"] SW --> USB MF --> USB USB --> PR["Prüfer
git clone oder index.html
offline, ohne 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 ED05 Z3+) para un ejercicio contiene:

Componente	Contenido	Relación con GoBD
git bundle	Repositorio completo (historial, commits, tags)	§ 147 Abs. 6 AO (soporte de datos Z3)
Static-Web	Sitio web navegable desde el navegador (HTML/PDF/JSON)	Z3+ (acceso del auditor sin IAM)
Manifest	Sumas de comprobación SHA-256 por archivo, índice V7GUID	Rz. 146 (integridad)
Documentación del procedimiento	Renderizada como HTML	Rz. 64–91 (documentación del procedimiento)
Documentos del DMS	Todos los justificantes (PDF, XML, EML)	§ 147 Abs. 1 (conservación)
Contratos	Documentos que abarcan varios ejercicios	§ 147 Abs. 1 Nr. 2/3 (correspondencia comercial)

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

Por supuesto, debe respetarse la seguridad física de la memoria USB (caja fuerte, protección contra incendios, copia de seguridad fuera de las instalaciones).

Gestión de plazos en el repositorio

`checks/FRISTEN_CHECK.md`

# Fristen-Check

## Vorlauf (bis 010926) - PRIO 1

- [ ] 200826: ELSTER-Organisationszertifikat anfordern
- [ ] 250826: Gefahrtarifstelle festlegen
- [ ] 300826: D&O-Versicherung GF-Haftung

## Aufbewahrungsfristen (laufend)

| Frist | Unterlagen-Typ | Endet | Status |
|---:|:---|---:|:---|
| 10 Jahre | Grundbuch FY2026 | 31.12.2036 | aktiv |
| 8 Jahre | E-Rechnungen FY2026 | 31.12.2034 | aktiv |
| 6 Jahre | E-Mails FY2026 | 31.12.2032 | aktiv |

Aviso automático ante plazos inminentes

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR FC["Fristen-Check
(Git-Artefakt)"] FC --> P14["über 14 Tage
grün"] FC --> P7["7–14 Tage
gelb"] FC --> P0["unter 7 Tage
orange/rot"] P0 --> W["Warnung
an Unternehmer"] style FC fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style P14 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style P7 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style P0 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style W fill:#FDBA74,stroke:#C2410C,color:#0F1B33

Tipo de plazo	Aviso	Acción
Vencimiento del plazo de conservación	30 días antes	Documentar la destrucción tras el vencimiento
Plazo administrativo (ELSTER, SV)	14 días antes	Preparar la remisión
Plazo de prescripción (§ 169 AO)	90 días antes	No destruir los documentos

Palancas de mitigación de riesgos

Hoy (barato)	Mañana (a prueba de revisiones)	Riesgo mitigado
`git bundle` como archivo autocontenido	Conservación de 10 años sin cuenta en la nube	Incumplimiento de GoBD por cancelación de la cuenta
Tags + Protected Branches	Inmutabilidad tras la aprobación	Incumplimiento de GoBD por modificaciones a posteriori
Paquete de evidencia (Z3+)	Acceso del auditor sin IAM, sin conexión	Incumplimiento de GoBD por datos inaccesibles
Comprobación de plazos como artefacto de Git	Se evita el incumplimiento de plazos	Recargos por retraso § 152 AO
Marca de obsolescencia	Correcciones trazables	Cambios ocultos
Commits firmados con GPG	Autenticidad demostrable	Negación de la autoría
Static-Web (Z3+)	Navegación en el navegador para el auditor	Incumplimiento de GoBD por datos poco operativos para el auditor

Requisito del harness (vista previa)

Derivables de ED08:

ID	Requisito	Prioridad
FA-4.1	Archivo de comprobación de plazos (`checks/FRISTEN_CHECK.md`)	MUST
FA-4.2	Entradas de plazos con fecha, tipo, tenant y referencia del justificante	MUST
FA-4.3	Aviso automático para plazos < 14 días	SHOULD
FA-6.5	Conservación de 10 años mediante paquetes de evidencia (Git bundles)	MUST
FA-6.6	Inmutabilidad tras la aprobación (tags, Protected Branches)	MUST
FA-6.7	Generador de Static-Web para el cierre de ejercicio (Z3+)	SHOULD
TA-2.4	Pre-Commit: comprobación del estado de obsolescencia	SHOULD

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

Fuentes

GoBD (comunicación del BMF, Rz. 146 - inmutabilidad, Rz. 152 - plazos de conservación)
AO (§ 146 Abs. 5 - disponibilidad, § 147 - plazos de conservación de 10/8/6 años, § 147 Abs. 4 - inicio del plazo, § 147 Abs. 6 - acceso a datos Z3)
GitCover.Ledger/docs/02-Tenant-Evidence-Package.md - concepto de Tenant Evidence Package
E1/agents/ (anonimizado) - concepto SSoT con comprobación de plazos y paquetes de evidencia

Topología de fuentes y enlaces de referencia del CDN

Función	Ubicación	Finalidad
Principal / SSoT	git.gitcover.org/GCC	Almacenamiento canónico (firmado con GPG, versionado)
Espejo OSS público / CDN	codeberg.org/gitcover-commons	Espejo de solo lectura; FLOSS-Discovery
Centro comunitario	github.com/gitcover-commons	Issues & Discussions; referencia al código fuente en Codeberg

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