Cross-functional finance

Finance does not work in software modules.

A business record runs across several finance areas. That is why FinanceOS models not only vertical capabilities per domain but 93 horizontal end-to-end chains in 23 families.

Two axes

Vertically responsibility. Horizontally the run.

Software is built along responsibility: one system for treasury, one for contracts, one for projects. A business record, however, runs across all of those areas.

Vertical · 22 product modules

ResponsibilityEach domain has a bounded remit: who decides, who calculates, who posts, who evidences. That is the axis software is normally built and bought along.

Horizontal · 93 end-to-end chains

The runA business record does not know your module boundaries. It runs across several domains until it stands in the result as a verified effect. That is the axis missing in practice.

The 22 modules define the product architecture. How FinanceOS is deployed and commercially packaged does not follow from that one to one. And the chains are not integration projects: both axes are the same product design, carried by the same data model and the same evidence model.

The control loop

From data to verified effect. And back.

Twelve stations in four phases. This is the base figure of FinanceOS and the answer to why a reporting layer is not enough.

Phase 01 · See

01DataWhat arrives from your systems02ContextWhich record it belongs to03SignalWhat of it is relevant to steer byThis is typically as far as a reporting layer goes. The number is correct, visible and still without consequence.

Phase 02 · Decide

04ControlWhich rule applies05CaseThe record with an owner06DecisionOptions and their effect07ApprovalWho is allowed to approveFour stations in which a number becomes an owned intention.

Phase 03 · Act

08ActionWhat is actually done09OutcomeWhat follows from it financiallyTwo stations that belong together. Considered separately, you get activity without measurable effect.

Phase 04 · Learn

10VerificationDid it work11EvidenceWhat it is evidenced by12LearningWhat runs differently next timeThese three are the ones most often missing in practice. Without them every measure stays a claim.

The verified effect goes back into context, signal and planning.

Where most tools stop

A classic reporting layer typically focuses on data, context and signal, that is stations 01 to 03. A classic workflow typically focuses on case, decision, approval and action — stations 05 to 08. An audit tool cares about 11. FinanceOS additionally connects the financial context before and the effect measurement after. Between those pieces sits manual work today, and that is the real effort inside a finance function.

Why station 10 is the decisive one

Verification is the station missing almost everywhere. Measures are decided and logged. Whether they had the expected effect is rarely measured in a way that holds. Without that measurement there is no control loop, only a chain.

Control, authority and evidence are not stations. They sit underneath all twelve — built as a cross-section, not as a step at the end. Evidence assembled after the fact is not evidence.

One chain in detail

When liquidity gets tight, a red field is not enough.

The balance falls below the target corridor. In most organisations that is a metric turning red, and then the phone calls start. Here it is the beginning of a modelled chain.

01 · Cash positionTreasury

Consolidated across banks, entities and currencies, FX-normalised, with a statement of how much of it is usable.

02 · Liquidity forecastTreasury · Control Tower

Maturities, payment behaviour, project drawdowns, payroll. Not the curve, but the drivers behind it.

03 · Funding decisionTreasury · Case Management

Draw a facility, move a payment run, intensify collections, intercompany funding. Each option with a calculated effect on position, buffer and covenant.

04 · ApprovalIdentity & Authority

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 status, not as a log line.

06 · Settlement and postingyour ERP and your bank

Transaction and posting authority stays where it is today. FinanceOS prepares and does not post alongside.

07 · VerificationControl Tower · Accounting

The realised effect is measured against the baseline recorded beforehand and attributed to the measure. The finding goes back into forecast and assumptions.

Six domains, one chain, one piece of evidence. Every single step exists in some system today. What is usually missing is the evidenced connection between them.

Financial Case Management

Every chain needs a place where the decision is taken.

The normal transaction runs through. What costs time, nerves and result are the cases where something does not fit. Financial Case Management is the domain in which each of the 93 chains finds its decision point: the horizontal execution backbone on which the vertical domains become able to act.

Where cases come from, across all domains

Invoice deviates Payment blocked Receivable escalates Forecast deviates Project margin tips Intercompany does not agree Close position unresolved Change order without approval Control finding open Tax position unclear

What a financial case brings together

Issue and materialityAmount and materiality determine who has to decide and how deeply it is documented.
Objects, documents, evidenceThe case carries its documents, postings, contracts and records with it. Nobody searches.
Options and approvalOptions with their expected effect, approval within authority, the reasoning recorded.
Measure and resultWhat was done, by whom, by when, with which financial effect.
Verification and closureExpected against actual effect. Closure is a statement, not a change of status.

This is not a ticketing system. A ticket has a status. A financial case has a financial effect, a decision authority and evidence. That is how exceptions become finance records that teach you something.

