Deine selbstgebaute Datenbank ist vielleicht GoBD-Problem Nr. 1

Von /

Der Anruf vom Steuerberater klingt harmlos: Betriebsprüfung, geplant für nächsten Monat, bitte Daten aus den letzten drei Jahren exportieren, möglichst maschinell lesbar.

Dann geht der GF in die Buchhaltung, fragt den Kollegen nach dem Export — und der sagt: „Welchen Export? Wir haben da diese Access-Datei…“

Genau das ist der Moment, in dem die GoBD-Konformität zur ganz praktischen Frage wird.

Was die GoBD überhaupt verlangt

Die GoBD — Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form — ist kein Bürokratiemonster. Sie ist im Kern eine Antwort auf eine einfache Frage: Kann ein Prüfer nachvollziehen, was wann von wem gebucht oder verändert wurde?

Konkret fordert sie fünf Dinge von jeder steuerlich relevanten Software:

Unveränderbarkeit. Einmal gebuchte Daten dürfen nicht spurlos gelöscht oder überschrieben werden. Jede Änderung muss nachvollziehbar bleiben.

Vollständigkeit. Alle steuerlich relevanten Vorgänge müssen erfasst sein — keine Lücken, keine Sammelposten ohne Einzelnachweis.

Maschinelle Auswertbarkeit. Der Prüfer hat ein Recht auf Daten in einem Format, das er mit eigener Software öffnen kann. Kein proprietäres Binaryformat, kein „den Export muss der Entwickler erst bauen“.

Aufbewahrungspflicht. Je nach Belegart sechs oder zehn Jahre. Die Daten müssen in dieser Zeit lesbar bleiben — auch wenn das Programm wechselt.

Zeitgerechtigkeit. Buchungen müssen zeitnah erfolgen. Nachträgliche Massenerfassungen zum Jahresende sind ein Prüfungs-Risiko.

Wo Access strukturell hakt

Microsoft Access ist kein Buchhaltungsprogramm. Es ist ein Werkzeug für Menschen, die Daten erfassen, auswerten und verwalten wollen — ohne IT-Abteilung, ohne Lizenzkosten, ohne Projektnummer. Das ist seine Stärke. Und sein GoBD-Problem.

Kein Löschschutz von Haus aus. In einer Standard-Access-Datenbank kann jeder Benutzer mit Schreibrechten einen Datensatz löschen. Einfach Entf, fertig. Kein Log, keine Warnung, kein Soft-Delete. Was weg ist, ist weg. Das widerspricht der Unveränderbarkeit direkt.

Kein Änderungslog. Access protokolliert nicht, wer wann welchen Feldwert geändert hat. Dafür müsste man in jeder Tabelle, in jedem relevanten Formular, in jedem VBA-Event-Handler selbst Hand anlegen. Das wird fast nie gemacht.

Format-Risiko. Das native Dateiformat von Access — die .accdb — ist proprietär. Microsoft hält es aktuell, aber ein Prüfer mit eigenem Werkzeug kommt damit nicht weiter. Maschinelle Auswertbarkeit im GoBD-Sinne bedeutet CSV, XML oder eine ODBC-Verbindung. Das muss eigens gebaut oder konfiguriert werden.

Mandantenmischung. In kleinen Betrieben läuft oft alles in einer Access-Datei: Rechnungsdaten, Angebote, Lieferscheine, manchmal auch Adressen und Notizen. Wer die Datei öffnet, sieht alles. Eine rollenbasierte Sicht auf steuerlich relevante Daten gibt es nicht.

Netzwerkbetrieb ist instabil. Access im Mehrbenutzer-Betrieb über einen Netzwerkpfad ist technisch möglich — aber fehleranfällig. Verbindungsabbrüche, hängende Sperrdateien, beschädigte Indizes. Für eine GoBD-Prüfung muss die Datenbank vollständig und lesbar sein. Eine korrupte .accdb ist weder das eine noch das andere.

Verfahrensdokumentation: kurz, aber nicht wegzulassen

Die GoBD verlangt, dass jedes eingesetzte EDV-System dokumentiert ist: was es tut, wie es eingesetzt wird, wer zuständig ist. Diese Verfahrensdokumentation fehlt nach meiner Erfahrung in fast jedem KMU, das mit selbstgebauten Datenbanken arbeitet.

Das ist kein technisches Problem — es ist ein organisatorisches. Eine knappe, ehrliche Beschreibung des Systems, der Prozesse und der Zugriffsrechte reicht für den Anfang. Wer sie nicht hat, bekommt beim Prüfer sofort den zweiten Fragebogen.

Mehr dazu verdient einen eigenen Beitrag. Hier geht es um die technische Seite.

Was sich mit Access allein reparieren lässt — und was nicht

Einiges ist in Access direkt adressierbar:

Ein Soft-Delete-Mechanismus lässt sich per VBA nachrüsten. Statt DELETE ein Feld blnGeloescht = True setzen, alle Abfragen filtern, einen Log-Eintrag schreiben. Das kostet Aufwand, ist aber machbar.

Ein Änderungslog per VBA über Form_BeforeUpdate ist ebenfalls möglich: Feldname, alter Wert, neuer Wert, Benutzer, Zeitstempel in eine Audit-Tabelle. Bei zehn Tabellen und dreißig relevanten Feldern wird das zur Fleißarbeit — aber es geht.

