The ERP Paradox: Why Manufacturers Still Use Spreadsheets After ERP Implementation

By Andy Caccavaro

It’s a strange thing to see up close: a manufacturer signs a seven-figure contract for an ERP system, spends a year or more implementing it, trains the whole floor on it, and eighteen months later, the real operating rhythm of the business is still a shared spreadsheet that the planning team quietly maintains because “the system doesn’t handle it.” For many manufacturers, spreadsheets after ERP implementation aren’t just temporary workarounds, they have become critical tools for planning, production, costing, and fulfillment.

This isn’t a rare failure story. It’s closer to the default outcome. Walk the back office of almost any small or mid-sized manufacturer and you’ll find the same layered reality: an ERP system holding the official numbers, and a shadow network of spreadsheets holding the numbers people actually trust for production, quoting, and fulfillment. When something breaks—a late order, a costing error, a scheduling conflict—the fix usually isn’t found in the system of record. It’s found in someone’s spreadsheet.

Why do manufacturers still use spreadsheets after ERP implementation? In many cases, spreadsheets survive because the ERP system does not fully represent the way production, planning, costing, quality, fulfillment, or customer-specific workflows actually operate. Teams use Excel to bridge those gaps because spreadsheets can be changed immediately, while ERP modifications may require configuration, IT support, consultants, or lengthy change requests.

This isn’t another ERP-versus-spreadsheets comparison. The more important question for many manufacturers is why spreadsheets return—or never disappear—after the organization has already invested in ERP.

Why Manufacturers Use Spreadsheets Alongside ERP: 5 Common Causes

• Generalized design. ERP platforms are built to serve thousands of customers with one configurable core, not one business with its own logic.
• Rigid workflow assumptions. The system encodes a “typical” version of quoting, production, or fulfillment, and typical rarely matches reality.
• The workaround becomes permanent. Spreadsheets start as a stopgap during rollout and quietly become the real system of record.
• Customization creates its own trap. Heavy configuration to force-fit the software often produces a fragile, consultant-dependent system that’s harder to change than the original problem.
• The failure gets mislabeled. Leadership blames the vendor, the integrator, or “adoption,” when the root cause is a mismatch between how the software is built and how the business actually runs.

Why Do Manufacturers Still Use Spreadsheets After ERP Implementation?

When an ERP rollout doesn’t stick, the post-mortem almost always lands on one of three explanations: the implementation was botched, the consultants oversold it, or it’s a change management problem.

Each has some truth: rollouts do fail across good integrators and bad ones alike; consultants usually configure the system as intended, they don’t control what the data model can represent; and operators genuinely do revert to Excel when training and adoption push fall short.

But all three explanations treat the software as fixed and the business, or its people, as the variable that failed to adapt, a framing that’s backwards for a large share of these failures.

Operators aren’t reverting to spreadsheets out of resistance to change. They’re reverting because the spreadsheet can represent their actual workflow in five minutes, while the ERP system can’t represent it at all without a change request, a consulting engagement, or a six-month wait for the next release.

Why ERP Spreadsheet Workarounds Develop in Manufacturing

Modern business software—ERP, CRM, MES, planning tools—is built by product teams solving for scale: a platform serving 5,000 manufacturers can’t ship 5,000 different data models, so vendors converge on a generalized template, a standard bill-of-materials structure, a standard order-to-cash flow, a standard costing method.

That template is the product, and by design it’s an average. Averages don’t describe any single real business particularly well.

That convergence wasn’t just a business choice, it was a technical one. Most core ERP architectures were designed twenty to thirty years ago, when a rigid relational schema was the only practical way to encode business logic at scale. There was no alternative to a human hand-coding every exception, because the software itself had no way to interpret one.

For a manufacturer with genuinely standard operations, that average is close enough. But most SMB manufacturers aren’t standard: their workflows are shaped by specific customers with non-standard terms, equipment quirks the software has never seen, regulatory requirements, and edge cases built up over years of solving real problems on the floor.

That accumulated specificity is often the actual competitive advantage, the thing that makes the business defensible, and exactly what a generalized system is least equipped to hold.

This is well documented, even if rarely named as a design problem. Panorama Consulting Group’s long-running ERP Report has found for years that the overwhelming majority of organizations modify their ERP systems in some way rather than run them “as delivered,” since the out-of-the-box workflow doesn’t match how they actually operate.

Panorama’s research also shows a substantial share of ERP projects exceed their original budget, with the leading causes tracing back to scope and customization needs identified only after go-live.

