Produktarchitektur

Zweiundzwanzig Domains. Ein Betriebsmodell.

Auf dieser Ebene lautet die Frage nicht, ob eine Funktion vorhanden ist. Sie lautet: Deckt das meinen Bereich ab, hält es über die Bereichsgrenzen zusammen, und woran erkenne ich das? Diese Seite zeigt die vollständige Verantwortungskarte und daneben die Ketten, ohne die eine Karte nur ein Regal wäre.

Die Karte

Das ist FinanceOS.

Zweiundzwanzig Domains, gruppiert nach Verantwortung. Ein Teil bildet fachliche Finance-Bereiche ab, ein Teil gemeinsame Fähigkeiten für Daten, Autorität und Betrieb. Zusammen ergeben sie kein Modulregal, sondern ein zusammenhängendes Betriebsmodell für Finance.

A · Fachliche Finance-DomainsSechzehn Domains mit abgegrenztem fachlichem Auftrag. Sie werden modular bereitgestellt.
Steuerung und Ergebnis
Finance Control TowerPlanning · FP&A · CFO IntelligenceZiel, Plan, Forecast, Signal, Entscheidung, Maßnahme, Ergebnis — und der Rückweg in die Prämisse, gegen die geplant wurde.
Margin & ProfitabilityErgebnisrechnung · MargenbrückeWelcher Kunde, welches Produkt und welcher Vertrag das Ergebnis trägt, mit benanntem Treiber zwischen den fünf Margenstufen.
Investment, Cost & ValueOPEX · CapEx · Value GovernanceVom Antrag über Budget, Obligo und Ist bis zum geprüften Wertbeitrag gegen den beim Antrag festgehaltenen Business Case.
Workforce Planning & CostPersonalkosten · KapazitätKopfzahl, Kapazität und Personalaufwand mit Wirkungszeitpunkt, gegen Projekt- und Auftragsbedarf gerechnet.
Operativer Finanzbetrieb
TreasuryTMS · Liquidität · ZahlungsverkehrCash-Position, Liquiditäts-Forecast, Funding, Zahlungsverkehr, Risiko, Settlement, Buchung, Nachweis.
Working CapitalAR · AP · Collections · Cash ApplicationOffene Posten mit Zusage, Streitfall und Zahlungsverhalten — und der Zielkonflikt dahinter, mit Beträgen unterlegt.
Accounting OperationsFinancial Close · R2RKein zweites Hauptbuch: Kontrolle und Intelligenz über einen Abschluss, der in mehreren Ledgern und Gesellschaften stattfindet.
Group FinanceKonsolidierung · Multi-Entity · IntercompanyKonsolidierungskreis, Mapping-Governance, Group Close Control — und die Intercompany-Differenz als ein Vorgang mit Eigentümer auf beiden Seiten.
Vorgang, Vertrag und Beleg
Financial Case ManagementException · DecisionDer Entscheidungspunkt jeder Kette: Sachverhalt, Wesentlichkeit, Kontext, Option, Freigabe, Maßnahme, Wirkung, Verifikation.
Contract LifecycleCLM · VerpflichtungenDer Vertrag als Finanzobjekt: Pflichten mit Fälligkeit, Zahlungsplan, Preisgleitklauseln und ihre bilanziellen Folgen.
Document IntelligenceDMS · ECM · IDPDer Beleg weiß, wozu er gehört: er belegt eine Buchung, begründet eine Entscheidung oder stützt eine Planungsannahme.
Project FinancePSA · Projektcontrolling · NachträgeNachtrag, Restkosten, Margenbrücke, Fakturierung, Projekt-Cash — bis in Konzern-Forecast und Liquiditätsplanung.
Weitere Fachdomains
TaxSteuerposition · ComplianceDie Steuerfolge sichtbar, bevor die Entscheidung fällt. Die Ermittlung bleibt in Ihrer Tax Engine.
Revenue & BillingMonetization · Revenue RecognitionUmsatz ist nicht Abrechnung, Abrechnung ist nicht Forderung, Forderung ist nicht Cash. Vier Größen, auseinandergehalten und verbunden.
Spend & Procurement FinanceBeschaffungsfinanzenKondition, Zahlungsziel und Obligo an Liquidität und Ergebnis gehängt. Einsparung nur gegen einen vorher festgehaltenen Basiswert.
Sustainability & ESG FinanceNachhaltigkeitsfinanzenNachhaltigkeitsangaben mit derselben Belegkette wie eine Buchung, auf dem Konsolidierungskreis, mit Verantwortlichem je Angabe.
B · In jeder Domain wirksamZwei Domains, die nicht neben den anderen liegen, sondern in ihnen wirken.
Risk, Controls & ComplianceGRC · Continuous Controls MonitoringAus einem Kontrollbefund wird ein Vorgang: Wesentlichkeit, Nachweis, Eigentümer, Entscheidung, Behebung, Nachtest, Zertifizierung.
Finance AI & Agentic AutomationErklären · Empfehlen · Vorbereiten · HandelnVier Stufen mit steigender Freigabe. Handeln nur innerhalb definierter Grenzen, verantwortet von einem namentlich benannten Menschen.
C · Gemeinsames FundamentVier Domains unter allen anderen. Sie sind in jedem Einstieg enthalten, weil ohne sie keine Kette belegbar wäre.
Finance Data FabricIntegration · Kontext · HerkunftKein Mega-Schema, sondern ein kanonisches Minimum: 108 Business Objects mit Herkunft je Wert und Historie je Stand.
Identity & Access GovernanceAutorität · SecurityWer darf was, bis zu welchem Betrag, für welche Gesellschaft und welche Entscheidungsart — mit Prüfspur je Ausübung.
Data Lifecycle & RecordsPrivacy · AufbewahrungDie Aufbewahrungsfrist hängt am Finanzobjekt, nicht am Dokument in einem Ordner. Verknüpfte Objekte können sich nicht gegenseitig unterlöschen.
Platform & AdministrationBetrieb · Releases · MandantenKonfiguration statt Fork: eine Plattform, geführte Umgebungen, kontrollierter Konfigurationstransport, jedes Release für alle.
D · Systems of RecordERP und Finanzbuchhaltung, Banken, DMS und CLM, Projekt- und Abrechnungssysteme, Steuer- und Konsolidierungssysteme behalten ihre fachliche Autorität.
ERP und FiBuBankenDMS · CLMPSA · PayrollSteuer · Konsolidierung

