GOBD & MICROSOFT ACCESS · STAND 1. AUGUST 2026
Access GoBD-konform betreiben: so bauen wir bestehende Datenbanken um
Microsoft Access kann Teil einer GoBD-gerechten Lösung sein. Entscheidend ist nicht die Dateiendung, sondern ob steuerlich relevante Daten nachvollziehbar, geschützt, verfügbar und prüfbar bleiben.
Kann eine Access-Datenbank GoBD-konform sein?
Ja – aber nicht automatisch und nicht allein durch eine technische Funktion. Die GoBD betreffen das gesamte Verfahren: von der Erfassung und Änderung steuerlich relevanter Daten über Berechtigungen und Kontrollen bis zu Aufbewahrung, Datenzugriff und Dokumentation.
Deshalb gibt es keinen Schalter „GoBD-konform“ und auch kein allgemeingültiges Access-Zertifikat. Ob ein Verfahren die Anforderungen erfüllt, hängt von der konkreten Datenbank, ihrer technischen Umgebung und der tatsächlichen Arbeitsweise im Unternehmen ab.
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.
Welche GoBD-Anforderungen für Access technisch relevant sind
§ 146 der Abgabenordnung verlangt unter anderem vollständige, richtige, zeitgerechte und geordnete Aufzeichnungen. Änderungen dürfen den ursprünglichen Inhalt nicht unkenntlich machen. Für elektronische Systeme kommen Verfügbarkeit, Lesbarkeit und Datenzugriff hinzu.
| Anforderung | Typisches Risiko in einer Access-Datei | Unser technischer Ansatz |
|---|---|---|
| Nachvollziehbarkeit | Ein Wert wird überschrieben, ohne dass alter Wert, Zeitpunkt und Benutzer erhalten bleiben. | Ein zentraler Audit-Trail protokolliert Einfügen, Ändern und Löschen mit Vorher-/Nachher-Werten. |
| Schutz vor unbemerkter Änderung | Tabellen können direkt geöffnet oder VBA- und Makro-Abläufe umgangen werden. | SQL-Trigger protokollieren auf Datenbankebene; Rollen und Rechte schützen Tabellen und Audit-Daten. |
| Ordnung und Vollständigkeit | Datensätze werden physisch gelöscht oder Exporte enthalten nur ausgewählte Ansichten. | Löschmarkierungen bewahren Datensätze; vollständige Exporte umfassen Stamm-, Bewegungs- und Audit-Daten. |
| Verfügbarkeit und Lesbarkeit | Eine einzelne ACCDB ist beschädigt, verloren oder nur mit altem Spezialwissen auswertbar. | Geprüfte Sicherungen, dokumentierte Wiederherstellung und strukturierte, maschinell lesbare Exporte. |
| Verfahrensdokumentation | Niemand kann später erklären, wie Erfassung, Korrektur, Sicherung und Berechtigungen funktionieren. | Eine verständliche Dokumentation beschreibt System, Rollen, Abläufe, Kontrollen und Änderungen. |
Warum eine reine VBA-Protokollierung meist nicht genügt
Eine Protokollierung im Access-Frontend ist besser als gar keine Protokollierung. Für steuerlich relevante Daten ist sie als einzige Schutzschicht jedoch häufig zu schwach.
- 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 mit weitreichenden Access-Rechten können lokale Logtabellen verändern.
Deshalb legen wir die eigentliche Audit-Logik 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 müssen deshalb begrenzt, protokolliert und in der Verfahrensdokumentation beschrieben werden.
Unsere Zielarchitektur: Access vorne, SQL Server hinten
Für kleine und mittlere Access-Anwendungen ist eine schrittweise Modernisierung oft wirtschaftlicher als eine komplette Neuentwicklung. Die vertraute Bedienung bleibt weitgehend bestehen, während die Datenhaltung robuster wird.
| Access-Frontend | SQL-Server-Backend |
|---|---|
| Formulare, Berichte, Bedienlogik und bestehende Access-Abfragen | Fachliche Tabellen, Beziehungen, Indizes und Datenintegrität |
| Direkt verknüpfte SQL-Tabellen über ODBC | Trigger und Stored Procedures für Audit- und Schutzfunktionen |
| Benutzerführung, Exporte und verständliche Statusanzeigen | Audit-Tabelle, Rollen, Berechtigungen, Sicherung und Wiederherstellung |
Wir arbeiten dabei nicht zwingend mit SQL-Views. Bestehende Access-Abfragen können im Frontend verbleiben, während die SQL-Tabellen direkt verknüpft werden. Das reduziert Aktualisierungsprobleme und hält den Umbau möglichst nah an der vorhandenen Anwendung.
Die wichtigsten Maßnahmen in der Praxis
-
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. Frontend und Backend sauber trennen
Formulare, Berichte und Bedienlogik bleiben in einer wartbaren Access-Datei. Die relevanten Tabellen werden zu SQL Server übertragen und anschließend direkt mit Access verknüpft.
-
3. Änderungen zentral protokollieren
Trigger 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. 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. 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. 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. 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. Eine E-Mail-Kopie allein ist keine vollständige Datensicherung.
Technik allein reicht nicht: Betrieb und Verfahrensdokumentation
Die beste Triggerlogik hilft wenig, wenn Benutzer weiter unkontrolliert Originaldaten bearbeiten, Sicherungen nie geprüft oder Systemänderungen nicht dokumentiert werden. Deshalb gehört zu einer belastbaren Lösung immer eine verständliche Verfahrensdokumentation.
Systemübersicht
Welche Access-Dateien, SQL-Datenbanken, Schnittstellen, Arbeitsplätze und Archive gehören zum Verfahren?
Arbeitsabläufe
Wie werden Daten erfasst, geprüft, korrigiert, gelöscht, exportiert und aufbewahrt?
Rollen und Kontrollen
Wer darf was, wer kontrolliert Ausnahmen und wie werden administrative Eingriffe behandelt?
Änderungshistorie
Welche Versionen wurden eingesetzt und wann wurden Datenmodell, Regeln oder Programme verändert?
Die Dokumentation muss zum tatsächlichen Kleinbetrieb passen. Sie soll vollständig genug für die Nachvollziehbarkeit sein, aber nicht aus künstlich aufgeblähten Textbausteinen bestehen.
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?
Häufige Fragen zu Access und GoBD
Amtliche Grundlagen und weiterführende 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.
Ist Ihre Access-Datenbank für GoBD-Anforderungen vorbereitet?
Wir prüfen Ihre bestehende Lösung und erstellen einen verständlichen, wirtschaftlich passenden Maßnahmenplan. Dabei bleibt so viel wie möglich erhalten – und wir ändern nur, was für Nachvollziehbarkeit, Schutz und Prüfbarkeit wirklich erforderlich ist.
Über den Autor
Jörg Hartgen arbeitet seit über 20 Jahren mit Microsoft Access, VBA und Office-Automation. Sein Schwerpunkt liegt auf der Betreuung, Stabilisierung und Modernisierung gewachsener Access-Anwendungen sowie deren Verbindung mit SQL Server, Webanwendungen und APIs.