Licensing
CPEA
PAYG
Commercial

BTP Licensing & Commercial Models

Complete guide to SAP BTP commercial models — PAYG, CPEA, and Subscription. Understand how services are metered, how to optimise spend, and how to plan entitlements for BTP's major services.

BTP Commercial Models — Service Consumption Flow
Rendering diagram…

Executive Summary

SAP BTP offers three commercial models: PAYG (pay-as-you-go, credit card based), CPEA (prepaid annual credit bundle, most common for enterprise), and Subscription (flat-fee per service). Most enterprise customers use CPEA — a prepaid bundle of BTP credits consumed across all services. Understanding the consumption model of each service is critical for cost planning and avoiding year-end overages.

Commercial Models Explained

PAYG (Pay-As-You-Go)

  • Available for trial, sandbox, and small-scale BTP adoption
  • No upfront commitment — pay monthly based on actual consumption
  • Billed via credit card or monthly invoice
  • Limited to services with PAYG pricing available
  • Not recommended for production workloads — no SLA cost predictability
  • PAYG rates are 3–4× more expensive than equivalent CPEA rates

CPEA (Cloud Platform Enterprise Agreement)

  • Annual prepaid credit bundle (e.g., 100,000 BTP credits/year)
  • Credits consumed by all enabled services: runtime, AI, integration, data
  • Burndown tracked in BTP Cockpit → Cost Center reporting
  • Overage: additional credits purchased at PAYG rates if annual bundle exhausted
  • Most cost-effective for enterprises with consistent BTP usage (>$100k/year)
  • Multi-year discounts: 15–30% reduction on 3-year commitments
  • Some services included at no additional credit cost within CPEA (CF Runtime)

Subscription (Fixed Fee)

  • Fixed fee per service per month or year — completely predictable cost
  • Common for Integration Suite (Enterprise Agreement), Joule, SAP Build Apps
  • No consumption anxiety — unlimited use within defined tier
  • Usually chosen for mission-critical services with guaranteed high usage
  • Cannot be combined with CPEA for the same service (one or the other)

BTP Service Licensing Matrix

Commercial model availability and recommended enterprise choice for the eight most commonly deployed BTP services. Rates are approximate list prices — negotiate with SAP for actual CPEA contract rates.

ServicePAYGCPEA RateSubscriptionMetering UnitEnterprise Choice
HANA CloudYes~0.10 credits/GB-hrNoGB RAM × hourCPEA
AI CoreYes~0.05 credits/unitNoInference unitsCPEA
CF RuntimeYesIncludedNoGB memory × hourCPEA
KymaYesYesNoNode instance hoursCPEA or PAYG
Integration SuiteLimitedYesEnterprise AgreementMessages/monthSubscription
SAP JouleNoLimitedWith S/4HANA tenantConversationsSubscription with S/4
SAP Build AppsTrial onlyYesPer userActive usersSubscription
Build Process AutomationYesYesNoProcess run instancesCPEA

CPEA Budget Planning Example

A TypeScript model for calculating annual CPEA credit consumption across core BTP services. Use this as a starting template for your own sizing exercise — add a 20% buffer before finalising the CPEA contract amount.

cpea-budget-planning.ts
1// BTP CPEA credit planning — annual budget calculation
2const btpServices = [
3  {
4    service: 'SAP HANA Cloud',
5    plan: 'hana-cloud (30GB RAM)',
6    monthlyCredits: 216,  // 30 GB × 24h × 30d × 0.01 credits/GB-hr
7    count: 3,             // 3 production instances
8    annualTotal: 7776,
9  },
10  {
11    service: 'Cloud Foundry Runtime',
12    plan: 'standard (8GB memory)',
13    monthlyCredits: 58,   // 8GB × 24h × 30d × ~0.01
14    count: 3,
15    annualTotal: 2088,
16  },
17  {
18    service: 'SAP AI Core',
19    plan: 'extended',
20    monthlyCredits: 400,  // estimated based on inference volume
21    count: 1,
22    annualTotal: 4800,
23  },
24  {
25    service: 'HANA Cloud (non-prod, stop/start)',
26    plan: 'hana-cloud (16GB RAM)',
27    monthlyCredits: 46,   // ~8h/day × 22 working days × 30d savings
28    count: 3,
29    annualTotal: 1656,
30  },
31  // Estimated total: ~25,000 credits/year for core services
32]
33
34// Recommendation: purchase 30,000 CPEA credits/year (20% buffer)
35// At SAP list price: ~$150,000/year CPEA contract
36// Stop/start non-prod HANA saves ~45,000 credits/year at scale

