Was leistet eine automatisierte Liquiditätsplanung genau?

Eine Liquiditätsplanung ist die Gegenüberstellung erwarteter Ein- und Auszahlungen über einen definierten Zeitraum, aktualisiert auf Basis realer Kontobewegungen und offener Posten. Anders als die Buchhaltung, die Geschäftsvorfälle periodengerecht verbucht, und anders als die Gewinn- und Verlustrechnung, die Erträge und Aufwendungen zeigt, bildet sie tatsächliche Zahlungsströme ab.

Diese Abgrenzung ist keine Formalität. Eine Rechnung erscheint in der GuV mit Rechnungsdatum, zahlungswirksam wird sie oft erst Wochen später, gemindert um Skonto oder verzögert durch ein Zahlungsziel. Wer nur auf die GuV schaut, sieht ein Unternehmen, das Gewinn erwirtschaftet, aber trotzdem am Monatsende die Löhne nicht überweisen kann.

Deshalb arbeitet eine belastbare Liquiditätsplanung mit zwei Horizonten. Kurzfristig, in der Regel als rollierende 13-Wochen-Vorschau, geht es um die Zahlungsfähigkeit der nächsten drei Monate auf Wochenbasis. Mittelfristig, über zwölf bis 24 Monate, geht es um die strukturelle Entwicklung: saisonale Muster, geplante Investitionen, absehbare Finanzierungslücken.

Automatisiert heißt dabei nicht autonom. Kontostände, offene Posten und wiederkehrende Zahlungen lassen sich zuverlässig fortschreiben, die Einschätzung eines Kundenausfalls oder einer verschobenen Investition bleibt eine Entscheidung von Menschen. Der Agent liefert die aktuelle Zahlenbasis, die Bewertung bleibt bei Geschäftsführung und Controlling.

Woran scheitert die Liquiditätsplanung in Excel?

Excel-Tabellen scheitern nicht an der Rechenlogik, sondern an der Fortschreibung im Alltag. Sobald eine Person krank ist oder im Urlaub, bleibt die Aktualisierung liegen, und niemand merkt es, bis eine Zahlung überraschend ausbleibt. Das Werkzeug ist nicht das Problem, die fehlende Vertretungsregelung schon.

Mit steigender Zahl an Bankkonten und Gesellschaften wächst der Abstimmungsaufwand überproportional. Wer Salden aus drei Konten und zwei Tochtergesellschaften händisch in ein Blatt überträgt, verliert Zeit genau dann, wenn schnelle Übersicht am wichtigsten wäre, etwa vor einem Bankgespräch.

Versionsstände sind die zweite Schwachstelle. Liquiditaet_final_v3.xlsx kursiert per E-Mail, während parallel eine andere Version bearbeitet wird. Am Ende weiß niemand mehr sicher, welcher Stand der aktuelle ist, und Entscheidungen stützen sich auf veraltete Zahlen, ohne dass dies auffällt.

Schließlich fehlt die Historie. Eine Tabelle zeigt den heutigen Stand, aber selten nachvollziehbar, wie sich die Planwerte der Vorwoche entwickelt haben und wo die größten Abweichungen lagen. Für ein Frühwarnsystem, das spätere Nachfragen aushalten muss, reicht das nicht aus, ein durchgängiges Änderungsprotokoll fehlt strukturell.

Welche Datenquellen speisen die Liquiditätsplanung?

Eine belastbare Liquiditätsplanung stützt sich auf vier bis fünf Quellen: Bankkonten über regulierte Schnittstellen, offene Posten aus dem Debitorenbereich, offene Posten aus dem Kreditorenbereich, wiederkehrende Zahlungen wie Mieten oder Gehälter sowie Plangrößen aus Vertrieb und Einkauf. Jede Quelle deckt einen anderen Teil des Zahlungsbilds ab, gemeinsam ergeben sie die Vorschau.

