Introduction – Why You Must Understand BTP’s Consumption Model
SAP Business Technology Platform (BTP) uses a consumption-based pricing model.
This means your costs directly reflect how much you use the platform’s services, rather than a flat license fee. Misunderstanding how credits and metering work can quickly lead to budget overruns.
SAP offers multiple licensing models under BTP — Pay-As-You-Go (PAYG), Cloud Platform Enterprise Agreement (CPEA), and Subscription. Each model handles consumption and billing differently, but all require vigilance.
With SAP BTP, cost control starts with knowing what every click, API call, or gigabyte costs — before it happens.
Understanding the BTP consumption model is crucial for CIOs, IT architects, and FinOps teams. It’s not enough to sign a contract; you need to know how every service usage translates into charges.
The following sections explain how SAP measures usage, how the credit system works, and ways to manage costs proactively.
Read our complete guide for SAP BTP Licensing & Cost Control: Managing Your SAP Cloud Platform Costs.
How SAP Measures BTP Usage
SAP BTP services are metered – each service has specific units that quantify usage. Consumption is tracked in these units and then converted into credits (the currency for BTP usage).
Whether you pay per month (PAYG) or draw down a prepaid credit pool (CPEA), every action on BTP has a measurable unit cost.
Examples of Consumption Units: Common metrics include API calls, data storage, computing time, and workflow executions.
For example:
- API calls (Integration Suite): Measured per 1,000 calls.
- Database storage (SAP HANA Cloud): Measured per gigabyte per month (GB/month).
- Compute runtime (Kyma or Cloud Foundry): Measured per vCPU-hour of usage.
- Workflow executions (Process Automation): Measured per number of workflow runs.
These units tie to SAP’s price list. Each service defines how usage translates to credits.
In essence, every technical action (storing data, processing an API message, running a compute instance) is metered and given a price in credits.
Consumption Flow: The process for how usage becomes a charge is straightforward:
- You use a service (e.g., deploy an integration flow, spin up a database, execute workflows).
- SAP measures that usage according to the service’s metric (e.g., counts the API calls or gigabytes used).
- The measured units are multiplied by the service’s rate (credits per unit) as defined in the BTP pricing catalog.
- The corresponding credits are deducted from your credit pool (if you have a CPEA agreement) or billed to you (if you’re on PAYG) for that period.
This means costs accumulate in real time based on activity. For example, 10GB of database usage over a month or 10,000 API calls in a day will each consume a certain number of credits as defined by SAP.
What Drives Consumption? Many factors influence your BTP credit burn. Keep an eye on these drivers of cost:
- Number of active services: Every running service (databases, application runtimes, integration tenants, etc.) incurs usage. More services = more consumption.
- Data storage volume: Large databases or file storage will consume credits continuously (charged per GB of storage per month).
- API and integration volume: High API call counts or message processing frequency (e.g. in Integration Suite or API Management) quickly add up in credits.
- Automation and workflow frequency: Frequent workflow or RPA bot executions will consume credits per run.
- Continuous runtimes: Running application environments (Cloud Foundry, Kyma, ABAP runtime) incur hourly compute charges even when idle, provided they remain active.
By understanding these metrics, you can predict how certain actions will impact your credit usage before you commit them.
Pay-As-You-Go (PAYG) Model
Definition: Pay-As-You-Go for SAP BTP is a purely metered model with no upfront commitment. You simply pay each month for whatever services you actually used in the prior month.
There is no pre-purchased credit pool; costs are calculated in arrears based on usage.
Advantages:
- Zero upfront cost: You don’t need to buy credits in advance. Great for pilots and proof-of-concepts.
- Flexibility: Ideal for experiments or unpredictable workloads, since you pay only for what you use.
- Transparency: Detailed monthly usage reports show exactly what was consumed and charged.
Drawbacks:
- Higher unit prices: PayG rates are at full list price. There are no volume discounts, so per-unit costs are higher than with committed agreements.
- Budget unpredictability: Monthly spend can spike if usage spikes. There’s no built-in cap – a surge in activity will directly translate to a higher bill.
- Harder to negotiate: With no commitment, you have less leverage for discounts. Large-scale use on PayG can become expensive.
For example, a small integration test that costs a few hundred euros under PayG might cost significantly less under a CPEA or subscription (due to discounts or included capacity if usage grows). PayG is best suited for initial trials or sporadic needs.
Tip: Use PAYG for short-term experiments and pilots — not for mission-critical production systems. As soon as usage becomes steady or significant, consider moving to a credit agreement to save on costs.
How to choose a consumption model, SAP BTP Subscription vs Pay-As-You-Go: Choosing the Right Model for Your Cloud Strategy.
Cloud Platform Enterprise Agreement (CPEA) Model
Definition: The CPEA model is a prepaid credit pool for SAP BTP services.
You commit to purchasing a certain amount of cloud credits (for example, €100,000 worth) for a time period, and then consume services against that credit balance over time.
- How It Works: You buy a pool of credits upfront (e.g., 100,000 credits, where 1 credit is roughly €1 in value). As you use BTP services, SAP deducts the corresponding credit amount from your pool each month. Each service has a conversion rate (usage units to credits) set in the price list. If you have credits remaining at the end of the term, they typically expire (use-it-or-lose-it) unless you have negotiated rollover terms. Conversely, if you burn through your credits before the term ends, you may incur overage charges or need to purchase additional credits.
Benefits:
- Flexibility across services: Credits can be spent on any BTP service. You’re not locked into specific services – if priorities shift, you can allocate your credit spend to different services as needed.
- Volume discounts: Buying a large block of credits often comes with discounted rates (lower cost per unit). High commitments give you better pricing than PAYG on many services.
- Simplified billing: All usage is consolidated into one credit balance and one contract. It centralizes your cloud spend into a single agreement and invoice stream.
Risks:
- Expired credits: Unused credits at the end of the period expire worthless by default. If you over-commit (buy too many credits and don’t use them), that money is wasted.
- Governance required: You must actively track the burn rate of your credits. Without monitoring, you might run out of credits unexpectedly or have a large unused amount nearing expiration.
- Limited visibility without tools: Out of the box, it can be hard to see detailed usage per service unless you regularly check the BTP cockpit or reports. Without proper monitoring and alerts, you might not notice an oncoming shortfall or overflow.
Monitoring Tip: Set up automated alerts in the SAP BTP Cockpit for when your credit consumption reaches critical thresholds (for example 50%, 75%, and 90% of your credit pool). This ensures you get notified well before you run out of credits or time.
Sample Metric Table: To illustrate how different services convert usage into credits, here are a few example service rates under a CPEA model (note: actual rates vary by region and contract):
| Service | Unit Metric | Credit Rate Example |
|---|---|---|
| SAP HANA Cloud | per 10 GB storage/month | 1 credit per 10 GB |
| SAP API Management | per 1,000 API calls | 0.05 credit |
| SAP Workflow Service | per 100 workflow runs | 0.1 credit |
| SAP Kyma Runtime | per vCPU hour | 0.2 credit |
In practice, SAP provides a detailed rate card for all services. For instance, if SAP HANA Cloud charges 1 credit per 10 GB-month, using 500 GB of storage for a month would consume 50 credits. These conversion rates help you estimate how a planned workload (like X GB of data or Y number of API calls) will draw down your credit balance.
Subscription Model
Definition: The subscription model is a fixed-price contract for specific BTP services (or bundles of services) with defined capacity. Instead of paying per actual usage, you pay a set fee for a certain usage entitlement, typically over a 1-3 year term. This is the classic SaaS licensing approach.
When to Use: Subscriptions make sense when you have steady, predictable workloads or require strict budget predictability. If you know a service will be used at a relatively constant level (e.g., a stable application or a fixed number of integration transactions each month), a subscription can lock in the cost.
Subscriptions are also common when BTP services are bundled into a larger SAP contract (for example, included with RISE with SAP or as part of an enterprise agreement for a core product).
Advantages:
- Predictable costs: You pay the same amount every month or year, regardless of minor usage fluctuations. This makes budgeting and forecasting straightforward – no surprises.
- Cost stability: There’s a capped cost. Even if usage spikes, you typically won’t pay extra (up to the limits of your subscription). This can protect against cost overruns.
- Potentially favorable pricing: Because you’re committing to a term, SAP often gives competitive pricing for that service. Subscriptions can sometimes be cheaper for a given level of usage than consuming equivalent credits, especially if included as part of a larger deal.
Drawbacks:
- Less flexibility: Funds are tied to a specific service. You cannot reallocate a subscription’s value to another service. If your priorities change (e.g., you need more of Service A and less of Service B), subscriptions can’t easily adjust — unlike credits which are fungible across services.
- Risk of overbuying: If your usage drops or never reaches the subscribed amount, you still pay the full price. Unused capacity in a subscription is essentially wasted spend. Sizing the subscription correctly is critical.
- Growth limits: If you exceed your subscription’s included capacity, you typically need to purchase an upgrade or add-on; you can’t just consume more and pay as you go. This means you must monitor usage to ensure you don’t hit caps that could interrupt service.
Tip: If you have a well-understood, stable workload, a subscription often saves money compared to pay-per-use credits. Lock in subscriptions for the “base load” services you know you’ll run, and use credits or PAYG for variable or new needs.
In short: If you know what you’ll run, a subscription can be more cost-effective than credits.
How Credits Convert to Cost
It’s important to understand the translation from credits to actual currency cost. Typically, one credit is roughly equivalent to €1 (or $1) at list price.
SAP may value credits slightly differently in some contracts, but the mindset is that credits are like money in an account, and each service withdraws a certain number of credits as you use it.
Example: Suppose you purchase €100,000 worth of BTP credits for the year. Now consider a specific usage: you make 2,000,000 API calls via the Integration Suite, and the rate for API calls is 0.05 credits per 1,000 calls.
- You used 2,000 batches of 1,000 calls (since 2,000,000 / 1,000 = 2,000).
- At 0.05 credits per batch, that consumption equals 100 credits (2,000 × 0.05).
- Those 100 credits correspond to €100 (since 1 credit = €1). This amount would be deducted from your credit pool (or billed in PAYG).
- After this usage, your remaining credit balance would be €99,900 (out of the original €100,000).
This simple example shows how metered usage converts into real costs. Every service has similar conversion logic, so understanding each key service’s “credits per unit” rate is essential to forecast costs.
Financial Control Tips: To manage BTP spend, treat credits like a budget that needs active management:
- Forecast usage by service: Estimate your monthly usage of each major service (compute hours, GB of storage, number of API calls, etc.) and translate that into expected credit burn. This helps predict your run rate.
- Include a buffer: Always include a safety margin for unplanned growth or spikes. Projects often expand or usage increases over time – having, say, 10-15% credits in reserve can cover unexpected usage without immediate overage.
- Track at the service level: Don’t just watch the total credit pool; monitor consumption per service. One runaway service (like an integration sending thousands of unexpected messages) can drain the pool. Service-level tracking lets you pinpoint where credits are going and react (optimize that service, allocate more budget to it, etc.).
Avoiding Common Cost Pitfalls
Even with a solid plan, there are common mistakes that can cause surprise costs in SAP BTP. Being aware of these pitfalls can save your budget:
- Pitfall 1: Idle services left running. (Example: A Kyma cluster or Cloud Foundry instance running on nights/weekends or test systems left active.) Fix: Implement auto-stop or schedule downtime for non-production systems. Regularly audit for unused instances and shut them down to stop the meter.
- Pitfall 2: Misaligned contract and usage. (Example: Purchasing too many credits that go unused, or too few credits, and incurring expensive overages.) Fix: Revisit your usage forecasts quarterly. If you’re consistently under-consuming or overrunning your credits, adjust your commitment or contract size in advance. Renegotiate if necessary to right-size your credit pool.
- Pitfall 3: Lack of ownership in BTP cost governance. (Example: No single person or team monitors the BTP spend, so issues go unnoticed.) Fix: Assign a cost owner for each BTP subaccount or project. This owner should regularly review usage and spending for their area, ensuring accountability and quick response if consumption jumps unexpectedly.
- Pitfall 4: Missing rollover clause for credits. (Example: You have €10k in credits left at year-end that expire, losing value.) Fix: Negotiate contract terms up front to handle unused credits. For instance, include a rollover clause such as “Unused credits at term end shall roll forward into the next 12-month term or be applied to future service consumption.” This protects you from losing prepaid value. If SAP won’t allow rollover, aim for other concessions (like converting leftover credits to a support fund or training credits).
By preemptively addressing these issues, you can avoid many of the budgetary surprises that others have faced with BTP.
Cost Control & Monitoring Framework
To keep SAP BTP costs in check, you need a proactive governance framework. Here’s a checklist of practices and metrics for ongoing cost control:
Governance Checklist:
- Monthly spend reviews: Have FinOps or IT finance review BTP usage reports every month. Discuss variances from the plan and highlight any anomalous spikes.
- Usage alerts: Configure automated alerts when credit consumption reaches key thresholds (e.g., 80% and 90% of your credit pool, or specific budget limits per project). Early warning allows corrective action (throttle usage, buy more credits, etc.).
- Credit expiry tracking: Keep track of when your prepaid credits expire. Set reminders well in advance of contract end to either ramp up usage (to use them) or negotiate extensions.
- Cost center allocation: Map BTP subaccounts or services to internal cost centers or projects. This way, you can attribute costs to the responsible teams and avoid “shared pool” confusion. Each team sees their spending, which encourages accountability.
- Align budget with growth: Regularly update your budget forecasts to match service growth trends. For example, if you know an application user base is growing 20% quarter-over-quarter, anticipate the corresponding increase in BTP resource usage and budget for it.
Key Metrics to Monitor: Establish KPIs to track the efficiency of your BTP usage:
- Monthly burn rate variance: Compare your actual credit consumption each month against your forecast. Large deviations (above a certain threshold) should trigger investigation.
- Active vs. inactive resources: Count how many subaccounts, service instances, or environments are running vs. how many are actually used. A high number of idle resources might indicate opportunities to shut down and save credits.
- Unused credit percentage: If you’re on CPEA, monitor what percent of your credits remain unused as the term progresses. For example, halfway through the year, you should have roughly half your credits consumed. If you find you’ve only used 20% or conversely 80% much earlier than halfway, it’s a sign to adjust consumption or renegotiate volumes.
By combining governance processes with these metrics, you create an early warning system for cost issues. This framework ensures that BTP’s flexibility doesn’t turn into a financial surprise.
5 Practical Ways to Manage SAP BTP Consumption
Finally, here are five concrete actions you can take to keep your SAP BTP costs under control:
- Monitor credit burn weekly: Don’t wait for monthly invoices. Log in to the SAP BTP Cockpit each week to check how many credits you’ve used. Regular monitoring helps catch unusual usage early.
- Automate idle shutdowns: Set up scripts or use SAP tools to automatically stop or scale down services during off-hours. For example, turn off development/test systems at night or scale down runtimes on weekends. Eliminating idle consumption saves a significant chunk of credits.
- Use subscriptions for steady workloads: If you have an application or integration with consistent demand, see if a subscription makes sense. Shifting predictable usage to a fixed-cost subscription can reduce your reliance on credits for those loads and often lowers the unit cost.
- Negotiate rollover rights: Before signing a CPEA or enterprise agreement, negotiate terms for unused credits. Even if SAP won’t allow unlimited rollover, aim for partial carryover or conversion of unused credits into a service (like extended support or training) so the value isn’t lost.
- Assign a cost owner per subaccount: Make someone responsible for the spend in each project or subaccount. This person should get the consumption reports, set up the alerts, and be accountable for optimizing usage. Clear ownership ensures that BTP consumption is actively managed rather than an afterthought.
By following these practices, organizations can fully leverage SAP BTP’s capabilities while avoiding cost surprises.
The key is to be as agile in cost management as you are in deploying BTP services — with the right awareness and controls, you can innovate on SAP BTP without blowing your budget.
Read about our SAP Services.
