A purchase order, a framework agreement, a verbal commitment in the business: the money is tied up the moment it is committed. It shows up in the numbers with the invoice, sometimes only with the payment. Until then the commitment lives in an order list, a contract and an accrual spreadsheet — three places, three points in time.
A purchase order in the buying system, a framework agreement in a folder, a call-off by email. The commitment is the sum of three.
It arrives, gets checked and approved. Whether it belongs to a commitment is checked from memory.
At period end someone estimates what was delivered and not yet invoiced. The basis for that estimate is rarely on file.
The data is usually there. It just takes effect in different systems at different times.
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.
In active development
Holds budget, coverage and commitment on one object: what is committed, what is consumed, what is still outstanding.
In active development
The framework agreement with its term, prices and notice periods — and the call-off that turns it into a concrete obligation.
Pilot / validation
Payment runs with segregation of duties and limits; the approval is checked server-side, not in the form.
In active development
The accrual comes from the commitment and the delivery status, not from an estimate without a basis.
In active development
An invoice without a commitment, a price deviation, an open delivery: a case with an owner and a deadline instead of an email query.
Approve, reject, accept in part or escalate — inside the authority that applies to this entity, this supplier and this amount. Four eyes where the rule requires it, and no approval where the rule is not clear.
The order, the goods receipt and the posting are created there and stay there. FinanceOS runs commitment, case and evidence above them.
The payment leaves the company through the bank. FinanceOS prepares the run and carries the approval; execution stays with the banking channel.
Master data and bank details stay in the leading system. FinanceOS uses them and does not change them.
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. The order and the goods receipt stay where purchasing works. This chain asks a different question: when a commitment reaches the numbers, who approves it, and what the period-end accrual actually rests on.
We claim no detection here. What this chain provides is visibility and control: an invoice without a commitment becomes a case, the approval is checked server-side against segregation of duties and limits, and every approval stays readable.
From the commitment and the delivery status, both of which sit on the record. The accrual then has a basis you can read on the object — rather than a number that appears at period end.
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.