Bankkonten liefern den tatsächlichen Ist-Stand, angebunden über PSD2-konforme Schnittstellen statt über manuellen Kontoauszugs-Import. Offene Posten Debitoren zeigen, welche Zahlungseingänge mit welchem Zahlungsziel zu erwarten sind, offene Posten Kreditoren das Gegenstück auf der Ausgabenseite, häufig direkt aus dem DATEV-Bestand oder dem OPOS-Export.

Wiederkehrende Zahlungen wie Mieten, Leasingraten oder Lohnläufe lassen sich als feste Muster hinterlegen und benötigen kaum manuelle Pflege. Plangrößen aus Vertrieb und Einkauf, etwa erwartete Auftragseingänge oder größere Bestellungen, ergänzen die Vorschau um Positionen, die noch nicht als Beleg existieren, aber absehbar sind.

Die folgende Übersicht ordnet die Quellen ihrer Aktualisierungslogik zu.

Wie funktioniert die rollierende 13-Wochen-Vorschau?

Die rollierende 13-Wochen-Vorschau arbeitet nach der direkten Methode: Sie summiert erwartete Ein- und Auszahlungen Woche für Woche, statt sie aus Gewinn und Verlust abzuleiten. Nach jeder abgeschlossenen Woche rückt der Horizont um eine Woche weiter, neue Ist-Werte ersetzen alte Planwerte, und die Liquiditätsplanung bleibt durchgehend aktuell statt einmalig erstellt.

Die Genauigkeit nimmt mit der Entfernung zum aktuellen Stichtag naturgemäß ab. Für die Wochen 5 bis 8 liegen belastbare Trefferquoten deutlich näher am späteren Ist-Wert als für die Wochen 9 bis 13, weil kurzfristige Zahlungseingänge und -ausgänge meist bereits als offener Posten vorliegen, während weiter entfernte Wochen stärker auf Plangrößen und Annahmen angewiesen sind.

Diese abnehmende Genauigkeit ist kein Mangel, sondern eine Eigenschaft der Methode, die im Reporting auch so ausgewiesen werden sollte. Wer die Wochen 9 bis 13 mit derselben Verbindlichkeit kommuniziert wie die Wochen 1 bis 4, erzeugt falsche Sicherheit, etwa gegenüber der Bank.

Der Plan-Ist-Abgleich am Ende jeder Woche macht Abweichungen sichtbar und dokumentiert sie. So lässt sich über mehrere Zyklen prüfen, welche Annahmen sich bewährt haben und wo die Planung systematisch zu optimistisch oder zu vorsichtig war, ein Lernprozess, der die Qualität der folgenden Prognosen verbessert.

Warum braucht die Liquiditätsplanung einen 24-Monats-Horizont?

Der 24-Monats-Horizont ergibt sich aus der gesetzlichen Erwartung an die Krisenfrüherkennung: Nach § 1 StaRUG sind Geschäftsleiterinnen und Geschäftsleiter zur fortlaufenden Überwachung bestandsgefährdender Entwicklungen verpflichtet, und daraus wird ein Planungszeitraum von mindestens 24 Monaten abgeleitet. Die kurzfristige 13-Wochen-Vorschau allein deckt diesen Zeitraum nicht ab.

Wichtig ist die Abgrenzung zur Überschuldungsprüfung nach § 19 Insolvenzordnung, deren Fortführungsprognose regelmäßig einen kürzeren Zeitraum von zwölf Monaten betrachtet. Beide Zeiträume verfolgen unterschiedliche Zwecke: der eine dient der laufenden Beobachtung, der andere der Bewertung im konkreten Krisenfall, und beide sollten in der Liquiditätsplanung sauber getrennt geführt werden.

In der Praxis bedeutet das eine mittelfristige Planung auf Monatsbasis, abgeleitet aus Umsatz-, Kosten- und Investitionsplanung, die neben die wöchentliche Vorschau tritt. Sie zeigt nicht jede Kontobewegung, wohl aber saisonale Muster, geplante Kreditlinien und absehbare Refinanzierungsbedarfe rechtzeitig genug, um gegenzusteuern.

