ED07 - Documentación del procedimiento GoBD: campos obligatorios, versionado, aprobación

Problema

GoBD Rz. 64–91 exige una documentación del procedimiento - pero en el ámbito de las pymes es la gran excepción:

"¿Qué es una documentación del procedimiento?" - la mayoría de los empresarios no conocen el término, y mucho menos su contenido
"Eso lo hace el asesor fiscal" - muchos creen que el asesor fiscal elabora la documentación del procedimiento - pero este solo puede orientar; el empresario debe elaborarla y mantenerla él mismo
Documento de Word en el cajón del escritorio - si existe una documentación del procedimiento, es un documento de Word estático que no se actualiza al cambiar de sistema - infracción de GoBD
Sin versionado - los cambios en la documentación del procedimiento no se documentan de forma trazable - pero GoBD Rz. 83 exige actualidad y trazabilidad
Sin aprobación - la documentación del procedimiento nunca se "aprueba" - pero GoBD exige que el estado en el momento de la auditoría esté claro
Cambio de sistema no documentado - al migrar a un nuevo software, la documentación del procedimiento no se actualiza - GoBD Rz. 146–150 lo exige expresamente

Mensaje central

Una documentación del procedimiento conforme a GoBD en el repositorio Git significa:

La documentación del procedimiento es un artefacto Git versionado - no un documento de Word, sino Markdown + JSON en el repositorio
Cada cambio es trazable - git log muestra quién, cuándo, qué, por qué (autor del commit, marca de tiempo uuidV7, diff, mensaje del commit)
Aprobación mediante tags - un tag de Git marca el estado aprobado de la documentación del procedimiento (p. ej. vd-v1.0-2026)
Los cambios de sistema se documentan de forma continuada - al migrar se crea un nuevo commit con la justificación; la versión anterior permanece trazable
El propio repositorio es parte de la documentación del procedimiento - git log muestra el procedimiento, .gitcover/schemas/ muestra las estructuras de datos, los Git-Hooks muestran los controles

Compliance by Design: La documentación del procedimiento no se crea a posteriori - surge del uso de Git. Quien trabaja con repositorios Git documenta su procedimiento automáticamente mediante commits, diffs y tags. La documentación formal del procedimiento complementa esto con la descripción legible para humanos.

