Ausgabenkontrollen und Freigabe-Routing mit KI

Ein Freigabe-Workflow ist ein Routing-Problem im Kostüm einer Richtlinie. Das meiste, was eine Kette leistet, beantwortet zwei Fragen: Ist diese Anfrage unter der Ausgabenrichtlinie zulässig, und wer ist die richtige Person, um sie zu unterzeichnen. KI beherrscht beides gut, solange man sie von der einen Handlung fernhält, die sie niemals ausführen darf: die Ausgabe freizugeben. Das Modell liest und routet; ein namentlich benannter Mensch verbindlich zusagt.

Diese Unterscheidung ist das gesamte Designprinzip. Wenn jemand eine Bestellanforderung einreicht, muss ein ganzer Stapel an Entscheidungen fallen, bevor sie in einem Posteingang landet. Welche Kategorie ist das. Überschreitet sie eine Schwelle, die einen zweiten Freigeber ins Spiel bringt. Ist im Kostenstellenbudget noch etwas übrig. Ist der Lieferant onboarded und nicht auf einer Sperrliste. Hat der Anforderer überhaupt die delegierte Kompetenz, sie zu stellen. Teams beantworten diese Fragen heute von Hand, und genau deshalb kann eine Bestellung für einen Laptop im Wert von 4.000 Euro sechs Tage lang bei jemandem liegen bleiben, der von Anfang an gar nicht der richtige Freigeber war.

Wo die Kontrollen tatsächlich sitzen

Ausgabenkontrollen sind nicht eine einzelne Regel. Sie sind ein geschichtetes Regelwerk, und jede Schicht hat einen anderen Verantwortlichen und einen anderen Fehlermodus. Bevor wir irgendetwas automatisieren, trennen wir sie, denn sie in einen einzigen Modellaufruf zusammenzupressen ist der sichere Weg zu einem System, das niemand mehr prüfen kann.

• Berechtigung: Darf dieser Anforderer diese Art von Anfrage überhaupt stellen. Das ist die Kompetenzdelegation, und sie gehört in eine Matrix, die nach Rolle, Kostenstelle und Betragsband aufgeschlüsselt ist.
• Kategorisierung: Was wird eingekauft. Das steuert alles Nachgelagerte, und es ist die Schicht, in der sich ein Modell seinen Wert verdient, weil Freitext-Anforderungen unordentlich sind.
• Schwellen und Eskalation: Wie viele Unterschriften, und wessen. Eine Softwareverlängerung über 900 Euro und eine über 90.000 Euro folgen unterschiedlichen Pfaden, selbst wenn die Kategorie identisch ist.
• Budget und Obligo: Ist noch Geld da, wobei bereits gegen die Position gebuchte offene Bestellungen mitgezählt werden, nicht nur die verbuchten Ist-Werte.
• Lieferanten- und Compliance-Status: onboarded, steuerlich validiert, nicht sanktioniert, nicht auf einer Zahlungssperre.

Das Modell greift stark in die Kategorisierung ein, leicht in Berechtigung und Schwellen, und in Budget und Lieferantenstatus überhaupt nicht. Diese letzten beiden sind deterministische Abfragen gegen das ERP und den Lieferantenstamm. Man möchte nicht, dass ein Sprachmodell das Restbudget schätzt. Man möchte, dass es die Anforderung liest, die Kategorie und das wahrscheinliche Betragsband bestimmt und dann harte Abfragen die Arithmetik erledigen lässt.

Routing, das aus versionierten Daten liest

Der althergebrachte Weg, eine Kette zu bauen, ist ein Flussdiagramm, das fest ins Beschaffungssystem einkodiert ist. Das funktioniert, bis sich die Organisation ändert, und dann verrottet es. Jemand geht, eine Schwelle verschiebt sich, eine neue Rechtseinheit kommt hinzu, und das Flussdiagramm lügt drei Wochen lang, bevor überhaupt jemand eine stockende Warteschlange bemerkt.

Wir modellieren das Routing stattdessen als Daten. Die Kompetenzmatrix, die Berichtslinien und die Schwellentabelle sind versionierte Datensätze mit Gültigkeitsdaten. Der Router liest die Version, die zum Zeitpunkt der Anfrageeinreichung aktiv war, und heftet sich an sie. Das ist entscheidend für die Point-in-Time-Korrektheit: Eine Freigabe, die im März stattfand, muss anhand der Richtlinie vom März erklärbar sein, nicht anhand der vom Juli. Wenn ein Prüfer fragt, warum eine Anfrage an einen bestimmten VP ging, ist die Antwort eine Matrix-Version und eine Zeile, keine Mutmaßung darüber, was der Code an jenem Tag getan hat.