Diese doppelte Struktur lässt sich in bestehende Planungswerkzeuge integrieren, ohne die vorhandene DATEV- oder ERP-Landschaft zu ersetzen. Eine technische Bestandsaufnahme der vorhandenen Datenquellen zeigt, welche Anpassungen für den mittelfristigen Horizont tatsächlich nötig sind, oft weniger, als eine neue Software-Einführung vermuten lässt.

Wer legt die Warnschwellen fest und wer wird informiert?

Die Warnschwellen legt die Geschäftsführung fest, in der Regel gemeinsam mit Finanzleitung oder Controlling, und dokumentiert sie schriftlich mit Begründung. Bei Unterschreitung wird ein festgelegter Personenkreis automatisch informiert, meist Geschäftsführung und Controlling gemeinsam. Diese Zuständigkeit ist keine Nebensache, sondern der Kern eines belastbaren Frühwarnsystems.

Genau hier liegt die häufigste Lücke bestehender Software-Angebote: Sie sprechen von automatischer Erkennung, bleiben aber vage, wer die Schwelle bestimmt hat und wer bei Alarm tatsächlich reagiert. Der Wirtschaftsprüfer-Standard IDW S 16 beschreibt, wie ein Frühwarnsystem von der Schwellenfestlegung bis zum Eskalationsprozess durchgängig aufgebaut sein sollte.

Der Agent kann Kontostände laufend gegen die hinterlegten Schwellen prüfen und bei Unterschreitung automatisch eine Benachrichtigung auslösen, etwa als Ticket im Ticket im IT Service Management oder als Eintrag im Change-Protokoll. Entscheiden, ob eine Kreditlinie gezogen oder eine Zahlung verschoben wird, darf er nicht, das bleibt bei den benannten Verantwortlichen.

Für die Dokumentation reicht ein einmaliger Beschluss nicht aus. Schwellenwerte, Änderungen daran und die jeweilige Begründung sollten nachvollziehbar protokolliert werden, damit im Krisenfall belegbar ist, wann ein Signal erkannt und wie darauf reagiert wurde. Eine strukturierte Ablage, etwa in einer strukturierten Wissensbasis geführt, unterstützt diese Nachvollziehbarkeit ohne zusätzlichen manuellen Aufwand.

Was kann Automatisierung in der Liquiditätsplanung nicht leisten?

Ein System kann Zahlungseingänge erfassen, Fristen fortschreiben und Abweichungen anzeigen. Es kann nicht einschätzen, ob ein Großkunde trotz Zahlungsverzug zuverlässig bleibt, ob ein Projekt sich verschiebt oder ob eine Lieferantin bei Zahlungsdruck einen Rabatt einräumt. Solche Einschätzungen setzen Erfahrung, Marktkenntnis und persönliche Gespräche voraus. Die Liquiditätsplanung bleibt deshalb ein Werkzeug, kein Orakel.

Das System liest den Zahlungseingang. Ob der Kunde in der nächsten Woche zahlt oder erst nach dem dritten Mahnschreiben, entscheidet niemand automatisiert. Das System zeigt eine Häufung überfälliger Posten. Ob dahinter ein Liquiditätsproblem des Kunden oder ein internes Abstimmungsproblem in der eigenen Buchhaltung steckt, klärt ein Mensch im Gespräch.

Auch Verhandlungsspielräume lassen sich nicht in Regeln fassen. Ob mit einer Bank eine Kontokorrentlinie erweitert wird, ob ein Lieferant längeren Zahlungszielen zustimmt oder ob ein Projekt intern priorisiert wird, sind unternehmerische Entscheidungen mit rechtlicher und finanzieller Wirkung. Diese Entscheidungen bleiben bei der Geschäftsführung und dem Controlling, nicht bei einer Software.

ANCUD IT baut deshalb keine vollautomatische Planung, sondern eine Vorschau, die Zahlen aktuell hält und Auffälligkeiten sichtbar macht. Die Bewertung dieser Auffälligkeiten und die daraus folgenden Schritte bleiben Aufgabe der Menschen, die das Unternehmen und seine Geschäftsbeziehungen kennen.

