The $66B ERP industry and why CFOs still reach for Excel

CFOs still reach for Excel after a multi-million ERP programme because the ERP was configured to capture data, not to support the decisions finance and operations people make. Excel gives them control, flexibility and speed for exactly those decisions. The fix is not training people out of spreadsheets. It is finding the spreadsheets that matter, understanding the decision each one supports, and designing ERP reports and analytics to do that job better. This piece is for CFOs, finance systems leads and programme sponsors. It covers why Excel persists, what it costs, what SAP's tools and AI change, and a worksheet for replacing your most important spreadsheets.

The logistics supervisor at one of my manufacturing clients told me his team exported its ERP data to Excel every week for inventory planning. The company had paid a fortune for its planning modules, and they had the best dashboards in its reporting. The team still used the spreadsheet. He is not unusual. I have worked with several Fortune 500 companies that openly admit they use Excel for critical work: financial audits, executive reports, even payroll calculations.

That is the actual ERP failure story. Not the go-live. Not the configuration. The gap between what the system produces and what the decision-maker needs.

Gartner puts worldwide ERP software revenue at $66 billion in 2024. Business cases routinely justify part of that spend by eliminating manual spreadsheet work. Yet in a May 2026 survey of 303 UK CFOs by Odoxa, 67% still used Excel for account analysis and reconciliation, exactly as many as used their ERP. Not because they failed to implement. Because the system, as implemented, did not replace what the spreadsheet was doing.

Excel has four properties most ERP implementations fail to replicate.

Familiarity. Most finance and operations professionals have used Excel for twenty years. When a manager needs an answer before tomorrow's board meeting, they open the tool they know will produce one.

Flexibility. Excel lets people build the analysis they need rather than the one the system provides. A CFO can model three cash scenarios in an afternoon. In an ERP, the same analysis may need a configuration request, a build and a test cycle.

Speed. Changing a formula takes seconds. Changing an ERP report needs someone who knows how, approval and testing.

Control. People trust what they can see and change. To most users an ERP is a black box. In Excel they can trace every number to its source.

These are rational responses to systems that were not designed for the decisions people need to make.

Traditional ERP screens were built for data completeness and process integrity. The goods receipt transaction captures every required field. The report that shows what that inventory position means for next month's production plan needs a separate tool, separate configuration and often a separate specialist.

SAP Fiori was a real step forward: role-based launchpads, simpler screens, mobile access. In many implementations, the configuration has not kept pace with the intent. Users have Fiori access, but the analytical tiles were never configured around the decisions they need to make. They run the transactions, then export to Excel, and Fiori becomes a pass-through to the same problem.

Embedded analytics in S/4HANA and SAP Analytics Cloud go further by bringing the analysis into the same environment as the transaction. SAP Business Data Cloud is SAP's current home for the wider data layer. Where companies have configured these properly, Excel dependency is genuinely lower. In most, the analytical investment trails the transactional investment by a long way. Cloud contracts make some analytics easier to license. They do not remove the design work.

The generative AI tools now around SAP help with some of the reasons people export:

1. Joule in SAP applications answers natural-language questions about SAP data and opens the right app. It is useful for the ad hoc question that used to trigger an export. It is not a substitute for scheduled operational reporting.
2. Microsoft 365 Copilot drafts narrative around numbers. The board commentary that a CFO used to write by hand can start as a draft against ERP-sourced figures, which shortens the end of the close.
3. Copilot in Power BI generates measures, visuals and summaries from plain language. Where Power BI already sits on SAP data, it speeds up the build. Where it does not, it does not change the architecture decision.

The pattern across all three: AI speeds up the work once reporting is designed around the decision. It does not decide what to build. That still needs people who understand what the business does.

The costs accumulate quietly.

Version conflicts. When five people update their own copies and reconcile weekly, someone is always working from the wrong version. A close run on a shared workbook is one simultaneous edit away from a reconciliation exercise that delays the board pack.

Audit gaps. ERP systems keep an audit trail by design. Spreadsheets do not. When an auditor asks why a number changed between drafts, the spreadsheet usually cannot answer.

Diverging data. When the ERP and the spreadsheet hold different versions of the same data, decisions split. Operations trusts the spreadsheet, finance trusts the ERP, and the monthly reconciliation eats time and trust.

Compounding manual errors. A copy-paste that misses a row, a formula that does not extend to new data, a filter left on. The more manual steps, the higher the error rate over time.