Customization is the industry’s standard answer to this mismatch, and also where the pain gets reintroduced: heavy configuration—custom fields, approval chains, reports bolted onto a system not built to flex that way—tends to produce something brittle, a system only the original consultant understands, that breaks during upgrades, and becomes its own maintenance burden.

The business spent millions trying to make rigid software behave like flexible software, often ending up with something worse than either.

How ERP Spreadsheet Workarounds Become Permanent

The pattern tends to unfold in a predictable sequence, whether the company is a contract manufacturer, a food producer, or a fabricator:

1. Go-live reveals the gaps. Some slice of the real workflow—a costing method, a multi-step approval, a customer-specific packaging rule—doesn’t fit cleanly into the new system.
2. Someone builds a bridge. A planner or controller sets up a spreadsheet to handle the piece the system can’t, intending it as temporary.
3. The bridge becomes infrastructure. Because the spreadsheet is faster to change than the ERP system, it absorbs more and more logic over time. Six months in, it’s not a workaround anymore. It’s where the real decisions get made.
4. The system of record stops being the source of truth. Reports pulled from the ERP system undercount or misstate what’s actually happening, because the operational reality has migrated to spreadsheets the system never sees.
5. Leadership diagnoses an adoption problem. More training gets scheduled. Usage gets mandated. The spreadsheets persist anyway, because they were never the symptom. They were the fix.

A composite version of this plays out constantly: a fabricator lands a new automotive customer requiring lot-level traceability the ERP system has no field for. Within days, the quality team has a spreadsheet tracking lot numbers by hand. Eighteen months later, it’s the only place anyone can answer “which lot went into which shipment,” and the ERP system’s paper trail stops at the point the workaround began.

None of this shows up as a single dramatic failure. It’s a slow erosion of trust in the system of record, one exception at a time, until the exceptions are the majority of the workflow.

Traditional ERP Systems vs. Evolving Manufacturing Operations

When Is Spreadsheet Use Alongside ERP Actually a Problem?

Spreadsheets aren’t automatically a sign that an ERP implementation has failed. They become a larger operational problem when they stop functioning as occasional productivity tools and begin acting as unofficial systems of record.

These shadow spreadsheets are unofficial files employees rely on to perform or manage business processes that aren’t fully represented in the organization’s formal systems.

In manufacturing, the risk grows when critical production, quality, scheduling, costing, traceability, or fulfillment decisions depend on spreadsheets that are disconnected from ERP. Version confusion, missing audit trails, manual reconciliation, and competing sources of truth can then become part of everyday operations.

What Does Spreadsheet Dependency Cost Manufacturers?

The direct costs are the ones leadership teams already track: license, implementation, consulting hours. The costs that rarely make it into a business case are the ones the workaround itself creates.

Shadow spreadsheets are, by nature, disconnected from the system of record: version confusion, no audit trail, no shared source of truth across shifts.

Coverage from diginomica, which tracks enterprise software adoption, has documented how persistently this “shadow IT” layer survives even well-funded transformation efforts, because the last mile of real operational work rarely fits the systems built to replace it.

Excel itself remains deeply entrenched in business operations, with estimates putting the number of business users worldwide at over 150 million, according to data compiled by Statista, reflecting less Excel’s merits than how few alternatives give operators that same freedom to adapt.

For a manufacturer, the compounding costs look like:

• Decisions made on stale or conflicting data, because the spreadsheet and the ERP system disagree and nobody’s sure which one is current.
• Audit and traceability gaps, particularly costly for manufacturers under ISO, FDA, or customer-mandated quality systems, where “who changed this and when” needs a real answer.
• Duplicate work, as staff re-enter or reconcile the same data across systems that were supposed to be unified.
• A second implementation, eventually. Many SMB manufacturers don’t run one ERP project in their history; they run two or three, each an attempt to finally close the gap the last one left open.

That’s the most expensive version of the problem: a recurring cycle of rip-and-replace, paying full implementation costs each time for a system built on the same generalized template as the last one.

Why ERP Customization Doesn’t Always Eliminate Spreadsheet Workarounds

Customization is often the first answer when an ERP system doesn’t fit the way the business actually operates. In some cases, it solves the problem. In others, it introduces a new layer of complexity.

Custom fields, approval chains, reports, integrations, and other modifications can help close gaps between standardized ERP workflows and actual manufacturing processes. But heavy customization can also create consultant dependency, make upgrades more difficult, slow future changes, and increase the maintenance burden.

