Feste Regeln für KI-Buchungen im Hauptbuch

Die Funktion war kurz und gut gemeint. Sie steckte in einer Rechnungsautomatisierung, die ein Kunde von einem anderen Anbieter übernommen hatte, und sprang immer dann an, wenn das System eine seiner eigenen Buchungen für falsch hielt, etwa wegen einer falschen Kostenstelle. Dann löschte sie den Beleg und buchte ihn korrigiert neu. Das ERP ließ das bei unbezahlten Belegen in offenen Perioden zu, also hielt sie niemand auf.

Das Hauptbuch, das sie hinterließ, war korrekt. Wie es zustande gekommen war, ließ sich nicht mehr nachvollziehen. Buchungen waren erschienen und wieder verschwunden, ohne jeden Hinweis auf den Grund, und das Finanzteam brauchte Wochen, um herauszufinden, welche überschrieben worden waren. Es schaltete die Funktion ab, bevor jemand fragte, was sie sonst noch löschen konnte.

In der Finanzautomatisierung gilt die meiste Aufmerksamkeit dem Auslesen von Belegen. Vertrauen gewonnen oder verspielt wird aber beim Buchen ins Hauptbuch. Dafür braucht es feste Regeln, nicht nur eine Schnittstelle.

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.

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 Belege, 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.

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: Buchungskreis, Lieferant, Rechnungsnummer des Lieferanten, Betrag. Er steht in einem Referenzfeld, das das ERP ohnehin hat, abgestimmt mit Finanzbereich und IT. Dieselbe Rechnung 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.

Vor dem Buchen nachfragen. Der Workflow fragt das ERP, ob es schon einen Beleg mit diesem Schlüssel gibt, und verlässt sich auf die Antwort des ERP, nicht auf sein eigenes Gedächtnis.

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 den Beleg 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 Controller und dem Verantwortlichen für das interne Kontrollsystem. Buchungen von Lieferantenrechnungen fallen unter die bestehenden Kontrollen für Dreiwegeabgleich und Rechnungsfreigabe. Abgrenzungsvorschläge fallen unter die Abgrenzungsprüfung im Monatsabschluss. Zahlungsvorschläge 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 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 Buchung ist ärgerlich. Eine doppelte Zahlung ist Geld, das das Unternehmen verlässt.

Rechnungsnummern von Lieferanten taugen schlecht als Kennung. Dieselbe Rechnung kommt als INV-0042, als 42 und als 0042 an oder taucht Monate später als Mahnung mit neuem Scan wieder auf. Vor der Zahlungsfreigabe sucht deshalb eine eigene Prüfung nach möglichen Dubletten: gleicher Lieferant, ähnlicher Betrag, ähnliches Datum und Rechnungsnummern, die ohne Präfixe, führende Nullen und Satzzeichen übereinstimmen. Treffer gehen an einen Menschen, auch wenn der Geschäftsschlüssel die Rechnung als neu ausweist. Wir verlassen uns nicht allein auf die Dublettenprüfung der Bank oder die Warnmeldung des ERP. Beide helfen, und bei beiden haben wir in der Praxis Lücken gesehen.

Für Zahlungsdateien gilt eine eigene Regel. Jeder freigegebene Zahlungslauf 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 jedem abgeschlossenen Vorgang gehört genau ein Beleg. Jeder Beleg mit der Referenz des Workflows gehört zu einem Vorgang. Jede Zahlung in einer Datei erscheint genau einmal in der Bestätigung der Bank. Abweichungen landen mit allen Nachweisen als Ausnahme beim Finanzteam.

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 ein PDF 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.