Das Klassifizierungsmodell sitzt davor. Es liest den Anforderungstext, ein etwaig angehängtes Angebot und den Kontext des Anforderers und erzeugt daraus eine Kategorie, ein Betragsband und einen Konfidenzwert. Niedrige Konfidenz fällt nicht in den offenen Zustand. Sie wird auf den strengeren Pfad geroutet und zur Prüfung markiert, denn die Kosten einer unnötigen zweiten Freigabe sind Minuten, und die Kosten einer versäumten sind eine Kontrolllücke. Das ist ein bewusstes Falsch-Positiv-Budget: Wir akzeptieren eine gewisse Über-Eskalation, um die Unter-Eskalation nahe null zu halten.

Ein paar Dinge, auf die wir in der Routing-Schicht bestehen:

• Jede Entscheidung schreibt einen vollständigen Datensatz: Eingabe, Matrix-Version, Kategorie, Konfidenz, gewählter Freigeber und Begründung. Das ist der Audit-Trail, und er wird geschrieben, bevor die Benachrichtigung rausgeht, nicht später rekonstruiert.
• Entity Resolution läuft auf der Identität von Anforderer und Freigeber, damit eine Reorganisation oder eine Namensgleichheit nicht zu Fehlroutings führt. Menschen wechseln Teams; der Router schlüsselt auf stabile Kennungen auf, nicht auf Anzeigenamen.
• Laufende Anfragen halten ihre Matrix-Version. Eine Richtlinienänderung sollte niemals stillschweigend etwas umleiten, das bereits durch die Kette wandert.

Durchsetzung, ohne das Geschäft auszubremsen

Der Fehler, in den die meisten Ausgabenkontroll-Projekte laufen, sind nicht schwache Kontrollen. Es sind Kontrollen, die so starr sind, dass das Geschäft sie umgeht, was schlimmer ist als gar keine, weil der Schattenprozess nun unsichtbar ist. Der Sinn der Routing-Automatisierung besteht darin, den regelkonformen Pfad zum schnellen zu machen.

Straight-Through Processing ist das Ziel für die risikoarme Mehrheit. Eine Anfrage unter der Schwelle, im Budget, von einem berechtigten Anforderer, gegen einen onboardeten Lieferanten, in einer sauberen Kategorie, braucht über die eine erforderliche Unterschrift hinaus überhaupt keinen Menschen, der sie liest. Wir messen, welcher Anteil ohne Warteschlange durchläuft, und behandeln diese Zahl als Gesundheitsmetrik. Wenn sie sinkt, ist irgendwo weiter oben etwas verrutscht: eine Kategorie, die das Modell falsch zu behandeln begann, ein Lieferantenstamm, der veraltet ist, eine Schwelle, die für die normalen Ausgaben eines Teams zu eng gesetzt wurde.

Die Durchsetzung konzentriert dann die menschliche Aufmerksamkeit dorthin, wo sie hingehört. Die auftauchenden Ausnahmen sind jene, die tatsächlich Urteilsvermögen brauchen: ein Lieferant außerhalb des Rahmenvertrags, ein Betrag, der spät im Freigabeprozess ins nächste Band gesprungen ist, eine Aufteilung, die so aussieht, als würde sie eine Schwelle umgehen. Auf Letzteres achten wir besonders. Zwei Bestellungen über je 9.000 Euro an denselben Lieferanten in derselben Woche, wenn die Schwelle bei 10.000 Euro liegt, sind ein Muster, das der Router markieren kann, obwohl jede Anfrage für sich genommen sauber ist. Um es zu erkennen, braucht es die Obligo-Historie, nicht die einzelne Anfrage, und genau deshalb liest das Routing den Zustand aus, statt jede Anforderung isoliert zu behandeln.

Nichts davon entfernt den Freigeber. Es entfernt die sechs Tage, in denen die Anfrage am falschen Ort liegt. Wer unterzeichnet, unterzeichnet weiterhin, trägt weiterhin die Entscheidung und tut es nun anhand einer Anfrage, die korrekt kategorisiert, korrekt geroutet und mit bereits geprüftem Budget- und Lieferantenstatus ankommt, mit einem Protokoll jedes einzelnen Schritts dahinter.