At this level the question is not whether a function exists. It is: does this cover my area, does it hold together across departmental boundaries, and how would I know? This page shows the complete responsibility map, and beside it the chains without which a map would only be a shelf.
Twenty-two domains, grouped by responsibility. Some cover business finance areas, some shared capabilities for data, authority and operations. Together they are not a shelf of modules but one coherent operating model for finance.
Twenty-two domains are not a product catalogue. They are the responsibility map of an operating model. The business domains are delivered modularly, the foundation is always included. How FinanceOS is deployed and commercially packaged does not follow one to one from the architecture.
We say domain where responsibility is meant and module where the product is meant. Both refer to the same thing.
These figures are not a performance promise. They state how deeply the product model is decided. That is exactly what separates a fully modelled product from a collection of screens.
22finance domains with delimited responsibility597product areas within those domains3,463product functions, 3,450 of them firmly assigned and 13 deliberately kept cross-cutting
23families of cross-functional finance processes93fully modelled end-to-end finance chains807process steps within those chains121named handoffs between domains
108business objects in the canonical core61financial effects
3,230qualified user stories15,500qualified acceptance criteria
What separates a finance tool from an operating model is not the interface but whether the handoffs between departments are modelled. Each of these 121 handoffs is named: which object passes over, which state applies, who owns it from then on and what travels with it. In most organisations that stretch is done by people, by email.
A requirement without an acceptance criterion is an intention. Only the criterion establishes when a capability works correctly, and makes it testable — for us in development and for you in acceptance. Just under five criteria per story on average.
Each of these figures has exactly one definition on this page. Wherever it appears elsewhere, it stands for the same thing.
Financial Case Management sits on the map under case, contract and document — it is a domain with a delimited responsibility. It is effective across all of them: the execution backbone on which each of the 93 chains finds its decision point.
This is not a ticketing system. A ticket has a status. A financial case has a financial effect, a decision authority and an evidence record.
And two domains that operate inside every other one
A control finding becomes a case: materiality, evidence, owner, decision, remediation, retest, certification.
Four levels with rising approval. Acting only within defined limits, owned by a named person.
Case, control and authority are why the map is not a shelf: they operate inside every domain rather than beside them.
Software is built and bought by responsibility. A business record runs across it. That is why FinanceOS models 93 end-to-end chains in 23 families — the same domains, a different axis.
Without the chains the map would be a shelf of modules. Without the map the chains would be integration projects. Both axes are the same product design, carried by the same data basis and the same evidence model.
Layer D of the map is not a list of interfaces but an architectural statement: business product responsibility is not the same as owning the operational source system.
Transaction, posting, close.
Accounts, payments, settlement.
Storage, authoring, signature.
Project delivery, time capture, payroll.
Operational truth stays with the source systems. FinanceOS carries the shared context and knows where every value came from. Two or three ERPs after acquisitions are the normal case for it.
No. The 22 domains define the product architecture. How FinanceOS is deployed and commercially packaged does not follow one to one from that. Six typical entry points are shown under business bundles.
No. The business domains are delivered modularly. The shared foundation — data model, authority, retention, operations — is part of every entry point, because without it no chain could be evidenced.
A domain has a delimited business remit: who is responsible for what. A chain is a sequence across several domains, from an operational event to a verified financial effect. 22 domains, 93 chains and 121 named handoffs between them.
No. ERP and general ledger, banks, DMS and CLM, project and payroll systems, tax and consolidation systems keep their business authority. FinanceOS connects context, control, decision and evidence across them. The principle is set out under systems of record.
Because a system that carries decisions about financial matters is only as sound as its answer to two questions: who was allowed to do this, and what evidences it. That is why both are cross-cutting in the product model and sit beneath all 22 domains.
No, and we mark that. What is verified in the product today is stated on the respective domain page and summarised on the product status page.
Verified in the product
The business objects with lineage per value, the role and amount limits, and the audit trail per exercise of an authority.
Pilot or validation
The last station of a chain against a baseline recorded beforehand.
In active development
Not every one of the 22 domains is equally far along. What holds today is stated on the respective domain page.
What is not marked, we do not claim.
Maturity per capability is stated on the domain pages. What we can evidence today
Forty minutes with an architect, no presentation. You say which systems stay authoritative and which two stretches are manual work today. We say which domains that touches, which chain runs across them, and what the foundation already brings.