Eine Kundenverpflichtung entsteht im Geschäft, die Rechnung im ERP, der Zahlungseingang auf dem Konto. Was dazwischen passiert — Mahnstufe, Zahlungsvereinbarung, Teilzahlung, Abzug, Reklamation — passiert in Postfächern und Tabellen. Am Monatsende stimmt die Summe, und trotzdem kann niemand sagen, warum ein Betrag offen ist und was als Nächstes geschieht.
Sie steht im ERP mit Betrag und Fälligkeit. Der Grund für die Überfälligkeit steht dort nicht.
Mahnung, Rückstellung, Zahlungsvereinbarung: besprochen, verschickt, notiert — meist außerhalb des Systems.
Er wird gebucht. Die Differenz zwischen erwartet und eingegangen bleibt als Restposten stehen.
Die Daten sind vorhanden. Sie werden nur in verschiedenen Systemen zu verschiedenen Zeitpunkten wirksam.
Vier Schritte, und über jedem davon dieselben Querschnittsfähigkeiten.
Jedes Modul ist ein eigenständiger Einstieg. Diese Kette zeigt, was zusammenkommt, wenn mehrere davon auf demselben Finanzmodell laufen.
In aktiver Entwicklung
Führt die Verpflichtung als Finanzobjekt: Gegenpartei, Gesellschaft, Laufzeit, Preis- und Zahlungsbedingungen. Damit ist die Forderung nicht nur eine Zahl, sondern eine Zusage mit Herkunft.
Pilot / Validierung
Altersstruktur, Maßnahme je Position, Eigentümer und Termin. Die Maßnahme hängt an der Forderung, nicht an einer Mail.
Pilot / Validierung
Kontoumsätze über alle Banken, Zuordnung zum offenen Posten, Differenzen als eigener Vorgang statt als Restbetrag.
Pilot / Validierung
Die erwartete Zahlung mit Termin und Wahrscheinlichkeit in der Vorschau — und die Korrektur, sobald eine Maßnahme greift.
In aktiver Entwicklung
Abzug, Teilzahlung und Reklamation werden ein Fall mit Eigentümer, Frist und Entscheidung — und nicht ein Merkposten.
Mahnstufe, Zahlungsvereinbarung, Abschreibung oder Eskalation — innerhalb der Befugnis, die für diese Gesellschaft und diesen Betrag gilt. Wo keine Regel eindeutig greift, entscheidet ein Mensch, und die Entscheidung bleibt am Vorgang.
Rechnung, Buchung und offener Posten entstehen dort und bleiben dort. FinanceOS führt den Vorgang darüber und schreibt keine Buchung um.
Der Kontoumsatz ist die Wahrheit der Bank. FinanceOS liest ihn und ordnet zu; die Bank bleibt die Quelle.
Kundenbeziehung und Vereinbarung bleiben im Vertriebssystem. FinanceOS nimmt daraus die finanzwirksamen Felder.
Was nicht gekennzeichnet ist, behaupten wir nicht. Den vollständigen Stand je Fähigkeit führen die Modulseiten und der Produktstand.
Nein. Die Rechnung entsteht im ERP, die Buchung bleibt dort und der offene Posten gehört weiter der Buchhaltung. Was FinanceOS ergänzt, ist der Vorgang darüber: warum ein Betrag offen ist, wer die Maßnahme verantwortet, was sie bewirkt hat und wo das nachlesbar ist.
Über Kontoumsatz, Referenz und offene Posten. Wo die Zuordnung eindeutig ist, ist sie eindeutig. Wo sie es nicht ist — Teilzahlung, Abzug, Sammelzahlung —, entsteht ein Fall mit Eigentümer statt einer Restzeile. Die Reife dieser Fähigkeit steht unten auf der Seite.
Das Limit selbst wird dort geführt, wo die Kundenbeziehung geführt wird. FinanceOS kann das Exposure aus Forderung, Auftrag und Verpflichtung zusammenführen und an die Entscheidung hängen. Als definierte Fähigkeit — nicht als heute laufende Kreditprüfung.
Bringen Sie diesen Fall mit, wie er bei Ihnen aussieht. Wir gehen ihn an Ihrem Beispiel durch und sagen, wo eine gemeinsame Finance-Ebene trägt und wo nicht.