Almost no business sits down and chooses spreadsheets as its system of record. It happens gradually — one tracker for inventory, another for purchase orders, a finance sheet that pulls numbers from both, and eventually a stack of interlinked files that nobody fully understands except the one person who built them. Excel and Google Sheets are genuinely excellent tools for what they're built for: ad hoc analysis, quick modeling, one-off reporting. The problem isn't that spreadsheets are bad software. It's that they were never designed to be multi-user, real-time operational systems of record, and at a certain point businesses start using them as exactly that.
The question worth asking isn't "do we have a lot of data in spreadsheets" — almost every business does, and that alone isn't a problem. The real question is whether spreadsheets have become the thing your operations actually depend on to function day to day. That's a different, much more specific threshold, and it usually shows up as a handful of concrete symptoms rather than a vague sense that things feel messy.
The most reliable sign is reconciliation error, not data volume. If your finance team is regularly finding that the inventory count in the warehouse sheet doesn't match what's in the sales sheet, or that a purchase order was entered twice because two people were working off different copies of the same file, that's not a training problem — it's a structural one. Spreadsheets have no built-in concept of a single source of truth when multiple people are editing in parallel, and "just be more careful" stops scaling somewhere around the third or fourth person touching the file.
A second concrete signal is version chaos: file names like Inventory_Final_v3_ACTUAL_updated.xlsx being emailed around, or a shared drive where nobody's certain which copy is current. A third is the absence of an audit trail — when something's wrong, nobody can say who changed a number, when, or why, because a cell just changed and the previous value is gone. A fourth, and often the most costly, is systems drifting out of sync with each other: finance's revenue numbers don't match sales' pipeline numbers, or the stock level in the sheet doesn't match what's physically on the shelf, because there's no automatic link between the sheet and the real-world event it's supposed to represent. None of these are about being "too big" for Excel in some abstract sense — they're specific, describable failures that cost real time and real money every month they continue.
An ERP system's core value isn't reporting dashboards or a nicer interface — it's a single, shared, real-time data model that every department reads from and writes to, with rules about who can change what and a record of every change. When a sales order is entered in a platform like Odoo, NetSuite, or Zoho ERP, inventory is decremented automatically, finance sees the receivable, and procurement can see the resulting stock impact — all from one transaction, not three people manually updating three separate files. That's what actually eliminates reconciliation errors: there's only one place the number lives, not several copies that have to be kept in sync by hand.
The audit trail piece matters more than it sounds like on paper. When a number is wrong, an ERP can usually show exactly who changed it, when, and often why, because approvals and edits are logged as part of how the system works, not as an afterthought. Role-based permissions matter for the same reason spreadsheets tend to fail: a warehouse clerk shouldn't be able to edit a finance ledger, and a spreadsheet with sharing turned on generally can't enforce that distinction cleanly, no matter how many tabs are hidden or protected.
It's worth being honest about the limits, because this is where a lot of ERP rollouts disappoint people who expected it to solve everything. An ERP does not fix bad processes — it makes them visible and repeatable, for better or worse. If your purchase approval process is genuinely unclear or inconsistent, implementing an ERP forces you to define it explicitly as a workflow, which is valuable, but the system itself won't invent a good process for you. Garbage-in, garbage-out still applies: an ERP with inconsistent product codes or duplicate customer records will just make those inconsistencies more visible and more expensive to fix, not less.
It also doesn't fix a data migration problem by itself. Moving years of spreadsheet history into a structured system is genuinely hard, unglamorous work — cleaning up duplicate SKUs, standardizing units, deciding what historical data is even worth migrating versus archiving. And it doesn't remove the need for change management: an ERP that the team resists using, or partially adopts while keeping shadow spreadsheets "just in case," delivers a fraction of its value and can end up as the worst of both worlds — two systems that now need to be kept in sync with each other.
There's no universal headcount or revenue number at which a business should switch — a ten-person business with three sheets syncing perfectly well can be in better shape than a fifty-person business drowning in reconciliation errors. The more useful exercise is tallying up the actual cost of staying on spreadsheets: hours per week spent reconciling numbers across files, the frequency and size of errors that reach a customer or a financial statement, and the number of people whose job has quietly become "keeping the spreadsheets consistent" rather than the work they were actually hired to do. When that cost is clearly bigger than the cost and disruption of an implementation, that's the real signal — not a specific company size.
It's also worth sizing the solution to the actual problem. Not every business that's outgrown spreadsheets needs a full enterprise ERP rollout across every department on day one. Sometimes the honest answer is a phased implementation — inventory and finance first, HR and procurement later — or even a lighter-weight tool for a specific workflow rather than a company-wide platform change. The goal is fixing the specific reconciliation, audit-trail, and sync problems that are actually costing time and money, not adopting a bigger system because it sounds more serious.