A receivable goes overdue. The ageing shows it, a dunning stage runs somewhere, and whether the payment now arrives four or eight weeks later gets estimated in the liquidity meeting instead of computed.
It shows what is open. It does not say which action is running and who owns it.
Calls, emails and payment arrangements happen beside the system and end there too.
The shifted receipt only reaches the liquidity plan once somebody updates the spreadsheet.
An open item is a number. An action with an owner, a date and an expected effect is something you can steer with.
Four steps, and the same cross-functional capabilities across every one of them.
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
Keeps open items, ageing and payment behaviour on the canonical receivables data and turns them into a work queue.
In active development
Turns every deviation into a case with an owner and a date — a complaint, a payment arrangement, a disputed line.
Pilot / validation
Carries the shifted receipt into the forecast and shows the range when several items slip at once.
Pilot / validation
Shows cash position and headroom against funding lines — with the cause attached, not only the number.
Pilot / validation
Connects the receipt to the open item, so the action gets a measured effect rather than a note.
Dunning stage, payment arrangement, escalation or preparing a write-down. The expected effect stays on the action, so it becomes visible later which action held for which customer behaviour.
Invoice, receipt and posting stay in the posting system. FinanceOS reads the open items.
Account information comes from your channels; FinanceOS claims no bank transmission of its own.
Where the conversation happens is your choice. The case holds the outcome, not the tool.
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. It is about steering before handover: which items first, which action, and what effect on liquidity to expect.
The formula is implemented. What we deliberately do not offer are DPO and the cash conversion cycle — there is no authoritative COGS denominator for them, and a ratio without a sound denominator is not a ratio.
They become a case with an owner and a date, not a line in an ageing report. That lets the forecast treat the item differently from an undisputed due date.
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.