Feste Regeln für KI-Buchungen im Hauptbuch

Die Funktion war kurz und gut gemeint. In einer Gruppe mit elf Gesellschaften buchte eine Automatisierung die Journale, die aus Kontoauszügen und konzerninternen Weiterbelastungen entstehen: Bankgebühren, Kursdifferenzen bei Zahlungseingängen in Fremdwährung, die monatliche Weiterbelastung gemeinsamer IT- und Finanzleistungen an jede Tochtergesellschaft. Die Funktion sprang immer dann an, wenn das System eine seiner eigenen Buchungen für falsch hielt, etwa eine Gebühr in der falschen Gesellschaft. Dann löschte sie die Buchung und buchte sie korrigiert neu. Das ERP ließ das bei nicht abgestimmten Journalen in offenen Perioden zu, also hielt sie niemand auf.

Mitten in einem Monat beschloss die Gruppe dann einen neuen Verteilungsschlüssel für die 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 Hauptbücher stimmten danach. Wie sie zustande gekommen waren, ließ sich nicht mehr nachvollziehen, 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.

In der Finanzautomatisierung gilt die meiste Aufmerksamkeit dem Abgleich von Bankpositionen. Die Kontrollen sitzen aber beim Buchen ins Hauptbuch. Dafür braucht es feste Regeln, nicht nur eine Schnittstelle. Je besser der Abgleich wird, desto wichtiger wird das. Wenn die meisten Auszugszeilen ohne einen Menschen zugeordnet werden, erreichen die meisten Buchungen, die daraus entstehen, das Hauptbuch, ohne dass vorher jemand hinsieht, und dann sind die Regeln für das Buchen die Kontrolle.

Fehler der Automatisierung werden wie menschliche Fehler korrigiert

Eine Regel steht über allen anderen. Macht die Automatisierung im Hauptbuch einen Fehler, wird er von denselben Menschen und im selben Prozess korrigiert wie jeder menschliche Fehler: mit einer Storno- oder Korrekturbuchung, die das Finanzteam veranlasst, begründet und freigibt. Nie durch das System selbst und nie durch Löschen.

Pat Helland hat Datenbankentwicklern 2007 dasselbe gesagt, in einem Essay mit dem Titel „Accountants Don't Use Erasers“. Ein Hauptbuch wächst nur. Einen Eintrag korrigiert man, indem man einen weiteren hinzufügt, der den ersten erklärt. Diese Funktion tat das Gegenteil: Sie ersetzte den Eintrag und hinterließ keine Spur des ersten. Entwickler von Ereignisprotokollen haben diese Idee aus der Buchhaltung übernommen. Automatisierung, die in ein echtes Hauptbuch schreibt, muss sie zurückgeben.

Das ist keine Vorsicht um ihrer selbst willen. Den Korrekturprozess testen die Wirtschaftsprüfer bereits, und die Controller vertrauen ihm. Eine Automatisierung, die ihre eigenen Buchungen korrigiert, schafft einen zweiten Korrekturprozess, undokumentiert und ohne Funktionstrennung. Deshalb darf sie im ERP Journale, die sie selbst gebucht hat, weder löschen noch vorerfassen noch ändern. Die Berechtigungen sind so gesetzt, dass die Regel auch dann greift, wenn der Code fehlerhaft ist.

Die Regel hat ihren Preis, und das Finanzteam spürt ihn zuerst. Wenn ein neuer Verteilungsschlüssel bedeutet, dass sich jede Weiterbelastung des Monats in neun Gesellschaften ändern muss, sind die Stornos von Hand mühsam, und irgendwer fragt immer, warum das System seine eigene Arbeit nicht stornieren kann. Unsere Antwort: Das System bereitet die Stornos und die neuen Buchungen vor, mit Begründung und den betroffenen Buchungen, und ein Mensch bucht sie als einen freigegebenen Stapel je Gesellschaft. Die Arbeit schrumpft auf eine Prüfung. Die Kontrolle bleibt dort, wo die Wirtschaftsprüfer sie erwarten.

Jede Buchung durchläuft fünf Schritte

Ein Geschäftsschlüssel statt einer Request-ID. Jede Buchung trägt einen eindeutigen Geschäftsschlüssel, gebildet aus dem, was gebucht wird. Für eine Bankgebühr sind das Gesellschaft, Bankkonto, Auszugsnummer und die Position der Zeile im Auszug. Für eine Weiterbelastung sind es die belastende Gesellschaft, die belastete Gesellschaft, die Leistungsvereinbarung und die Periode. Der Schlüssel wird nur aus Feldern gebildet, die das ERP ohnehin führt, abgestimmt mit Finanzbereich und IT, sodass man das ERP selbst nach ihm fragen kann: In SAP steht er in der Referenz im Belegkopf, in Dynamics 365 Business Central in der externen Belegnummer. Dieselbe Auszugszeile ergibt immer denselben Schlüssel, egal wie oft der Workflow neu startet oder einen Schritt wiederholt. Das Engineering-Team von Stripe hat 2017 beschrieben, wie Idempotenzschlüssel bei Zahlungs-APIs funktionieren. Im ERP kommt es vor allem darauf an, woraus der Schlüssel gebildet wird. Ein Schlüssel, der für jede Anfrage neu erzeugt wird, schützt vor einer doppelten Anfrage. Nur ein Geschäftsschlüssel schützt davor, dass der Workflow dieselbe Entscheidung zweimal trifft.

