Working Capital mit ML zu optimieren heißt, pro Rechnung, Kunde oder SKU vorherzusagen, wann Cash tatsächlich fließt – und dann vor Quartalsende danach zu handeln, statt die Lücke im Nachhinein zu erklären. Die Modelle sitzen auf Forderungen, Verbindlichkeiten und Beständen. Ziel ist ein kürzerer Cash Conversion Cycle, der Sie weder einen Lieferanten noch einen Stockout kostet.
Die meisten Treasury-Dashboards berichten den Cash Conversion Cycle als drei Durchschnittswerte: Days Sales Outstanding, Days Payable Outstanding, Days Inventory on Hand. In den Durchschnitten versteckt sich das Geld. Ein DSO von 47 Tagen kann bedeuten, dass alle am Tag 47 zahlen – oder dass 70 % am Tag 30 zahlen und ein langer Zahlungsausläufer den Mittelwert nach oben zieht. Diese beiden Welten brauchen unterschiedliche Interventionen, und die Kennzahl allein verrät Ihnen nicht, in welcher Sie sich befinden. Modellieren Sie also die Verteilung pro Kontrahent und pro Position. Die aggregierte Zahl kann das nicht.
DSO dort modellieren, wo die Labels ehrlich sind
Forderungen sind der richtige Startpunkt, weil das Label eindeutig ist. Eine Rechnung wird an einem Datum ausgestellt, das Cash geht an einem Datum ein, und die Differenz ist genau das, was Sie vorhersagen. Diese Klarheit ist im Finance-ML selten, und Sie sollten sie ausnutzen.
Die Falle ist Leakage. Der mit Abstand häufigste Bug, den wir in einem DSO-Modell finden, ist ein Feature, das klammheimlich genau die Zahlung kodiert, die es vorhersagen soll. Jemand joint das aktuelle Kreditlimit des Kunden hinein – das gekürzt wurde, nachdem die Rechnung unbezahlt blieb. Oder ein Streitfall-Flag, das während des Inkassos gesetzt wurde. Oder ein Cleared-Date-Feld, das null bleibt, bis das Cash eintrifft, und dann plötzlich nicht mehr. Jedes davon verwandelt einen Out-of-Sample-Test in eine Auswendiglern-Übung, und das Modell sieht brillant aus – bis es auf eine echte, laufende Rechnung trifft.
Point-in-time-Korrektheit ist die Disziplin, die das behebt. Jedes Feature muss so rekonstruiert werden, wie es zum Rechnungsdatum bekannt war:
- Zahlungshistorie dieses Kunden, abgeschnitten auf die zu diesem Zeitpunkt bereits ausgeglichenen Rechnungen.
- Die an diesem Datum geltenden Zahlungsbedingungen – nicht die heutigen.
- Offener Saldo und Fälligkeitsbucket zum Ausstellungszeitpunkt, berechnet aus dem As-of-Nebenbuch statt aus dem aktuellen.
- Saisonalitäts- und Kalender-Features, die unbedenklich sind, weil sie im Voraus bekannt sind.
Bauen Sie den Trainingsdatensatz aus einem Feature Store, der diese As-of-Snapshots vorhält, und Ihre Eval-Zahlen beginnen etwas zu bedeuten. Der Output, auf den es dann ankommt, ist eine Zahlungsdatum-Verteilung pro Rechnung – kein einzelner Punktschätzer. Diese Form treibt zwei Entscheidungen: welche Konten im Inkasso priorisiert werden, und welchen Anteil des Forderungsbestands man in der Prognose als verlässliches kurzfristiges Cash behandeln darf.
Verbindlichkeiten und die Disziplin, die man wirklich will
DPO ist verlockend zu maximieren und gefährlich, wenn man es naiv optimiert. Jeden Lieferanten bis ans vertragliche Limit zu strecken sieht aus wie kostenlose Finanzierung – genau bis ein kritischer Lieferant die Konditionen verschärft oder Sie in seiner Allokationsliste nach unten setzt. Die Modellierungsfrage lautet also: Welche Zahlungszeitpunkte kosten in der Beziehung nichts, und welche kosten still und leise eine Menge?
Wir modellieren Verbindlichkeiten als eine Menge von Constraints statt als ein Ziel, das man nach oben drückt. Für jeden Lieferanten: die vertraglichen Konditionen, jeglicher Skonto bei früher Zahlung, die beobachtete Toleranz für verspätete Zahlung und das strategische Gewicht der Beziehung. Die Optimierung plant Zahlungen so, dass das Cash so lange gehalten wird, wie die Constraints es erlauben, und Skonti nur dort mitgenommen werden, wo die implizite annualisierte Rendite die Kosten des Cash schlägt. Genau bei diesem Vergleich verlieren Finance-Teams in beide Richtungen Geld. Sie zahlen früh für einen trivialen Rabatt – oder sie verpassen ein 2/10 net 30, das sich auf rund 37 % annualisiert, deutlich über den meisten Kapitalkosten.
Bestände sind ein Prognoseproblem im Working-Capital-Kostüm
Bestände sind das schwierigste der drei, weil das Label umstritten ist. Das im Lager gebundene Cash ist real und messbar. Wie hoch dieser Bestand hätte sein sollen, ist ein Kontrafaktum, das von einer Nachfrageprognose abhängt – und Nachfrageprognosen liegen auf strukturierte Weise daneben.
Der Modellstack besteht hier aus einem Nachfragemodell pro SKU-Standort, einem Lead-Time-Modell für die Wiederbeschaffung und einem Service-Level-Ziel, das das Management setzt. Der Working-Capital-Hebel ist der Sicherheitsbestand – der Puffer, der gegen Nachfrage- und Lead-Time-Varianz gehalten wird. Überschätzen Sie die Varianz, frieren Sie Cash in einem Lager ein. Unterschätzen Sie sie, kommt es zum Stockout – ein Umsatzproblem, das der Vertrieb immer schwerer gewichten wird als die Lagerhaltungskosten. Das False-Positive-Budget ist hier asymmetrisch und politisch, also machen Sie diesen Trade-off explizit, statt ihn stillschweigend von einer Loss-Funktion entscheiden zu lassen.
Ein paar Grundsätze, an denen wir bei Bestandsmodellen festhalten:
- Fitten Sie die Nachfrageverteilung, nicht nur den Mittelwert. Der Sicherheitsbestand ist eine Funktion der Varianz, deshalb dimensioniert ein Modell, das die Durchschnittsnachfrage trifft, aber deren Streuung verfehlt, die Puffer falsch.
- Modellieren Sie auch die Lead Time als Verteilung. Die Lead-Time-Varianz des Lieferanten dominiert in der Sicherheitsbestandsrechnung oft die Nachfragevarianz – und ist genau der Teil, den Teams am häufigsten als Konstante behandeln.
- Achten Sie nach jeder Sortiments- oder Lieferantenänderung auf Drift. Ein auf den Lead Times des Vorjahres trainiertes Modell dimensioniert die Puffer falsch, sobald sich eine Route ändert – und niemand merkt es, bis der Bestandsbericht schief aussieht.
Damit die Zahlen ein Audit überstehen
Nichts davon ist viel wert, wenn der Treasurer eine Freed-Cash-Zahl nicht zu ihren Inputs zurückverfolgen kann. Jede Vorhersage, die ein Zahlungsdatum oder ein Bestandsniveau verschiebt, braucht Lineage: welche Rechnung, welche Features, welche Modellversion, welcher Snapshot. Wenn das Quartalsende kommt und jemand fragt, warum sich der DSO um vier Tage bewegt hat, muss die Antwort aus dem Datensatz rekonstruierbar sein – nicht aus einem Dashboard zurückentwickelt.
Zwei Praktiken sorgen dafür, dass das hält. Führen Sie ein Eval-Set aus abgewickelten Rechnungen und abgeschlossenen Bestandszyklen, aktualisieren Sie es, sobald neue Labels eintreffen, und berichten Sie das Modell in festem Takt dagegen, sodass Drift als Zahl auftaucht statt als Überraschung. Gleichen Sie anschließend die Cash-Vorhersagen des Modells gegen das Hauptbuch ab, damit die Working-Capital-Geschichte, die die Modelle erzählen, zur Geschichte passt, die die Bücher erzählen. Wenn die beiden auseinanderlaufen, ist genau diese Divergenz das nützlichste Signal, das Sie haben.
Häufige Fragen
Lässt sich Working Capital ohne neue Quellsysteme optimieren?
Meistens ja. Der Großteil des Signals steckt bereits im ERP, im Debitoren-Nebenbuch und im WMS. Die Arbeit besteht darin, diese Feeds auf einen Point-in-time-Zustand abzugleichen und Kunden sowie SKUs zu stabilen Entitäten aufzulösen – nicht darin, neue Tools zu kaufen.
Wie vermeidet man Lookahead, wenn man auf Zahlungsdaten von Rechnungen trainiert?
Jedes Feature so als Snapshot festhalten, wie es zum Rechnungsdatum bekannt war – niemals zum späteren Zahlungsdatum. Ausgeglichene Zahlungsfelder, im Nachhinein angepasste Kreditlimits und nachträglich gesetzte Streitfall-Flags sind die üblichen Leakage-Vektoren. Deshalb bauen wir den Trainingsdatensatz aus As-of-Datensätzen statt aus dem aktuellen Tabellenzustand.
Was ist ein realistisches erstes Ziel: DSO, DPO oder Bestände?
DSO auf Forderungen, weil die Labels am saubersten sind und die Feedback-Schleife kurz ist. Die Tage zwischen Rechnung und Zahlungseingang werden direkt beobachtet, sodass man Eval-Sets aufbauen und Drift schnell messen kann, bevor man die Bestände anfasst – wo Nachfrageannahmen die Attribution erschweren.