The Spreadsheet Running Your Business

There is a spreadsheet somewhere in your business that matters more than most of your software. Somebody built it years ago, it has grown, and a real part of your operation now depends on it.

It is not backed up properly, one person understands the formulas, and if it were lost on a Tuesday you would have a bad month.

Why it exists

Not because anybody made a bad decision. It exists because your software did not do the thing, somebody needed it done that week, and a spreadsheet was the only tool available without a budget conversation.

That is exactly the right instinct, and the reason these files are valuable rather than embarrassing. Somebody identified a real gap and closed it, at no cost, without asking permission.

The risk is specific

One person understands it. The formulas encode business rules that exist nowhere else, including several decisions nobody remembers making.

Errors are silent. A dragged formula that stopped one row short produces a number that is wrong and looks entirely normal. This is the most common serious failure and it can persist for years.

Versions multiply. It gets emailed, edited and returned, and now there are four. The one being used for decisions is whichever was opened.

It cannot be checked. There is no record of who changed what, so a disputed figure cannot be traced.

Do not replace it yet

The usual reaction is to commission a proper system. That is frequently the wrong first move, and it is how businesses end up with software that does less than the spreadsheet did.

The file is the most accurate specification you will ever have of what the business actually needs. It was built by the person who does the work, refined against real cases over years, and it contains every exception that a requirements document would have missed.

Read it before replacing it. Most of the value of the project is in understanding what is already there.

Reduce the risk this week

• Move it somewhere shared and versioned. Off the laptop, with history. An hour, and it removes the worst outcome entirely.

• Have somebody else walk through it with the person who built it, and write down what each section does. Two hours, and it ends the single point of dependency.

• Find the manual steps. The paste that happens every Monday, the column somebody updates by hand. Those are where the errors live.

• Check one output against reality. Take a figure it produced last month and verify it independently. This is where silent errors surface.

None of that requires a project or a budget, and it converts a serious exposure into an ordinary one.

What AI changes about the decision

Two things, and the first was previously the expensive part of any replacement.

AI reads the logic out. Given the file, it can explain in plain language what the formulas actually do, including the parts the author has forgotten, and flag the inconsistencies: the rows excluded from a range, the hard coded value in the middle of a calculation, the rule that applies to some records and not others.

That is the documentation nobody was ever going to write, and it is what makes the replace-or-keep decision possible on evidence rather than on nerve.

AI removes the reason it was manual. Most of these files exist because the input arrives in a form no system could read: emails, statements, supplier reports, documents. Somebody keys it into a sheet because a sheet accepts anything. Once the reading is handled, the case for keeping a manual file mostly disappears.

The person who built it

Worth handling deliberately, because how this conversation goes decides whether the project works.

They solved a real problem with the tools they had, usually in their own time, and the business has depended on it since. If the first thing they hear is that the spreadsheet is a risk that needs replacing, they will reasonably read that as criticism of the one useful thing nobody asked them to do.

Say the opposite, because it is true: the file is the specification, and it is better than anything the business would have written. Then ask them to be the person who decides whether the replacement is good enough. They know every exception, and they will refuse things a manager would have accepted.

The macro is a different problem

One category deserves separate treatment.

If your spreadsheet contains macros or scripts written years ago by somebody who has left, that is not a spreadsheet risk, it is undocumented software running your business with none of the controls software would have. It also tends to break silently on a platform update rather than at a convenient moment.

Those are worth reading and documenting first, ahead of anything else on this list, because they are the ones most likely to fail in a way nobody can diagnose.

Sometimes the answer is to keep it

Worth saying plainly, because the pressure runs the other way.

If one person uses it, the logic is stable, and the consequence of an error is small, a documented, backed up, shared spreadsheet is a perfectly good answer. Building software to replace something that works is how businesses spend forty thousand dollars to be slightly worse off.

Replace it when several people need it at once, when errors would be expensive, when it has to connect to other systems, or when it has grown past the point anybody can explain it. Until then, make it safe and leave it alone.

Find yours

Ask one question at your next management meeting: if we lost one file tomorrow, which would hurt most.

Everybody will name the same one within about four seconds, which tells you the exposure was already known and simply never written down. That is the file, and an afternoon on it this week is worth more than most projects on the list.

AI Optimize reads the spreadsheet and explains what it actually does before anybody proposes replacing it. That work sits under Custom Software.