Concept card

SAP Data Products — The 300+ Catalogue

As of 2026-09-27

Edited by Cédric Mary, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is SAP Data Products?

SAP Data Products are curated, versioned, governed data assets shaped for downstream consumption — the building blocks of BDC.

What it is

SAP Data Products are curated, versioned, governed data assets shaped for downstream consumption — the building blocks of BDC. Sapphire 2026 confirmed 300+ live and announced a 500+ target for Q2 2026; that milestone has not been confirmed as reached, so quote the catalogue count you can verify on the tenant.

Domain coverage visible in the keynote slide. Finance: Billing & Payments · Cash Flow · Compensation. Supply Chain: Deliveries · Inventory · Manufacturing Material · Purchase Orders. Human Resources: Headcount. Service & Sales: Cases & Tickets. Plus extensions across Spend Management and Industry-specific products.

What a Data Product actually contains. Each Data Product is a typed schema + business-meaningful KPIs + lineage to the source SAP system + governance metadata (owner, refresh cadence, classification) + the data itself. A consumer (Joule agent, SAC dashboard, Datasphere model) queries a Data Product as a first-class object — no need to write joins against raw S/4HANA tables.

Why 300 → 500 matters. Every net-new Data Product is a feature SAP delivers for free to existing BDC customers. The pace (200 products added in 2 quarters) is the proof-point SAP is investing in BDC content depth, not just platform. A consultant should track the quarterly Data Product release notes the way an SAP BW consultant used to track Business Content shipments.

When to consume a packaged SAP Data Product versus building a custom Datasphere view — the trade-off decision. The packaged Data Product is the right starting point whenever a standard SAP domain is in scope and the customer's reporting requirements map cleanly to the delivered KPI set. Consuming a standard product means SAP absorbs the maintenance burden: schema updates, lineage corrections, and certification are SAP's responsibility, not the project team's. The implementation speed advantage is real — a Finance team can start querying a standardised Cash Flow Data Product within days of BDC provisioning, versus weeks building and validating an equivalent custom Datasphere Analytic Model.

Choose a custom Datasphere view when the business logic diverges from the standard product: proprietary calculation methods, non-standard cost allocation structures, multi-system blending of SAP and non-SAP sources, or industry-specific KPI definitions that SAP has not yet delivered as a packaged product. The trade-off is full ownership of maintenance. When S/4HANA upgrades change the underlying table structure, a custom Datasphere view breaks silently until someone investigates a report deviation; a packaged Data Product does not. This maintenance asymmetry is the strongest argument for starting with the standard product and customising only where the gap is documented and justified.

Versus replicating raw S/4HANA tables directly into Datasphere: raw replication gives maximum flexibility but zero semantic layer — every consumer team re-implements the same join logic, currency conversion, and KPI definition independently. The Data Product layer is the governance contract that prevents that fragmentation. Replicating raw tables is appropriate only during initial exploration or for operational reporting requirements that no packaged product covers and where custom modeling has begun.

The BW connection. SAP BW Data Product Generator (Available) converts existing BW InfoProviders into Data Products, the canonical BW modernization path. Don't rebuild BW logic from scratch in BDC — generate it.

Governing a catalogue that keeps growing. A 300-to-500 product catalogue is not a static list a consultant memorises once; it is a moving target with its own versioning discipline. Every Data Product publishes a data contract alongside its schema — a named owner, a stated refresh cadence, a sensitivity classification, and an explicit consumer roster — and that contract is what actually distinguishes a Data Product from a shared table with a nicer label. When SAP ships a schema change to an existing Data Product (a new field, a renamed KPI, a tightened classification), the contract is what tells a consuming Joule agent or SAC dashboard whether the change is additive and safe to ignore, or breaking and in need of a review before the next refresh.

Worked example: a Finance team consuming the packaged Cash Flow Data Product for a working-capital dashboard notices, at the start of a new quarter, that SAP's release notes list a schema update adding a currency-hedging field to that product. Because the team consumed the Data Product as a first-class object rather than joining raw tables, the update arrives as an additive column with zero rework required on the existing dashboard — the exact scenario the Data Product layer exists to guarantee. Contrast this with a team that built an equivalent custom Datasphere view against the same raw S/4HANA tables: an unrelated S/4 upgrade changing an underlying table's structure breaks that view silently, and nobody notices until a number in the dashboard looks wrong weeks later.

The edge case worth flagging to a client explicitly: a domain migrating from "no packaged Data Product exists yet" to "a Data Product now covers it" mid-project. When that happens, any custom view built during the gap period needs an explicit decision — retire it in favour of the new packaged product, or document precisely why it still diverges (a proprietary calculation the standard product does not support, for instance). Leaving both alive silently is how two Finance dashboards end up reporting two different working-capital numbers from the same underlying transactions, and it is the single most common data-quality complaint that traces back to Data Product catalogue growth rather than to an actual data error.

The Joule angle, September 2026. The SAP Knowledge Graph reads Data Product metadata — owner, lineage, refresh cadence, sensitivity classification — as its grounding substrate, which means the 300-to-500 catalogue race is not only a content story, it is a Joule-capability story. Every net-new Data Product SAP ships is a net-new entity Joule agents and the generative AI hub's orchestration service can ground an answer on without a consultant hand-wiring a semantic model first. Practically: before scoping a Joule agent for a Finance or SCM use case, check whether the domain already has a packaged Data Product, because a domain covered by one converts into a groundable agent in days, while a domain covered only by a raw table or an undocumented custom view forces the project to build the grounding layer by hand — the same 300+ catalogue count that decides a build-vs-buy reporting decision also decides a build-vs-buy AI-grounding decision.