Zweiundzwanzig Domains sind kein Produktkatalog, sondern die Verantwortungskarte eines Betriebsmodells. Die fachlichen Domains werden modular bereitgestellt, das Fundament ist immer dabei. Wie FinanceOS eingesetzt und kommerziell paketiert wird, folgt aus der Architektur nicht eins zu eins.

Wir sagen Domain, wo es um die Verantwortung geht, und Modul, wo es um das Produkt geht. Gemeint ist dasselbe.

Produkttiefe

Woran ein Finance-Verantwortlicher erkennt, ob dahinter ein Produkt steht.

Diese Zahlen sind kein Leistungsversprechen. Sie sagen, wie tief das Produktmodell entschieden ist. Genau daran unterscheidet sich ein durchmodelliertes Produkt von einer Sammlung von Bildschirmen.

Produktarchitektur

22Finance-Domains mit abgegrenzter Verantwortung597Product Areas innerhalb dieser Domains3.463Product Functions, davon 3.450 fest zugeordnet und 13 bewusst als Querschnitt geführt

Cross-Functional Finance

23Familien fachübergreifender Finance-Prozesse93durchmodellierte End-to-End-Finance-Ketten807Prozessschritte in diesen Ketten121benannte Übergaben zwischen Domains

Datenmodell

108Business Objects im kanonischen Kern61Financial Effects

Produktwissen

3.230qualifizierte User Stories15.500qualifizierte Akzeptanzkriterien

121 benannte Übergaben.

