Calculating Capacity Units and Cloud Credits in SAP BTP: A Practical Enterprise Guide

Why SAP BTP Pricing Is the Most Misunderstood Cost in Enterprise SAP Contracts

SAP BTP (Business Technology Platform) has become the architectural layer through which SAP delivers its Clean Core strategy — the migration of custom developments, integrations, and extensions out of the core SAP ERP system and into BTP-hosted services. As RISE with SAP migrations proceed across the enterprise SAP market, BTP consumption costs have emerged as the most consistently underestimated cost category in SAP commercial planning.

The reason is structural: BTP credits are consumed based on actual service usage, not contracted seat counts. This makes BTP costs simultaneously difficult to predict, easy to underestimate at contract signing, and potentially very expensive once consumption scales post-go-live. Enterprise IT and procurement teams accustomed to per-user SAP pricing need a different analytical framework to plan, negotiate, and govern BTP costs.

BTP overages typically run at $1.00–$1.20 per capacity unit versus $0.50–$0.70 contracted — a 60–80% premium that compounds quickly once consumption scales. Understanding how BTPEA and CPEA commercial models differ, how to model credit burn rates before go-live, and how to use BTP as a lever in broader SAP negotiations is what separates organisations that control their BTP spend from those that get invoiced into submission. Redress Compliance operates as SAP commercial advisory specialists with specific expertise in BTP commercial modelling across 500+ enterprise engagements.

What Are SAP BTP Cloud Credits?

SAP BTP cloud credits are prepaid digital currency used to pay for SAP BTP services. One cloud credit corresponds to approximately USD 1.00 at list price and can be spent on any eligible BTP service. Credits are purchased upfront as part of a BTP commercial agreement and consumed as services are activated and used.

The credit model exists because BTP offers over 100 services spanning integration (SAP Integration Suite), extension development (SAP Build), data management (SAP Datasphere, SAP HANA Cloud), analytics (SAP Analytics Cloud), AI (SAP Joule), automation (SAP Build Process Automation), and identity management — each with its own pricing metric, consumption rate, and capacity unit definition. Credits provide a unified currency across this diverse service landscape.

The commercial implication: a company that commits to USD 500,000 in BTP credits per year has a credit pool that can be allocated across any combination of BTP services. If the allocation is not planned carefully against actual service requirements, the pool will either be exhausted prematurely (triggering overage billing) or consumed unevenly (with some services starved for capacity while unused credits expire in other buckets).

What Are Capacity Units?

Capacity units (CUs) are a lower-level consumption metric used within specific BTP services to measure resource consumption. A capacity unit is a ratio of services consumed via the cloud service, calculated as defined in the relevant Product Supplement, Service Description Guide, or Service Use Description for each service.

In practice, different BTP services use different capacity unit definitions. For SAP HANA Cloud, capacity units measure memory and compute resources provisioned in the database layer. For SAP Integration Suite, capacity units measure message volume and integration flow execution. For SAP Build Process Automation, capacity units measure workflow execution and robotic process automation task runs. For SAP Analytics Cloud, capacity units relate to story executions and planning model complexity.

The mapping between capacity units and cloud credits varies by service. Each BTP service publishes a credit conversion rate in SAP's Discovery Centre — the number of credits consumed per capacity unit per time period. Understanding this conversion rate for each service you plan to use is the foundation of accurate BTP cost modelling.

The Two BTP Commercial Models: CPEA and BTPEA

SAP currently operates two consumption-based commercial models for BTP: CPEA (Cloud Platform Enterprise Agreement) and BTPEA (BTP Enterprise Agreement). Understanding the difference is essential for any enterprise entering a BTP commitment.

CPEA: Cloud Platform Enterprise Agreement

CPEA is the older of the two models. It provides access to SAP BTP services and a range of other SAP cloud services within a single credits pool. CPEA credits can be spent across BTP services and some SAP cloud applications, making it the more flexible model for organisations that consume both BTP platform services and SAP cloud line-of-business applications through a single commercial pool.

CPEA minimum commitment is typically USD 150,000 per year, with discounts scaling at higher commitment tiers. Credit overage under CPEA is invoiced monthly at list price — typically 30 to 40% above the effective rate of the committed credit tier.

BTPEA: BTP Enterprise Agreement

BTPEA was introduced in 2024 as a refined version of CPEA focused exclusively on SAP BTP services. BTPEA provides a dedicated BTP credit pool without the wider cloud application scope of CPEA. For organisations whose primary consumption is BTP platform services (integration, extension, analytics, data management) rather than LoB cloud applications, BTPEA can offer slightly better credit conversion rates and simpler governance.

BTPEA minimum commitment starts at approximately USD 50,000 per year, making it accessible for organisations with smaller BTP footprints than CPEA requires. Overage under BTPEA is also invoiced at list price — the same structural risk applies.

The Overage Problem: What SAP Prefers Buyers Not Model in Advance

BTP credit overages are billed at list price — the full, non-discounted rate for each service consumed beyond the committed credit pool. For a large enterprise with a BTPEA at USD 500,000 per year, the effective credit rate might be USD 0.65 per credit after volume discount. List price for the same credits is USD 1.00. An overage scenario means paying USD 1.00 for credits that were USD 0.65 in the contracted pool — a 54% cost premium on incremental consumption.

