Die Entscheidungsvorlage: menschliche Freigaben in KI-gestützten Finanzprozessen

Fünfundfünfzig angehaltene Zahlungen in gut vier Minuten. Wir saßen neben der Person, die im Treasury einer Unternehmensgruppe den morgendlichen Zahlungslauf für sieben Gesellschaften abarbeitete, den ersten, den ein neuer Workflow vorbereitet hatte. Danach fragten wir, worauf bei jeder Zahlung geachtet worden war. Die Antwort kam nach kurzem Überlegen und war ehrlich: auf die Summe je Gesellschaft und darauf, ob ihr die Namen der Empfänger bekannt vorkamen.

Der Bildschirm listete jede angehaltene Zahlung mit Empfänger, Betrag, Währung, Fälligkeit und zahlender Gesellschaft, dazu einen Link zu den Unterlagen und einen Freigabeknopf. Warum eine Zahlung angehalten worden war, stand nirgends. Also wurde geprüft, was sich schnell prüfen ließ, und das hätte jeder von uns bei fünfundfünfzig Zeilen und einem Cut-off um elf genauso gemacht. Im Audit-Log standen fünfundfünfzig Freigaben durch eine namentlich genannte Person. Was tatsächlich angesehen worden war, konnte es nicht zeigen.

Finanzkontrollen trennen seit Langem die Person, die eine Buchung vorbereitet, von der Person, die sie verbindlich ausführt. Auf derselben Trennung bauen wir Workflows: Eine KI bereitet die Aktion vor, ein Mensch führt sie aus. Ob das trägt, entscheidet sich im Moment dazwischen, also daran, was der Mensch sieht, wenn er bestätigen soll, und wie lange er wirklich hinsieht.

Eine Vorlage für jeden Grund, aus dem ein Fall anhält

Ein Bildschirm mit dem ganzen Datensatz verlangt von der prüfenden Person, das Problem selbst zu finden. Das System weiß aber bereits, warum es die Zahlung angehalten hat, also sollte der Bildschirm es sagen. Wir ersetzen die Datensatzansicht durch eine Entscheidungsvorlage, die sich um eine einzige Frage dreht.

Die Vorlage beginnt mit einer Zeile: welche Entscheidung ansteht und warum die Zahlung angehalten wurde. „Diese Zahlung ist viermal so hoch wie die größte, die diese Gesellschaft je an diesen Empfänger geleistet hat.“ Darunter stehen nebeneinander das auslösende Feld, der gefundene und der erwartete Wert. Dann die Belege zu genau diesem Punkt und zu nichts anderem. Der vollständige Datensatz ist einen Klick entfernt und steht nicht an erster Stelle.

In jenem Treasury begann eine typische Betragsvorlage mit der Entscheidung in Fettschrift: 86.400 EUR von der spanischen Gesellschaft an einen Frachtführer freigeben oder an die Kreditorenbuchhaltung zurückgeben. Die Zeile darunter nannte den Grund. Die Regel hält alles an, was über dem Doppelten der größten Zahlung der Gesellschaft an diesen Frachtführer in den letzten zwölf Monaten liegt, und die betrug 21.750 EUR. Dann folgte die letzte Zahlung, 18.920 EUR im August für zwei Wochen Transport, alle übrigen Felder gleich und eingeklappt. Im Belegbereich lagen der Rahmenvertrag für eine neue saisonale Route und die Oktober-Buchungen an der Bestellung.

Die prüfende Person sieht in wenigen Sekunden, dass der Sprung einen Grund hat, eine neue Route, vertraglich vereinbart und gebucht, und dass sich an der Zahlung sonst nichts geändert hat.

