Ist KI-Buchhaltung GoBD-konform? Das Änderungsprotokoll

Wenn ein Betriebsprüfer 2027 dein Änderungsprotokoll öffnet und sieht, dass die Kategorie einer Ausgabe an einem Sonntag um 03:14 gesetzt wurde, wird er nicht fragen, ob eine KI das durfte. Er wird fragen, wer es war. Und die meisten Buchhaltungssysteme, unseres bis vor kurzem eingeschlossen, können das nicht beantworten.

Das ist das gesamte Compliance-Problem der KI-Buchhaltung in Deutschland, und es ist deutlich enger und lösbarer, als die Debatte vermuten lässt. Die GoBD verbieten automatisiertes Buchen nicht. Sie haben es nie getan. Verlangt wird, dass jeder steuerlich relevante Datensatz auf seinen Ursprung zurückführbar und nachträglich unveränderbar ist. Eine KI, die deinen Kaffeebeleg auf das falsche Konto bucht, ist ein Buchhaltungsfehler. Eine KI, die ihn bucht und keine Spur davon hinterlässt, überhaupt etwas entschieden zu haben, ist ein GoBD-Problem.

Ist KI-Buchhaltung GoBD-konform?

Sie kann es sein, und die Anforderungen haben sich nicht geändert, weil KI dazugekommen ist. GoBD-Konformität ruht auf denselben Grundsätzen wie immer: Nachvollziehbarkeit, Unveränderbarkeit, zeitgerechte Buchung, Belegprinzip und eine schriftliche Verfahrensdokumentation. Keine dieser Anforderungen interessiert sich dafür, ob ein Mensch oder ein Modell die Kategorie vorgeschlagen hat. Alle interessieren sich dafür, dass die Entscheidung und jede spätere Änderung daran protokolliert ist und nicht still überschrieben werden kann.

Der praktische Test für jedes KI-Buchhaltungstool ist also nicht, ob auf der Preisseite "GoBD-konform" steht. Es sind drei Fragen, die du an das Änderungsprotokoll stellen kannst:

1. Entsteht überhaupt eine Zeile im Änderungsprotokoll, wenn die Automatisierung etwas bucht?
2. Weist diese Zeile die Automatisierung als Akteur aus, unterscheidbar vom Kontoinhaber?
3. Kann nach der Abgabe oder dem Export einer Periode noch etwas direkt bearbeitet werden, statt per Gegenbuchung korrigiert zu werden?

Wir haben GoBD-Mechanik für unsere eigene Buchhaltung gebaut, und als ich diese drei Fragen an unsere Produktionsdaten gestellt habe, haben wir die dritte bestanden und die ersten beiden nicht. Dazu komme ich zurück.

Was der EU AI Act wirklich verlangt, und was gerade verschoben wurde

Falls du darauf gewartet hast, dass der AI Act dir sagt, was du protokollieren musst: hör auf zu warten. Dieses Jahr sind zwei Dinge passiert.

Erstens haben die EU-Gesetzgeber am 7. Mai 2026 eine vorläufige politische Einigung erzielt, die Hochrisiko-Pflichten im Rahmen des Digital Omnibus zu verschieben. Die Pflichten, die ab dem 2. August 2026 für eigenständige Hochrisikosysteme nach Anhang III gegolten hätten, einschließlich der automatischen Aufzeichnungspflicht in Artikel 12, gelten nun ab dem 2. Dezember 2027. KI in regulierten Produkten nach Anhang I rückt auf den 2. August 2028.

Zweitens kam der 2. August 2026 trotzdem, weil die Transparenzpflichten aus Artikel 50 im ursprünglichen Zeitplan geblieben sind. Das sind Offenlegungspflichten: Menschen mitteilen, dass sie mit einem KI-System interagieren, synthetische Inhalte kennzeichnen. Es sind keine Protokollpflichten.

Und ein dritter Punkt geht dabei unter. Buchhaltung und steuerliche Kategorisierung stehen nicht in Anhang III. Diese Liste umfasst Biometrie, kritische Infrastruktur, Bildung, Beschäftigung, grundlegende Dienstleistungen, Strafverfolgung, Migration und Justiz. Kreditwürdigkeitsprüfung steht drin, die Entscheidung, ob dein Laptopkauf eine Betriebsausgabe ist, nicht. Für die überwiegende Mehrheit der Buchhaltungsautomatisierung hätte der Protokollartikel des AI Act also ohnehin nie gegriffen, und dort, wo er gegriffen hätte, ist er jetzt verschoben.

