This is Part 2 of a three-part series on project financial management in infrastructure programs. Part 1 examined why financial control breaks during execution — read it here.
Many infrastructure operators running spreadsheet-based financial management have misclassified what they’re operating. They describe it as a tracking tool. It’s functioning as a financial control system for capital programs with significant cost exposure, and it was never designed for that role.
The consequences of that misclassification become measurable as portfolios scale: committed costs that aren’t visible until reconciliation runs, budget adjustments with no traceable history, time-phased forecasts that fall out of sync with construction reality. The spreadsheet didn’t change. The demands placed on it did.
What spreadsheet-based financial control actually requires
Spreadsheets were designed as calculation environments. They have no concept of workflow, version authority, or financial state. When a single analyst controls a file, those absences are manageable. When a portfolio expands to ten, twenty, or fifty projects running in parallel, with development engineers, construction managers, procurement teams, and finance directors all contributing financial data from different systems at different times, maintaining a single authoritative financial picture requires constant manual intervention.
Spreadsheets don’t enforce a single version of financial truth. Any team member can update an estimate to complete, reclassify a cost category, or adjust a budget line without that change being visible to the rest of the program. Across a large portfolio, someone has to determine which file is current, which numbers are authoritative, and which updates have been incorporated before any financial summary can be trusted.
That reconciliation effort is the primary mechanism by which financial control operates in spreadsheet-based programs. As programs scale, it consumes increasing coordinator time and still produces financial summaries that are partially outdated by the time they’re circulated.
What scale actually looks like for infrastructure operators
A utility-scale solar developer or data center operator at portfolio scale is typically managing projects at different lifecycle stages simultaneously: some in development, some in active construction, some in commissioning. Each stage has different financial dynamics. Development projects carry soft costs and contingency assumptions. Construction projects generate committed costs through purchase orders and change orders before a single invoice is processed. Commissioning projects require final cost reconciliation against the approved baseline.
Financial visibility across those stages requires manually consolidating inputs from ERP exports, procurement systems, and project management tools into a unified view. During active construction, that consolidation may need to happen daily. As project count grows, so does the frequency of updates required and the number of handoffs between teams introducing inconsistency.
More parties also have legitimate reasons to touch financial data as programs scale: contractors submitting change orders, owners requesting program-level summaries, finance teams preparing period-end reports. Each interaction arrives from a different system and requires a manual reconciliation cycle to incorporate.
The committed cost blind spot
Committed costs, purchase orders and contract obligations approved but not yet invoiced, represent real financial exposure the moment they’re signed. In capital-intensive programs, committed exposure can represent a substantial portion of total project cost months before actuals appear in the ERP.
In a spreadsheet model, committed costs are typically tracked separately from actuals, often in a procurement tool or a dedicated tab, and consolidated manually into the financial summary. EAC (estimate at completion) calculations are therefore frequently understated during active construction, because the tool requires manual intervention to connect contractual obligation to forecast. The financial picture appears better than it is until someone runs the reconciliation.
Beyond total cost, knowing when costs will land, which months require the highest capital draw, where schedule changes will compress or shift spend, is what cash flow planning and program-level resource allocation actually depend on. Maintaining an accurate time-phased cost projection across a portfolio of active projects requires continuous manual updates in a spreadsheet model, and those projections fall out of sync as construction conditions change.
The governance gap
Budget adjustments happen in every infrastructure program. Scope changes, contractor modifications, design revisions: each should produce a documented, traceable delta against the approved baseline. In a structured system, those adjustments generate an audit record: who requested the change, when it was approved, whether it was driven by an internal decision or an external contractor event, and what the cumulative effect on the budget is.
In Excel, budget adjustments are typically made by overwriting existing values. Historical context is lost unless someone has manually implemented version control. Ownership of changes is unclear. When a finance lead needs to explain a material variance against the original baseline, reconstructing that history becomes a manual exercise through file versions and email chains.
Responsible capital stewardship requires more than accurate numbers at a point in time. It requires a traceable record of how those numbers changed and why. Spreadsheets provide neither by default.
Where spreadsheet-based programs end up
As infrastructure portfolios scale, the manual effort required to maintain forecast accuracy grows faster than the portfolio itself. Committed cost visibility lags behind actual exposure. Budget adjustments accumulate without traceable history. Time-phased cost projections fall out of sync with construction reality. Financial summaries require assembly before they can be used.
Operators typically respond by adding coordinators, extending reporting timelines, or accepting reduced confidence in their own numbers. Each response increases operational cost without addressing the source of the problem: financial control in spreadsheet-based programs depends on manual processes, and manual processes don’t scale.
What infrastructure operators at portfolio scale require is a financial control layer embedded in project execution, one where committed costs are visible the moment obligations are approved, budget adjustments are governed and traceable, time-phased cost projections stay current as conditions change, and a consolidated financial summary reflects the actual state of the program without manual assembly.
This is Part 2 of a three-part series. Part 1 examined why financial control breaks during execution. The next post in this series examines how infrastructure operators should evaluate project financial management systems, and where most buyers go wrong in the selection process.
See Finance Central in action
Finance Central gives infrastructure operators a financial control layer embedded directly in project execution, replacing spreadsheet-based reconciliation with structured workflows for budgets, commitments, forecasts, and time-phased cost projections.
Key Takeaways
- Spreadsheets function as tracking tools at small scale. As project portfolios grow, they become the de facto financial control system for programs they were never designed to manage.
- Spreadsheets can model financial data but cannot enforce workflow, version authority, or audit trails across distributed teams. At portfolio scale, financial control ends up living in the manual processes surrounding the file.
- Committed costs create persistent forecast error in spreadsheet-based programs because contractual obligations aren’t automatically reflected in EAC calculations until someone runs the reconciliation.
- Time-phased cost projections, knowing when costs will land rather than just the total, require continuous manual maintenance in spreadsheets and fall out of sync as construction conditions change.
- Responsible capital stewardship requires a traceable record of budget changes. Spreadsheets provide neither version authority nor audit trails by default.
FAQs
Version control tools preserve file history, but they don’t enforce financial workflows. They can show you what a file looked like at a previous point in time, but they can’t prevent two people from updating different versions simultaneously, enforce an approval process for budget adjustments, or automatically reflect a new purchase order in a project’s EAC. The governance and workflow gaps remain.
There’s no universal threshold. The breaking point depends on project complexity, team distribution, and how frequently financial data changes. Programs with high contractor volume, active change order management, or parallel construction across multiple sites tend to reach the limit earlier. The signal is usually when reconciliation effort becomes a recurring bottleneck rather than a periodic task.
No. ERP systems serve a necessary function as the system of record for actuals, compliance, and financial close. The gap spreadsheets are filling is not in the ERP. It’s in the layer between project execution and accounting. A project financial management system addresses that gap by managing budgets, commitments, forecasts, and time-phased cost projections within the execution environment, while keeping the ERP as the authoritative source for actuals.
