The Spreadsheet That Runs Your Company: Acknowledging It, Then Replacing It

Every mid-market finance team has one. The spreadsheet that is, functionally, the system of record for something important. Usually built over years by one person who understood the business deeply. Usually a masterpiece of its kind. And usually one resignation, one corrupted file, or one formula error away from a crisis the business isn’t prepared to handle.

This isn’t a piece about spreadsheets being bad. Spreadsheets are among the most productive tools ever created for financial work, and the people who build sophisticated financial models in Excel are doing something genuinely impressive. This is a piece about a specific use case that spreadsheets handle worse than they appear to — the use case where a spreadsheet becomes, by default, the system of record for business-critical data that should live in a proper system.

How it happens

The spreadsheet-as-system usually starts with a legitimate gap. The ERP doesn’t produce the revenue recognition schedule the controller needs, so they build one. The billing system doesn’t calculate the commission structure the right way, so someone builds a model. The FP&A tool doesn’t support the segment structure the CFO wants, so the quarterly board pack gets built in Excel.

Each of these decisions is individually rational. The gap is real. The spreadsheet fills it faster than any other option. The model gets built, validated, and used. It gets handed off when the person who built it changes roles. The next person inherits the model and the implicit knowledge that comes with it — or doesn’t.

What makes it a system of record

A spreadsheet becomes a system of record when the business makes decisions based on what it says, when it’s treated as authoritative rather than analytical, and when no other system contains the same information in a more reliable form. The deferred revenue balance in the recognition spreadsheet is what gets posted to the GL. The commission calculation in the model is what drives payroll. The budget in the Excel file is what gets reported to the board.

Once the spreadsheet is the authoritative source for a number that matters, its fragility is the business’s fragility. The risks are well-documented: formula errors that propagate silently, version control that depends on disciplined file management rather than software, calculations that are valid for the business logic as it existed when the model was built and may not reflect process changes since then. A 2022 study by the European Spreadsheet Risks Interest Group found that over 88% of spreadsheets examined contained errors, and that error rates increased with spreadsheet complexity.¹

The institutional knowledge problem

The more significant risk, in many cases, is the knowledge embedded in the spreadsheet that exists nowhere else. The model the controller built encodes assumptions about how revenue is recognized, how costs are allocated, how exceptions are handled. Those assumptions aren’t documented separately — they’re expressed in the formula logic. When the controller moves on, the new person inherits the model but not the reasoning. They can maintain it. They may not know what to do when something unusual happens that the model wasn’t built to handle.

The knowledge loss isn’t immediate. It’s cumulative. The model drifts from the business as the business changes. Patches get added. Assumptions stop being valid but stay in the formulas. Eventually the model produces results that feel slightly wrong but nobody can explain why, because nobody remembers how it was supposed to work.

The replacement path

Replacing the spreadsheet-as-system requires two things that are usually handled in sequence: identifying where the data should live systemically, and migrating the business logic from the spreadsheet into that system in a way that’s transparent and testable.

The first step — choosing the right system home for the data — is usually obvious once the question is asked clearly. Revenue recognition should live in the ERP, connected to the contract and the subscription. Commissions should be calculated in a commissions system or in the ERP’s compensation module. The budget should live in a planning system that connects to actuals.

The second step — migrating the business logic — is where honesty matters. The logic in the spreadsheet is the institutional knowledge. Moving to a system without preserving and validating that logic produces a system that runs faster and fails more reliably. The migration needs to be treated as a knowledge transfer, with the original model’s builder involved in validating that the new system produces the same results.

Sources