Why the CFO is always the last to know a project went over (and how to change that)

It's the second week of the month. The monthly review meeting is on the calendar for Thursday. By Tuesday, the project reports have started landing. One of them — the big industrial fit-out that's been running since January — is £180,000 over budget. The project manager has known for two weeks. The commercial lead has known for about ten days. By the time the CFO opens the deck on Thursday morning, the overrun is already in the past tense.

The conversation that follows is predictable. Why didn't we see this coming? When did it happen? What have we committed to that we can't walk back? And underneath those questions, the quieter one: how did finance end up being the last to know about a cost that finance is now responsible for explaining?

This isn't a reporting-cadence problem. It isn't a project-manager-didn't-flag-it problem. It's a structural problem with when financial systems first see cost — and until that structure changes, the CFO will keep learning about commitments weeks after the business committed to them.

The visibility gap, measured in weeks

Here's what actually happens between a cost being decided and the CFO seeing it. A project team identifies a need. They raise a purchase order. The PO gets approved — perhaps by the project lead, perhaps by the commercial manager, perhaps up a chain depending on the amount. Once approved, the business is committed. The supplier has been authorised to deliver, and the money is contractually owed when the invoice arrives.

That approval happens in a system — a procurement tool, a shared drive, an email thread, sometimes a project management platform. The commitment lives there. It does not live in the finance system.

Weeks pass. The supplier delivers. Then invoices. The invoice arrives in accounts payable, gets coded, matched, approved for payment, and finally lands in the accounting system. That is the moment finance first sees the cost.

From commitment to accounting-system recognition, the typical gap is three to eight weeks. By the time finance sees it, the decision was made.

The CFO isn't last to know because people are hiding things. The CFO is last to know because the systems that produce the CFO's view only start recording the cost after the commitment has already been made.

Everyone upstream has newer information. Finance has the oldest.

Why standard tooling doesn't solve this

The intuitive responses to this problem all fail for the same underlying reason — they address presentation, not timing.

None of these addresses the structural issue: cost needs to be captured at the moment of commitment, not at the moment of invoicing, and that capture needs to happen in a system the CFO can see without asking anyone.

Purchase order visibility, properly understood

The term purchase order visibility usually gets reduced to a reporting feature — "can I see my open POs in a dashboard?" That's the shallow version. The deeper version is this: can the person responsible for the business's cash position see every committed cost at the moment it was committed, with context on which project it hits, which budget line it draws from, and how it compares against the budget for that project?

Most businesses answer "sort of" to that question. They can see POs that have been approved, usually in a procurement tool or shared drive. They can see spend that's hit the accounting system. What they can't see is the join between those two — the committed cost that's been approved but not yet invoiced, aggregated against project budgets, visible to finance in the same view as everything else.

That missing join is where the CFO's visibility gap lives. Not in the reporting layer. Not in the dashboards. In the data model that treats PO approval as a procurement event rather than a financial event.

The moment a PO is approved, the money is as good as spent. The business can walk back a request. It can rarely walk back a commitment. The accounting system just doesn't know yet.

The structural fix is to treat PO approval the same way the business already treats invoice-received: as the moment the cost becomes real. From that moment onward, the cost should show up against the project budget, against the cash flow forecast, against the committed total — not as a prediction, but as a fact. It's committed. It's going to happen. The invoice is a formality.

This is what tracking committed cost actually means in practice. It isn't a feature of accounting software. It's a different place to capture the data.

What a CFO can actually see — three versions of the same business

To make the gap concrete, consider three versions of the same business running the same project.

Version A · Accounting system only

The CFO's view updates when invoices hit the accounting system. By the time an overrun is visible in the monthly report, the costs were committed three to eight weeks ago. The project team has moved on. Any corrective action — scope reduction, variation push-back — is now a cleanup exercise rather than a prevention exercise. The CFO explains the overrun in the board report.

Version B · Manual tracker alongside the accounting system

The CFO has pushed PMs to log commitments in a spreadsheet as they make them. Some PMs do, some don't. The tracker is usually current to within a week on well-managed projects and current to within a month on the others. The CFO can get an estimate if someone collates the trackers, but it's not reliable enough to run a cash flow forecast against. Monthly reporting is still accounting-system-driven. Overrun visibility improves marginally.

