Treasury & Liquidity
One cash position across banks, entities and currencies, and the decisions that follow from it.
Connected to payments, forecasting and working capital.
Treasury & Liquidity →
Platform architecture
Different systems. One finance language.
One finance model above your systems of record — that is the whole architecture.
Every ERP and every accounting system represents finance in its own way: its own names for an entity, its own structure for an open item, its own idea of what a payment is. That is not a defect — it is what makes each system good at recording. It is also the reason group finance ends up in spreadsheets: there is no shared language in which a process can be defined once.
The canonical finance model
What a canonical finance model actually is.
FinanceOS translates the structures of each connected system, at the integration boundary, into a small set of finance objects that mean the same thing everywhere. Everything above that boundary — processes, controls, KPIs, workflows — works on those objects and never on a system's field schema.
Above the model · finance operations
See
Plan
Approve
Execute
Reconcile
Evidence
The canonical finance model
Legal entity
Bank account
Counterparty
Obligation
Payment
Receivable
Document
Period
Below the model · provider adapters
ERP and accounting systems
Banking channels
Document sources
This is the only architectural decision on this page that matters. Everything else — multi-entity, multi-bank, the control layer, the workflows — is a consequence of it.
What follows from it
Three consequences, and they are the reason for the whole design.
1
Consistency
One finance semantic. The same process, the same controls and the same KPIs across every connected system — so a group figure is a figure and not an assembly of local interpretations.
2
Portability
Finance processes stop depending on a single ERP. When an entity replaces its source system, the adapter changes and the finance operation keeps running. Your process investment is no longer hostage to a vendor decision.
3
Scalability
A new entity, a new bank or an additional system joins an existing finance control structure instead of starting another island. Growth stops multiplying methods.
Complexity as the normal case
Built for the landscape you actually have.
Multi-entity
Several entities, one process.
Canonical legal entities with consolidated and per-entity views, and governance and permissions that follow the entity rather than the person's memory.
Multi-ERP
Different systems, one finance language.
One canonical core with provider adapters at the edge. NetSuite is the first and deepest connected path as a system of record; further systems connect through the same model, not through a second product.
Multi-bank
Several banking relationships, one cash position.
Canonical bank accounts per entity and currency, so a cash position is one figure with a known composition instead of a comparison across portals.
Multi-currency
Foreign currency where it belongs.
In balances, due dates, exposure and the forecast — with the reference rate and rate date shown next to the value, and no value produced when a rate is missing.
The control layer
The control layer is part of the architecture, not a module.
Because processes run on the canonical model, the controls do too. A rule is defined once and applies in every entity and for every connected system — which is exactly what a group policy is supposed to mean.
IdentityCentral sign-in, access bound to people, no shared accounts.
Entitlement by roleVisibility and rights per task and per entity, enforced server-side rather than hidden in the interface.
Segregation of dutiesPreparation, review and release are separate rights; self-approval is blocked by the rule, not by etiquette.
Limits and policiesThresholds and approval matrices are configuration of the platform, applied identically everywhere.
Audit trailRecords on financial objects are appended, so history cannot be quietly rewritten.
Data qualityUnknown is not zero: a missing source produces a labelled gap, never a confident number.
Workflow architecture
Workflow is how the layer does its work.
Work is explicit
A finance task has an owner, a due date and a state. It exists as an object in the platform, not as an expectation in a conversation.
- Owner per task
- Due dates and follow-up
- Escalation when nothing moves
Exceptions are first-class
Anything that does not fit becomes a case in a queue — and a case can hold a release rather than being noticed after the money left.
- Exception queue
- Blocking where blocking is right
- Reason recorded on resolution
Workflows sit on finance objects
An approval is attached to the obligation, the payment or the receivable it concerns, so the evidence never has to be reassembled.
- Evidence attached, not searched for
- History retained
- One case across systems
The same engine everywhere
Approval, collection, reconciliation and document handling are the same workflow architecture applied to different finance objects — not four separate products.
- One rule set
- One audit trail
- One place to act
Modularity and entitlement
Modular by architecture, one product by design.
Which capabilities a tenant has is a matter of entitlement and configuration, not a different codebase. That is what makes a phased introduction possible: you start with one area and one entity, and the rest is switched on against the same model when you are ready for it.
One core, one modelThere is one FinanceOS core. Every tenant runs the same canonical model, so switching an area on does not mean a migration.
Entitlement, not forksScope is granted per tenant. Nobody gets a private version that has to be maintained separately.
Phased introductionOne area and one entity first, end to end and governed — then further entities, banks and areas onto the same layer.
Commercial scope is a conversationWhat belongs in your scope, and in which order, is defined with you. There is no published package matrix on this page for that reason.
How the areas connect
The areas are not modules. They are one process, seen from different sides.
This is the practical test of the architecture: each area is useful on its own, and each one is better because the others sit on the same model.
Payments & Banking
One governed release path with roles, limits and dual control, and the liquidity effect in the same step.
Connected to treasury, payables and cases.
Payments & Banking →Documents, Workflow & Cases
The work behind the figures: intake, classification, tasks, exceptions, evidence.
Connected to payments, payables and treasury.
Documents, Workflow & Cases →Cash forecasting, working capital, receivables and payables run on the same model. Which of them we look at first in your environment is a scoping question, not an architectural one.
Where the platform ends
What the platform is — and what it is not.
What FinanceOS is
- The operational control layer — the layer between your systems of record and your finance team, where finance is actually run
- One canonical finance model — so processes, controls and KPIs are defined once and apply across connected systems
- A control layer first — roles, limits, segregation of duties and an audit trail are architecture, not options
- ERP-neutral by design — the source system is an adapter concern; your finance processes are not
What FinanceOS is not
- Not an ERP — your system of record keeps the transactions, the master data and the accounting authority
- Not a general ledger — FinanceOS does not take over accounting or become the book of record
- Not a BI tool — it does not replace your reporting stack; it acts, which reporting never does
- Not a point solution — treasury, payments, receivables and cases are one operation here, not four tools
Who this page is for
Written for the people who have to decide this.
CFOWhether finance can be steered daily instead of reported monthly.
Finance transformationWhether a process improvement survives the next system change.
CIO / ERP leadWhat is connected, what is replaced — and the answer is: nothing is replaced.
Group financeWhether a group figure means the same thing in every entity.
Enterprise architectureWhere the boundary between record and operation is drawn, and why it holds.
Next step
Bring us your architecture, not a requirements list.
Tell us how many systems, entities, banks and currencies are involved and where the manual bridges are today. We come back within one working day with an honest read of where a common finance layer would help you most — and where it would not.
- What happens next. An automatic confirmation, then a personal reply within one working day.
- Who you talk to. The people who build the platform and the architects who implement it — not a call centre.
- What you don't need. No prepared data, no NDA for a first conversation, no purchase intent.
The bottom line
Keep your systems. Unify your finance operations.
One finance model, one control layer, one audit trail — across entities, ERP systems and banks.