Treasury & Liquidität
Eine Cash-Position über Banken, Gesellschaften und Währungen — und die Entscheidungen, die daraus folgen.
Verbunden mit Zahlungen, Forecast und Working Capital.
Treasury & Liquidität →
Plattformarchitektur
Different systems. One finance language.
Ein Finanzmodell über Ihren Systems of Record — das ist die ganze Architektur.
Jedes ERP und jedes Buchhaltungssystem stellt Finance auf seine eigene Weise dar: eigene Namen für eine Gesellschaft, eigene Struktur für einen offenen Posten, eine eigene Vorstellung davon, was eine Zahlung ist. Das ist kein Fehler — genau das macht die Systeme gut im Verbuchen. Es ist aber auch der Grund, warum Konzern-Finance in Tabellen endet: Es fehlt die gemeinsame Sprache, in der ein Prozess einmal definiert werden kann.
Das kanonische Finanzmodell
Was ein kanonisches Finanzmodell tatsächlich ist.
FinanceOS übersetzt die Strukturen jedes angebundenen Systems an der Integrationsgrenze in eine kleine Menge von Finanzobjekten, die überall dasselbe bedeuten. Alles oberhalb dieser Grenze — Prozesse, Kontrollen, Kennzahlen, Workflows — arbeitet auf diesen Objekten und nie auf dem Feldschema eines Systems.
Über dem Modell · Finance Operations
Sehen
Planen
Freigeben
Ausführen
Abstimmen
Nachweisen
Das kanonische Finanzmodell
Gesellschaft
Bankkonto
Partner
Verpflichtung
Zahlung
Forderung
Dokument
Periode
Unter dem Modell · Provider-Adapter
ERP- und Buchhaltungssysteme
Bankkanäle
Dokumentenquellen
Das ist die einzige Architekturentscheidung auf dieser Seite, die zählt. Alles andere — Multi-Entity, Multi-Bank, Kontrollebene, Workflows — folgt daraus.
Was daraus folgt
Drei Konsequenzen, und sie sind der Grund für das ganze Design.
1
Konsistenz
Eine Finance-Semantik. Derselbe Prozess, dieselben Kontrollen und dieselben Kennzahlen über alle angebundenen Systeme — damit eine Gruppenzahl eine Zahl ist und keine Sammlung lokaler Auslegungen.
2
Portabilität
Finance-Prozesse hängen nicht mehr an einem einzelnen ERP. Wenn eine Gesellschaft ihr Quellsystem wechselt, ändert sich der Adapter, und der Finance-Betrieb läuft weiter. Ihre Prozessinvestition ist nicht länger Geisel einer Herstellerentscheidung.
3
Skalierbarkeit
Eine neue Gesellschaft, eine neue Bank oder ein weiteres System kommt in eine bestehende Finance-Kontrollstruktur, statt eine neue Insel zu eröffnen. Wachstum vervielfacht keine Methoden mehr.
Komplexität als Normalfall
Gebaut für die Landschaft, die Sie tatsächlich haben.
Multi-Entity
Mehrere Gesellschaften, ein Prozess.
Kanonische Gesellschaften mit konsolidierter und gesellschaftsbezogener Sicht — Governance und Rechte folgen der Gesellschaft und nicht dem Gedächtnis einer Person.
Multi-ERP
Verschiedene Systeme, eine Finanzsprache.
Ein kanonischer Kern mit Provider-Adaptern am Rand. NetSuite ist der erste und tiefste Anbindungsweg als System of Record; weitere Systeme werden über dasselbe Modell angebunden und nicht über ein zweites Produkt.
Multi-Bank
Mehrere Bankbeziehungen, eine Cash-Position.
Kanonische Bankkonten je Gesellschaft und Währung — eine Cash-Position ist eine Zahl mit bekannter Zusammensetzung statt eines Vergleichs über Portale.
Multi-Currency
Fremdwährung dort, wo sie hingehört.
In Bestand, Fälligkeit, Exposure und Forecast — mit Referenzkurs und Kursdatum neben dem Wert, und ohne Wert, wenn ein Kurs fehlt.
Die Kontrollebene
Die Kontrollebene ist Teil der Architektur, kein Modul.
Weil Prozesse auf dem kanonischen Modell laufen, tun es die Kontrollen auch. Eine Regel wird einmal definiert und gilt in jeder Gesellschaft und für jedes angebundene System — genau das soll eine Gruppenrichtlinie bedeuten.
IdentitätZentrale Anmeldung, Zugriff an Personen gebunden, keine geteilten Konten.
Berechtigung über RollenSichtbarkeit und Rechte je Aufgabe und Gesellschaft, serverseitig durchgesetzt statt in der Oberfläche versteckt.
FunktionstrennungVorbereitung, Prüfung und Freigabe sind getrennte Rechte; Selbstfreigabe blockiert die Regel, nicht die Höflichkeit.
Limits und RichtlinienSchwellen und Freigabematrizen sind Konfiguration der Plattform und gelten überall identisch.
PrüfpfadEinträge auf Finanzobjekten werden angehängt. Historie lässt sich nicht still umschreiben.
DatenqualitätUnknown is not zero: Eine fehlende Quelle erzeugt eine gekennzeichnete Lücke, nie eine selbstsichere Zahl.
Workflow-Architektur
Workflow ist die Art, wie diese Ebene arbeitet.
Arbeit wird explizit
Eine Finance-Aufgabe hat einen Verantwortlichen, eine Frist und einen Zustand. Sie existiert als Objekt in der Plattform, nicht als Erwartung im Gespräch.
- Verantwortlicher je Aufgabe
- Fristen und Wiedervorlage
- Eskalation, wenn nichts passiert
Ausnahmen sind erstklassig
Was nicht passt, wird ein Fall im Arbeitsvorrat — und ein Fall kann eine Freigabe halten, statt erst aufzufallen, wenn das Geld weg ist.
- Arbeitsvorrat für Ausnahmen
- Blockierend, wo Blockieren richtig ist
- Begründung bei der Erledigung
Workflows sitzen auf Finanzobjekten
Eine Freigabe hängt an der Verpflichtung, der Zahlung oder der Forderung, um die es geht. Der Nachweis muss nie neu zusammengesetzt werden.
- Nachweis hängt am Objekt
- Historie bleibt
- Ein Vorgang über Systeme hinweg
Dieselbe Maschinerie überall
Freigabe, Collections, Abstimmung und Dokumentenbearbeitung sind dieselbe Workflow-Architektur auf unterschiedlichen Finanzobjekten — nicht vier getrennte Produkte.
- Ein Regelwerk
- Ein Prüfpfad
- Ein Ort zum Handeln
Modularität und Berechtigung
Modular in der Architektur, ein Produkt im Design.
Welche Fähigkeiten ein Mandant hat, ist eine Frage von Berechtigung und Konfiguration und nicht einer anderen Codebasis. Genau das macht eine stufenweise Einführung möglich: Sie beginnen mit einem Bereich und einer Gesellschaft, der Rest wird gegen dasselbe Modell zugeschaltet, wenn Sie dafür bereit sind.
Ein Kern, ein ModellEs gibt einen FinanceOS-Kern. Jeder Mandant arbeitet auf dem gleichen kanonischen Modell — einen Bereich zuzuschalten ist keine Migration.
Berechtigung statt AbzweigungenUmfang wird je Mandant erteilt. Niemand bekommt eine eigene Version, die separat gepflegt werden muss.
Stufenweise EinführungZuerst ein Bereich und eine Gesellschaft, end to end und kontrolliert — dann weitere Gesellschaften, Banken und Bereiche auf dieselbe Ebene.
Kommerzieller Umfang ist ein GesprächWas in Ihren Umfang gehört und in welcher Reihenfolge, legen wir mit Ihnen fest. Deshalb steht hier keine Paketmatrix.
Wie die Bereiche zusammenhängen
Die Bereiche sind keine Module. Sie sind ein Prozess, von verschiedenen Seiten gesehen.
Das ist der praktische Test der Architektur: Jeder Bereich ist allein nützlich, und jeder wird besser, weil die anderen auf demselben Modell liegen.
Zahlungen & Banking
Ein kontrollierter Freigabeweg mit Rollen, Limits und Vier-Augen-Prinzip — und die Liquiditätswirkung im selben Schritt.
Verbunden mit Treasury, Verbindlichkeiten und Fällen.
Zahlungen & Banking →Dokumente, Workflow & Fälle
Die Arbeit hinter den Zahlen: Eingang, Klassifizierung, Aufgaben, Ausnahmen, Nachweis.
Verbunden mit Zahlungen, Verbindlichkeiten und Treasury.
Dokumente, Workflow & Fälle →Cash Forecasting, Working Capital, Forderungen und Verbindlichkeiten laufen auf demselben Modell. Was wir davon in Ihrer Umgebung zuerst ansehen, ist eine Umfangsfrage und keine Architekturfrage.
Wo die Plattform endet
Was die Plattform ist — und was sie nicht ist.
Was FinanceOS ist
- Die operative Kontrollebene — die Ebene zwischen Ihren Systems of Record und Ihrem Finance-Team, auf der Finance tatsächlich betrieben wird
- Ein kanonisches Finanzmodell — damit Prozesse, Kontrollen und Kennzahlen einmal definiert werden und über angebundene Systeme gelten
- Zuerst eine Kontrollebene — Rollen, Limits, Funktionstrennung und Prüfpfad sind Architektur und keine Optionen
- ERP-neutral als Entwurf — das Quellsystem ist eine Adapterfrage; Ihre Finance-Prozesse sind es nicht
Was FinanceOS nicht ist
- Kein ERP — Ihr System of Record behält Transaktionen, Stammdaten und Buchungsautorität
- Kein Hauptbuch — FinanceOS übernimmt die Buchhaltung nicht und wird nicht das Buch der Wahrheit
- Kein BI-Werkzeug — es ersetzt Ihren Reporting-Stack nicht; es handelt, was Reporting nie tut
- Keine Punktlösung — Treasury, Zahlungen, Forderungen und Fälle sind hier ein Betrieb und nicht vier Werkzeuge
Für wen diese Seite ist
Geschrieben für die Menschen, die das entscheiden müssen.
CFOOb Finance täglich gesteuert werden kann statt monatlich berichtet.
Finance TransformationOb eine Prozessverbesserung den nächsten Systemwechsel übersteht.
CIO / ERP-VerantwortungWas angebunden und was ersetzt wird — und die Antwort lautet: nichts wird ersetzt.
Konzern-FinanceOb eine Gruppenzahl in jeder Gesellschaft dasselbe bedeutet.
Enterprise ArchitectureWo die Grenze zwischen Record und Betrieb liegt und warum sie hält.
Nächster Schritt
Bringen Sie uns Ihre Architektur, keine Anforderungsliste.
Sagen Sie uns, wie viele Systeme, Gesellschaften, Banken und Währungen im Spiel sind und wo heute die manuellen Brücken liegen. Wir melden uns innerhalb eines Werktags mit einer ehrlichen Einordnung, wo eine gemeinsame Finance-Ebene am meisten hilft — und wo nicht.
- Was danach passiert. Eine automatische Bestätigung, dann innerhalb eines Werktags eine persönliche Antwort.
- Mit wem Sie sprechen. Mit den Leuten, die die Plattform bauen, und den Architekten, die sie einführen — nicht mit einem Callcenter.
- Was Sie nicht brauchen. Keine vorbereiteten Daten, keine NDA für ein erstes Gespräch, keine Kaufabsicht.
Das Fazit
Behalten Sie Ihre Systeme. Vereinheitlichen Sie Ihre Finance Operations.
Ein Finanzmodell, eine Kontrollebene, ein Prüfpfad — über Gesellschaften, ERP-Systeme und Banken.