BTP FinOps and Credit Governance: Managing SAP Cloud Budgets by Consumption

SAP BTP is consumed under four contract models, but only one of them (BTPEA) is today's strategic default for new customers. Underneath it sits a credit mechanic where unused budgets expire at year-end and overages are billed at full list price. Anyone who wants to govern BTP costs transparently, allocate them by consumption, and embed them in a FinOps cycle needs three things: the right contract model, continuous monitoring, and clearly defined internal accountability.

Table of Contents

1. What BTP Is and Why the Contract Model Choice Matters
2. The Four Contract Models: CPEA, BTPEA, PAYG, Subscription
3. CPEA vs. BTPEA: What Differs and Who Should Migrate
4. Capacity Units: Understanding the Billing Metric
5. Depreciation Groups: Stability and Innovation Risk in the Service Catalog
6. Credit Expiration and the Use-It-or-Lose-It Logic
7. Overage: How Overconsumption Happens and What It Costs
8. BTP Monitoring: What You Need to See in Order to Govern
9. FinOps Inform Phase: Establishing Visibility into BTP Consumption
10. FinOps Optimize Phase: Aligning Consumption and Commitment
11. FinOps Operate Phase: Continuous Governance as a Running Process
12. Internal Allocation: Charging BTP Costs Back to Projects and Cost Centers
13. FAQ
14. Next Steps

---

