A supplier contract gets signed out in the business and filed in SharePoint. In the numbers it usually appears with the first invoice. In between, the commitment has been made but is visible neither in the forecast nor in the liquidity plan.
The contract sits where the business works — counterparty and deadline in a PDF, not in the finance model.
Cost only takes effect once someone sees the invoice and assigns the period by hand.
The expected outflow is in no plan until it shows up on the account.
The data is 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.
Pilot / validation
Reads the incoming document and files it with its finance-relevant fields: document type, counterparty, entity, deadlines, amounts, reference.
In active development
Records the contractual commitment as an economic obligation with value and due dates — before the first invoice.
In active development
Assigns the obligation to entity and period and sets the accrual. That makes it comparable at the close.
In active development
Takes the recorded obligation into the entity's forecast and budget; cost forecast and headroom move on the day it is recorded.
Pilot / validation
Takes payment plan, due date, currency and entity into the liquidity forecast — the expected outflow is there before value date.
Review, approve, escalate or replan — within the authority that applies to this entity and this amount. Where no rule applies unambiguously, a case is created instead of an approval.
Filing stays where the business works. FinanceOS reads the document and attaches the finance context to it.
Posting authority stays in the posting system. FinanceOS does not post in its place.
Where write-back is in scope, it is defined per path and per system and not assumed.
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 question is not where the contract is filed but when its economic effect reaches the numbers. FinanceOS records the obligation as a finance object and carries it through accrual, forecast and liquidity.
They are treated like new ones: capture the document fields, value the obligation, set the due dates. The work is in the existing stock, not in the mechanism.
By its origin. The obligation carries the document it came from, and every decision on it stays retrievable with person, authority, basis and time.
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.