¿Qué es una documentación del procedimiento?

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD VD["Verfahrensdokumentation
(GoBD Rz. 64–91)"] VD --> V["Verfahren
(Wie wird gebucht?)"] VD --> S["Systemumgebung
(Welche Software/Hardware?)"] VD --> O["Organisation
(Wer macht was?)"] VD --> K["Kontrollen
(Wie wird geprüft?)"] VD --> D["Daten
(Welche Formate/Strukturen?)"] V --> G["Git-Repo
(Commits, Hooks)"] S --> G O --> G K --> G D --> G style VD fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style V fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style S fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style O fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style K fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style D fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style G fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33

Requisito de GoBD	Contenido	Cómo lo cumple Git
Procedimiento (Rz. 64–71)	Descripción del procedimiento contable	`git log` muestra cada paso; los mensajes de commit documentan la justificación
Entorno del sistema (Rz. 72–76)	Software, hardware, versiones	`.gitcover/` con esquemas y diccionarios; `git config` muestra la configuración
Organización (Rz. 77–80)	Responsabilidades, roles, permisos	campo `role` por artefacto; `git log --author` muestra la responsabilidad
Controles (Rz. 81–85)	Controles internos, comprobaciones de plausibilidad	Pre-Commit-Hooks (esquema, esferas, obsolescencia); Post-Commit-Hooks (índice)
Datos (Rz. 86–91)	Estructuras de datos, formatos, interfaces	Esquemas JSON en `.gitcover/schemas/`; sidecars con `v7g_taxonomy`

Campos obligatorios de la documentación del procedimiento

Estructura en el repositorio Git

ORG-1/
├── .gitcover/
│   ├── schemas/                    # Datenstrukturen (Rz. 86–91)
│   │   ├── diary-entry-1.0.schema.json
│   │   ├── v7g-sidecar-1.0.schema.json
│   │   └── timesheet-1.0.schema.json
│   ├── dictionaries/               # Klassifizierungen (Rz. 86–91)
│   │   ├── spheres.json
│   │   ├── roles.json
│   │   └── beleg-types.json
│   └── LEGAL_ENTITY.v7g.json       # Tenant-Identität
├── docs/
│   └── verfahrensdokumentation/
│       ├── README.md               # Einstieg + Übersicht
│       ├── 01-verfahren.md         # Buchführungsverfahren (Rz. 64–71)
│       ├── 02-systemumgebung.md    # Software/Hardware (Rz. 72–76)
│       ├── 03-organisation.md      # Zuständigkeiten (Rz. 77–80)
│       ├── 04-kontrollen.md        # Internen Kontrollen (Rz. 81–85)
│       └── 05-daten.md             # Datenstrukturen (Rz. 86–91)
└── .githooks/
    ├── pre-commit                  # Kontrollen (Rz. 81–85)
    └── post-commit                 # Index-Generierung

La documentación del procedimiento como artefacto JSON

La propia documentación del procedimiento es un artefacto versionado con V7GUID (Class) y uuidV7 (Object ID como DocID):

{
  "$schema": "https://gitcover.org/schemas/verfahrensdoku-1.0.schema.json",
  "V7GUID": "<V7GUID-Class-aus-Registry>",
  "uuidV7": "<uuidV7-Object-mit-vorgegebener-Zeitmarke>",
  "author": "E1",
  "role": "GF",
  "tenant": "ORG-1",
  "sphere": "wirtschaftlich",
  "source": "E1",
  "version": "1.0",
  "status": "released",
  "sections": ["01-verfahren", "02-systemumgebung", "03-organisation", "04-kontrollen", "05-daten"]
}

Nota: La uuidV7 es la DocID de la documentación del procedimiento. La clave compuesta V7GUID:uuidV7 sirve para la organización del almacenamiento y las consultas a la base de datos. Sin campo datetime/date separado - el tiempo está contenido en la uuidV7.

Versionado y aprobación

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD E["Entwurf
Commit 1"] E --> R["Review
Commit 2 (Änderungen)"] R --> F["Freigabe
Tag: vd-v1.0-2026"] F --> P["Produktiv
Stand v1.0"] P --> A["Änderung nötig
(z. B. Systemwechsel)"] A --> E2["Entwurf v2.0
Commit 3"] E2 --> R2["Review v2.0"] R2 --> F2["Freigabe
Tag: vd-v2.0-2027"] F2 --> P2["Produktiv
Stand v2.0"] F -.-> OBS["obsolescence:
v1.0 → superseded by v2.0"] style E fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style R fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style F fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style P fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style A fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style E2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style R2 fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style F2 fill:#10A987,stroke:#0A7F5C,color:#FBFAF7 style P2 fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style OBS fill:#E5E7EB,stroke:#6B7280,color:#0F1B33

Fase	Operación Git	Referencia GoBD
Borrador	Commit en `main` (o Feature-Branch)	Rz. 83 (actualidad)
Revisión	Commits adicionales con cambios	Rz. 83 (trazabilidad)
Aprobación	`git tag vd-v1.0-2026`	Rz. 83 (estado vinculante)
Productivo	El tag es inmutable (Protected)	Rz. 146 (inmutabilidad)
Cambio	Nuevos commits + nuevo tag	Rz. 146–150 (cambio de sistema)
Obsolescencia	Versión antigua `obsolescence: superseded_by`	Rz. 146 (trazabilidad)

Importante - tags como marcadores de aprobación: Un tag de Git es inmutable

marca un estado de commit exacto que no puede modificarse posteriormente. Esto corresponde a GoBD Rz. 146 (inmutabilidad). El auditor puede reconstruir con git show vd-v1.0-2026 el estado exacto de la documentación del procedimiento en el momento de la auditoría.

Cambio de sistema y migración (GoBD Rz. 146–150)

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR A["Altes System
(z. B. Cloud-Lohn)"] A --> M["Migration
Commit mit Begründung"] M --> N["Neues System
(z. B. Git-Cover)"] A --> DA["Daten alt
git bundle
(self-contained)"] N --> DN["Daten neu
Git-Repo
(fortgeführt)"] M --> VD["Verfahrensdoku
fortgeschrieben
+ Commit-Message
mit Begründung"] style A fill:#FDBA74,stroke:#C2410C,color:#0F1B33 style M fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style N fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style DA fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style DN fill:#D1FAE5,stroke:#0A7F5C,color:#0F1B33 style VD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7

GoBD Rz. 146–150 exige en caso de cambio de sistema:

Mantener disponibles los datos del sistema antiguo - git bundle como archivo self-contained (sin necesidad de cuenta en la nube, véase ED05 Z3)
Actualizar la documentación del procedimiento - nuevo commit con la justificación: "Migración de Cloud-Lohn a GitCover, fecha, rol"
Documentar el período de transición - qué datos se migraron y cómo, qué comprobaciones se realizaron
Marcar la versión antigua como obsoleta - obsolescence: superseded_by en el antiguo artefacto de documentación del procedimiento

Ejemplo práctico: El empresario (E1) migra de un software Cloud-Lohn a GitCover. Crea un git bundle de los datos antiguos, actualiza la documentación del procedimiento (nuevo commit con el mensaje de commit "Migración a GitCover, 260815, rol: GF"), marca la versión antigua como superseded y etiqueta la nueva versión como vd-v2.0-2027. El auditor puede seguir ambas versiones.

El propio repositorio como documentación del procedimiento

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TD R["Git-Repo"] R --> GL["git log
Verfahren (Rz. 64–71)"] R --> GC["git config
Systemumgebung (Rz. 72–76)"] R --> GA["git log --author
Organisation (Rz. 77–80)"] R --> GH["Git-Hooks
Kontrollen (Rz. 81–85)"] R --> SC["Schemata + Sidecars
Daten (Rz. 86–91)"] GL --> VD["Verfahrensdokumentation
entsteht automatisch"] GC --> VD GA --> VD GH --> VD SC --> VD style R fill:#0F1B33,stroke:#0F1B33,color:#FBFAF7 style GL fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GC fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GA fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style GH fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style SC fill:#DBEAFE,stroke:#1D4ED8,color:#0F1B33 style VD fill:#10A987,stroke:#0A7F5C,color:#FBFAF7

La idea central: Un repositorio Git es en sí mismo una documentación del procedimiento - git log muestra el procedimiento, git config muestra el entorno del sistema, los Git-Hooks muestran los controles, los esquemas muestran las estructuras de datos. La documentación formal del procedimiento (Markdown en docs/verfahrensdokumentation/) complementa esto con la descripción legible para humanos - pero la fuente autoritativa es el propio repositorio.

Apalancamiento de riesgo

Hoy (barato)	Mañana (a prueba de auditoría)	Riesgo mitigado
Documentación del procedimiento como artefacto Git	GoBD Rz. 64–91 cumplido by Design	Estimación § 162 AO (sin documentación del procedimiento)
`git log` como prueba del procedimiento	Trazabilidad en un plazo razonable	Impugnación de la documentación del procedimiento
Tags como marcadores de aprobación	Estado inmutable en el momento de la auditoría	Impugnación del estado
Cambio de sistema como commit + bundle	Conforme a GoBD Rz. 146–150	Infracción de GoBD por un cambio no documentado
Marcado de obsolescencia	Versiones antiguas trazables	Cambios encubiertos
El propio repositorio como documentación del procedimiento	Documentación automática mediante el uso	Documentación del procedimiento desactualizada

Requisito de Harness (vista previa)

Se puede deducir de ED07:

ID	Requisito	Prioridad
FA-6.1	Documentación del procedimiento como artefacto Git versionado	MUST
FA-6.3	Gestión del plan de cuentas SKR04 (incl. cuentas de nómina)	SHOULD
FA-6.6	Inmutabilidad tras la aprobación (tags, Protected Branches)	MUST
FA-6.7	Generador web estático para el cierre de período (Z3+)	SHOULD
TA-2.1	Pre-Commit: validación de JSON Schema	MUST
TA-2.4	Pre-Commit: comprobación del estado de obsolescencia	SHOULD
TA-2.6	Post-Commit: generación automática del índice	SHOULD

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

Fuentes

GoBD (escrito del BMF, Rz. 64–91 - documentación del procedimiento, Rz. 146–150 - cambio de sistema, Rz. 83 - actualidad)
AO (§ 146 - normas de orden, § 147 - conservación)
AFJD/agents/ (anonimizado) - concepto SSoT con la documentación del procedimiento como artefacto Git

Topología de fuentes y enlaces de referencia CDN

Rol	Lugar	Propósito
Primary / SSoT	git.gitcover.org/GCC	Almacenamiento 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, compruebe la fuente canónica correspondiente en gitcover.org para conocer el estado actual.