1. What BTP Is and Why the Contract Model Choice Matters {#what-btp-is}

BTP as a Technical Platform Across Five Pillars

SAP Business Technology Platform (BTP) is the central technology layer in the SAP ecosystem. It connects application development, automation, integration, data management, and artificial intelligence in a single platform. For organizations with complex SAP landscapes, BTP is where extensions are built, integrations are operated, and data is brought together.

The five pillars of the platform are clearly distinct. Application Development covers low-code and pro-code environments such as SAP Build Apps, SAP Build Code, and the Business Application Studio. Automation includes workflow management, robotic process automation, and document processing. Integration bundles the SAP Integration Suite with more than 3,400 pre-built integration packages, API management, and event mesh architecture. Data and Analytics encompasses SAP Datasphere, SAP Analytics Cloud, and SAP HANA Cloud as an in-memory database platform. The fifth pillar, AI, provides SAP AI Core, the Generative AI Hub, and AI services.

This five-pillar architecture has a direct implication for contract governance: BTP is not a single product you switch on or off. It is a platform with dozens of active services running simultaneously, each with its own consumption pattern, collectively drawing from the same monthly credit budget.

Why the Contract Model Choice Is More Than a Procurement Decision

The choice between CPEA, BTPEA, PAYG, and subscription models determines more than the price per Capacity Unit. It determines which services are accessible at all, how overages are billed, which expiration rules apply to unused credits, and what governance requirements follow.

A CPEA contract provides access to a historically grown catalog of roughly 85 services but offers no forward-looking coverage for new services. A BTPEA contract includes newer services exclusively but introduces the two-group model for service deprecation, which creates its own monitoring requirements. PAYG offers maximum flexibility at list price but is not suited for production use. Subscriptions deliver cost precision for individual, stable services but quickly generate shelfware when workloads are variable.

The contract model choice is therefore a governance moment that shapes the entire BTP governance posture over the contract term. Choosing the wrong model, or failing to govern actively after signing, leads to one of two outcomes: credits expire unused, or overages accumulate at full list price without the consumption being recognized in time.

BTP in the RISE Context: Included Credit Budget vs. a Standalone BTP Contract

For customers with a RISE contract, there is an important distinction that frequently leads to misestimation in practice. The RISE package includes a BTP credit budget whose size depends on the license tier. That budget is not unlimited and does not cover all BTP consumption scenarios.

Customers who consume BTP services beyond the included budget either generate unplanned overages within the RISE contract or need to sign a standalone BTP contract (CPEA or BTPEA). In practice, we regularly see organizations discover in year two or three that their BTP demand has outgrown the originally planned budget, because integration volumes were underestimated or new use cases emerged after signing that were never part of the original scope.

What the Wrong Model Choice Means Over the Contract Term

The financial consequences of a misaligned contract structure become visible over time, not immediately. A credit pool that is sized too large and not fully consumed costs the entire unused budget at year-end. A pool sized too small generates overages where all volume discounts vanish and billing reverts to full list price.

This governance moment between over-dimensioning and under-dimensioning can only be managed through active, continuous monitoring and a structured governance process. One-time planning decisions made at contract signing are not sufficient across a typical three-year term.

---

2. The Four Contract Models: CPEA, BTPEA, PAYG, Subscription {#four-contract-models}

Four models, four distinct governance logics. What they share, what separates them, and which fits when.

CPEA: Core Principle and Key Characteristics

The Cloud Platform Enterprise Agreement (CPEA) is the traditional enterprise model for BTP. It works on the commit-to-consume principle: the customer buys an annual credit budget upfront and consumes it flexibly across the roughly 85 available BTP services. The logic resembles a prepaid card: credits are loaded upfront, and services draw from them at defined rates.

Key characteristics at a glance: annual minimum commitment with volume discounts, flexible consumption across the full service catalog, self-provisioning without SAP approval, monthly balance statements broken down by service and subaccount. The credit price decreases with higher commitment; typical ranges are 10 to 25 percent discounts on list price at mid-range volumes (community knowledge: Redress Compliance, Rizing).

One structural feature of CPEA: the service catalog is no longer extended with new services. Anyone who wants to use new SAP services developed after CPEA was introduced will find those exclusively in the BTPEA catalog (source: ASUG, SAP Experts Detail New SAP BTP Enterprise Agreement).

BTPEA: Core Principle and Strategic Positioning

The BTP Enterprise Agreement (BTPEA) was introduced in 2024 as the strategic successor model and is today the recommended default contract for new customers. The underlying logic is identical to CPEA: upfront credit purchase, flexible consumption across a defined service catalog, volume discounts, monthly billing.

The decisive difference lies not in billing mechanics but in service scope and forward compatibility. BTPEA includes all new services exclusively, among them SAP Analytics Cloud, newer AI services, and future additions. At the same time, some low-adoption services have been removed from the catalog. The Minimum Price Guarantee ensures that customers automatically benefit if SAP list prices decrease during the contract term (source: ASUG).

PAYG: When and Why

Pay-As-You-Go is the zero-commitment model. No minimum consumption, no upfront payment, monthly billing based on actual usage. In exchange, full list price applies with no volume discounts.

PAYG makes sense for proof-of-concept projects, developer sandboxes, evaluating services before committing to an enterprise agreement, and as an entry point to understand consumption patterns. For production use at meaningful volume, PAYG is structurally unsuitable because unit costs are considerably higher than under an enterprise agreement.

Subscription: Stability vs. Rigidity

The subscription model offers fixed pricing for individual services with defined capacity limits. For stable, predictable workloads, it delivers the highest cost precision. SAP HANA Cloud in the production environment, the Integration Suite at a fixed message volume, or SAP Build for a defined development team are typical subscription scenarios.

The downside: subscriptions are inflexible. If you need more capacity than contracted, you pay overage. If you consume less, you still pay the full amount. Shelfware is common with subscriptions because planned demand often fails to materialize in the expected usage after signing.

Hybrid Models in Practice

Most enterprise customers do not run a single unified strategy; they combine models. A typical pattern pairs subscriptions for core services with constant demand, such as the Integration Suite in production, with CPEA or BTPEA credits for flexible use, such as AI workloads, new development projects, and dev/test environments. This hybrid approach delivers cost precision for the baseline and flexibility for the variable portions of BTP consumption.

Governance requirement for hybrid models: two contract structures require two monitoring streams. The governance moment where subscription overage and credit consumption must be observed simultaneously raises the complexity of internal governance.

---

3. CPEA vs. BTPEA: What Differs and Who Should Migrate {#cpea-vs-btpea}

Service Scope Difference: Legacy Breadth vs. Forward Compatibility

CPEA launched with a catalog of roughly 85 to 90 services that grew organically over time. That catalog is stable but closed. New services that SAP has developed since BTPEA was introduced are not available in CPEA.

BTPEA has a narrower legacy scope because low-adoption services were removed, but it includes all new services exclusively. SAP Analytics Cloud is the most prominent example: it was brought into the enterprise agreement model with BTPEA and is not available to CPEA customers through this vehicle. The same applies to the latest generation of AI services and further strategic additions (source: ASUG, SAP Experts Detail New BTPEA).

For the model decision, this means: if you exclusively use services included in CPEA and have no need for new services, staying on CPEA is defensible. If you want to use SAP Analytics Cloud through an enterprise agreement or plan to adopt new SAP AI services, BTPEA is required.

Deprecation Policy: The Two-Group Model in BTPEA

BTPEA introduces a structured deprecation policy that CPEA does not have. Services are divided into two groups.

Group 1 (Core Services) are services that SAP supports until the end of the current contract term. Customers can use these services productively throughout their contract without migration pressure. This protection is equivalent to the assurance that CPEA customers generally enjoy.

Group 2 (Innovation Services) are newer or less-adopted services that SAP can remove from the BTPEA catalog or promote to Group 1 with at least six months' advance notice. This means: productive workloads running on Group 2 services carry a structural risk that must be actively monitored (source: ASUG, SAP Experts Detail New BTPEA).

For practice, the two-group model means: every deployment on a BTPEA service should be checked at the outset for which group that service belongs to. This governance moment in the infrastructure domain is not a one-time task but a continuous monitoring requirement.

What Has Been Added in BTPEA

Beyond SAP Analytics Cloud (public system, BI, and planning), BTPEA includes new AI services from the SAP AI portfolio and further newer additions that SAP continues to expand. The Discovery Center service catalog shows in real time which services are available under which model (https://discovery-center.cloud.sap/).

When Migration Makes Sense and When It Does Not

A migration from CPEA to BTPEA makes sense if at least one of the following conditions applies: the organization wants to use SAP Analytics Cloud through the enterprise agreement, new AI services are to be incorporated into the platform strategy, forward compatibility of the contract vehicle is strategically important, or new SAP innovation services should be explorable flexibly.

A migration is less urgent when all actively used services are covered by the existing CPEA catalog, no services from the BTPEA-exclusive range are needed, and the existing contract still has meaningful remaining term.

Migration Process: What Changes Technically and What Changes Commercially

The good news: migrating from CPEA to BTPEA does not require any technical changes to the existing BTP landscape. The global account, subaccounts, running services, and all configurations remain unchanged. Only the new commercial terms are activated on the existing global account (source: ASUG, SAP Experts Detail New BTPEA).

The commercial side of the migration matters more: the new contract establishes a new price basis that may differ from the old CPEA terms. Services not included in BTPEA must be continued as separate subscriptions if they are still needed. A thorough analysis of all services in use before the migration is therefore a mandatory step.

---

4. Capacity Units: Understanding the Billing Metric {#capacity-units}

What a Capacity Unit Is and How the Conversion Works

Capacity Units (CU) are the universal billing metric across all BTP services. Each service defines its own technical consumption metrics, for example GB RAM per hour for runtime environments, message volume for the Integration Suite, or storage and compute units for SAP HANA Cloud. These service-specific metrics are converted into Capacity Units via credit rates.

The rule of thumb: one credit corresponds roughly to one dollar of consumption at list price (the exact conversion is contract-specific and defined in the order form). The monthly billing process is consistent: SAP measures technical consumption per service, multiplies it by the service-specific rate, totals the Capacity Units across all services, and deducts them from the credit pool. The result is documented in monthly balance statements (source: SAP Help Portal, Monitoring Usage and Consumption Costs).

Service-Specific Metrics Compared

The range of consumption metrics is significant, and this variation is precisely what makes BTP forecasting difficult without a solid understanding of CU mechanics.

Cloud Foundry Runtime is measured in GB RAM per hour. A rough reference value is approximately 0.1 CU per GB RAM per hour, which at 24/7 operation amounts to around 72 credits per gigabyte per month (community knowledge: Redress Compliance). Kyma Runtime, the Kubernetes-native execution environment, runs at roughly 0.24 CU per node-hour; a three-node cluster therefore accumulates around 518 credits in continuous monthly operation.

The Integration Suite uses message counts as its metric. The volume model is progressive: at low volumes (200,000 messages per month), costs run at approximately 6 credits per 10,000 messages; at high volumes (5 million messages per month), they drop to 2 to 3 credits per 10,000 messages. SAP HANA Cloud is typically the single largest line item in any BTP budget: a production instance with significant memory can consume several thousand credits per month (community knowledge: Redress Compliance, SAP HANA Cloud CU Estimator).

All figures cited here are reference values drawn from community practice. The current, authoritative rates are found in the SAP Discovery Center and in service-specific estimators, since SAP updates these values periodically.

Monthly Billing Process and Balance Statements

SAP delivers monthly balance statements that break down consumption by service and subaccount. These statements are the primary data source for any BTP monitoring effort. They show which services consumed how many credits, what the credit balance was at month-end, and which consumption is attributable to which subaccount.

One important governance moment in the cost domain: balance statements are retrospective reports, not real-time data. Anyone who wants to govern proactively also needs ongoing monitoring settings in the BTP cockpit that track thresholds and signal when the budget is being approached.

Where to Find Current Rates

The authoritative sources for current Capacity Unit rates are the SAP Discovery Center Service Catalog (https://discovery-center.cloud.sap/), which provides a full list of all services and pricing per commercial model; the SAP Discovery Center Estimator (https://discovery-center.cloud.sap/estimator) for interactive cost estimates; and service-specific estimators for HANA Cloud, Datasphere, and AI Core. Rates change over time, so forecasts should be dated with the version of rates used.

Why Forecasting Without CU Understanding Stays Systematically Inaccurate

A forecast that only counts in euros and ignores the credit-rate structure of the services in use will produce two structural errors. First, consumption dynamics remain invisible: an integration use case with growing message volume can exhaust the credit pool within months if it is not modeled against the progressive rate structure of the Integration Suite. Second, service combinations are underestimated: when AI workloads draw from both BTP Capacity Units and separate AI Units, the forecast must track both pools independently.

---

5. Depreciation Groups: Stability and Innovation Risk in the Service Catalog {#depreciation-groups}

Group 1 (Core Services): Protection Until Contract End

Group 1 services are those BTP services that SAP supports until the end of the current contract term. Customers can deploy these services in production without fearing an unexpected migration during the contract period. This protection corresponds to the commitment CPEA customers generally receive: the service scope is locked in for the term.

Group 1 services therefore form the reliable foundation for productive, business-critical workloads. The Integration Suite core, HANA Cloud, Cloud Foundry Runtime, and ABAP Environment are considered stable Group 1 services.

Group 2 (Innovation Services): Six Months' Notice Before Removal

Group 2 services can be removed from the BTPEA catalog or promoted to Group 1 by SAP with at least six months' advance notice. Those six months are not a buffer that allows comfortable waiting; they are a window during which migration planning must be initiated.

For deploying Group 2 services in productive processes, this means: all dependencies on such services must be documented, and deprecation monitoring must be configured so that a removal notice does not go undetected until after the announcement period has begun to run.

How to Check Which Services in Use Belong to Which Group

The SAP Discovery Center service catalog shows the group designation for every service. It is good practice to document the group membership of all services used when introducing a new BTPEA deployment. This documentation is part of the governance moment in the infrastructure domain.

Currently Affected Services: Datasphere and SAP Analytics Cloud

Two services relevant to many BTP customers have faced deprecation pressure: SAP Datasphere and SAP Analytics Cloud showed deprecation warnings in BTP Cockpit instances with a reference date of December 31, 2025 (SAP KBA 3630656, SAP KBA 3632353). The migration path from Datasphere leads toward SAP Business Data Cloud. Customers using Datasphere in production should check their migration status and the current state of these announcements, as SAP migration plans continue to evolve.

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

Governance Consequence: Deprecation Monitoring as a Continuous Task

Deprecation monitoring is not a one-time setup task; it is a structural component of BTP governance. SAP publishes news about service changes in the BTP Release Navigator (https://help.sap.com/whats-new/cf0cb2cb149647329b5d02aa96303f56). A regular quarterly review of this channel is a practical measure for responding early to changes in the service catalog you rely on.

---

6. Credit Expiration and the Use-It-or-Lose-It Logic {#credit-expiration}

Default Rule: Unused Credits Expire at the End of the Contract Period

The credit expiration rule is one of the most consequential mechanics in the BTP contract model. Unused credits expire at the end of the contract period, typically at the end of the contract year. There is no automatic rollover to the next contract year. This rule applies equally to CPEA and BTPEA (source: SAP FAQ, Consumption-based Commercial Model CPEA).

In practice this means: an organization that purchases a credit budget of 100,000 credits at the start of the year but consumes only 65,000 credits by year-end loses the remaining 35,000 credits. This situation arises frequently when BTP use cases are planned too optimistically and are delayed in execution, or when services are activated but not used at the expected intensity.

No Automatic Rollover in Standard Contracts

The absence of a standard rollover is the governance moment that makes quarterly consumption reviews non-negotiable. Discovering at year-end that a significant share of credits will expire unused typically leaves no room for corrective action.

The structural recommendation is to size the credit commitment conservatively. It is better to choose a slightly smaller pool and top up as needed than to let a larger pool expire. The right to purchase additional credits at the original contract terms should be secured contractually so that a top-up does not have to happen at list price (source: SAP BTP Licensing Models, community knowledge).

When Over-Commitment Arises and How It Materializes

Over-commitment occurs when actual BTP usage falls behind the plan. Three common causes: first, BTP projects are delayed or reprioritized so that planned services do not go live during the contract period; second, services are activated but not used at planned intensity because user adoption or process integration takes longer than expected; third, optimistic sizing assumptions made at signing overestimate the realistic usage scenario.

Negotiation Latitude: Limited Credit Rollover

A limited credit rollover is achievable in contract negotiations, though it is not a standard provision. A rollover of 10 to 20 percent of unused credits has been reported as a negotiated outcome (community knowledge: Rizing, Redress Compliance). This is not an official SAP position or a guaranteed result; it is an experience-based reference.

Alternatively, a short grace period or the reapplication of unused credits toward other SAP software purchases can be negotiated, though neither is standard.

Quarterly Reviews as a Structural Measure Against Expiration

The most practically effective measure against unexpected credit expiration is the quarterly consumption review. In this review, cumulative consumption is compared against the planned consumption path. If actual usage is significantly below plan, there is still time to take corrective action: activating additional services for dev/test workloads, adjusting running service configurations, or proactively opening a conversation with SAP about a contract adjustment.

The governance moment of a quarterly BTP review creates the foundation for recognizing unused budgets and addressing them before they expire irreversibly at year-end.

---

7. Overage: How Overconsumption Happens and What It Costs {#overage}

What Happens When the Credit Pool Is Exhausted

When the contractually fixed credit pool is exhausted before the end of the contract period, BTP services continue to run. SAP does not automatically shut them down. Instead, the overage mechanic kicks in: consumption beyond the allotment is billed at full list price, without the volume discounts negotiated in the enterprise agreement (source: SAP FAQ, Consumption-based Commercial Model CPEA; SAP Help Portal).

This is the key financial difference: while an enterprise agreement customer may have a 25 percent discount on list price, overage credits are billed without that discount. At significant overconsumption, the effective cost increase can be material.

Overage Mechanic: All Volume Discounts Are Lost

The formula is straightforward: within the allotment, the negotiated credit price applies. Outside the allotment, list price applies. This asymmetry is the financial core of the overage mechanic. It makes overages not only more expensive but structurally harder to plan for, because list price was not the baseline on which the original budget was built.

For the governance moment in the cost domain: overage risk is a budget risk that should not be underestimated in any internal SAP cost planning effort.

Typical Overage Drivers

In practice, three causes account for the majority of overage situations.

Integration Suite volume underestimation: integration workloads have a characteristic that is easy to overlook at initial planning. What starts as 100,000 messages per month can quickly multiply through file splits (one batch file generates hundreds of individual messages), retry logic on errors, and larger payloads. Integration volume monitoring is therefore one of the most critical BTP governance tasks.

HANA Cloud: SAP HANA Cloud is in many BTP setups the largest single credit consumer. A 24/7 production instance with significant memory can strain the annual credit pool more than originally planned, especially when additional capacity is activated during the project lifecycle.

AI consumption: AI Core and Generative AI Hub workloads often have consumption patterns that are difficult to predict, because token usage depends heavily on the use case, model selection, and usage intensity. Initial AI pilots rarely overshoot, but at productive scale-up, consumption can grow quickly.

Self-Reporting Obligation: Overconsumption Notification Is the Customer's Responsibility

One aspect that is frequently underestimated in practice: in many BTP contracts, the obligation to report overconsumption rests with the customer, not automatically with SAP (source: SAP FAQ CPEA). This means: anyone generating overage without actively tracking and reporting it may face a catch-up billing at year-end that has been accumulating over several months.

Proactive Top-Up vs. Unplanned Overage

There is a structural difference between a planned top-up and an unplanned overage. A customer who initiates a conversation with SAP at 70 to 80 percent credit consumption and agrees on a top-up at the original contract terms avoids the list-price surcharge. A customer who exceeds the allotment without acting first pays list price (source: SAP BTP Licensing Models KB, community knowledge: Rizing).

The right to purchase additional credits at the original terms should therefore be secured contractually. Acting at 70 to 80 percent consumption is the practical alert threshold for proactive governance.

Overage Cap as a Negotiation Target

An overage cap is achievable in contract negotiations: a ceiling that limits how many multiples of the contract price overage can reach. A cap at 110 percent of list price means that overage credits cannot cost more than 10 percent above list price. This clause protects against extreme budget overruns in scenarios with unexpected consumption spikes.

---

8. BTP Monitoring: What You Need to See in Order to Govern {#btp-monitoring}

BTP Cockpit and Monthly Balance Statements

The BTP Cockpit is the primary interface for managing BTP services, subaccounts, and entitlements. It provides an overview of active services and usage. Monthly balance statements are the structured consumption summary: they show credit consumption per service and per subaccount, the remaining credit balance, and the trend over the contract period.

Subaccount-Based Breakdown by Service and Project

Monthly balance statements are only interpretable by consumption origin if the subaccount structure of the global account is organized sensibly. A subaccount that mixes all project environments delivers aggregated numbers but provides no attribution to projects or cost centers.

The governance moment in the usage domain requires a subaccount structure that reflects organizational units, projects, or cost centers. Only with that structure in place can balance statements be read by consumption origin and used for internal allocation.

Alert Thresholds: When Action Is Required

A practically proven alert strategy uses two thresholds: a first notification at 70 to 80 percent credit consumption triggers proactive governance measures. A second notification at 90 percent is the latest point to initiate a top-up conversation with SAP and avoid unplanned overages.

The BTP Cockpit allows you to configure notifications for subaccount usage. These alerts should be a standard configuration in every production BTP setup.

SAP BTP Discovery Center Estimator for Ongoing Forecasts

The Discovery Center Estimator (https://discovery-center.cloud.sap/estimator) is not just a one-time tool at contract signing; it is an ongoing forecasting instrument. When service usage changes, for example through new projects, growing integration volume, or the introduction of AI workloads, the estimator allows an updated estimate of credit demand for the remaining contract period.

Limits of SAP-Native Monitoring

The BTP Cockpit has structural limits that are relevant for complete governance. It reports consumption per subaccount and per service but does not offer a consolidated view across multiple contract structures, such as CPEA and subscriptions running in parallel. It does not show historical consumption trends across multiple contract years in a comparable format. It does not automatically connect to internal cost center or budget structures.

Anyone who wants to govern BTP costs entirely with SAP-native tools will reach those limits as soon as the contract structure becomes complex or cost-by-consumption internal allocation is required. This gap is the starting point for building a dedicated BTP governance function.

Linking to Internal Cost Centers

Complete BTP cost governance connects the subaccount consumption data from the monthly balance statements to the organization's internal cost center structures. Establishing that link requires two steps: the subaccount structure must reflect the organizational attribution units, and a process must exist that transfers monthly BTP data into the internal cost accounting system.

---

9. FinOps Inform Phase: Establishing Visibility into BTP Consumption {#finops-inform}

The FinOps Framework as a Structure

The FinOps Framework is an open standard developed and maintained by the FinOps Foundation. The FinOps Foundation is a non-profit organization under the Linux Foundation umbrella, founded in 2019, with more than 10,000 members worldwide. The framework structures technology cost management in three phases: Inform, Optimize, Operate (source: FinOps Foundation, FinOps Framework 2025).

Originally developed for public cloud (AWS, Azure, GCP), the FinOps Foundation explicitly extended the scope of the framework in 2024 and 2025. Licensing is now a standalone domain, and SAP BTP is a concrete example within it: the specific mechanics of commit-to-consume models, credit expiration, and overage logic make BTP a textbook case for FinOps principles outside of public cloud (source: FinOps Foundation, Licensing and SaaS Capability).

Inform Means: Complete Visibility Before You Optimize

The first step in the FinOps cycle is not optimization but transparency. The Inform phase means that all relevant data about BTP entitlements, service usage, and costs is fully captured and accessible to the relevant roles. Without complete visibility, optimization is not grounded; it is random.

The governance moment of the Inform phase for BTP spans four dimensions: What is contractually entitled (all services and limits in the contract)? What is actually activated (all active service plans per subaccount)? What is actually being used (monthly consumption data from balance statements)? And what costs does that produce (conversion to credits and ultimately to euros)?

Inventory: All BTP Entitlements, Subaccounts, Active Service Plans

The concrete first step in the Inform phase is a complete inventory. For BTP this covers: all contracts and amendments (CPEA, BTPEA, subscriptions), all global accounts and their subaccount structure, all activated entitlements per subaccount, and all active service plans with their current usage status.

This inventory is not a one-time project but a baseline that must be updated with every contract change, every new project setup, and every renewal.

Cost Allocation in the Inform Phase: First Attribution of Credits to Projects

Once the inventory is in place, the first cost attribution begins. In the Inform phase, the goal is not yet optimized allocation but simply the basic ability to attribute credits to projects or organizational units. This first attribution is the starting point for all subsequent governance decisions.

Recognizing Shelfware in the BTP Context

Shelfware, meaning activated services that are used little or not at all, is a structural phenomenon in BTP environments. Services are activated during projects and keep running after the project ends. Test instances are stood up and never shut down. Service plans are activated for future use cases that never materialize.

In the Inform phase, shelfware becomes visible because active service plans are compared against actual usage volumes. An active service plan with near-zero consumption over several months is a candidate for deactivation or downsizing.

---

10. FinOps Optimize Phase: Aligning Consumption and Commitment {#finops-optimize}

Optimize Means: Active Intervention, Not Just Observation

The Optimize phase builds on the data from the Inform phase and targets active measures to improve credit efficiency. Optimize is not a one-time cost-reduction project but a continuous process that is initiated whenever Inform data reveals potential for improvement.

Rightsizing: Oversized Service Plans and Runtime Configurations

The first optimization approach concerns the sizing of active services. Runtime environments (Cloud Foundry, Kyma) frequently run with more resources than actually needed, because the initial configuration was designed for peak load that is never reached in normal operation. SAP HANA Cloud instances can have memory that is permanently used at only a fraction of capacity.

Rightsizing means adjusting service configurations to actual usage needs. For the governance moment in the usage domain: every resource running beyond actual demand consumes credits without corresponding business value.

Checking for Hyperscaler Overlap: Where Are You Paying Twice?

For customers running on hyperscalers (AWS, Azure, GCP), a structural double-payment risk exists. BTP provides integration, analytics, and AI capabilities, but the respective hyperscalers offer comparable or complementary services. When an organization pays for both BTP analytics services and hyperscaler analytics services without a clear demarcation, it incurs costs for overlapping capabilities.

The optimization measure consists of a systematic comparison: which BTP services have direct hyperscaler equivalents? Where is the BTP service better suited (for example, the SAP Integration Suite for SAP-specific integrations), and where is the hyperscaler service equivalent or cheaper? Consolidating on a single capability source eliminates redundancy costs.

Non-Production Shutdown Strategies

Development and test instances of HANA Cloud, Kyma clusters, and Cloud Foundry runtime environments do not need to run around the clock. Automated shutdown strategies for nights and weekends significantly reduce the credit consumption of those environments without affecting development operations.

HANA Cloud has scheduling functions that enable automatic starts and stops. Kyma clusters can be scaled down to zero nodes when not in use. Cloud Foundry applications can be set to zero instances. These measures typically have a direct and measurable impact on monthly credit consumption.

Credit Commitment Calibration

The Optimize phase also includes calibrating the credit commitment for the next contract period. Based on the Inform data of the current period, it is possible to build a well-grounded forecast that is more realistic than the initial planning at contract signing. This forecast is the basis for the next period's commitment: enough to secure volume discounts, but not more than can actually be consumed.

The recommendation to start with a conservative initial sizing and a contractually secured top-up right combines the risk of expiration (too much) and the risk of list-price overage (too little) into a more manageable picture.

---

11. FinOps Operate Phase: Continuous Governance as a Running Process {#finops-operate}

Operate Means: Continuous Governance, Not a One-Time Project

The Operate phase closes the FinOps cycle, which then begins again. Operate means that the governance processes from Inform and Optimize are embedded in the organization's regular operating rhythm. BTP FinOps is not a project with a completion date; it is a continuous function.

Monthly Governance Rhythm

The monthly governance rhythm covers three core activities: first, reviewing the monthly balance statements and comparing actual consumption against the planned path (budget tracking); second, checking for anomalies, including services consuming unexpectedly large amounts, new service activations without documented business justification, or consumption spikes pointing to configuration errors or unexpected workloads; third, an updated forecast for the remaining contract period based on current consumption.

Four Roles in the BTP FinOps Process

Ongoing BTP governance requires the structured collaboration of four roles, clearly defined in the FinOptory governance model.

The Contract Manager owns the contract structure: which models and services are contracted, which terms and renewal dates are coming up, and which clauses (overage cap, rollover, top-up right) are secured in the contract. The Contract Manager is the governance moment owner for the interface between the contract and actual consumption.

Procurement is responsible for purchasing decisions: is the current model still the right one, what is the optimal negotiation timing (SAP Q4 close, renewal window), and how are top-up terms secured in negotiations with SAP?

Controlling bridges BTP consumption and internal budget governance: are BTP costs allocated by consumption to projects and cost centers, does the BTP budget reconcile with actual costs, and which variances become visible in management reporting?

The Executive holds decision authority on threshold questions: should the renewal commitment be increased or reduced, which new BTP use cases are strategically prioritized, and how is the BTP budget positioned in overall planning?

Four Governance Moment Domains in the BTP Context

Ongoing BTP governance touches all four governance moment domains of the FinOptory governance model.

Usage: which services are used at what intensity? Which service plans are active but unused? Where is there shelfware? Where is consumption growing unexpectedly?

Entitlements: which subaccounts have access to which services? Are the entitlement structures in the global account consistent with organizational responsibilities? Are services being activated by unauthorized subaccounts?

Infrastructure: which runtimes are running in production and which only for dev/test? Are non-production environments shut down outside business hours? Which services belong to Deprecation Group 2 and require active migration preparation?

Cost: how is credit consumption trending relative to budget? Are there overages or is overage risk building? Are BTP costs allocated by consumption to cost centers? Does the commitment for the next period align with the consumption forecast?

Quarterly Business Review for BTP

A Quarterly Business Review (QBR) for BTP is the structural governance instrument at the management level. It distills the monthly tracking data into a strategic status picture and addresses decisions that go beyond the day-to-day rhythm: contract model review, renewal preparation, strategic prioritization of new BTP use cases, and internal budget planning for the next period.

QBR content should include consumption-to-plan gap versus annual target, overage risk assessment, shelfware identification, service deprecation status for Group 2 services in use, and a recommendation for commitment calibration for the coming year.

Audit Readiness and Annual Compliance Review

BTP contracts, like all SAP contracts, are subject to SAP's audit rights. Audit readiness means that balance statements from prior periods are fully documented, all service activations can be traced, and the subaccount structure is consistent with contractual entitlements. An annual compliance review checks these points systematically and identifies any inconsistencies before they surface in an SAP audit.

---

12. Internal Allocation: Charging BTP Costs Back to Projects and Cost Centers {#internal-allocation}

Why Consumption-Based Allocation Is Nearly Impossible Without Subaccount Structure

The requirement for consumption-based internal allocation of BTP costs is a controlling standard in most larger organizations. In practice, it cannot be fulfilled without a correspondingly structured subaccount architecture.

SAP delivers monthly balance statements at the subaccount level. Anyone who wants to allocate BTP costs internally to projects or cost centers needs subaccounts that correspond to those projects or cost centers. If all BTP workloads run in the same subaccount, there is no technical basis for differentiated internal allocation.

Subaccount as the Attribution Unit: Organizational Design as a Prerequisite

The decision about how global accounts and subaccounts are organized is a governance decision, not a purely technical one. It determines the granularity at which consumption-based BTP cost allocation is possible.

Typical organizational principles for subaccounts are: by business unit (one subaccount per business unit), by project (one subaccount per BTP project), by environment with project separation (one subaccount each for production, test, and development per project), or by cost center. The more granular the subaccount structure, the more precise the consumption-based allocation.

The challenge: an excessively granular structure creates administrative overhead and can complicate entitlement assignment. The right balance depends on the organization's structure and its controlling requirements.

Credit Rate as the Internal Allocation Basis

What a cost center owner needs to know: BTP costs arise in credits, not euros, and are subsequently converted to euros. The credit rate, meaning the contractually fixed price per Capacity Unit, is the basis of internal allocation.

For the cost center, this means: it pays internally not the list price but the negotiated contract credit price. This difference is significant when the enterprise agreement contains a 25 to 35 percent discount on list price. Internal allocation should reflect the actual contract costs incurred, not the list price.

Showback vs. Chargeback: Two Models for Internal Transparency

Two models for internal BTP cost distribution have become established, differing in their binding effect.

Showback shows cost centers and projects their BTP costs without making an actual internal booking. The goal is transparency and awareness of one's own consumption. Showback is the simpler entry point because it does not require changes to internal booking processes. It creates governance incentives through visibility, but no hard budget accountability at the consumer level.

Chargeback actually allocates BTP costs to cost centers or projects, either through internal bookings or through corresponding budget assignments. Chargeback creates real cost accountability at the consumer level and gives them a direct governance incentive: those who use more BTP resources see it in their budget. Chargeback requires a more mature internal financial structure and a functioning subaccount architecture as a prerequisite.

The FinOps Foundation describes showback as a maturity step on the path to chargeback. Many organizations begin with showback to establish transparency first, before introducing the more complex chargeback process.

What SAP-Native Tools Deliver and Where Their Limits Are

The BTP Cockpit and the monthly balance statements provide the raw data for internal allocation. They show consumption per subaccount and per service. They do not, however, offer direct integration into internal ERP systems, cost center attribution beyond the subaccount level, or automated booking logic.

Anyone pursuing a fully automated chargeback solution must ingest the balance statement data into the internal controlling system and process it there. This is solvable but requires a dedicated process and potentially a technical integration.

How the "Cost" Governance Moment Connects to BTP

The governance moment in the cost domain covers four interconnected dimensions for BTP: ACV tracking (does the contracted annual volume match actual consumption?), derived charges (are unexpected overage costs arising that were not planned in the original budget?), invoice reconciliation (does the SAP invoice match the expected balance statement data?), and internal allocation (are BTP costs distributed by consumption to the organizational units that generate them?).

All four dimensions are only addressable with a structured governance process. Anyone who wants to govern BTP costs completely needs not just cockpit access but a systematic governance model that connects contract structure, monitoring, forecasting, and internal allocation.

---

13. FAQ {#faq}

What is the difference between CPEA and BTPEA and which model fits when?

CPEA and BTPEA share the same underlying logic: upfront credit purchase, flexible consumption across a service catalog, volume discounts. The difference is in service scope. CPEA has a historically broad catalog that no longer accepts new services. BTPEA includes all new and strategic services exclusively, among them SAP Analytics Cloud and newer AI services. BTPEA is the recommended model for new customers. Existing CPEA customers should check at their next renewal whether services they need require the switch (source: ASUG, SAP Experts Detail New BTPEA).

What happens to unused BTP credits at year-end?

Unused credits expire at the end of the contract period. There is no automatic rollover. A limited rollover of 10 to 20 percent of unused credits has been achieved in contract negotiations (community knowledge: Rizing, Redress Compliance) but is not part of a standard agreement. The best strategy against expiration is conservative sizing with a contractually secured top-up right at the original terms (source: SAP FAQ CPEA).

How is overage billed under CPEA/BTPEA and what does it cost compared to the contract price?

When the credit pool is exhausted before the end of the contract period, services continue to run but are billed at full list price. All volume discounts from the enterprise agreement are lost. An organization with a 25 percent discount in its contract pays 100 percent of list price in overage instead of 75 percent. An overage cap limiting the maximum surcharge is negotiable (source: SAP FAQ CPEA; community knowledge: Rizing).

What are Capacity Units and how do you convert them to euros?

Capacity Units (CU) are the universal billing metric across all BTP services. The rule of thumb: 1 credit corresponds roughly to one dollar of consumption at list price (contract-dependent). The actual euro equivalent is derived from the credit price fixed in the order form multiplied by CU consumption. The SAP Discovery Center Estimator shows volumes in credits, not euros. Euro amounts result from individually negotiated prices recorded in the order form (source: SAP Discovery Center; SAP Help Portal, Monitoring Usage and Consumption Costs).

What is the difference between Depreciation Group 1 and Group 2 for BTP services?

Group 1 services in BTPEA are supported until the end of the current contract term, analogous to the CPEA protection rule. Group 2 services (Innovation Services) can be removed from the catalog or promoted to Group 1 with at least six months' advance notice. The deprecation risk of Group 2 services requires active monitoring and documentation of all dependencies on those services (source: ASUG, SAP Experts Detail New BTPEA).

How many BTP credits are typically included in a RISE contract?

The BTP credit budget included in a RISE contract depends on the license tier. SAP does not publish standard values for these budgets. In practice, the included budget is frequently a starting point that needs to be supplemented for more extensive BTP usage scenarios in year two or three. Anyone who wants to know their specific BTP credit allotment in the RISE contract will find it in the order form or in the appendix to the RISE contract.

How do I set up credit alerts in the BTP Cockpit?

The BTP Cockpit allows you to configure notifications for subaccount usage. The practically proven alert configuration sets a first notification at 70 to 80 percent consumption and a second at 90 percent. These thresholds provide sufficient time to take proactive measures before unplanned overages arise. The exact configuration steps are in the SAP Help Portal under Monitoring Usage and Consumption Costs (source: SAP Help Portal).

What is the FinOps Inform-Optimize-Operate model and how does it apply to BTP?

The Inform-Optimize-Operate model from the FinOps Foundation is an iterative cycle for technology cost management. Applied to BTP: Inform creates complete visibility into entitlements, active services, and actual consumption. Optimize implements active measures, for example rightsizing, non-production shutdowns, and hyperscaler overlap elimination. Operate embeds governance in the regular operating rhythm, with monthly tracking, quarterly reviews, and an annual compliance check (source: FinOps Foundation, Framework 2025; Licensing and SaaS Capability).

How do I distribute BTP costs to internal cost centers or projects?

The prerequisite is a subaccount structure that reflects organizational units, projects, or cost centers. SAP delivers monthly balance statements at the subaccount level. That data forms the basis for showback (transparency without booking) or chargeback (actual internal allocation). Without a suitable subaccount structure, there is no reliable technical basis for consumption-based allocation (source: SAP Help Portal, Monitoring Usage and Consumption Costs).

What is a hyperscaler overlap and how do I recognize if I am paying twice?

A hyperscaler overlap arises when an organization pays for both BTP services and comparable hyperscaler services (AWS, Azure, GCP) for the same or similar function. Typical overlap areas: analytics, database services, integration middleware, AI platform services. A systematic comparison of the BTP services in use and the hyperscaler services in use identifies redundancies. The optimization decision should be based on relative value: SAP-specific integrations and SAP data structures justify BTP services; generic cloud workloads may run cheaper on the hyperscaler.

When does a migration from CPEA to BTPEA make sense?

A migration makes sense when the organization needs services available exclusively in BTPEA (SAP Analytics Cloud, newer AI services), or when the forward compatibility of the contract vehicle is strategically important. The migration does not require any technical changes to the existing BTP landscape. Before migrating, a full analysis of services in use should confirm whether all of them are included in the BTPEA catalog or whether separate subscriptions will be required (source: ASUG, SAP Experts Detail New BTPEA).

How do I prepare BTP credit data for a renewal conversation with SAP?

A well-prepared renewal conversation is built on three data points: first, actual annual consumption for the expiring period from the monthly balance statements, broken down by the most significant services; second, a forecast for the next contract year that accounts for new use cases, growth in existing workloads, and planned optimization measures; third, an overview of currently used services and their deprecation status in the BTPEA catalog. With this data, the renewal commitment can be substantiated and the negotiation over conditional clauses, such as top-up rights, overage caps, and rollovers, can rest on a documented foundation.

---

14. Next Steps {#next-steps}

Book a Contract Check: if you want to analyze your BTP contract share, evaluate the right model for the next period, or build a foundation for the next renewal conversation, the FinOptory Contract Check is the structured entry point. Four weeks, fixed price, with a clear action recommendation as the output.

FinOptory AI Chat: for an initial assessment of your BTP contract share, the FinOptory AI Chat is available without preparation effort and without any upload requirement.

Further Reading: Pillar 1: SAP Contract Governance Across the Full Portfolio | Pillar 2: SAP Business AI Units as a Separate Credit Pool