Liquiditätsplanung aus SAP-, Oracle- und NetSuite-Daten

Das Wichtigste in Kürze

• Eine debitoren- und kreditorenbasierte Liquiditätsprognose braucht sechs Datenbestände aus dem ERP, jeweils mit dem Datum, aus dem sich der Zahlungszeitpunkt ableiten lässt.
• Offene und ausgeglichene Posten sowie Kontoauszüge ziehen Sie täglich und legen jeden Extrakt als Stichtagsstand ab.
• Für 49 % von 425 befragten Treasury-Fachleuten ist die Cash- und Liquiditätsprognose die schwierigste Aufgabe im Treasury (AFP, 2026).
• CashPulse von Transformance erreicht auf Sicht von bis zu 90 Tagen eine Prognosegenauigkeit von 90 bis 95 % (100 minus MAPE). Der erste 13-Wochen-Forecast steht nach 2 bis 4 Wochen.

In diesem Artikel

• Das Wichtigste in Kürze
• Welche ERP-Daten braucht die Liquiditätsplanung?
• Welche SAP-Tabellen speisen die Liquiditätsplanung?
• Welche Oracle- und NetSuite-Datensätze speisen die Liquiditätsplanung?
• Wie oft sollten Sie ERP-Daten für die Liquiditätsprognose ziehen?
• Welche Datenprüfungen gehören vor die Prognose?
• Wie messen Sie die Genauigkeit einer Prognose aus ERP-Daten?
• Wie nutzt CashPulse Daten aus SAP, Oracle und NetSuite?

Welche ERP-Daten braucht die Liquiditätsplanung?

Eine Liquiditätsplanung aus ERP-Daten braucht sechs Datenbestände: offene Forderungen, die Zahlungshistorie der Kunden, offene Verbindlichkeiten, Bestellungen, noch nicht fakturierte Kundenaufträge und Kontoauszüge.

Eine debitorenbasierte Liquiditätsprognose ist eine Prognose der Einzahlungen, die auf den offenen Kundenposten und dem Zahlungsverhalten jedes einzelnen Kunden beruht. Eine kreditorenbasierte Prognose macht dasselbe für die Auszahlungen und stützt sich auf offene Lieferantenposten, Ihren Zahllaufkalender und das Obligo aus offenen Bestellungen. Zusammen ergeben beide die kurzfristige Prognose nach der direkten Methode.

Das Kernproblem: Das ERP speichert Fälligkeiten, doch Kunden zahlen nicht am Fälligkeitstag. Die Zahlungshistorie rechnet das eine ins andere um: Die Verzugstage (Days Beyond Terms) sind das Ausgleichsdatum minus die Nettofälligkeit, und ihr Durchschnitt je Kunde verschiebt jede offene Rechnung auf den Tag, an dem sie voraussichtlich bezahlt wird.

Die Cash- und Liquiditätsprognose bleibt die schwierigste Aufgabe im Treasury: 49 % von 425 befragten Treasury-Fachleuten nennen sie (AFP, 2026). Von den 213 Teilnehmern der Global Corporate Treasury Survey von Deloitte halten nur 18 % ihre Prognosefähigkeiten für mindestens überdurchschnittlich. Bei vielen läuft die Prognose noch überwiegend in Tabellenkalkulationen (Deloitte, 2024).

Fiktives Beispiel: Eine Rechnung ist am Montag, 30. November 2026, fällig, und der Kunde zahlt im Schnitt 11 Tage zu spät. Der Zahlungseingang gehört auf Freitag, den 11. Dezember, also in die Woche ab 7. Dezember und nicht in die Woche ab 30. November (Zahlungseingänge aus offenen Forderungen vorhersagen).

‍

‍

Welche SAP-Tabellen speisen die Liquiditätsplanung?

In SAP S/4HANA liegen die Debitoren- und Kreditorenposten im Universal Journal (ACDOCA) und in BSEG; BSID, BSIK, BSAD und BSAK gibt es weiterhin als gleichnamige Views.

In ECC sind BSID und BSIK die Indextabellen für offene Debitoren- und Kreditorenposten, BSAD und BSAK die für ausgeglichene. Laut SAP-Konvertierungsleitfaden wurden diese Indextabellen in S/4HANA „durch SAP-HANA-Views mit denselben Namen ersetzt“, und ACDOCA „enthält alle Einzelposten aus FI“ (SAP, Konvertierungsleitfaden S/4HANA 1511). Bestehende Lesezugriffe funktionieren also weiter. Solange die Migration läuft, legen Sie die Extraktion so an, dass sie auf beiden Systemen läuft (Playbook zum ECC-Wartungsende).