Cost Optimisation Tactics

Quick Wins for Reducing CPEA Burn
The following optimisations are proven in enterprise DEWA BTP deployments and do not require application changes — only infrastructure scheduling.
HANA Cloud stop/start scheduling
Use BTP Cockpit or BTP CLI automation to stop HANA Cloud in dev/QA subaccounts at 7pm and restart at 7am. Saves credits for the 13 hours the instance is stopped.
~60% of non-prod HANA costs
CF autoscaler — scale to 1 instance at night
Configure CF App Autoscaler to scale non-prod applications to 1 instance (minimum) outside business hours. Production apps should retain full instance count for SLA.
30–50% of CF runtime costs
Kyma serverless functions for low-traffic APIs
Move low-traffic integration APIs to Kyma serverless functions — they consume credits only when invoked, rather than running always-on deployment nodes.
Eliminate always-on node costs
Monthly CPEA burndown review
Identify unexpectedly high-consuming services early. Common culprits: forgotten sandbox HANA Cloud, AI Core test workloads left running, oversized CF apps.
Prevents 10–20% overage waste
SAP sizing workshop
Request a free SAP BTP sizing workshop before the first CPEA contract. SAP architects provide consumption models based on transaction volumes and user counts.
Avoids over-purchasing CPEA

Enterprise Example (DEWA)

DEWA's annual BTP CPEA contract: 150,000 credits/year. Services in scope: 3 HANA Cloud instances (S/4 Extensions, Integration Hub, Smart City), CF Runtime (6 apps across 3 environments), AI Core (Generative AI Hub, model training jobs), and Business Application Studio (development). Integration Suite is on a separate Subscription contract (Enterprise Agreement). Monthly burndown is reviewed by the CTO and BTP admin team in the monthly IT governance meeting. Stop/start automation for non-production HANA Cloud instances saves approximately 45,000 credits/year — 30% of the total annual entitlement.

Governance

CPEA Budget Ownership
Assign CPEA budget ownership to a named BTP Account Manager. Restrict entitlement assignment to 2–3 Global Account administrators. Use BTP directory-level chargeback reporting to attribute costs to individual business units. Include BTP cost review as a standing agenda item in monthly IT governance meetings.

Best Practices

Weekly CPEA burndown review

Use BTP Cockpit Cost Center reporting to track CPEA credit consumption weekly. Monthly reviews are too infrequent to catch anomalies before they become overages.

Set cost budget alerts

Configure budget alerts at 70%, 90%, and 100% of annual CPEA entitlement in BTP Cockpit. Alerts give time to act before overage charges kick in.

Stop/start non-production instances

Automate HANA Cloud and CF app shutdown outside business hours (7pm–7am, weekends). Saves up to 60% of non-production credit consumption.

Negotiate 3-year CPEA with volume discount

Multi-year CPEA contracts attract 15–30% discounts over list price. Volume tiers reduce per-credit cost at 100k, 250k, and 500k+ annual credit thresholds.

Request SAP Quarterly Business Review

SAP provides free QBR sessions for enterprise customers — includes license optimisation recommendations, upcoming CPEA contract review, and early renewal pricing.

Common Pitfalls

Unmonitored CPEA burndown
Without weekly monitoring, overage is typically discovered at year-end when the bill arrives. CPEA overage is billed at PAYG rates — 3–4× the CPEA credit rate.
Running non-prod HANA Cloud 24/7
Development and QA HANA Cloud instances running around the clock waste ~60% of their annual credit allocation. Stop/start scheduling is a quick win.
Choosing PAYG for steady-state workloads
PAYG is 3–4× more expensive than CPEA for predictable, consistent workloads. Any service running >50% of the time should be evaluated for CPEA instead.
Underestimating AI Core consumption
AI Core inference usage scales exponentially with user adoption. Initial estimates are almost always too low — add 40% buffer and monitor weekly for the first 3 months.