Most companies do not intentionally decide to build operational systems in Excel.
It just happens.
A workflow inside the ERP becomes too slow. Reporting cannot answer the questions the business is asking. Product data needs cleanup before it can be used downstream. Customer pricing gets too complex. Someone exports data into a spreadsheet to bridge the gap “temporarily.”
Then the temporary process becomes permanent.
Over time, entire operational workflows start living outside the ERP. Teams rely on spreadsheets, CSV exports, email approvals, and manually maintained files to keep the business moving. Eventually, there is a point where the ERP is technically the system of record, but operationally, the real system is Excel.
If you work in manufacturing, distribution, or complex B2B commerce, you have probably seen this firsthand.
This usually is not caused by bad teams or bad operational discipline. It happens because most ERP systems were designed to manage transactions and standardize process, not adapt quickly to operational complexity.
As organizations grow, the business almost always evolves faster than the ERP workflow does.
Product catalogs expand. Customer expectations change. Pricing models become more nuanced. Ecommerce introduces new operational pressure. Teams need more visibility, faster reporting, and more flexibility than the original implementation anticipated.
The ERP can still technically support the process, but modifying it becomes expensive, politically difficult, or operationally risky. So teams solve the problem somewhere else.
Excel becomes the path of least resistance because it is flexible, fast, and available immediately.
Honestly, some of these spreadsheets are incredibly sophisticated. We have seen organizations running quoting workflows, pricing management, product normalization, operational reporting, and even light orchestration logic entirely through spreadsheets and exports.
From the business perspective, those spreadsheets are not the problem. They are the thing keeping operations functional.
Organizations sometimes frame shadow operational systems as governance failures. In reality, they are usually symptoms of operational gaps that existing systems are no longer handling well.
The spreadsheet itself is often solving a very real business problem.
What is actually happening is that operational complexity has outgrown the workflows the ERP was originally designed to support.
That distinction matters.
Because when leadership looks at the spreadsheet and says “we need to eliminate Excel,” they often miss the bigger issue entirely. The business created those workflows for a reason. Removing the spreadsheet without addressing the operational need just pushes the problem somewhere else.
In a lot of B2B organizations, especially ones with complex products, pricing, or fulfillment requirements, operational nuance matters more than rigid process standardization. That is where shadow systems start emerging.
And once they exist long enough, they become deeply embedded into how the organization actually operates.
The real risk is not that spreadsheets exist. The real risk is when operational logic becomes fragmented, undocumented, and dependent on individuals.
That is usually when things start getting expensive.
You end up with situations where one employee understands how a critical pricing workbook functions. Reporting logic differs between departments because everyone built their own operational view of the data. Teams spend more time moving information between systems than actually acting on it.
Eventually the organization loses visibility into how work is actually getting done.
This becomes even more obvious when companies start talking about AI initiatives or workflow automation. Leadership assumes the ERP contains the operational model of the business, but in practice the real operational logic is scattered across spreadsheets, exports, emails, and undocumented exception handling.
The ERP contains the transaction history. The business logic often lives somewhere else.
That realization catches a lot of organizations off guard.
This is one of the reasons we are seeing more organizations build operational layers around their ERP ecosystems instead of trying to force every workflow directly into the ERP itself.
The ERP still matters. It remains the system of record.
But surrounding operational systems increasingly handle the workflows that require more adaptability. Product enrichment, search optimization, analytics, orchestration, pricing intelligence, operational monitoring, AI enablement, and cross-platform coordination are all areas where businesses are looking for more flexibility without destabilizing the ERP.
This is not an anti-ERP mindset. It is just a recognition that transactional systems and operational agility are solving different problems.
The organizations handling this best are usually not the ones trying to eliminate every spreadsheet. They are the ones identifying where operational complexity is emerging and intentionally building systems around those realities instead of pretending they do not exist.
The better question usually is not “why are people using spreadsheets?”
The better question is “what operational need caused the spreadsheet to appear in the first place?”
That is where the real insight is.
Because once organizations start asking that question, they usually uncover the same patterns over and over again: quoting complexity, product data gaps, customer-specific pricing, disconnected reporting, manual coordination between systems, and workflows that require more adaptability than the ERP can realistically provide on its own.
Most businesses already know where these operational gaps exist. They feel them every day.
The spreadsheet is just the visible symptom that the operational model of the business has evolved faster than the systems supporting it.