The result can be another version of the same underlying problem: manufacturers gain functionality, but lose the ability to adapt quickly as customers, equipment, processes, and operating requirements change.

What Should Manufacturers Look for in More Flexible Manufacturing Software?

The next wave of manufacturing software treats this differently: not as a training problem to fix with better change management, but as a design problem to fix with better architecture.

Instead of shipping a fixed workflow and asking the business to conform, newer platforms are built to absorb the business’s actual logic without a consulting engagement every time reality changes.

In practice, that shows up as a few concrete shifts worth watching for when evaluating any system, not just ERP:

• Configuration that lives with the operator, not the consultant. Can a planner adjust a costing rule or approval path the way they’d adjust a spreadsheet formula, or does every change route through IT and a ticket?
• Data models that don’t assume a “typical” business. Can the system represent a genuinely nonstandard bill of materials, a customer-specific pricing rule, or an unusual production sequence without a workaround?
• AI removes the translation bottleneck, not just the interface. The reason a truly custom system used to require an enterprise budget wasn’t the software itself, it was the labor: a consultant had to sit with operators, translate their actual workflow into rigid system logic, and hand-code every exception. AI is now positioned to absorb that translation directly, learning a business’s real patterns, including from the very spreadsheets built to work around the gaps, instead of requiring a human to formalize them first.
• Faster iteration loops. The gap between “this doesn’t fit our workflow” and “the system now handles it” should be measured in days, not the next major release cycle.

This isn’t a call to abandon ERP. It’s a recognition that the category has been forced past a founding assumption that no longer holds, and complex, fast-moving manufacturers have already proven it wrong, one spreadsheet at a time.

Can AI Reduce ERP Spreadsheet Workarounds?

AI’s larger potential in this problem isn’t simply adding another feature or interface to an existing ERP system. It’s reducing the translation work required to turn a manufacturer’s actual operating logic into software.

For most of ERP’s history, that translation required people: operators explaining processes, consultants interpreting those processes, and developers or system specialists configuring the software around them.

AI creates the possibility of shortening that loop by learning patterns from existing workflows, data, and even the spreadsheets employees have already built to compensate for system gaps.

The important distinction is architectural. Bolting AI onto a rigid data model still leaves the underlying model rigid. The larger shift comes when AI helps software adapt more directly to the business’s actual operating logic rather than forcing that logic through a predetermined structure.

How to Identify ERP Spreadsheet Workarounds in Your Manufacturing Operation

Before blaming the next implementation partner, it’s worth running a candid internal audit. Three questions tend to surface the real problem fast:

1. Map the shadow spreadsheets.

List every spreadsheet the team relies on outside the official system, and ask what workflow each is replacing, and why the system couldn’t handle it.

2. Separate “we didn’t configure it” from “it can’t be configured.”

Some gaps are fixable with better setup; others are structural limits of the platform’s data model. Conflating the two leads to another round of expensive customization aimed at a problem no configuration will solve.

3. Price the workaround, not just its symptoms.

Add up the hours spent reconciling spreadsheets against the system of record, errors traced to version conflicts, and audit gaps that surface at customer or certification review.

That number, not the license cost, is usually the real business case for change.

Our Take

What makes this moment different is that a truly tailored system is no longer something only enterprise budgets can afford.

For most of ERP’s history, software built specifically around one company’s workflow meant a custom build, a price tag out of reach for most manufacturers doing $5M to $100M in revenue, and years of maintenance to keep it running.

AI is starting to change that math, not by making ERP smarter in the abstract, but by taking over the translation work a consultant used to bill for.

That’s the real paradigm shift worth watching: not incrementally better ERP, but software built around a specific business instead of a business built around the software’s assumptions.

That’s bigger than a cost or speed improvement. Bolting an AI feature onto a rigid data model still leaves the model rigid.

The real shift is architectural: AI-native operations software is being built from the ground up to represent a business’s actual logic instead of forcing that logic through a fixed schema first, which changes what the software fundamentally is, not just how fast it gets configured.

The manufacturers who get ahead of this aren’t running the most disciplined change management program. They’re the ones who recognize this isn’t a smarter version of the old category. It’s a different one.

If your team is carrying a spreadsheet that quietly runs more of the business than your official system does, that’s not an adoption failure. It’s data, and it’s worth mapping before the next system change gets evaluated the same way the last one was.