KI im Treasury: Wo LLMs SAP-Forecasts schlagen und wo nicht

Warum CFOs im Mittelstand jetzt über KI im Treasury nachdenken

Die Zinswende hat eine Zahl wieder in den Vordergrund geschoben, die zehn Jahre lang niemanden interessiert hat: die Kosten des Liquiditätspuffers. Wer früher 5 Millionen Euro auf dem Girokonto liegen hatte, hat dafür nichts bezahlt. Heute kostet das im Mittelstand schnell 150.000 bis 200.000 Euro pro Jahr an entgangenem Termingeld-Ertrag. Gleichzeitig sind Forecasting-Fehler in die andere Richtung schmerzhafter geworden. Eine unerwartete Lücke wird nicht mehr mit einem Zwei-Prozent-Kontokorrent überbrückt, sondern mit sechs bis acht Prozent.

Für CFOs im DACH-Mittelstand bedeutet das: Cash-Flow-Forecasting ist plötzlich wieder eine Disziplin, in der Präzision Geld kostet oder spart. Und genau in diesem Moment steht KI vor der Tür und verspricht bessere Prognosen.

Bevor wir über Lösungen reden, eine Begriffsklärung. Wenn in Vorstandspräsentationen heute von „KI im Treasury" die Rede ist, sind in der Regel zwei sehr unterschiedliche Dinge gemeint:

• Klassische ML-Zeitreihenmodelle wie ARIMA, Prophet oder Gradient-Boosting auf historischen Buchungsdaten. Das ist seit zehn Jahren in SAP Analytics Cloud, Oracle Hyperion oder Anaplan implementiert.
• Large Language Models wie GPT-4, Claude oder Mistral, die unstrukturierten Text verarbeiten und in Treasury-Kontexten erst seit etwa 18 Monaten ernsthaft pilotiert werden.

Das sind zwei verschiedene Werkzeuge für zwei verschiedene Probleme. Wer sie verwechselt, bekommt entweder enttäuschende Pilot-Ergebnisse oder bezahlt für Komplexität, die er nicht braucht.

Klassisches ERP-Forecasting: Stärken, die man nicht unterschätzen sollte

Der Reflex in jeder Beratungspräsentation ist heute, das bestehende SAP- oder Oracle-Setup als überholt darzustellen. Das ist in den meisten Fällen falsch.

Strukturierte Zeitreihen sind das Heimspiel klassischer ERP-Forecasts. Lohnauszahlungen am 25. des Monats, Umsatzsteuer-Vorauszahlungen am 15., Pacht-Daueraufträge am Monatsersten, saisonale Umsatzspitzen im Q4, Lieferanten-Skonti mit fixen Zahlungszielen. All das sind Muster, die ein ARIMA-Modell oder ein Prophet-Forecast auf drei Jahren sauberer Buchungsdaten erschreckend gut abbildet. Die Mean Absolute Percentage Error liegt bei stabilen Geschäftsmodellen routinemäßig unter fünf Prozent für 30-Tage-Horizonte.

Dazu kommt ein Argument, das in der KI-Euphorie gerne übersehen wird: Erklärbarkeit. Wenn der Wirtschaftsprüfer im Rahmen der Going-Concern-Beurteilung fragt, warum der Forecast für Februar einen Liquiditätsengpass zeigt, kann der Treasurer auf konkrete Posten zeigen: drei Großkunden mit historisch verzögertem Zahlungsverhalten, eine fällige Anleihe-Tilgung, saisonal niedriger Auftragseingang. Das ist auditfähig. Banken verstehen es, weil sie selbst mit denselben Modellen arbeiten. Steuerberater können es nachvollziehen.

Ein LLM, das dieselbe Aussage trifft, muss sich erst beweisen.

Konkret: Wenn Ihre Zahlungsströme zu mindestens 70 Prozent aus wiederkehrenden, terminierten Posten bestehen, und Ihre historischen Daten drei oder mehr saubere Jahre umfassen, reicht ein klassisches Zeitreihenmodell in SAP Analytics Cloud oder einem vergleichbaren Tool. Punkt. Den LLM-Layer brauchen Sie für die restlichen 30 Prozent.

