Access-Datenbank GoBD-konform betreiben: Die wichtigen Schritte

Was GoBD-Konformität und Revisionssicherheit bedeuten

GoBD steht für „Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in elektronischer Form sowie zum Datenzugriff“. Vereinfacht gesagt müssen steuerlich relevante Daten vollständig, richtig, zeitgerecht und geordnet erfasst werden. Sie müssen während der jeweils geltenden Aufbewahrungsfrist verfügbar, lesbar und für eine Prüfung auswertbar bleiben.

GoBD-Konformität und Revisionssicherheit sind keine Synonyme, sondern stehen im Verhältnis von Rahmen und Schutzziel: Die GoBD bilden den amtlichen Rahmen der Finanzverwaltung. Revisionssicherheit beschreibt ein wesentliches technisch-organisatorisches Schutzziel innerhalb dieses Rahmens – insbesondere für Aufbewahrung, Unveränderbarkeit und die nachvollziehbare Dokumentation von Änderungen.

Der häufig verwendete Begriff Revisionssicherheit beschreibt in diesem Zusammenhang das praktische Ziel: Der ursprüngliche Datenstand bleibt feststellbar, Änderungen werden lückenlos nachvollziehbar, unberechtigte Manipulationen werden verhindert oder zumindest erkennbar und die Daten können innerhalb der gesetzlichen Fristen wiedergegeben werden. Revisionssicherheit ist dabei kein einzelnes Produktmerkmal oder Schalter, sondern muss durch verschiedene Maßnahmen hergestellt werden.

Revisionssicherheit ist damit ein wichtiger Bestandteil einer GoBD-gerechten Lösung, reicht für sich allein aber nicht aus. Zusätzlich müssen beispielsweise Vollständigkeit, zeitgerechte Erfassung, Berechtigungen, betriebliche Kontrollen, Datenzugriff und Verfahrensdokumentation berücksichtigt werden.

Access kann Teil eines GoBD-gerechten Gesamtsystems sein. Mit Access-Bordmitteln allein lässt sich der dafür erforderliche Schutz bei typischen steuerlich relevanten Anwendungen jedoch nicht belastbar erzwingen. Entscheidend sind die Serverdatenbank, wirksame Kontrollen, der tatsächliche Betrieb und eine passende Verfahrensdokumentation.

Deshalb gibt es auch kein allgemeingültiges „Access-Zertifikat für GoBD“. Ob ein Verfahren die Anforderungen erfüllt, hängt von der konkreten Datenbank, ihrer technischen Umgebung und der tatsächlichen Arbeitsweise im Unternehmen ab.

Wir sorgen dafür, dass durch technische Anpassungen belastbare Voraussetzungen für GoBD-Konformität geschaffen werden.

Die Grundidee ist einfach: Wir erhalten die bewährte Access-Oberfläche, verlagern die schutzbedürftige Datenhaltung aber in eine Serverdatenbank. Damit lassen sich Änderungen zentral protokollieren und Zugriffe besser kontrollieren, ohne Formulare, Berichte und eingespielte Arbeitsabläufe vollständig neu zu entwickeln.

Warum Access-Bordmittel allein nicht ausreichen

VBA, Makros und lokale Protokolltabellen können nützliche Bedien- und Kontrollfunktionen übernehmen. Für steuerlich relevante Daten sind sie als einzige Schutzschicht jedoch nicht belastbar genug.

• VBA läuft nur, wenn der vorgesehene Formular- oder Programmablauf tatsächlich ausgeführt wird.
• Direkte Änderungen in Tabellen, Aktionsabfragen oder externe Zugriffe können Frontend-Code umgehen.
• Programmfehler, deaktivierte Inhalte oder ein Absturz können eine Protokollierung unterbrechen.
• Benutzer können lokale Logtabellen verändern.

Auch Kennwörter, ausgeblendete Navigationsbereiche oder gesperrte Formulare ändern dieses Grundproblem nicht: Die Access-Datei bleibt eine Anwendung, deren Programmabläufe und Tabellenzugriffe mit ausreichenden Rechten umgangen werden können. Für typische steuerlich relevante Access-Anwendungen ist eine ausschließlich Access-basierte Lösung deshalb nicht ausreichend.

Die Lösung ist, die fachlichen Daten zu Microsoft SQL Server auszulagern und Access als vertrautes Frontend beizubehalten. Die eigentliche Audit-Logik zur Gewährleistung der Revisionssicherheit liegt dann in SQL Server. Trigger werden bei Datenänderungen direkt in der Datenbank ausgeführt – unabhängig davon, ob die Änderung aus einem Access-Formular, einer Abfrage oder einem anderen freigegebenen Zugriff stammt.

