Key Takeaways
- RISE with SAP includes a fixed allocation of BTP credits — typically 1,000–2,500 Cloud Units depending on contract size — which most enterprises exhaust within 12–18 months of serious BTP adoption.
- Standalone BTP licensing gives more flexibility but requires careful capacity planning; the standard BTP capacity unit pricing can be 20–40% higher than RISE bundle equivalents when purchased at low volume.
- SAP's BTP credit consumption model is intentionally complex: different services consume credits at wildly different rates, and SAP provides no real-time visibility dashboard by default.
- 70% of enterprises with RISE contracts never fully activate the BTP services they have, yet SAP counts those unactivated credits as proof of customer value at renewal time.
- Independent BTP licensing review before renewal or migration can identify 25–40% cost reduction opportunities in most enterprise landscapes.
What SAP BTP Actually Is — and Why the Licensing Is Deliberately Confusing
SAP Business Technology Platform (BTP) is SAP's integration and extension platform — the connective tissue that links S/4HANA to cloud services, enables custom app development, supports AI capabilities via SAP AI Core, and powers integration through SAP Integration Suite. In SAP's sales narrative, BTP is positioned as the future of enterprise SAP architecture. In licensing reality, it is one of the most commercially aggressive products SAP has ever packaged.
The complexity is structural, not accidental. SAP BTP operates on a consumption-based model using Cloud Units, capacity units, or service-specific quotas depending on which BTP service you're activating. Each service — Integration Suite, Extension Suite, HANA Cloud, Analytics Cloud, Joule AI — has its own consumption rate and pricing tier. When SAP bundles some of this into RISE, it provides just enough to create dependency without providing enough to run production-grade workloads at scale. The remainder must be purchased separately, at prices SAP negotiates with individual customers.
Our SAP licence optimisation team has reviewed dozens of RISE contracts and standalone BTP agreements. The pattern is consistent: enterprises discover the true cost of BTP 12–18 months into deployment, once committed, locked in, and facing a RISE renewal conversation they're not prepared for.
SAP's standard RISE contract language gives SAP the right to adjust credit consumption rates and service entitlements during the contract term in response to "platform updates." Most legal teams miss this clause. It means the BTP allocation you contracted for can effectively shrink without a formal price change.
SAP BTP in RISE: What's Actually Included
When you sign RISE with SAP, BTP is included as a bundled allocation — not as a separately itemised contract. SAP quotes it in Cloud Units, which is a generic consumption currency that maps to specific services at rates SAP determines. The standard RISE BTP inclusion typically covers:
- SAP Integration Suite — a limited number of integration flows and message volume (commonly 100–500 million API calls/month depending on contract size)
- SAP Extension Suite — basic app development capacity on the SAP BTP Application Runtime (Cloud Foundry environment)
- SAP HANA Cloud — a small shared instance allocation, typically 32GB–128GB of HANA Cloud compute, nowhere near enough for a production HANA Cloud database
- SAP Analytics Cloud — limited user entitlements, often 3–5 full users, insufficient for enterprise reporting at scale
- SAP Joule / AI Core credits — a nominal token allocation for AI feature previews, not production-grade AI workloads
The headline number SAP quotes — "25,000 Cloud Units included" — sounds substantial until you understand that a single production-grade Integration Suite deployment with real enterprise message volumes can consume 8,000–12,000 Cloud Units annually. Add HANA Cloud, SAC, and any extension development and the "included" allocation is gone before the end of Year 1.
RISE BTP: The Dependency Trap
SAP's commercial team understands this mathematics precisely. The BTP inclusion in RISE is sized to create adoption — to get enterprise technical teams building on BTP, creating integrations, training developers — and then to generate an overage conversation at the Year 1 or Year 2 review. At that point you have two choices: pay SAP's top-up pricing (which is significantly higher than the original bundle rate), or reduce BTP usage and accept the operational disruption. Neither is comfortable. Both benefit SAP.
This is not speculation. It is the documented experience of enterprises across manufacturing, financial services, and retail sectors who have engaged our RISE with SAP advisory service. In 8 out of 10 RISE renewals we have supported, BTP overage or top-up licensing was either already a cost item or an imminent one.
Standalone SAP BTP Licensing: How It Works
Standalone BTP — where you license BTP independently of RISE, typically alongside ECC on-premise, S/4HANA on-premise, or a third-party ERP environment — operates on a different commercial structure. Instead of embedded credits within a hyperscaler infrastructure contract, you negotiate BTP capacity directly as a standalone SAP Order Form.
Standalone BTP licensing typically involves three commercial models:
- Subscription-based capacity — annual fixed commitment for a defined volume of Cloud Units or service-specific capacity. Predictable cost, but requires accurate consumption forecasting upfront.
- CPEA (Cloud Platform Enterprise Agreement) — a pre-paid cloud credit pool that can be drawn down across multiple BTP services. CPEA provides flexibility but comes at a premium and requires minimum commitment thresholds (typically $500K+ annual spend).
- Pay-as-you-go (PAYG) — on-demand consumption without commitment. Unit rates are the highest available — typically 3–5x the subscription rate for equivalent consumption. Appropriate only for non-production or experimental workloads.
The key advantage of standalone BTP is negotiating leverage. When BTP is not bundled into a RISE infrastructure deal, you negotiate it as a standalone commercial conversation. You can benchmark rates, bring in third-party analysis, and walk away if SAP's pricing doesn't meet market standards. That leverage disappears when BTP is wrapped inside RISE — because renegotiating BTP means renegotiating your entire cloud ERP contract.
Enterprises with existing ECC or S/4HANA on-premise landscapes who are evaluating BTP for integration or extension use cases should always price standalone BTP before entering RISE conversations. The standalone rate benchmarks give you critical data to evaluate whether the BTP inclusion in RISE is commercially rational for your consumption profile.
SAP BTP in RISE vs Standalone: Side-by-Side Comparison
The table below summarises the key commercial and operational differences between BTP as included in RISE versus BTP purchased as a standalone licence. This comparison is based on our direct review of enterprise contracts across both models.
| Factor | BTP in RISE | Standalone BTP |
|---|---|---|
| Commercial structure | Embedded in RISE Order Form; credits allocated as part of hyperscaler bundle | Separate SAP Order Form; direct capacity or CPEA pool |
| Negotiation leverage | ⚠ Low — BTP repricing requires renegotiating RISE contract | ✓ High — standalone conversation with clear benchmarks |
| Credit expiry | ✗ Typically expire annually; unused credits do not carry forward | ⚠ Varies by agreement; CPEA credits may have 3-year horizon |
| Consumption visibility | ✗ Limited dashboard access; SAP controls reporting cadence | ⚠ Improved but still requires proactive monitoring via BTP cockpit |
| Overage risk | ✗ High — embedded allocation typically insufficient for production scale | ✓ Lower if properly sized; subscription model caps exposure |
| Service coverage | ⚠ Pre-defined service bundle; expanding to new services requires change order | ✓ Flexible; CPEA pool can be directed to any BTP service |
| Renewal risk | ✗ Very high — BTP dependency embedded in RISE renewal leverage | ⚠ Moderate — SAP will negotiate hard but you retain walk-away option |
| Typical cost efficiency | ⚠ Appears low-cost initially; true cost emerges at overage/renewal | ✓ Higher upfront transparency; easier to benchmark and right-size |
The Credit Consumption Problem: What SAP Doesn't Tell You
SAP BTP Cloud Unit consumption is one of the least transparent aspects of SAP licensing. The SAP BTP Service Description — a document SAP publishes but rarely highlights during sales conversations — contains the service-specific consumption rates that determine how quickly your credits are depleted. Here is what that document reveals for key services:
- SAP Integration Suite — message processing rates vary by tier. At the "Standard" tier, each processed message consumes credits at a rate that, for a mid-size enterprise processing 10 million messages/month, exhausts approximately 4,000–6,000 Cloud Units annually.
- SAP HANA Cloud — a single production-grade HANA Cloud instance (64 vCPUs, 1TB memory) consumes roughly 8,000–12,000 Cloud Units/year. The "included" HANA Cloud allocation in most RISE contracts covers test environments only.
- SAP Analytics Cloud — SAC is priced per active user per month. The typical RISE-included allocation covers 3–5 full users. Scaling to 50 enterprise users requires substantial additional licensing.
- SAP AI Core / Joule — AI token consumption varies enormously by use case. Production-grade AI inference workloads can consume token allocations in days if not carefully governed.
The practical consequence is that enterprises often enter RISE believing they have "SAP BTP included" as a production platform. They do not. They have a development and prototyping allocation that creates dependency without providing production-grade capacity. Our SAP licence optimisation service regularly quantifies this gap during pre-renewal analysis — and the findings consistently show enterprises are carrying 40–60% BTP costs that were invisible at contract signature.
The Unused Credits Paradox
Here is the counter-intuitive reality that makes BTP licensing particularly complex: many enterprises simultaneously over-consume some BTP services while leaving others entirely untouched. SAP's own data indicates 70% of RISE customers never activate the full range of BTP services included in their contract. Yet SAP cites this breadth of "included services" as evidence of contract value at renewal time, even when those services were never used.
This creates a negotiating disadvantage. When you have not consumed all your BTP credits, SAP's commercial team argues that the inclusion was generous and any renewal price increase is justified by expanded capabilities you "could have used." When you have over-consumed, SAP argues you clearly need more capacity and any reduction request is commercially unreasonable. The asymmetry is designed-in. Both outcomes generate revenue for SAP.
SAP's RISE contract metering terms give SAP the right to conduct technical consumption reviews against your BTP usage data. In practice, this means SAP has detailed visibility into your BTP consumption profile before entering renewal negotiations — data you may not have organised in equivalent analytical form. This information asymmetry is a significant commercial disadvantage.
When to Choose RISE BTP vs Standalone: Decision Framework
The choice between accepting BTP as embedded in RISE or licensing it standalone is not purely a cost question — it depends on your consumption profile, migration timeline, and commercial risk appetite. Here is the framework we use with enterprise clients:
Choose RISE-embedded BTP if:
- You are a net-new SAP customer with limited existing integration architecture and plan to build on BTP from scratch
- Your initial BTP use case is limited to basic Integration Suite for cloud-to-cloud connections (low volume, under 5 million messages/month)
- Your contract negotiations secured a significantly above-average BTP allocation — specifically, at least 3x the standard inclusion — with contractual caps on consumption rate adjustments
- You have negotiated overage protections with hard caps on Year 1–2 top-up pricing locked into the RISE Order Form
Choose standalone BTP if:
- You are running S/4HANA or ECC on-premise and evaluating BTP for integration or extension use cases without committing to RISE hyperscaler infrastructure
- Your consumption profile includes HANA Cloud at production scale, high-volume Integration Suite, or significant Analytics Cloud user requirements
- You want to maintain commercial separation between your ERP contract and your platform/integration contract to preserve renewal leverage in each
- You are operating in a regulated environment where cloud data residency or contract governance requirements make bundled hyperscaler agreements problematic
Our RISE with SAP advisory team has helped enterprises across both paths. The most consistently successful outcomes involve clients who conducted a BTP consumption modelling exercise before entering any commercial conversation — translating actual integration and extension roadmaps into credit consumption forecasts and benchmarking those against both RISE inclusion and standalone pricing.
Negotiation Tactics: Getting the Right BTP Structure in Your Contract
Whether you are entering a new RISE contract, approaching renewal, or considering standalone BTP, the following negotiation principles apply. These are drawn from our direct experience in over 50 enterprise SAP BTP licensing negotiations.
1. Itemise BTP allocations in the Order Form
Never accept BTP as a bundled credit number in RISE. Demand that each service allocation be explicitly itemised: Integration Suite capacity (by tier and message volume), HANA Cloud compute (by vCPU and memory allocation), SAC users (by type — full vs viewer), Extension Suite runtime (by memory and CPU). If SAP refuses to itemise, that is a strong signal the allocation is insufficient for production use.
2. Lock in consumption rate stability
Include a clause requiring SAP to provide 12 months' written notice before changing the Cloud Unit consumption rates for any BTP service included in your contract. SAP will resist this, but it is achievable for enterprise clients with leverage. Without it, SAP can effectively reduce your BTP capacity mid-contract by adjusting consumption rates.
3. Negotiate carry-forward provisions
Standard RISE BTP credits expire annually. Negotiate a 30–50% carry-forward provision — unused credits that roll into the following year — to reduce the pressure to over-consume before year-end. SAP offers this to enterprise clients at premium tiers; it is rarely offered proactively.
4. Secure a BTP right-sizing review
Include a contractual provision for a BTP consumption review at the 12-month mark with the right to adjust (upward or downward) the allocation for Year 2 based on actual usage data, at Year 1 unit rates. This protects against both over-consumption and under-utilisation penalties.
For more detailed negotiation tactics specifically designed for the BTP-in-RISE context, see our companion guide: SAP BTP in RISE vs Standalone: Negotiation Tactics.
Independent BTP Licensing Review
Don't Let SAP Define What "Included" Means
Our SAP BTP licensing review gives you an independent consumption forecast, credit modelling, and negotiation brief — so you enter every SAP conversation knowing exactly what you need and what you should be paying.
Book a Free Consultation →The Hyperscaler Variable: AWS, Azure, GCP and BTP Costs
One dimension of BTP cost that enterprises frequently underestimate is the hyperscaler infrastructure cost embedded in RISE. RISE with SAP runs on your chosen hyperscaler (AWS, Azure, or GCP), and while SAP manages the infrastructure layer, the underlying compute and storage costs are factored into your RISE contract price. BTP services in RISE run on the same hyperscaler, meaning BTP consumption drives both SAP credit depletion AND underlying infrastructure utilisation.
Standalone BTP can run on the same hyperscaler environment as your on-premise connectivity infrastructure, potentially at lower effective cost if you already have committed hyperscaler spend through AWS, Azure, or GCP enterprise agreements. Some enterprises have successfully negotiated BTP capacity as part of broader hyperscaler commitment packages — effectively reducing the unit cost of BTP by consuming it against existing cloud credits rather than through a separate SAP agreement.
This is a sophisticated commercial strategy that requires coordination between your SAP licensing, cloud architecture, and procurement teams — which is exactly why enterprises engaging our SAP licence optimisation service achieve materially better outcomes than those negotiating in siloed functional teams.
Case Study Reference: Manufacturing Enterprise, BTP Restructuring
A European manufacturing enterprise with 28,000 SAP users approached us 8 months into their RISE deployment. Their BTP credits — nominally "included" in RISE — were 70% depleted after activating Integration Suite for 15 integration flows and a modest HANA Cloud development environment. SAP's commercial team was preparing a top-up proposal at rates 35% above their original contracted price.
Our analysis found that three of their Integration Suite flows were running at the Standard tier when they qualified for the lower-cost Basic tier. Additionally, their HANA Cloud environment had been over-provisioned during initial setup and was running at 40% utilisation. By right-sizing both services, we identified 28% immediate credit recovery — enough to eliminate the overage. We then negotiated a contractual carry-forward provision and Year 2 consumption rate stability clause, saving the client approximately €1.4M in projected BTP costs over the RISE contract term. See our full case studies for similar enterprise outcomes.
Hidden Cost Layers: What the Contract Doesn't Highlight
Beyond credit consumption, SAP BTP licensing contains several secondary cost layers that consistently surprise enterprise finance and procurement teams. For a full breakdown, see our dedicated guide: SAP BTP in RISE vs Standalone: Hidden Costs Explained. The most common are:
- Implementation and activation costs — SAP BTP services require configuration effort that SAP typically scopes through its partner ecosystem. Implementation costs for a production Integration Suite deployment range from €150K to €400K depending on complexity.
- Custom domain and certificate costs — running BTP applications on custom domains requires additional configuration and periodic certificate management, typically charged through the BTP cockpit.
- Support tier uplift — activating production BTP services often triggers a requirement to upgrade from Standard SAP Enterprise Support to Premium Engagement or equivalent, adding 2–4% to your annual support bill.
- Training and enablement — SAP BTP is architecturally distinct from SAP's traditional on-premise technology stack. Most enterprise teams require significant retraining investment, often €50K–€200K for mid-size implementations.
- Third-party integration costs — connecting non-SAP systems through Integration Suite may require third-party adapters sold separately through the SAP Store, with their own subscription pricing.
Preparing for BTP Renewal: What to Do Before SAP Calls
The most powerful moment in any BTP commercial cycle is the 6–12 months before renewal — before SAP has initiated its sales process and before your internal teams are distracted by year-end pressures. Use this window to:
- Conduct a full BTP consumption audit using BTP cockpit data and SAP for Me reporting
- Model Year 2–3 consumption based on your technical roadmap, not just current usage
- Benchmark your current Cloud Unit rates against market equivalents using independent data
- Identify services in your RISE bundle that you are not using and can be removed or traded for more of what you need
- Prepare your alternative: document what a standalone BTP agreement would cost and whether your current RISE structure can be unbundled
Our SAP licence optimisation and contract negotiation services cover all of these steps as a structured engagement, typically initiated 9–12 months before RISE or BTP renewal. Enterprises that engage this process consistently achieve 20–40% better outcomes than those who begin negotiating after SAP's commercial team has already presented their renewal proposal. Learn more about our approach in the RISE with SAP Evaluation Guide.
The Future of BTP Licensing: What to Watch in 2026
SAP's strategic direction is unambiguous: BTP is the platform on which SAP intends to generate the majority of its cloud revenue growth over the next five years. This commercial priority will drive several licensing developments enterprise buyers should monitor:
- AI-driven consumption acceleration — SAP Joule and AI Core are being positioned as must-have capabilities in RISE renewals. AI workloads consume BTP credits at significantly higher rates than integration or extension workloads. Expect SAP to push AI feature activation aggressively at renewal, with the predictable consequence of credit exhaustion and top-up requirements.
- CPEA restructuring — SAP has signalled changes to the CPEA (Cloud Platform Enterprise Agreement) model that will affect how enterprise clients pre-purchase BTP capacity. Independent tracking of these changes is essential for enterprises with CPEA agreements approaching renewal.
- Unified cloud licensing convergence — SAP is progressively moving toward a "unified cloud" licensing model that blurs the boundary between RISE infrastructure costs and BTP application costs. Enterprises should resist any contract structures that make this separation ambiguous, as it will complicate future BTP-specific negotiations.
Frequently Asked Questions: SAP BTP in RISE vs Standalone
Independent SAP Licensing Advisory
BTP optimisation, RISE advisory, licence right-sizing — buyer-side only, zero SAP affiliation.
Explore All Services → Case StudiesReal Results for Enterprise Buyers
See how we've helped enterprises cut SAP BTP costs by 25–40% and win RISE renewal negotiations.
Read Case Studies →Independent SAP licensing advisory — not affiliated with SAP SE. SAP, S/4HANA, RISE with SAP, and SAP BTP are trademarks of SAP SE. All analysis is based on independent review of enterprise contracts and publicly available SAP licensing documentation.