In most organisations this is a figure that turns red. What happens next depends on who is reachable. Here it is the start of a modelled chain — eight stations, six domains, one piece of evidence at the end.
It sits in several bank portals and a spreadsheet. By the time it is consolidated and FX-normalised, half the day is gone.
Draw a facility, delay the payment run, push collections. Which one delivers what is estimated, not calculated.
Whether the chosen action worked is recorded nowhere. The next decision starts from zero again.
Every single step exists in some system today. What is missing is the evidenced connection between them.
Four steps, and the same cross-functional capabilities across every one of them.
Every single step exists in some system today. What is usually missing is the column in the middle: the evidenced connection between them.
01 · Cash positionTreasury
Consolidated across banks, entities and currencies, FX-normalised, with a statement of how reliable it is.
02 · Liquidity forecastTreasury · Finance Control Tower
Due dates, payment behaviour, project drawdowns, personnel cost. Not just the curve but the drivers behind it.
03 · Funding decisionTreasury · Financial Case Management
Draw a facility, delay the payment run, push collections, intercompany funding. Each option with a calculated effect on position, buffer and covenant.
04 · ApprovalIdentity & Access Governance
Who may decide up to which amount in which entity. Checked at the moment of the action, not afterwards.
05 · ExecutionTreasury · Working Capital
Drawdown, payment run, collections action. With an owner, a deadline and a state, not as a log line.
06 · SettlementYour bank
The account movement is the bank's truth. FinanceOS reads it and applies it.
07 · PostingYour ERP
Transaction and posting authority stay where they are today. FinanceOS prepares and does not post alongside.
08 · VerificationFinance Control Tower · Accounting Operations
The realised effect is measured against the baseline recorded beforehand and attributed to the action. The finding goes back into forecast and assumptions.
Six domains, one chain, one piece of evidence. Two of the eight stations sit explicitly in your systems — settlement at the bank, posting in the ERP. That is precisely why the column in between is the subject.
Every module is a standalone entry point. This chain shows what comes together once several of them run on the same finance data model.
Pilot / validation
Carries the consolidated position across banks and entities, the forecast on top of it, and the funding options with their calculated effect on buffer and covenant.
Pilot / validation
The curve and the causes behind it: due dates, payment behaviour, project drawdowns. A scenario here is derived from records, not a free assumption.
In active development
The funding decision as a case: options with an expected effect, approval by authority, the reasoning recorded, verification at the end.
Verified in product
Who may approve up to which amount for which entity — as an enforced rule at the moment of the action, with an audit trail per exercise.
Pilot / validation
The payment run across all banks and entities, with server-side approval checking and the application of the account movement to the case.
A facility, a payment run or a collections action — within the authority that applies to this entity and this amount. The chosen option carries its expected effect with it, so that something is comparable at the end.
Accounts, payments and settlement stay with the bank. FinanceOS reads the movement and applies it; the bank remains the source. Connectivity runs through Konfipay as the provider route in normal operation.
Posting and posting authority stay in the ERP. FinanceOS prepares the journal handover and does not post alongside.
Where one is in use it keeps trading, screening and custody. FinanceOS integrates it rather than replacing it.
What is not marked, we do not claim. The full state per capability is on the module pages and under what we can evidence today.
No. A treasury system shows the position. What it does not know is why the position will move — that lies in projects, contracts and payment terms. Because those domains share the same model, the forecast here is derived from records.
Through a stored rule per entity, amount and type of decision, checked at the moment of the action rather than afterwards. Segregation of duties is an enforced rule: whoever creates does not approve.
Before the action runs, the starting value is recorded — position, buffer, expected effect. Afterwards the realised effect is measured against it and attributed to the action. Without that baseline any statement about effect is a claim.
Bring this case as it looks in your organisation. We work through it on your example and say where a common finance layer holds and where it does not.