CSV-Export kann automatisiert werden, per VBA und Aufgabenplanung. Für die maschinelle Auswertbarkeit reicht das.

Was Access allein nicht löst: skalierbare Mehrbenutzerstabilität, echte rollenbasierte Sicherheit auf Datenbankebene, zuverlässige Replikation und eine Backup-Strategie, die den Prüfer überzeugt.

Warum Access-Frontend mit SQL Server Backend die sauberere Antwort ist

Das ist kein Argument gegen Access. Es ist ein Argument für die richtige Aufgabenteilung.

Access bleibt, was es gut kann: Erfassungsmaske, Auswertungstool, schnell anzupassen, nah am Nutzer. SQL Server übernimmt, was Access strukturell nicht kann.

Unveränderbarkeit per Trigger. Ein INSTEAD OF DELETE-Trigger auf der relevanten Tabelle verhindert physisches Löschen. Der Datensatz bekommt ein DeletedAt-Feld, ein DeletedBy-Feld — und der Trigger schreibt beides, bevor er den echten Delete abfängt. Das ist nicht umgehbar, solange der Benutzer keinen direkten Schema-Zugriff hat.

CREATE TRIGGER trg_Rechnungen_SoftDelete
ON dbo.Rechnungen
INSTEAD OF DELETE
AS
BEGIN
    UPDATE dbo.Rechnungen
    SET    DeletedAt = GETDATE(),
           DeletedBy = SYSTEM_USER
    WHERE  RechnungID IN (SELECT RechnungID FROM deleted);
END;

Kein VBA, kein Formular-Event, keine Umgehungsmöglichkeit über Direktabfragen.

Änderungslog per Trigger. Dasselbe Prinzip für UPDATE: Ein AFTER UPDATE-Trigger schreibt alte und neue Werte in eine Audit-Tabelle — vollautomatisch, unabhängig davon, ob die Änderung aus Access, Excel, einem Import-Skript oder einem anderen Tool kommt.

Rollenbasierte Sicherheit. SQL Server kennt Datenbankrollen, Schemas, spaltenbasierte Berechtigungen. Der Buchhalter sieht die Rechnungsdaten. Der Lagermitarbeiter sieht die Bestandsdaten. Niemand sieht beides, wenn es nicht sein muss.

ODBC für den Prüfer. Wer einem Betriebsprüfer mit IDEA oder ACL eine ODBC-Verbindung auf den SQL Server gibt, ist im GoBD-Kontext auf der sicheren Seite. Keine Konvertierung, keine Exportdiskussion.

Backup mit Nachweis. SQL Server-Backups lassen sich automatisieren, versionieren, auf Vollständigkeit prüfen und dokumentieren — mit Datumsstempel, Prüfsumme und Aufbewahrungspfad. Das ist etwas anderes als ein manuelles Kopieren der .accdb auf einen Netzwerklaufwerk.

Was das in der Praxis bedeutet

Ein bestehender Access-Bestand lässt sich schrittweise migrieren. Tabellen, die steuerlich relevante Daten halten — Rechnungen, Zahlungseingänge, Buchungspositionen — wandern als erstes nach SQL Server. Access bleibt als Frontend: Formulare, Berichte, VBA-Logik. Die Benutzer merken wenig bis gar nichts.

Tabellen, die keine steuerliche Relevanz haben — Adressstammdaten, Projektnotizen, interne Listen — können vorerst in Access bleiben. Das reduziert den Umstellungsaufwand und macht das Projekt planbar.

Die Verknüpfung läuft über ODBC: Access-Tabellen werden als Linked Tables gegen SQL Server verbunden. Das ist seit Access 2007 stabil und gut dokumentiert.

Aus meiner Praxis im norddeutschen Mittelstand zeigt sich: Der Aufwand für die initiale Migration liegt bei einem typischen Access-Bestand mit fünf bis fünfzehn Kerntabellen und einem bis drei Benutzern selten über zwei bis drei Tage. Was danach entsteht, ist GoBD-tauglich — und gleichzeitig stabiler, schneller und wartbarer als der Ausgangszustand.

Das Risiko bleibt, solange nichts passiert

Eine Access-Datenbank ohne Änderungslog, ohne Löschschutz, ohne nachvollziehbare Exportstrategie ist kein Risiko. Sie ist bereits ein Schaden — der nur noch nicht aufgefallen ist.

Betriebsprüfungen kommen mit Vorlauf. Der richtige Zeitpunkt, die Struktur zu bereinigen, ist nicht der Tag vor dem ersten Termin.

Wenn du weißt, dass du steuerlich relevante Daten in Access hältst, und dir nicht sicher bist, ob das hält — melde dich. Ich schaue mir das an.

Quellen

Über den Autor

Sönke Schäfer berät seit über 25 Jahren norddeutsche KMU bei der Weiterentwicklung und Absicherung von Microsoft-Access-Anwendungen. Sein Schwerpunkt liegt auf der Anbindung von Access-Frontends an SQL Server — für mehr Stabilität, bessere Wartbarkeit und, ja, für Anforderungen wie GoBD-Konformität, die aus einem selbstgebauten Access-Bestand heraus sonst kaum zu erfüllen sind. Mehr unter sesoft.de/datenschaefer-soenke-schaefer/.

Ähnliche Beiträge

Nach oben scrollen