ERP go-live worked, but the reports didn't: what to fix first
Quick answer
If ERP go-live worked but the reports did not, the usual problem is not the ERP software. It is missing report ownership, changed data structures, unvalidated KPI definitions, broken legacy extracts and no day-one reporting continuity plan.
The ERP can be live, orders can be moving, stock can be transacting, invoices can be raised, and the project can still feel like it has failed. That happens when the business loses the reports it used to rely on.
For manufacturers, this is common after an ERP cutover. The system works technically, but production planners cannot see the same shortage view. Finance cannot reconcile the management pack. Operations does not trust the OTIF numbers. The board asks for proof the project has improved the business and the reporting team starts rebuilding years of hidden spreadsheet logic under pressure.
This is not a Power BI problem first. It is a data management and migration-readiness problem that has arrived late.
Why reports break after ERP go-live
Legacy reports usually depend on more than the old ERP database. They depend on field names, manual extracts, spreadsheet lookup tables, local definitions, user habits and exceptions that nobody wrote down because they were "just how we do month-end".
When the ERP changes, all of that changes too. A report can break because a field has moved, but it can also break because the meaning of the field changed. Customer type might become a controlled category. Product groups might be rationalised. Cost centres might be split. Historic part codes might be merged. Open orders might carry different statuses.
The new system may be cleaner than the old one, but the reporting layer has lost its map.
A successful data load does not guarantee useful reporting. It only proves the target system accepted the records.
The first fix is a report catalogue
Before rebuilding anything, list the reports the business actually uses. Not every report deserves to survive go-live. Some old reports exist because the legacy ERP could not answer a question properly. Others are duplicate versions of the same KPI.
For each report, capture:
- Who uses it and what decision it supports.
- Whether it is needed daily, weekly, monthly or only at year-end.
- Which source tables, exports or spreadsheets feed it.
- Which definitions matter: OTIF, margin, WIP, available stock, backlog, open order status.
- What it should reconcile to: finance, stock ledger, order book, production schedule or customer SLA records.
- Who signs it off as correct.
This gives you a controlled reporting backlog instead of a queue of complaints.
Then rebuild around business definitions, not old layouts
It is tempting to recreate every old spreadsheet exactly. Sometimes that is right for day-one continuity, especially for finance packs. But long term, copying the old report can preserve the same ambiguity that caused problems before the migration.
The better sequence is:
- Preserve critical day-one reports so the business can operate.
- Validate the numbers against finance, stock and operational owners.
- Document the definitions and known gaps.
- Then redesign reports around the new ERP model.
This matters because the new ERP should create better reporting, not just newer exports.
Where manufacturers usually feel the pain
Manufacturing reporting tends to fail in a few predictable places after cutover:
- Stock visibility: teams cannot trust available, allocated, quarantined or excess stock views.
- Open orders: statuses and dates do not match the old order book logic.
- WIP and costing: finance and operations disagree about what has been consumed, completed or valued.
- OTIF and SLA reporting: the new system records events differently, so old KPI logic no longer works.
- Margin reporting: product groups, cost methods or customer categories have changed.
- Board packs: manual adjustments have disappeared, or worse, nobody knows where to apply them now.
None of these are solved by making the dashboard prettier. They are solved by reconciling source data, agreeing definitions and creating ownership.
What to do in the first two weeks after go-live
If you are already live and reporting is unstable, do not start with a big reporting transformation. Start with operational triage.
- Separate reports needed to run the business from reports that are merely nice to have.
- Pick five to ten critical reports: finance pack, stock view, open orders, production plan, purchasing, despatch, OTIF.
- For each one, name a business owner and a data owner.
- Reconcile totals back to the new ERP and, where useful, to the final legacy report.
- Document the differences caused by changed definitions.
- Build exception lists before dashboards. Exceptions tell teams what needs action.
This creates control quickly. Once the critical reports are stable, the dashboard rebuild becomes much easier.
What should have happened before cutover
The honest answer is that reporting should have been treated as its own workstream. In a good ERP migration, the team catalogues business-critical reports before cutover, maps them to the new data model, rehearses the data loads, and validates outputs against known numbers before Monday morning.
That is how we approached the Infor LN cloud consolidation case study: the migration work was not finished when the data loaded. It was finished when stock, logistics and SLA reporting could support the business from day one of each go-live.
When to bring in help
Bring in outside support when internal teams are arguing about whether the numbers are right, but nobody has time to trace the issue from report to field to source system to owner.
A practical reporting rescue should produce:
- A report catalogue and priority list.
- A source-to-report mapping for critical outputs.
- A reconciliation pack for finance and operations.
- A data-quality backlog ranked by operational risk.
- Agreed KPI definitions and owners.
- A Power BI or Excel rebuild plan based on trusted source data.
The goal is not to create another reporting project. It is to restore trust in the numbers the business uses to run production, purchasing, stock, finance and customer delivery.
The takeaway
If your ERP went live but the reports did not, do not assume the system has failed. The more likely issue is that reporting continuity, data definitions and ownership were not treated as part of cutover.
Fix the critical reports first. Reconcile them. Assign owners. Document definitions. Then rebuild the reporting layer around the new ERP model.
That is how the ERP investment starts paying back after go-live.
ERP live, but reporting is not trusted?
Digital Adaption helps manufacturers stabilise post go-live reporting, reconcile critical outputs and rebuild Power BI or Excel reporting on trusted ERP data.
Book a reporting rescue call