ED05 - Fundamentos de GoBD: trazabilidad, verificabilidad, inmutabilidad
Problema
Un empresario empieza a llevar la contabilidad y se enfrenta a la pregunta: ¿qué exige concretamente GoBD y cómo lo cumplo sin un software especializado caro?
La práctica actual en el ámbito de las pymes:
- GoBD como un libro con siete sellos: las GoBD (escrito del BMF, 146 páginas) son abstractas, están formuladas en lenguaje jurídico y apenas son accesibles para legos
- «Eso lo hace el asesor fiscal»: muchos empresarios delegan GoBD en el asesor fiscal sin entender ellos mismos qué se exige, y lo pagan
- Soluciones aisladas: software de nóminas, contabilidad y archivo de justificantes cada uno por separado, sin conformidad GoBD integral
- PDF como «electrónico»: muchos creen que un PDF en un disco duro cumple GoBD, pero GoBD exige evaluabilidad automatizada (§ 147 Abs. 6 AO), no solo almacenamiento
- Ninguna documentación del procedimiento: GoBD Rz. 64–91 exige una documentación del procedimiento, pero ¿quién en una pyme tiene una?
- Modificaciones posteriores: los asientos se «corrigen» sin que la modificación sea trazable; GoBD Rz. 146 exige inmutabilidad
Afirmación central
GoBD exige tres principios centrales que Git cumple por diseño:
- Trazabilidad (GoBD Rz. 146): cada entrada debe ser trazable (¿quién? ¿cuándo? ¿qué? ¿por qué?)
- Verificabilidad (GoBD Rz. 147): la contabilidad debe ser verificable (trazabilidad retrógrada/progresiva)
- Inmutabilidad (GoBD Rz. 146): tras el asiento, los datos no deben modificarse (correcciones como nuevas entradas)
Git cumple los tres estructuralmente, no mediante controles posteriores, sino mediante la propia arquitectura:
Rz. 146"] G --> P["Nachprüfbarkeit
Rz. 147"] G --> U["Unveränderbarkeit
Rz. 146"] N --> GN["Git: Commit-Autor
+ Zeitstempel
+ Commit-Message"] P --> GP["Git: V7GUID + SHA-256
retrograd/progressiv
auflösbar"] U --> GU["Git: Tags + Protected Branches
+ Obsoleszenz-Markierung
Korrekturen als neue Commits"] style G fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style N fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style P fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style U fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GN fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GP fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style GU fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
Compliance by Design: la conformidad con GoBD no surge de una revisión posterior, sino de la elección del medio. Quien trabaja en repositorios Git cumple la trazabilidad, la verificabilidad y la inmutabilidad estructuralmente, no mediante controles adicionales.
GoBD: origen y vigencia
Las GoBD (principios para el mantenimiento y conservación ordenados de libros, registros y documentos en formato electrónico, así como para el acceso a datos) son un escrito del BMF de 28.11.2019 (BStBl I S. 1269), modificado por última vez el 14.07.2025 (BStBl I S. 1502).
| Característica | Valor |
|---|---|
| Editor | Bundesministerium der Finanzen (BMF) |
| Carácter jurídico | Instrucción administrativa (no es una ley, pero vincula a las oficinas tributarias) |
| Base | § 146 AO (normas de orden), § 147 AO (conservación), HGB (§§ 238–241) |
| Aplicación | Para todos los empresarios que contabilizan electrónicamente (en la práctica: todos) |
| Alcance | 146 números marginales (Rz.) |
Importante: las GoBD no son una «recomendación»: son la instrucción administrativa conforme a la cual comprueban las oficinas tributarias. Quien no cumple las GoBD se arriesga a una estimación (§ 162 AO), a recargos por demora (§ 152 AO) y, en el peor de los casos, a un procedimiento penal tributario (§ 370 AO).
Los tres principios centrales de GoBD en detalle
1. Trazabilidad (GoBD Rz. 146)
GoBD Rz. 146: «La contabilidad debe estar configurada de tal manera que un tercero experto pueda, en un tiempo razonable, obtener una visión general de las operaciones comerciales y de la situación de la empresa.»
Esto significa que un auditor (o asesor fiscal, o funcionario de Hacienda) debe poder reconstruir en un tiempo razonable qué ha ocurrido.
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| ¿Quién contabilizó? | git log --author muestra cada autor de commit |
| ¿Cuándo se contabilizó? | uuidV7 contiene una marca de tiempo de 48 bits (RFC 9562 §5.7) |
| ¿Qué se contabilizó? | El diff del commit muestra exactamente qué se añadió/modificó |
| ¿Por qué se contabilizó? | El mensaje del commit documenta la justificación |
| ¿En qué rol? | Campo role en el artefacto JSON (dirección, contable, responsable de I+D) |
Wer? Wann? Was?"] P --> SH["git show
Commit-Details"] P --> DF["git diff
Was hat sich geändert?"] P --> V7["uuidV7 decode
Exakte Erfassungszeit"] GL --> R["Nachvollziehbarkeit
in angemessener Zeit"] SH --> R DF --> R V7 --> R style P fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SH fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style DF fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style V7 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
2. Verificabilidad (GoBD Rz. 147)
GoBD Rz. 147: «La contabilidad debe estar configurada de tal manera que sea verificable.»
Esto significa que la contabilidad debe poder rastrearse de forma retrógrada y progresiva (véase ED03):
- Retrógrada: del asiento contable → justificante → asiento del diario → V7GUID
- Progresiva: del justificante → asiento contable → libro de registro → balance de apertura
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| Trazabilidad retrógrada | source_sha256 en el asiento del diario → justificante |
| Trazabilidad progresiva | V7GUID en el justificante → asiento del diario → libro de registro |
| Evaluabilidad automatizada (§ 147 Abs. 6 AO) | JSON-Schema-First: datos estructurados, no PDF |
| Integridad | El hook de pre-commit comprueba que cada entrada del libro de registro tenga source_sha256 |
3. Inmutabilidad (GoBD Rz. 146)
GoBD Rz. 146: «Las entradas no deben modificarse de tal manera que el contenido original deje de ser determinable.»
Esto significa que, tras el asiento, los datos no deben modificarse. Las correcciones deben realizarse como nuevas entradas con justificación.
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| Ninguna modificación posterior | Los commits de Git son inmutables (hash SHA-256) |
| Correcciones como nuevas entradas | Nuevos commits con obsolescence: superseded_by |
| Corrección trazable | git log muestra original + corrección + justificación |
| Ramas protegidas | Rama main protegida, sin push forzados |
| Etiquetas como marcadores de aprobación | Las etiquetas marcan estados aprobados (inmutables) |
Commit 1"] B --> TAG["Tag v1.0
freigegeben"] K["Korrektur nötig"] K --> C["Korrektur-Buchung
Commit 2"] C --> OBS["obsolescence:
status: superseded
superseded_by: Commit 2"] B --> OBS style B fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style TAG fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style K fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style C fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style OBS fill:#E5E7EB,stroke:#6B7280,color:#0F1B33
Importante: Git permite técnicamente
git rebaseygit commit --amend, pero conforme a GoBD solo es válido un historial lineal sin reescritura. El hook de pre-commit comprueba que no se realicen push forzados sobremainy que las correcciones se realicen como nuevos commits con marcado de obsolescencia.
GoBD y AO: la base jurídica
Ordnungsvorschriften
für Buchführung"] AO --> S147["§ 147 AO
Aufbewahrung
von Unterlagen"] S146 --> GoBD["GoBD
(BMF-Schreiben)
Konkretisierung
für elektronische Systeme"] S147 --> GoBD GoBD --> R146["Rz. 146
Nachvollziehbarkeit
Unveränderbarkeit"] GoBD --> R147["Rz. 147
Nachprüfbarkeit"] GoBD --> R64["Rz. 64–91
Verfahrensdokumentation"] GoBD --> R152["Rz. 152
Aufbewahrungsfristen"] style AO fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style S146 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S147 fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GoBD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style R146 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R147 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R64 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style R152 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
| Fuente jurídica | Contenido | Relación con GoBD |
|---|---|---|
| § 146 Abs. 1 AO | Asientos «individuales, completos, correctos, puntuales y ordenados» | Rz. 146 (trazabilidad) |
| § 146 Abs. 4 AO | Ninguna modificación que haga irreconocible el contenido original | Rz. 146 (inmutabilidad) |
| § 146 Abs. 5 AO | «disponible en todo momento y legible sin demora» | Rz. 152 (disponibilidad) |
| § 147 Abs. 2 AO | «puedan evaluarse de forma automatizada» | Rz. 147 (verificabilidad) |
| § 147 Abs. 3 AO | Plazos de conservación (10/8/6 años) | Rz. 152 (conservación) |
| § 147 Abs. 6 AO | Acceso a datos en inspección externa (Z1/Z2/Z3) | Rz. 147 (acceso a datos) |
Acceso a datos según GoBD (Z1, Z2, Z3)
Las GoBD definen tres tipos de acceso que la Administración Tributaria puede utilizar en una inspección fiscal externa:
| Tipo de acceso | Descripción | Cómo lo admite Git |
|---|---|---|
| Z1 (acceso directo) | El auditor utiliza el sistema del empresario | git log, git show, git grep directamente en el repositorio |
| Z2 (acceso indirecto) | El auditor da especificaciones, el empresario evalúa | git log --since, git grep, exportación JSON |
| Z3 (entrega de soportes de datos) | El empresario entrega datos en un soporte de datos | git bundle como archivo autocontenido |
Z3 es la fortaleza de Git: un
git bundlecontiene todo el repositorio (historial, commits, etiquetas) en un único archivo: autocontenido, sin cuenta en la nube, sin licencia de software. El auditor puede reconstruir el repositorio en su sistema congit cloney realizar todas las operaciones Z1/Z2. Esto es una exportación Z3 conforme a GoBD «por diseño».
Ampliación de GitCover: web estática como acceso para el auditor (Z3+)
Más allá de git bundle, las herramientas de GitCover (si están instaladas
y se utilizan) pueden generar, en el marco de un cierre de periodo, un
sitio web estático navegable mediante navegador a partir del Tenant Evidence Package.
Este sitio web contiene:
- Todos los documentos del DMS (justificantes, facturas, contratos) como HTML/PDF
- Contratos que abarcan varios periodos y documentos de larga duración
- Evaluaciones (libro de registro, Journal, BWA, balance)
- Normas de procedimiento (documentación del procedimiento, plan de cuentas)
- Sidecars (
.gc.mdcon V7GUID, SHA-256, taxonomía) - Pruebas de integridad (manifiesto con sumas de verificación)
(Periodenabschluss)"] EP --> GB["git bundle
(Z3-Basis)"] EP --> SW["Static-Web-Generator
(GitCover Tool)"] GB --> CL["git clone
(Prüfer rekonstruiert Repo)"] SW --> FS["Filesystem-Based-Web
(HTML + PDF + JSON)"] FS --> BR["Browser
(Prüfer navigiert)"] FS --> IDX["Index-Seiten
(nach Datum, Belegart, V7GUID)"] FS --> NAV["Navigation
(retrograd/progressiv)"] FS --> SRH["Suche
(Volltext, SHA-256, V7GUID)"] style EP fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GB fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SW fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style CL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style FS fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style BR fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style IDX fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style NAV fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style SRH fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33
El método más seguro de todos: una web basada en sistema de archivos no necesita ningún sistema IAM, ni infraestructura de servidores, ni base de datos, ni conexión de red. El auditor abre
index.htmlen su navegador: offline, local, sin autenticación. La integridad se garantiza mediante el manifiesto con sumas de verificación SHA-256, no mediante derechos de acceso. Esta es la forma más segura de acceso para el auditor, porque no hay superficie de ataque.
| Característica | git bundle (Z3) | Web estática (Z3+) |
|---|---|---|
| El auditor necesita | Git instalado | Solo un navegador |
| Navegación | CLI (git log, git show) |
Navegador (clic, búsqueda) |
| Evaluaciones | Manual mediante git grep |
Páginas de índice pregeneradas |
| Documentos del DMS | En el repositorio (PDF, XML) | Integrados como HTML/PDF |
| Documentación del procedimiento | Markdown en el repositorio | Renderizada como HTML |
| Integridad | Git-SHA-256 | Manifiesto + SHA-256 por archivo |
| IAM necesario | No | No |
| Red necesaria | No | No |
| Superficie de ataque | Mínima | Mínima (solo sistema de archivos) |
Ejemplo práctico: el empresario (
E1) crea el cierre de periodo para FY2026. La herramienta GitCover genera un Tenant Evidence Package congit bundle(para auditores con conocimientos técnicos) y un sitio web estático (para auditores que solo quieren usar un navegador). Ambos se entregan en una memoria USB: autocontenidos, offline, sin IAM. El auditor decide por sí mismo si abregit cloneoindex.html.
Apalancamiento de riesgo
| Hoy (barato) | Mañana (seguro para auditoría) | Riesgo mitigado |
|---|---|---|
| Repositorio Git como medio de contabilidad | GoBD Rz. 146/147 cumplidas por diseño | Estimación § 162 AO |
git log como prueba |
Trazabilidad en un tiempo razonable | Impugnación de la regularidad |
| V7GUID + SHA-256 por entrada | Trazabilidad retrógrada/progresiva | Degradación del valor probatorio |
| Etiquetas + ramas protegidas | Inmutabilidad tras la aprobación | Infracción de GoBD por modificación posterior |
git bundle como exportación Z3 |
Entrega de soporte de datos sin cuenta en la nube | Infracción de GoBD por sistemas antiguos no disponibles |
| Marcado de obsolescencia | Correcciones trazables | Modificaciones encubiertas |
| Web estática como Z3+ (cierre de periodo) | Acceso para el auditor sin IAM, solo navegador | **Infracción de GoBD por datos inaccesibles o poco amigables para el auditor ** |
Requisito del harness (avance)
Derivable de ED05:
| ID | Requisito | Prioridad |
|---|---|---|
| FA-6.1 | Documentación del procedimiento como artefacto Git versionado | MUST |
| FA-6.2 | Libro de registro (Journal) como JSON con V7GUID + SHA-256 por asiento | MUST |
| FA-6.5 | Conservación durante 10 años mediante Evidence-Packages (Git-Bundles) | MUST |
| FA-6.6 | Inmutabilidad tras la aprobación (etiquetas, ramas protegidas) | MUST |
| FA-6.7 | Generador de web estática para el cierre de periodo (Z3+): sitio web navegable mediante navegador a partir del Tenant Evidence Package, sin IAM, basado en sistema de archivos | SHOULD |
| TA-2.1 | Pre-commit: validación de esquema JSON | MUST |
| TA-2.4 | Pre-commit: comprobación del estado de obsolescencia (ningún commit sobre obsolete) |
SHOULD |
La lista completa de requisitos en Harness-Anforderungen.md.
Fuentes
- 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 - normas de orden, § 147 - conservación, § 162 - estimación, § 152 - recargo por demora)
- HGB (§§ 238–241 - obligación de llevar contabilidad)
E1/agents/(anonimizado) - concepto SSoT con uso de Git conforme a GoBDGitCover.Ledger/docs/02-Tenant-Evidence-Package.md- concepto de Tenant Evidence Package (cierre de periodo, roles del repositorio, reglas de completitud)GitCover.Toolbox- conjunto de herramientas de GitCover (análisis, V7GUID, componentes de UI)
Topología de fuentes y enlaces de referencia CDN
| Rol | Ubicación | Propósito |
|---|---|---|
| Primary / SSoT | git.gitcover.org/GCC | Almacenamiento 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, espejo y Community Hub refleja el estado actual y puede cambiar. Consulte la fuente canónica correspondiente en gitcover.org para conocer el estado actual.