Wie erkennt ein Frühwarnsystem einen Liquiditätsengpass?

Ein Frühwarnsystem vergleicht laufend die aktuelle Vorschau mit festgelegten Schwellen für Kontostand und Reichweite. Es erkennt einen Engpass durch drei Muster: eine negative Entwicklung über mehrere Wochen, eine ungewöhnliche Häufung überfälliger Posten und eine spürbare Verlängerung der tatsächlich gezahlten Zahlungsziele gegenüber den vereinbarten Fristen.

Die Mechanik dahinter ist bewusst nachvollziehbar gehalten. Jede Woche werden Kontostände, offene Forderungen und wiederkehrende Zahlungen fortgeschrieben. Sinkt der prognostizierte Tiefstwert unter eine vorher festgelegte Schwelle, löst das System eine Meldung aus. Steigt der Anteil der Rechnungen, die ihr Zahlungsziel um mehr als eine definierte Anzahl Tage überschreiten, wird das als Trend markiert, nicht als Einzelfall abgetan.

Wichtig ist die Unterscheidung zwischen einem einmaligen Ausschlag und einer strukturellen Verschlechterung. Eine einzelne verspätete Zahlung ist normaler Geschäftsalltag. Wiederholt sich das Muster über mehrere Wochen oder betrifft es mehrere Kunden gleichzeitig, deutet das auf ein Problem hin, das über den Einzelfall hinausgeht. Solche Trendbrüche lassen sich mit einfachen Kennzahlen wie Reichweite in Tagen oder Anteil überfälliger Posten gut abbilden, ähnlich wie bei der laufenden Qualitätssicherung technischer Systeme einem vergleichbaren Prinzip aus der Softwarequalität, wo Abweichungen ebenfalls über Schwellen statt Einzelmeldungen erkannt werden.

Wer die Schwellen festlegt und wer die Meldung erhält, wird bei der Einführung schriftlich festgelegt. Ohne diese Zuordnung verschwindet eine Warnung im Postfach, statt zur Entscheidung zu führen. Das System meldet, es entscheidet nicht, ob eine Warnschwelle sinnvoll gewählt ist oder angepasst werden muss.

Wie verbindet sich die Liquiditätsplanung mit DATEV und ERP?

Die Liquiditätsplanung übernimmt Daten aus vorhandenen Systemen statt sie zu ersetzen: den DATEV-OPOS-Export für offene Debitoren und Kreditoren, den Buchführungsbestand für bereits verbuchte Belege und die Belegdaten aus dem ERP-System für Bestellungen und Rechnungen, die noch nicht in der Buchhaltung angekommen sind. Die bestehende Landschaft bleibt erhalten, die Planung ergänzt sie.

In der Praxis bedeutet das: Der OPOS-Export liefert offene Forderungen und Verbindlichkeiten mit Fälligkeit, der Buchführungsbestand zeigt, was bereits gebucht ist, und das ERP-System liefert die Belege, die den nächsten Wochen zugeordnet werden, auch wenn sie noch nicht in DATEV erfasst sind. Diese drei Quellen zusammen ergeben ein Bild, das weder DATEV noch das ERP-System allein liefern.

Die Abstimmung mit der Steuerkanzlei bleibt Teil des Ablaufs. Buchungsstände ändern sich rückwirkend, etwa durch Nachbuchungen oder Korrekturen. Die Liquiditätsplanung markiert solche Änderungen, damit klar ist, welche Zahl aus welchem Stand stammt, statt stillschweigend eine ältere Zahl zu überschreiben. Das entspricht demselben Grundsatz wie bei jeder Anbindung an vorhandene Fachsysteme über Schnittstellen: Die Datenherkunft bleibt nachvollziehbar, auch wenn mehrere Quellen zusammenlaufen.

