How to Fix Reporting Without Replacing Your ERP

You don’t have to replace your ERP to fix reporting. Build a governed data layer beside the ERP instead of inside it: pull the data that matters most into one defined model, replace the most painful manual reports first, and sequence the rest into a phased plan. The ERP stays the system of record and keeps running routes and billing untouched. A year later the monthly reporting is automated and leadership works from one set of numbers — and if you still want to replace the ERP, you’re making that call with far better information than you had.

Do you have to replace your ERP to fix reporting?

No. Reporting problems and ERP problems feel like one problem, and treating them as one is what keeps operators stuck for years. The ERP decision is expensive, political, and slow. Reporting is neither — it can be fixed beside the ERP, on its own timeline, without touching billing or routing.

The confusion is understandable. The numbers you can’t get come out of the ERP, so the ERP looks like the thing standing in the way. But the ERP is doing exactly what it was built to do — run routes, bill customers, track transactions. It was never built to model margin by route or produce an “as of” AR view. A newer ERP would be better at the first job. It wouldn’t be much better at the second one.

Which means the replacement you’re waiting on probably wouldn’t have solved the reporting anyway. That’s the part worth sitting with before you spend another year waiting.

Why does the ERP replacement decision stall for years?

Because it’s a large, irreversible decision with no forcing function. A waste company I worked with had an ERP older than half their leadership team. Everyone agreed it needed to go. No one agreed on when, or on what would replace it. Meanwhile reporting ran on Crystal Reports, Excel, and one very patient analyst.

Nothing about that is unusual, and nobody involved was being unreasonable. The decision stalls for the same handful of reasons almost every time:

• Billing is the business. Whatever else breaks in a migration, invoices have to go out. That risk alone justifies moving slowly.
• The timing is never clean. An acquisition is closing, a yard is opening, a disposal contract is up. There’s no quiet quarter to do it in.
• There’s no consensus on the replacement. Operations wants one thing, finance wants another, and the demo that impressed one group didn’t impress the other.
• Nothing is technically on fire. The old system still bills. Painful isn’t the same as broken, and painful rarely wins a capital fight.

So the decision sits. And while it sits, reporting quietly gets worse — not because the ERP is degrading, but because the business is growing around it. More locations, more service lines, more people who need numbers, all still routed through the same manual assembly line.

What is a “data layer beside the ERP”?

It’s a separate, governed copy of the data you need for reporting — read out of the ERP and your other systems on a schedule, defined once, and modeled for analysis instead of for transactions. It reads from the ERP. It writes nothing back. The ERP stays the system of record and doesn’t know or care that it exists.

Beside is the word doing the work. Building inside the ERP means custom reports, version lock, and a vendor conversation every time you want a new field. Building beside it means the reporting stack has its own life — you can change it on a Tuesday without a change-control meeting, and it keeps running through an ERP upgrade.

The practical effect is that reporting stops being hostage to a decision nobody is ready to make. You’re no longer choosing between “live with the spreadsheets” and “bet the year on a migration.” There’s a third option, and it’s the cheap one.

What does building it actually involve?

Four moves, in order. None of them touch the ERP’s configuration, and none of them require a decision about its future.

• Stand up the layer beside the ERP. A governed place for reporting data to land, reading from the ERP on a schedule. This is the smallest part of the work and the part people expect to be hardest.
• Pull the data that matters most into a governed model. Not everything — the subset your reporting actually uses, with the terms defined once. What counts as revenue on a route, which hours belong to which yard, when a receivable ages. Those definitions are the real asset; everything built later inherits them.
• Replace the most painful manual reports first. Start where the human cost is highest, not where the build is easiest. The first automated report is what buys you the credibility to keep going.
• Sequence the rest into a phased plan. Each phase useful on its own, so if budget stops at month six you’re still ahead. We lay out a typical version of that sequence in the 12-month analytics roadmap.

The order matters more than the tooling. Operators who start with the tool selection end up with a platform and no definitions. Operators who start with the definitions end up with reports people trust, and the tool question answers itself.

Which reports should you replace first?

The ones that cost the most human time and cause the most disagreement. Those two things usually travel together, and the overlap is where the first win lives. A simple test: if a report takes more than a day to assemble and someone still questions the numbers when it lands, it goes first.

• The monthly operations package. Usually the single biggest consumer of someone’s week, and the one most likely to be rebuilt from scratch every cycle.
• AR aging and DSO. The data is in the ERP but isn’t structured for historical “as of” views, so it gets rebuilt outside the system — and the finance team loses the front half of the month doing it.
• Route or location P&L. The number the ERP can’t produce alone, because the cost inputs live in systems it doesn’t own. High effort by hand, high value automated.
• The board or ownership deck. Lower frequency, but the highest-stakes place for two versions of the same KPI to show up.

What you’re buying with the first replacement isn’t just the hours. It’s the first time in a while that a number came out of a system instead of out of a person — and everyone in the room can tell the difference.

What actually changes in a year?

In the case above, a year later the ERP was still there. But monthly reporting was automated, leadership was working from one set of numbers, and the conversation about replacing the ERP had become a much more informed one. That last part surprised people the most.

Three things tend to shift, and none of them required the migration:

• Time comes back. The analyst who was assembling reports is doing analysis. That’s not a headcount story — it’s the same person, pointed at work that needs judgment.
• The arguing stops. When ops and finance pull from the same governed layer, meetings start at the decision instead of at whose number is right. If your KPIs currently disagree across decks, that’s one of the signs the foundation hasn’t kept up.
• Reporting stops depending on one person. When the logic lives in the architecture instead of in someone’s head, a vacation stops being a reporting risk — the unicorn problem resolving itself as a side effect.

Does this make replacing the ERP harder later?

It makes it easier, and considerably better informed. The layer isn’t throwaway work you’d redo after a migration — it’s the part that survives one.

When the ERP does change, you re-point the layer at the new source. The definitions, the models, and the reports built on top of them stay. Compare that to a migration where reporting lives in the old system’s custom reports: those don’t come with you, and rebuilding them is often the longest tail of the whole project.

The bigger gain is at the decision itself. After a year on a governed layer you know which data you actually use, which fields are genuinely required, and where the current system falls short in specifics rather than in complaints. That turns a requirements document written from memory into one written from evidence — and it gives the migration a way to check itself, because you have a trustworthy set of numbers from before the cutover to compare against after.

Where does this start?

With a roadmap that doesn’t assume the ERP has to go first. That’s the whole shift — sequencing the reporting work so it delivers on its own, and letting the ERP decision happen on whatever timeline it needs, with better information behind it.

If you’re earlier than that and still weighing which tool to buy, start with why fixing ERP reporting begins with a roadmap, not a tool. If you want to see where your company sits today, our executive and operations maturity assessments take about a minute and come back with the three moves that come next.

You don’t have to fix the ERP to fix the reporting. You just need a plan that stops pretending the ERP has to go first.