Im Dolibarr-Forum tauchte vergangene Woche eine Frage auf, die ziemlich genau den Nerv trifft: „Gap-Analyse und möglicher Compliance-Layer“. Der Fragesteller wollte wissen, an welchen Stellen Vanilla-Dolibarr für eine deutsche Betriebsprüfung schon trägt und wo nachgearbeitet werden muss. Das ist die Frage, die in jedem zweiten Audit-Gespräch fällt — meistens drei Wochen vor der Prüfungsanordnung, manchmal auch erst, wenn der Prüfer schon im Haus sitzt.
Diese Seite ordnet die Antwort sachlich ein. Was die GoBD im Kern verlangt, wo Dolibarr aus dem Karton heraus solide aufgestellt ist, an welchen Punkten typischerweise Lücken auftauchen — und welche fünf bis sieben Sachen ein Mittelständler ohne Berater selbst nachsehen kann. Eine Vorab-Klarstellung gleich vorneweg: Die GoBD sind kein Strafverfolgungsinstrument. Sie sind der Standard, an dem eine Betriebsprüfung die Buchführung misst. Wer sauber dokumentiert ist und die Grundsätze technisch umsetzt, geht ohne Zuschätzung nach § 162 AO aus dem Gespräch — wer schludert, riskiert eine Schätzungsbefugnis, die schnell ins Geld geht.
Was die GoBD im Kern verlangen
Die Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff — kurz GoBD — gehen auf das BMF-Schreiben vom 14. November 2014 zurück, in der heute gültigen Fassung neu gefasst am 28. November 2019. Sie binden jeden Buchführungspflichtigen nach §§ 140 ff. AO. Praktisch heißt das: jedes deutsche Unternehmen, das Geschäftsvorfälle elektronisch erfasst (siehe auch unseren ERP-Vergleich für den Mittelstand), fällt darunter — vom Zwei-Personen-Handwerksbetrieb bis zum Konzern.
Im Kern geht es um sechs materielle Grundsätze, die jeder Datensatz erfüllen muss. Nachvollziehbarkeit und Nachprüfbarkeit bedeutet, dass ein sachverständiger Dritter den Weg vom Beleg zur Buchung und zurück rekonstruieren kann. Vollständigkeit verlangt, dass kein Geschäftsvorfall fehlt — auch nicht der kleine Barbeleg vom Baumarkt. Richtigkeit zielt auf inhaltliche und rechnerische Korrektheit. Zeitgerechte Buchungen verlangen, dass Vorgänge zeitnah erfasst werden — die alte „spätestens nach acht Tagen“-Regel für Kasse, „innerhalb des Monats“ für unbare Vorgänge ist sinngemäß noch da. Ordnung meint nachvollziehbare Belegnummern und ein klares Kontensystem. Und Unveränderbarkeit — Tz. 58, die in der Praxis am meisten Konflikt erzeugt — verlangt, dass eine einmal in den Verarbeitungsprozess gegebene Buchung nicht so verändert werden kann, dass der ursprüngliche Inhalt verloren geht.
Quer dazu liegen zwei organisatorische Themen, die in jeder Prüfung gesondert abgefragt werden: die Verfahrensdokumentation nach Tz. 151 und der Datenzugriff nach § 147 Abs. 6 AO in den drei Spielarten Z1 (Prüfer arbeitet direkt im System mit Lesezugriff), Z2 (Sie werten auf Anforderung aus) und Z3 (Datenträgerüberlassung im maschinell auswertbaren Format, typischerweise GDPdU/IDEA). Welche der drei Zugriffsarten der Prüfer wählt, entscheidet er — nicht Sie. Heißt: Sie müssen alle drei bedienen können.
Wo Vanilla-Dolibarr schon trägt
Dolibarr ist im Auslieferungszustand kein deutsches Buchhaltungssystem, aber die Architektur ist deutlich besser, als viele vermuten. Das interne Änderungsprotokoll arbeitet sauber: Jede Rechnung, Buchung, Bestandsbewegung und Stammdaten-Änderung wird mit Zeitstempel und Benutzer protokolliert. Den Audit-Trail finden Sie auf jeder Detailseite unter „Info“ oder „Bearbeitungs-Historie“ — Anlage, Statuswechsel, Validierung, Zahlungs-Verknüpfung, alles sichtbar.
Die Validierungs-Sperre für Rechnungen ist ebenfalls da, sie ist nur per Default nicht aktiv. Unter Einstellungen → Module/Anwendungen → Faktura → Rechnungen konfigurieren liegt der Schalter MAIN_DISABLE_INVOICE_EDITION. Einmal aktiviert, lassen sich validierte Rechnungen nicht mehr im Betrag oder in den Positionen ändern — Korrekturen laufen ausschließlich über Stornorechnung und Neuanlage, die untereinander bidirektional verknüpft sind und in dieser Verknüpfung nicht aufgelöst werden können. Das entspricht genau dem, was Tz. 58 und Tz. 61 verlangen.
Auch die Belegablage ist konzeptionell richtig gebaut. Eingehende PDFs, gescannte Papier-Belege und XRechnungen werden im Datensatz unter „Dokumente“ verknüpft und liegen physisch im Verzeichnis documents/ — sauber getrennt nach Beleg-Typ (facture, facture_fournisseur, produit). Die Tabellen-Struktur in der MariaDB ist standardisiert und damit Z3-tauglich, das Modul Ereignisse / Agenda protokolliert Logins, Passwortänderungen und Rollenwechsel. Das Berechtigungs-System mit Benutzergruppen erlaubt eine saubere Vier-Rollen-Trennung (Erfassung, Freigabe, Auswertung, Administration), wie sie Tz. 44 und Tz. 52 für die Trennung kritischer Vorgänge im Hintergrund mitdenken.
Kurz: Vanilla-Dolibarr ist GoBD-fähig. Nicht GoBD-fertig.
Wo die Lücken sitzen
Der Unterschied zwischen „fähig“ und „fertig“ entscheidet in der Praxis darüber, ob eine Betriebsprüfung glatt durchläuft oder Diskussionen produziert. Vier Lücken tauchen immer wieder auf.
Die Verfahrensdokumentation fehlt komplett. Das ist der häufigste formale Mangel — bei jeder zweiten Prüfung, die wir begleitet haben, war keine vorhanden oder die letzte Fassung war drei Jahre alt. Tz. 151 verlangt eine schriftliche Darstellung, in der ein sachverständiger Dritter sich in angemessener Zeit zurechtfindet: Beleg-Eingangswege, Verarbeitungsschritte mit Verantwortlichen, Archivierung, Berechtigungssystem, Backup-Strategie, Software-Versionen. Dolibarr bringt davon nichts mit — die Doku ist eine organisatorische Pflicht, die der Betreiber erfüllen muss.
Der Z3-Export ist nicht out-of-the-box. Unter Buchhaltung → Exporte → GDPdU-Export liegt zwar ein Modul, das eine ZIP-Datei mit Bewegungsdaten, Stammdaten und der formalen index.xml erzeugt. In der Standardkonfiguration treffen die Feld-Mappings aber selten exakt das, was die Prüfer-Software IDEA erwartet — vor allem bei den Kontenrahmen SKR03/SKR04 und der DATEV-typischen Kostenstellen-Logik. Das fällt erst auf, wenn der Prüfer die Datei nicht lesen kann. Bei einem unserer Audits aus diesem Frühjahr stellte sich heraus, dass der Z3-Export seit der letzten Migration eine fehlerhafte DTD-Referenz trug — drei Jahre lang, nie getestet, in der Prüfung dann der Aufschlag.
Ein Berechtigungs-Audit-Werkzeug fehlt. Wer prüfen will, welche Benutzer welche Rollen haben, wann zuletzt eingeloggt wurde und ob verwaiste Admin-Accounts existieren, muss in Dolibarr durch mehrere Module klicken und die Daten manuell zusammenführen. Ein konsolidierter Bericht für den halbjährlichen Berechtigungs-Review — den Tz. 100 sinngemäß verlangt — existiert nicht. Im Audit-Alltag sieht man dann fünf Jahre alte Accounts mit Admin-Rechten von Mitarbeitern, die längst nicht mehr im Haus sind.
Standard-Checklisten für Betriebsprüfung gibt es nicht. Die typischen Mängel — Excel-Listen ohne Bewegungsprotokoll, Belege auf lokalen Arbeitsplatz-PCs statt im zentralen Archiv, Mail-Anhänge ohne dokumentierten Eingangsworkflow, Lücken im Audit-Trail nach Update — werden in jeder Prüfung wieder neu gefunden, weil keine systematische Vorab-Selbstprüfung läuft. Das ist keine Dolibarr-Schwäche, sondern eine organisatorische — Dolibarr liefert nur kein Werkzeug, das vor der Prüfung daran erinnert.
Was wir auf Dolibarr-Basis ergänzen
Diese Lücken lassen sich schließen, ohne den Dolibarr-Kern anzufassen — und genau das ist die Linie, die wir bei jedem Setup fahren. Wir liefern eine angepasste Verfahrensdokumentation als Word-Vorlage mit, in der die Standardkapitel vorbefüllt sind und nur noch die unternehmensspezifischen Stellen (Beleg-Eingangswege, Verantwortliche, Backup-Ziele) ergänzt werden müssen. Die Validierungs-Sperre für Rechnungen ist im Auslieferungsprofil standardmäßig aktiv — sie auszuschalten ist im Wartungs-Vertrag ausdrücklich ausgenommen. Der Z3-Export wird einmalig gegen IDEA getestet, das Ergebnis kommt mit Datum in die Verfahrensdokumentation. Das Berechtigungs-System wird als Vier-Rollen-Schema (Erfassung, Freigabe, Auswertung, Administration) eingerichtet, der halbjährliche Review-Termin landet als wiederkehrender Eintrag im Kunden-Kalender.
Wer mehr Werkzeug-Unterstützung will, kann das DigiBasiX-Auslieferungsprofil für Dolibarr nutzen — das bündelt diese Voreinstellungen plus einige zusätzliche Helfer (Hashsummen-Lauf für die Belegablage, vorkonfiguriertes Backup mit Restore-Test-Protokoll). Der entscheidende Punkt ist aber nicht das Modul, sondern die Disziplin: GoBD-Konformität ist nach Tz. 20 eine Eigenschaft des Verfahrens — also der Kombination aus Software, Organisation und tatsächlichem Anwenderverhalten. Eine im Auslieferungszustand saubere Software wird durch abgeschaltete Sperren, schlampige Rollen und veraltete Doku innerhalb von Monaten wieder ungenügend.
Was Sie heute selbst prüfen können
Eine kurze Selbstcheck-Liste für den Mittwochnachmittag, ohne Berater:
- Verfahrensdokumentation greifbar? Liegt sie in einem Ordner, den die Geschäftsführung findet — nicht nur der IT-Dienstleister? Trägt sie ein Versionsdatum aus den letzten zwölf Monaten?
- Validierungs-Sperre aktiv? Unter Einstellungen → Faktura nachsehen, ob
MAIN_DISABLE_INVOICE_EDITIONauf1steht. Wenn nicht: warum nicht, und wer hat es ausgeschaltet? - Z3-Export funktioniert? Einmal probeweise einen Monatsbestand exportieren und in IDEA (oder beim Steuerberater) gegenlesen lassen. Wenn das nicht klappt, will man das nicht erst in der Prüfung herausfinden.
- Audit-Trail-Lücken nach Migrationen? Bei einer Rechnung aus dem Vorjahr nachsehen, ob der Bearbeitungs-Verlauf vollständig ist oder ob das Migrationsdatum eine harte Kante zeigt.
- Backup zuletzt getestet? Wann wurde zum letzten Mal ein Restore in eine Testumgebung gefahren und protokolliert? Tz. 103 ist hier eindeutig — ein nicht getestetes Backup gilt prüfungsrechtlich nicht als Backup.
- Berechtigungs-Liste aktuell? Alle aktiven Benutzer durchgehen: arbeitet die Person noch im Haus, passt die Rolle, wann war der letzte Login? Verwaiste Accounts deaktivieren — nicht löschen, damit der Audit-Trail referenzfähig bleibt.
- Belegablage vollständig? Stichprobe aus dem letzten Quartal: Wo liegt der Original-PDF zu einer Lieferantenrechnung? Im Dolibarr-
documents/-Verzeichnis oder im Outlook eines Mitarbeiters? Tz. 121 GoBD verpflichtet zur Aufbewahrung eingehender E-Mails als steuerrelevante Unterlagen — der Mail-Body gehört dazu, nicht nur der Anhang. Tz. 130 verlangt zusätzlich, dass die Aufbewahrung in der Form des Eingangs erfolgt.
Wenn drei oder mehr dieser Punkte Fragezeichen werfen, ist eine systematische Gap-Analyse vor der nächsten Betriebsprüfung gut investiert. Wenn alle sieben grün sind, ist die Hausaufgabe gemacht — dann braucht es höchstens noch das jährliche Update der Verfahrensdokumentation.
Wann sich eine Gap-Analyse lohnt
Drei Anlässe, bei denen wir den genauen Blick empfehlen. Vor einem System-Wechsel — die Aufbewahrungspflicht knüpft an die Daten, nicht an das System (Tz. 164). Wer migriert, muss entweder das Altsystem im Lese-Modus weiterbetreiben oder die Migration mit Übergabeprotokoll, Stichprobenvergleich und Versionsschnitt in der Verfahrensdokumentation absichern. Reine PDF-Archivierung der alten Auswertungen reicht nicht, weil die maschinelle Auswertbarkeit für Z3 verloren geht. Vor einer angekündigten Betriebsprüfung — die typischen Mängel (fehlende Doku, Z3-Export ungetestet, verwaiste Accounts) lassen sich in vier bis sechs Wochen Vorlauf in Ordnung bringen. Während der Prüfung wird das ungleich schwieriger. Nach einem Major-Update — Modul-Updates können Audit-Trail-Lücken erzeugen oder Default-Einstellungen verändern (gerade die Validierungs-Sperre ist immer wieder ein Kandidat). Tz. 155 lässt zu, solche Brüche als Versionsschnitt in der Verfahrensdokumentation zu vermerken — aber nur, wenn man sie überhaupt bemerkt hat.
Eine Klarstellung zum Schluss, die wir öfter aussprechen müssen: GoBD-Konformität ist keine Kategorie, die Software „hat“ oder „nicht hat“. Sie ist eine Eigenschaft des laufenden Betriebs — Software-Konfiguration, organisatorische Regeln, Anwender-Disziplin. Werbung mit „GoBD-Zertifizierung“ bezieht sich nach Tz. 21 stets auf den Auslieferungszustand des Produkts. Die Verantwortung für die Einhaltung im konkreten Setup bleibt nach § 34 AO bei der Geschäftsführung. Das ist keine Drohung, das ist nur die Geschäftsgrundlage, auf der jede Betriebsprüfung beruht.
Wenn Sie konkret prüfen wollen, ob Ihr Dolibarr GoBD-fit ist, vereinbaren Sie ein Audit-Gespräch. Wir gehen Ihre Konfiguration durch, fahren die sieben Selbstcheck-Punkte einmal sauber durch, und sagen ehrlich, wo Lücken sind und wo nicht. Keine Standard-Checkliste mit roten Häkchen, sondern eine Einschätzung für genau Ihren Stand.
