The spreadsheet lifecycle
Every commerce business starts the same way: a spreadsheet that works. Orders go in a column, costs go in another, and for a while the arithmetic is simple enough that one sheet, kept by one careful person, tells the truth.
Then the business does the thing it's supposed to do — it grows. A second channel opens. A warehouse gets added. Someone starts handling returns in a separate tab because the main sheet was getting cluttered. A finance hire builds their own version because they don't fully trust the operations one. None of this happens through negligence. Each fork is a reasonable, local fix to a real problem — "I just need my own copy to try something" — and each one is invisible the day it's made.
The lifecycle has a predictable shape: works, then forks, then nobody trusts the totals. Not because anyone did anything wrong, but because a spreadsheet has no concept of a single source of truth. It has cells, and cells can diverge the moment two people open two copies. By the time a business notices the problem, there usually isn't one drifting spreadsheet to fix — there are four or five, each partially right, and reconciling them has become its own monthly project.
This isn't a story about disorganized teams. It's what happens mechanically to any system built on independent files instead of one shared record.
The real cost is latency
The obvious cost of spreadsheet sprawl is the time spent reconciling it. The less obvious — and more expensive — cost is latency: the gap between something happening in the business and someone being able to see it happened.
A spreadsheet-based operation makes decisions on stale numbers by construction. Sales data gets exported at the end of the day, or the end of the week. Stock counts get updated when someone remembers to. Cost information trickles in from a supplier invoice that lands in an inbox and doesn't get logged until the next bookkeeping pass. Every one of those delays means a decision — reorder this SKU, cut this ad spend, extend this payment term — gets made on a number that was already out of date when it was read.
Latency compounds because it's invisible in the moment. Nobody feels behind while they're looking at a spreadsheet — the numbers on screen look current, precise, complete. The gap only becomes visible in hindsight, when a stockout happens on a SKU that "looked fine" three days ago, or a margin call gets made on a product whose true cost hadn't been updated in the sheet yet.
The fix isn't more spreadsheet discipline. It's closing the distance between an event happening and it being visible — which is a different kind of system, not a better-organized version of the same one. That's the role an always-on intelligence layer is meant to play: surfacing what changed as it changes, instead of waiting for someone to notice during the next export.
What "one system" actually means, mechanically
"One system" gets used as marketing language often enough that it's worth being precise about what it means underneath. It isn't a dashboard that pulls from five spreadsheets and displays them side by side — that's still five sources of truth, just with a nicer viewer. It isn't a nightly sync job that copies numbers from one tool into another — that's still latency, just on a schedule instead of ad hoc.
Mechanically, one system means a single event writes to every place that event needs to be reflected, in the same transaction, once. A sale isn't "recorded in the order tool, then later reflected in inventory, then later posted to the ledger." A sale happens, and in that same instant: the order exists, the stock for that SKU decrements at the location it shipped from, and the journal entry for revenue, cost of goods sold, and any tax owed gets posted — debits and credits balanced, tied back to that exact order.
That's the actual distinction between "integrated" and "connected." Connected tools pass messages to each other and hope the messages arrive, in order, without duplication. One system doesn't pass a message — there's nothing to pass, because the order, the stock movement, and the ledger entry are facets of the same write. This is also why reconciliation stops being a recurring task rather than becoming an occasional one: there's no second copy of the number to reconcile against. The finance layer isn't downstream of operations catching up later — it's generated by the same event operations already recorded.
Signs you've hit the ceiling
Spreadsheets don't announce their failure with an error message. They fail quietly, and the signs tend to show up in operations and finance separately before anyone connects them. A few honest signals that the ceiling has been reached:
- Reconciliation has become a multi-day event. If closing the books, or even just agreeing on last week's revenue number, now reliably eats more than a day of someone's time each month, that's not a discipline problem — it's a structural one. The time spent reconciling is a direct measure of how many independent copies of the truth exist.
- Stockouts and dead stock happen at the same time. This is one of the clearest tells. If some SKUs are chronically out of stock while others pile up unsold in a different location, it usually means stock visibility is fragmented by location or channel — nobody has one number for a SKU, they have several, and none of them is being looked at together.
- Margin moves and nobody can say exactly why. When a product's profitability shifts and the honest answer is "we're not sure which cost changed," that's a sign cost data (freight, fees, COGS) isn't flowing into the same place revenue is recorded. The two halves of the margin equation live in different files.
- The same number has two different values depending on who you ask. Ops says one figure for last month's sales; finance says another. Both people are being careful. The spreadsheets simply disagree, because they were never the same source.
- A new hire needs a walkthrough just to find "the real one." If onboarding into the reporting process requires a tour of which spreadsheet is authoritative for what, the system has already fragmented past the point where any one person can hold the whole picture in their head.
None of these signs, on their own, is a crisis. Together, they describe a business that has outgrown the tool it's using to run itself — which is a normal, almost inevitable point to reach, not a failure of the team that got there.
What switching looks like in practice
The instinct many operators have is to assume replacing spreadsheets means a long, disruptive migration — months of parallel-running two systems, re-entering everything by hand, and hoping nothing falls through the cracks. That's a fair worry, because it used to be true of most ERP transitions. It doesn't have to be the shape of this one.
In practice, switching to one system starts with connecting the tools already in use — the storefront, the payment processor, the shipping carrier — rather than replacing them. The new system observes and absorbs what's already flowing through those connections: orders, payments, fulfillment events. Historical data comes in through an import rather than manual re-entry, so the switch isn't a blank slate — past orders, stock levels, and a chart of accounts carry over, and the books pick up from where the spreadsheets left off rather than starting over.
What changes isn't the day-to-day motion of taking an order or shipping a package — it's what happens behind that motion the moment it occurs. The reconciliation work that used to happen at month-end starts happening continuously and automatically instead, and the multi-spreadsheet ritual quietly stops being necessary, because there's only one place the numbers live now.
The practical first questions worth asking are: which channels need to connect, how much order history is worth importing, and what the current chart of accounts looks like. Those three answers shape almost everything else about the switch — and they're worth working through concretely, with real numbers, before committing to a plan.