Why Finance Teams Are Building Their Own Tools (And Why That's a Good Thing)

Table of contents

Finance teams have always been builders — just not in code.

They build in Excel. The models that run budgeting, headcount planning, scenario analysis, and month-end close are rarely “software” in the way most people mean it. They’re spreadsheets someone on the team built, pressure-tested, and refined over years until the business could depend on them.

A field audit by Ray Panko at the University of Hawaii found that 88% of operational spreadsheets contain errors.^[1]

That stat usually gets deployed as an argument to replace spreadsheets entirely. A more useful takeaway: finance teams are already doing the hardest part of tooling — encoding how the business actually works into something other people rely on. The failure mode isn’t that the spreadsheet exists. It’s what happens after it works.

Once a spreadsheet becomes important, it starts getting emailed, copied, and re-labeled. It ends up in a shared drive folder with fuzzy access rules. One person becomes the owner by default. And the organization ends up relying on a tool that can’t be governed like a tool.

Why do finance teams build their own tools instead of buying them?

Most finance systems are systems of record. They store transactions and enforce rules. Finance work — especially FP&A — lives in the space between systems: translating messy inputs into decisions.

That’s why so many “internal tools” inside finance look like spreadsheets:

a budget model that reconciles a hiring plan with payroll reality
a vendor spend tracker that maps general ledger exports to the categories leadership actually uses
a pricing calculator that reflects how discounts really work this quarter
a forecast that turns a few operational drivers into a plan leadership can pressure-test

These aren’t “nice-to-have spreadsheets.” They’re internal products. They exist because every business has edge cases, exceptions, and politics that no purchased tool can fully anticipate.

Even when a team buys specialized software, the last mile still ends up in Excel: exports for ad hoc adjustments, manual assumptions layered on top of system data, and one-off “what if we move hiring by 30 days?” scenarios. Excel isn’t a workaround. For most teams, it’s where decisions actually get made.

A spreadsheet becomes painful the moment it has users outside the person who built it.

When Sales, Ops, HR, or leadership needs to run the model, the spreadsheet stops being a personal tool and starts acting like a shared service. That’s where the friction shows up:

Version control breaks down. Someone downloads a copy, tweaks an assumption, and the team debates which file is real.
Access control becomes informal. The file is “in the right folder,” until someone changes roles or leaves and no one is sure who still has access.
Ownership gets fragile. The original author becomes a gatekeeper, even if they don’t want to be.
Auditability is thin. When a number changes, answering “who changed what, when, and why?” turns into detective work.
The tool is hard to find. People still ask “where’s the model?” every month.

Most teams respond with coping strategies: naming conventions, locked tabs, FINAL_v7 filenames, links pasted into Slack. Those are coordination hacks. They hold until the stakes get high.

What do finance teams actually want? Spreadsheet flexibility with tool-level governance

Finance teams don’t want to stop building. They want what they built to behave like a proper internal tool:

one canonical version
a stable URL people can bookmark
access that matches the company’s security posture
a clear owner and a clean way to update

That’s also why many “modernize finance” projects disappoint. They replace spreadsheet logic with a purchased product but don’t solve the day-to-day reality of sharing, controlling access, and iterating. If the new tool can’t keep up with how finance actually works, the spreadsheet quietly comes back.

How do you turn a finance spreadsheet into an internal tool?

There’s a better order of operations than “rebuild the spreadsheet as a custom app.”

Start by making the spreadsheet usable as a shared internal tool. That gets you the wins that matter immediately:

colleagues can use the tool without passing files around
access can be restricted to the right people
finance can update the underlying model without chasing down copies

Then, if the tool proves its value and you need deeper integration, evolve it. Not every spreadsheet should become a full product. But every spreadsheet other people depend on should be publishable.

A concrete example: the budget request model that becomes a bottleneck

Most companies have some version of this loop:

Department leads submit requests.
Finance validates assumptions.
Leadership reviews tradeoffs.
Finance consolidates and updates the model.

The spreadsheet starts as a clean model. Then it becomes a process.

People email requests. Finance updates cells. Finance becomes the human API. Eventually the model’s value isn’t the math anymore — it’s the interface: what inputs are required, what constraints apply, and what outputs requesters get back.

That workflow can still be powered by a spreadsheet. But it needs to be delivered like a tool.

A decision rule: if people keep asking you for the spreadsheet, it’s already a product

If your finance team is fielding repeated messages like:

“Can you resend the model?”
“Which version should I use?”
“I don’t have access to the folder.”
“Can you run the scenario for me?”

…you don’t have a spreadsheet problem. You have a publishing problem.

The tool exists. The team trusts it. The organization depends on it. It just isn’t delivered like software.

Where to start

If your finance team is already building in Excel, the fastest win isn’t rebuilding everything. It’s making those tools usable, findable, and governed — with:

a URL instead of a filename
login-protected access instead of folder permissions
a way to share without passing files around
a way to update without creating version chaos

The finance team already did the hard part. The missing piece is the publishing layer.

Sources

Ray Panko, University of Hawaii. “What We Know About Spreadsheet Errors,” meta-analysis (1995–2016). researchgate.net