Somewhere in your company there is a spreadsheet that no one officially owns, that three departments depend on, and that one person understands. It probably has a tab called "DO NOT TOUCH." It was built in an afternoon four years ago to solve a real problem, and it worked so well that it never got replaced.
This isn't a failure of discipline. Spreadsheets multiply because they are the fastest tool available when a system can't do something and nobody has time to wait for IT. The problem isn't that they exist. The problem is that some of them quietly became load-bearing — and load-bearing things deserve to be engineered, not improvised.
Start With an Inventory, Not an Opinion
Before anyone argues about what should be automated, find out what's actually running. Ask each team leader a simple question: what spreadsheets or docs do you touch every week that aren't part of a system?
For each one, capture five things: who maintains it, who depends on its output, where the data comes in, where the data goes out, and what happens if it's wrong for a week. That last question is the important one. It separates convenience from risk.
Expect surprises. Pricing exceptions, commission calculations, inventory reorder points, job costing, PTO tracking, customer onboarding checklists — these tend to live outside the system far more often than owners assume. So do the manual reconciliations that happen quietly at month-end because two systems don't agree.
Apply the Load-Bearing Test
A spreadsheet is load-bearing if any of the following are true:
- Money moves because of it — you invoice, pay, price, or commission from its output
- It holds data that exists nowhere else, so losing the file means losing the record
- A compliance, tax, or contractual obligation depends on its accuracy
- Only one person can explain the formulas, and that person is not documenting anything
- Another system's data is manually re-keyed into it, or out of it, on a recurring basis
Everything that passes this test needs a plan. Everything that doesn't can stay exactly where it is, and you should feel fine about that.
Sort Into Four Buckets
Once you know what's load-bearing, decide what each spreadsheet becomes.
Keep. Analysis, modeling, scenario planning, one-off investigations. Spreadsheets are excellent at thinking. Leave them alone.
Formalize in the system. The work belongs in your ERP or CRM and the system can already do it — the team just never got the fields, workflow, or report configured. This is usually the cheapest, fastest win in the whole exercise.
Replace with integration or automation. The spreadsheet exists because two systems don't talk. The spreadsheet is a human API. Replace the human with a real one: a scheduled sync, a webhook, a middleware flow that moves records and reconciles differences.
Retire. It was built for a process that changed, a report nobody reads, or a customer you no longer serve. Deleting things is a legitimate outcome and it costs nothing.
Don't Rebuild the Spreadsheet — Rebuild the Decision
The most common mistake is recreating the spreadsheet field-for-field inside the new system. You end up with all the original assumptions, plus a longer change request queue.
Instead, ask what decision the spreadsheet supports. Someone built a margin tracker because they needed to know which jobs to stop quoting. Someone built a reorder sheet because they needed to know what to buy Monday. Design for the decision, and the required data model usually gets simpler than the spreadsheet was.
This is also where a unified view earns its keep. A lot of shadow spreadsheets exist purely because the answer requires data from three tools at once — the accounting system, the CRM, and the website. Pull those into one place and the spreadsheet has no reason to exist.
Sequence by Risk, Not by Annoyance
The loudest complaint is rarely the biggest exposure. Fix in this order: things that create financial or compliance risk, then things that consume the most recurring hours, then things that irritate people.
Work one process at a time and let each fix prove itself before starting the next. A big-bang spreadsheet purge fails for the same reason big-bang ERP rollouts fail — too many changes landing on people at once, with no time to trust any of them.
Where AI Helps and Where It Doesn't
AI is genuinely good at the archaeology part of this work: reading a tangled workbook and explaining what the formulas do, drafting documentation for the logic you're about to migrate, and summarizing where two data sources disagree. That shortens the discovery phase considerably.
What AI won't do is decide which processes matter to your business. That still requires an operator who understands how the money actually flows.
The Real Payoff
When load-bearing work lives in systems instead of files, three things change. Reporting stops requiring a person. Vacations stop being risky. And onboarding a new hire stops depending on whether they inherit the right version of the file.
If you have a good idea which spreadsheets in your business are load-bearing — or a sinking feeling that you don't — that's a productive conversation to have. Reach out to Infraxio and we'll walk your processes with you and map what should stay, what should move into your ERP, and what should be an integration instead of a person.