Replacing Spreadsheet Dependence With an SQL Finance Dashboard
The $25M program relied on detailed financial management across 70 projects. I built an internal SQL-based finance dashboard to reduce spreadsheet dependence, improve data accuracy and make financial information easier for stakeholders to access.
The finance process had outgrown a spreadsheet-only way of working.
I was already managing forecasting, budgeting, allocations, POs, run rates, invoicing and accruals across the program. That made the reporting limitations very visible: finance data had to be both accurate and practical to use in recurring program decisions.
I developed an internal SQL-based finance dashboard and later administered and validated the finance view used by stakeholders.
The dashboard had to solve an operating problem, not become another reporting layer.
Spreadsheet dependence
Manual spreadsheet reporting made it harder to scale the same financial view across a large program.
Accuracy
Financial information needed checking before it could be used in program and stakeholder decisions.
Accessibility
The right people needed a simpler route to the financial information relevant to them.
Program context
A number by itself was not enough; it had to make sense against budgets, run rates, projects and the broader program picture.
I understood both sides of the problem: the financial process and the reporting need.
Because I owned the program financial cycle, I could design the reporting around the way the information was actually used. I built the SQL-based dashboard and also remained involved in the validation and governance of the financial view.
Build around the financial questions people already ask.
Mapped reporting to the finance cycle
Used the underlying budgeting, forecasting, allocation, run-rate, invoicing and accrual processes as the basis for the information the dashboard needed to support.
Built the SQL-based dashboard
Moved recurring financial information towards an internal SQL-driven view, reducing dependence on spreadsheet-only reporting.
Kept validation in the process
Administered and checked the finance dashboard so stakeholders received information that was both accessible and dependable.
Used the dashboard inside program governance
Kept the financial view connected to recurring program reviews and decisions rather than treating it as a standalone technical product.
The biggest risk in financial automation is making the wrong number easier to distribute.
Validation remained part of the process even after reporting became more automated.
The dashboard was tied back to the underlying financial processes and program context.
The SQL-based view reduced dependence on repeatedly rebuilding the same information manually.
The reporting was designed to make relevant financial information easier for stakeholders to obtain and use.
The dashboard stayed connected to program finance and review routines so the data led into management action.
The users were not looking for a technical solution; they wanted reliable financial answers.
Program leaders, finance stakeholders, project teams and vendor operations all needed different slices of the financial picture. The dashboard had to make that information easier to use without losing the controls behind it.
The program moved away from spreadsheet dependence towards a more accurate and accessible SQL-based finance view.
The technology was the easy part to describe. The more important work was understanding the finance process well enough to know what should be automated, what still needed validation and what information people actually used to make decisions.
Some operational detail and internal terminology have been generalised to respect organisational confidentiality.