Die meisten Cashflow-Prognoseprojekte wählen zuerst das Modell und zuletzt die Fragestellung. Jemand wünscht sich „eine bessere Prognose”, ein Data Scientist greift zu einem Gradient-Boosting-Modell oder einem LSTM, und sechs Wochen später existiert eine Kurve, die das Vorjahr gut abbildet und niemandem hilft. Die Prognose war nie an eine Entscheidung gekoppelt, also hat ihre Genauigkeit keinen Bezugspunkt.
Beginnen Sie stattdessen bei der Entscheidung. Ein Treasurer, der abwägt, ob er kommende Woche eine Kreditlinie ziehen soll, benötigt einen 13-Wochen-Horizont und legt großen Wert auf das Abwärtsrisiko. Ein FP&A-Team, das einen Liquiditätspuffer zum Quartalsende festlegt, braucht einen anderen Horizont und eine andere Fehlertoleranz. Das sind nicht dieselben Prognosen, und sie rechtfertigen nicht denselben maschinellen Aufwand. Zu wissen, welche Entscheidung die Zahl speist, sagt Ihnen den Horizont, die Taktung und wie weit Sie danebenliegen dürfen, bevor jemand auf Basis einer schlechten Zahl handelt.
Merkmale aus dem aufbauen, was bereits geschehen ist
Das nützliche Signal in Cashflow-Prognosen steckt meist in Transaktionsdaten, die Sie ohnehin schon besitzen. Die Altersstruktur von Verbindlichkeiten und Forderungen, Zahlungsbedingungen je Geschäftspartner, die tatsächlichen Zahlungseingänge gegenüber den Rechnungsdaten, Lohn- und Gehaltsläufe, Steuer- und Umsatzsteuerzyklen. Darin steckt Struktur. Ein Großkunde, der jedes Quartal am Tag 47 zahlt, ist ein Merkmal, kein Rauschen.
Konstruieren Sie Merkmale aus dieser Historie mit derselben Point-in-Time-Korrektheit, die Sie auch von einem Backtest verlangen würden. Der mit Abstand häufigste Fehler bei ML-Prognosen ist hier das Lookahead-Leakage: das Training auf einer abgestimmten, monatlich abgeschlossenen Sicht auf die Liquidität, die zum Prognosezeitpunkt noch gar nicht verfügbar war. Wenn Ihre Merkmale klammheimlich Zahlen enthalten, die erst nach dem Buchungsabschluss existierten, sieht Ihr Backtest hervorragend aus und Ihre Live-Prognose enttäuscht. Bauen Sie den Merkmalssatz so auf, wie er sich am jeweiligen Tag darstellte, mit den verspätet eintreffenden Posten noch fehlend – sonst lernt das Modell, sich auf Informationen zu verlassen, die es im Produktivbetrieb nie haben wird.
Saisonale Strukturen sollten Sie explizit kodieren, statt zu hoffen, dass das Modell sie selbst erschließt:
- Kalendereffekte: Quartalsende, Monatsende, Gehaltstermine, gesetzliche Steuerfristen
- Zahlungsverhalten von Geschäftspartnern, einschließlich derjenigen, die zuverlässig zu spät zahlen
- Bekannte, wiederkehrende Einmaleffekte wie jährliche Lizenzverlängerungen oder Bonusläufe
Schlagen Sie die einfache Methode, bevor Sie zur komplexen greifen
Bauen Sie vor all dem die langweilige Baseline. Eine saisonale naive Prognose, einen gleitenden Durchschnitt oder die bestehende Tabelle des Treasury-Teams. Und dann messen Sie ehrlich dagegen. Ein überraschend großer Teil der Treasury-Analytics-Arbeit endet genau hier, denn eine gut abgestimmte Baseline ist auf kurzen Horizonten schwer zu schlagen, und der marginale Genauigkeitsgewinn eines schwergewichtigen Modells wiegt den Aufwand seines Betriebs nicht auf.
Wir haben dazu eine klare Meinung. Ein Modell, das Sie der Person, die sich darauf verlässt, nicht erklären können, das ständiges Nachtrainieren braucht und die Tabelle um zwei Prozent schlägt, ist kein Fortschritt. Es ist eine Wartungslast mit gutem Marketing. Greifen Sie erst dann zum komplexen Modell, wenn das einfache erkennbar Geld auf dem Tisch liegen lässt – und wenn Sie zeigen können, woher die zusätzliche Genauigkeit kommt.
Backtesten Sie so, wie die Prognose später tatsächlich laufen wird. Verwenden Sie eine Walk-forward-Evaluation, die bis zu jedem Prognosezeitpunkt auf den verfügbaren Daten nachtrainiert und dann nach vorne prognostiziert, statt eines einzelnen zufälligen Splits. Bewerten Sie auf dem Horizont, der für die Entscheidung zählt, nicht auf einem Durchschnitt über alle Horizonte, der schwache Leistung genau dort verschleiert, wo es darauf ankommt.
Kommunizieren Sie die Bandbreite – und beobachten Sie dann, wie sie sich bewegt
Ein Treasurer kann nicht auf Basis einer einzelnen Zahl handeln, die Gewissheit vorgaukelt. Cashflows sind sprunghaft und werden teils von Geschäftspartnern getrieben, die Sie nicht steuern. Prognoseunsicherheit ist daher Information, kein Versagen, das es zu verbergen gilt. Erzeugen Sie eine Verteilung oder eine Reihe von Quantilen und rahmen Sie diese in den Begriffen des Treasurers: die Wahrscheinlichkeit, einen Mindestbestand zu unterschreiten, die Höhe des Puffers, der die meisten plausiblen Wochen abdeckt. Eine Bandbreite, über die jemand gestritten hat, schlägt eine Punktschätzung, die niemand hinterfragt hat.
Und dann bleiben Sie wachsam. Zahlungsverhalten verschiebt sich, ein Großkunde ändert seine Konditionen, Zinsen bewegen sich, eine Rezession lässt die Forderungen schrumpfen. Ein auf die Bedingungen des Vorjahres abgestimmtes Modell verschlechtert sich leise, und das erste Anzeichen ist meist ein Treasurer, der der Zahl nicht mehr traut. Überwachen Sie den Live-Fehler gegenüber dem im Backtest gemessenen Fehler, verfolgen Sie, ob die Ist-Werte weiterhin innerhalb Ihrer angegebenen Bandbreite landen, und definieren Sie einen Schwellenwert, der ein Nachtrainieren oder eine Überprüfung auslöst. Behandeln Sie das Monitoring als Teil des Aufbaus, nicht als Nachgedanken, sobald das Modell im Produktivbetrieb ist.
Nichts davon ist exotisch. Es geht darum, die Prognose um eine echte Entscheidung herum zu rahmen, im Backtest ehrlich zu sein und klar zu benennen, was man nicht weiß. Darin liegt der größte Teil des Werts – und die meisten Teams überspringen genau das, um zum Modell zu gelangen.