Je Einzelposten ergeben sich aus dem Basisdatum und dem Schlüssel der Zahlungsbedingungen die Nettofälligkeit und das Skontodatum; bei ausgeglichenen Posten liefert das Ausgleichsdatum die Zahlungshistorie. Kunden, die regelmäßig Skonto ziehen, zahlen früh, deshalb planen Sie ihre Posten auf das Skontodatum.

Über die offenen Posten hinaus:

• Kundenaufträge und Fakturierungspläne: VBAK und VBAP enthalten Kopf und Positionen der Kundenaufträge, auch der noch nicht fakturierten; Fakturierungspläne halten die geplanten Fakturatermine fest.
• Bestellungen: EKKO und EKPO enthalten Bestellkopf und -positionen, die Einteilungen in EKET das Lieferdatum der Position und EKBE die Bestellentwicklung mit Waren- und Rechnungseingängen. Das Bestellobligo, also der Bestellwert ohne Rechnungseingang, ist der Mittelabfluss, den die offenen Kreditorenposten noch nicht zeigen.
• Zahlläufe: Wann die Kreditorenbuchhaltung tatsächlich zahlt, entscheidet der Terminplan Ihres automatischen Zahlprogramms.
• Elektronische Kontoauszüge: die Istwerte, mit Valutadatum und Buchungsdatum je Position.

Planen Sie je Buchungskreis und eliminieren Sie anschließend konzerninterne Posten auf Konzernebene (Liquiditätsplanung im Konzern). Wie ein Agent in FI-AR liest und schreibt: KI-Agenten und SAP.

Welche Oracle- und NetSuite-Datensätze speisen die Liquiditätsplanung?

In Oracle enthält AR_PAYMENT_SCHEDULES_ALL eine Zeile je Rate einer Rechnung, mit Fälligkeitsdatum und offenem Betrag; in NetSuite sind Rechnungen, Lieferantenrechnungen und Aufträge Transaktionsdatensätze, unterschieden nach Typ.

Laut Oracle speichert AR_PAYMENT_SCHEDULES_ALL „alle Transaktionen außer Anpassungen und sonstigen Zahlungseingängen“ (Oracle, Fusion 26A, 2026). DUE_DATE ist das Fälligkeitsdatum der Rate, AMOUNT_DUE_REMAINING der offene Betrag. STATUS wechselt von OP auf CL, sobald nichts mehr offen ist. ACTUAL_DATE_CLOSED ist das Datum, an dem eine Zahlung oder Gutschrift zugeordnet wurde; es kann nach dem tatsächlichen Geldeingang liegen.

AP_PAYMENT_SCHEDULES_ALL enthält die geplanten Zahlungen je Lieferantenrechnung, mit Fälligkeitsdatum und einem Kennzeichen für den Zahlungsstatus: Y bezahlt, N unbezahlt, P teilweise bezahlt (Oracle, Fusion 26A). Bestellungen liegen in PO_HEADERS_ALL und PO_LINES_ALL, Kontoauszugszeilen in CE_STATEMENT_LINES.

In den SuiteAnalytics-Datensatzdefinitionen von NetSuite sind Rechnungen, Kundenzahlungen, Gutschriften, Lieferantenrechnungen, Lieferantenzahlungen, Bestellungen und Kundenaufträge ein gemeinsamer Transaktionsdatensatz, unterschieden nach transaction.type: CustInvc, CustPymt, CustCred, VendBill, VendPymt, PurchOrd, SalesOrd (Oracle NetSuite, Hilfecenter). In OneWorld lesen Sie je Tochtergesellschaft. Übliche Zugriffswege sind gespeicherte Suchen, SuiteAnalytics Workbooks und SuiteQL; welchen Sie nutzen, stimmen Sie mit Ihrem NetSuite-Administrator ab (Schnittstellenwahl für NetSuite).

Wo die Daten für die Liquiditätsplanung in SAP, Oracle und NetSuite liegen

Die Objektnamen unterscheiden sich je nach Release; lassen Sie sie von Ihrem ERP-Team bestätigen.

Wie oft sollten Sie ERP-Daten für die Liquiditätsprognose ziehen?

Offene und ausgeglichene Posten sowie Kontoauszüge ziehen Sie täglich, ebenso Bestellungen und Kundenaufträge, soweit sie in den 13-Wochen-Horizont fallen. Bei Stammdaten und Zahlungsbedingungen genügt ein wöchentlicher Lauf.

Die ersten Wochen einer 13-Wochen-Liquiditätsplanung ändern sich täglich: Eine Zahlung, die heute Morgen ausgeglichen wurde, streicht einen erwarteten Zahlungseingang aus der nächsten Woche. Wer nur wöchentlich aktualisiert, rechnet ihn weiter mit.