Meine Meinung, und sie ist widerlegbar: Für die deutsche Buchhaltung ist der AI Act eine Ablenkung. Das bindende Regelwerk ist eine Verwaltungsvorschrift von 2019, neu gefasst mit Wirkung zum 1. April 2024, die für jedes Unternehmen unabhängig von einer Risikoklasse gilt, keine Übergangsfrist mehr hat und von Menschen durchgesetzt wird, die in dein Büro kommen.

Was die GoBD verlangen und der EU AI Act nicht

Lies die Zeile zur Unveränderbarkeit zweimal. Sie ist die einzige, die kein KI-Regelwerk verlangt und die jede deutsche Betriebsprüfung voraussetzt. Sie ist auch die, die schwer zu bauen ist, weil sie gegen jeden Instinkt eines Produktteams arbeitet, Nutzer ihre eigenen Daten korrigieren zu lassen.

Die Spalte, die unser Änderungsprotokoll nicht hatte

Wir haben die GoBD-Mechanik im April gebaut. Eine Transaktion trägt ein Feld is_locked, im Code beschrieben als "GoBD locked (immutable)", und einen record_hash, einen SHA-256 über die zwölf Felder, die die Buchung bestimmen: Betrag, Leistungsdatum, Steuersatz und Steuerbetrag, Zahlungsrichtung, Kategorie, Lieferantenland, Reverse Charge, Umsatzart, Beschreibung. Der Versuch, eine gesperrte Transaktion zu entverifizieren, löst einen Fehler aus, der auf eine Stornobuchung verweist. Es gibt ein Modell AuditLog, dessen Docstring wörtlich von einem GoBD-konformen Änderungsprotokoll spricht und das Anlegen, Ändern, Löschen, Verifizieren und Exportieren mit einem feldweisen Vergleich von alt und neu erfasst, dazu Nutzer und IP-Adresse.

Dann habe ich die drei Fragen gegen die Produktion laufen lassen. Vier Monate Protokollzeilen, knapp zweihunderttausend.

Frage zwei zuerst, weil die Antwort am klarsten ist. Die Tabelle AuditLog hat genau eine Akteursspalte: einen nullbaren Fremdschlüssel auf einen Nutzer. Es gibt keine Spalte dafür, welche Art von Akteur die Änderung gemacht hat. Bei Transaktionszeilen ist der Nutzer fast immer gefüllt. Bei Rechnungs- und Belegzeilen ist er in jeder einzelnen Zeile leer, mehrere tausend davon, weil diese aus einem Datenbank-Signalhandler geschrieben werden, der keinen Request und keinen Nutzer weitergeben kann. Ein Prüfer, der diese Zeilen liest, erfährt, dass sich etwas geändert hat und worauf. Nicht durch wen.

Frage eins ist schlimmer. Unsere automatische Kategorisierung läuft in einem Nachbearbeitungsdienst beim Import, der Kategorie, Steuersatz, Steuerbetrag und Kategorisierungsstatus setzt und dann speichert. Er berührt das Änderungsprotokoll überhaupt nicht, und er kann es auch nicht versehentlich tun: Protokollzeilen für Transaktionen werden explizit aus Services geschrieben, mit einem Kommentar in den Signalhandlern, der Entwickler ausdrücklich davor warnt, ein Signal für Transaktionen zu ergänzen. Die Rechnung über vier Monate lautet also: knapp eine Million Transaktionen wurden angelegt, und etwa eine von fünfzig hat einen Anlage-Eintrag im Änderungsprotokoll. Etwa die Hälfte wurde kategorisiert. Weniger als eine von vierzig dieser Kategorisierungen verweist auf eine benannte deterministische Regel, und das ist der einzige Entscheidungspfad, der einen dauerhaften Zeiger auf seine eigene Begründung hinterlässt.

Der Rest wurde vom Firmengedächtnis entschieden, einem deterministischen Nachschlagen von Geschäftspartnern, die dieses Unternehmen mindestens zweimal korrigiert hat, oder vom Modell. Beides ist buchhalterisch vertretbar. Keines ist im Nachhinein aus dem Datensatz selbst unterscheidbar.

Die Form des Fehlers finde ich lehrreich. Das Änderungsprotokoll hält getreu fest, wie der Mensch die Maschine korrigiert, und sagt nichts über die ursprüngliche Entscheidung der Maschine. Das ist genau die Umkehrung dessen, was Nachvollziehbarkeit bedeutet.

Was wir falsch gemacht haben: verifiziert ist nicht unveränderbar

Die Nachbetrachtung ist kurz und leicht peinlich.

