The financial roadmap is set once a year, in a board pack. The general ledger records what actually happened, after the fact. Between those two points sits the project, where most of the money is currently being spent and most of the surprises currently live.
The standard arrangement is that the project finance position is reconstructed at month-end from a spreadsheet, an email from procurement, a call to the project manager, and a glance at the latest ledger extract. Nobody is quite sure if the numbers reconcile until the management accounts come out. By the time they do, the conversation has already moved on.
The project finance tracker in DemandFlow is built to close that gap.
What it holds
Each project carries a live finance position. Approved budget, taken from the roadmap line that funded it. Committed spend, from purchase orders, requisitions and active contracts raised against the project. Actual spend, recorded as it lands. Forecast to complete, owned by the project manager. Variance against the original commitment.
These are not month-end snapshots. They are the current state of the project, drawn fresh whenever someone opens the view.
The line level matters. The tracker is not a single budget number. It is a grid of forecast and actual figures by month, split by spend type, vendor, staff member and source. A purchase order on the project shows up on the lines it relates to. A timesheet entry against a named role appears against the matching staffing line. The view rolls up cleanly to the project, the programme and the portfolio.
How it ties back to the roadmap
The link to the financial roadmap is built into the data model. When the plan is approved, the selected projects generate roadmap line items year by year. The project finance tracker carries those line items as its starting budget.
That means the question “is this project still working on the scope that was funded” can be answered without leaving the project. The approved envelope is on the record. The current commitment is on the record. The variance between them is on the record.
When a project asks for more money, the conversation is not “how much” first. It is “against which roadmap line, and how much of that line is left”, first. Which is a more useful conversation.
Forecast is a discipline, not a feed
A live tracker does not run itself. The honest position is that forecast quality depends on project managers maintaining the forecast, and actuals quality depends on the team recording costs against the right project as they happen. The platform makes both jobs easier. It does not do either job for them.
Where the platform does add something is in the AI review layer. The finance grid can be sent to a structured analysis that looks at vendor concentration, late-loaded spend, missing forecasts on previously active categories, and other patterns that quietly indicate a project drifting. The output is a short set of flags for the project manager and the finance partner to act on. Not a forecast it has generated. A list of things worth checking.
The boundary we left alone
The tracker is not trying to be the general ledger. It pulls actuals from the accounting system as they are recorded against the project, holds the project-level commitments and forecasts that the ledger does not, and links both to the roadmap line that authorised the work. Where the line is between the project finance tracker and the corporate ledger is deliberate.
That is a feature, not a limitation. Finance teams do not want a second source of truth for the year-end accounts. They want the project-level numbers in front of them, with the audit trail intact, while the decisions are still being made.
What this changes in practice
Three things tend to move once the tracker is live.
Month-end becomes shorter. The reconciliation between the project view and the finance view is a check, not a hunt.
Change control gets sharper. A scope addition that pushes a project past its roadmap line is visible the day the commitment is raised, not three weeks later in a variance report.
Closure becomes cleaner. A project closes against its roadmap line with a clear record of approved, committed, actual and remaining. The final position is auditable without anyone writing a separate close-out spreadsheet.
The bigger point
Project finance is rarely a counting problem. The numbers are findable, given enough time. It is a timing problem. By the time the count is done, the spending decisions have already been made.
Putting the project tracker and the funding roadmap on the same record fixes the timing. The PMO and the CFO function get to have one conversation about the same data, while it is still useful to be having it.
That is the value of closing the gap between the board pack and the ledger. Not better numbers. Better timing.