This overage mechanics is the fact SAP would prefer enterprise buyers not model in detail before signing their BTP commercial agreement. When SAP presents BTP consumption estimates as part of a RISE proposal, those estimates are typically based on steady-state production usage of already-decided BTP services. They do not model the BTP credit consumption associated with the migration itself: the integration flows running during data migration, the development and testing environments consuming credits before go-live, the Clean Core remediation projects consuming Build services while the migration is in flight.

Adding migration-phase BTP consumption to steady-state operational consumption consistently produces a total credit requirement that is 40 to 80% higher than SAP's initial proposal estimates. The difference is paid at overage rates unless negotiated into the committed pool before signing.

How to Model BTP Credit Requirements Accurately

Accurate BTP credit modelling requires a structured approach that covers three phases of consumption: pre-go-live (migration and development), steady-state production, and growth.

Phase 1: Pre-Go-Live Consumption

Development, test, and quality assurance environments consume BTP credits continuously from the point BTP provisioning begins until go-live. For a complex RISE migration with 50+ integration scenarios, the pre-go-live credit consumption for SAP Integration Suite alone can reach 80,000 to 150,000 credits over an 18-month implementation timeline. Add SAP Build Process Automation for workflow migration, SAP Build Apps for extension development, and SAP HANA Cloud for development database instances, and pre-go-live consumption can rival or exceed the first year of steady-state production consumption.

Phase 2: Steady-State Production

Steady-state production consumption is driven by the number and complexity of integration scenarios running in SAP Integration Suite, the number of BTP-hosted extensions and custom applications executing on SAP Build, the SAP HANA Cloud database size and query volume, the SAP Analytics Cloud story execution volume and planning model size, and SAP Joule AI skill invocations (where consumption-based Joule skills apply beyond what is included in S/4HANA and RISE). For each service, calculate the expected monthly capacity unit consumption and convert to credits using the Discovery Centre conversion rates.

Phase 3: Growth Buffer

Add a growth buffer of 15 to 25% above modelled consumption to account for new integration scenarios added post-go-live, new users and usage patterns that differ from pre-go-live projections, Clean Core remediation projects that continue after go-live as technical debt is addressed, and unforeseen consumption spikes from reporting, analytics, or automation initiatives.

Negotiating BTP Credits in Multi-Product SAP Deals

BTP credits are a negotiating lever in broader SAP commercial discussions, not just a line item to accept as proposed. Several negotiating strategies consistently improve BTP commercial terms.

Commit at the right tier. BTPEA and CPEA both offer volume discounts at higher commitment levels. The effective credit rate at USD 1M annual commitment is typically 30 to 35% below list price, versus 20 to 25% at USD 250K commitment. If your consumption model supports a USD 1M commitment, committing at that level and receiving a lower per-credit rate produces better economics than committing at a lower tier and paying overage at list price.

Negotiate mid-term top-up rights. Standard BTP agreements do not automatically allow you to purchase additional credits at your contracted rate once the pool is exhausted — overage is invoiced at list price. Negotiate an explicit right to top up your credit pool mid-term at the contracted discount rate rather than list price. This protection costs SAP nothing in the normal case (where consumption stays within the committed pool) and saves the buyer significantly in overage scenarios.

Negotiate credit carry-forward. Unused BTP credits in a given year typically do not carry forward under standard terms. Across the SAP customer base, approximately USD 600 million in BTP credits went unconsumed in 2025. Negotiate a provision for carrying forward a defined percentage of unused credits (typically 10 to 20%) into the following year. This reduces the cost of conservative initial commitments while maintaining protection against overage.

Align BTP and S/4HANA renewal dates. BTP commercial terms are most favourable when negotiated as part of a combined S/4HANA (or RISE) renewal rather than as standalone procurement. Aligning contract end dates and negotiating the full SAP portfolio together gives the buyer portfolio leverage — your total SAP cloud spend, not just BTP, is the negotiating anchor.

Benchmark against comparable deals. SAP BTP pricing is not uniform. Comparable enterprises negotiating BTP in the same quarter may achieve materially different credit rates depending on deal size, timing, and negotiating preparation. Benchmarking your proposed credit rate against current market transactions identifies whether you are receiving competitive pricing or leaving value on the table.

BTP and the SAP 2027 Context

The BTP credit conversation cannot be separated from the broader SAP commercial context. RISE with SAP — the migration path SAP is most actively promoting ahead of the December 31, 2027 ECC maintenance deadline — includes BTP credits as a bundled component. The standard inclusion is calibrated to generate BTP adoption, not to cover an enterprise's actual Clean Core migration needs.

According to Gartner data, only 39% of SAP's approximately 35,000 ECC customers have licensed S/4HANA as of end-2024. Horváth's 2025 survey found that only 37 of 200 surveyed companies had completed migration, with over 60% over budget and behind schedule. The migration complexity that drives BTP credit underestimation is structural — not exceptional. The SAP ERP Private Edition Transition Option (introduced Q1 2025) and Extended Maintenance options exist precisely because many enterprises cannot complete migration by 2027 on standard timelines.

For enterprises that do proceed with RISE, getting BTP commercial terms right — adequate credit commitment, competitive pricing, overage protection, and carry-forward rights — is as important as getting S/4HANA user pricing right. The two cost categories are comparable in scale over a five-year horizon for enterprises with complex customisation estates, and BTP is the one that most enterprises underestimate at contract signing.