Excel financial reporting still exists in organizations that have fully implemented ERP systems. After all the time and money spent getting a cloud ERP in place, all the days and weeks spent converting and reconciling historical data, the reporting still ends up in Excel.
From an outside perspective, the non-financial folks on our teams will often look incredulously at this behavior and ask the same question. Why does finance go through implementation, training, and go-live, only to come back to the same place for reporting?
Excel financial reporting in practice
You get through implementation, the data is in place, and the reports start coming out of the system. The close runs, the financial statements are produced, and everything ties. For a while, it feels like the heavy lift is behind you. Then a reporting request comes in that was never part of the original design. Finance needs a different view across entities. The team needs a schedule that connects actuals to what was expected. Someone asks for a way to reshape the data instead of just pulling it.
That is the moment we accounting and finance professionals recognize. The system is doing exactly what it was set up to do, and finance still has to build something else. So finance builds it. The team creates a schedule, reuses it, and adjusts it the next time the question comes back in a slightly different form.
Over time, that work becomes part of the reporting process. Finance keeps it in a place where the team can change it each time it is needed.
Where reporting gets questioned in ERP environments
After implementation, someone starts asking why reporting still happens in Excel. The question usually comes from outside finance. The system is in place, the data is centralized, and the expectation is that reporting should come directly from it. So finance takes a look. Can this report be built inside the system? Can the structure be adjusted to support it? Can a new dimension or mapping solve it?
Sometimes the answer is yes. Most of the time, the answer creates more work than it removes. Changing the structure affects other reports. It introduces dependencies that did not exist before. It requires coordination, testing, and time that the reporting cycle does not allow.
Meanwhile, the request does not go away. The deadline does not move. So finance answers the question the same way it always has. The report gets built in a place where the team can control the structure and deliver it on time.
Reporting workflows in Excel
The first question is who can build the report. If it's an internal resource, the next question is how long it will take. The person who knows how to do it is already tied up. The request gets added to a list. The timing becomes uncertain, and the deadline does not move.
If it's an external resource, the question shifts immediately to cost. What started as a reporting request turns into a scoped piece of work. There is a conversation about hours, revisions, and whether the result will actually match what was needed the first time. Those questions come up every time the reporting need falls outside what already exists in Business Central. The report still has to be built. The meeting is still on the calendar.
At that point, the decision changes. Finance builds the report where it can control the outcome. Excel becomes the place where the structure gets defined, adjusted, and delivered without waiting on availability or approvals. That is where custom reporting actually happens. The system provides the balances. The workbook defines how those balances are organized and explained.
Excel financial reporting and control
Once finance builds a report in Excel, the team is responsible for keeping it aligned with what stakeholders need to see.
Those requirements come from different directions. Leadership wants a different view. Auditors ask for additional support. Lenders need a format that ties to their covenants. The structure changes as those requests come in.
Finance updates the report directly. The team adjusts groupings, adds new schedules, and changes how results are presented without going back to system configuration each time. A request comes in and the team can open the file, adjust the structure, and produce an updated version in the same cycle. No handoff. No waiting. No need to rethink how the system is configured just to answer a different question.
Over time, the report becomes something the team relies on. It gets reused, expanded, and modified as new requirements come in. The work stays close to the people who are responsible for explaining the numbers.
Maintaining reporting with live data
Go back to the question from the beginning. After all the time and money spent on an ERP implementation, why does the reporting still end up in Excel?
Because this is where the work keeps moving. New questions come in. Requirements change. The structure gets adjusted again and again as finance works through what needs to be explained.
That work doesn't suddenly vanish or slow down once a new system is in place. It continues every reporting cycle. Excel stays in the process because it gives finance a place to keep building on top of what already exists. A report created this month becomes the starting point next month. The team extends it, reshapes it, and carries it forward.
The friction comes from keeping that structure aligned with the data in Business Central as it changes underneath it. When the process depends on exports, someone has to reconnect everything each time the report evolves. A like Velixo removes that step. Finance keeps building in Excel, keeps control of the structure, and works on top of data that stays tied to the system.
If the current process still relies on exporting data and rebuilding that connection each time the report changes, that is the place to focus.