Zwischen einem Finance-Werkzeug und einem Betriebsmodell liegt nicht die Oberfläche, sondern die Frage, ob die Übergaben zwischen Fachbereichen modelliert sind. Jede dieser 121 Übergaben ist benannt: welches Objekt übergeht, welcher Zustand gilt, wer ab dann verantwortet und was mitgeht. Genau diese Strecke erledigen heute in den meisten Häusern Menschen per Mail.

15.500 Mal festgelegt, wann etwas stimmt.

Eine Anforderung ohne Akzeptanzkriterium ist eine Absicht. Erst das Kriterium legt fest, wann eine Fähigkeit fachlich korrekt arbeitet, und macht sie prüfbar — für uns in der Entwicklung und für Sie in der Abnahme. Im Schnitt knapp fünf Kriterien je Story.

Jede dieser Zahlen hat auf dieser Seite genau eine Definition. Wo sie an anderer Stelle vorkommt, steht sie für dasselbe.

Der waagerechte Träger

Zweiundzwanzig senkrechte Domains brauchen eine Stelle, an der entschieden wird.

Financial Case Management steht in der Karte bei Vorgang, Vertrag und Beleg — es ist eine Domain mit abgegrenzter Verantwortung. Wirksam ist es quer durch alle: der Execution Backbone, auf dem jede der 93 Ketten ihren Entscheidungspunkt findet.

Sachverhalt und WesentlichkeitAus Betrag und Wesentlichkeit leitet sich ab, wer entscheiden muss.
Objekte, Dokumente, NachweiseDer Fall trägt seine Belege, Buchungen und Verträge bei sich.
Optionen und FreigabeHandlungsoptionen mit erwarteter Wirkung, Freigabe nach Autorität.
Maßnahme und ErgebnisWas getan wurde, von wem, bis wann, mit welcher finanziellen Wirkung.
Verifikation und AbschlussErwartete gegen tatsächliche Wirkung. Der Abschluss ist eine Aussage.

Das ist kein Ticketsystem. Ein Ticket kennt einen Status. Ein Financial Case kennt eine finanzielle Wirkung, eine Entscheidungsinstanz und einen Nachweis.

Und zwei Domains, die in jeder anderen wirken

Risk, Controls & Compliance

Aus einem Kontrollbefund wird ein Vorgang: Wesentlichkeit, Nachweis, Eigentümer, Entscheidung, Behebung, Nachtest, Zertifizierung.

Finance AI & Agentic Automation

Vier Stufen mit steigender Freigabe. Handeln nur innerhalb definierter Grenzen, verantwortet von einem namentlich benannten Menschen.

Fall, Kontrolle und Autorität sind der Grund, warum die Karte kein Regal ist: sie wirken in jeder Domain und nicht daneben.

Die zweite Achse

Die Karte sagt, wer verantwortet. Die Ketten sagen, wie gearbeitet wird.

Software wird nach Zuständigkeit gebaut und gekauft. Ein Geschäftsvorgang läuft quer dazu. Deshalb modelliert FinanceOS 93 End-to-End-Ketten in 23 Familien — dieselben Domains, andere Achse.

Cross-Functional Finance Der Regelkreis in zwölf Stationen und acht der 93 Ketten
Die Achse ansehen
Featured Business Bundles Sechs typische Einstiege, jeder über mehrere Domains
Einstiege ansehen
Beleg bis Entscheidung Eine Kette in voller Länge, mit Übergaben und Nachweis
Kette lesen

Ohne die Ketten wäre die Karte ein Modulregal. Ohne die Karte wären die Ketten Integrationsprojekte. Beide Achsen sind derselbe Produktentwurf, von derselben Datenbasis und demselben Nachweismodell getragen.

Grenze

Was FinanceOS nicht übernimmt.

Ebene D der Karte ist keine Aufzählung von Schnittstellen, sondern eine Architekturaussage: fachliche Produktverantwortung ist nicht dasselbe wie der Besitz des operativen Quellsystems.

ERP und FiBu