Am Anfang jeder Einführung steht deshalb eine technische Bestandsaufnahme der vorhandenen Buchhaltungs- und ERP-Datenquellen. Erst danach lässt sich seriös sagen, welche Felder automatisch übernommen werden können und wo eine manuelle Ergänzung nötig bleibt.

Welche Kennzahlen gehören in das Cashflow-Monitoring?

Ins Cashflow-Monitoring gehören die Liquiditätsgrade eins bis drei, das Working Capital, die tatsächlichen Zahlungsziele im Vergleich zu den vereinbarten Fristen und die Reichweite der liquiden Mittel in Tagen. Zusammen zeigen sie, ob ein Unternehmen kurzfristig zahlungsfähig ist und wie sich das ohne Gegenmaßnahmen in den nächsten Wochen entwickelt.

Der Liquiditätsgrad eins, auch Cash Ratio genannt, setzt die sofort verfügbaren Mittel ins Verhältnis zu den kurzfristigen Verbindlichkeiten und zeigt die unmittelbare Zahlungsfähigkeit. Der Liquiditätsgrad zwei, die Quick Ratio, bezieht zusätzlich kurzfristige Forderungen ein. Der Liquiditätsgrad drei, die Current Ratio, berücksichtigt auch Vorräte und gibt damit ein breiteres, aber weniger kurzfristiges Bild.

Das Working Capital zeigt, wie viel Kapital im laufenden Geschäft gebunden ist, etwa in Lagerbeständen und offenen Forderungen. Die Reichweite in Tagen sagt, wie lange die aktuellen liquiden Mittel bei unverändertem Verlauf reichen würden, und ist damit eine der anschaulichsten Zahlen für die Geschäftsführung, weil sie sich direkt in einen Handlungszeitraum übersetzt.

Diese Kennzahlen ersetzen keine Bewertung, sie liefern die Grundlage dafür. Ein guter Liquiditätsgrad bei gleichzeitig stark steigendem Working Capital kann trotzdem ein Warnsignal sein, wenn Kapital zunehmend in Forderungen gebunden bleibt.

Wie läuft der Plan-Ist-Abgleich in der Liquiditätsplanung?

Der Plan-Ist-Abgleich stellt wöchentlich die zuvor geplanten Zahlungseingänge und -ausgänge den tatsächlich verbuchten Werten gegenüber. Abweichungen werden nicht nur als Zahl angezeigt, sondern einer Ursache zugeordnet: verschobener Zahlungstermin, storniertes Projekt, unterschätzte Ausgabe. Diese Zuordnung übernimmt weiterhin die Person, die die Planung verantwortet.

In der wöchentlichen Runde wird geprüft, welche Abweichungen einmalig sind und welche sich wiederholen. Eine einzelne verschobene Zahlung wird korrigiert und fließt in die nächste Vorschau ein. Wiederholt sich dasselbe Muster bei mehreren Kunden, etwa eine systematisch längere Zahlungsdauer, wird das als strukturelle Änderung markiert und in die Annahmen der Folgewochen übernommen.

Der Lerneffekt liegt genau in dieser Rückkopplung: Jede Abweichung schärft die Annahmen für die nächste rollierende Woche. Eine Liquiditätsplanung, die nie mit der Realität abgeglichen wird, verliert innerhalb weniger Wochen an Aussagekraft. Der wöchentliche Abgleich hält die Vorschau nah an der tatsächlichen Zahlungslage, ohne dass jede Abweichung sofort eine Krisenreaktion auslöst.

Dokumentiert wird dabei nicht nur die Abweichung selbst, sondern auch, wer sie bewertet und welche Annahme daraus für die nächste Woche folgt. Das schafft im Krisenfall eine nachvollziehbare Historie darüber, dass Warnsignale erkannt und geprüft wurden.

Welche Rolle spielen mehrere Gesellschaften und Konten?

Bei mehreren Gesellschaften und Konten muss die Liquiditätsplanung Werte konsolidieren, ohne die einzelnen Buchungsstände zu vermischen. Jede Gesellschaft hat ihren eigenen Buchhaltungsstand, ihre eigenen Fristen und oft ihre eigene Bank. Die Konsolidierung zeigt die Gruppensicht, muss aber jederzeit auf die einzelne Gesellschaft zurückführbar bleiben.