Wo LLMs im Cash-Flow-Forecasting echten Mehrwert liefern

Die restlichen 30 Prozent sind allerdings genau jene Posten, die in der Praxis Forecasting-Fehler verursachen. Und hier liegt der eigentliche Use-Case für LLMs.

Unstrukturierte Signale auswerten. In jedem mittelständischen Unternehmen liegen Informationen über zukünftige Zahlungsströme nicht im ERP, sondern in E-Mails, CRM-Notizen, Auftragskommentaren und Mahnhistorien. „Der Kunde hat angerufen, zahlt diesen Monat verspätet wegen interner Umstellung." „Auftragsbestätigung mit Zusatzposition über 80.000 Euro, Liefertermin Q3." Diese Informationen verändern den Forecast erheblich, kommen aber bei klassischen Zeitreihenmodellen nie an. Ein LLM kann sie lesen, klassifizieren und an die numerische Prognose koppeln.

Szenario-Sprache. Der Klassiker im Treasury-Meeting: „Was passiert mit unserer Liquidität, wenn Kunde X 30 Tage später zahlt und gleichzeitig der USD-Kurs um fünf Prozent fällt?" Heute beantwortet das ein Treasury-Analyst in zwei Stunden Excel-Arbeit. Mit einem gut angebundenen LLM-Layer ist die Antwort in 30 Sekunden da, inklusive Sensitivitätsanalyse. Das ist kein revolutionärer Use-Case, aber er entlastet das Team spürbar.

Anomalie-Erkennung in Freitext-Buchungsdaten. Doppelzahlungen, unklare Verrechnungen, falsch zugeordnete Eingangsrechnungen. Klassische Regelsysteme finden das nur, wenn jemand die Regel vorher definiert hat. Ein LLM, das auf Buchungstexten trainiert ist, erkennt Auffälligkeiten auch dort, wo niemand sie erwartet hat.

Synthese externer Signale. Branchennews, Lieferanten-Ratings, Makro-Indikatoren, Schiedsgerichts-Entscheidungen. Klassische Modelle können das nicht lesen. LLMs können. Wenn der wichtigste Lieferant eines Maschinenbauers in der FAZ als Insolvenz-Kandidat erwähnt wird, ist das ein Forecast-relevantes Signal. Heute landet es bei niemandem strukturiert auf dem Tisch.

Wo LLMs scheitern: ehrliche Grenzen für den Mittelstand

Jetzt der unbequeme Teil. LLMs haben in vier Bereichen strukturelle Schwächen, die im Treasury-Kontext besonders wehtun.

Saisonale Cash-Patterns kommen nicht aus Text. Ein LLM weiß nicht von sich aus, dass im Dezember Jahresschluss-Rabatte fällig werden, dass im August die Urlaubsauszahlungen den Personalkosten-Block aufblähen, dass Q1 für Bauzulieferer traditionell schwach ist. Es sei denn, man gibt es ihm explizit als Kontext mit. Damit wird der LLM-Forecast zur aufwendigeren Variante dessen, was die Zeitreihe ohnehin besser kann.

Halluzinations-Risiko bei konkreten Zahlen. Das ist der gefährlichste Punkt. LLMs sind sprachlich präzise, aber numerisch unzuverlässig. Wenn Sie ein Modell direkt fragen „Wie hoch ist mein erwarteter Cash-Inflow im März?", bekommen Sie eine Zahl, die plausibel klingt und falsch sein kann. Im Finanzkontext ist das katastrophal. Die einzig saubere Architektur: numerischer Anker aus dem ERP, LLM nur für qualitative Anpassung und Erklärung. Nie umgekehrt.