Transaktion, Buchung, Abschluss.

Banken

Konten, Zahlungsverkehr, Settlement.

DMS und CLM

Speicherung, Authoring, Unterschrift.

PSA und Payroll

Projektabwicklung, Zeiterfassung, Abrechnung.

Die operative Wahrheit bleibt bei den Quellsystemen. FinanceOS führt den gemeinsamen Kontext und weiß, woher jeder Wert stammt. Zwei oder drei ERPs nach Zukäufen sind dafür der Normalfall.

FAQ

Sechs Fragen, die auf dieser Ebene immer kommen.

Sind das 22 Produkte, die ich einzeln kaufe?

Nein. Die 22 Domains definieren die Produktarchitektur. Wie FinanceOS eingesetzt und kommerziell paketiert wird, folgt daraus nicht eins zu eins. Sechs typische Einstiege zeigen die Business Bundles.

Muss ich alle 22 Domains einführen?

Nein. Die fachlichen Domains werden modular bereitgestellt. Das gemeinsame Fundament — Datenmodell, Autorität, Aufbewahrung, Betrieb — ist in jedem Einstieg enthalten, weil ohne es keine Kette belegbar wäre.

Was ist der Unterschied zwischen einer Domain und einer Kette?

Eine Domain hat einen abgegrenzten fachlichen Auftrag: wer wofür verantwortet. Eine Kette ist ein Ablauf quer durch mehrere Domains, von einem operativen Ereignis bis zur verifizierten finanziellen Wirkung. 22 Domains, 93 Ketten und 121 benannte Übergaben dazwischen.

Ersetzt FinanceOS mein ERP?

Nein. ERP und Finanzbuchhaltung, Banken, DMS und CLM, Projekt- und Abrechnungssysteme sowie Steuer- und Konsolidierungssysteme behalten ihre fachliche Autorität. FinanceOS verbindet Kontext, Kontrolle, Entscheidung und Nachweis darüber. Der Grundsatz steht auf Systems of Record.

Warum liegen Autorität und Aufbewahrung im Fundament und nicht in der Administration?

Weil ein System, das Entscheidungen über Finanzsachverhalte führt, nur so belastbar ist wie die Antwort auf zwei Fragen: Wer durfte das, und woran ist es belegt. Deshalb sind beide im Produktmodell Querschnitt und liegen unter allen 22 Domains.

Sind alle 22 Domains gleich weit?

Nein, und wir kennzeichnen das. Was heute im Produkt verifiziert ist, steht auf der jeweiligen Domainseite und zusammengefasst auf dem Produktstand.

Stand

Was an dieser Architektur heute im Produkt verifiziert ist

Kanonischer Kern und Autorität

Im Produkt verifiziert

Die Business Objects mit Herkunft je Wert, die Rollen- und Betragslimits und die Prüfspur je Ausübung einer Befugnis.

Wirkungsverifikation

Pilot oder Validierung

Die letzte Station einer Kette gegen eine vorher festgehaltene Basis.

Gleichmäßige Tiefe über alle Domains

In aktiver Entwicklung

Nicht jede der 22 Domains ist gleich weit. Was heute trägt, steht auf der jeweiligen Domainseite.

Was nicht gekennzeichnet ist, behaupten wir nicht.

Reifegrade je Fähigkeit stehen auf den Domainseiten. Was wir heute belegen können

Gespräch

Legen Sie Ihre Systemlandschaft neben diese Karte.

Vierzig Minuten mit einem Architekten, keine Präsentation. Sie sagen, welche Systeme führend bleiben und welche zwei Strecken heute Handarbeit sind. Wir sagen, welche Domains das betrifft, welche Kette darüber läuft und was das Fundament davon mitbringt.

Architekturgespräch anfragen Cross-Functional Finance ansehen
Wie langeVierzig Minuten, mit einem Architekten
Was Sie mitbringenIhre Systemlandschaft und zwei Strecken, die heute Handarbeit sind
Was danach klar istWelche Domains betroffen sind und was das Fundament abdeckt