Analytics Legends The knowledge platform for SAP Analytics
Guide

SAP Analytics Cloud licensing: the entitlement decisions that set the bill

As of 2026-08-14

Licensing SAP Analytics Cloud is an entitlement design, not a procurement exercise. Three decisions carry nearly all the cost and all the audit exposure: who gets a planning seat rather than a BI seat, whether stories are embedded in another application, and what platform sits underneath. Get the first wrong and you pay two to three times more per user for people who will never type a number into the tool.

The tier split is the whole decision

SAC's licence families divide along the one capability that separates it from a BI tool: write-back. A BI seat reads. A planning seat reads and writes into a multi-version, audit-trailed model, and commonly costs two to three times as much per user.

The design rule follows. Licence BI broadly for consumption, and scope the planning tier to the population that genuinely needs write access — in a typical large enterprise, roughly fifty to two hundred finance and planning users rather than the whole analytics base.

The reason to be strict is not only budget. Every planning-licensed user is a potential source of version tampering that then has to be governed: access controls partitioning the planning area, locks at version, member or measure granularity, and an approval trail that survives an audit. Entitlement you do not grant is control you do not have to build.

Decision table — which entitlement fits which person

Reads dashboards, never enters a number → a BI consumption seat → the large majority of the population; keep it that way deliberately.

Builds stories and models for others → a BI authoring entitlement → the design population, which needs governance training more than tooling.

Enters a forecast, budget or driver → a planning seat → the expensive tier; the test is whether they type a number and expect it saved.

Approves a plan version without entering data → still a planning seat in practice → approval is a state transition on a version, and the trail records it as one.

Consumes a story inside another application → embedded deployment, a separate licence → an iframe and a JavaScript API, not a setting on an existing seat.

Consumes on a phone or tablet → no separate entitlement, but a design cost → the native client serves the same content; what changes is whether the story has a mobile layout worth opening twice.

What the licence does not cover

The platform underneath is a separate commercial model. SAC bills separately from Datasphere capacity, and Business Data Cloud is quote-only on a capacity-unit basis. An entitlement plan that does not state what sits below it is incomplete, because the connection mode changes how hard that layer works.

Extensibility is your maintenance, not SAP's. A custom widget is a JavaScript bundle your organisation now owns and each SAC release can break it; a scripted analytic application is developer-owned code nobody else can safely change. Neither appears as a licence line, and both appear in every release cycle.

Reviewing an existing SAC estate

Start with the write population and compare it to the planning entitlements issued. The common finding is planning seats held by people who have never opened a planning model, granted during a rollout before the tier distinction was visible.

Then inventory connections. Imported models should be a small minority of the catalogue, each with a documented reason and a quarterly review retiring the unused. An imported model nobody remembers is both a stale-data risk and an access gap.

Then inventory the extensibility surface: every custom widget and scripted application, with a named owner and a note on when it was last tested against a release. Anything unowned is a scheduled outage.

What we cannot assert

SAP publishes no authoritative licence price list for SAC, and the names and boundaries of its commercial tiers change between contract cycles. We describe the entitlement decisions that hold across those changes — write access, embedding, platform layer — and publish no per-tier price.

Frequently asked

What is the difference between an SAC BI licence and a planning licence?

A BI licence reads; a planning licence writes into a multi-version, audit-trailed model. The planning tier commonly costs two to three times as much per user, which is why the practical test for granting one is whether the person types a number into the tool and expects it saved.

How many planning licences does a large enterprise actually need?

In a typical tier-one deployment the write population is roughly fifty to two hundred finance and planning users, not the whole analytics base. Granting more wastes budget and widens the governance surface, since every planning-licensed user is a potential source of version tampering.

Is embedding SAC content in another application covered by a normal licence?

No. Embedding stories inside a portal, a CRM or a collaboration tool is a separately licensed deployment delivered via an iframe and a JavaScript API. Plan it as its own line and its own design problem rather than a configuration of an existing seat.

What this page is built on

Read next