Andere Gründe bekommen andere Vorlagen. Ist ein Empfänger für diese Gesellschaft neu, wird aber seit Jahren von einer Schwestergesellschaft bezahlt, öffnet die Vorlage mit dieser Historie, und die prüfende Person sieht eine bekannte Beziehung statt einer leeren Seite. Zahlt eine Gesellschaft in einer Währung, die sie noch nie verwendet hat, beginnt die Vorlage mit der Währung, der Kursquelle und den Währungen, in denen die Gesellschaft sonst zahlt. Zwei Gründe ergeben zwei Vorlagen. Und ließen sich die Unterlagen gar nicht zuordnen, öffnet die Vorlage auf dem, was fehlt, mit der Zahlungszeile dahinter.

Jeder Grund braucht seine eigene Vorlage, und jede ist Entwicklungsarbeit. Wir bauen zuerst Vorlagen für die Gründe hinter den meisten Stopps. Die seltenen fallen auf die Datensatzansicht zurück, deutlich als Ausweichlösung gekennzeichnet, damit niemand sie für das fertige Design hält.

Zeigen, was sich unterscheidet, nicht alles, was da ist

Nach unserer Erfahrung arbeiten Prüfende schneller und genauer, wenn sie vergleichen, als wenn sie lesen. Jede Vorlage stellt die Zahlung deshalb neben ihren nächsten Vergleichsfall, meist die zuletzt freigegebene Zahlung an denselben Empfänger aus derselben Gesellschaft, oder aus einer Schwestergesellschaft, wenn diese hier noch nie an ihn gezahlt hat. Unveränderte Felder sind eingeklappt, geänderte hervorgehoben. Ein Betrag weit außerhalb des Üblichen oder eine Währung, die die Gesellschaft noch nie benutzt hat, steht dort, wohin der Blick zuerst fällt. Es ist das, was jemandem im Treasury auf einer ausgedruckten Zahlungsliste auffallen würde, wenn die Zeit dafür da wäre.

Den Konfidenzwert des Modells zeigen wir in der Vorlage nicht. Wer eine hohe Zahl sieht, prüft tendenziell weniger genau. Die Literaturübersicht von Microsoft zu übermäßigem Vertrauen in KI (Passi und Vorvoreanu, Juni 2022) trägt Studien dazu zusammen, darunter eine, in der selbst eine nichtssagende Genauigkeitsangabe das Vertrauen der Menschen in die Antworten des Systems erhöhte. Prüfende fragen trotzdem danach. Wir nutzen den Wert dort, wo er kein Urteil verankern kann: um die Queue zu sortieren, niedrigste Werte zuerst.

Ob Sammelfreigabe erlaubt ist, hängt von den Fällen ab

Zahlungen einzeln freizugeben ist langsam, und Treasury-Teams fragen meist schon in der ersten Woche nach einem Knopf für die Sammelfreigabe. Genau dort wird die Prüfung aber leise dünner. Deshalb bietet der Bildschirm sie nicht als Funktion an; die Fälle müssen sich dafür qualifizieren.

Das tun sie, wenn sie aus demselben Grund angehalten wurden, in allen Feldern außer dem freizugebenden mit demselben Vergleichsfall übereinstimmen, dieselbe Währung haben und in einer Betragsspanne liegen, die das Treasury festgelegt hat. Zwölf Zahlungen aus drei Gesellschaften an einen Frachtführer, alle angehalten, weil die neuen Saisonpreise den Betrag über denselben Vergleichsfall gehoben haben, sind eine Entscheidung. Derselbe Frachtführer mit zwölf verschiedenen Gründen sind zwölf.

Jede Abweichung braucht einen Grund

Ändert eine prüfende Person den Vorschlag des Systems, fragt die Vorlage nach dem Grund, aus einer kurzen, mit dem Treasury abgestimmten Liste: Betrag außerhalb des Vertrags vereinbart, falsche zahlende Gesellschaft, Dublette einer früheren Zahlung, aufteilen oder verschieben, Sonstiges mit Notiz. Eine kurze Liste wird deutlich zuverlässiger ausgefüllt als ein Freitextfeld.

