Bestellungen durchgängig automatisieren

Die Bestellung ist der Punkt, an dem ein Unternehmen seine Ausgaben entweder kontrolliert oder den Überblick verliert. Sie durchgängig zu automatisieren, verwandelt eine Bedarfsanforderung in eine kontierte, freigegebene und budgetgeprüfte Verpflichtung, ohne dass jemand etwas neu tippen muss, und hält diese Verpflichtung dann als Referenz vor, gegen die jede nachgelagerte Rechnung und jeder Wareneingang abgeglichen wird. Machen Sie die Bestellung richtig, wird die Kreditorenbuchhaltung zur Rechenaufgabe; machen Sie sie falsch, taucht jedes Problem später auf, zum denkbar ungünstigsten Zeitpunkt.

Der meiste Schmerz im Procure-to-Pay steckt nicht in der Rechnung. Er sitzt weiter vorne, in einer Bedarfsanforderung, die auf die falsche Kostenstelle kontiert, von jemandem ohne Befugnis freigegeben oder gegen einen Lieferanten erfasst wurde, der bereits dreimal unter leicht abweichenden Namen im Stamm liegt. Bis dieser Fehler in der Kreditorenbuchhaltung ankommt, ist das Geld gebunden und die Korrektur eine manuelle Umbuchung. Die Arbeit beginnt also beim Wareneingang der Anforderung.

An der Bedarfsanforderung entscheidet sich die Kontierung

Eine Bedarfsanforderung kommt als Freitext, als Punchout-Warenkorb, als E-Mail, manchmal als Foto eines Angebots. Die Aufgabe beim Erfassen ist, daraus strukturierte Positionen zu machen, mit denen ein System arbeiten kann: was gekauft wird, von wem, gegen welches Budget, unter welcher steuerlichen Behandlung. Das ist ein Extraktions- und Klassifikationsproblem, und das Genauigkeitsziel richtet sich danach, was eine falsche Antwort nachgelagert kostet.

• Die Positionsextraktion zieht Menge, Einzelpreis, Bezeichnung und jede angegebene Lieferanten-SKU aus dem Format heraus, in dem die Anforderung ankam.
• Sachkonto, Kostenstelle und Projektschlüssel werden aus der Positionsbeschreibung sowie der Abteilung des Anfordernden und der historischen Kontierung ähnlicher Einkäufe vorhergesagt.
• Die steuerliche Behandlung leitet sich aus der Jurisdiktion des Lieferanten und der Artikelkategorie ab, denn eine Reverse-Charge-Position, die als inländische Umsatzsteuer kontiert wird, zerstört Ihre Steuererklärung, nicht nur Ihr Hauptbuch.

Wir behandeln die Kontierung als Modell mit einem Eval-Set, nicht als Nachschlagetabelle. Das Eval-Set stammt aus historisch gebuchten Bestellungen, bei denen die endgültige, korrigierte Kontierung bekannt ist, und wir messen die Genauigkeit pro Feld dagegen. Die Point-in-Time-Disziplin ist hier entscheidend: Wenn Sie die Trainings- oder Evaluierungsdaten aufbauen, verwenden Sie den Lieferantenstamm und den Budgetstand so, wie sie am Datum der Bedarfsanforderung waren, nicht so, wie sie heute sind. Andernfalls schleusen Sie künftige Korrekturen zurück ins Modell, und es sieht im Test weit besser aus, als es in der Produktion sein wird.

Bei allem, worüber sich das Modell unsicher ist, sollte es nicht raten. Ein Konfidenz-Schwellenwert leitet Positionen mit geringer Sicherheit an einen Menschen weiter, mit vorausgefüllter Vorhersage, sodass die Person bestätigt oder korrigiert, statt von Grund auf zu kontieren. Das hält das False-Positive-Budget explizit: Sie entscheiden, wie viele fehlkontierte Positionen Sie automatisch durchlassen wollen, und stellen den Schwellenwert so ein, dass er genau das trifft.

Freigabe-Routing ist eine Policy-Engine, kein Modell

Bei der Freigabe geht Automatisierung am häufigsten schief, weil die Versuchung groß ist, das Modell entscheiden zu lassen. Tun Sie es nicht. Das Modell bereitet die Entscheidung vor; eine deterministische Policy-Engine trifft sie. Freigabebefugnis, Funktionstrennung und Delegation sind Regeln, die Sie präzise formulieren können, und sie müssen jedes Mal dieselbe Antwort liefern und einer Prüfung standhalten.