The May 2026 addition of batch inference from SAP AI Core embedded directly into business-ready Data Products (so a tabular-model prediction — SAP-RPT-1.6 as of September 2026, the current generation on the generative AI hub — lands as a field next to the governed data Joule already reads) is the concrete mechanism worth naming to a client: it means a Data Product is no longer only a query target, it can carry a prediction column populated by SAP's own tabular foundation model without a separate MLOps pipeline. For a consultant, the decision worth raising explicitly is whether a given domain's Data Product should be enriched with an AI Core batch-inference column now, or left descriptive until the business case for the prediction is proven — enriching too early adds AI Units cost and a model-refresh obligation nobody has budgeted.

The BDC Modernization Option for SAP BW NetWeaver, open for subscription since September 2026, changes the sequencing question for BW-heavy accounts: it removes the pressure to convert every InfoProvider into a Data Product before AI grounding can start, because the option itself is a bridge, not a forcing function. A pragmatic scoping rule for 2026: convert to Data Products first wherever a Joule use case is already funded, and leave the rest on the Modernization Option bridge until a use case names them.

Why it matters

The consumption pattern is concrete: a consumer queries a Data Product as a first-class object, skipping hand-written joins against raw S/4HANA tables.
The 300-to-500 pace (200 net-new in two quarters) is the stated proof-point that SAP is investing in content depth, not just platform — worth tracking the way BW consultants tracked Business Content releases.
The build-vs-buy rule is explicit: use a packaged Data Product when the standard domain and KPI set match the requirement — build custom Datasphere only when business logic genuinely diverges.

Key points

300+ Data Products confirmed live at Sapphire 2026; the 500+ milestone announced for Q2 2026 has not been confirmed as reached — verify the catalogue count before quoting it.
Domains: Finance (Billing, Cash Flow, Comp) · SCM (Deliveries, Inventory, Mfg Mat, POs) · HR (Headcount) · Service (Cases & Tickets) · Spend · Industry.
Each product: typed schema + KPIs + lineage + governance metadata + data.
Consumers (Joule, SAC, Datasphere) query Data Products as first-class objects — no raw S/4HANA joins needed.
SAP BW Data Product Generator converts BW InfoProviders into Data Products — canonical BW modernization path.
Each Data Product publishes a data contract (owner, refresh cadence, sensitivity classification, consumer list) — that contract, not the schema alone, is what distinguishes it from a shared table.
SAP Knowledge Graph and Joule ground answers directly on Data Product metadata, so a catalogue gap in a domain is also an AI-grounding gap, not only a reporting gap.

Common pitfalls

Treating the 500+ milestone as already reached — Signal: A proposal or demo quotes '500+ Data Products available' without checking the tenant's current release notes. Fix: Quote only the count confirmed live on the tenant or in the current quarter's SAP release notes; label the 500+ figure explicitly as a Q2 2026 target, not a delivered count.
Rebuilding a Data Product that already exists — Signal: A team starts a custom Cash Flow or Headcount Analytic Model without first checking the current Data Product catalogue. Fix: Check the live Data Product catalogue before any custom build — SAP ships net-new products every quarter, and the domain may already be covered.
Letting a custom view silently diverge from a newly shipped Data Product — Signal: Two Finance dashboards report different working-capital numbers because one reads the packaged Data Product and one still reads a legacy custom view. Fix: When a Data Product now covers a domain a custom view used to serve alone, retire the custom view or document explicitly, in writing, why it still diverges.
Scoping AI grounding without checking Data Product coverage — Signal: A Joule agent proposal is scoped for a domain before anyone checks whether a packaged Data Product exists for it. Fix: Treat Data Product coverage as the first grounding-readiness check for any Joule agent scope — an uncovered domain adds a semantic-modelling phase to the agent build, not just to the reporting build.

Decision framework

Decision framework
Decision	Option A	Choose A when	Option B	Choose B when
Is the domain a standard SAP domain already in scope?	Consume the packaged Data Product	Reporting requirements map cleanly to the delivered KPI set; SAP-owned maintenance (schema, lineage, certification) is acceptable.	Build a custom Datasphere view	Business logic genuinely diverges — proprietary calculations, non-standard cost allocation, multi-system blending, or an industry-specific KPI SAP has not packaged yet.
Exploration versus production consumption	Replicate raw S/4HANA tables directly	Initial exploration only, or an operational reporting need no packaged product covers yet and custom modelling has begun.	Consume through the Data Product layer	Production reporting with multiple consumer teams that need a shared, governed contract rather than each re-implementing joins and KPI logic independently.

Facts worth quoting

SAP confirmed 300+ Data Products live in the BDC catalogue at Sapphire 2026, with a 500+ target stated for Q2 2026 — verify the current count against the tenant's own release notes before quoting it (SAP Sapphire keynote coverage, news.sap.com, May 2026).
The BW Data Product Generator is SAP's own shipped path from BW InfoProviders to BDC Data Products, positioned as the canonical BW modernization route rather than a rebuild from scratch (SAP Community, BW modernization blog series, 2026).
SAP's Business Data Cloud Modernization Option for SAP BW NetWeaver opened for subscription in September 2026, giving BW-heavy customers a bridge that does not require converting every InfoProvider to a Data Product first (SAP Community, September 2026).
SAP added batch inference from SAP AI Core embedded directly into business-ready Data Products in May 2026, so a tabular-model prediction can land as a field next to the governed data a Joule agent already reads (SAP Community / SAP News Center, May 2026).

Sources

Open in the app →

Guides that answer with this page

These guides cite this page as one of the sources their answer rests on.