Die Wahl der Felder ist eine Abwägung, und der Finanzbereich sollte sie bewusst treffen. Steht die Auszugsnummer im Schlüssel, erzeugt eine Bank, die einen korrigierten Auszug unter neuer Nummer schickt, neue Schlüssel für dieselben Gebühren, und der Geschäftsschlüssel allein ließe beide durch. Steht sie nicht darin, blockieren sich zwei echte Gebühren mit gleichem Betrag am gleichen Tag gegenseitig, und das kommt auf einem lebhaften Konto ständig vor. Wir nehmen die Auszugsnummer auf und verlassen uns darauf, dass die Dublettenprüfung weiter unten den korrigierten Auszug abfängt. Der Schlüssel verhindert, dass der Workflow sich wiederholt. Die zweite Prüfung verhindert, dass die Welt sich wiederholt.

Vor dem Buchen nachfragen. Der Workflow fragt das ERP, ob es schon ein Journal mit diesem Schlüssel gibt, und verlässt sich auf die Antwort des ERP, nicht auf sein eigenes Gedächtnis. Dieser Schritt macht Zeitüberschreitungen harmlos. Läuft ein Buchungsaufruf in einen Timeout, weiß der Workflow nicht, ob das Journal angelegt wurde. Er rät nicht und wiederholt nicht einfach. Der nächste Versuch beginnt mit der Abfrage, findet das Journal oder nicht und macht von dort aus weiter.

Die Periode prüfen. Ist die Zielperiode geschlossen oder liegt sie in einem vom Controller festgelegten Sperrzeitraum, wird nicht gebucht. Der Fall geht mit einem Datumsvorschlag an einen Menschen. Welche Periode eine Buchung bekommt, ist eine Ermessensentscheidung im Abschluss, und die trifft nicht die Automatisierung.

Nur über die Standardschnittstellen buchen. Buchungen laufen über die regulären Schnittstellen des ERP, damit Validierung, Nummernvergabe, Steuerlogik und Berechtigungen greifen. Nie direkt in die Tabellen.

Zurücklesen und dokumentieren. Nach dem Buchen liest der Workflow das Journal zurück und hinterlegt die Belegnummer aus dem ERP am Vorgang. Erst dann gilt der Schritt als abgeschlossen.

Jede Buchungsart fällt unter eine bestehende Kontrolle

Jeder geprüfte Finanzbereich hat ein internes Kontrollsystem: Schlüsselkontrollen mit jeweils einem Verantwortlichen und einem Test, den die Wirtschaftsprüfer jedes Jahr durchführen. Automatische Buchungen werden am schnellsten akzeptiert, wenn man für sie keine neuen Kontrollen erfindet, sondern jede Buchungsart einer Kontrolle zuordnet, die ohnehin schon getestet wird.

Vor dem Go-live erarbeiten wir diese Zuordnung gemeinsam mit dem Konzerncontroller und dem Verantwortlichen für das interne Kontrollsystem. Buchungen von Bankgebühren fallen unter die bestehende Kontrolle der Bankabstimmung. Kursdifferenzen fallen unter die Prüfung der Fremdwährungsbewertung im Monatsabschluss. Konzerninterne Weiterbelastungen fallen unter die Freigabe der Leistungsvereinbarungen und die Intercompany-Abstimmung, die ohnehin vor der Konsolidierung läuft. Die Netting-Zahlungen, mit denen die Weiterbelastungen ausgeglichen werden, fallen unter die Zahlungsfreigabe, bei unveränderter Funktionstrennung. Für jede Buchungsart dokumentieren wir, was die Automatisierung innerhalb der Kontrolle tut und welche Nachweise sie für den Test hinterlässt.

Passt keine bestehende Kontrolle, ist das bereits ein Befund. Dann tut die Automatisierung etwas, was der Finanzbereich nie manuell getan hat, und das braucht eine Entscheidung des Kontrollverantwortlichen, keinen geschickten Umweg. Der Workflow bucht in jeder Gesellschaft unter einem eigenen, namentlich geführten technischen Benutzer. So können Prüfer seine Buchungen mit denselben Prüfungshandlungen in Stichproben ziehen wie die Buchungen von Mitarbeitenden.

