In Kyribas CFO Risk Radar 2026 gaben nur 26 % der Finanzteams an, kontinuierliche oder automatisierte Szenariomodellierung durchzuführen. Die übrigen 74 % arbeiten noch nach einem festen Kalenderrhythmus – monatlich, quartalsweise oder sogar jährlich –, während die Risiken, die sie modellieren, nicht auf den nächsten Review-Zyklus warten. Manuelle Prognosen und fragmentierte Zahlungsworkflows wirken wie zwei separate Probleme. Es ist dasselbe Grundproblem – das sich an zwei Stellen zeigt.

Dieselbe Umfrage zeigt: 83 % der Finanzteams können die finanzielle Auswirkung eines Risikos nicht in Echtzeit quantifizieren. Aus CFO-Perspektive lautet die entscheidende Frage, ob das Treasury eine Risikoposition bewerten kann, solange noch Handlungsoptionen bestehen – nicht, ob ein Modell im Monatsreporting erscheint.

Beide Erkenntnisse verweisen auf dieselbe Reifegradlücke: das Fehlen einer zentralisierten, in Echtzeit bereinigten Datenbasis, die Planung und Ausführung miteinander verbindet. Finanzteams beschreiben diese Lücke oft als Personal- oder Technologieproblem. Die eigentliche Ursache liegt im Governance-Design. Die Daten und Kontrollen sind nicht eng genug und nicht zeitnah genug mit den Entscheidungen verknüpft, die das Treasury treffen soll.

Zwei Symptome einer einzigen Reifegradlücke

Excel-basierte Prognosen sind das Symptom auf der Planungsseite. Fragmentierte Zahlungsabwicklung ist das Symptom auf der Ausführungsseite. Die Prozesse sehen unterschiedlich aus – doch beide erfordern, dass Fachkräfte zunächst voneinander getrennte Informationen zusammenführen, bevor das Unternehmen seine Liquiditätsposition klar genug erkennen kann, um handeln zu können.

Prozessineffizienz bedeutet langsames Arbeiten. Datenfragmentierung schafft blinde Flecken. Unternehmen mit geringerer Prozessreife setzen zusätzliche Kapazitäten ein, um die Warteschlange zu bearbeitender Dateien zu verkürzen – ohne den blinden Fleck jedoch zu beseitigen. Das ist besonders relevant, wenn Finanzverantwortliche Investitionen auf separate Prognose- und Zahlungsinitiativen aufteilen – mit jeweils eigenen Verantwortlichen, Prioritäten, Business Cases und Meilensteinen.

Eine Prognose kann nicht aktuell bleiben, wenn Zahlungsdaten verspätet oder in inkonsistenten Formaten eintreffen. Schnellere Zahlungsabwicklung kompensiert kein Risikoprofil, das auf nicht konsolidierten Salden basiert. Die gemeinsame Ursache liegt unterhalb beider Workflows: Dem Treasury fehlt eine verlässliche Gesamtübersicht darüber, was bereits geschehen ist, was sich gerade in Bewegung befindet und was als Nächstes finanziert werden muss.

Warum manuelle Prognosen nicht skalieren

Eine manuelle Prognose scheitert in der Regel an denselben Stellen – unabhängig davon, wie erfahren das Team ist. Daten treffen aus mehreren Banken und Einheiten ein. Die Analystin oder der Analyst lädt Dateien herunter oder fordert sie an, harmonisiert unterschiedliche Formate, gleicht Salden ab, untersucht Abweichungen und aktualisiert anschließend das Modell. Die Prognose steht erst zur Verfügung, wenn diese Arbeit abgeschlossen ist.

Der Abstimmungsschritt, der montagmorgens zwei Stunden kostet, ist selten die Berechnung selbst. Es ist die Abweichungsanalyse: Eine Einheit hat in einem System am Dienstag verbucht, in einem anderen am Mittwoch – und weist nun eine Saldenabweichung auf, die niemand erklären kann, bis die richtige Person auf eine E-Mail antwortet. Das Modell mag mathematisch korrekt sein. Die Eingaben hängen dennoch von Timing, Interpretation und implizitem Wissen ab.

Dieser Prozess schafft im größeren Maßstab einen Single Point of Failure. Die Fachkräfte, die das Modell betreiben, wissen, welche Datei mit Kontoinformationen zu verwenden ist, welche Einheit ein ungewöhnliches Buchungsmuster aufweist, welcher konzerninterne Saldo einer Anpassung bedarf und welche Annahmen sich seit dem letzten Zyklus geändert haben. Sind sie nicht verfügbar, muss eine andere Person die Logik unter Zeitdruck neu aufbauen.

Personalfragen verschärfen diese Fragilität zusätzlich. 57 % der Finanzteams geben an, sich erheblich oder mäßig Sorgen über Personalthemen zu machen – darunter Einstellungen, Mitarbeiterbindung und Qualifikationen. Mehr Köpfe lösen ein Personalproblem. Ein strukturelles Problem lösen sie nicht. Mehr Mitarbeitende, die manuelle Workflows ausführen, können den Durchsatz vorübergehend steigern – bei gleichzeitig unveränderter Abhängigkeit von fragmentierten Daten und implizitem Wissen.

Die Erhebungsdaten zur Modellierungsfrequenz verdeutlichen, warum das Quantifizierungsproblem fortbesteht. Nur 26 % der Teams führen eine kontinuierliche oder automatisierte Szenariomodellierung durch, während 34 % monatlich, 35 % quartalsweise und 3 % jährlich modellieren. Ein kalenderbasiertes Modell kann einen geplanten Review unterstützen. Es kann jedoch nicht zuverlässig beantworten, was ein neues Gegenparteirisiko, eine verzögerte Kundenzahlung, ein unerwarteter Finanzierungsbedarf oder eine Währungsbewegung in den Stunden nach dem Ereignis für die Liquidität bedeutet.

