Alle BeiträgeEngineering
Feste Regeln für KI-Buchungen im Hauptbuch
Die Aufmerksamkeit gilt meist dem Abgleich von Bankpositionen. Ob sich jeder Eintrag in der Buchhaltung später noch erklären lässt, entscheidet sich aber beim Buchen. Ein fester Schlüssel pro Buchung, eine Prüfung des Buchungsmonats, ein einziger Eingang und die Regel, dass die Automatisierung ihre eigenen Buchungen nie selbst korrigiert.
Die Funktion war kurz und gut gemeint. Sie gehörte zu einer Automatisierung, die für eine Gruppe mit elf Gesellschaften Einträge in der Buchhaltung (dem Hauptbuch) erfasste: Bankgebühren, Kursdifferenzen bei Zahlungen in Fremdwährung und die monatliche Weiterbelastung gemeinsamer IT- und Finanzleistungen an jede Tochtergesellschaft. Hielt das System eine seiner eigenen Buchungen für falsch, etwa eine Gebühr in der falschen Gesellschaft, löschte die Funktion sie und buchte sie korrigiert neu. Das ERP, das zentrale Geschäftssystem der Gruppe, ließ das zu, solange der Monat offen war. Niemand hielt sie auf.
Mitten in einem Monat beschloss die Gruppe dann eine neue Formel zur Aufteilung der Weiterbelastungen, eine Routineanpassung, nachdem Personal zwischen zwei Tochtergesellschaften gewechselt war. Die Funktion hielt jede bereits gebuchte Weiterbelastung des Monats für falsch. Sie löschte jede einzelne und buchte sie mit der neuen Aufteilung erneut, in neun Gesellschaften. Die Zahlen stimmten danach. Wie sie zustande gekommen waren, war verloren, und es kostete den Konzernbereich Finanzen Wochen geduldiger Arbeit, herauszufinden, welche Buchungen überschrieben worden waren. Die Funktion wurde abgeschaltet, bevor jemand fragen konnte, was sie sonst noch löschen durfte.
Die meiste Aufmerksamkeit in der Finanzautomatisierung gilt dem Abgleich: Welche Bankposition gehört zu welcher offenen Rechnung? Doch sobald die meisten Positionen ohne Menschen zugeordnet werden, erreichen die daraus entstehenden Buchungen die Bücher, ohne dass jemand vorher hinsieht. Die Regeln fürs Schreiben, ein Protokoll, werden dann selbst zur Kontrolle.
Automatische Fehler laufen durch den menschlichen Korrekturprozess
Die Regel unter allem anderen: Macht die Automatisierung einen Fehler in der Buchhaltung, korrigieren ihn dieselben Menschen und derselbe Prozess, die menschliche Fehler korrigieren. Eine Korrekturbuchung, erstellt vom Finanzteam, mit Begründung und Freigabe. Das System korrigiert seine eigenen Buchungen nicht und löscht nie.
Pat Helland hat das 2007 Datenbankentwicklern in einem Essay mit dem Titel „Accountants Don't Use Erasers" erklärt: Ein Hauptbuch wächst nur. Der Korrekturprozess ist der Teil der Buchhaltung, den die Prüfer bereits testen. Eine Automatisierung, die sich selbst korrigiert, hat still einen zweiten gebaut, ohne Dokumentation und ohne Freigabe. Deshalb fehlen ihr im ERP die Rechte, etwas zu löschen oder zu ändern, das sie gebucht hat, und die Regel hält auch an dem Tag, an dem der Code falsch ist.
Einen Monat Weiterbelastungen in neun Gesellschaften von Hand zu stornieren ist mühsam. Also bereitet das System Stornos und neue Buchungen samt Begründung vor, und ein Mensch gibt sie als einen Stapel pro Gesellschaft frei. Aus Tipparbeit wird eine Durchsicht, und die Kontrolle bleibt dort, wo die Prüfer sie erwarten.
Jede Buchung durchläuft fünf Schritte
Erstens der Schlüssel. Jede Buchung trägt einen Schlüssel aus den Geschäftsdaten dessen, was gebucht wird. Bei einer Bankgebühr: Gesellschaft, Bankkonto, Auszugsnummer und Position der Zeile darauf. Bei einer Weiterbelastung: sendende Gesellschaft, empfangende Gesellschaft, Leistungsvereinbarung und Monat. Wir verwenden nur Felder, die das ERP bereits führt, damit man das ERP selbst danach fragen kann. Wie oft der Ablauf es auch erneut versucht, dieselbe Bankzeile ergibt denselben Schlüssel, also wird sie nie doppelt gebucht.
Die Wahl der Felder ist eine Abwägung für die Finanzabteilung. Mit Auszugsnummer erzeugt ein korrigierter Auszug der Bank unter neuer Nummer neue Schlüssel für dieselben Gebühren; ohne sie blockieren sich zwei echte Gebühren in gleicher Höhe am selben Tag. Wir haben sie drin gelassen, und die Dublettenprüfung weiter unten fängt korrigierte Auszüge ab.
Zweitens nachsehen vor dem Schreiben. Der Ablauf fragt das ERP, ob es schon eine Buchung mit diesem Schlüssel gibt, und glaubt dem ERP mehr als dem eigenen Gedächtnis. Läuft ein Aufruf in eine Zeitüberschreitung, wird weder geraten noch blind wiederholt; der nächste Versuch beginnt mit der Abfrage.
Drittens der Monat. Ist er abgeschlossen oder liegt er in einer vom Controller gesetzten Sperrfrist, wird nichts gebucht; der Fall geht mit einem Datumsvorschlag an einen Menschen. In welchem Monat eine Buchung landet, ist ein Urteil über den Abschluss, und das gehört nicht der Automatisierung.
Viertens der Haupteingang: die Standardschnittstellen des ERP, damit dessen eigene Prüfungen, Nummernkreise, Steuerlogik und Berechtigungen greifen. Nie direkt in die Datenbank.
Fünftens zurücklesen und die Belegnummer des ERP am Fall speichern. Erst dann ist der Schritt erledigt.
Jede Buchungsart fällt unter eine Kontrolle, die es schon gibt
Jede geprüfte Finanzabteilung hat eine Reihe von Schlüsselkontrollen, jede mit Verantwortlichem und jährlichem Test. Am schnellsten akzeptierten Prüfer automatische Buchungen, wenn wir keine neuen Kontrollen erfanden und jede Buchungsart unter eine bereits getestete stellten.
Vor dem Start bauen wir diese Zuordnung deshalb mit dem Konzerncontroller und dem Kontrollverantwortlichen. Hier kamen Bankgebühren unter die bestehende Prüfung, ob Bank und Bücher übereinstimmen, Kursdifferenzen unter die Durchsicht zum Monatsende, und Weiterbelastungen unter die Freigabe der Leistungsvereinbarungen und die Prüfung, ob sich die Gesellschaften der Gruppe einig sind, was sie einander schulden. Für jede halten wir fest, was die Automatisierung tut und welche Nachweise sie für den Test hinterlässt.
Passt nichts, tut die Automatisierung meist etwas, das die Finanzabteilung nie von Hand getan hat, und der Kontrollverantwortliche entscheidet. Der Ablauf bucht zudem unter einem eigenen, benannten Konto, damit Prüfer seine Buchungen so stichprobenartig prüfen können wie die von Menschen.
Doppelzahlungen bekommen eine zweite, unabhängige Prüfung
Eine doppelt gebuchte Weiterbelastung wird zu Geld, das zwischen zwei Gesellschaften fließt, oft über eine Grenze, und es zurückzuholen heißt eine zweite Zahlung und ein Gespräch mit der Steuerabteilung. Vor jedem Zahlungslauf sucht deshalb eine eigene Prüfung nach Beinahe-Dubletten: dieselben zwei Gesellschaften, dieselbe Leistung, derselbe oder der nächste Monat, ein ähnlicher Betrag. Auf der Bankseite vergleicht sie Konto, Betrag, Datum und Buchungscode über Auszüge hinweg. Was sie findet, geht an einen Menschen, auch wenn der Schlüssel sagt, die Buchung sei neu.
Die eigenen Prüfungen des ERP helfen, aber ein Auszugsimport lehnt nur eine Auszugsnummer ab, die er schon kennt, also kommt ein korrigierter Auszug unter neuer Nummer durch. Wo das ERP sperren statt warnen kann, stellen wir es auf Sperren. Eine Warnung an ein automatisches Konto liest niemand.
Jeder freigegebene Zahlungsstapel erzeugt genau eine Datei, die erfasst wird, bevor sie das Haus verlässt. Scheitert die Übertragung oder ist ihr Status unklar, sendet das System nicht erneut; ein Mensch klärt das mit der Bank.
Das System prüft seine eigene Arbeit täglich
Einmal am Tag vergleicht ein eigener Prozess, was der Ablauf geschrieben zu haben glaubt, mit dem, was ERP und Bank tatsächlich führen: Bankzeilen ohne Fall, Fälle ohne Buchung oder mit zweien, Weiterbelastungen, die der Sender gebucht hat, der Empfänger aber nicht, Zahlungen, die nicht genau einmal in der Bestätigung der Bank stehen. Was nicht passt, geht mit den Nachweisen an die Finanzabteilung.
Die Entwickler von Stripe haben im Februar 2024 in einem Beitrag über ihr Ledger-System eine strukturelle Variante beschrieben: Geld, das durch ein Durchgangskonto läuft, sollte es auf null zurücklassen, also weist jedes Durchgangskonto mit Restsaldo auf einen gebrochenen Ablauf hin. Der tägliche Lauf listet Posten, die länger als vereinbart auf den Durchgangskonten der Gruppe liegen, oft das erste Zeichen, dass etwas doppelt oder gar nicht gebucht wurde.
An den meisten Tagen meldet er nichts. Wenn doch, hat er das Problem meist eine oder zwei Wochen vor dem Monatsabschluss gefunden.
Geben Sie ihr keinen Weg, die Geschichte umzuschreiben
Finanzteams beurteilen eine Automatisierung danach, ob sie jeden Eintrag in den Büchern erklären können. Eine, die nur hinzufügen kann und deren Fehler so korrigiert werden wie die von Menschen schon immer, bleibt erklärbar.