Doppelzahlungen werden ein zweites Mal unabhängig geprüft

Eine doppelte Bankgebühr ist ärgerlich. Eine doppelte Weiterbelastung ist etwas anderes: Sie fließt in das monatliche Netting und wird zu Geld, das zwischen zwei Gesellschaften fließt, oft über eine Grenze hinweg. Sie rückgängig zu machen heißt dann eine zweite Zahlung und ein Gespräch über Steuern.

Referenzen von Weiterbelastungen taugen schlecht als Kennung. Dieselbe Belastung kommt als Korrektur zurück, als Ausgleich zum Quartalsende oder mit einer Periode, die auf drei verschiedene Arten geschrieben ist. Vor dem Netting-Lauf sucht deshalb eine eigene Prüfung nach möglichen Dubletten: gleiches Gesellschaftspaar, gleiche Leistung, gleiche oder benachbarte Periode, ähnlicher Betrag. Auf der Bankseite sucht sie über alle Auszüge hinweg nach gleichem Konto, Betrag, Valutadatum und Geschäftsvorfallcode. Treffer gehen an einen Menschen, auch wenn der Geschäftsschlüssel die Buchung als neu ausweist. Wir verlassen uns nicht allein auf die Prüfungen des ERP. Sie helfen, und sie wurden für eine andere Frage gebaut. Ein Auszugsimport weist meist eine Auszugsnummer zurück, die er schon kennt, und genau deshalb kommt ein korrigierter Auszug unter neuer Nummer durch. Wo das ERP eine Prüfung die Buchung stoppen lässt statt nur zu warnen, stellen wir sie auf Stopp, denn eine Warnung an einen technischen Benutzer liest niemand.

Für Zahlungsdateien gilt eine eigene Regel. Jeder freigegebene Netting-Lauf erzeugt genau eine Datei, und ihre Kennung wird gespeichert, bevor die Datei das Haus verlässt. Schlägt die Übertragung fehl oder ist ihr Status unklar, sendet das System die Datei nie ein zweites Mal. Ein Mensch klärt den Status mit der Bank und entscheidet. Erneutes Senden ist die eine Wiederholung, die echtes Geld kosten kann, und die Klärung dauert Minuten.

Das System gleicht seine eigenen Aktionen täglich ab

Einmal täglich vergleicht ein separater Prozess, was der Workflow gebucht zu haben glaubt, mit dem, was tatsächlich in ERP und Bank steht. Zu jeder eingegangenen Auszugszeile gehört ein Vorgang. Zu jedem abgeschlossenen Vorgang gehört genau ein Journal. Jedes Journal mit der Referenz des Workflows gehört zu einem Vorgang. Jede Weiterbelastung in der belastenden Gesellschaft hat ihr Gegenstück in der belasteten. Jede Zahlung in einer Netting-Datei erscheint genau einmal in der Bestätigung der Bank. Abweichungen landen mit allen Nachweisen als Ausnahme beim Finanzteam.

Das Engineering-Team von Stripe hat die strukturelle Form dieser Prüfung in seinem Beitrag über Ledger (Februar 2024) beschrieben: Ist ein Geldfluss abgeschlossen, müssen die Verrechnungskonten, die er durchlaufen hat, wieder auf null stehen, sodass eine einzige Abfrage nach Verrechnungskonten mit Saldo jeden unterbrochenen Fluss findet, egal was ihn unterbrochen hat. Die Hauptbücher einer Gruppe haben diese Konten bereits. Die Bankverrechnungskonten sollten sich leeren, während Auszugszeilen gebucht werden, und die Intercompany-Verrechnungskonten, während das Netting ausgleicht. Der tägliche Job listet deshalb auch offene Posten auf diesen Konten, die älter als das vereinbarte Zeitfenster sind, gruppiert nach Gesellschaftspaar. Ein dort hängengebliebener Posten ist oft das erste Anzeichen einer Buchung, die zweimal oder gar nicht stattgefunden hat.

Fast immer meldet der Job nichts, und genau so soll es sein. Meldet er etwas, findet er das Problem vor dem Abschluss. Außerdem beantwortet er die Frage der Prüfer nach automatischen Buchungen direkt: Das ist jede Aktion des Systems, und das ist der Nachweis, dass jede genau einmal stattgefunden hat.

Lassen Sie die Automatisierung nie die Historie umschreiben

Ein Finanzteam beurteilt eine Automatisierung nicht danach, wie gut sie einen Kontoauszug liest, sondern danach, ob sich jede Buchung im Hauptbuch erklären lässt. Eine Automatisierung, die nur neue Buchungen hinzufügen kann und deren Fehler so korrigiert werden, wie menschliche Fehler schon immer korrigiert wurden, bleibt jederzeit erklärbar.