Ein praktischer Stolperstein ist der unterschiedliche Buchungsstand der Gesellschaften: Während eine Tochtergesellschaft ihre Buchhaltung bereits für die Vorwoche abgeschlossen hat, hängt eine andere noch bei Nachbuchungen. Eine konsolidierte Zahl, die diese Zeitverschiebung ignoriert, suggeriert eine Genauigkeit, die nicht besteht. Die Planung muss deshalb kennzeichnen, auf welchem Stand jede einbezogene Gesellschaft beruht.

Cash Pooling verschiebt Liquidität zwischen Konten der Gruppe und verändert damit die Aussagekraft einzelner Kontostände. Wer nur auf ein Einzelkonto schaut, sieht möglicherweise einen Engpass, der durch den Pool bereits ausgeglichen ist, oder übersieht umgekehrt eine Abhängigkeit von der Liquidität anderer Gesellschaften. Bei Kreditlinien mit Covenants kommt hinzu, dass bestimmte Kennzahlen auf Gruppenebene eingehalten werden müssen, unabhängig davon, wie die Liquidität innerhalb der Gruppe verteilt ist.

Für die technische Umsetzung bedeutet das: Die Konsolidierung mehrerer Buchhaltungs- und Bankquellen ist ein Integrationsthema, das eine saubere Datenhaltung voraussetzt, entsprechend den Grundsätzen der strukturierten Datenaufbereitung, bevor überhaupt über Warnschwellen oder Berichte gesprochen wird. Wer diesen Schritt überspringt, bekommt eine Gesamtzahl, die niemand im Unternehmen mehr im Detail erklären kann.

Wie wird die Liquiditätsplanung nachvollziehbar dokumentiert?

Nachvollziehbar wird eine Liquiditätsplanung, wenn drei Dinge protokolliert werden: welche Warnung zu welchem Zeitpunkt ausgelöst wurde, wer sie zur Kenntnis genommen hat und welche Gegenmaßnahme geprüft und mit welchem Ergebnis entschieden wurde. Diese Kette aus Warnung, Kenntnisnahme und Entscheidung ist die eigentliche Dokumentation, nicht der reine Kontostand.

Technisch bedeutet das: Jede Unterschreitung einer Warnschwelle erzeugt einen Eintrag mit Zeitstempel, betroffener Gesellschaft und Verantwortlichem. Wird eine Gegenmaßnahme geprüft, etwa das Ziehen einer Kreditlinie oder das Verschieben einer Investition, wird auch das Ergebnis dieser Prüfung festgehalten, selbst wenn die Entscheidung lautet, vorerst nichts zu tun. Genau dieses Protokoll unterscheidet eine geführte Liquiditätsplanung von einem Dashboard, das nur Zahlen anzeigt.

Im Bankgespräch zahlt sich diese Dokumentation aus, weil sie zeigt, dass Engpässe nicht überrascht haben, sondern erkannt und bewertet wurden. Bei späteren Haftungsfragen nach der Geschäftsführersorgfalt ist dieselbe Dokumentation der Nachweis, dass die Überwachungspflicht tatsächlich gelebt wurde und nicht nur auf dem Papier stand. Wo dieses Protokoll technisch abgelegt wird, hängt von der vorhandenen Landschaft ab, häufig eignet sich dafür ein bereits genutztes Ticket- oder Vorgangssystem aus dem laufenden IT-Service-Management-Betrieb.

Welche Risiken bringt eine automatisierte Liquiditätsplanung mit?

Die größten Risiken sind falsches Vertrauen in automatisch erzeugte Zahlen, veraltete Stammdaten, Schnittstellenabbrüche und Alarmmüdigkeit durch zu viele Warnungen. Jedes dieser Risiken lässt sich begrenzen, wenn es von Anfang an mitgeplant wird, statt erst nach einem Vorfall aufzufallen.

