What are Capacity Units?

Capacity Units are the universal billing metric across all BTP services. Each service defines its own technical consumption metrics, which are converted into Capacity Units via credit rates.

What is the difference between Depreciation Group 1 and 2?

Group 1 services are supported through the end of the current contract term. Group 2 services can be removed after a minimum notice period of six months.

Capacity Units and Depreciation Groups: How BTP Consumption Is Actually Measured

SAP BTP is billed in credits, but measured in something else entirely. If you want to set a meaningful alert threshold for your credit pool or build a reliable forecast for the next contract period, you need to understand the layer beneath: Capacity Units, service-specific metrics, and the depreciation logic that determines how stable your active service catalog actually is.

This article explains both concepts in a way that makes them immediately actionable for the governance moment around usage and cost.

Capacity Units: The Billing Unit Behind the Credits

What a Capacity Unit Is

Capacity Units (CUs) are the universal billing measure across all BTP services. The basic logic: every BTP service measures consumption in a technical unit that makes sense for that service. Cloud Foundry Runtime measures in GB of RAM per hour. Integration Suite counts messages. SAP HANA Cloud combines memory, storage volume, and compute. SAP AI Core bills by token.

These different units are converted into Capacity Units using service-specific credit rates, and the sum of all Capacity Units across all active services determines the monthly drawdown from your credit pool.

A useful rule of thumb: one credit corresponds roughly to one US dollar of consumption at list price. The exact conversion is contract-specific and defined in the Order Form (source: SAP Discovery Center). What matters for governance is not the dollar figure alone, but the conversion logic per service: two services with identical cost equivalents can have entirely different consumption dynamics.

The Monthly Billing Process

SAP measures technical consumption per service and subaccount, multiplies it by the service-specific rate, aggregates Capacity Units across all services, and deducts the result from the credit pool. The outcome is documented in monthly Balance Statements, broken down by service and subaccount (source: SAP Help Portal, Monitoring Usage and Consumption Costs).

These Balance Statements are the primary data foundation for every governance moment in the cost domain: they show not just how much was consumed, but which service in which subaccount contributed how much. If your subaccount structure is organized meaningfully by project or organizational unit, you can use this data directly for internal cost allocation.

Service-Specific Metrics Compared

The range of consumption metrics is substantial, and this variation is the main reason why BTP forecasting stays systematically inaccurate without a solid understanding of CUs.

Cloud Foundry Runtime is measured by GB of RAM per hour. A useful reference point is roughly 0.1 CU per GB of RAM per hour (Community Knowledge: Redress Compliance). Running an application with 1 GB of RAM around the clock comes to about 72 credits per month. That sounds manageable, but production applications rarely run on a single gigabyte. A typical Java application with 4 GB across three instances comes to over 800 credits per month.

Kyma Runtime, the Kubernetes-native execution environment, runs at approximately 0.24 CU per node-hour. A three-node cluster in continuous operation generates around 518 credits per month (Community Knowledge: Redress Compliance). The governance moment in the infrastructure domain: Kyma clusters are frequently set up for a project and then left running after the project closes.

SAP Integration Suite uses message counts as its metric. The model is progressive: at low volumes of 200,000 messages per month, the cost is around 6 credits per 10,000 messages. At 5 million messages monthly, it drops to 2 to 3 credits per 10,000 messages (Community Knowledge: Redress Compliance). What is easy to overlook: a single batch file split inside Integration Suite can generate hundreds of individual messages. Retry logic on failures multiplies that volume further. Integration volume monitoring is therefore one of the most critical governance moments in any BTP setup with an active Integration Suite.

SAP HANA Cloud is often the single largest line item in the credit budget. Billing combines memory, storage volume, Native Storage Extension, and compute. A production instance with significant memory allocation can consume several thousand credits per month (Community Knowledge: Redress Compliance, SAP HANA Cloud CU Estimator). The difference between running HANA Cloud as a subscription versus drawing it from the credit pool is therefore frequently one of the most consequential individual decisions in BTP cost governance.

SAP AI Core bills by token consumption, with input tokens priced lower than output tokens. AI workloads have the most difficult consumption patterns to forecast of any BTP service, because token consumption depends heavily on use case, model selection, prompt length, and usage intensity. The governance moment: AI pilots often scale faster than planned when user adoption is strong.

Where to Find Current Rates

