Data Factory for SAP Integration - Connecting SAP to Power BI in 2026

If you're running SAP in Australia and you want your data in Power BI, you've probably already discovered that there isn't one correct way to do it. There are at least six, and the wrong choice can cost you a six-figure rebuild eighteen months from now when SAP licensing changes or your data volumes outgrow whatever shortcut you took.

I run Team 400 and we've been doing SAP integration work for Australian enterprises across mining, manufacturing, utilities, retail, and government. This post is for the person who has a Power BI ambition, a SAP system in the way, and a vendor or two quoting wildly different numbers to bridge them. I'll cover the connector patterns that actually work, the ones that look attractive but cause pain, and what each option costs to deliver and run.

Why This Is Harder Than It Looks

SAP isn't a database. It's a platform with its own application layer that owns the business logic, the data structures, and (the part most teams forget) the licensing terms around how you can extract data. Bypass the application layer (by going straight to the underlying database, for example) and you'll often find yourself in breach of SAP's note 7404511 or its successor. SAP audits do happen and they're expensive.

So the question of "how do I get my SAP data into Power BI" is actually three questions stacked on top of each other.

How do you legally and supportably extract data from SAP? How do you transport that data into a modern data platform (typically Azure Data Lake or Microsoft Fabric)? And how do you model it so Power BI can produce reports that perform and that finance recognises as correct?

Most of the cost in an SAP-to-Power-BI project sits in the first and third questions. The middle bit, the Data Factory pipelines, is usually the easiest part.

The Six Connector Patterns and When Each Is Right

Here are the patterns we see in production. Each has trade-offs, and the right one depends on your SAP version, your data volumes, your latency requirements, and your licensing situation.

Pattern 1 - SAP Table Connector via Data Factory

The SAP Table connector in Data Factory (both Azure and Fabric variants) reads data directly from transparent and cluster tables in SAP ECC or S/4HANA. It's fast, doesn't need a SAP BW or Datasphere licence, and works well for bulk historical extraction.

The catch is licensing. SAP doesn't love bulk table extraction by external tools. If you're on a current S/4HANA licence with the data access terms post-2024, you have specific rights to extract via the table interface for data warehousing purposes, but you should have your SAP basis team and licensing partner confirm this in writing for your specific contract.

When it's right - You have ECC or S/4HANA on-premise, your data team needs to extract sizeable history (think tens of millions of rows from BSEG, MARA, VBAK and the like) and you have clear extraction rights confirmed.

When it's not - You're on RISE with SAP cloud-hosted, where direct table access is more restricted. Or you're trying to extract from CRM, SuccessFactors, or Ariba where this connector doesn't apply.

Pattern 2 - SAP CDS Views via OData

Core Data Services views are SAP's modern data model. They wrap the underlying tables with proper business semantics, currency handling, and authorisation checks. You expose them via OData and consume from Data Factory using the OData connector.

This is the pattern SAP themselves push, and for good reason. The data comes out semantically correct, you're using interfaces SAP intends for external consumption, and your licensing posture is clean.

The trade-off is performance and history. OData is request-response, not bulk extract. Pulling 50 million rows from a CDS view is going to take hours and may time out. You're also dependent on whether the CDS view you need exists or whether your SAP team has to build it.

When it's right - Real-time or near-real-time reporting, modest data volumes (low millions of rows per extract), or extracts that need SAP's business logic applied. Particularly good for S/4HANA where CDS views are first-class citizens.

When it's not - Bulk historical loads or anywhere you need column-level joins across multiple SAP modules that don't have a unified CDS view.

Pattern 3 - SAP ODP (Operational Data Provisioning) via Data Factory

ODP is the framework SAP designed for incremental data extraction. It tracks changes and lets you pull deltas efficiently. Data Factory has a native ODP connector that supports SAP extractors, CDS views with ODP enabled, and BW objects.

This is what we recommend for most ongoing operational reporting. You do an initial load, then daily or hourly delta extracts. Performance is good, the licensing story is clean, and it works on both ECC and S/4HANA.

The complexity is in setup. ODP requires basis configuration on the SAP side, gateway configuration, and proper authorisation. If your SAP basis team is overloaded or unfamiliar with ODP, this can stall a project for weeks.

When it's right - Operational reporting where you need fresh data, mixed full-load and delta scenarios, or extraction from BW objects you want to retire.