Falsches Vertrauen entsteht, wenn eine automatisch aktualisierte Vorschau als fertige Entscheidung missverstanden wird. Die Liquiditätsplanung liefert eine Grundlage, die Einschätzung von Zahlungseingängen, Kulanzfällen oder saisonalen Schwankungen bleibt bei den Verantwortlichen in Buchhaltung und Geschäftsführung. Veraltete Stammdaten, etwa falsche Zahlungsziele oder nicht gepflegte Skonto-Fristen in den Debitoren- und Kreditorendaten, verzerren die Vorschau unbemerkt; ein regelmäßiger Stammdatenabgleich vor jeder Aktualisierung fängt das ab.

Schnittstellenabbrüche zwischen Bank, DATEV und ERP-System führen dazu, dass die Planung auf einem alten Stand stehen bleibt, ohne dass dies auffällt. Eine sichtbare Alterskennzeichnung je Datenquelle und ein automatischer Hinweis bei ausbleibender Aktualisierung schaffen hier Transparenz. Alarmmüdigkeit entsteht, wenn zu viele oder zu eng gesetzte Warnschwellen ständig auslösen und irgendwann ignoriert werden; wenige, fachlich begründete Schwellen mit klarer Eskalationsstufe wirken hier zuverlässiger als eine Vielzahl automatischer Meldungen.

Diese Grenzen gelten unabhängig davon, ob die Auswertung klassisch regelbasiert oder mit Unterstützung von Sprachmodellen erfolgt, wie sie in anderen Kontexten der Beratung zu KI-gestützten Auswertungen beschrieben werden. Die Verantwortung für die Bewertung bleibt in jedem Fall bei den Menschen, die die Zahlen kennen.

Wie schützen wir Bank- und Buchhaltungsdaten?

Bank- und Buchhaltungsdaten werden über abgestufte Zugriffsrechte geschützt, bei denen Lesezugriff auf Kontoumsätze strikt von Schreibrechten für Zahlungen getrennt ist. Die Liquiditätsplanung selbst benötigt ausschließlich lesenden Zugriff, ausgeführt werden Zahlungen weiterhin über die bestehenden Bankfreigabeprozesse mit den dort üblichen Vier-Augen-Regeln.

Der Betrieb erfolgt je nach Anforderung im eigenen Rechenzentrum der Kundschaft oder in einer europäischen Cloud-Umgebung, die den regulierten PSD2-Vorgaben für Bankschnittstellen entspricht. Welches Modell passt, hängt von vorhandener Infrastruktur, internen Sicherheitsrichtlinien und der Zahl der angebundenen Gesellschaften ab, eine pauschale Empfehlung gibt es hier bewusst nicht.

Innerhalb der Anwendung werden Rollen so vergeben, dass die Buchhaltung Stammdaten und Plangrößen pflegt, die Geschäftsführung Warnschwellen und Eskalationen einsieht und externe Berater, etwa im Bankgespräch, nur auf freigegebene Auswertungen zugreifen. Jede dieser Rollen ist protokolliert, sodass jederzeit nachvollziehbar ist, wer welche Kontostände wann eingesehen hat, ohne dass dafür Zahlungsrechte notwendig wären.

Wie läuft ein Einführungsprojekt für die Liquiditätsplanung ab?

Ein Einführungsprojekt beginnt mit einer technischen Bestandsaufnahme der vorhandenen Bank-, DATEV- und ERP-Datenquellen, gefolgt von einem Pilotbetrieb mit einer einzelnen Gesellschaft, dem schrittweisen Ausbau auf weitere Gesellschaften und Konten und dem Übergang in den laufenden Betrieb mit fester Zuständigkeit. Jede Phase endet mit einer bewussten Entscheidung, ob die nächste beginnt.

In der Bestandsaufnahme wird geklärt, welche Konten, Gesellschaften und Datenquellen überhaupt einbezogen werden sollen, wie aktuell die Stammdaten in den offenen Posten sind und welche Schnittstellen bereits bestehen oder neu aufgebaut werden müssen. Diese Phase liefert auch die Grundlage für die spätere Aufwandsschätzung.