Auch ein SQL-Audit ist nur so gut wie sein Berechtigungskonzept. Administratorzugriffe, Änderungen an Triggern und technische Wartung werden deshalb begrenzt, protokolliert und in der Verfahrensdokumentation beschrieben.

Die wichtigsten Maßnahmen in der Praxis

1. 1. Steuerlich relevante Daten und Arbeitsabläufe bestimmen

   Nicht jede Hilfstabelle braucht denselben Schutz. Gemeinsam mit dem Unternehmen wird festgelegt, welche Daten, Belege, Auswertungen und Korrekturwege für die Besteuerung bedeutsam sind.

2. 2. Frontend und Backend sauber trennen

   Formulare, Berichte und Bedienlogik bleiben in einer wartbaren Access-Datei. Die relevanten Tabellen einschließlich ihrer Daten werden zu SQL Server übertragen und anschließend direkt mit Access verknüpft.

3. 3. Änderungen zentral protokollieren

   Automatische Prozeduren auf dem SQL Server schreiben Tabellenname, Datensatzschlüssel, Vorgang, Zeitpunkt, Benutzer sowie alte und neue Werte in einen geschützten Audit-Trail. Je Datensatz ergänzen wir außerdem Anlage- und Änderungszeitpunkt sowie die verantwortliche Benutzerkennung.

4. 4. Physisches Löschen verhindern

   Wo fachlich sinnvoll, wird ein Datensatz nur als gelöscht markiert. Die normalen Access-Abfragen blenden ihn aus; Audit-Trail und Berechtigungen bewahren die Änderungshistorie. Echte Bereinigungen bleiben ein dokumentierter Ausnahmevorgang.

5. 5. Benutzer und Rechte eindeutig zuordnen

   Die Windows-Benutzerkennung wird kontrolliert an SQL Server übergeben und bei Änderungen gespeichert. Normale Benutzer dürfen Audit-Daten nicht ändern; administrative Rechte werden auf das erforderliche Minimum begrenzt.

6. 6. Vollständigen Export und Datenzugriff vorbereiten

   Ein definierter Export stellt die benötigten Fach- und Audit-Daten strukturiert und maschinell lesbar bereit. Das konkrete Format und der Umfang werden mit Steuerberatung und Prüfungsanforderungen abgestimmt.

7. 7. Sicherung und Wiederherstellung testen

   Gesichert werden nicht nur das Access-Frontend, sondern vor allem die SQL-Server-Datenbank und der Audit-Trail. Aufbewahrungsfristen, getrennte Sicherungsziele und regelmäßige Rücksicherungstests gehören zum Konzept. Für eine revisionssichere Aufbewahrung wird zusätzlich ein dafür geeignetes und passend konfiguriertes Speichersystem benötigt, beispielsweise ein WORM-Speichermedium.

Was wir bei einer bestehenden Access-Datenbank zuerst prüfen

Der sinnvolle Umfang lässt sich erst nach einem Blick in die konkrete Anwendung bestimmen. Für einen kompakten Erstcheck betrachten wir insbesondere:

• Tabellen, Beziehungen, Abfragen, Formulare, Berichte, Makros und VBA
• Art und Umfang der steuerlich relevanten Daten
• bestehende Änderungs-, Korrektur- und Löschwege
• Benutzer, Rechte und Möglichkeiten zur direkten Tabellenbearbeitung
• aktuelle Sicherungen, Exporte und Aufbewahrungsprozesse
• Dokumentation, bekannte Sonderfälle und betriebliche Kontrollen

Das Ergebnis ist keine pauschale Komplettmigration, sondern eine nachvollziehbare Umsetzungsplanung: Was muss zwingend geändert werden, was ist sinnvoll und was kann im gewachsenen Access-System bleiben?

Amtliche Grundlagen und technische Informationen

Dieser Beitrag erläutert eine technische Vorgehensweise und ersetzt keine steuerliche oder rechtliche Einzelfallberatung. Maßgeblich sind die jeweils geltenden Vorschriften und die konkrete betriebliche Umsetzung.

• § 146 Abgabenordnung: Ordnungsvorschriften für die Buchführung und für Aufzeichnungen
• § 147 Abgabenordnung: Aufbewahrung von Unterlagen und Datenzugriff
• Bundesfinanzministerium: Änderung der GoBD vom 11. März 2024
• Bundesfinanzministerium: zweite Änderung der GoBD vom 14. Juli 2025
• Microsoft Learn: Editionen und unterstützte Funktionen von SQL Server 2025
• IONOS: GoBD-konforme E-Mail-Archivierung