Liquiditätsplanung: bezahlte Rechnungsanteile nicht doppelt zählen

Setzen Sie einen bereits im Banksaldo enthaltenen Eingang nicht erneut als künftigen Zufluss ein. Beginnen Sie die Liquiditätsplanung mit einem festen Bankstichtag und ergänzen Sie nur verbleibende erwartete Einzahlungen/Auszahlungen samt Zeitannahmen. Ein Rechnungsfälligkeitstag beweist keinen Bankankunftstag.

Tatsächliches Geld und künftige Erwartungen trennen

Istwerte sind hier historische Bankbeobachtungen bis zum Stichtag, Erwartungszeilen dagegen Annahmen späterer Perioden. Anfangsliquidität ist der belegte Grenzsaldo, kein neuer Zufluss zusätzlich zu allen historischen Transaktionen.

1. Fixieren Sie Kontoumfang, Währung, Stichtag und Quellversion. Bewahren Sie Anfangssaldo und historische Eingangskennungen auf.
2. Erfassen Sie je offener Rechnung ursprünglichen Betrag, separat belegte Eingänge und Rest. Behalten Sie die Rechnungszuordnung; ein ähnlicher Banktext ist kein automatischer Treffer.
3. Ordnen Sie den Rest nur bei belegter oder ausdrücklich angenommener Zeitbasis einer erwarteten Periode zu. Unbekannte Zeitpunkte bleiben sichtbar ohne Periodenzuordnung.
4. Trennen Sie erwartete Abflüsse von tatsächlichen Zahlungen und kennzeichnen Sie Datums-/Betragsannahmen. Kombinieren Sie Währungen nicht ohne dokumentierte Umrechnung.
5. Berechnen Sie je Szenario Anfang plus erwartete Zuflüsse minus erwartete Abflüsse. Behalten Sie eine Alternative ohne unsicheren Eingang und nennen Sie die geänderte Annahme.

Die australische Cashflow-Anleitung trennt Istwerte und Schätzungen und nennt Anfang/Zufluss/Abfluss/Ende. Ihre GST-Angaben sind keine globale Steuerregel. Hier dient die Rechnung einer Planungstabelle, keinem gesetzlichen Abschluss oder garantierten Guthaben.

Den offenen Rest vor der Periodenzuordnung lesen

Im fiktiven EUR-Fall beträgt die Anfangsliquidität 500 und enthält den historischen Eingang H1=100 bereits. Rechnung I1 war 400 und ist ausdrücklich H1 zugeordnet, also bleiben 300 offen. Das Szenario nimmt deren Eingang im November an und erwartet einen Abfluss 200 in diesem Monat.

Das Eingangsszenario endet mit 600: 500+300−200. Die Alternative ohne den unsicheren Eingang endet mit 300: 500−200. H1 nochmals hinzuzufügen würde einen bereits enthaltenen Betrag doppelt zählen. Kein Ergebnis sagt den tatsächlichen Banksaldo voraus.

Eine weitere offene Rechnung I2=50 hat keinen Eingangstermin. Behalten Sie sie als nicht zugeordnete Erwartung, statt sie im November zu platzieren oder das unbekannte Datum durch Fälligkeit zu ersetzen. Die Tabelle darf 50 offen ausweisen, ohne sie zum bestätigten Novemberzufluss zu machen.

Das fiktive Ist-/Erwartungsregister und die ausgeführte Szenariorechnung lesen vorgegebene Zeilen und berechnen diese begrenzten Ergebnisse. Sie erschließen keine Eingangsdaten, verbinden keine Rechnungen, führen kein Excel aus und messen keine Prognosegenauigkeit.

Tabellen summieren, ohne Unsicherheit zu verbergen

Microsofts SUMIFS-Dokumentation beschreibt Summen mit mehreren Kriterien. Sie validiert weder Lieferanten-/Kundenidentität noch Eingangszuordnung oder realistische Erwartungsdaten. Eine Formel kann falsch klassifizierte Zeilen korrekt addieren.

Trennen Sie in der Tabelle Ist/Erwartung, Währung und Szenario/Periode vor dem Summieren. Behalten Sie Quellkennungen und Datumsbasis am Wert, damit geänderte Annahmen nachvollziehbar bleiben. Leere Daten gehören auf die Ausnahmeliste und dürfen nicht still aus einer beruhigenden Gesamtsumme verschwinden.

Bei neuem Geldeingang sichern Sie das alte Szenario und markieren die Beobachtung am nächsten Stichtag als tatsächlich. Berechnen Sie den Rechnungsrest anhand belegter Eingänge neu, statt alte Prognose und neuen Bankeingang nebeneinander zu behalten. So bleibt eine Erwartungsänderung sichtbar, ohne Geld doppelt zu zählen.

Historische Vergleiche erläutert der Bankabgleich. Liegt die Bankquelle nur als PDF vor, laden Sie LocalExtract herunter, extrahieren ein PDF lokal in date,description,amount-CSV und prüfen am Original. Die App erstellt keine Liquiditätsprognosen, klassifiziert keine Rechnungen und garantiert keine Zahlung.

Offizielle Dokumentation geprüft am 17. Oktober 2026. Beispiel zur beleggestützten Planung, keine individuelle Finanz- oder Steuerberatung.