Eine Bestellung, ein Rahmenvertrag, eine mündliche Zusage im Fachbereich: das Geld ist gebunden, sobald zugesagt wurde. In den Zahlen erscheint es mit der Rechnung, manchmal erst mit der Zahlung. Bis dahin steht die Bindung in einer Bestellliste, einem Vertrag und einer Abgrenzungstabelle — drei Orte, drei Zeitpunkte.
Bestellung im Einkaufssystem, Rahmenvertrag in der Ablage, Abruf per Mail. Das Obligo ergibt sich aus dreien.
Sie kommt, wird geprüft und freigegeben. Ob sie zu einer Zusage gehört, prüft ein Mensch aus dem Gedächtnis.
Am Periodenende wird geschätzt, was geliefert und noch nicht fakturiert ist. Die Grundlage dafür ist selten belegt.
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 Budget, Deckung und Obligo an einem Objekt: was zugesagt ist, was davon verbraucht ist, was noch aussteht.
In aktiver Entwicklung
Der Rahmenvertrag mit Laufzeit, Preisen und Kündigungsfristen — und der Abruf, der daraus eine konkrete Verpflichtung macht.
Pilot / Validierung
Zahlungsläufe mit Funktionstrennung und Limits; die Freigabe wird serverseitig geprüft, nicht im Formular.
In aktiver Entwicklung
Die Abgrenzung entsteht aus dem Obligo und dem Lieferstand, nicht aus einer Schätzung ohne Grundlage.
In aktiver Entwicklung
Rechnung ohne Zusage, Preisabweichung, offene Lieferung: ein Fall mit Eigentümer und Frist statt einer Rückfrage per Mail.
Freigeben, zurückweisen, teilweise anerkennen oder eskalieren — innerhalb der Befugnis, die für diese Gesellschaft, diesen Lieferanten und diesen Betrag gilt. Vier-Augen dort, wo die Regel es verlangt, und keine Freigabe, wo die Regel nicht eindeutig ist.
Bestellung, Wareneingang und Buchung entstehen dort und bleiben dort. FinanceOS führt Obligo, Fall und Nachweis darüber.
Die Zahlung verlässt das Haus über die Bank. FinanceOS bereitet den Lauf vor und führt die Freigabe; die Ausführung bleibt beim Bankkanal.
Stammdaten und Bankverbindungen bleiben im führenden System. FinanceOS nutzt sie und ändert sie nicht.
Was nicht gekennzeichnet ist, behaupten wir nicht. Den vollständigen Stand je Fähigkeit führen die Modulseiten und der Produktstand.
Nein. Bestellung und Wareneingang bleiben dort, wo der Einkauf arbeitet. Die Frage dieser Kette ist eine andere: wann eine Zusage in den Zahlen ankommt, wer sie freigibt und woran die Abgrenzung am Periodenende hängt.
Wir behaupten hier keine Erkennung. Was diese Kette leistet, ist Sichtbarkeit und Kontrolle: eine Rechnung ohne Zusage wird ein Fall, die Freigabe wird serverseitig gegen Funktionstrennung und Limit geprüft, und jede Freigabe bleibt nachlesbar.
Aus dem Obligo und dem Lieferstand, die beide im Vorgang stehen. Damit hat die Abgrenzung eine Grundlage, die man am Objekt nachlesen kann — statt einer Zahl, die am Periodenende entsteht.
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.