Dass 83 % der Teams die finanziellen Auswirkungen in Echtzeit nicht quantifizieren können, ist daher ein Prozessbefund – nicht nur ein Modellierungsbefund. Wenn das Szenariomodell erst nach dem Risikoereignis aktualisiert wird, misst das Treasury eine Risikoposition, nachdem das Entscheidungsfenster bereits enger geworden ist.

Warum fragmentierte Zahlungen das Problem verschärfen

Fragmentierte Zahlungsprozesse erzeugen denselben Sichtbarkeitsverzug auf der Ausführungsseite. Ein Multi-Portal-Betriebsmodell mag die erforderlichen Informationen enthalten – doch Informationen, die sich über mehrere Portale und Prozesse einzelner Einheiten verteilen, ergeben keine geprüfte, entscheidungsreife Liquiditätsposition.

Analystinnen und Analysten müssen weiterhin Salden vergleichen und Verfügbarkeit prüfen, freigegebene und ausstehende Zahlungen bestätigen, Ausnahmen abstimmen und feststellen, ob eine Zahlung den Kontrollprozess durchlaufen hat.

Das operative Detail ist entscheidend. Eine Zahlung kann in einem Workflow genehmigt, über einen anderen freigegeben und in einem Bankportal bestätigt werden, das die Prognose noch nicht abbildet. Das Ergebnis ist eine Lücke zwischen der Liquiditätsposition, die das Treasury plant, und der Position, die das Unternehmen tatsächlich ausführt. Liquidität wird sichtbar, nachdem Bewegungen stattgefunden haben – nicht davor. Die Folgen können sich in Form einer kostspieligen Kontoüberziehung oder suboptimaler Renditen auf vorhandene Mittel äußern.

Nur 38 % der Finanzteams berichten von hohem Vertrauen in ihre Fähigkeit, Risikoexpositionen in Echtzeit zu analysieren. Datenintegrität, Datenverfügbarkeit und Entscheidungssicherheit sind unterschiedliche Fähigkeiten. Ein Saldo oder eine Transaktion, die technisch irgendwo in einer fragmentierten Umgebung existiert, ist kein verlässlicher Input für Prognosen, Finanzierung, Hedging oder Liquiditäts-Governance.

Kontrollen verdeutlichen denselben Unterschied: Eine Kontrolle, die durchgeführt wird, nachdem eine Zahlung ausgeführt wurde, ist eine Überprüfung. Eine Kontrolle, die in den Zahlungs-Workflow eingebettet ist, kann eine Ausnahme vor der Kontobelastung verhindern, weiterleiten oder eskalieren. Der eine Ansatz produziert Prüfungsnachweise. Der andere schützt Geld in Bewegung.

Ein Zahlungsprozess, der keine an Compliance- und Prüfanforderungen ausgerichteten Kontrollen konfigurieren kann, unterstützt nicht die Governance-Struktur, die kontinuierliche Liquiditätsintelligenz erfordert. Zahlungszentralisierung, kombiniert mit systematischer Prüfbarkeit und Nachverfolgbarkeit, ist daher eine Reifegradvoraussetzung – und keine bloße Effizienzinitiative.

Ein einziger Fehler oder eine Kontrollschwäche kann erhebliche Reputationsschäden verursachen. Ein Zahlungsprozess muss über einen kontinuierlichen, autonomen und dauerhaft aktiven Kontrollrahmen verfügen, der proaktiv schützt – nicht erst nach einem Vorfall. Dorthin gelangt man nicht, wenn die Zahlungs-Workflows noch über mehrere unterschiedliche Bankportale verteilt sind.

Zentralisierung bedeutet nicht, Urteilsvermögen auszuschalten oder jede Einheit in ein standardisiertes Betriebsmodell zu zwingen. Es bedeutet, eine konsistente Grundlage für Kontodaten, Zahlungsstatus, Genehmigungen, Ausnahmen, Betrugserkennung und Liquiditätsbewegungen über Banken, Einheiten und Währungen hinweg zu schaffen. Eine vernetzte Datenschicht kann dann automatisch die Prognose mit aktuellen Ausführungsdaten speisen und Zahlungsentscheidungen mit dem Kontext der Liquiditätsposition versehen, auf die das Treasury hinarbeitet.

Infrastruktur aufbauen – nicht nur das Mindset

Finanzteams erreichen keine kontinuierliche Liquiditätsintelligenz, indem sie Fachkräfte auffordern, härter zu arbeiten, sorgfältiger zu dokumentieren oder ein weiteres Review-Meeting einzuführen. Disziplin ist wichtig – doch Disziplin, die auf fragmentierten Daten aufsetzt, liefert verzögerte Antworten genau dann, wenn das Treasury sie sich am wenigsten leisten kann.

Die eigentlichen Kosten manueller Treasury-Arbeit liegen in der Einengung von Handlungsoptionen. Wenn ein manueller Prozess das Risiko erst sichtbar macht, ist die Entscheidung, die am meisten hätte zählen können, oft nicht mehr verfügbar.

Beginnen Sie mit einem Datenstruktur-Audit. Erfassen Sie, wo Zahlungsdaten liegen, wer sie konsolidiert und wie lange es dauert, bis sie die Prognose erreichen. Diese Antworten zeigen, wo die Reifegradlücke liegt und welche Kontrollen in den Prozess integriert werden müssen.

Behandeln Sie Prognose und Zahlungen nicht länger als getrennte Budgetposten. Betrachten Sie sie als ein einziges Reifegradthema.