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

Vierzig Freigaben in gut drei Minuten. Wir saßen neben einer Controllerin, während sie morgens die Queue eines neuen Rechnungs-Workflows abarbeitete, und fragten sie anschließend, was sie bei jedem Posten geprüft hatte. Sie überlegte kurz und antwortete ehrlich: den Betrag und ob ihr der Name des Lieferanten bekannt vorkam.

Nachlässig war sie nicht. Der Bildschirm zeigte das vollständige Rechnungsbild, zwanzig ausgelesene Felder, die vorgeschlagene Kontierung und einen Freigabeknopf. Nichts verriet ihr, warum ein Posten überhaupt bei ihr gelandet war, also prüfte sie, was sich schnell prüfen ließ. Im Audit-Log standen vierzig Freigaben durch eine namentlich genannte Controllerin. Tatsächlich hatte das Modell vierzig Rechnungen freigegeben, und ein Mensch hatte seinen Namen daruntergesetzt.

Palantir beschreibt in „Connecting Agents to Decisions“ (April 2026) das Muster, auf dem heute die meisten Plattformen beruhen: Eine KI bereitet eine Aktion vor, und ein Mensch führt sie verbindlich aus. Ob das trägt, entscheidet sich im Moment dazwischen: 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 Freigabebildschirm, der den gesamten Datensatz zeigt, überlässt es dem Prüfer, das Problem zu finden. Genau das hätte aber das System leisten sollen. Wir ersetzen die Datensatzansicht deshalb durch eine Entscheidungsvorlage, die sich um eine einzige Frage dreht.

Die Vorlage beginnt mit einer Zeile, die die anstehende Entscheidung benennt und sagt, warum der Fall angehalten wurde: „Preis in Position 3 liegt über dem Vertragspreis für diesen Lieferanten.“ Darunter stehen nebeneinander das Feld, das die Prüfung ausgelöst hat, der tatsächliche und der erwartete Wert. Dann folgen die Belege, und zwar nur zu diesem Punkt: die Vertragsklausel, die Bestellposition, die letzten drei Rechnungen des Lieferanten für diesen Artikel. Der vollständige Datensatz ist einen Klick entfernt, steht aber nicht an erster Stelle.

Wurde ein Fall aus zwei Gründen angehalten, gibt es zwei Vorlagen. Wurde er angehalten, weil ein Beleg nicht lesbar war, zeigt die Vorlage die unlesbare Stelle, nicht die ganze Seite.

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

Prüfer arbeiten schneller und genauer, wenn sie vergleichen, als wenn sie lesen. Jede Vorlage stellt den Fall deshalb seinem nächsten Vergleichsfall gegenüber: dem zuletzt freigegebenen Fall desselben Lieferanten mit derselben Belegart. Unveränderte Felder sind eingeklappt, geänderte hervorgehoben. Eine neue Bankverbindung, eine neue Mengeneinheit, ein veränderter Preis: Was einer Controllerin auf Papier auffallen würde, wenn sie Zeit hätte, steht dort, wohin ihr Blick zuerst fällt.

Den Konfidenzwert des Modells zeigen wir in der Vorlage nicht. Wer eine hohe Zahl sieht, prüft weniger genau.

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

Einzelfreigaben sind langsam, und Controller fragen spätestens in der ersten Woche nach einem Knopf für die Sammelfreigabe. Bei Sammelfreigaben hört die Prüfung unbemerkt auf. Deshalb bietet der Bildschirm sie nicht pauschal an. Die Fälle müssen die Voraussetzungen dafür erfüllen.

Fälle lassen sich nur dann gemeinsam freigeben, wenn sie aus demselben Grund angehalten wurden, in allen Feldern außer dem freizugebenden mit demselben Vergleichsfall übereinstimmen und in einer Betragsspanne liegen, die die Controllerin festgelegt hat. Zehn Rechnungen eines Lieferanten mit derselben Preiserhöhung gegenüber demselben Vertrag sind eine Entscheidung. Derselbe Lieferant mit zehn verschiedenen Gründen sind zehn Entscheidungen.

Jede Abweichung braucht einen Grund

Ändert ein Prüfer die vorgeschlagene Aktion, fragt die Vorlage nach dem Grund, ausgewählt aus einer kurzen, mit dem Finanzbereich abgestimmten Liste: falsche Kontierung, Preis abweichend vom Vertrag vereinbart, Dublette, Fehler des Lieferanten, Sonstiges mit Notiz. Ein Freitextfeld wird ignoriert. Eine kurze Liste wird genutzt.

Diese Gründe sind die wertvollsten Daten, die das System nach dem Go-live liefert. Sie zeigen, welche Regeln falsch sind, bei welchen Lieferanten sich etwas verändert und welchen Segmenten die Dunkelverarbeitung wieder entzogen werden sollte.

Der Prüfaufwand wird gemessen

Wir messen die Prüfung selbst: die Zeit je Vorlage, ob die Belege geöffnet wurden, wie oft die vorgeschlagene Aktion geändert wird und wie oft eine Freigabe später zurückgenommen wird. Nichts davon dient dazu, Menschen zu beurteilen. Es dient dazu, die Kontrolle zu beurteilen.

Ein Prüfschritt, bei dem Woche für Woche jeder Fall in wenigen Sekunden unverändert freigegeben wird, fügt kein Urteil hinzu. Entweder brauchen die Fälle keinen Menschen, dann sollte an seine Stelle eine automatische Prüfung treten. Oder die Vorlage zeigt nicht, was der Mensch braucht. Beides sind Designprobleme, und keines davon löst man, indem man die Prüfer um mehr Sorgfalt bittet.

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

Die Freigabe wird dokumentiert wie jede Finanzkontrolle

Freigeben darf nie das System, das den Fall vorbereitet hat, und bei Zahlungen und Kreditorenstammdaten nie die Person, die die Änderung beantragt hat. Jede Freigabe wird gespeichert, mit Prüfer, Zeitpunkt, der Vorlage in der angezeigten Form, den geöffneten Belegen und dem Grund jeder Änderung. Fragt ein Wirtschaftsprüfer, wie die Kontrolle funktioniert hat, lautet die Antwort, was der Prüfer gesehen hat, und nicht nur, dass er geklickt hat.

Aus demselben Grund bieten wir keine Freigabe per E-Mail-Antwort oder Chat-Button 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, ist schlechter als gar keiner, denn er erzeugt einen Nachweis, dass jemand geprüft hat. Gestalten Sie die Vorlage so, dass der Name im Audit-Log beschreibt, was tatsächlich geschehen ist.