ED05 - Fundamentos de GoBD: Trazabilidad, Verificabilidad, Inmutabilidad
Problema
Un empresario comienza con la contabilidad - y se enfrenta a la pregunta: ¿Qué exige GoBD concretamente, y cómo lo cumplo sin software especializado caro?
La práctica actual en el ámbito de las PYME:
- GoBD como un libro con siete sellos - las GoBD (escrito del BMF, 146 páginas) son abstractas, redactadas en lenguaje jurídico, apenas accesibles para profanos
- "Eso lo hace el asesor fiscal" - muchos empresarios delegan GoBD al asesor fiscal sin entender ellos mismos qué se exige - y pagan por ello
- Soluciones aisladas - software de nóminas, contabilidad y archivo de comprobantes, cada uno por separado, sin conformidad con GoBD de extremo a extremo
- 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 archivado
- Sin 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
Idea central
GoBD exige tres principios centrales que Git cumple by Design:
- 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 pueden modificarse (correcciones como nuevas entradas)
Git cumple los tres estructuralmente - no mediante controles posteriores, sino por la propia arquitectura:
Rz. 146"] G --> P["Verificabilidad
Rz. 147"] G --> U["Inmutabilidad
Rz. 146"] N --> GN["Git: autor del commit
+ marca de tiempo
+ mensaje del commit"] P --> GP["Git: V7GUID + SHA-256
resolubles de forma
retrógrada/progresiva"] U --> GU["Git: Tags + Protected Branches
+ marcado de obsolescencia
correcciones como nuevos 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 comprobación posterior, sino de la elección del medio. Quien trabaja en repositorios Git cumple trazabilidad, verificabilidad e inmutabilidad estructuralmente - no mediante controles adicionales.
GoBD - Origen y validez
Las GoBD (Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff) son un escrito del BMF del 28.11.2019 (BStBl I S. 1269), modificado por última vez el 14.07.2025 (BStBl I S. 1502).
| Propiedad | Valor |
|---|---|
| Emisor | Ministerio Federal de Hacienda (BMF) |
| Naturaleza jurídica | Instrucción administrativa (no es una ley, pero es vinculante para las oficinas de hacienda) |
| Base | § 146 AO (normas de orden), § 147 AO (conservación), HGB (§§ 238–241) |
| Ámbito de aplicación | Para todos los empresarios que contabilizan electrónicamente (en la práctica: todos) |
| Extensión | 146 números de margen (Rz.) |
Importante: las GoBD no son una "recomendación" - son la instrucción administrativa según la cual las oficinas de hacienda realizan las comprobaciones. Quien no cumple las GoBD se arriesga a una estimación (§ 162 AO), recargos por extemporaneidad (§ 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 constituida de tal manera que un tercero experto pueda hacerse una idea general de las operaciones comerciales y de la situación de la empresa en un tiempo razonable."
Esto significa: un inspector (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 el autor de cada 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 (GF, contable, responsable de I+D) |
¿Quién? ¿Cuándo? ¿Qué?"] P --> SH["git show
Detalles del commit"] P --> DF["git diff
¿Qué ha cambiado?"] P --> V7["uuidV7 decode
Hora exacta de captura"] GL --> R["Trazabilidad
en un tiempo razonable"] 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 constituida de tal manera que sea verificable."
Esto significa: la contabilidad debe ser trazable de forma retrógrada y progresiva (véase ED03):
- Retrógrada: del asiento contable → comprobante → entrada del diario → V7GUID
- Progresiva: del comprobante → asiento contable → libro diario → balance de apertura
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| Trazabilidad retrógrada | source_sha256 en la entrada del diario → comprobante |
| Trazabilidad progresiva | V7GUID en el comprobante → entrada del diario → libro diario |
| Evaluabilidad automatizada (§ 147 Abs. 6 AO) | JSON-Schema-First - datos estructurados, no PDF |
| Completitud | El Pre-Commit-Hook comprueba que cada entrada del libro diario tenga source_sha256 |
3. Inmutabilidad (GoBD Rz. 146)
GoBD Rz. 146: "Las anotaciones no deben modificarse de tal manera que el contenido original ya no pueda determinarse."
Esto significa: tras el asiento, los datos no pueden modificarse. Las correcciones deben realizarse como nuevas entradas con su justificación.
| Requisito de GoBD | Cómo lo cumple Git |
|---|---|
| Sin 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 |
| Protected Branches | rama main protegida, sin Force-Pushes |
| Tags como marcadores de aprobación | Los tags marcan los estados aprobados (inmutables) |
Commit 1"] B --> TAG["Tag v1.0
aprobado"] K["Corrección necesaria"] K --> C["Asiento de corrección
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 es conforme a GoBD una historia lineal sin reescritura. El Pre-Commit-Hook comprueba que no se realicen Force-Pushes a
mainy que las correcciones se realicen como nuevos commits con marcado de obsolescencia.
GoBD y AO - la base jurídica
normas de orden
para la contabilidad"] AO --> S147["§ 147 AO
conservación
de documentos"] S146 --> GoBD["GoBD
(escrito del BMF)
concreción
para sistemas electrónicos"] S147 --> GoBD GoBD --> R146["Rz. 146
Trazabilidad
Inmutabilidad"] GoBD --> R147["Rz. 147
Verificabilidad"] GoBD --> R64["Rz. 64–91
documentación del procedimiento"] GoBD --> R152["Rz. 152
plazos de conservación"] 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 irreconocible el contenido original | Rz. 146 (inmutabilidad) |
| § 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 datos en la 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 fiscal puede utilizar en una inspección externa:
| Tipo de acceso | Descripción | Cómo lo admite Git |
|---|---|---|
| Z1 (acceso directo) | El inspector usa el sistema del empresario | git log, git show, git grep directamente en el repositorio |
| Z2 (acceso indirecto) | El inspector da las pautas, el empresario realiza la evaluación | git log --since, git grep, exportación JSON |
| Z3 (entrega de soporte de datos) | El empresario entrega los datos en un soporte | git bundle como archivo self-contained |
Z3 es la fortaleza de Git: un
git bundlecontiene todo el repositorio (historia, commits, tags) en un único archivo - self-contained, sin cuenta en la nube, sin licencia de software. El inspector puede reconstruir el repositorio en su sistema congit cloney realizar todas las operaciones Z1/Z2. Esa es la exportación Z3 conforme a GoBD "by Design".
Extensión de GitCover: Static-Web como acceso del inspector (Z3+)
Más allá 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 Static-Web navegable desde el navegador a partir del Tenant Evidence Package.
Este sitio contiene:
- Todos los documentos del DMS (comprobantes, facturas, contratos) como HTML/PDF
- Contratos que abarcan varios períodos y documentos de larga duración
- Evaluaciones (libro diario, Journal, BWA, balance)
- Normas del procedimiento (documentación del procedimiento, plan de cuentas)
- Sidecars (
.v7g.mdcon V7GUID, SHA-256, taxonomía) - Pruebas de integridad (manifiesto con checksums)
(cierre de período)"] EP --> GB["git bundle
(base Z3)"] EP --> SW["Generador Static-Web
(GitCover Tool)"] GB --> CL["git clone
(el inspector reconstruye el repositorio)"] SW --> FS["Filesystem-Based-Web
(HTML + PDF + JSON)"] FS --> BR["Navegador
(el inspector navega)"] FS --> IDX["Páginas de índice
(por fecha, tipo de comprobante, V7GUID)"] FS --> NAV["Navegación
(retrógrada/progresiva)"] FS --> SRH["Búsqueda
(texto completo, 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 Filesystem-Based-Web no necesita sistema de IAM, ni infraestructura de servidores, ni base de datos, ni conexión de red. El inspector abre la
index.htmlen su navegador - sin conexión, localmente, sin autenticación. La integridad se garantiza mediante el manifiesto con checksums SHA-256, no mediante derechos de acceso. Esta es la forma más segura de acceso del inspector, porque no existe superficie de ataque.
| Propiedad | git bundle (Z3) | Static-Web (Z3+) |
|---|---|---|
| El inspector necesita | Git instalado | Solo un navegador |
| Navegación | CLI (git log, git show) |
Navegador (clic, búsqueda) |
| Evaluaciones | Manualmente vía git grep |
Páginas de índice pregeneradas |
| Documentos del DMS | En el repositorio (PDF, XML) | Incorporados como HTML/PDF |
| Documentación del procedimiento | Markdown en el repositorio | Renderizada 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 (Filesystem only) |
Ejemplo práctico: el empresario (
E1) elabora el cierre de período para FY2026. La herramienta GitCover genera un Tenant Evidence Package congit bundle(para inspectores con conocimientos técnicos) y un sitio Static-Web (para inspectores que solo quieren usar un navegador). Ambos se entregan en una memoria USB - self-contained, sin conexión, sin IAM. El inspector elige por sí mismo si ejecutagit cloneo abreindex.html.
Apalancamiento de riesgo
| Hoy (barato) | Mañana (a prueba de revisiones) | Riesgo mitigado |
|---|---|---|
| Repositorio Git como medio de contabilidad | GoBD Rz. 146/147 cumplidas by Design | Estimación § 162 AO |
git log como prueba |
Trazabilidad en un tiempo razonable | Cuestionamiento de la regularidad |
| V7GUID + SHA-256 por entrada | Trazabilidad retrógrada/progresiva | Degradación del valor probatorio |
| Tags + Protected Branches | 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 |
| Static-Web como Z3+ (cierre de período) | Acceso del inspector sin IAM, solo navegador | **Infracción de GoBD por datos inaccesibles/poco amigables para el inspector ** |
Requisito del Harness (vista previa)
Deducible de ED05:
| ID | Requisito | Prioridad |
|---|---|---|
| FA-6.1 | Documentación del procedimiento como artefacto Git versionado | MUST |
| FA-6.2 | Libro diario (Journal) como JSON con V7GUID + SHA-256 por entrada | MUST |
| FA-6.5 | Conservación de 10 años mediante Evidence-Packages (Git-Bundles) | MUST |
| FA-6.6 | Inmutabilidad tras la aprobación (Tags, Protected Branches) | MUST |
| FA-6.7 | Generador Static-Web para el cierre de período (Z3+): sitio web navegable en el navegador a partir del Tenant Evidence Package, sin IAM, Filesystem-Based | SHOULD |
| TA-2.1 | Pre-Commit: validación JSON-Schema | MUST |
| TA-2.4 | Pre-Commit: comprobación del estado de obsolescencia (ningún commit en obsolete) |
SHOULD |
La lista completa de requisitos en Harness-Anforderungen.md.
Fuentes
- GoBD (escrito del BMF del 28.11.2019, BStBl I S. 1269, última modificación el 14.07.2025, BStBl I S. 1502)
- AO (§ 146 - normas de orden, § 147 - conservación, § 162 - estimación, § 152 - recargo por extemporaneidad)
- HGB (§§ 238–241 - obligación de llevar contabilidad)
AFJD/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 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 | Almacén canónico (firmado con GPG, versionado) |
| Public OSS Mirror / CDN | codeberg.org/gitcover-commons | Réplica de solo lectura; descubrimiento FLOSS |
| Community Hub | github.com/gitcover-commons | Issues & Discussions; referencia del código fuente en Codeberg |
Nota: Esta asignación de fuentes, mirror y Community Hub refleja el estado actual y puede cambiar. Por favor, consulte la fuente canónica correspondiente en gitcover.org para conocer el estado actual.