My guide to SAP FICO covers how the finance close is meant to run inside S/4HANA.

Yes, if the implementation deals with the reasons people reached for Excel.

The finance close that runs on pivot tables is not a training problem. It is a reporting design problem: the close needs outputs the ERP does not produce in a usable form. Configure the ERP to produce them rather than telling people to stop using Excel.

The inventory planner who exports to Excel is not resisting the system. The planning reports do not show him what he needs for his decision. Design them around the decision, not the data model. For planning that genuinely needs scenarios and simulation, SAP IBP is built for it, but only if planners trust its outputs.

In every post-go-live review where spreadsheet dependency is high, the pattern is the same. IT and the SAP consultant designed the reports around what the system could produce, not what the business needed to see. It is the same mistake as buying the system before mapping the processes, just later in the programme.

Start with the processes where accuracy and audit trail matter most: the financial close, inventory reconciliation, procurement analysis and management reporting. For each important spreadsheet, fill in a row.

1. 01Pick the spreadsheetClose, inventory, procurement and reporting first
2. 02Name the decisionFor example, the board pack cash forecast
3. 03Why the ERP falls shortMissing report, wrong layout, judgement, speed
4. 04Design the replacementERP report, Fiori app, SAP Analytics Cloud or Power BI
5. 05Owner tests itBefore go-live, against the same decision
6. 06Retire the spreadsheetOn a set date

The decision runs on the system of record

Field	What to record
Spreadsheet	Name and location of the workbook
Owner	The person who maintains it
Decision it supports	The specific decision or output, for example the monthly cash forecast for the board pack
Data sources	Which ERP reports or exports feed it, and any manual inputs
Why the ERP does not do it today	Missing report, wrong layout, judgement step, speed
Replacement	Configured ERP report, Fiori analytical app, SAP Analytics Cloud story or Power BI on governed data
Acceptance test	The owner confirms the replacement supports the same decision before go-live
Retirement date	When the spreadsheet stops being used

Sometimes the ERP genuinely cannot produce what the business needs at the speed it needs it. Then use a governed analytics layer such as SAP Analytics Cloud or Power BI on top of ERP data, not a manual export and rebuild. The data stays in the system of record. The visualisation meets the decision.

What does not work is training people to use reports that were not designed for their decisions. They go back to Excel. Not because they resist change. Because the report does not do the job.

Why do CFOs still use Excel despite having ERP systems?

Because Excel is familiar, flexible, fast and transparent, and because the ERP reports were usually configured around what the system could produce rather than the decisions finance needs to make. A controller who builds the monthly close model in Excel usually does so because the ERP close reports do not produce the format the management pack requires. Replace that output and the spreadsheet loses its reason to exist.

What are the risks of running business processes in spreadsheets?

Version conflicts when several people maintain copies of the same model. Audit gaps, because spreadsheets do not keep a reliable change history. Data that drifts away from the ERP, so operations and finance work from different numbers. And manual errors that accumulate with every copy, paste and formula, usually surfacing at audit or in a management report rather than when they happen.

How can ERP systems reduce Excel dependency?

By being configured around the decisions people make. Before go-live, list the most important spreadsheets for each key role and the decision each supports. Design the ERP report, Fiori app or analytics story to replace that specific spreadsheet, and have the owner test it before go-live. For the close, produce the management pack format directly instead of requiring an export and reformat.

Does AI such as Joule or Copilot end the need for Excel?

Not on its own. Joule answers ad hoc questions about SAP data, which removes some exports. Copilot drafts narrative and Power BI content faster. None of them decides which reports the business needs or redesigns a report built around the data model. AI speeds up good reporting design; it does not replace it.

Why do inventory and supply chain teams still use Excel after ERP go-live?

Two reasons. The planning reports were not configured for the planner's decision, for example a rolling twelve-week coverage view with exception flags. And planners trust ERP data but apply their own judgement on lead times, supplier reliability and customer priority, which the ERP gives them nowhere to record. Configure decision-focused reports first; for complex scenario planning, SAP IBP provides a place for that judgement.

What is the real cost of an ERP that does not replace spreadsheets?

Over five years it is often larger than the implementation overrun. It includes reconciliation time across finance and operations and audit remediation when spreadsheet errors surface. Add paying for the ERP while people maintain manual equivalents, slower decisions, and senior talent spent on data assembly. An ERP that is live but has not replaced the manual processes has been purchased, not delivered.