Every S/4HANA implementation reaches the same fork: what should handle reporting? The system ships with a native analytics layer that covers most operational use cases at no additional cost. But it has hard limits. When those limits surface (cross-system consolidation, financial planning, long-term historical data), organizations reach for BW/4HANA or SAP Analytics Cloud. Getting the sequencing wrong costs time and money. Getting it right means standing up fast, cheap operational reporting on day one, then adding layers as business demand justifies the investment.
This article maps out what each layer does, where each one stops, and how to choose between them for a given S/4HANA environment.
Table of Contents
The Three Native SAP Reporting Layers for S/4HANA
SAP provides three distinct analytics layers for S/4HANA environments, and they are built to work together rather than replace each other.
S/4HANA Embedded Analytics is the reporting capability built into S/4HANA itself. It runs on the same SAP HANA in-memory database as the transactional system, exposes data through Core Data Services (CDS) views, and surfaces operational reports and KPIs through the Fiori Launchpad. There is no separate infrastructure, no data replication, and no additional license cost. The scope is limited to data within the S/4HANA system boundary.
BW/4HANA is SAP’s enterprise data warehouse. It sits outside the transactional system and consolidates data from S/4HANA alongside other SAP applications (SuccessFactors, Ariba) and non-SAP sources. It handles complex transformations, long-term historical retention, and cross-system reporting under a governed data model. It requires a separate product license and specialist skills to implement.
SAP Analytics Cloud (SAC) is the cloud-only front-end for BI, integrated planning, and predictive analytics. It connects to S/4HANA or BW/4HANA via live or import connections and adds visualization, write-back planning, and ML-driven forecasting that neither of the other two layers provides.
These three layers occupy different positions in the analytics stack. Embedded Analytics answers “what is happening right now in my S/4HANA processes?” BW/4HANA answers “what does the consolidated picture look like across all systems and time periods?” SAC answers “where are we heading, and how do we plan around that?” Most mature SAP organizations run all three, phased in over time as their requirements grow.
S/4HANA Embedded Analytics: Architecture and Capabilities
Embedded Analytics is often undersold at go-live and then relied on more heavily than expected. Understanding its architecture explains both why it performs so well for operational reporting and why it breaks down the moment requirements extend beyond the S/4HANA boundary.
CDS Views and the Virtual Data Model
The foundation is the CDS view layer, organized into three tiers. Basic views sit closest to the database tables. Composite views join and aggregate basic views into reusable building blocks. Consumption views are the top tier: they are the ones flagged for analytical use, exposed as OData services, and surfaced in Fiori apps. A standard S/4HANA system contains over 72,000 CDS views, with consumption views serving as the analytical entry point for each functional area.
Because CDS views are virtual data models layered over in-memory HANA tables, query results reflect the current state of the transactional data without any batch load or replication delay. A procurement controller checking open purchase orders sees the same data state as the buyer processing them in real time.
Analysts who need to build custom queries without development skills can use the Custom Analytical Queries Fiori app. It lets users compose pivot-style queries against existing consumption views, define calculated key figures, and configure default filters without writing a line of ABAP. More complex use cases involving custom joins or annotation logic require ABAP Development Tools (Eclipse ADT).
Fiori Analytical App Types
SAP ships more than 500 predefined analytical Fiori apps covering over 50 lines of business. The main app types serve distinct purposes. Overview Pages provide role-based dashboard cards with a shared filter bar, designed for roles like procurement manager or plant controller who need a snapshot of their process area. Analytical List Pages combine chart and table analysis with the ability to trigger a follow-up transaction from the same screen, keeping the operational loop tight. Smart Business KPI tiles sit on the Fiori Launchpad and show threshold-based indicators (red, yellow, green) with trend arrows and drill-down paths.
The combination of Overview Pages and ALPs covers most day-to-day operational reporting requirements for controllers, plant managers, warehouse supervisors, and production planners. The Query Browser supports power analysts who prefer free-form ad hoc queries, replacing the ECC-era SAP Query tool.
Where Embedded Analytics Stops
The single-system boundary is the defining constraint. Embedded Analytics cannot query data from other SAP systems or non-SAP applications. It has no planning engine, no write-back capability, and no historical data warehouse. Predictive forecasting (time-series, classification) requires SAC’s Smart Predict module. Visualization options are functional but limited compared to SAC Stories or Power BI visuals.
SAP also recommends keeping any embedded BW component within S/4HANA to no more than 20% of the total S/4HANA database size. Organizations that push operational reporting beyond the CDS view model run into that boundary quickly.
BW/4HANA: Enterprise Data Warehouse for Cross-System Reporting
BW/4HANA is SAP’s HANA-exclusive data warehouse, the successor to classic SAP BW launched in 2016. It fills the gap that Embedded Analytics cannot close: consolidating data from multiple source systems, retaining years of historical transactions, and applying complex transformation logic before data reaches any reporting surface.
LSA++ Architecture and Core Objects
BW/4HANA uses the Layered Scalable Architecture (LSA++) model. The acquisition layer handles data ingestion and staging from source systems. The modeling layer handles transformation, enrichment, currency conversion, and master data harmonization. The analysis layer holds the query and reporting objects that SAC, Analysis for Office, or direct HANA consumers read from.
The primary storage object in BW/4HANA is the Advanced DataStore Object (ADSO), which replaces both InfoCubes and classic DSOs from BW 7.x. The CompositeProvider object replaces MultiProviders and InfoSets, executing JOIN and UNION operations entirely within the HANA in-memory engine rather than at the application server layer. This architectural change is significant for performance: complex analytical queries that took minutes on classic BW hardware typically run in seconds on HANA.
BW/4HANA models can be exposed as native HANA Calculation Views, letting SAC, Datasphere, or third-party BI tools consume the modeled data without requiring a BW-specific connection.
Migration from Classic BW 7.x
SAP BW 7.5 mainstream maintenance ends December 31, 2027, the same date as SAP ECC mainstream support. Organizations running both ECC and BW 7.5 face parallel migration tracks. Coalesce’s migration FAQ advises against waiting for the ECC migration to complete before starting the BW migration: treating them as sequential projects compresses the timeline dangerously. A better approach is to treat ECC and S/4HANA as separate data sources in the BW model and run them in parallel during transition.
BW/4HANA on HANA carries a maintenance commitment through at least 2040, aligning with the S/4HANA roadmap. Organizations that complete the migration preserve a supported, high-performance data warehouse without committing to a public cloud architecture.
The migration path from BW 7.5 supports shell conversion (technical migration preserving object structure with full data reload) or remote conversion (migration from a source BW running in a separate system). Object mapping is direct: InfoCubes and classic DSOs become ADSOs, MultiProviders become CompositeProviders, and BEx Query Designer is replaced by BW Modeling Tools in Eclipse. BEx Analyzer, which reached end of support in October 2025 tied to Office 2016/2019 EOL, must be replaced by Analysis for Office or SAC.
A broader discussion of how BW/4HANA, Embedded Analytics, and external BI tools fit into the full SAP reporting landscape is covered in this SAP reporting overview on the Metrica blog.
SAP Analytics Cloud: BI, Planning, and Predictive on One Platform
SAC is a cloud-only SaaS product hosted on SAP Business Technology Platform. It has no on-premise deployment option. SAP manages infrastructure, patching, and quarterly release cycles, removing most of the administrative overhead associated with on-premise BI platforms.
Live vs. Import Connections to S/4HANA
The connection model to S/4HANA and BW/4HANA is one of SAC’s most consequential architectural decisions, and organizations frequently underestimate the tradeoffs at implementation time.
Live connections to S/4HANA on-premise use the InA (Information Access) REST protocol with CORS configuration between the S/4HANA system and the SAC tenant. At runtime, queries go from the user’s browser directly to S/4HANA; data does not transit through SAC infrastructure. SAP authorization checks run in the source system. This preserves data residency and ensures that SAC reports always show current system state, but performance depends entirely on the quality of the CDS view design and the HANA server load at query time.
Import connections copy data into SAC’s own in-memory storage on a scheduled basis. They enable more complex data blending and predictive scenarios that live connections cannot support, but they introduce a staleness gap. For boards reviewing last night’s data cut, that is acceptable. For a controller checking open invoices before a payment run, it is not.
Organizations running S/4HANA 1909 or later get the best live connection experience; the SAML SSO Standard-Compliant mode is supported from that release. The SAP Help Portal documents both live data connections to S/4HANA for organizations evaluating the technical setup requirements.
SAC Planning Licenses and the Datasphere Coupling
SAC’s licensing model splits cleanly between BI use and planning use. The BI license covers dashboards, reporting, and exploration. Planning licenses (standard and professional editions) include full BI rights and add write-back to S/4HANA CO/FI accounts, version management, driver-based planning, and approval workflows. Currency conversion and value driver trees require the professional edition.
A significant architectural shift landed in Q1 2025: SAC’s Seamless Planning architecture now uses SAP Datasphere as the storage layer for planning data. SAC and Datasphere have become architecturally co-dependent for enterprise planning scenarios. Organizations evaluating SAC for planning need to factor in Datasphere licensing and implementation alongside SAC licensing.
The Seamless Planning change aside, SAC’s unified BI, planning, and predictive capability remains its strongest argument over standalone BI tools. Smart Predict provides time-series forecasting, classification, and regression without requiring a data science team. The Digital Boardroom packages executive KPIs and guided narratives for board presentations. Analysis for Office keeps Excel power users productive without migrating them off Excel entirely.
Decision Matrix: Comparing the Three Layers
The table below covers the dimensions that most commonly drive architecture decisions during S/4HANA rollouts.
| Dimension | Embedded Analytics | BW/4HANA | SAP Analytics Cloud |
|---|---|---|---|
| Data scope | S/4HANA only | Multi-source, cross-system | SAP + limited non-SAP via connections |
| Data latency | Zero (true real-time) | Near-real-time to batch | Near-real-time (live) or batch (import) |
| Historical data retention | Limited to active S/4HANA data | Long-term warehouse retention | Dependent on connected source |
| Cross-system consolidation | No | Yes, core capability | Limited without Datasphere or BW/4HANA |
| Planning and write-back | No | Via SAP BPC add-on | Yes, core capability |
| Predictive and AI | No | No | Yes, Smart Predict + Joule |
| Additional license cost | None | Separate product license | Per-user SaaS subscription |
| Deployment model | On-premise/cloud S/4HANA | On-premise or private cloud | Cloud SaaS only |
| Typical implementation time | Days to weeks | Months to years | Weeks to months |
| Self-service for business users | Limited | Low | Moderate |
Common Challenges Across SAP Analytics Implementations
Knowing the tools is one thing. Knowing where implementations stall is another.
CDS view quality determines Embedded Analytics coverage. A poorly modeled S/4HANA implementation with custom fields not exposed via CDS views will have analytical blind spots from day one. Organizations that carry forward ECC customizations to S/4HANA without reviewing the CDS layer often discover this only when the first reporting requirements arrive.
BW/4HANA complexity is frequently underestimated. The 2027 deadline creates pressure to migrate BW 7.5 quickly, but BW/4HANA still requires specialist skills for data modeling, ETL development, and administration. Teams that treat BW/4HANA migration as a technical lift-and-shift without assessing the business logic in existing data flows typically inherit the same complexity in a new platform.
SAC performance is the most cited pain point by end users. Complex live connection scenarios with large datasets and poorly optimized HANA models can produce slow query times that undermine adoption. SAC is not a substitute for a clean data layer; it amplifies whatever quality exists underneath it.
The 2027 ECC deadline compounds the challenge. Only around 57% of ECC customers are projected to complete S/4HANA transformations before the support cutoff, according to Basis Technologies research. Organizations that are still mid-migration in late 2027 will be running unsupported ECC infrastructure feeding reporting systems that depend on it. BEx Analyzer already hit end of support in October 2025, so any analyst still using it has an active gap today.
Best Practices for S/4HANA Analytics Architecture
The organizations that build sustainable analytics architectures tend to follow a consistent set of principles, even when the platform stack varies.
Start with Embedded Analytics at S/4HANA go-live. The 500+ predefined Fiori apps cover 60-80% of standard operational reporting with zero additional spend. Activating them early establishes a reporting baseline, builds user familiarity with Fiori, and gives the project team time to identify the gaps that will eventually require SAC or BW/4HANA.
Define the cross-system data requirement before committing to a BW/4HANA build. If the reporting scope is 100% S/4HANA data, BW/4HANA adds cost and complexity without corresponding benefit. The decision to build a data warehouse should be driven by a confirmed requirement for historical retention or cross-system consolidation, not by organizational habit from the ECC era.
Do not treat SAC as a shortcut around a missing data layer. SAC’s live connections are excellent when backed by well-designed CDS views or BW queries. When the data foundation is messy, SAC surfaces that mess for users to interact with. Investing in CDS view quality or BW modeling before building SAC dashboards pays dividends downstream.
Separate BW and ECC migration timelines. Running them in parallel is manageable; sequencing ECC first creates a timeline problem for BW 7.5, whose mainstream maintenance ends on the same December 2027 date.
For organizations evaluating how data integration layers connect the SAP stack to broader analytics infrastructure, the distinctions covered in this ETL vs. data integration guide are relevant context for scoping a BW/4HANA or Datasphere build.
Third-Party BI in S/4HANA Environments
Some organizations already have Power BI or Tableau in production and want to extend their existing BI investment to cover S/4HANA rather than adopt SAC. This is a legitimate architecture in the right circumstances.
Power BI connects to S/4HANA through SAP HANA DirectQuery, which queries CDS-based Calculation Views via HANA’s columnar in-memory engine. For S/4HANA 1909 and later, this is the recommended connector path. The SAP BW connector for Power BI is the other option for BW-sourced data, but it carries well-documented performance limitations: queries that return in seconds inside BEx Analyzer can take 10-15 minutes through BAPI overhead in Power BI. Currency conversion logic defined in BW does not carry through to Power BI automatically and requires reimplementation.
The functional gap between SAC and Power BI for SAP environments is real. SAC live connections preserve full SAP hierarchy navigation, BW variable logic, and authorization inheritance. Power BI’s BW connector supports these only partially. For organizations deeply invested in SAP semantic objects (InfoObjects, hierarchies, authorization-relevant characteristics), SAC retains a material edge for governed reporting.
Where Power BI genuinely outperforms SAC is in non-SAP connectivity. With over 300 native connectors and DAX’s flexible calculation model, Power BI is the better choice when the analytics scope spans SAP alongside Salesforce, Azure SQL, Snowflake, and a dozen other sources. The Power BI Connector for SAP from Metrica Software is one option for teams that want to maintain a Power BI-centric stack while connecting to SAP data sources.
A hybrid approach is common in practice: SAC handles governed SAP-centric reporting and financial planning while Power BI covers ad hoc analysis and departmental dashboards drawing on non-SAP data. This avoids the tool debate by assigning clear ownership based on data context.
Choosing the Right Layer for Your S/4HANA Rollout
The right starting point depends on three variables: data scope, planning requirements, and deployment model.
If the reporting scope is confined to S/4HANA data, start with Embedded Analytics. Add SAC when integrated financial planning with write-back becomes a business requirement. BW/4HANA belongs in the architecture when cross-system consolidation, long-term historical retention, or a regulated data lineage requirement appears.
For organizations migrating from ECC with an existing BW 7.5 installation, the migration question is not whether to keep BW but which version and deployment model to target. BW/4HANA on HANA carries SAP maintenance through 2040 and supports private cloud deployment, making it a stable choice for regulated industries or organizations with on-premise commitments. The more ambitious alternative is moving directly to SAP Business Data Cloud (Datasphere plus SAC), bypassing standalone BW/4HANA in favor of a cloud-native data fabric. That path suits organizations pursuing a public cloud strategy and willing to invest in the platform transition.
The crawl-walk-run model describes how most organizations sequence this in practice. Crawl: activate Embedded Analytics at go-live, zero additional spend. Walk: add SAC for executive dashboards and financial planning. Run: build out BW/4HANA or Datasphere for cross-system consolidation and governed data products. Each phase delivers standalone value, and the next phase can be deferred until business demand makes the investment clearly justified.
One last variable worth checking early: organizational skill inventory. Embedded Analytics and SAC have lower technical barriers for business teams. BW/4HANA requires ABAP and data warehouse skills that take time to recruit or develop. Datasphere is more accessible for business modelers but still requires architectural expertise for multi-source integration. An analytics strategy that outruns the available skills creates a delivery gap regardless of which platform is chosen.
For a broader view of enterprise analytics strategy and how these platforms fit into longer-term data infrastructure decisions, this enterprise analytics guide covers the foundational concepts.