• Delta-Extraktion statt Vollladung: nur die seit dem letzten Lauf geänderten Datensätze, mit einem täglichen Abgleich der Summen mit dem Hauptbuch.
• Jeden Prognosetag als Stichtagsstand sichern. Das ERP zeigt heute nicht mehr, was am Tag der Prognose offen war; ohne Stichtagsstände lässt sich keine Prognose sauber nachträglich testen.
• Das Valutadatum der Bank verwenden. Oracle beschreibt es als das Datum, an dem die Mittel „dem Kontoinhaber zur Verfügung stehen“ (Oracle, Fusion 26A); MT940 und camt.053 führen es neben dem Buchungsdatum.
• Einen Stichzeitpunkt je Gesellschaft festlegen, nach deren letztem Kontoauszug und Zahllauf, damit sich keine Tagesstände aus verschiedenen Zeitzonen vermischen.

Welche Datenprüfungen gehören vor die Prognose?

Bevor ERP-Daten in die Liquiditätsprognose gehen, stehen sieben Prüfungen an: mit dem Hauptbuch abgleichen, bereits bezahlte Posten herausnehmen, Klärungsfälle kennzeichnen, konzerninterne Posten eliminieren, Währungen umrechnen, Datumsfelder kontrollieren und einen Stichtagsstand sichern.

Sieben Prüfungen, bevor ERP-Daten in die Liquiditätsprognose gehen

1. Gleichen Sie offene Forderungen und Verbindlichkeiten täglich mit dem Saldo im Hauptbuch ab, je Gesellschaft und Währung.
2. Entfernen Sie Posten, die bezahlt, aber noch nicht ausgeglichen sind: Ordnen Sie zuerst die heutigen Zahlungseingänge auf dem Kontoauszug zu, sonst zählt die Prognose dieses Geld doppelt.
3. Kennzeichnen Sie strittige und gekürzt bezahlte Posten anhand von Klärungsfällen, Abzugsgründen oder Notizen und planen Sie sie gesondert.
4. Eliminieren Sie konzerninterne Posten, bevor Sie die Gesellschaften zusammenrechnen.
5. Rechnen Sie jede Währung mit derselben Kursquelle und demselben Kursdatum um und führen Sie die Transaktionswährung für Währungsszenarien mit.
6. Prüfen Sie die Datumsfelder: Posten ohne Basisdatum, offene Posten mit weit zurückliegender Fälligkeit, Bestellungen mit überschrittenem Lieferdatum ohne Wareneingang.
7. Legen Sie die geprüfte Liste der offenen Posten als datierten Stichtagsstand ab, damit sich jede Prognose nachträglich testen lässt.

Für die Einzahlungen zählen die Prüfungen 2 und 3 am meisten. Eine Zahlung, die noch auf den Zahlungsabgleich wartet, lässt ihre Rechnung offen aussehen. Eine strittige Rechnung sieht aus, als käme der volle Betrag pünktlich. Beides lässt die Prognose zu hoch ausfallen (Leitfaden zur Prognosegenauigkeit). Jedes ERP erfasst Klärungsfälle anders; stimmen Sie deshalb mit der Debitorenbuchhaltung ab, wo sie bei Ihnen liegen.

‍

‍

Wie messen Sie die Genauigkeit einer Prognose aus ERP-Daten?

Die Genauigkeit einer Prognose aus ERP-Daten messen Sie am Kontoauszug. Vergleichen Sie jede Wochenprognose, erstellt aus dem Stichtagsstand ihres Prognosetags, mit den tatsächlichen Zahlungseingängen, und zwar für jeden Horizont, mit dem Sie planen.

Was MAPE, WAPE und Bias bedeuten, erklärt der Beitrag Liquiditätsplanung mit KI genauer planen; was eine Angabe wie 90 % aussagt, steht in Wie genau ist eine Liquiditätsprognose mit KI? Speziell für ERP-Daten gilt:

• Gleiche Abgrenzung: Prognose und Istwert beziehen sich auf dieselbe Gesellschaft, dieselbe Währung und dieselbe Woche.
• Istwerte von der Bank: maßgeblich ist das Valutadatum der Bank, nicht das Ausgleichs- oder Zuordnungsdatum im ERP, das Tage nach dem Geldeingang liegen kann.
• Fehler je Datenbestand: Bewerten Sie offene Forderungen, noch nicht fakturierte Aufträge und Auszahlungen aus Bestellungen getrennt; so sehen Sie, welche Extraktion Sie nachbessern müssen.