Unser erster Versuch von Unveränderbarkeit sperrte eine Transaktion, sobald der Nutzer sie verifizierte. Das klang richtig: Der Nutzer hat die Buchung bestätigt, also versiegeln wir sie. Es war in beide Richtungen gleichzeitig falsch. Verifizieren ist ein Arbeitsschritt, den Nutzer beiläufig tun und oft zurücknehmen, also brach das Sperren beim Verifizieren das normale Bearbeiten. Und es entspricht nichts, was die GoBD interessiert, denn der rechtlich entscheidende Moment ist der, in dem die Zahlen dein System in eine Abgabe oder einen Export verlassen, nicht der, in dem jemand ein Häkchen setzt.

Eine spätere Migration hat daher alle verifizierten Transaktionen entsperrt, mit dem Hinweis, is_locked solle nur explizit gesetzt werden, etwa nach einem DATEV-Export. Richtige Diagnose. Nur ruft im aktuellen Code niemand die Methode auf, die es setzt. lock() hat Leser, einen Integritätsprüfbefehl, Wächter, die das Löschen eines Belegs an einer gesperrten Transaktion verweigern, aber keinen Aufrufer. In der gesamten Produktionsdatenbank ist keine einzige Transaktion gesperrt. Der Storno-Korrekturpfad, also der Teil, der Unveränderbarkeit tatsächlich umsetzt, ist nie ausgeführt worden.

Die Lehre gilt über uns hinaus. Unveränderbarkeit ist kein Wahrheitswert in einer Zeile, den man umlegt, wenn ein Nutzer sich sicher fühlt. Sie ist die Folge eines Ereignisses, das dein System verlässt: eine abgegebene Umsatzsteuervoranmeldung, ein ausgeführter DATEV-Export, ein geschlossener Zeitraum. Modellier diese Ereignisse, und das Sperren folgt daraus. Modellier es als Nutzereinstellung, und du kämpfst am Ende entweder gegen deine Nutzer oder hast, wie wir, ein Feld, das niemand setzt.

Das Akteursproblem hat dieselbe Form. Ein Änderungsprotokoll, das um den Request eines eingeloggten Menschen herum gebaut ist, hat eine Akteursspalte, weil es immer nur eine Art von Akteur gab. Die Lösung ist nicht raffiniert. Sie ist eine zweite Spalte, auf jedem Schreibpfad gefüllt, die den Kontoinhaber von einer deterministischen Regel und von einem Modell unterscheidet, wobei Regel oder Modell benannt werden. Das ergänzen wir gerade, und ich würde jeden Anbieter, dessen Produkt für dich bucht, fragen, ob sein Protokoll das hat.

Wie du GoBD-Konformität in einem KI-Buchhaltungstool prüfst

Lass das Compliance-Siegel weg. Bitte um einen Screenshot des Änderungsprotokolls für eine Transaktion, die die Automatisierung kategorisiert hat, und prüfe drei Dinge: dass eine Zeile für die Entscheidung der Automatisierung selbst existiert, dass diese Zeile die Automatisierung benennt und nicht dich oder niemanden, und dass der alte Wert neben dem neuen erhalten ist. Frag dann, welches Ereignis eine Periode versiegelt und ob eine versiegelte Periode bearbeitet oder nur per Gegenbuchung korrigiert werden kann. Frag dann nach der Vorlage für die Verfahrensdokumentation, denn du schuldest dem Finanzamt eine schriftliche Beschreibung genau dieses Prozesses, und ein Anbieter, der über die ersten vier Fragen nachgedacht hat, hat sie schon aufgeschrieben.

Eine belastbare und gelebte Verfahrensdokumentation ist mehr wert, als der Papierkram vermuten lässt. Im Rahmen der Reform der steuerlichen Außenprüfung kann ein Steuerkontrollsystem, dessen Wirksamkeit in einer Prüfung bestätigt wurde, dokumentierte Erleichterungen in späteren Prüfungen bringen. Automatisierung macht das leichter zu verdienen, nicht schwerer, weil eine Maschine dem dokumentierten Prozess zuverlässiger folgt als ein Mensch. Aber nur, wenn sie aufschreibt, was sie getan hat.

Zu den zugrunde liegenden Pflichten deckt unser Leitfaden zur GoBD-konformen Buchhaltung die zehn Grundsätze, die Aufbewahrungsfristen und den Datenzugriff Z1 bis Z3 ab. Auf der technischen Seite beschreiben wie wir Agenten-Läufe ohne Datenspeicherung nachvollziehen und wie unsere Kategorisierung aus Korrekturen lernt die beiden Mechanismen, die die Akteursfrage überhaupt beantwortbar machen.

