Spreadsheets are not evidence that a business is badly run. They are accessible, adaptable and familiar. Modern Excel and Google Sheets files support simultaneous editing, comments and version history. A spreadsheet can remain the right tool for analysis, modelling, temporary planning and many well-bounded activities.
The warning appears when the spreadsheet stops being a tool inside the work and becomes the system holding the work together.
You have probably reached that point when making one business change requires several spreadsheet changes, employees are afraid that an improvement might break the system, or management cannot make financial decisions until separate ledgers converge at month-end or year-end.
These problems do not automatically mean that you need an ERP. They mean the spreadsheet is coordinating more than it can safely own. What replaces it depends on which burden has become unacceptable.
You do not outgrow a spreadsheet at a particular size
A sheet with 30 rows can be an operational risk. A workbook with 30,000 rows can be perfectly appropriate.
The difference is not the number of cells. It is the job those cells are expected to perform.
Spreadsheets are naturally good at calculating, comparing, modelling and presenting data. They become harder to govern when expected to decide who owns the next action, enforce a sequence of approvals, protect different records for different employees, trigger another system, preserve the history of a business event or keep several departments aligned around the same changing fact.
That distinction matters because replacing every large spreadsheet would be wasteful. The goal is to remove work that has become fragile, repetitive or too late to support decisions—not to ban spreadsheets from the company.
One change requires several changes
The clearest sign is the cost of changing one fact.
A customer moves a delivery date. Sales updates its pipeline. The project manager changes a tracker. Purchasing revises a supplier plan. Finance adjusts a cash-flow forecast. Someone updates the management report before the next meeting.
Each file may be internally correct, yet the business now has several versions of the same event. If one update is missed, two departments can act on different dates without either knowing that a conflict exists.
The same pattern appears when the company changes a price, adds a service, opens a location or introduces an approval. What looks like a small operating decision becomes a search for every place where the old assumption was copied.
This is not merely duplicate data. It changes employee behaviour. People postpone useful improvements because the work of updating the system is larger than the change itself. They build checklists to remember which files must follow which other files. Senior employees become human integration points because they are the only people who know where the copies live.
The right replacement depends on why the copies exist.
If the current applications perform their jobs well but employees repeatedly re-enter the same facts, the useful intervention may be to remove repeated updates between systems. A confirmed deal can create the delivery record, notify the owner and pass the required details forward without somebody copying the row.
If the records are mainly clients, projects, responsibilities, documents and light approvals, the company may need a lighter operating setup in Notion. The objective is one maintained record with different views, rather than another collection of departmental copies.
Neither choice means automating every handoff. Automate stable repetition. Keep judgement visible and owned by a person.
People are afraid to change the system
The second sign is hesitation.
Employees know that a column, formula or workflow should be changed, but nobody is confident about what else depends on it. A small improvement might break a report, remove a reference or delay work for another department.
The system may still function, but only because experienced employees know what not to touch.
That creates a dangerous form of stability. The business cannot improve its way of working without risking its current work. Knowledge lives in individual memory. Dependencies are difficult to see. Testing often means making the change and waiting to discover what failed.
Fear also produces shadow systems. An employee downloads a private copy before changing the shared file. A manager keeps a separate control sheet because the main tracker is not trusted. Teams exchange screenshots so that a changing dashboard cannot alter the evidence behind a decision. Every defensive copy makes the next change harder.
A dependable operating system should make change controlled, not frightening. People should be able to understand what will be affected, test the change, identify an owner and reverse it when necessary.
Before buying software, map the dependencies before rebuilding. Identify which records are authoritative, which formulas affect decisions, who can approve a change and what must continue working during the transition. This is not an abstract exercise in documenting everything. It is a practical way to separate essential controls from habits that accumulated around the workbook.
The result may still be automation, Notion or ERP. But the company can move without reproducing invisible dependencies in a newer tool.
Financial truth arrives after the decision
The third sign appears when management cannot understand the financial position until several ledgers and reports are reconciled at the end of the month—or sometimes the year.
Sales has the order. Operations has the delivery status. Purchasing has the supplier commitment. Inventory has the movement. Finance has the invoice and payment. Each record may be correct, but management cannot see their combined financial effect until someone brings them together.
By then, the decision has already happened.
A sales manager may see revenue without the latest fulfilment cost. Purchasing may commit cash without seeing a change in the sales plan. Finance may report what has been invoiced while management needs to know what has been ordered, delivered, accrued and collected. The month-end close becomes the first reliable explanation of the month instead of a confirmation of information managers already had.
This is the situation in which ERP becomes materially different from another shared workspace.
An ERP records a business event once and carries it through the departments affected by it. A confirmed sale can update delivery requirements, stock demand, invoicing and financial records without each team rebuilding the event in a separate ledger. A purchase can move from request and approval to receipt, supplier invoice and payment while retaining the relationship between those steps.
That gives management a more current view of committed revenue, costs, stock and cash exposure. It reduces dependence on month-end reconciliation as the first moment when the business understands what already happened.
It also explains why ERP should not be prescribed merely because a spreadsheet is untidy. If finance, purchasing, stock and delivery do not need to act on the same orders and movements, a full ERP can impose more structure than the operation needs. If they do, read how to choose an ERP around the decisions and controls the business must share—not around the longest feature list.
Spreadsheet errors are real, but the evidence needs context
Spreadsheet risk is often presented with a dramatic universal statistic. The evidence is more useful when stated precisely.
In a 1998 controlled experiment, 152 undergraduate and MBA participants built a relatively simple model. Thirty-five percent of the submitted models were incorrect. Among the 17 MBA participants who reported at least 250 hours of spreadsheet experience, 24% were incorrect. This does not prove that 35% of business spreadsheets are wrong, and it should not be presented that way. It does show that experience alone did not eliminate errors even in a bounded task.
A later controlled study found that a structured design approach significantly reduced linking errors. The practical lesson is not that spreadsheets inevitably fail. It is that structure, review and visible dependencies matter.
Modern collaboration features do not remove that need. Excel supports co-authoring, and Google Sheets provides version history. Those features help people work together and recover earlier versions. They do not decide which copy of a customer, price or delivery commitment should govern the rest of the business.
What should replace the overloaded spreadsheet?
The replacement should match the burden, not the software category that happens to be selling to you.
| What employees experience | What the replacement must fix | Likely route | Cost and time shape | The clearest indication |
|---|---|---|---|---|
| One update is repeated across several applications | Pass the same fact forward without manual re-entry | Automation and integrations | A single workflow often takes 2–4 weeks; broader integrations 4–10 weeks, with a fixed price after assessment | The applications work, but employees keep copying the same facts |
| Nobody is confident about changing formulas or workflows | Expose dependencies, ownership and controls before rebuilding | Technology consulting | Usually a defined period of analysis over a few weeks; scope depends on the decisions involved | The business depends on rules that only a few employees understand |
| Client, project, document and responsibility records have no shared structure | Give operational work one adaptable, searchable home | Notion | Usually weeks rather than quarters, fixed after a readiness session | The work needs coordination more than accounting control |
| Financial decisions wait for sales, purchasing, stock and finance records to be reconciled | Carry an order or purchase through delivery, invoice and payment in one connected system | ERP | Small implementations may take 1–3 months, mid-sized 3–5 months and larger work 6–9 months; defined scope is fixed, ongoing support may use a retainer | Management cannot see the financial effect of current operations |
The categories can overlap. A company might first make the logic safe, then automate two handoffs. Another may use Notion for delivery while accounting remains the financial source of truth. A company implementing ERP may still keep spreadsheets for forecasting and analysis.
The decision is not which product should contain everything. It is which system should own each kind of truth.
Fix these things before moving the data
Migration should not begin with a bulk import. It should begin with a few operational decisions.
First, name the authoritative record. If the same customer, project or order appears in five files, decide which system is allowed to define it.
Second, name the owner of each important state. Someone must be responsible for confirming that an order is approved, a delivery is complete or a supplier invoice is ready. Software can display and enforce ownership, but it cannot invent accountable decisions.
Third, separate repetition from judgement. Re-keying an approved order is repetition. Deciding whether an unusual order should be approved is judgement. Automate the first and make the second visible.
Fourth, preserve what spreadsheets still do well. Keep them for calculations, scenario models, temporary analysis and reports whose inputs already come from controlled sources. Replacing operational coordination does not require replacing every grid.
Finally, move one real workflow first. Test it with the employees who carry the work, not only the managers who consume its reports. A successful pilot should make an ordinary change easier and safer, not merely make the dashboard look cleaner.
Three questions before you choose
Ask three questions using a recent example, not a hypothetical future process:
- When one customer, price or delivery fact changes, how many places must employees update manually?
- What useful change are employees postponing because they fear breaking a formula, report or handoff?
- Which financial decision must wait until sales, purchasing, inventory and finance records are reconciled?
The answers reveal the shape of the problem, but they are not a software specification. Sahla's business operations assessment examines the wider operation and routes the next step without assuming that ERP, Notion, automation or consulting must win.
The spreadsheet may be where the problem becomes visible. It is not always the problem itself. Replace the burden that is blocking the business, and keep the spreadsheet wherever it remains the simplest reliable tool.
