A customer obligation starts in the business, the invoice in the ERP, the payment on a bank account. What happens in between — a dunning step, a payment arrangement, a part payment, a deduction, a dispute — happens in inboxes and spreadsheets. The total is right at month end, and still nobody can say why an amount is open and what happens next.
It sits in the ERP with an amount and a due date. The reason it is overdue does not.
Dunning, provision, payment arrangement: discussed, sent, noted — usually outside the system.
It gets posted. The gap between expected and received stays behind as a residual line.
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
Carries the obligation as a finance object: counterparty, entity, term, pricing and payment terms. The receivable is then a commitment with an origin, not just a number.
Pilot / validation
Ageing, an action per position, an owner and a date. The action hangs on the receivable rather than on an email.
Pilot / validation
Bank items across all banks, matched to the open item, with differences raised as their own record instead of a remainder.
Pilot / validation
The expected payment with a date and a likelihood in the forecast — and the correction as soon as an action takes effect.
In active development
A deduction, a part payment or a dispute becomes a case with an owner, a deadline and a decision, not a reminder note.
A dunning step, a payment arrangement, a write-off or an escalation — inside the authority that applies to this entity and this amount. Where no rule clearly applies, a person decides, and the decision stays on the record.
The invoice, the posting and the open item are created there and stay there. FinanceOS runs the record above them and rewrites no posting.
The bank item is the bank's truth. FinanceOS reads it and matches against it; the bank stays the source.
The customer relationship and the agreement stay in the sales system. FinanceOS takes the financially relevant fields.
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 invoice is created in the ERP, the posting stays there and the open item still belongs to accounting. What FinanceOS adds is the record above it: why an amount is open, who owns the action, what it changed, and where that can be read back.
From the bank item, the reference and the open items. Where the match is unambiguous, it is unambiguous. Where it is not — part payments, deductions, lump-sum payments — a case with an owner appears instead of a residual line. The maturity of that capability is stated below.
The limit itself is held where the customer relationship is held. FinanceOS can bring exposure together from receivables, orders and obligations and attach it to the decision. As a defined capability — not as a credit check running today.
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.