Pexon Consulting | 10 Min. Lesezeit | 20.06.2026
TL;DR
Ein Liquiditätsplanung-KI-Agent zieht Zahlungsdaten aus ERP, Bankkonten und offenen Posten zusammen und rechnet daraus einen rollierenden 13-Wochen-Cashflow. KI-Modelle erreichen auf diesem Horizont 88-92 % Treffergenauigkeit gegenüber rund 60 % bei manueller Excel-Planung. Pexon baut solche Agenten als 6-Wochen-Pilot, angebunden an SAP, DATEV und Banken-APIs.
Warum die Excel-Liquiditätsplanung in der Fertigung nicht mehr trägt
Die kurze Antwort: Weil produzierende Unternehmen das längste Working Capital aller Branchen haben und gleichzeitig die schlechtesten Daten zur Verfügung stellen. Manufacturing-Betriebe liegen beim Days Sales Outstanding (DSO) im Schnitt bei 45-60 Tagen — deutlich über dem branchenübergreifenden Median von 56 Tagen, weil komplexe Rechnungen, lange Verkaufszyklen und Streitfälle die Zahlungseingänge strecken. Wer dann noch Vorräte für Wochen vorhält und Lieferanten nach 30 Tagen bezahlt, hat einen Cash Conversion Cycle, in dem mehrere Millionen Euro gebunden sind.
Das eigentliche Problem ist nicht die Liquidität an sich, sondern die Sicht darauf. Die typische Treasury-Abteilung im Mittelstand pflegt einen 13-Wochen-Plan in Excel, zieht montags die Kontostände aus dem Banking-Portal, kopiert offene Posten aus dem ERP und schätzt den Rest. Das Ergebnis ist eine Momentaufnahme, die am Donnerstag schon falsch ist.
Genau hier setzt ein KI-Agent an. Er ersetzt nicht den CFO und nicht das ERP — er ersetzt das Copy-Paste und die Schätzung dazwischen.
Was ein Liquiditätsplanung-KI-Agent konkret macht
Ein Liquiditätsplanung-KI-Agent ist ein autonomer Software-Dienst, der Zahlungsströme aus mehreren Systemen liest, das künftige Zahlungsverhalten anhand historischer Muster prognostiziert und einen rollierenden Forecast schreibt — ohne dass jemand morgens Daten zusammenkopiert. Anders als ein klassisches Treasury-Tool wartet er nicht auf Eingaben, sondern arbeitet einen festen Ablauf ab.
Der Agent läuft in vier Schritten, die wir in unseren Projekten so verdrahten:
- Daten ziehen. Über native APIs holt er offene Forderungen (AR-Aging), offene Verbindlichkeiten (AP-Schedule), Bestellobligo und historische Zahlungseingänge aus dem ERP — bei SAP S/4HANA, Microsoft Dynamics oder DATEV.
- Bankdaten anbinden. Per Banken-API oder PSD2-Schnittstelle kommen die echten Kontostände und Buchungen rein, nicht der CSV-Export von gestern.
- Prognostizieren. Ein ML-Modell lernt, wann welcher Kunde tatsächlich zahlt — nicht wann die Rechnung fällig wäre. Aus 40-Tage-DSO im Durchschnitt werden kundenspezifische Wahrscheinlichkeiten.
- Forecast schreiben und alarmieren. Der Agent aktualisiert den 13-Wochen-Plan täglich und meldet, wenn eine Woche unter den definierten Liquiditätspuffer rutscht.
Der entscheidende Punkt: Der Agent arbeitet auf den bestehenden Systemen, nicht statt ihnen. SAP bleibt das System of Record, das Bankkonto bleibt das Bankkonto. Der Agent ist die Schicht, die beides liest und daraus eine Prognose macht.
Wie genau ist die KI-Prognose wirklich?
Die ehrliche Antwort: gut, aber nur mit sauberen Daten. KI-Modelle erreichen auf dem 13-Wochen-Horizont 88-92 % Genauigkeit, einzelne gut konfigurierte Implementierungen kommen auf 90-95 % bei 90-Tage-Sicht. Manuelle Spreadsheet-Forecasts liegen demgegenüber bei rund 60 % — ein Handicap von über 25 Prozentpunkten. McKinsey beziffert die Verbesserung durch Machine-Learning-Modelle bei der kurzfristigen Cash-Prognose auf 30-50 %.
Aber: Modellgenauigkeit und Forecast-Genauigkeit sind nicht dasselbe. Ein hochpräzises Modell produziert eine schlechte Prognose, wenn es mit veralteten oder lückenhaften Daten gefüttert wird. Gartner zufolge betreffen Datenqualitätsprobleme 70 % der KI-Projekte im Finanzbereich. Wir sehen das in jedem Projekt: Die ersten zwei Wochen gehen nicht ins Modell, sondern in die Bereinigung der Stammdaten und das Mapping der Kontenrahmen.
Unsere klare Empfehlung: Wer keine saubere Anbindung an ERP und Bank hat, soll nicht mit dem ML-Modell anfangen, sondern mit der Datenplattform darunter. Ein Agent auf chaotischen Daten ist teurer als die Excel-Tabelle, weil er falsche Sicherheit vorgaukelt.
DSO, DPO und der Hebel im Working Capital
Der größte Hebel liegt nicht in der Prognose, sondern in dem, was man mit ihr macht. Sobald der Agent kundenspezifisches Zahlungsverhalten kennt, lassen sich drei Stellschrauben datenbasiert drehen:
- DSO senken (Forderungen schneller eintreiben): Der Agent erkennt, welche Kunden chronisch spät zahlen, und priorisiert das Mahnwesen automatisch. Jeder Tag DSO weniger setzt bei 100 Mio. EUR Umsatz rund 274.000 EUR frei.
- DPO halten oder ausreizen (Lieferanten nicht zu früh bezahlen): Statt pauschal nach 14 Tagen zahlt der Agent zum letztmöglichen Skonto-optimalen Termin — sichtbar im Forecast statt im Bauchgefühl.
- Vorratsbindung an den Forecast koppeln: Wenn die nächsten Wochen knapp werden, sieht die Produktionsplanung das, bevor das Konto ins Minus läuft.
Für produzierende Unternehmen ist das relevanter als für jede andere Branche, weil hier am meisten Kapital im Cash Conversion Cycle steckt. Die Datenbasis dafür ist dieselbe, die auch eine moderne Datenplattform speist — weshalb sich der Liquiditäts-Agent gut mit einem Fabric-basierten Datenplattform-Piloten kombinieren lässt. Wer die Datenbasis ohnehin aufräumt, sollte beides in einem Zug denken.
Technische Umsetzung: Forecast aus ERP- und Bankdaten
Der Kern eines solchen Agenten ist überschaubar. Hier ein lauffähiges Python-Beispiel, das aus offenen Forderungen und einem kundenspezifischen Zahlungsverzug einen wochengenauen Forecast rechnet — die Logik, die im Agenten unter der Haube läuft:
import pandas as pd
from datetime import datetime, timedelta
# Offene Posten aus dem ERP (vereinfacht): Betrag, Faelligkeit, Kunde
forderungen = pd.DataFrame([
{"kunde": "A", "betrag": 120_000, "faellig": "2026-06-25"},
{"kunde": "B", "betrag": 80_000, "faellig": "2026-07-02"},
{"kunde": "C", "betrag": 200_000, "faellig": "2026-07-10"},
])
# Aus der Historie gelernter Zahlungsverzug je Kunde (Tage).
# In Produktion liefert das ML-Modell diese Werte, nicht eine feste Tabelle.
verzug = {"A": 3, "B": 25, "C": 12} # Kunde B zahlt chronisch spaeter
def erwarteter_eingang(row):
"""Verschiebt die Faelligkeit um den gelernten Zahlungsverzug."""
d = datetime.strptime(row["faellig"], "%Y-%m-%d")
return d + timedelta(days=verzug[row["kunde"]])
forderungen["erwartet"] = forderungen.apply(erwarteter_eingang, axis=1)
# Auf Kalenderwoche aggregieren = rollierender 13-Wochen-Forecast
forderungen["kw"] = forderungen["erwartet"].dt.isocalendar().week
forecast = forderungen.groupby("kw")["betrag"].sum()
print(forecast)Die Anbindung an die Quellsysteme ist der eigentliche Aufwand. Bankdaten kommen in der Regel über eine PSD2- oder Banken-API rein. Ein typischer Account-Information-Call sieht so aus:
# Kontoumsaetze via PSD2-Banken-API abrufen (Beispiel)
# Der Agent ruft das einmal pro Tag ab und gleicht gegen den Forecast ab
curl -X GET "https://api.bank.example/v1/accounts/DE89.../transactions"
-H "Authorization: Bearer $BANK_API_TOKEN"
-H "Consent-ID: $PSD2_CONSENT"
-H "Accept: application/json"Die ERP-Seite läuft analog über native Konnektoren — bei SAP etwa über OData- oder MCP-Schnittstellen, wie wir sie auch in anderen SAP-Daten-per-Sprache-Projekten nutzen. Der Agent selbst orchestriert diese Calls, prüft die Antworten und schreibt das Ergebnis zurück in die Liquiditätssicht.
Was das in der Praxis bedeutet: ein 6-Wochen-Pilot
Wir starten solche Vorhaben bewusst klein. Statt eines Konzern-Rollouts über alle Gesellschaften nehmen wir eine Legaleinheit, ein bis zwei Banken und das produktive ERP. Die Branche bewegt sich gerade von Pilot zu Produktion — laut PwC CFO Pulse 2026 geht KI-gestützte Treasury-Automatisierung dieses Jahr in den Regelbetrieb. Auch Anbieter ziehen nach: Bottomline kündigte im Oktober 2025 einen eingebetteten Treasury-KI-Agenten namens Bea mit Rollout Anfang 2026 an.
Der Pilot folgt einem festen Takt:
Realistisch ist eine Deployment-Dauer von wenigen Wochen, sobald die Datenquellen stehen — das deckt sich mit unserem Pilot-Ansatz und mit dem, was am Markt für Vier-Agenten-Frameworks genannt wird (30-60 Tage). Den Pilotansatz für datengetriebene Projekte haben wir auch im risikoarmen Start eines Datenplattform-Piloten beschrieben — die Logik ist dieselbe: erst messbarer Wert auf einem Ausschnitt, dann skalieren.
Für produzierende Unternehmen, die ihre gesamte Wertschöpfungskette datenseitig durchdenken, ordnet sich der Liquiditäts-Agent in ein größeres Bild ein, das wir im Überblick zu KI entlang der Wertschöpfungskette zeigen.
Häufig gestellte Fragen
Was kostet ein Liquiditätsplanung-KI-Agent?
Ein erster produktiver 13-Wochen-Forecast als 6-Wochen-Pilot liegt im Projektbudget-Bereich von 50.000 bis 80.000 EUR, abhängig von Anzahl der Banken, ERP-Komplexität und Datenqualität. Der laufende Betrieb ist deutlich günstiger als die manuellen Personentage, die heute in die wöchentliche Excel-Pflege fließen. Den größten Kostenblock macht nicht das Modell aus, sondern die Datenanbindung.
Wie genau ist die KI-Prognose gegenüber unserer Excel-Planung?
Auf dem 13-Wochen-Horizont erreichen KI-Modelle 88-92 % Genauigkeit, manuelle Spreadsheet-Forecasts rund 60 %. Voraussetzung ist eine saubere Anbindung an ERP und Bank — mit veralteten Daten sinkt die reale Forecast-Qualität trotz gutem Modell. Die Prognose wird mit jedem Monat besser, weil das Modell mehr Zahlungsverhalten lernt.
Müssen wir unser ERP oder unsere Bank wechseln?
Nein. Der Agent arbeitet auf den bestehenden Systemen und liest über APIs aus SAP S/4HANA, Microsoft Dynamics, DATEV und gängigen Banken-Schnittstellen. Das ERP bleibt System of Record, der Agent ist die Prognose-Schicht darüber. Ein Systemwechsel ist nie Voraussetzung für den Start.
Ist die Bankanbindung DSGVO- und sicherheitskonform?
Bankdaten laufen über regulierte PSD2- oder dedizierte Banken-APIs mit expliziter Einwilligung (Consent). Wir betreiben die Pipeline in der Regel in einer von Ihnen kontrollierten Cloud-Umgebung in Deutschland, sodass Zahlungsdaten das gewählte Rechenzentrum nicht verlassen. Zugriffe sind protokolliert und audit-fähig.
Liquiditäts-Agent oder klassisches Treasury-Management-System — was ist der Unterschied?
Ein Treasury-Management-System ist ein Werkzeug, das auf Eingaben wartet. Der Agent arbeitet autonom einen Ablauf ab: Daten ziehen, prognostizieren, Forecast schreiben, alarmieren. Beides schließt sich nicht aus — der Agent kann auf einem bestehenden TMS aufsetzen und es um die ML-Prognose ergänzen, statt es zu ersetzen.
Nächster Schritt
Wenn Sie gerade evaluieren, ob sich ein KI-Agent für Ihre Liquiditätsplanung lohnt: Der schnellste Weg ist ein kurzer Realitäts-Check Ihrer Datenanbindung, bevor irgendein Modell trainiert wird. Genau das machen wir im ersten Schritt.
Verwandte Themen
