ED05 - Fundamentos de GoBD: trazabilidad, verificabilidad e inalterabilidad
Problema
Un empresario empieza a llevar la contabilidad y se plantea la pregunta: ¿Qué exige GoBD concretamente y cómo puedo cumplirlo sin software especializado?
La práctica actual en el ámbito de las pymes:
- GoBD como un libro de siete sellos: la GoBD (escrito del BMF, 146 páginas) es abstracta, está formulada en lenguaje jurídico y resulta casi inaccesible para los no especialistas
- "Eso lo hace el asesor fiscal": muchos empresarios delegan el cumplimiento de GoBD en su asesor fiscal (StB), sin llegar a entender por sí mismos qué se exige, y pagan por ello
- Soluciones aisladas: software de nóminas, contabilidad y archivo de justificantes por separado, sin conformidad integral con GoBD
- PDF como "electrónico": muchos creen que un PDF en un disco duro cumple GoBD, pero GoBD exige que los datos puedan evaluarse de forma automatizada (§ 147 Abs. 6 AO), no solo que estén almacenados
- Sin documentación de procedimientos: GoBD Rz. 64–91 exige una documentación de procedimientos, pero ¿quién la tiene en una pyme?
- Modificaciones posteriores: los asientos se "corrigen" sin que la modificación sea trazable; GoBD Rz. 146 exige inalterabilidad
Mensaje principal
GoBD exige tres principios fundamentales que Git cumple desde el diseño:
- Trazabilidad (GoBD Rz. 146): cada asiento debe ser trazable (¿Quién? ¿Cuándo? ¿Qué? ¿Por qué?)
- Verificabilidad (GoBD Rz. 147): la contabilidad debe ser verificable (seguimiento retrospectivo/progresivo)
- Inalterabilidad (GoBD Rz. 146): después de realizar el asiento, los datos no deben modificarse (correcciones como nuevos asientos)
Git cumple los tres de forma estructural: 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
Cumplimiento por diseño: La conformidad con GoBD no surge de una comprobación posterior, sino de la elección del medio. Quien trabaja en repositorios Git cumple la trazabilidad, la verificabilidad y la inalterabilidad de forma estructural, no mediante controles adicionales.
GoBD - Origen y ámbito de aplicación
La GoBD (Principios para la gestión y conservación adecuadas de libros, registros y documentos en forma electrónica, así como para el acceso a los datos) es un escrito del BMF de 28.11.2019 (BStBl I S. 1269), modificado por última vez el 14.07.2025 (BStBl I S. 1502).
| Propiedad | Valor |
|---|---|
| Editor | Ministerio Federal de Hacienda (BMF) |
| Naturaleza jurídica | Instrucción administrativa (no es una ley, pero es vinculante para las oficinas tributarias) |
| Base | § 146 AO (normas de organización), § 147 AO (conservación), HGB (§§ 238–241) |
| Ámbito de aplicación | Para todos los empresarios que contabilizan electrónicamente (en la práctica, todos) |
| Alcance | 146 números marginales (Rz.) |
Importante: GoBD no es una "recomendación": es la instrucción administrativa conforme a la cual examinan las oficinas tributarias. Quien no cumpla GoBD corre el riesgo de una estimación (§ 162 AO), de recargos por demora (§ 152 AO) y, en el peor de los casos, de un procedimiento penal tributario (§ 370 AO).
Los tres principios fundamentales de GoBD en detalle
1. Trazabilidad (GoBD Rz. 146)
GoBD Rz. 146: "La contabilidad debe estar organizada de tal forma que un tercero con los conocimientos especializados pertinentes pueda obtener, en un plazo razonable, una visión general de las operaciones y de la situación de la empresa."
Esto significa: Un auditor (o un asesor fiscal o un inspector de Hacienda) debe poder determinar en un plazo razonable qué ha ocurrido.
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| ¿Quién realizó el asiento? | git log --author muestra cada autor del commit |
| ¿Cuándo se realizó el asiento? | 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ó o modificó |
| ¿Por qué se contabilizó? | El mensaje del commit documenta la justificación |
| ¿Con qué rol? | Campo role en el artefacto JSON (GF, 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 organizada de tal forma que sea verificable."
Esto significa: La contabilidad debe poder rastrearse hacia atrás y hacia delante (véase ED03):
- Hacia atrás: desde el asiento contable → justificante → asiento del libro diario → V7GUID
- Hacia delante: desde el justificante → asiento contable → libro mayor → balance inicial
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| Seguimiento hacia atrás | source_sha256 en el asiento del libro diario → justificante |
| Seguimiento hacia delante | V7GUID en el justificante → asiento del libro diario → libro mayor |
| Evaluación automatizada (§ 147 Abs. 6 AO) | Primero el esquema JSON: datos estructurados, no PDF |
| Completitud | El Pre-Commit-Hook comprueba que cada asiento del libro mayor tenga source_sha256 |
3. Inalterabilidad (GoBD Rz. 146)
GoBD Rz. 146: "Los asientos no deben modificarse de tal forma que el contenido original deje de ser determinable."
Esto significa: Después de realizar el asiento, los datos no deben modificarse. Las correcciones deben realizarse como nuevos asientos con justificación.
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| Ninguna modificación posterior | Los commits de Git son inalterables (hash SHA-256) |
| Correcciones como nuevos asientos | Nuevos commits con obsolescence: superseded_by |
| Corrección trazable | git log muestra el original + la corrección + la justificación |
| Ramas protegidas | La rama main está protegida, no se permiten force-pushes |
| Tags como marcadores de aprobación | Los tags marcan los estados aprobados (inalterables) |
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 solo un historial lineal sin reescritura es conforme a GoBD. El Pre-Commit-Hook comprueba que no se efectúen force-pushes enmainy que las correcciones se realicen como nuevos commits con marca 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, oportunos y ordenados" | Rz. 146 (trazabilidad) |
| § 146 Abs. 4 AO | Ninguna modificación que haga que el contenido original ya no pueda determinarse | Rz. 146 (inalterabilidad) |
| § 146 Abs. 5 AO | "disponibles en todo momento y legibles de inmediato" | Rz. 152 (disponibilidad) |
| § 147 Abs. 2 AO | "que 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 los datos en una auditoría externa (Z1/Z2/Z3) | Rz. 147 (acceso a datos) |
Acceso a datos de GoBD (Z1, Z2, Z3)
GoBD define tres modalidades de acceso que la administración tributaria puede utilizar en una auditoría externa:
| Modalidad de acceso | Descripción | Cómo lo respalda 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 formula las indicaciones y el empresario realiza la evaluación | git log --since, git grep, exportación JSON |
| Z3 (entrega del soporte de datos) | El empresario entrega los datos en un soporte | git bundle como archivo autocontenido |
Z3 es la fortaleza de Git: Un
git bundlecontiene todo el repositorio (historial, commits, tags) en un único archivo: autocontenido, sin cuenta en la nube y sin licencia de software. El auditor puede reconstruir el repositorio en su sistema congit cloney realizar todas las operaciones Z1/Z2. Esta es una exportación Z3 conforme a GoBD "por diseño".
Extensión de GitCover: web estática como acceso para el auditor (Z3+)
Además de git bundle, las herramientas GitCover (si están instaladas
y se utilizan) pueden generar, en el marco de un cierre de período, un
sitio web estático navegable desde el 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 períodos y documentos de larga vigencia
- Evaluaciones (libro mayor, libro diario, análisis económico-financiero, balance)
- Reglas de procedimiento (documentación de procedimientos, plan de cuentas)
- Sidecars (
.v7g.mdcon V7GUID, SHA-256, taxonomía) - Pruebas de integridad (manifiesto con sumas de comprobació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: Un sitio web basado en el sistema de archivos no necesita ningún sistema IAM, ninguna infraestructura de servidores, ninguna base de datos ni conexión de red. El auditor abre el archivo
index.htmlen su navegador: sin conexión, de forma local y sin autenticación. La integridad está garantizada por el manifiesto con sumas de comprobación SHA-256, no por los derechos de acceso. Esta es la forma más segura de acceso para el auditor, porque no existe superficie de ataque.
| Propiedad | 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 | Manualmente mediante git grep |
Páginas de índice pregeneradas |
| Documentos del DMS | En el repositorio (PDF, XML) | Incrustados como HTML/PDF |
| Documentación de procedimientos | Markdown en el repositorio | Renderizado como HTML |
| Integridad | SHA-256 de Git | Manifiesto + SHA-256 por archivo |
| IAM necesario | No | No |
| Red necesaria | No | No |
| Superficie de ataque | Mínima | Mínima (solo el sistema de archivos) |
Ejemplo práctico: El empresario (
E1) crea el cierre de período 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 quieran utilizar un navegador). Ambos se entregan en una memoria USB: autocontenidos, sin conexión y sin IAM. El auditor decide por sí mismo si utilizagit cloneo abreindex.html.
Palancas de reducción de riesgos
| Hoy (barato) | Mañana (resistente a la manipulación) | Riesgo mitigado |
|---|---|---|
| Repositorio Git como soporte de contabilización | Cumplimiento de GoBD Rz. 146/147 por diseño | Estimación § 162 AO |
git log como evidencia |
Trazabilidad en un plazo razonable | Impugnación de la regularidad |
| V7GUID + SHA-256 por entrada | Seguimiento retrospectivo/progresivo | Reducción del valor probatorio |
| Tags + ramas protegidas | Inalterabilidad tras la aprobación | Incumplimiento de GoBD por modificaciones posteriores |
git bundle como exportación Z3 |
Entrega de soportes de datos sin cuenta en la nube | Incumplimiento de GoBD por sistemas heredados no disponibles |
| Marca de obsolescencia | Correcciones trazables | Cambios ocultos |
| Sitio web estático como Z3+ (cierre de período) | Acceso del auditor sin IAM, solo con un navegador | **Incumplimiento de GoBD por datos inaccesibles o no adaptados al auditor ** |
Requisito del harness (vista previa)
Derivado de ED05:
| ID | Requisito | Prioridad |
|---|---|---|
| FA-6.1 | Documentación de procedimientos como artefacto Git versionado | MUST |
| FA-6.2 | Libro mayor (libro diario) en JSON con V7GUID + SHA-256 por entrada | MUST |
| FA-6.5 | Conservación durante 10 años mediante Evidence Packages (Git Bundles) | MUST |
| FA-6.6 | Inalterabilidad tras la aprobación (tags, ramas protegidas) | MUST |
| FA-6.7 | Generador de web estática para el cierre de período (Z3+): sitio web navegable desde el navegador a partir del Tenant Evidence Package, sin IAM, basado en el sistema de archivos | SHOULD |
| TA-2.1 | Pre-Commit: validación del 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 se encuentra 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 organización, § 147 - conservación, § 162 - estimación, § 152 - recargo por demora)
- HGB (§§ 238–241 - obligación de llevar la 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 período, roles del repositorio, reglas de completitud)GitCover.Toolbox- conjunto de herramientas GitCover (análisis, V7GUID, componentes de UI)
Topología de fuentes y enlaces de referencia de CDN
| Rol | Ubicación | Finalidad |
|---|---|---|
| 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 & 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. Compruebe la fuente canónica correspondiente en gitcover.org para conocer el estado actual.