Häufige Fragen

Gibt es eine Buchhaltungssoftware, die ohne technische Kenntnisse bedienbar und GoBD-konform ist?

Ja, und die Bedienbarkeit ist von der Konformität unabhängig. GoBD-Konformität ist eine Eigenschaft davon, wie ein System Daten protokolliert und versiegelt, nicht davon, wie schwer es zu bedienen ist. Prüfen solltest du, dass das Tool ein Änderungsprotokoll mit alten und neuen Werten führt, direktes Bearbeiten nach Abgabe oder Export einer Periode verhindert und eine Vorlage für die Verfahrensdokumentation mitliefert, denn die schriftliche Prozessbeschreibung ist deine Pflicht, nicht die des Anbieters.

Welche Kriterien sollten die Bewertung KI-gestützter Steuertechnologie durch ein deutsches Unternehmen leiten?

Vier, in dieser Reihenfolge. Kann das Änderungsprotokoll eine Buchung speziell der Automatisierung zuordnen und nicht nur deinem Konto? Welches Ereignis versiegelt eine Periode gegen weitere Änderungen, und erfolgen Korrekturen danach per Gegenbuchung? Ist der Datenexport in einem Format, das ein Betriebsprüfer beim Zugriff Z1 bis Z3 wirklich lesen kann? Und liefert der Anbieter eine Verfahrensdokumentation, die zur tatsächlichen Funktionsweise passt? Die Modellqualität ist weniger wichtig als das, denn eine falsche Kategorie ist billig zu korrigieren, ein nicht prüfbares Buch nicht.

Was ist die beste Buchhaltungssoftware in Bezug auf Rechtssicherheit (GoBD-Konformität, Datenschutz, Updates zu neuen Gesetzen)?

Rechtssicherheit besteht aus drei trennbaren Dingen, also bewerte sie getrennt. GoBD-Konformität ist im Änderungsprotokoll und im Export überprüfbar, wie oben beschrieben. Datenschutz betrifft die Frage, wo Daten verarbeitet werden und wie die Liste der Subunternehmer aussieht. Die Aktualität bei neuen Gesetzen ist eine Frage des Release-Rhythmus: Frag, wann der Anbieter die letzte für dich relevante gesetzliche Änderung umgesetzt hat, etwa die E-Rechnungspflichten, und woher du davon erfahren hast.

Gilt der EU AI Act für die Buchhaltungsautomatisierung?

Überwiegend nicht so, wie erwartet. Buchhaltung und steuerliche Kategorisierung stehen nicht in Anhang III, die Hochrisiko-Pflichten einschließlich der Protokollpflicht aus Artikel 12 greifen daher in der Regel nicht, und sie wurden mit der vorläufigen Digital-Omnibus-Einigung vom 7. Mai 2026 ohnehin auf den 2. Dezember 2027 verschoben. Die Transparenzpflichten aus Artikel 50 gelten seit dem 2. August 2026, betreffen aber die Offenlegung, dass ein System KI ist, nicht die Führung von Buchhaltungsaufzeichnungen. Die bindende Schranke sind die GoBD.

Darf eine KI die Buchung entscheiden, oder muss ein Mensch sie bestätigen?

Die GoBD verlangen keine menschliche Bestätigung jeder Buchung. Sie verlangen, dass die Buchung nachvollziehbar, belegbasiert, zeitgerecht und nachträglich unveränderbar ist und dass deine Verfahrensdokumentation zutreffend beschreibt, wie gebucht wird. Wenn deine Verfahrensdokumentation sagt, dass eine automatische Kategorisierung ohne Prüfung gebucht wird, kann das konform sein, sofern das Änderungsprotokoll die Entscheidung erfasst und der Korrekturweg eine Gegenbuchung ist. Nicht konform ist eine Prozessbeschreibung, die eine menschliche Prüfung behauptet, die nicht stattfindet.

Fazit

Die interessante Frage zu KI in der Buchhaltung war nie, ob der Gesetzgeber sie erlaubt. Sie lautet, ob dein System sich hinterher noch erklären kann. Die GoBD haben das 2019 verlangt, auf eine Weise, die für maschinelle Akteure zufällig genau richtig ist: den Ursprung benennen, den alten Wert behalten, niemals still überschreiben. Wir haben zwei Lücken in unserer eigenen Umsetzung gefunden, indem wir drei Fragen an unsere eigenen Daten gestellt haben, und beide lagen in der langweiligen Richtung, eine fehlende Spalte und eine nicht aufgerufene Methode, nicht im Modell. Genau dort würde ich auch die Lücken aller anderen erwarten.