What Happens Between Your ERP and Your Dashboard? A Practical Guide to ETL


After more than 30 years working with businesses, finance teams and reporting, I have learnt that most finance leaders do not spend much time thinking about what happens to data before it reaches a dashboard.

And I understand why.

What matters is the result. Are the numbers current? Do they agree? Can the board trust them? Can you answer the next question without asking someone to rebuild the report?

The problem is that these questions become much harder to answer when the underlying information sits across an ERP, an accounting platform, operational systems and spreadsheets.

A dashboard may present everything neatly, but a good looking dashboard does not automatically mean you have reliable reporting. What happens to the data before it reaches that dashboard matters just as much as what you eventually see on screen.
that dashboard matters just as much as what you eventually see on screen.

This is where the ETL Process for business intelligence comes in.

ETL stands for Extract, Transform and Load. It sounds technical, but the business purpose is quite simple. You take the relevant data from the systems you already use, prepare it consistently, and make it available to a reporting layer that your team can work with.

For CFOs and finance leaders, understanding this foundation helps explain why reporting can remain frustrating even after new dashboards have been introduced.


Why Connecting Systems Is Only the Beginning

One of the assumptions I often come across is that better reporting starts with connecting all your systems to a dashboard.

That is certainly part of the process, but it is only the beginning.

A connection gives you access to data. It does not automatically make that data consistent, comparable or useful for management reporting.

One system may define a customer differently from another. Product codes may have changed over time. A spreadsheet may contain adjustments that never make their way back into the ERP. Finance may calculate a key metric differently from the operational team.

If you simply take those differences and push them into a dashboard, you have not solved the underlying reporting problem. You have presented it more neatly.

In my experience, this is an important distinction.

A reliable reporting layer needs work beneath the dashboard. The data has to be brought together, checked and structured around definitions that the business agrees on.

What ETL Means in Plain English

ETL describes three connected steps.

Extract means retrieving the relevant information from the systems the business already uses.

Transform means preparing that information so that formats, definitions and calculations are consistent.

Load means placing that prepared information into the structure used for reporting and analysis.

For me, the important part is not the terminology. A finance leader does not need to become an ETL specialist.

What matters is having a controlled path between the original source data and the number that eventually appears in a management pack or dashboard.

When that path is repeatable, you reduce the dependence on someone exporting files, copying columns, correcting formulas and remembering which manual adjustment needs to happen every month.

That is where ETL starts becoming a finance issue rather than simply a technology issue.

Extracting Data From the Systems You Already Use

Many of the businesses I have worked with already have the systems they need to run their operations.

The difficulty is that those systems were built to do different jobs.

Your ERP may handle transactions and financial processes. An operational platform may contain information that finance needs for performance reporting. Important calculations, classifications or adjustments may still sit in key spreadsheets.

That does not necessarily mean those systems need to be replaced.

With Insight BI, our approach is to work with the systems a business already relies on. Relevant data can be extracted in a controlled and repeatable way and brought into the reporting environment. This is important because improving reporting should not mean creating unnecessary disruption across the organisation.

The aim is to establish a dependable reporting foundation around the systems that are already doing their jobs.

Turning Raw Data Into Agreed Business Information

For me, the transformation stage is one of the most important parts of the process.

This is where raw data starts becoming useful management information.

Consider a situation I have seen many times. Two reports show different values for what appears to be the same metric.

People immediately ask which report is wrong.

Sometimes neither report is technically wrong. They may simply be working from different definitions, periods, mappings or adjustments.

That is a reporting problem that another dashboard alone will not solve.

During the transformation process, these differences can be addressed before the information reaches the reporting layer. Data is prepared according to agreed definitions and calculations so that everyone is working from the same basis.

Finance has an important role here.

Technology can process the information, but the business still needs to agree on what a metric actually means. Gross margin, customer categories, portfolio measures and other management metrics need clear definitions if leadership is expected to use them consistently.

Why the Data Model Matters

Once the information has been prepared, it needs structure.

In Business Intelligence, we call this the data model.

I tend to think of the data model as the agreed structure underneath your reports. It connects the relevant information and calculations so that dashboards and reporting packs draw from the same foundation.

At Insight BI, we build and maintain this layer around the definitions and calculations agreed with the business.

One of the reasons this matters is that it reduces the amount of critical reporting logic hidden inside individual spreadsheets and manual processes.

Businesses change.

A new branch opens. A product structure changes. Management introduces another metric. Reporting requirements develop as the organisation grows.

What Good Data Foundations Change for Finance

A strong data foundation does not replace the judgement of an experienced finance team.

It supports it. Instead of rebuilding the same reporting process every month, your team can work with a repeatable flow of information. Agreed metrics can be applied consistently across dashboards and reporting packs. When management asks another question, the team can investigate it within the same reporting environment instead of immediately starting another spreadsheet exercise.

There is also the issue of key person risk.

I have seen many reporting environments where one person knows exactly how everything works.
They know which spreadsheet to open, which formula needs attention, where the manual adjustments are made and which numbers need to be checked before the report goes out.

Those people are incredibly valuable, but that dependence creates risk for the organisation.

Moving important reporting logic into a shared data model makes the process easier to understand, maintain and repeat.

For a CFO, that creates a much clearer line between the original data, the agreed calculations and the information eventually presented to leadership.

Where Insight BI Fits

This thinking is central to how we approach reporting at Insight BI.

We provide a managed reporting layer over the ERP, accounting systems, operational tools and key spreadsheets that a business already uses.

We connect to the relevant sources, structure the information around agreed definitions and present dashboards, reports and automated packs that reflect how the organisation is actually managed.

But the work does not stop once the first dashboard is delivered.

The reporting layer needs to be maintained. Metrics change. Structures change. Management asks different questions. The organisation itself changes.
That is why I do not see ETL and data modelling as once off technical tasks.

They form part of an ongoing reporting environment that needs to remain aligned with the business.

If your management reporting still relies heavily on manual exports, spreadsheet adjustments and knowledge held by a few key people, I would encourage you to look beneath the dashboard.

The question is not only whether the dashboard looks good.

The more important question is whether you can trust the reporting foundation underneath it.

That is the problem we work on at Insight BI.

If you would like to discuss what a managed reporting layer could look like around the systems you already use, get in touch with us.