Wie nutzt CashPulse Daten aus SAP, Oracle und NetSuite?

CashPulse von Transformance stützt die Prognose auf aktuelle Debitoren- und Kreditorendaten aus SAP, Oracle, NetSuite oder Dynamics. Auf Sicht von bis zu 90 Tagen liegt die Prognosegenauigkeit bei 90 bis 95 % (100 minus MAPE).

Über die ERP-Daten hinaus weiß CashPulse, welche Zahlungen ClearMatch zugeordnet hat, für welche Rechnungen eine Zahlungszusage aus CollectPulse vorliegt, welche Rechnungen ClaimIQ als strittig markiert hat und welche Lieferantenzahlungen fällig sind. Damit liegen die Informationen für die Prüfungen 2 und 3 bereits vor.

• Modellumfang: über 100 Treiber, über 20 Länder in einem einzigen Modell, Horizonte von 30, 90 und 365 Tagen. Der erste 13-Wochen-Forecast steht nach 2 bis 4 Wochen; ein Proof of Value für eine Gesellschaft dauert 4 bis 5 Wochen.
• Zugriff und Kontrolle: Die Daten bleiben in Ihrer Region, für EU-Kunden also in der EU. Auf Wunsch betreiben Sie die Software in Ihrer eigenen Cloud (VPC). Der Zugriff läuft über SSO/SAML und RBAC mit lückenlosem Audit-Trail; Buchungen im ERP gibt ein Mensch frei (wie KI-Agenten sicher auf ERP-Daten zugreifen).
• Ein Datensatz je Kunde: Vero, der KI-Agent von Transformance, arbeitet in Microsoft Teams und mit Customer 360, einem Graphen je Kunde. So liegen die Rechnungen, Zahlungszusagen und Klärungsfälle hinter den erwarteten Zahlungseingängen eines Kunden an einem Ort.

Fazit: Planen Sie mit dem Tag, an dem das Geld tatsächlich fließt

Ob SAP, Oracle oder NetSuite: Eine Liquiditätsprognose aus ERP-Daten steht und fällt mit der Umrechnung von Fälligkeiten in Zahltermine, der täglichen Extraktion und den Stichtagsständen. Beginnen Sie mit offenen Posten, Zahlungshistorie und Kontoauszügen; Bestellungen und Kundenaufträge kommen hinzu, sobald die ersten 13 Wochen stabil stehen.

Häufig gestellte Fragen

Welche ERP-Daten brauchen Sie für eine Liquiditätsplanung?

Sie brauchen offene Forderungen, die Zahlungshistorie der Kunden, offene Verbindlichkeiten, Bestellungen, noch nicht fakturierte Kundenaufträge und Kontoauszüge, jeweils mit dem Datum, aus dem sich der Zahlungszeitpunkt ableiten lässt.

Welche SAP-Tabellen enthalten die offenen Posten für die Liquiditätsplanung?

In SAP ECC liegen offene Debitoren- und Kreditorenposten in den Indextabellen BSID und BSIK, ausgeglichene Posten in BSAD und BSAK. In S/4HANA sind diese Namen Views; die Einzelposten liegen im Universal Journal (ACDOCA) und in BSEG.

Welche Oracle-Tabelle enthält die Fälligkeitsdaten der Rechnungen?

In Oracle Receivables enthält AR_PAYMENT_SCHEDULES_ALL eine Zeile je Rate einer Rechnung, mit Fälligkeitsdatum und offenem Betrag. Die Raten der Lieferantenrechnungen liegen in AP_PAYMENT_SCHEDULES_ALL.

Warum reicht das Fälligkeitsdatum für eine Liquiditätsprognose nicht aus?

Das Fälligkeitsdatum sagt, wann der Kunde zahlen soll, nicht, wann er zahlt; erst die Zahlungshistorie jedes Kunden macht aus Fälligkeiten erwartete Zahltermine.

Wie oft sollten ERP-Daten für die Liquiditätsprognose aktualisiert werden?

Offene und ausgeglichene Posten sowie Kontoauszüge sollten täglich aktualisiert werden. Jeden Extrakt legen Sie als datierten Stichtagsstand ab, damit sich die Prognose nachträglich testen lässt.

Welche Software für die Liquiditätsplanung lässt sich an SAP, Oracle und NetSuite anbinden?

CashPulse von Transformance lässt sich an SAP S/4HANA und ECC, Oracle, NetSuite und Dynamics anbinden. Auf Sicht von bis zu 90 Tagen liegt die Prognosegenauigkeit bei 90 bis 95 % (100 minus MAPE), und der erste 13-Wochen-Forecast steht nach 2 bis 4 Wochen.