Getting data out of SAP into Power BI without breaking things

When an organisation running SAP wants modern analytics, the first proposal it usually receives is to connect Power BI straight to the tables. It works in the demo. The problems show up later, and they come in three different flavours.

Why reading tables directly breaks

SAP's data model was never designed to be read from outside. A business fact you think of as an order line lives spread across several tables with technical names, with the interpretation logic sitting in the application code, not in the database.

That has two consequences:

• The logic gets duplicated. You reimplement in DAX or SQL rules that SAP already applies. When SAP changes a rule and nobody tells you, your numbers stop matching theirs and nobody knows which is right.
• An upgrade knocks it over. Internal structures can change between versions. What was stable for two years stops working on a Monday morning.

The third problem, which is the expensive one

Accessing SAP data from an external system can carry implications for your licence agreement, depending on how the access happens and who consumes the result. This is not a technical detail: it is a contractual conversation.

Before choosing an extraction method, ask whoever owns your SAP contract what each route implies. It is half an hour that can prevent a very unpleasant licence review.

No serious integrator should design your extraction without having had that conversation first. If somebody proposes one without mentioning it, be sceptical.

The routes that do hold up

• OData services published from SAP. The SAP team exposes what it chooses to expose, with business logic already applied. It is the cleanest option: you consume a stable contract, not an internal table.
• SAP's own analytical views. Built precisely for external consumption, they preserve the business semantics.
• Extraction into an intermediate layer. Data lands in your own store — Fabric, Azure SQL — and from there you are in control. This is what we recommend when volume is high or when SAP has to be joined with other sources.

The decision almost nobody raises in time

How often do you genuinely need the data? The instinctive answer is “real time”, and it is almost never true. A financial close does not change every minute; inventory, depending on the business, perhaps it does.

The difference matters because an incremental overnight extraction is an order of magnitude cheaper and more stable than continuous synchronisation. Paying for real time in order to look at a dashboard once a day is the most common waste in these projects.

Where someone like us fits

Let us be clear about the split: the SAP side belongs to whoever knows your SAP, which is usually your internal team or your SAP consultancy. We come in from the extraction point onwards: modelling, storing, calculating and presenting. That boundary is worth writing down before starting, because the projects that fail usually fail exactly there, in the no man's land between the two teams.