Three versions of the same business. The only structural difference is when the commitment hits a system finance can see.

Why this matters more for project-based businesses

In a product-based business, costs are relatively predictable: inventory, salaries, overhead, known supplier contracts. The gap between commitment and invoicing matters less because the base-case cost structure doesn't vary much month to month.

Project-based businesses — construction, engineering consultancies, marine fit-out, events, energy infrastructure — are different in three specific ways:

• High commitment rate. Costs are decided in real time by the people doing the work, often without finance in the loop
• High variability. Every project is different; scope evolves, variations get agreed on site, subcontractors are brought in mid-project
• High consequence. One under-estimated subcontract on one project can take an entire project from profitable to loss-making — there's no inventory turnover or sales mix to absorb it

If finance sees a bad commitment six weeks after it's signed, there's no mitigation path left. And yet, most project businesses operate exactly this way — because the tools finance uses were designed for product businesses. Accounting systems recognise cost when it's invoiced. ERP systems recognise commitment, but only after a heavy implementation. Procurement tools capture POs, but they don't speak project-cost-control fluently. Between those three categories, the specific need of a project-based CFO — real-time commitment visibility, mapped against project budgets, without a six-figure ERP build — falls through the gap.

What to change (and in what order)

If the goal is to close the visibility gap without rebuilding the finance stack, the sequence matters.

1 · Decide where committed cost will live

Before buying anything, finance and operations need to agree on where the authoritative record of committed cost sits. If it's the accounting system, you're stuck with invoice-timing. If it's a shared tracker, you're stuck with manual-entry discipline. If it's a dedicated purchase order control system that holds budgets and commitments together, you've got a chance. This decision determines everything downstream.

2 · Move PO approval into that system

Once the system of record is chosen, every PO approval needs to happen inside it. This is the hardest change behaviourally — PMs are used to approving POs by email, Slack, or verbal confirmation. The transition requires a short-term enforcement push and a system that doesn't make the approval harder than the current method. The benefit — real-time commitment data — only arrives if this step holds. Partial adoption produces a worse result than no change at all.

3 · Build the cash flow forecast from committed data

Once commitments are captured at approval, cash flow forecasting changes shape. Instead of forecasting cash out from invoice-received dates, you forecast from committed costs plus delivery lead times plus payment terms. The forecast reflects what the business has actually committed to, not what accounts payable has already processed.

What the CFO sees afterwards

After this change takes hold, the monthly review conversation shifts in two specific ways.

First, overruns stop being surprises. By the time a project is over budget, finance has been watching commitments trend toward the limit for weeks. The conversation isn't "when did this happen?" — it's "we flagged this three weeks ago, here's what we decided to do, here's where it landed."

Second, the cash flow forecast becomes something the business can plan around. If committed costs are visible as they're approved, the forecast of cash out over the next 60 days reflects actual commitments, not an extrapolation from recent spend. Working capital decisions get made against real data. Covenant conversations with lenders get easier. The finance team stops being a lagging indicator and starts being a current-state system.

The CFO is no longer last to know — not because they're asking more questions, but because the data arrives at the moment of commitment, before anyone needs to ask.

Why this is harder than it looks (and why it's worth doing anyway)

The hardest part of closing this gap isn't the tooling. It's convincing operations that moving PO approvals into a central system is worth their time. From the PM's perspective, the current process works — the project gets its subcontractors, the materials show up, the deliveries happen. The visibility gap is finance's problem, not operations'.

The counter-argument that actually lands with PMs is this: the overruns that embarrass finance also embarrass PMs. When a project goes 15% over budget, the project manager carries that too. The overrun they didn't see coming is also the overrun that lands on their performance review, their next-project budget, and their credibility in the commercial team's eyes. Capturing commitments at approval is as much a PM safety net as a CFO visibility tool.

Reframed that way, the change becomes something operations wants, not something finance imposes. The tooling supports a practice both sides benefit from. The CFO's visibility is a side effect of giving the project team a better way to see their own commitments against their own budgets.

None of this requires an ERP. None of this requires months of implementation. It requires the business to agree on where committed cost will live, move PO approvals into that place, and let the data flow from there into the reports finance already runs.

The CFO stops being last to know. Not because they got more aggressive with reporting demands. Because the data model finally reflects when commitments actually happen.