Titelvorschlag:
GoBD-Kompatibilitaet von Dolibarr: technische Gap-Analyse und moeglicher Compliance-Layer
Stand: 2026-05-22T17:50:12Z UTC
Hallo zusammen,
ich schaue mir gerade an, wie man eine bestehende Dolibarr-Installation technisch besser in Richtung deutscher GoBD-Anforderungen absichern kann.
Wichtig: Es geht nicht um eine rechtliche Zertifizierung und auch nicht um die Aussage, dass Dolibarr dadurch automatisch GoBD-konform waere. Mir geht es um eine technische Gap-Analyse und um einen moeglichen zusaetzlichen Compliance-Layer fuer Auditierbarkeit, Unveraenderbarkeit, Exportierbarkeit und Dokumentation.
Die Punkte, die ich aktuell pruefe:
Append-only Audit-Logs fuer kritische Objekte
- Rechnungen
- Rechnungspositionen
- Zahlungen
- Banktransaktionen
- Buchungssaetze
- Kunden und Lieferanten
- Dokumente und Dateien
- Steuerkonfiguration
Pro Audit-Eintrag waeren mindestens sinnvoll:
- Tabellenname
- Datensatz-ID
- Aktionstyp
- Benutzer-ID
- UTC-Zeitstempel
- alter Wert
- neuer Wert
- Quellsystem
- Request-ID
- Begruendung oder Kommentar
Normale Anwendungslogik duerfte solche Audit-Eintraege nicht veraendern oder loeschen.
Keine harten Loeschungen bei geschaeftskritischen Daten
Stattdessen waeren Soft-Delete- oder Storno-Zustaende noetig, z. B.:
- deleted_at
- deleted_by
- deletion_reason
- original_status
- audit_reference
Geschaeftskritische Daten sollten nicht still geloescht werden.
Unveraenderbare finale Dokumente
Wenn ein Dokument final ist, sollte es archiviert und gegen Ueberschreiben geschuetzt werden:
- PDF speichern
- SHA256-Hash berechnen
- Hash-Metadaten speichern
- Version speichern
- UTC-Zeitstempel speichern
- Bezug zum Quellobjekt speichern
Beispiel:
documents/factures/2026/RE-2026-001_v1.pdf
documents/factures/2026/RE-2026-001_v1.sha256
Rohdaten unveraendert archivieren
Relevant waeren z. B.:
- OCR-Uploads
- Eingangsrechnungen
- Bank-CSV-Dateien
- MT940-Dateien
- CAMT-XML-Dateien
- DATEV-Importe
- rechtlich relevante API-Payloads
Dazu gehoeren Metadaten wie Originaldateiname, interner Dateiname, SHA256-Hash, Upload-Zeitpunkt, Quelle und Verarbeitungsstatus.
Bankimporte auditierbar machen
Fuer jede importierte Banktransaktion waeren sinnvoll:
- Referenz auf die Original-Importdatei
- Quell-Bankkonto
- Importzeitpunkt in UTC
- Transaktionshash
- Matching-Ziel
- Matching-Methode
- Matching-Konfidenz
- freigebender Benutzer
- Freigabezeitpunkt in UTC
Automatisierung oder KI sollte nur Vorschlaege erzeugen, aber keine finalen Buchungen oder Zuordnungen ohne menschliche Freigabe.
KI nur als Vorschlagssystem
KI sollte keine Rechnungen, Buchungen, Zahlungen, Steuerdaten oder Bank-Matches finalisieren.
Jede KI-unterstuetzte Aktion sollte enthalten:
- menschliche Freigabe
- Audit-Eintrag
- gespeicherter KI-Vorschlag
- gespeicherte finale Benutzerentscheidung
API-Schreiboperationen loggen
Bei API-Writes waeren relevant:
- Endpoint
- Methode
- authentifizierter Benutzer oder Client
- Request-ID
- Payload-Hash
- betroffenes Objekt
- Response-Status
- UTC-Zeitstempel
Secrets, Tokens, Passwoerter oder Zugangsdaten duerfen dabei nicht im Klartext geloggt werden.
Rollen haerter trennen
Mindestens sinnvoll waeren getrennte Rollen fuer:
- technischer Admin
- Buchhaltungsbenutzer
- Auditor oder Read-only-Benutzer
- API-Client
- KI-Assistent
API- und KI-Benutzer sollten nur die minimal noetigen Rechte erhalten.
Deterministische Exporte vorbereiten
Exportierbar und reproduzierbar sollten sein:
- Buchungssaetze
- Rechnungen
- Zahlungen
- Banktransaktionen
- Dokument-Metadaten
- Audit-Logs
- Hash-Manifeste
- Rohimport-Metadaten
Formate: CSV, JSON und wo sinnvoll XML.
Zeitbehandlung
Intern sollte alles mit UTC und ISO-8601-Zeitstempeln laufen, z. B.:
2026-05-22T18:44:00Z
Backup und Restore dokumentieren
Die Verfahrensdokumentation sollte mindestens beschreiben:
- Datenbank-Speicherung
- Datei-Speicherung
- Backup-Strategie
- Restore-Testverfahren
- Aufbewahrungsannahmen
- wie Audit-Logs nach Restore erhalten bleiben
Verfahrensdokumentation
Geplant waere ein Entwurf mit:
- Systemuebersicht
- verwendete Dolibarr-Module
- Datenfluesse
- Rechnungsprozess
- Bankimportprozess
- OCR- und Importprozess
- KI-unterstuetzte Workflows
- Benutzerrollen
- Audit-Trail
- Archivstrategie
- Exportprozess
- Backup- und Restore-Prozess
Meine Fragen an die Runde:
Welche Dolibarr-Tabellen, Hooks oder Module waeren aus eurer Sicht die richtigen Ansatzpunkte fuer so einen technischen GoBD-Layer?
Gibt es bestehende Dolibarr-Module oder etablierte Setups fuer revisionssichere Dokumentablage, Audit-Logs oder DATEV/Export-Dokumentation?
Wie wird in produktiven Dolibarr-Installationen typischerweise verhindert, dass finale Rechnungen oder relevante Dokumente ueberschrieben oder geloescht werden?
Gibt es Empfehlungen, ob solche Audit- und Archivfunktionen besser innerhalb von Dolibarr, ueber Hooks, ueber ein externes Archivsystem oder ueber eine Kombination umgesetzt werden sollten?
Hat jemand bereits eine Verfahrensdokumentation fuer Dolibarr im deutschen Kontext erstellt und kann sagen, welche technischen Nachweise besonders wichtig waren?
Ich freue mich ueber Hinweise, Erfahrungen und Korrekturen. Mir geht es zuerst um eine saubere Gap-Analyse, bevor irgendeine Implementierung gebaut wird.
Diskussion:
- Discord: https://discord.gg/p5vw8a8Bb
- Dolibarr-Forum: https://forum.dolibarr.de/forum/t/godb-kompalitaet-von-dolibar/10212