The authoritative, up-to-date rates are available in the SAP Discovery Center Service Catalog (https://discovery-center.cloud.sap/), which lists all services with pricing per commercial model. The Discovery Center Estimator (https://discovery-center.cloud.sap/estimator) supports interactive cost estimates. Several services have dedicated estimators, including the SAP HANA Cloud CU Estimator and the SAP AI Core Cost Calculator.

All reference values in this article come from community sources (Redress Compliance, Rizing) and may change with SAP price adjustments. For binding planning purposes, always use the Discovery Center as the primary source, and document the rates used in your forecast with a date and source reference.

Why Forecasting Without CU Understanding Stays Systematically Inaccurate

A forecast that only works in dollars and ignores the credit rate structure of your active services introduces two structural errors.

First, consumption dynamics remain invisible: an integration use case with growing message volumes will exhaust the credit pool on a different timeline than a stable HANA Cloud production workload, even if both represent the same credit value at the time of planning. The governance moment in the cost domain requires knowing not just current volume, but the growth rate of consumption per service.

Second, service combinations are underestimated: when AI workloads consume both BTP Capacity Units and separate AI Units (the latter are covered in the pillar on SAP Business AI Units), both pools must be planned and monitored independently. Tracking only one pool means you do not have a complete governance picture.

Depreciation Groups: How Stable Is Your Active Service Catalog?

The Two-Group Model in BTPEA

BTPEA, the strategic successor to CPEA and the recommended BTP contract model for new customers today, introduces a structured deprecation policy that CPEA does not have. Services are divided into two groups carrying different stability commitments.

This model is not a risk signal that argues against BTPEA. It is a more transparent treatment of a reality that was always present under CPEA implicitly: service catalogs change. The difference is that BTPEA provides a clear framework for managing those changes.

Group 1 (Core Services): Protected Through Contract End

Group 1 services are BTP services that SAP supports through the end of the current contract term. You can deploy these services in production without facing a forced migration during the contract period. This protection matches the commitment CPEA customers generally have for their entire service catalog.

Services considered stable Group 1 offerings include Integration Suite core services, SAP HANA Cloud, Cloud Foundry Runtime, and ABAP Environment. These services form the backbone of productive BTP landscapes. The governance moment in the infrastructure domain: business-critical workloads should always be built on Group 1 services.

Group 2 (Innovation Services): 6 Months Notice on Retirement

Group 2 services can be removed from the BTPEA catalog or promoted to Group 1 with a minimum advance notice period of 6 months. Those 6 months are not a comfortable buffer that allows relaxed waiting. They are a window in which migration planning, resource allocation, and testing must all be completed.

For production deployments on Group 2 services, this creates a clear governance requirement: all dependencies on Group 2 services must be documented. Deprecation monitoring must be configured so that a retirement announcement does not arrive in your landscape only after the notice period has already started running (source: ASUG, SAP Experts Detail New BTPEA).

How to Check Which Services Belong to Which Group

The SAP Discovery Center Service Catalog shows the group assignment for every service under the BTPEA model. A practical process: when introducing a new BTPEA deployment, document the group of the service being used. This documentation is part of the governance moment in the infrastructure domain and should be included as a mandatory step in your internal governance process for every new project setup.

For existing deployments, a one-time inventory of all active services with their group assignments is a reasonable starting point, followed by a quarterly review for changes.

Services Currently Affected: Datasphere and SAP Analytics Cloud

Two services relevant to many BTP customers were under deprecation pressure that became visible as warnings in BTP Cockpit instances. SAP Datasphere and SAP Analytics Cloud showed deprecation warnings referencing December 31, 2025 as a key date (SAP KBA 3630656, SAP KBA 3632353). The migration path for Datasphere leads toward SAP Business Data Cloud.

If you are running Datasphere or SAP Analytics Cloud in production, verify your migration status and the current state of these announcements. SAP migration plans continue to evolve, so the latest information should be verified directly at the SAP Help Portal and the BTP Release Navigator.

For CPEA customers: service scope is secured for the contract term, but new development for these services is happening in the successor solutions. Forward-looking planning for your next renewal should factor this in.

Deprecation Monitoring as an Ongoing Task

Deprecation monitoring is not a one-time setup task. It is a structural element of BTP governance. SAP publishes service changes in the BTP Release Navigator (https://help.sap.com/whats-new/cf0cb2cb149647329b5d02aa96303f56). Reviewing this channel quarterly is the most effective practical measure for responding early to changes in your active service catalog.

The governance moment in the infrastructure domain therefore covers three levels: check group assignment at onboarding, document active Group 2 deployments, and review the Release Navigator each quarter.

Three Diagnostic Questions for the Governance Moment

If you want to use Capacity Units and Depreciation Groups as active governance tools, these three questions provide a practical frame:

On usage: Which services consume how many credits, and at what rate is that consumption growing? A monthly Balance Statement answers the past; a CU-based forecast answers the future.

On cost: Which services carry the highest potential for surprises? Integration Suite at growing volumes and HANA Cloud when new instances come online are the most frequent drivers of unplanned credit consumption.

On infrastructure: Which production workloads run on Group 2 services? Keeping that documentation current is the foundation for ensuring that a deprecation signal does not go unnoticed until the notice period has already begun.

Conclusion

Capacity Units are the layer between the credit pool and actual service consumption. Understanding them lets you build forecasts, set alert thresholds that mean something, and use monthly Balance Statements as a governance instrument rather than just a ledger. Without that understanding, you are watching the result, not the cause.

Depreciation Groups are the risk management tool for your service catalog. Group 1 provides planning certainty. Group 2 requires active monitoring. The two-group model makes a reality transparent that exists in every BTP contract: services evolve, and some of those evolutions affect your own landscape.

Together, both concepts define the governance moment across infrastructure and usage: the goal is not to minimize consumption, but to understand it, attribute it, and make it plannable.

Further reading:

BTP FinOps: Governing Credits, Avoiding Overages, Allocating Costs (Pillar 3 Hub)
CPEA and BTPEA: Two Contract Models, One Platform (Cluster 1)
BTP Credit Expiry and Overage Mechanics (Cluster 3)

Bernhard Mändle is Managing Consultant at FinOptory, helping companies govern their SAP contracts after signature, across the full contract term. Connect on LinkedIn

Want to know how your BTP contract structure is set up? Schedule an initial call.