SAP’s Business Technology Platform uses capacity units as a unified currency to measure consumption across all services. CIOs and CTOs need to understand how key services — Integration Suite, extension runtimes, HANA Cloud, and analytics — consume these credits to accurately predict costs, avoid expensive overages, and align BTP spending with business needs.
Capacity units are SAP’s standardised metric for usage on BTP. Instead of buying fixed licences per service, you purchase a pool of cloud credits (where one credit roughly equals $1 at list price) that can be spent on any eligible BTP service. Each service’s usage is measured in technical terms (transactions, memory hours, API calls) and converted into capacity units using published conversion rates.
This unified model simplifies procurement — it functions like a prepaid cloud account covering all BTP services. The flexibility is high, but so is the responsibility: credits are use-it-or-lose-it within the contract period, and going beyond your credit allotment incurs pay-as-you-go charges at full list rates.
You commit to a credit pool (e.g., 50,000 credits for a year). As teams use services, SAP measures consumption, converts it to capacity units using published rates, and deducts from your pool monthly.
Unused credits for one service can be applied to another. A shared pool means integration savings can fund extension development — but also means one overused service can drain the entire pool.
Unused credits typically expire at the end of the year or contract. Size your commitment carefully: over-committing wastes budget, while under-committing triggers expensive overage rates.
Each service has a specific conversion rate: 1 hour of compute might equal 0.1 credits, while 10,000 API calls might equal 6 credits. These rates are published in SAP’s service catalogue and Discovery Centre.
The key for IT leaders is to translate anticipated usage (number of integration messages, GB of memory, data volumes) into capacity units per month and thus into credits. This requires collaboration between architects and financial planners — know your integration traffic, user counts, data volumes, and runtime hours to avoid surprises.
A practical example illustrates the mechanics: suppose you commit to 50,000 BTP credits for a year. In a given month, your teams consume 800 credits on Integration Suite (message processing), 500 on HANA Cloud (database memory and storage), 300 on Cloud Foundry runtime (custom application hosting), and 200 on other services. That is 1,800 credits subtracted from your pool in a single month. At that burn rate, your annual pool would be exhausted in approximately 28 months — comfortable headroom. However, if a new project doubles your integration traffic mid-year, the monthly burn could jump to 2,600 credits, exhausting the pool in only 19 months and triggering expensive overage charges in the final quarter. This is why continuous monitoring and quarterly re-forecasting are essential, not optional.
Read Allocating SAP BTP Costs Across Projects and Teams.
The SAP Integration Suite (covering cloud integration middleware and API management) often becomes the largest consumer of capacity units due to message traffic. SAP measures integration usage primarily by the number of messages (transactions) processed.
Each Integration Suite tenant includes a base message quota (typically 10,000 messages per month included per tenant). Beyond this, usage is charged in blocks of 10,000 messages, with each block costing a defined number of credits.
| Monthly Message Volume | Approx. Blocks | Approx. Credits/Block | Monthly Credit Cost |
|---|---|---|---|
| 100,000 messages | 9 (after 10K free) | ~6.0 | ~54 credits |
| 500,000 messages | 49 | ~5.5 | ~270 credits |
| 2,000,000 messages | 199 | ~4.0 | ~796 credits |
| 5,000,000 messages | 499 | ~2.8 | ~1,397 credits |
| 10,000,000 messages | 999 | ~2.2 | ~2,198 credits |
“A retailer’s integration error — a misconfigured loop — sent millions of extra messages over a weekend, tripling their monthly credit burn and incurring tens of thousands of euros in unplanned costs. Monitor message counts and set alerts for anomalies: a stuck process triggering retries can drain your credit budget before anyone notices.”
Many enterprises adopt a hybrid approach: using a subscription for a base load of integration traffic and credits for excess usage or additional services. If you plan to process 8 million messages monthly, compare whether the flat subscription (with its included volume) costs less per year than consuming the equivalent from your credit pool.
A mid-size enterprise runs 35 integration interfaces connecting S/4HANA to CRM, warehouse management, e-commerce, and banking systems. Monthly message volume across all interfaces totals approximately 350,000 messages. After deducting the 10,000 free messages per tenant, 340,000 chargeable messages remain — that is 34 blocks of 10K. At the low-volume tier rate of approximately 6 credits per block, monthly credit consumption is ~204 credits, or approximately 2,448 credits per year at list price.
However, 60% of these messages originate from a single high-volume interface (daily order synchronisation). By consolidating order payloads into batch messages rather than sending individual orders, the enterprise reduced message counts by 40% on that interface alone — cutting annual integration credits from 2,448 to approximately 1,560, a saving of nearly $900 per year at list price. Small architectural decisions compound into significant credit savings over a multi-year contract term.
When evaluating whether to use subscription versus credit consumption for Integration Suite, the critical variables are message volume stability and growth trajectory. Subscription tiers provide a fixed annual cost regardless of actual usage within the included volume — ideal when traffic is predictable and steady. The credit model is preferable when message volumes fluctuate significantly (seasonal businesses, project-based integrations) or when you are still ramping up interfaces during an S/4HANA implementation. A useful rule of thumb: if your monthly message volume varies by less than 20% from the mean, a subscription likely delivers better value; if it varies by more than 40%, the credit model’s flexibility is worth the premium per message.
Beyond integration, SAP BTP provides platforms for building and running extensions and custom applications — Cloud Foundry runtime, Kyma (Kubernetes) runtime, and ABAP environment. SAP measures these compute and storage resources with capacity units based on memory, CPU, and duration. Additionally, SAP HANA Cloud database consumption is expressed in capacity units by combining memory allocation, storage volume, and throughput into a single figure — a larger instance with more memory and storage consumes proportionally more units per hour than a smaller one. HANA Cloud is often the second-largest credit consumer after Integration Suite in a typical BTP estate.
Cost is based on the memory allocated to app instances, measured hourly. Running a single 1 GB app: ~0.1 credits/hour × 720 hours/month = ~72 credits/month. Ten such instances running continuously: ~720 credits/month. Unused capacity is wasted — leaving a dev system running nights and weekends still incurs hourly charges.
Charged based on nodes and storage consumed. One Kyma node (2 vCPU, 8 GB RAM): ~0.24 credits/hour. A 3-node cluster running continuously: ~518 credits/month. Persistent storage volumes also count (~0.02 credits per GB/hour). Multiple nodes with high availability and large data volumes add up quickly.
ABAP PaaS uses “ABAP Compute Units” bundling SAP modules for licensing discounts memory, CPU, and usage into capacity units. AI services charge per GB-second of execution. Large ABAP instances or heavy AI model training can consume dozens of capacity units per hour — plan capacities carefully and shut down when not needed.
Smart cloud management yields significant benefits. Treat your BTP runtime resources with the same FinOps discipline you would apply to any public cloud environment. The principles are identical to AWS or Azure cost optimisation: right-size resources, eliminate idle capacity, schedule non-production downtime, and govern provisioning. The difference with BTP is that all runtime costs draw from the same credit pool as integration and analytics, so runtime waste directly reduces capacity available for other services.
Do not allocate 4 GB of memory if 1 GB suffices. Review application resource utilisation monthly and scale down over-provisioned instances. A single right-sizing pass across your BTP estate typically reduces runtime credit consumption by 15–25%.
Development, demo, and test environments can be stopped during off-hours (nights, weekends). Unlike perpetual licences, the meter stops when the service is off. Shutting off an 8 GB test node for 12 hours daily saves approximately 50% of its monthly cost.
Allow applications to scale out for performance during peak periods, but set maximum instance limits to control cost during unexpected spikes. Without caps, a traffic surge can spawn dozens of instances and consume weeks’ worth of credits in hours.
Each sandbox sub-account, idle service instance, or forgotten prototype application still consumes a trickle of credits. A monthly cleanup review typically eliminates 5–10% of wasted consumption across the BTP estate.
SAP offers a BTP free tier for many services. Encourage development teams to use the free tier for prototyping and proof-of-concept work, preserving paid credits for production workloads that deliver genuine business value.
One capacity unit does not have a fixed price — it depends on the service and your SAP contract negotiation strategiesed discount. As a general rule, under the standard enterprise agreement, one credit is roughly equivalent to $1 of list-price consumption. If you negotiated a 20% volume discount, you effectively pay $0.80 per credit.
SAP provides tools in the BTP cockpit to monitor credit consumption by service and sub-account. Set up alerts when consumption hits 50%, 75%, and 90% thresholds. Monthly consumption reports from SAP detail each service’s usage and cost — review these in the same manner as a cloud bill. Many enterprises establish internal chargeback models using these reports, allocating BTP credit costs to the projects or departments that consume them.
Effective chargeback requires sub-account architecture that mirrors your organisational structure. Create separate BTP sub-accounts for each major project, department, or cost centre. This enables granular consumption tracking without additional tooling — SAP’s cockpit reports consumption at the sub-account level natively. When a project team can see that their integration interfaces consumed 180 credits last month (and that 45 of those credits came from a forgotten test environment), behaviour changes rapidly. Visibility drives accountability.
For enterprises with large BTP estates (50+ active services or hundreds of integration interfaces), consider augmenting SAP’s native tools with custom reporting dashboards. Export consumption data via SAP’s APIs and visualise it in your existing BI platform (Analytics Cloud, Power BI, or Tableau). This enables cross-correlation with business metrics — for example, tracking the cost-per-order-processed through your integration layer, or the cost-per-user for a custom BTP extension. These unit economics inform architectural decisions: if one integration pattern costs $0.003 per transaction while an alternative costs $0.001, the business case for refactoring becomes concrete.
Redress Compliance provides independent SAP licensing advisory — fixed-fee, no vendor affiliations. Our specialists help enterprises optimize BTP consumption, negotiate cloud credits, and structure cost-effective agreements.
Explore SAP Advisory Services →SAP BTP offers three primary commercial models. Choosing the right model (or mix of models) is crucial for cost optimisation:
| Model | Commitment | Pricing | Best For |
|---|---|---|---|
| Pay-As-You-Go | None; billed monthly | List price; no discounts | Pilots, POCs, sporadic or unpredictable usage |
| CPEA / BTPEA Credits | Annual credit commitment | 20–40% below list (volume-tiered) | Multi-service enterprises with predictable aggregate usage |
| Subscription | 1–3 year term per service | 15–35% below list | High, steady single-service workloads (e.g., Integration Suite at scale) |
Many enterprises use a hybrid strategy: for core, predictable workloads (constant high-volume integration or a production HANA database), a subscription provides cost certainty. For everything else (new applications, variable or innovative workloads), a credit pool delivers flexibility. SAP’s BTP contracts allow mixing models — you might hold a CPEA for most services but also a subscription for one or two high-consumption services where the per-unit cost is lower.
The decision between CPEA and BTPEA (SAP’s newer BTP Enterprise Agreement) also warrants careful analysis. BTPEA is designed specifically for BTP-centric customers and may offer slightly different credit conversion rates or discount structures compared to the broader CPEA model. Ask SAP to provide a side-by-side comparison of credit costs under each model for your specific workload profile — the difference can be 5–15% on annual spend for large BTP estates.
When negotiating any BTP commercial model, pay particular attention to renewal escalation terms. SAP’s standard contracts may include annual price increases of 3–5% on credit prices or subscription fees. Over a five-year term, a 4% annual escalation compounds to a 22% increase in per-credit cost. Negotiate a cap on annual increases (ideally CPI-linked or a fixed 2% maximum) and secure the right to renegotiate credit volumes at renewal without being forced into SAP’s proposed escalation schedule.
A global manufacturer took a CPEA committing $500K for BTP credits over three years ($167K/year). They allocated credits roughly as: 40% integration, 30% extensions, 20% analytics and other services, and 10% contingency. By monitoring consumption monthly and adjusting team allocations quarterly, they ended year one at 95% credit utilisation — near-perfect planning that maximised value without waste or overage.
An enterprise on RISE with SAP migration guide with SAP received 5,000 BTP credits included as a starter allocation. Without consumption governance, teams built integrations and workflows enthusiastically. Within six months, all 5,000 credits were exhausted, requiring an unplanned mid-term purchase at higher rates. The lesson: treat included credits as real budget, assign a consumption owner, and track usage from day one — “free” credits disappear faster than expected when there is no accountability.
Even experienced IT procurement teams make errors when sizing BTP credit commitments. Understanding these pitfalls helps you avoid the most expensive mistakes:
Teams frequently estimate Integration Suite costs based on the number of logical transactions (e.g., 1,000 orders per day = 1,000 messages). In reality, each order may trigger multiple messages across different integration flows (acknowledgements, status updates, error handling), and large payloads count as multiple messages. Actual message counts are typically 3–5× higher than naive estimates.
Development, testing, staging, and training environments collectively consume 30–50% of total BTP credits in many organisations. Teams that size their credit commitment based solely on production workload projections are surprised when non-production environments consume nearly as much as production by the end of the year.
BTP services like Event Mesh, Connectivity Service, HANA Cloud backups, and logging consume credits continuously in the background. These “infrastructure” services are easy to overlook during sizing exercises but collectively can account for 10–15% of total credit consumption across a mature BTP estate.
Sizing credits based on a point-in-time estimate ignores growth. If your S/4HANA implementation is adding new integrations quarterly, BTP consumption grows accordingly. Build growth curves into your forecast — a 10% quarterly increase in integration volume compounds to 46% annual growth.
The most effective approach to credit sizing combines bottom-up estimation (calculating consumption for each planned service and interface) with top-down validation (comparing the total against benchmarks from similar-sized SAP deployments). If your bottom-up estimate differs significantly from what comparable enterprises consume, investigate the gap before committing to a credit volume. SAP’s customer success team and independent advisory firms like Redress Compliance can provide benchmark data to validate your estimates.
Inventory all planned integrations, extensions, and databases. Use SAP’s calculators or past system metrics to estimate monthly capacity unit consumption, then size your credit purchase or subscription accordingly. This prevents both under-buying (overage costs) and over-buying (wasted credits).
How much should your SAP BTP consumption actually cost? Our free calculator benchmarks your capacity unit usage and identifies optimization opportunities.
Take the Free Assessment →Treat BTP like a utility bill. Set up real-time monitoring and monthly reviews. Establish alerts for unusual spikes in message counts, memory usage, and API call volumes. Early detection of anomalies (a misconfigured job flooding the system) can save thousands in credits.
Align the model to the workload. High, steady usage warrants a subscription. Sporadic or evolving usage fits the credit model. Many enterprises subscribe to a base Integration Suite package for predictable traffic and cover spikes with flexible credits.
Higher commitments yield better per-credit rates. Ensure your contract includes tiered pricing to support future growth. Clarify overage terms — ideally cap overage rates or arrange the ability to true up at discounted rates rather than full list pricing.
Define who can activate costly services and require justification. Use chargeback or showback to make teams aware of their consumption. When business units see a cost attached to leaving a test system running, they shut it down on time. A culture of cost transparency treats capacity units as real currency, not an IT freebie. Appoint a dedicated BTP consumption owner — a single individual or small team within your SAP centre of excellence — who is accountable for monitoring dashboards, managing provisioning requests, conducting quarterly optimisation reviews, and reporting consumption trends to finance and IT leadership.
BTP consumption patterns change as new integrations go live, applications scale, and business requirements evolve. A forecast built during contract signing may be inaccurate six months later. Conduct quarterly reviews comparing actual consumption against projections, update forecasts for the remaining contract period, and escalate to procurement if the trajectory suggests credit exhaustion or significant underutilisation before term end. Proactive management avoids both expensive overages and wasteful expiry of unused credits.
A capacity unit is a standardised measure of service usage (such as 1 GB memory-hour, or 10,000 messages) on SAP BTP. Cloud credits are the currency you purchase. You spend credits as you consume capacity units. Each service’s consumption is quantified in capacity units, and those units are deducted from your credit balance — with one credit roughly equal to one unit of consumption at list price, subject to your contract’s negotiated discounts.
Start by estimating your monthly message count through Integration Suite. For 100,000 messages per month, after the first 10K free per tenant, you have 90K chargeable — that is 9 blocks of 10K at approximately 6 credits per block, totalling ~54 credits per month. Higher volumes benefit from tiered pricing where the per-block cost drops. Factor in the large message multiplier (payloads over 250 KB count as multiple messages). SAP provides calculators in the Discovery Centre for estimating credit consumption. Add a 15–20% buffer for unexpected spikes.
You are not cut off, but you will be charged overage at pay-as-you-go rates for the excess usage. Those rates are typically undiscounted list prices, making them significantly more expensive than your committed rate. Monitor consumption proactively and either curb usage or purchase additional credits at your negotiated discount before running out. Always clarify overage terms in your contract — some agreements allow automatic top-ups at the same discount, while others default to full list pricing.
Generally, no. Unused credits expire at the end of the contract period (usually annually). The model is use-it-or-lose-it. If you purchased 100,000 credits and used only 90,000, the remaining 10,000 are forfeited. Some customers negotiate partial rollover provisions (typically 10–25%), but this is not standard. Aim to use close to 100% of your commitment by monitoring quarterly and accelerating planned projects if consumption is tracking below forecast.
It depends on predictability and cost. If a service will be used heavily and steadily (e.g., 5 million integration messages monthly or a fixed-size HANA database running 24/7), compare the subscription price against the equivalent credit consumption. Subscriptions are often cheaper for known constant workloads. Credits excel when you have many different services or uncertain usage patterns. Many enterprises use both: subscribe for “big rocks” they can predict, and use credits for everything else. Calculate the yearly cost via credits (list price minus your discount) versus a subscription quote for equivalent capacity.
Yes. SAP allows you to run a CPEA credit pool alongside separate subscriptions for specific services. You might also maintain a pay-as-you-go account for development sandboxes. This hybrid approach is common and often delivers the best overall cost outcome: subscriptions lock in rates for predictable high-volume services, while the credit pool covers variable and multi-service workloads. Ensure your contract explicitly permits this mixing and that credits cannot be double-counted against subscription entitlements.
Redress Compliance provides independent, vendor-neutral analysis of SAP BTP consumption, credit sizing, and commercial model selection — ensuring you pay only for what you need.
Book a Consultation SAP Contract Negotiation Service →Book a free consultation with our licensing specialists. No obligations, no vendor ties — just independent advice tailored to your situation.
Book Your Free Consultation →