FinanceOS is a finance platform that sits on top of the systems you already run. A contract, a change in project progress or a payment moves cost, margin, forecast and liquidity inside it while the process is still running. Your ERP keeps posting and keeps its authority.
Which projects are losing margin right now?
Progress sits in time recording, cost in the ERP, the estimate to complete in a spreadsheet. They come together at the close, and by then the quarter is gone.
What happens to our cash if three large milestones slip by four weeks?
Billing slips, the receivable arises later, the payment is missing from the forecast. It takes weeks before that reaches the liquidity plan.
Which obligations have we entered into that are not yet in the forecast?
Signing happens out in the business. The contract shows up in the numbers with the first invoice. In between, there was still time to correct course.
The data is usually there. It just takes effect in different systems at different times.
A contract moves cost, forecast and cash, often across several periods. A project delay moves margin, billing and the liquidity plan. A payment hangs on an approval, an authority and the transaction that triggered it.
Those links exist in every company. FinanceOS brings them together in one shared finance data model, so they reach the numbers while the process is still running.
Four questions a chain should have answered by the end: What was decided? Was it acted on? Did it work? And is the record closed in a way you can show?
Here is what that looks like
Pick a step. You see the module's role, what it takes on, what it hands to finance, and why that matters for steering the business.
A supplier contract comes in.It gets signed out in the business and filed in SharePoint. In the numbers it usually appears with the first invoice.
Within the authority that applies to this entity and this amount.
Person, authority, basis and time stay retrievable on the obligation.
Reads the incoming document and files it with its finance-relevant fields.
Why this matters Without counterparty, entity and deadline on the document, every step that follows starts with a search.
Records the contractual commitment as an economic obligation with value and due dates.
Why this matters A contract causes cost and payments across its whole term, not on the day it is signed.
Assigns the obligation to entity and period and sets the accrual.
Why this matters That makes the obligation comparable at the close instead of visible only at the invoice date.
Takes the recorded obligation into the entity's forecast and budget.
Why this matters If obligations only reach planning through invoices, the forecast stays permanently behind the business.
Takes payment plan, due date, currency and entity into the liquidity forecast.
Why this matters Liquidity depends on what the business has committed to, not only on what the bank shows today.
A project slips.Delivery knows the same day. Finance hears about it through the margin report, treasury through the payment that does not arrive.
Each option with its consequence for result and cash.
The expected effect stays on the decision, so the actual one is comparable later.
Keeps progress, actual cost and estimate to complete per project.
Why this matters Estimate to complete decides between intervening and letting it run, and in many organisations it lives in a spreadsheet.
Works the change through to contribution per project, customer and segment.
Why this matters Margin losses in project business build up across several periods. A monthly report shows them once the buffer is gone.
Carries the margin change into the earnings expectation for the period and the year.
Why this matters A forecast variance only becomes steerable once the cause is named.
Sets when delivered work becomes an invoice and from there a receivable.
Why this matters A milestone that slips changes billing before it shows up at the close.
Carries the shifted receipts into cash forecast and headroom.
Why this matters Four weeks of delay on three milestones is a funding question, if you ask it early enough.
Each chain starts with a business event and ends at a decision that is documented and closed.
Every module offers a standalone entry point. Which one makes sense depends on where the work sits in spreadsheets and inboxes today.
Cash position across all banks and entities, the forecast on top of it, scenarios next to it.
See Treasury & Liquidity →Progress, actual cost and estimate to complete on one project object, with contribution attached.
See Project Finance →Reconciliation, accruals and task control, with exceptions that have an owner and a date.
See Accounting & Close →Entities, roles, approval paths and rate sources are set up once. The modules that follow use them. The product architecture shows how that is built.
Pick a module. It highlights the cross-functional capabilities, the foundation and the source systems it uses.
No module selected. The three layers below apply to all of them.
Another module uses the same entities, roles, approval paths and evidence mechanisms. What it adds are its own business processes.
Friday afternoon. A payment to a supplier is waiting for approval, the amount is above the preparer's limit, and the responsible approver is not in the building. In many organisations it is then approved by email, and the evidence has to be assembled later from three systems.
In FinanceOS the server checks the approval. The approval matrix applies per entity and amount, self-approval is blocked, and where no rule applies unambiguously a case is created instead of an approval. What remains is a decision with person, authority, basis and time.
The server-side approval control was observed running in a controlled environment, by a party independent of the implementation.
Approval authorities apply per entity, amount and transaction type. The check happens at the moment of the decision — and an approval for step A is not an approval for step B.
Segregation of duties and limits apply wherever money or a record moves. Where no rule applies unambiguously, a case is created.
Every approval and every change stays findable on the transaction, with the document and the rule it relies on.
Where no rule applies unambiguously, a case appears with an owner and a deadline. Cases are a subject in their own right and at the same time run across every module.
A notice, a contract or a receipt stays connected to the transaction it triggered — and to the decision that followed from it.
AI explains variances, prioritises work queues and prepares proposals. Approving and posting stay with people who hold the authority.
No. Your ERP and accounting systems keep posting and keep their authority. FinanceOS reads from them, brings the data together in one shared finance data model, and takes on the processes that sit between the systems today: approvals, reconciliations, chasing, spreadsheets.
Yes. Every module offers a standalone entry point. Modules that follow use the same finance data model, the same roles and approval paths, and the same evidence mechanisms.
Separation by tenant and entity is enforced at row level in the database, not filtered in the interface. Development has no access to production data, test data is not customer data, and access to each environment is a separate permission.
Maturity per capability is stated on the module pages. See where each capability stands
Bring a question that today needs two systems and three people. We work through it on your example and show where it gets answered in FinanceOS.
Eighteen questions, an assessment per dimension, the result without contact details. Finance Operations Assessment →