The spreadsheet that runs your company

There is a workbook somewhere in your finance function that nobody wants to touch.

It has grown for years. It has a tab that exists because of a one-off question in 2021, a column of hardcoded numbers where a lookup used to be, and a SUM that stops one row short of the range somebody extended by hand. The close depends on it. The person who built it may or may not still work there.

This is not a story about a badly run finance team. Almost every finance team has one of these. It is what happens when the only programmable tool on the desk is a spreadsheet, and the work keeps needing programs.

Nobody meant to write software

The workbook started as a calculation. Then it needed to handle a second entity. Then a currency. Then someone added an IF statement, then a nested one, and at some point it stopped being a document and became a program.

The trouble is that it is a program written in the one environment with no version control, no tests, no separation between logic and data, and no way to see what changed between last month and this one. Every cell is potentially the mistake, and none of them announce themselves.

This has been studied for a long time and the findings are not comforting. Ray Panko, who has spent a career on this at the University of Hawaii, pulled together the field audits that used rigorous methods and found that at least 86% of the operational spreadsheets examined contained at least one error.

The cause is not carelessness. Humans make small mistakes at a low but stubborn rate during any complex task, and a spreadsheet gives those mistakes nowhere to surface. A program with a bug usually crashes. A spreadsheet with a bug returns a number.

There is an entire research community devoted to this, the European Spreadsheet Risks Interest Group, which has been collecting peer-reviewed work and public horror stories since 2000. It is a slightly absurd fact that this needs to exist, and a completely reasonable one.

The famous ones

The cases that made the news are useful because they show the failure mode, not because the organizations involved were unusual.

In April 2013, three researchers at UMass Amherst got hold of the working spreadsheet behind a heavily cited economics paper on public debt and growth. The paper’s headline claim was that countries above 90% debt-to-GDP saw average growth of -0.1%. One of the problems was an averaging formula that did not reach every row, leaving five countries out of the calculation. Corrected, the same analysis produced average growth of 2.2%. That paper had been cited in real budget arguments in several countries.

In October 2020, Public Health England lost 15,841 positive COVID-19 test results because case data was being handled in the old XLS format, which caps out at 65,536 rows. When a file filled up, the extra cases were simply left off. The consequence was not a wrong chart. It was contacts who were never traced.

Neither of these was caused by someone being bad at spreadsheets. Both were caused by a spreadsheet being asked to be a data pipeline.

Why a small program is the safer option

Here is the counterintuitive part, especially if you have spent a career being told that code is the risky thing and the spreadsheet is the safe one.

A ten-line script that reads the bank export and the ledger and reports mismatches is easier to verify than a workbook that does the same job. You can read it start to finish. It has one code path instead of a thousand cells that might each be different. You can run it against last month’s data and check that it produces last month’s answer. You can put it in version control and see exactly what changed.

Most importantly, it separates the logic from the data. The reason the scary workbook is scary is that its logic and its data are interleaved beyond recovery. Nobody can tell you what it does without opening it, and opening it does not really tell you either.

The reason finance teams did not do this before is straightforward. Writing the script required a programmer, and programmers were not going to be assigned to your bank reconciliation.

That constraint is gone

The change of the last couple of years is not that AI can write enterprise software. It is that AI can write the small thing, and the small thing was always the gap.

The examples in the accounting trade press are exactly this shape. The Journal of Accountancy ran a piece in June 2025 collecting them. Karl Spanbauer, a CPA and controller at the Capital Area Food Bank, built himself a workflow in Power Automate that scans, summarizes, and responds to incoming mail. Glenn Hopper at Eventus Advisory Group built a bot that drafts technical accounting memos against the firm’s own back catalogue, which he reckons took memo writing “from a four-hour task to a 30-minute task that includes careful human review.”

Neither of those is a moonshot. Both are somebody in finance writing the tool they had wanted for years.

These are not replacing accountants. They are replacing the workbook, which is a much better thing to replace.

What finance actually needs from a place to run it

So the script exists. Now it needs to live somewhere, and finance has requirements that a general audience does not.

Access has to be real. Not a link that keeps working for whoever it was forwarded to. A tool that touches the ledger needs to know who opened it, and the answer needs to be a work identity your company already manages.

There has to be a record. Auditors ask who ran what and when. “It was on Dana’s laptop” is not an answer, and it is the answer today for an enormous amount of finance tooling.

Rollback has to include the data. Reverting code while leaving a half-migrated database behind is worse than not reverting at all. Reverting both together is the only version that means anything at close.

It cannot require an engineer to keep alive. If a tool breaks on day two of close and the fix requires a skill nobody on the team has, the tool is already dead. The thing that makes this newly tractable is that an assistant can read the error and repair its own work, provided it can see the logs.

The honest part

Sploot is being built for exactly this handoff: the folder your assistant wrote goes in, a link your team opens with their work email comes out. It is in private beta, there is nothing to sign into yet, and I would rather say that than pretend otherwise.

But you do not need us to act on the underlying point. The workbook everyone is afraid of is afraid-making for structural reasons, and those reasons are now fixable by the people who live with it. That is genuinely new. The remaining problem is only about where the fixed version gets to live.