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 wäre. Mir geht es um eine technische Gap-Analyse und um einen möglichen zusätzlichen Compliance-Layer für Auditierbarkeit, Unveränderbarkeit, Exportierbarkeit und Dokumentation.
Die Punkte, die ich aktuell prüfe:
- Append-only Audit-Logs für kritische Objekte
- Rechnungen
- Rechnungspositionen
- Zahlungen
- Banktransaktionen
- Buchungssätze
- Kunden und Lieferanten
- Dokumente und Dateien
- Steuerkonfiguration
Pro Audit-Eintrag wären mindestens sinnvoll:
- Tabellenname
- Datensatz-ID
- Aktionstyp
- Benutzer-ID
- UTC-Zeitstempel
- alter Wert
- neuer Wert
- Quellsystem
- Request-ID
- Begründung oder Kommentar
Normale Anwendungslogik dürfte solche Audit-Einträge nicht verändern oder löschen.
- Keine harten Löschungen bei geschäftskritischen Daten
Stattdessen wären Soft-Delete- oder Storno-Zustände nötig, z. B.:
- deleted_at
- deleted_by
- deletion_reason
- original_status
- audit_reference
Geschäftskritische Daten sollten nicht still gelöscht werden.
- Unveränderbare finale Dokumente
Wenn ein Dokument final ist, sollte es archiviert und gegen Überschreiben geschützt 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 unverändert archivieren
Relevant wären z. B.:
- OCR-Uploads
- Eingangsrechnungen
- Bank-CSV-Dateien
- MT940-Dateien
- CAMT-XML-Dateien
- DATEV-Importe
- rechtlich relevante API-Payloads
Dazu gehören Metadaten wie Originaldateiname, interner Dateiname, SHA256-Hash, Upload-Zeitpunkt, Quelle und Verarbeitungsstatus.
- Bankimporte auditierbar machen
Für jede importierte Banktransaktion wären 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 Vorschläge 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-unterstützte 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, Passwörter oder Zugangsdaten dürfen dabei nicht im Klartext geloggt werden.
- Rollen härter trennen
Mindestens sinnvoll wären getrennte Rollen für:
- technischer Admin
- Buchhaltungsbenutzer
- Auditor oder Read-only-Benutzer
- API-Client
- KI-Assistent
API- und KI-Benutzer sollten nur die minimal nötigen Rechte erhalten.
- Deterministische Exporte vorbereiten
Exportierbar und reproduzierbar sollten sein:
- Buchungssätze
- 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-Speicherunggodb
- Backup-Strategie
- Restore-Testverfahren
- Aufbewahrungsannahmen
- wie Audit-Logs nach Restore erhalten bleiben
- Verfahrensdokumentation
Geplant wäre ein Entwurf mit:
- Systemübersicht
- verwendete Dolibarr-Module
- Datenflüsse
- Rechnungsprozess
- Bankimportprozess
- OCR- und Importprozess
- KI-unterstützte Workflows
- Benutzerrollen
- Audit-Trail
- Archivstrategie
- Exportprozess
- Backup- und Restore-Prozess
Meine Fragen an die Runde:
- Welche Dolibarr-Tabellen, Hooks oder Module wären aus eurer Sicht die richtigen Ansatzpunkte für so einen technischen GoBD-Layer?
- Gibt es bestehende Dolibarr-Module oder etablierte Setups für revisionssichere Dokumentablage, Audit-Logs oder DATEV/Export-Dokumentation?
- Wie wird in produktiven Dolibarr-Installationen typischerweise verhindert, dass finale Rechnungen oder relevante Dokumente überschrieben oder gelöscht werden?
- Gibt es Empfehlungen, ob solche Audit- und Archivfunktionen besser innerhalb von Dolibarr, über Hooks, über ein externes Archivsystem oder über 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 über Hinweise, Erfahrungen und Korrekturen. Mir geht es zuerst um eine saubere Gap-Analyse, bevor irgendeine Implementierung gebaut wird.
Diskussion:
- Discord: Dolibarr
- Dolibarr-Forum: GoBD-Kompatibilität von Dolibarr: technische Gap-Analyse und möglicher Compliance-Layer
- Latest Referenz: GoBD-Kompatibilität von Dolibarr