Der Pilot läuft bewusst mit nur einer Gesellschaft, damit Warnschwellen, Rollen und die Dokumentation aus dem vorherigen Abschnitt in einem überschaubaren Rahmen erprobt werden können, bevor sie auf die gesamte Gruppe übertragen werden. Erst wenn dieser Pilot fachlich abgenommen ist, folgt der Ausbau auf weitere Einheiten, häufig mit angepassten Schwellen je Gesellschaft.

Die Dauer einzelner Phasen hängt stark von der Zahl der Konten, dem Zustand der Stammdaten und der vorhandenen Schnittstellenlandschaft ab, weshalb an dieser Stelle bewusst keine pauschale Wochenangabe genannt wird. Ähnliche Vorgehensweisen aus stufenweisen Softwareeinführungen sind in unseren Referenzprojekten zur Softwareentwicklung dokumentiert und lassen sich auf ein Liquiditätsprojekt übertragen.

Was kostet die Einführung einer Liquiditätsplanung?

Belastbare Preise für eine Liquiditätsplanung lassen sich erst nach einer technischen Bestandsaufnahme nennen, da der Aufwand von der Zahl der Konten und Gesellschaften, dem Zustand der Stammdaten und der vorhandenen Schnittstellenlage abhängt. Diese Bestandsaufnahme ist deshalb selbst der erste beauftragbare Schritt, nicht ein kostenloses Vorgespräch.

Wesentliche Preisfaktoren sind die Anzahl der Bankkonten und Gesellschaften, die angebunden werden sollen, der Pflegezustand der offenen Posten in Debitoren und Kreditoren, ob DATEV-Exporte und ERP-Anbindungen bereits stabil laufen oder erst aufgebaut werden müssen, und schließlich das gewünschte Betriebsmodell zwischen eigenem Rechenzentrum und europäischer Cloud.

Je mehr Altlasten in den Stammdaten stecken und je fragmentierter die Bankenlandschaft ist, desto größer der Aufwand vor dem eigentlichen Aufbau der Vorschau. Umgekehrt lässt sich bei einer sauberen, bereits über DATEV konsolidierten Buchführung ein Pilot mit einer Gesellschaft vergleichsweise zügig aufsetzen. Eine seriöse Aussage zu Kosten setzt deshalb immer eine Bestandsaufnahme voraus, die auch andere Projekte, etwa im Bereich der Legacy-Modernisierung, grundsätzlich vorschalten.

Woran erkennen Sie, dass Ihre Liquiditätsplanung reif für den nächsten Schritt ist?

Reif für den nächsten Schritt ist eine Liquiditätsplanung, wenn Excel-Tabellen manuell zwischen mehreren Gesellschaften abgeglichen werden, Warnschwellen nicht dokumentiert sind oder Bankgespräche mit veralteten Zahlen vorbereitet werden müssen. Diese Anzeichen lassen sich anhand einer kurzen Checkliste prüfen, bevor eine Investition sinnvoll wird.

Typische Signale sind:

Treffen mehrere dieser Punkte zu, lohnt sich ein Gespräch über eine technische Bestandsaufnahme, aus der sich sehen lässt, welcher Ausbauschritt tatsächlich zum Unternehmen passt. Ein Verkaufsabschluss ist damit nicht verbunden, sondern eine belastbare Grundlage für die eigene Entscheidung.

• Mehr als eine Gesellschaft oder mehr als eine Handvoll Konten müssen von Hand zusammengeführt werden
• Zahlungseingänge und offene Posten werden nicht regelmäßig, sondern nur bei Bedarf abgeglichen
• Es gibt keine dokumentierte Warnschwelle, ab der die Geschäftsführung informiert wird
• Bankgespräche werden mit statischen, mehrere Wochen alten Tabellen vorbereitet
• Niemand kann auf Nachfrage sagen, wer eine drohende Unterdeckung zuletzt geprüft hat