Why Excel appears beside almost every business system
Excel isn't a failure of discipline — it's a symptom of gaps in your business systems. Here's why it keeps appearing, and what it actually costs you.
Your ERP went live two years ago. Everyone was trained. The old spreadsheets were supposed to disappear. But open any shared drive today and you'll find dozens of them — production planning sheets, exception logs, inventory trackers, margin calculators — all running quietly alongside the system you paid to replace them. This article explains why that happens, what it costs, and what you can actually do about it.
Why does Excel keep coming back, even after you've implemented a proper system?
Business systems — whether that's an ERP like AFAS, SAP, or Exact, a CRM, a WMS, or a custom solution — are built around structured, repeatable processes. They handle the mainstream workflow well. But every real company has edges: exceptions, workarounds, one-off calculations, or reporting needs that the core system wasn't designed to cover.
Excel fills those gaps instantly. No IT ticket. No development sprint. No waiting for a vendor update. A warehouse manager who needs to track which production batches are on hold for quality review doesn't wait for the ERP team to build a module — she builds a sheet by Friday afternoon. That's not indiscipline. That's pragmatism.
The problem isn't that Excel exists. The problem is that it stays — and quietly becomes load-bearing infrastructure nobody is maintaining or governing.
What does Excel actually get used for next to a business system?
In manufacturing and wholesale businesses specifically, the most common Excel workloads running alongside ERP systems fall into a few recognizable categories:
Production planning and scheduling exceptions The ERP holds the master production plan. But when a machine goes down, a supplier delivers late, or a rush order comes in, the production planner opens a separate Excel sheet to manually reschedule jobs, recalculate capacity, and communicate changes to the shop floor. The ERP is too rigid or too slow to update in real time — so Excel becomes the live planning layer.
Inventory tracking for edge cases The ERP tracks stock movements in the official warehouse locations. But the 40 items set aside for a key customer? The returned goods in uncertain condition? The consignment stock that technically isn't yours yet? Those often end up in a spreadsheet because they don't fit cleanly into the ERP's stock model.
Reporting and margin analysis A sales manager exports order data from the ERP into Excel every Monday morning to build the weekly revenue report. She adds columns for margin per customer, compares it to the same period last year, and colours rows red if a customer's order frequency has dropped. None of that is available as a standard ERP report — so Excel becomes the BI layer.
Exception management and escalation tracking A purchasing team tracks supplier delivery reliability in a shared Excel file. A logistics coordinator maintains a manual backorder list. A customer service manager keeps a sheet of open complaints that the CRM doesn't capture well. In each case, Excel is handling the exception while the main system handles the rule.
What is this actually costing you?
This is where the real conversation starts — and where most companies dramatically underestimate the impact.
Duplicate data entry — every single day An order arrives and gets entered into the ERP. Then the logistics coordinator manually copies delivery details into a separate Excel tracker to monitor shipment status. Then, at end of day, someone transcribes exception notes from that tracker back into a customer update email. One order. Three manual touches. In a wholesale business processing 200 orders a day, this is not a minor inefficiency — it's several hours of paid labour spent on data movement that adds no value.
Version chaos and decision risk The production planning sheet gets emailed to five people on Monday. By Wednesday, there are five different versions. The operations director makes a capacity decision based on version 3. The plant manager is working from version 5. Nobody realizes this until a delivery commitment is missed. This isn't a hypothetical — it's a pattern that surfaces in post-mortems at manufacturing companies constantly.
No audit trail, no accountability When a stock discrepancy turns up at year-end, the ERP shows what the system recorded. But significant decisions were made in Excel files that have since been overwritten or deleted. There is no history, no record of who changed what, and no way to reconstruct the decision chain. For companies operating under ISO standards, food safety regulations, or financial audit requirements, this is a serious compliance exposure.
Key-person dependency and fragility The Excel model that calculates landed cost per SKU? Only one person fully understands it. When she goes on maternity leave, nobody is sure which cells to update, whether the formulas are still correct, or where the source data comes from. The business is operationally dependent on a spreadsheet that lives in one person's head.
The invisible maintenance burden Every Excel workaround needs to be updated when something changes: a new product category, a supplier price increase, a change in VAT rates. That maintenance happens informally — often by whoever notices the problem first — and it's never tracked, estimated, or budgeted. It's pure overhead that accumulates silently.
Is Excel always a problem, or is it sometimes the right tool?
This is an important distinction. Excel is genuinely excellent at certain things:
- One-off analysis that doesn't need to repeat
- Exploratory data work before you know what structure you need
- Small-team coordination where a shared sheet is genuinely faster than a system
- Prototyping a new process before you invest in building it properly
The moment Excel becomes a problem is when it transitions from tool to system — when it starts holding data that other people depend on, when it runs critical calculations nobody else understands, when it gets updated daily as part of an operational workflow, and when the business would visibly break if the file were deleted tomorrow.
A useful diagnostic question: if that Excel file disappeared tonight, would you notice by 9am tomorrow? If yes, it's no longer just a spreadsheet. It's infrastructure.
Why don't companies just fix this?
The honest answer is that fixing it requires admitting the system you implemented didn't fully cover your processes — and that's politically uncomfortable. It also requires investment: time to map the real workflow, budget to build or configure a proper solution, and change management to get people to actually use it.
Excel, by contrast, costs nothing visible. The labour is hidden in salary lines. The risk of version errors or data loss is abstract until something goes wrong. The key-person dependency only becomes a crisis when that person leaves. So the decision to fix it gets deferred quarter after quarter, while the spreadsheet ecosystem quietly grows.
There's also a real capability gap. Many ERP systems — particularly mid-market platforms common in manufacturing and wholesale — have rigid data models. Getting them to handle a genuinely non-standard process requires customization that the vendor may not support, or that costs more than the business wants to spend. So the workaround stays.
How do you actually start reducing your dependency on Excel workarounds?
You don't solve this by telling people to stop using Excel. You solve it by making the proper system good enough that Excel is no longer needed. That requires a structured approach:
Audit your current Excel landscape. Collect every spreadsheet that is used operationally — not for one-off analysis, but as part of a recurring workflow. For each one, document: who uses it, how often, what data it contains, whether it connects to other systems, and what would break if it disappeared.
Classify each spreadsheet by risk and volume. Prioritize the ones that (a) touch the most people, (b) hold data that isn't stored anywhere else, or (c) are involved in decisions with real financial or compliance consequences.
Trace the gap it fills. For each high-priority spreadsheet, ask: what is the underlying process this covers, and why isn't the existing system doing it? Is it a missing feature? A rigid data model? A reporting gap? A one-off exception that became permanent?
Design the right fix for each gap. Not every gap requires a full development project. Some can be closed by configuring a new report in the ERP. Some need a small custom module. Some need an API connection to pull data from a second system automatically. Some genuinely need a separate tool. The answer depends on the gap.
Build and migrate deliberately. When you replace a spreadsheet with a proper solution, run both in parallel for a transition period — long enough to catch edge cases, short enough that you don't end up maintaining two systems indefinitely.
Establish a governance norm. Define — explicitly — when a spreadsheet is acceptable and when a process needs to be built into a system. Without this, the Excel ecosystem grows back.
Checklist: Is your Excel use a workaround or a risk?
Use this to quickly assess whether a given spreadsheet has crossed from useful tool to operational liability:
- Is it updated more than once a week as part of a routine workflow?
- Does more than one person depend on it for daily decisions?
- Does it contain data that isn't stored anywhere else?
- Would it take more than 30 minutes to recreate if the file were lost?
- Does it feed into financial reporting, compliance records, or customer commitments?
- Is only one person fully able to maintain or explain it?
- Has it been in use for more than six months?
If you checked three or more boxes, that spreadsheet is infrastructure — and it should be treated as a process improvement project, not a personal productivity tool.
Frequently asked questions
Isn't Excel just a symptom of a bad ERP implementation? Sometimes, but not always. Even well-implemented ERP systems have genuine coverage gaps — especially around exception management, non-standard reporting, and processes that are specific to your business model. The question isn't whether your ERP is good or bad, but whether the gaps it leaves are being managed safely.
We've tried to migrate Excel workflows before and it always fails. Why? Usually because the replacement solution was designed around what the system could do, rather than what the process actually needed. People revert to Excel when the new solution is less flexible or more time-consuming than the spreadsheet it replaced. The fix has to be genuinely better — not just more official.
How do we get buy-in from people who built and rely on these spreadsheets? Involve them in the design of the replacement. The person who built the Excel workaround understands the edge cases better than anyone. If they help design the new solution, they're far more likely to trust it — and far less likely to keep the spreadsheet as a backup.
Do we need to replace every spreadsheet? No. The goal isn't to eliminate Excel — it's to eliminate the spreadsheets that are carrying operational risk. One-off analysis, personal productivity tools, and exploratory work are all legitimate uses. Focus your effort on the ones that are doing the work a system should be doing.
How long does it typically take to fix a major Excel workaround? For a focused gap — like replacing a manual inventory exception tracker or automating a weekly ERP export — a well-scoped custom development project typically takes four to ten weeks. Larger process integrations take longer, but the individual workarounds don't have to wait for a big-bang project. You can tackle them one by one.
If your business runs on a mix of ERP data and Excel files that have quietly become indispensable, the first step is usually mapping where the real process gaps are — not just the spreadsheets, but the underlying workflows they're compensating for. Loggix works with manufacturing and wholesale businesses to do exactly that: identifying where custom FileMaker solutions, ERP integrations, or API connectors can replace fragile spreadsheet workarounds with something reliable, auditable, and actually built around how your operation works. If you want to think through where to start, that's a conversation worth having.