Why everyone still exports to Excel
You implemented an ERP with reporting built in, and the finance team still exports to a spreadsheet every month. That is not resistance to change. It is feedback.
Six months after go-live, someone notices that the weekly routine still involves exporting to Excel and rebuilding the same report by hand.
The usual interpretation is that people are being stubborn, or need more training. It is worth considering the alternative, which is that the spreadsheet is doing something the system genuinely is not.
What the spreadsheet is actually providing
Watch the export closely and it is almost always one of five things.
A calculation the system does not hold. Margin worked out a particular way, allocations, a commission rule, a seasonal adjustment. The logic lives in a formula because nobody ever put it in the system, often because nobody could agree on it formally enough to configure it.
A join across two systems. ERP data alongside something from payroll, freight, or a customer portal. The spreadsheet is functioning as an integration, maintained by a person.
A layout somebody outside the business requires. A bank, an auditor, a head office, a customer who wants their data in their template. That is a formatting requirement, not a reporting one, and it is legitimate.
The ability to annotate. A column of notes explaining the exceptions. Systems are frequently poor at this and it is often the most valuable column.
Speed. The person can get an answer in ninety seconds in a tool they know completely, versus five minutes fighting a report builder they use monthly.
Each of those has a different fix, and only two of them are reporting problems.
The one that matters most
The first. A calculation held in a spreadsheet is a business rule that exists nowhere official.
It cannot be audited. It cannot be checked by anyone but its author. When that person is away the number does not get produced, and when they leave nobody can reconstruct why it was calculated that way. We have seen businesses where the definitive margin figure depended on a workbook on one laptop.
If the export is providing a calculation, the right response is not to make the spreadsheet easier. It is to get the rule agreed, written down, and configured, which is usually a conversation about definitions rather than a technical task. The conversation is where the difficulty is: two people in the room often turn out to have been calculating it differently for years.
What to do about the rest
A join across systems is an integration request, and it should be treated as one with the maintenance cost stated, rather than left as a monthly manual task nobody counts.
An external template is fine. Export to Excel, format, send. Not every use of a spreadsheet is a failure and pretending otherwise wastes effort on the ones that are.
Annotation is worth solving inside the system where it can be, because notes in a spreadsheet are lost every time the report is regenerated.
Speed is a training and design question. Often the answer is that nobody built the five reports people actually need, so they build them themselves every week. Five saved reports, set up once with the people who use them, removes most of it.
The measurement worth taking
Ask, without judgement, what gets exported and what happens to it after. Not what reports people want; what they currently do.
You will get a short list, and it is the most accurate specification of your reporting requirement that exists, because it describes what people need badly enough to do manually every week.
Where this lands
An ERP that everyone exports out of is not a failed implementation. It is an implementation that stopped one step short, usually because the last step was a set of definition arguments rather than configuration and nobody wanted to have them.
Have them. They are cheaper than the workbook on the laptop.