When it's not - You don't have basis support to configure the SAP side. Or you need data that isn't exposed through an extractor or ODP-enabled CDS view, and creating one is too much work.

Pattern 4 - SAP Datasphere as a Middle Layer

Datasphere (formerly Data Warehouse Cloud) is SAP's managed data warehouse offering. The pattern here is to expose your SAP data through Datasphere, then connect Fabric or Power BI to Datasphere via its data access APIs.

This works well for organisations already invested in Datasphere or for those who want to keep the modelling layer inside SAP for governance reasons. It's also the only sensible answer if you're on RISE with SAP and direct table extraction is locked down.

The downside is cost. Datasphere licensing in Australia for a moderate-sized enterprise typically lands between $250,000 and $700,000 per year. You're paying for a platform you may not need if your goal is just to get data to Power BI.

When it's right - You have governance requirements that mean SAP must own the semantic model, you're already paying for Datasphere, or you're on RISE and don't have other options.

When it's not - You're cost-sensitive and have alternatives.

Pattern 5 - SAP LT Replication Server (SLT) to a Staging Database

SLT performs trigger-based replication from SAP into a staging database (Azure SQL, Synapse, or Fabric Lakehouse). It's real-time, it scales, and it captures every change.

We see this in two situations. Mining and manufacturing clients who need operational dashboards that reflect SAP state within seconds, not hours. And clients running large historical workloads who've decided that the upfront licensing and infrastructure cost is worth it because they're doing tens of integrations from SAP.

SLT is expensive to set up and operate. You need a SAP SLT system (licensing and basis effort), a target database, and ongoing operations of the replication. Implementation projects we've done in this space typically run $250,000-$600,000 for the SAP side, plus $150,000-$300,000 for the Azure data platform work.

When it's right - You need real-time or near-real-time data, you have a high integration count justifying the platform cost, or you're already running SLT for another reason.

When it's not - You only need daily reporting and you don't have other SLT use cases.

Pattern 6 - SAP BW Open Hub or BW Bridge

If you have a legacy SAP BW system, Open Hub is the well-established pattern for exporting data to external consumers. BW Bridge is the newer SAP-cloud-native equivalent that links BW to Datasphere.

We see this less often as new builds because most enterprises moving to Power BI are also moving away from BW. But if you have a BW system that contains years of carefully modelled data, Open Hub is the path of least resistance to expose that modelling work to Power BI without rebuilding it.

A Comparison Table

Pattern	Best For	Licensing Risk	Typical Setup (AUD)	Latency
SAP Table Connector	Bulk extract, ECC/S4 on-prem	Verify with SAP licensing partner	$80k-$180k	Hours
CDS via OData	Modern S/4HANA, modest volumes	Low	$100k-$220k	Minutes
ODP Connector	Ongoing operational extracts	Low	$120k-$250k	Minutes to hours
Datasphere middle layer	Governance-heavy or RISE	Low	$150k-$300k + Datasphere licence	Minutes
SLT replication	Real-time, high volume	Low	$400k-$900k total	Seconds
BW Open Hub	Existing BW assets	Low	$80k-$180k	Hours

These ranges are for the end-to-end Data Factory and Power BI delivery, not just the SAP connector configuration. They include landing the data in Azure or Fabric, modelling it in a sensible warehouse, and building the first set of Power BI reports.

What Goes Wrong (and How to Avoid It)

We've cleaned up enough SAP integration projects to know what kills them.

Ignoring the semantic layer. The team extracts data from SAP, lands it in Fabric, and starts building Power BI reports. Six months later, finance points out that the numbers don't match the SAP P&L because nobody handled the currency conversion logic, the period close adjustments, or the cost centre rollups properly. Building a semantic layer that finance trusts is genuinely 30-40% of the work in an SAP-to-Power-BI project. Plan for it.

Underestimating master data. SAP master data has business logic embedded in it. A material isn't just an ID, it's an ID with valid-from dates, view structures, plant assignments, MRP types, valuation classes, and a dozen other attributes that determine whether your reports are right. Get the master data wrong and your reports will be wrong in subtle ways that take months to discover.

Skipping incremental extraction strategy. Pulling full data sets every day works fine until you have 200 million rows. Then it doesn't. Get the change tracking strategy right at the start - either using ODP, SLT, or change date columns - and you'll save yourself a rebuild down the line.