Datenhunger versus Mittelstands-Realität. Wer im Beratungsmarkt verspricht, ein domänenspezifisches LLM für Ihre Treasury-Daten zu fine-tunen, hat oft nicht verstanden, wie viele saubere Beispiele dafür nötig sind. Zwei oder drei Jahre Buchungsdaten eines 80-Millionen-Umsatz-Mittelständlers reichen nicht für ein eigenes Fine-Tuning. Was funktioniert, ist Retrieval-Augmented Generation auf bestehenden Modellen. Was nicht funktioniert, ist „Wir trainieren ein eigenes Modell auf unseren Daten". Diese Erwartung muss man früh einfangen.

Compliance und Datenschutz. Finanzdaten in eine externe LLM-API zu schicken, ist eine kritische Frage. DSGVO greift, sobald Kundennamen in Buchungstexten enthalten sind. Bankverträge enthalten oft Klauseln, die Datenweitergabe an Dritte einschränken. Wer hier sauber arbeiten will, braucht entweder ein gehostetes Modell in der EU (Mistral, Aleph Alpha) oder einen Azure-OpenAI-Vertrag mit EU-Data-Residency und expliziter No-Training-Klausel. Das ist machbar, aber kein Nebenbei-Thema.

Das hybride Modell: ERP-Zeitreihen plus LLM-Layer

In der Praxis funktioniert weder reines ERP-Forecasting noch ein reiner LLM-Ansatz. Was funktioniert, ist ein hybrides Setup mit klarer Arbeitsteilung.

Die Architektur sieht typischerweise so aus:

1. SAP, Oracle oder DATEV liefert den numerischen Baseline-Forecast. Strukturierte Zeitreihe, ARIMA oder Prophet, 30-, 60- und 90-Tage-Horizont. Das ist die Zahl, auf die der Wirtschaftsprüfer schaut.
2. Der LLM-Layer reichert an. Er liest Mahnkorrespondenz, CRM-Notizen, externe News-Feeds. Er klassifiziert Kunden in Zahlungsverhalten-Cluster anhand ihrer Kommunikation. Er flaggt Posten, bei denen die Baseline-Wahrscheinlichkeit aus seiner Sicht zu optimistisch ist.
3. Der Treasurer sieht beides nebeneinander. Baseline-Forecast plus LLM-Anmerkungen. Die Entscheidung über die finale Zahl trifft der Mensch.

Ein typisches Beispiel für den Debitoren-Bereich: Ein Mittelständler mit 200 aktiven Kunden hat im SAP-Forecast für Mai 2,3 Millionen Euro Eingänge stehen. Der LLM-Layer hat die letzten 60 Tage Mahnkorrespondenz gelesen und identifiziert drei Kunden mit einem Volumen von zusammen 380.000 Euro, die in der schriftlichen Kommunikation auf Verzögerungen hindeuten. Die Baseline bleibt unverändert, aber der Treasurer sieht: 1,9 Millionen sind hochwahrscheinlich, weitere 400.000 mit erhöhtem Verzögerungsrisiko. Diese Information hat er ohne den LLM-Layer schlicht nicht.

Für Mittelständler ohne eigene Data-Science-Abteilung sind aktuell drei Tool-Optionen realistisch:

• Microsoft Copilot for Finance. Tief in Excel und Dynamics 365 integriert, EU-Hosting verfügbar. Solide für Standard-Use-Cases, begrenzt anpassbar.
• SAP Joule. Native Integration in S/4HANA und SAP Analytics Cloud. Sinnvoll, wenn das SAP-Setup ohnehin tief verankert ist.
• Spezialisierte Treasury-APIs wie Trovata, HighRadius oder Kyriba mit eingebauten KI-Modulen. Pragmatisch für Unternehmen, die ohnehin gerade ihr Treasury-Tool wechseln.

Eine eigene LLM-Pipeline zu bauen, lohnt sich für den Mittelstand in fast keinem Fall. Die Total-Cost-of-Ownership ist im Verhältnis zum Erkenntnisgewinn nicht darstellbar.

Implementierungs-Roadmap: drei ehrliche Schritte

