There is a pattern I see repeatedly at companies between $5M and $20M: reporting is bad, someone concludes the systems are the problem, and the answer becomes a new ERP or a big upgrade. Two years and a lot of money later, the reports are still bad. Sometimes worse, because now they are official.
I want to explain why this keeps happening, because once you see the mechanism you stop making the mistake, and you stop paying for it.
Why ERP reporting disappoints
Reporting is a checkbox in the sale. The ERP gets selected on modules, compliance, and license cost. Reporting quality gets a demo of the standard reports, which look impressive in a conference room because they answer accounting questions. Your questions are not accounting questions. They are: what sold this week, which jobs are stalling, what is about to break. The standard pack does not answer those, and everyone quietly discovers this in month three.
Implementations gut the reporting to hit budget. The implementation is scoped to go-live: data migrated, processes configured, users trained. The reporting layer is the first thing cut when the project runs long, because it is the least visible at go-live. So you get the standard reports, unmodified, and the project is declared a success.
The ERP answers the questions it was designed for. An ERP is built to keep the books correct and the processes compliant. That is genuinely valuable and it is not the same job as telling the owner how the business is doing. Expecting the system of record to also be the system of answers is asking one tool to be two tools, and it has never worked at your size.
The pattern that works
Keep the ERP boring and authoritative. Its job is to be the single true source for transactions, inventory, and financials. Boring is a compliment here. The less custom logic you push into it, the cheaper your upgrades and the fewer surprises in five years.
Pull its data out on a schedule. A nightly sync into a reporting layer is enough for almost every decision a company this size makes. You are not trading latency for anything real; nobody needs intraday inventory to run a weekly purchasing meeting.
Build the five to ten reports the business actually runs on. The Monday-morning numbers, the weekly exceptions, the monthly pack. Built on the synced copy, in the shape the people who use them want, not the shape the ERP's data model finds convenient. When the ERP changes, your reports read from the sync, and the blast radius is one connector instead of every report you own.
This is not a small consolation prize. It is the actual architecture: system of record, system of answers, separate and both good at their jobs.
The honest exception
Sometimes the ERP genuinely is the problem. A wrong-fit ERP, licensed for a company three times your size, or one whose data model fights your industry, will make everything downstream miserable no matter how good your reporting layer is. How to tell: if the standard reports are not just incomplete but actively wrong, if users routinely bypass the ERP to do their real work in spreadsheets, or if the vendor's roadmap is moving away from your industry, the problem is the ERP itself. That is a different, harder conversation, and it deserves its own honest assessment rather than a reporting band-aid.
But if the ERP is doing its job and the reports still disappoint, buying another system is not a strategy. The fantasy is that the next purchase will make reporting good. Reporting becomes good when someone owns the question "what does this business need to know, and when" and builds the answers deliberately, beside the system, not inside it.
Jai Indiongco
FOUNDER & PRINCIPAL CONSULTANT