The exception is where result is lost. A clarification sitting for four weeks is tied-up liquidity. A change order without approval is work delivered without payment.

Eight chains at a glance

How a business record really runs through your finance function.

Eight of the 93 modelled chains, each from a different family. Read one of them through in your own organisation: at every arrow you will find a person, a mail or a spreadsheet. Those arrows are the product.

Family 01 · Cash to posting Cash position › liquidity forecast › funding decision › approval › execution › settlement › posting › verification
Read the chain
Family 02 · Project through margin to cash Project event › remaining cost and EAC › margin effect › billing effect › cash effect › forecast › decision › verified result
See the chain
Family 03 · Contract to financial effect Contract › obligation › financial effect › billing and revenue › cash › forecast › posting › evidence
See the chain
Family 04 · Working capital Open item › promise or dispute › expected receipt › dunning action › receipt › cash application › financial effect › verification
See the chain
Family 05 · Risk to remediation Control signal › materiality › case › decision › remediation › retest › certification
See the chain
Family 06 · Investment to value Investment intent › business case › approval › commitment › actual cost › forecast › benefit › verified value
See the chain
Family 07 · Close to evidence Ledger › reconciliation › exception › materiality › case › document › correction › certification
See the chain
Family 08 · Plan to effect Strategy › plan › forecast › signal › decision › measure › result › learning
Read the chain

Four further chains we can show

Order to cash From customer obligation to explained cash
See the chain
Procure to pay Commitment, approval, accrual, payment
See the chain
Intercompany reconciliation Differences, elimination, evidence
See the chain
Document to decision Notice, deadline, evidence
See the chain
The boundary

Your systems keep the work. FinanceOS connects the context.

The most important architectural principle: product responsibility for a financial matter is not the same as owning the operational source system. A domain can be responsible for a financial matter without replacing the system in which it arises.

ERP and ledger

Transaction, posting, close. NetSuite, Business Central, D365, SAP and others.

Banks

Accounts, payments, settlement. Connected via a provider route or our own EBICS path.

DMS and archive

Storage, full-text search, records, legal hold, e-signature.

CLM vendors

Legal authoring, redlining, the signature process.

TMS and trading

Trading, screening and custody functions where they exist.

PSA and payroll

Project delivery, time capture, payroll.

Tax engines

Tax determination and filings in the respective jurisdiction.

Consolidation

Existing statutory consolidation tools where they are in use.

No replacement as a precondition. You do not have to harmonise, migrate or switch anything off first in order to start. Two or three ERPs after acquisitions are the normal case for FinanceOS.

Questions

What gets asked first at this point

Isn't this just a workflow tool?

A classic workflow mainly covers case, decision, approval and action, that is stations 05 to 08. Some platforms also model steps before or after. The difference here is that the financial context of stations 01 to 03 and the effect measurement of stations 10 to 12 are part of the same product model rather than built alongside it.

Why isn't our reporting enough?

A classic reporting layer typically focuses on data, context and signal. FinanceOS additionally connects control, case, decision, approval, action, outcome, verification, evidence and learning in the same product model. So what is usually missing is not the number but who does what by when, and whether it worked.

Do we have to introduce all 93 chains?

No. The entry point is one chain that is manual work in your organisation today. The chains share stations and the same data model, so extending does not become an integration project.

Does FinanceOS replace our ERP or our consolidation tool?

No. Your systems stay authoritative for transaction, posting and close. FinanceOS connects context, control, decision and evidence across them.

What does “121 named handoffs” actually mean?

At every point where a record moves from one domain to the next, it is described: which object moves, which state applies, who is responsible from then on and what travels with it. In most organisations people do that stretch by mail today.

Is the number of chains a promise of availability?

No. The numbers evidence modelling depth, not availability. What is verified in the product today is stated as a maturity level on the capability itself.

Status

What of this is verified in the product today

Case, control, evidence

Verified in the product

Case intake, ownership, approval within authority and the evidence record on the item.

Effect verification

Pilot or validation

Station 10 against a baseline recorded beforehand, at different depths per chain.

Full chain coverage

In active development

Not all 93 chains are equally far along. What holds today is stated on the page itself.

What is not marked, we do not claim. The figures on this page evidence modelling depth, not availability.

Maturity per capability is stated on the module pages. What we can evidence today

Conversation

Show us a finance process that runs through several systems and Excel today.

Thirty minutes, no presentation. We walk the chain through on your example and tell you which stations are missing in your organisation.

Present a process See the product architecture
What you bringOne record that runs through several systems today
How longThirty minutes, without a slide deck
What is clear afterwardsWhich of the twelve stations are missing in your case