SAP BTP — the credit pool that always looks generous on day one.

Credits are pre-purchased, discounted, and dated — and they expire.

SAP BTP runs on the Cloud Platform Enterprise Agreement (CPEA) consumption model. The buyer commits to an annual credit pool at a discount versus pay-as-you-go list pricing. Credits draw against any of 90+ BTP services: Cloud Integration, Cloud Foundry runtime, HANA Cloud, Build Apps, AI Core, Joule, SAP Analytics Cloud and others. Each service has its own per-unit consumption rate published in the SAP Service Catalogue.

The economics issue: unused credits expire at the end of the contract year by default. The renewal pricing references the prior year's commitment. A buyer who under-consumed in year one faces a difficult choice in year two — either renew at the same commitment (knowing the same under-consumption is likely) or step down the commitment (losing the volume discount). The structure favours SAP in either outcome.

RISE bundles BTP credits — at allocations that rarely match consumption.

Inside a RISE with SAP contract, BTP credits arrive as a fixed annual allocation determined at RISE signature. The allocation is typically modest relative to what the buyer will eventually consume if BTP is genuinely adopted. The risk pattern: in year one, the buyer is mid-migration and consumes well below the allocation, so credits expire. In year three, the buyer has built integration and extension workloads on BTP and consumes well above the allocation, so credits are top-up purchased at list. SAP captures margin at both ends.

The negotiation move at RISE signature is to sever BTP from the RISE bundle commercially: take a smaller allocation inside RISE, with a separately negotiated CPEA agreement for the actual BTP workload. The CPEA carries better discounts on volume and clearer carryover terms; getting both halves priced against benchmark is standard scope in a buyer-side SAP contract negotiation.

Service catalogue burn rate awareness

Different BTP services burn credits at very different rates. Cloud Integration message volume is metered per million messages. HANA Cloud burns by GB-hour. AI Core (the runtime behind Joule and other AI scenarios) burns by GPU-hour and token volume. A workload that looks small in user terms — five integration flows with high-volume traffic — can consume more credits than a workload that looks large — fifty Build Apps applications with intermittent use. Pre-deployment burn modelling is the discipline that prevents surprise.

Generative AI burns BTP credits faster than any other service.

Joule and the embedded generative AI scenarios across SuccessFactors, S/4HANA and SAP Analytics Cloud all consume BTP credits via AI Core. The burn rate at production scale is materially higher than buyers expect — a single team using natural-language reporting at typical query volumes can burn tens of thousands of credits per month. The pricing is also moving: SAP's AI consumption rates have repriced twice in 18 months, with both moves favouring SAP.

The buyer-protective negotiation move: at signature, lock the AI Core unit rate for the contract term (rather than accepting SAP's right to reprice). The hedge value is significant.