Im laufenden Betrieb gehören diese Gründe zu den nützlichsten Daten, die das System liefert. Sie zeigen uns, welche Halteregeln falsch sind und welche Empfängerbeziehungen sich verändern. Über ein, zwei Quartale zeigen sie auch, welche Zahlungsarten nicht mehr ohne Halt freigegeben werden sollten.

Der Prüfaufwand wird gemessen

Wir messen die Prüfung selbst: die Zeit je Vorlage, ob die Belege geöffnet wurden, wie oft der Vorschlag geändert wird und wie oft eine Freigabe später storniert oder zurückgerufen wird. Nichts davon dient dazu, Menschen zu beurteilen. Es zeigt uns, ob die Kontrolle funktioniert.

Wird an einem Prüfschritt Woche für Woche jeder Fall in wenigen Sekunden unverändert freigegeben, fügt dieser Schritt kein Urteil hinzu. Vielleicht brauchen die Fälle keinen Menschen, und eine automatische Prüfung sollte an seine Stelle treten. Oder die Vorlage zeigt nicht, was die Person braucht. Beides sind Designprobleme, und keines davon löst man, indem man die Prüfenden um mehr Sorgfalt bittet.

Vor dem Go-live bearbeiten die Prüfenden außerdem in einer Shadow-Umgebung Fälle mit bekanntem Ergebnis, darunter einige, die angehalten werden müssten. So zeigt sich, bevor echtes Geld fließt, ob die Vorlage eine falsche Antwort sichtbar macht.

Nach dem Go-live prüft eine zweite freigabeberechtigte Person im Treasury jede Woche eine kleine Zufallsstichprobe freigegebener Vorlagen erneut, ohne die erste Entscheidung zu kennen. Wo beide sich nicht einig sind, sehen wir uns zuerst die Vorlage an. Es ist das direkteste Maß, das wir gefunden haben, dafür, ob die Prüfung erkennt, wofür sie da ist.

Das Muster, auf das wir achten, sind zwei Kurven, die gemeinsam fallen: die Zeit je Vorlage und die Quote, mit der Vorschläge geändert werden. Meist heißt das, dass jemand gelernt hat, dass das System überwiegend richtig liegt, und genau dann lässt die Prüfung tendenziell nach. Sehen wir das, blendet jede zwanzigste Vorlage die vorgeschlagene Aktion aus, bis die prüfende Person selbst entschieden hat. Die Forschung nennt das eine Cognitive Forcing Function. Buçinca, Malaya und Gajos in Harvard stellten 2021 fest, dass solche Designs das übermäßige Vertrauen in KI verringerten und dass die Teilnehmenden gerade die Designs, die es am stärksten verringerten, als am unangenehmsten bewerteten. Wir nehmen beide Befunde ernst. Deshalb schaltet sich die Funktion ein, wenn die Zahlen es verlangen, statt dauerhaft zu laufen, und wir erklären dem Team, wozu sie da ist.

Die Freigabe wird dokumentiert wie jede Finanzkontrolle

Freigeben darf nie das System, das den Lauf vorbereitet hat, und nie die Person, die die Zahlung vorgeschlagen hat. Jede Freigabe wird gespeichert, mit der prüfenden Person, dem Zeitpunkt, der Vorlage genau so, wie sie angezeigt wurde, den geöffneten Belegen und dem Grund jeder Änderung. Fragt ein Wirtschaftsprüfer, wie die Kontrolle funktioniert hat, können wir zeigen, was die Person gesehen hat, und nicht nur, dass sie geklickt hat.

Aus demselben Grund bieten wir keine Freigabe per E-Mail-Antwort oder per Knopf in einem Chatfenster an. Damit fehlen der Entscheidung die Belege, und übrig bleibt nur die Unterschrift.

Der Name im Log muss etwas bedeuten

Ein Prüfschritt, bei dem niemand hinsieht, kann schlechter sein als gar keiner, denn er hinterlässt einen Nachweis, dass jemand geprüft hat. Gestalten Sie die Vorlage so, dass der Name im Audit-Log beschreibt, was tatsächlich geschehen ist.