Building on the wrong platform tier. We see this with Fabric. A client buys an F4 capacity, lands their SAP data, and then can't run anything because they don't have the compute. Fabric capacities for SAP workloads typically need to be F32 or higher. The maths is real.

No documentation of the SAP source logic. When the original developer leaves, nobody knows why BSEG has been joined to BSEG_ADD with a particular filter on KOART. The next engineer who has to fix something has to reverse-engineer it. Write down the SAP source logic in plain language and you'll save your future team weeks of forensics.

Pricing Ranges for Australian Engagements

Most SAP-to-Power-BI projects we deliver in Australia land in one of three brackets.

Compact ($120,000-$250,000, 12-20 weeks). One SAP source system, a defined scope of around 10-30 entities, a Fabric or Synapse staging layer, and an initial set of 5-15 Power BI reports. Suitable for mid-sized enterprises with a clear reporting need and a relatively contained SAP environment.

Mid-size ($250,000-$600,000, 5-9 months). Multiple SAP source systems (ECC plus SuccessFactors, or S/4HANA plus Concur), incremental extraction patterns, a proper semantic layer in Power BI, and 30-80 reports. This is the typical "the BI team wants to move off Excel" engagement.

Enterprise ($600,000-$1.5M+, 9-18 months). Real-time replication, multiple SAP and non-SAP sources, governance and lineage, training, and a phased migration off legacy reporting tools. Often delivered alongside an SAP migration or upgrade.

Beyond these, ongoing operations and enhancements typically run $15,000-$60,000 per month depending on scope, change rate, and how much new reporting you're commissioning.

Where Fabric Changes the Picture

The launch of Microsoft Fabric in 2024 and its maturation through 2025 and 2026 has shifted the typical architecture for SAP integration projects. Where we used to recommend Azure Data Factory plus Azure Synapse plus Power BI as separate services, we now mostly recommend Fabric Data Factory plus Lakehouse plus Power BI as a single integrated platform.

The advantages are practical. One billing model. Direct Lake mode in Power BI means Power BI queries the Lakehouse data directly without import, which removes a layer of refresh complexity. Fabric Data Factory's pipeline experience is close enough to Azure Data Factory's that the transition isn't painful.

The caveats are also practical. Fabric's SAP connector parity isn't yet 100%. Some advanced patterns we used in Azure Data Factory require additional work in Fabric. And Fabric capacity pricing requires careful sizing to avoid surprise bills.

We have detailed guides on the differences in Microsoft Fabric consultants and Microsoft Data Factory consultants.

When You Need a Specialist

The Australian market has many BI implementers and many Microsoft partners. The number who genuinely know SAP integration is much smaller. Generic Microsoft partners can build the Azure side fine, but if they haven't worked with SAP's quirks (the difference between ECC and S/4HANA extraction, the implications of UnicodeReturnCode, how to handle text tables, currency translation, period parameters in BW queries) they'll burn six weeks figuring it out on your dime.

The right team for an SAP-to-Power-BI engagement has Microsoft data engineering depth, real SAP knowledge (not just having installed the connector once), and the data modelling experience to build a semantic layer that finance trusts. That combination is rarer than the slideware suggests.

Team 400 has built this kind of integration for Australian mining companies, manufacturers, utilities, financial services firms, and government agencies. We have engineers with SAP basis backgrounds, data modellers who've spent years inside SAP general ledger structures, and Power BI specialists who can build the reports that go on the CEO's screen.

How to Start

If you're at the comparison stage, three things to do.

First, ask any vendor pitching this work to walk you through how they'd handle currency translation, period close adjustments, and master data versioning for SAP general ledger data going into Power BI. If they can't, they haven't done it properly before.

Second, request a worked example with realistic numbers from a previous client (anonymised). Specifics or nothing.

Third, talk to us through our contact page. If you'd like to read more first, our Power BI consultants and Data Factory consultants pages cover how we work. The AI for manufacturing and mining industry pages have examples from SAP-heavy environments.

The tooling is mature and the patterns are well understood. The outcome (a finance team that trusts the Power BI reports more than the SAP standard ones) is achievable. Getting there requires doing the work properly, and properly costs more than the cheapest quote you'll receive.