SAP Analytics Cloud (SAC) combines planning, business intelligence, and predictive analytics in a single cloud platform. Yet its licensing model creates significant complexity for enterprise buyers. Understanding SAC user types, capacity limits, RISE entitlements, and competitive positioning is essential for controlling costs and negotiating effectively.
SAP Analytics Cloud is SAP's unified cloud analytics platform, consolidating business intelligence (BI), planning, predictive analytics, and data visualisation in a single tool. It serves as the successor to legacy SAP BI tools like BusinessObjects and the analytics layer for organisations adopting S/4HANA or RISE with SAP. SAC handles three distinct but overlapping workloads: descriptive analytics (dashboards, reports, ad-hoc queries), planning and budgeting (financial and operational planning), and predictive analytics (forecasting, scenario modelling, AI-driven insights).
This multi-workload architecture means SAC is licensed differently from point BI tools like Tableau or Power BI, which focus primarily on analytics and reporting. SAC's planning capabilities, embedded AI models, and story/model lifecycle create a more complex pricing framework. For organisations coming from legacy BI (BusinessObjects, Crystal Reports) or planning tools (SuccessFactors Planning), SAC represents both a capability upgrade and a licensing shift.
This guide is part of our comprehensive SAP license negotiation guide. For SAC in the context of RISE, see our RISE with SAP review. For SAC's role in the broader analytics architecture, our BTP licensing guide covers SAC as a BTP service and its credit consumption model.
SAP Analytics Cloud is licensed on a combination of user seats and capacity metrics. The user component is straightforward: you purchase named user seats, each of which grants access to the SAC environment for one individual. The capacity component is more complex: beyond your user seat allocation, SAC imposes limits on the number of stories (dashboards/reports) and models (planning artefacts) you can create, and additional capacity triggers additional charges.
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
Unlike many enterprise software licensing models where overage simply means paying at-risk or on-demand rates, SAC capacity overages are often discovered during true-up or renewal and result in retroactive charges for the period in which the overage occurred. This makes capacity planning during the sales process critical.
SAC users are licensed as named seats. Each seat represents one individual with permanent access rights to SAC. Seat types vary by use case — Business Intelligence users for analytics consumers, Planning users for budget/forecast contributors, Predictive users for advanced analytics, and Administrative users for content creation and system maintenance. Organisations typically need a mix of these seat types depending on their analytics footprint.
SAC seat licenses are annual subscriptions. Unlike perpetual enterprise software licensing, there is no option to purchase SAC as a one-time licence; you must renew annually or lose access. This subscription model means SAC is a recurring operational cost, and renewal is mandatory regardless of usage levels.
Beyond user seats, SAC imposes limits on the number of analytics objects (stories and models) you can create. A "story" is a dashboard, report, or analytical narrative — essentially any published analytics artefact that a user views. A "model" is a planning object (budget, forecast, or scenario model). Each SAC user seat tier comes with an included allocation of story and model slots. For example, a Business Intelligence user seat might include 500 story slots. If your organisation creates 750 stories, you have exceeded your allocation by 250 stories and must purchase additional story capacity or delete existing stories.
This capacity model creates significant cost surprise risk. Organisations that adopt SAC aggressively, empowering business users to self-serve analytics, routinely exceed their initial story and model allocations within 6–9 months and discover large additional charges at year-end true-up or renewal.
BI users consume analytics — they view dashboards, run reports, and perform ad-hoc analysis. They cannot create or modify stories or models. BI users are the largest segment in most deployments. Pricing is annual per-user-seat. This is the entry-level SAC user tier.
Planning users create and modify budget and forecast models, contribute data to planning cycles, and perform scenario analysis. Planning users have higher capability scope than BI users and are typically higher-priced on a per-seat basis. The number of planning users is usually much smaller than BI users — typically 5–15% of total user count.
Predictive users have access to SAC's advanced analytics capabilities — time series forecasting, statistical models, machine learning features, and scenario simulation. In most organisations, predictive users are a small, specialised population (data scientists, advanced analysts). Predictive user seats are premium-priced relative to standard BI seats.
Administrative users manage SAC system configuration, security, metadata, and content governance. Most organisations need only 2–4 admin users regardless of size. Admin seats are typically priced similarly to Planning users and include elevated story and model allocations.
A representative enterprise SAC deployment might have 1,000 total users distributed as: 850 BI users, 120 Planning users, 20 Predictive users, and 10 Admin users. BI users represent the bulk of seats but the lowest per-seat cost. Planning and Predictive users represent smaller populations but higher per-seat cost. This distribution directly affects your SAC subscription cost and your ability to add analytics capability across the organisation cost-effectively.
SAC's story and model limits are often the source of the largest licensing surprises. Understanding these limits and planning for overages is critical.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
Each SAC user tier comes with an included allocation of story slots and model slots. For Business Intelligence users, a standard allocation might be 500 story slots per seat (meaning 1,000 BI users would have 500,000 total available story slots). Models are allocated at lower volumes — typically 100 model slots per Planning user. When you exceed these allocations, you must either delete existing artefacts to free up slots (operationally disruptive) or purchase additional capacity from SAP.
Many organisations discover their story/model overages only at annual renewal or audit. The contractual language governing how this is billed varies — some agreements explicitly allow unlimited stories/models under the assumption of tiered pricing, while others strictly cap them and charge significant overage fees. Clarify this before signing.
Stories accumulate over time. Organisations that aggressively adopt self-service analytics can easily create hundreds of stories per year. Templates that business units use to create variants (e.g., "Sales by Month" for each region or product line) multiply story count rapidly. If you start with 1,000 BI users at 500 stories each (500,000 total available slots) and create 60,000 new stories per year, you will reach full capacity within 8–9 months.
The practical solution is either to size your initial user allocation to account for story inflation (which increases cost upfront) or to negotiate an "unlimited stories" clause in your SAC contract, which SAP will accept for large accounts but typically at a higher per-seat price.
Model capacity is less of a day-to-day issue than story capacity but matters significantly during planning cycles. A typical annual financial planning cycle might generate dozens of model versions (e.g., base plan, best case, worst case, sensitivity analyses). Quarterly revisions multiply this. A Planning user allocation of 100 models per Planning user seat is typically sufficient for standard financial planning, but organisation-wide scenario modelling or heavy operational planning can exhaust this quickly.
| User Tier | Typical Story Allocation | Typical Model Allocation | Cost of 10% Overage |
|---|---|---|---|
| BI User (500 users) | 500 per user (250K total) | N/A | $15K–25K/year |
| Planning User (100 users) | 500 per user (50K total) | 100 per user (10K total) | $8K–15K/year |
| Predictive User (20 users) | 500 per user (10K total) | 100 per user (2K total) | $5K–10K/year |
| Admin User (5 users) | 1000 per user (5K total) | 500 per user (2.5K total) | Typically included |
Organisations upgrading from legacy SAP BI (SAP BW) face a choice: continue with SAP BW/4HANA or migrate to SAP Analytics Cloud. This is not purely a technology decision — it has significant licensing implications.
SAP BW/4HANA is a data warehouse and BI platform hosted on SAP HANA. It is licensed on a perpetual software basis (purchase once, support annually) or as a cloud subscription. SAC is a cloud-only, subscription-based analytics platform. The licensing cost profile is fundamentally different.
SAP BW perpetual licenses are purchased upfront and amortised over multi-year useful life. Support costs are 22% of license cost annually. SAC is a pure subscription — monthly or annual charge, no upfront licence purchase, support included. For organisations with large data warehouse teams, perpetual BW is typically cheaper than SAC over a 10-year horizon, but this depends heavily on concurrent user count and support intensity.
For organisations with smaller BI populations (under 100 concurrent BI users), SAC's subscription model is often cheaper. For large populations (1,000+ analytics consumers), the perpetual BW licence frequently becomes more cost-effective, especially if the organisation already owns it.
SAC's planning capabilities (budgeting, forecasting, scenario analysis) are better integrated with the BI platform than BW/4HANA. If planning is a significant workload, SAC simplifies tool consolidation — you use one platform for BI and planning rather than two (BW for BI, SuccessFactors Planning for budgeting). This consolidation can reduce the total analytics tool cost despite SAC being more expensive than BW per user.
Conversely, if your analytics workload is purely BI (no planning), and you have large concurrent user populations, BW/4HANA often remains the more economical choice.
The decision between BW and SAC should include a 5–10 year total cost of ownership (TCO) model comparing: perpetual BW licence cost + annual support, versus SAC subscription cost growth with annual user expansion. Add in the cost of planning tool redundancy if you stick with BW (requiring a separate planning tool). For most organisations, this TCO analysis reveals the true cost advantage.
SAP does not compete in BI purely on SAC merits — it competes against Microsoft Power BI and Tableau. Understanding this competitive dynamic is essential for negotiating SAC pricing.
Power BI and Tableau are cheaper on a per-user basis and more widely used in the market. Microsoft has bundled Power BI with Microsoft 365 and Azure, making it nearly free for organisations that standardise on Microsoft. Tableau is premium-priced but offers superior self-service analytics and dashboard capability, justifying its cost premium to many business-focused buyers.
SAC's value proposition over Power BI is planning capabilities (Power BI is analytics-only) and SAP integration (SAC is optimised for SAP data sources). Its value proposition over Tableau is RISE bundling, native SAP data connectivity, and embedded planning. Neither is compelling enough for SAP to ignore market pricing pressure.
If your organisation is evaluating SAC against Power BI or Tableau, use this explicitly in SAC negotiations. The talking points are straightforward: "We can deploy Power BI for [X per-user cost], so SAC must deliver [Y planning value] to justify [higher cost]. Help us see how we get value at [target cost]." SAP sales teams understand this dynamic and have authority to discount SAC when competitive pressure is credible.
The most effective negotiations include a detailed ROI model for planning consolidation. If you're replacing a legacy planning tool with SAC, quantify the operational savings: headcount reduction in planning teams, faster planning cycles, reduced spreadsheet errors, improved scenario capability. Present this as justification for SAC investment at the price point you're targeting.
SAC is often bundled as part of RISE with SAP. If you're negotiating a RISE contract, SAC is bundled and its per-user cost is already built into your RISE price. In this context, demanding SAC cost transparency is pointless — it's a standard RISE entitlement. However, if you're negotiating additional SAC seats beyond the RISE included allocation, competitive pressure (Power BI/Tableau alternatives) becomes relevant again.
RISE with SAP includes SAP Analytics Cloud as a standard entitlement. The size and scope of this inclusion is negotiable, but SAP's standard RISE SAC entitlement is sized conservatively and often insufficient for organisations with significant analytics workloads.
SAP's standard RISE SAC inclusion typically covers: 500–1,000 Business Intelligence user seats, 50–100 Planning user seats, 10–20 Predictive user seats, and a standard allocation of stories and models. For many organisations, especially those with analytics ambitions beyond financial planning, this baseline is undersized.
The best practice is to conduct a pre-RISE analytics user survey before committing. Identify: (1) Current BI users across the organisation (who views reports and dashboards today?), (2) Potential new BI users (who should have analytics access under the new system?), (3) Planning contributors (how many people contribute to budgets and forecasts?), (4) Advanced analytics needs (predictive analytics, data science use cases). Build a 3–5 year user expansion model. Then negotiate RISE SAC allocations that cover your Year 1 needs and allow for user expansion at no additional per-user cost (or at a negotiated rate) in Years 2–5.
The story and model limits within RISE SAC are often extremely tight — smaller than if you licensed SAC standalone. This is a point of frequent contention. Negotiate explicit overage allowances or "unlimited" stories/models clauses for RISE SAC. Given that RISE is already a large contract, SAP has commercial flexibility here and will often agree to unlimited stories/models as part of the overall RISE package rather than nickel-and-diming you on story overages post-signature.
SAC can be licensed as a standalone subscription or as a service within SAP BTP. When licensed through BTP, SAC consumption is measured in BTP credits rather than per-user-seat subscription fees. This creates a pricing arbitrage: for some use cases, BTP-based SAC pricing is cheaper than standalone SAC; for others, it is more expensive. Understanding which applies to your situation is important.
Standalone SAC is priced as an annual per-user subscription: BI users at [X], Planning users at [2X], Predictive users at [3X]. BTP-based SAC consumes credits at a rate that depends on user count, session duration, and analytics complexity. The credit model can be more economical for organisations with lower analytics intensity (fewer concurrent sessions, lighter workloads) but becomes less economical for heavy analytics consumers with continuous dashboard access.
If you have a large Planning user population running complex planning models simultaneously, standalone SAC is typically cheaper. If you have a smaller BI population with light dashboard usage, BTP credit-based pricing might be better. The only way to know is to model both approaches against your expected usage.
Uncertain whether standalone SAC or BTP-based SAC is right for your analytics roadmap?
Organisations often purchase Planning user seats assuming a broad population will participate in planning cycles. In reality, 80–90% of planning work is done by 20–30 people in finance, supply chain, and operations. The rest of the organisation contributes data or approves allocations but doesn't need a full Planning user seat. Negotiate Planning users down aggressively; you can always add more at year-end if uptake exceeds expectations.
Self-service analytics always generate more content than forecast. Teams create variants of dashboards for each region, product, customer, and metric combination. Overages at year-end true-up are common. Budget for 50% more story capacity than you think you'll need, or negotiate unlimited stories into your contract.
SAC uses data from various sources: S/4HANA, SAP Data Warehouse Cloud, external data connectors, etc. Some of these data integrations incur additional data acquisition or connectivity charges in SAC's commercial terms. Review the service description for any hidden data ingestion costs that might not be bundled in your user seat price.
SAC's predictive analytics and Joule (SAP's generative AI copilot) are not always included in base SAC seats. Some advanced analytics features require additional "Joule add-on" or "Predictive add-on" subscriptions. If your analytics roadmap includes these capabilities, budget for add-on pricing explicitly.
Using SAC embedded in custom applications or accessing SAC via mobile apps sometimes triggers different licensing models. If you plan mobile consumption or app embedding, clarify the licensing model with your SAP representative — it may not be covered under your standard seat count.
SAC is licensed on named users, not concurrent sessions. You cannot purchase a small number of "concurrent user" licences for a large population sharing seats. Each individual who accesses SAC must have their own named user seat. This is important for organisations considering "shared access" models.
Organisations that purchase standalone SAC before committing to RISE often find that SAC pricing drops significantly as part of RISE (due to bundling), but the pricing change happens at RISE signature and may not be retroactive. Plan your SAC/RISE timing carefully to avoid double-paying for overlapping periods.
Get pricing and feature comparison from Microsoft Power BI (per-user or through Microsoft 365) and Tableau. Present this to SAP explicitly: "We have evaluated Power BI at [cost], Tableau at [cost]. For SAC to be the winner, it must deliver [planning/integration value] at [target price]. What's your best SAC pricing?" SAP understands this dynamic and will respond with discounts if your competitive alternative is credible.
Don't accept SAC contracts with capped story/model limits unless you are absolutely confident in your forecast. Negotiate "unlimited stories and models" or at minimum a "true-up at year-end with no retroactive overage charges" clause. The first option is preferable; the second reduces your overage risk if unlimited is not available.
Start with conservative Planning user counts (typically 10–15% of BI users). Negotiate a provision to add Planning users at a discounted rate at any point during the contract period. This saves money Year 1 while preserving flexibility to expand planning scope if adoption is higher than expected.
If SAP is pushing Joule (generative AI) or Predictive analytics add-ons, defer them to Year 2 or 3. These are emerging capabilities, and starting without them allows you to evaluate demand within your organisation before committing to add-on cost. This also gives you renegotiation leverage at Year 2 renewal if adoption is lower than SAP expects.
Request SAP's benchmarking data on stories and models per BI user across similar-sized organisations. Most enterprises operate at 50–100 stories per BI user on average. If SAP is offering you 500 stories per user, press them on whether this is above or below industry norms. Use benchmarking to justify aggressive story/model limits in your contract.
If you are committing to RISE, bundle SAC into RISE rather than licensing it separately. RISE bundles reduce per-user costs compared to standalone SAC pricing due to volume discounts and bundling efficiency. However, only do this if you have modelled the RISE SAC allocation and confirmed it covers your Year 1–2 requirements.
For multi-year SAC deals, negotiate that additional user seats purchased in Year 2, 3, or beyond are available at the Year 1 negotiated per-user price (or at a specified escalation rate). This prevents SAP from hiking per-user prices at renewal and gives you cost certainty for user expansion without renegotiation.
Don't sign a SAC contract without explicit story and model limits, competitive benchmarking, and a 3–5 year user forecast. The difference between a well-negotiated SAC deal and an oversized one is hundreds of thousands of dollars.