Schritt 1: Daten-Hygiene zuerst. Das ist der unsexy Teil, an dem 60 Prozent aller KI-Treasury-Projekte scheitern. Wenn Ihr Kontenplan über die letzten fünf Jahre dreimal umstrukturiert wurde, wenn Buchungstexte je nach Sachbearbeiter unterschiedlich aussehen, wenn Debitoren teilweise unter verschiedenen IDs geführt werden, wird kein KI-Modell der Welt brauchbare Forecasts liefern. Bevor Sie einen Cent in ein LLM-Tool stecken, lassen Sie Ihre Buchungsdaten der letzten 36 Monate prüfen. Konsistenz schlägt Komplexität.

Schritt 2: Pilot mit einem Teilbereich. Der häufigste Fehler ist, „den ganzen Cash-Flow" mit KI machen zu wollen. Das funktioniert nicht. Was funktioniert: ein klar abgegrenzter Teilbereich, in dem der Hebel groß ist und die Daten sauber sind. Zwei Kandidaten haben sich in Mittelstands-Piloten bewährt:

• Debitorenlaufzeiten. LLM liest Mahnkorrespondenz und CRM-Notizen, adjustiert Zahlungswahrscheinlichkeiten je Kunde. Messbarer Output: Reduktion der DSO um zwei bis fünf Tage.
• FX-Exposure-Forecast. LLM liest News zu Lieferanten in Fremdwährungs-Räumen, flaggt Volumen-Verschiebungen frühzeitig. Messbarer Output: weniger ungeplante Sicherungsgeschäfte.

Nicht beides gleichzeitig. Erst eins, sechs Monate Laufzeit, dann nachjustieren.

Schritt 3: Mensch bleibt im Loop. Das ist nicht nur ein Compliance-Punkt, sondern auch eine Frage der internen Akzeptanz. Ein LLM-Forecast, der ohne menschliche Prüfung an Geschäftsführung und Aufsichtsrat geht, wird beim ersten Fehler das ganze Projekt diskreditieren. Kommunizieren Sie von Anfang an: KI ist Decision-Support, nicht Autopilot. Der Treasurer trifft die Entscheidung. Das LLM liefert Inputs, die er sonst nicht hätte.

Fazit: wann sich welches Modell lohnt

Die ehrliche Entscheidungsmatrix für CFOs im DACH-Mittelstand:

• Saisonal-stabile Cash-Patterns, hoher Anteil terminierter Posten, drei Jahre saubere Daten. Klassisches ERP-Zeitreihenmodell reicht. Sparen Sie sich den LLM-Layer.
• Textreiche Debitoren-Situation, volatile Kundenbasis, viele unstrukturierte Signale. LLM-Layer oberhalb der ERP-Baseline bringt messbaren Mehrwert.
• Beides gemischt, was im Mittelstand der Normalfall ist. Hybrides Setup. SAP oder gleichwertig als Anker, LLM-Layer für die qualitativen Inputs.

Der ROI-Horizont für KI-Treasury-Projekte im Mittelstand ist realistischerweise 12 bis 18 Monate, gerechnet vom ersten Pilot bis zum produktiven Einsatz mit messbarem Effekt auf DSO oder Liquiditätspuffer. Wer schneller verspricht, verkauft Marketing.

Meine Empfehlung an CFOs, die jetzt loslegen wollen: Investieren Sie das erste Quartal nicht in Tool-Auswahl, sondern in Daten-Inventur. Prüfen Sie, wie sauber Ihre Buchungsdaten, Kundenstammdaten und Korrespondenz-Archive wirklich sind. Wählen Sie dann einen Teilbereich mit hohem Hebel. Setzen Sie auf bestehende Tools, nicht auf Eigenentwicklung. Und kommunizieren Sie nach oben: KI verbessert den Forecast in den 30 Prozent der Posten, die heute am unsichersten sind. Die anderen 70 Prozent macht das ERP weiterhin besser. Das ist keine Niederlage. Das ist eine ehrliche Arbeitsteilung.