Die Routing-Logik liest die kontierte Bedarfsanforderung und löst auf:

• Welche Freigabegrenzen gelten, je nach Betrag, Kategorie und Kostenstelle.
• Ob Anfordernder und Freigebender verschiedene Personen sind und ob der Freigebende die Befugnis für diese Budgetposition tatsächlich innehat.
• Welche zusätzlichen Kontrollpunkte oberhalb bestimmter Schwellen greifen, etwa eine zweite Unterschrift, eine Sourcing-Prüfung oder ein Capex-Gremium.

Jede Routing-Entscheidung schreibt einen Audit-Trail mit Lineage zurück zur Regel, die ausgelöst hat, und zum Zustand der Bedarfsanforderung in diesem Moment. Wenn ein Prüfer fragt, warum eine Bestellung über 40.000 EUR den zweiten Freigebenden übersprungen hat, antworten Sie mit einem Nachweis, nicht mit einer Rekonstruktion. Das Modell trägt bei, indem es die Bedarfsanforderung anreichert, damit die Regeln saubere Eingaben haben, und indem es Muster markiert, die einen menschlichen Blick verdienen, etwa eine Reihe von Bestellungen, die knapp unter einer Freigabegrenze liegen. Ausgaben zu splitten, um eine Schwelle zu umgehen, ist eine Kontrolle, die die Policy-Engine sichtbar machen sollte, und das kann sie nur, wenn die Kontierung weiter vorne stimmte.

Der Abgleich schließt den Kreis, und er hängt an einer sauberen Bestellung

Sobald eine Bestellung erzeugt ist, wird sie zum Anker für den Drei-Wege-Abgleich: Bestellung gegen Wareneingang gegen Rechnung. Die Qualität dieses Abgleichs entscheidet sich weiter vorne. Sind die Bestellpositionen gut strukturiert und kontiert, läuft der Abgleich nahezu im Straight-Through-Processing. Sind sie vage, wird jede Rechnung zu einer manuellen Untersuchung.

• Mengen- und Preistoleranzen werden pro Kategorie definiert, sodass eine kleine Frachtabweichung automatisch durchläuft, während eine verdoppelte Menge stoppt.
• Teillieferungen und Teilrechnungen werden gegen den offenen Bestellsaldo abgeglichen, sodass eine Bestellung mit drei Sendungen nicht drei Ausnahmen auslöst.
• Die Entity Resolution verknüpft den Lieferanten der Rechnung mit dem Lieferanten der Bestellung, selbst wenn der Zahlungsempfängername vom Bestellname abweicht, was bei factorierten oder konzernübergreifend abgerechneten Lieferanten Routine ist.

Der Abgleich speist auch die Abgrenzungen. Zum Quartalsende ist eine offene Bestellung mit gebuchtem Wareneingang und ohne Rechnung eine bekannte Verbindlichkeit, die Sie mit einer Zahl statt einer Schätzung abgrenzen können. Das gilt nur, wenn der Wareneingang gegen die richtige Bestellposition erfasst wurde. Je sauberer das Frontend, desto kleiner der manuelle Abschluss.

Worauf wir nach dem Go-live achten

Mit dem Start ist die Automatisierung nicht fertig. Kontierungsmodelle driften, wenn sich das Geschäft verändert: neue Lieferanten, neue Kategorien, eine Reorganisation, die Kostenstellen verschiebt. Wir überwachen die Kontierungsgenauigkeit pro Feld gegen eine rollierende Stichprobe menschlich korrigierter Bestellungen, und wir beobachten die Ausnahmequote beim Abgleich als Frühindikator dafür, dass sich weiter vorne etwas verschoben hat. Eine steigende Abgleich-Ausnahmequote bedeutet meist, dass sich die Kontierung der Bedarfsanforderungen schon Wochen zuvor verschlechtert hat.

Die Gewohnheit, die das gesund hält, ist, jede menschliche Korrektur als gelabeltes Beispiel zu behandeln. Wenn jemand eine vorhergesagte Kostenstelle überschreibt, fließt diese Korrektur zurück ins Eval-Set. Mit der Zeit lockern Sie den Routing-Schwellenwert in Kategorien, in denen die Genauigkeit hält, und ziehen ihn dort an, wo sie nachlässt, sodass das System genau dort mehr Autonomie übernimmt, wo die Evidenz es stützt.