Integrated Finance Platform: contract to cash, in one system, for a group

A CFO running a multi-entity group does not lack information. There is plenty of it, and it disagrees. The month goes on deciding which version to believe before anyone can decide anything else.

Sales, operations, the ERP and the spreadsheets each hold one link of the same chain. A contract becomes work, work becomes an invoice, an invoice becomes cash, and cash funds the next contract. Break the chain into separate systems and the chain still exists. It is just that the CFO is the one reassembling it by hand, every month, and the reassembly finishes after the decision was due.

The chain is held as a single model. Seven stages, each inheriting from the one before, so nothing is rekeyed between them and nothing has to be reconciled afterwards.

Underneath all seven sits one foundation: one data model, one entity structure, one chart of categories, one audit trail, and one definition of every metric. What comes out of it is what a board asks for. Cash forecast, budget variance, project margin, working capital, finance KPIs, and the audit trail that stands behind all of them.

Nothing is replaced. The finance team keeps its ledger, its existing close process and its existing chart of accounts. Source systems remain the system of record. The platform reads from them and builds the forward view they were never designed to give you. No migration, no rip and replace.

Multi-entity support decides more implementations than it should, so it is worth being plain about. A group that acquires, incorporates or restructures needs the entity structure held in the foundation rather than added as a filter on top, so that the arrival of another company is routine rather than a project.

The contract becomes a financial object. Value, duration, escalation, credit terms, milestones and retention are held against it, so every downstream date is derived rather than typed. The order book becomes the revenue forecast without anyone rebuilding it as one.

Margin is live rather than post-mortem. Cost to date against value earned shows erosion while the contract is still running and something can still be done about it. Unbilled revenue stops hiding.

Then the stage where days sales outstanding is actually won, and usually lost. Most of the delay in getting paid happens before the invoice is issued: work is certified on site, then billed whenever the billing run next goes out. Here, certification triggers billing, and the gap between the two is measured, attributed, banded and reported. A day of lag is a day of DSO, applied across the whole order book, every month, permanently.

Because the platform already holds the contract, it knows what was agreed before it writes to a customer. Chasing runs as a ladder: advance notice before the due date, a courtesy on the day itself, an escalating sequence once overdue, then escalation to both finance leads. Tone is set per relationship. A public-sector customer and a long-standing private one do not receive the same letter, and sending both the same letter damages the relationship the process exists to protect.

Receivables are priced against the alternative: which of them are worth an early-settlement discount, and what that discount costs measured against a facility draw. DSO is reported on two bases, from submission and from invoice, with ageing on both sides and customer concentration next to it.

On the payment side, control. Two levels of approval, and the role that enters a payment cannot approve it. Rejections capture who, when and why. Integrity checks run continuously across every entity, and each one states how much cash the issue puts at risk, so the exception queue arrives already ranked. Every action is written to the audit log with user, timestamp, before and after values and free-text remarks, filterable for internal audit.

Cash decides the week, so it gets its own screen and several horizons on one selector: a short one for the payment run, a longer one for the board, a longer one again for the plan. Consolidated or by entity on the same view. Every figure is drillable. Click a number and the invoices behind it open, and from an invoice, the contract behind that.

The forward view is built from contracts and from history rather than from typing. Contracted revenue is already in it, because milestones and credit terms are held, so future billing lands in the right week without anyone keying it. The rest is learned from your own record: rent, payroll, tax, and the customers who habitually pay late. Behaviour, not just terms, so a customer whose contract says one thing and whose payment history says another is forecast on the history.

Then the decision the screen exists for: a prioritised payment run. What to settle, what to defer, what to accelerate, and what each of those costs. Group before facility, so surplus in one entity is offered against a deficit in another before anything is drawn.

A budget is only useful if it knows what has already been committed. Because contracts, purchase obligations and the cash forecast share a model, variance is live rather than monthly, committed spend is not a surprise, and variance drills to the cause.

Change an assumption and the budget and the cash position reforecast together, because they are the same model. Delay a contract, lose a customer, move a facility rate, and the effect on EBITDA and on cash appears at once.

Every module earns its place alone. Connected, they answer questions no single system in your estate can answer, because no single system holds both halves of the question.

Three things make the joins hold. One definition of every metric, so that DSO, margin, burn, utilisation and variance are defined once and computed the same way everywhere, and two reports cannot disagree because there is only one calculation. One path from the board pack to the clause: a number on the board pack opens the entity, then the invoice, then the milestone, then the contract clause that produced it. And an assistant that answers in plain language against your live data, your own contracts and your own policies, cites its sources, and cannot move money.

The test is what you can answer on the day you are asked it. What is the group cash position and the funding requirement next quarter. We are behind on EBITDA, where exactly is it going. This week is tight, do we draw on the facility or offer a discount. How much of our DSO is the customer and how much is us. Is this contract still making the margin we bid. Who approved this payment, when, and on what basis.

Four joins do most of that work.

Four deployment models, and the choice does not change the product.

Groups choose differently for reasons that have little to do with software: an existing hosting arrangement, a regulator's expectation, a board that settled the question years ago. It is worth deciding early because it shapes the integration work, but it is not a decision that changes what the platform does.

Cash and working capital first, because it is the quickest part of the chain to make true and the part a CFO needs on a Monday. Contracts and billing second, because that is where the forward view stops being an estimate and starts being derived. Budget and intelligence third, once the first two have populated the model that makes them worth having.

Each phase is useful before the next one starts. Nobody runs two systems through a long parallel period, and nobody has to justify the whole programme on a benefit that only arrives at the end. If the first phase does not earn its place, the second does not have to happen.

This argument is easy to make in the abstract and easy to test in the specific. The useful first conversation is short and factual: how many entities, what your contracts commit you to, where the forecast is built today, and how long after certification you invoice.

We would rather walk the platform through your own figures than a demonstration set. It becomes obvious quickly whether the chain described here is the chain you run, and which link is costing you most.