BTP credits inside RISE

Every RISE with SAP contract includes an allocation of credits for the Business Technology Platform, or BTP. The credits cover platform services across integration, extension, data, AI, and analytics. The marketing position is that the credits come included with the RISE bundle, a benefit that buyers receive at no separate cost. The contractual position is different. BTP credits are a paid component of the RISE subscription, billed inside the headline FUE rate, subject to specific consumption rules, and forfeitable under standard SAP terms. Treating them as a benefit rather than as an entitlement is the recurring buyer-side error that we see across our contract negotiation engagements.

What the credit allocation actually buys

A BTP credit is a unit of consumption applicable to the BTP service catalogue. The catalogue includes Integration Suite, Extension Suite, HANA Cloud, Build, Datasphere, AI Core, Analytics Cloud, and dozens of more granular services. Each service consumes credits at a defined rate, set by SAP and revisable. The allocation included in a RISE contract is denominated in credits, not in services. The buyer chooses the consumption pattern within the credit pool.

The allocation size varies by deal. Smaller RISE contracts may include a few thousand credits per year; larger contracts include tens of thousands. The right allocation depends on the buyer’s planned BTP consumption, which is usually under-mapped at contract sign. The RISE topic page covers the bundle architecture in detail.

The use-it-or-lose-it default

SAP’s standard contractual position is that BTP credits expire at the end of the annual subscription period in which they are issued. Unused credits do not carry forward. The position is presented as a standard cloud-subscription practice, comparable to how unused capacity expires in many SaaS arrangements. The practical effect for buyers is that an allocation set too generously at contract sign converts into recurring forfeited entitlement at year end.

The default is negotiable. Where the buyer has commercial leverage at sign — a large deal, a multi-year commitment, a competitive evaluation in flight — the carry-forward provision can be added to the contract. Variants we have seen include twelve-month carry-forward, end-of-term true-up against actual consumption, conversion to other entitlement at defined ratios, and mid-term reallocation rights. The cloud credit roll-over piece covers the negotiated variants in detail.

Sizing the allocation to real consumption

The allocation size should follow the buyer’s realistic BTP consumption forecast, not SAP’s recommendation. The forecast has three components: known integration workloads, known extension workloads, and exploratory or speculative workloads. The first two are estimable from current architecture; the third is not, and the temptation is to size the allocation generously to cover it.

The forecast inputs

For integration workloads, the inputs include the count and pattern of integration flows planned during the contract term, the volume of messages per flow, the message-size distribution, and the consumption rate per million messages under the current SAP rate card. For extension workloads, the inputs include the count of planned extensions, the runtime model (CAP, Kyma, ABAP environment), and the consumption rate per runtime hour or per memory unit. For exploratory workloads, an explicit reserve allocation should be set rather than padding the overall figure.

The under-consumed allocation

The most common pattern across our reviews is over-allocation. Buyers commit to a credit allocation that they consume at thirty to fifty per cent of the contracted level. The forfeited portion is real cost, paid for inside the FUE rate but never received as service. The mitigation is the realistic forecast plus the carry-forward negotiation, applied together.

The rate-card volatility

SAP revises the BTP rate card periodically. A service that consumed one credit per thousand messages at contract sign may consume two credits per thousand messages eighteen months later, with the buyer’s allocation unchanged. The buyer pays the same headline FUE price for half the effective consumption capacity. The pattern is hard to defend against at audit but visible in advance through rate-card tracking.

The contractual protection is a price-protection clause for the credit consumption rates, fixing the rate-card pricing applicable to the buyer’s allocation for the duration of the contract. Few RISE contracts include the clause as standard. The buyer-side ask should include rate-card lock for the credit consumption alongside the carry-forward provision.

The true-up mechanic

Where the buyer’s actual consumption exceeds the contracted allocation, SAP applies an overage charge at the prevailing rate card. The overage pricing is usually less favourable than the per-credit pricing inside the bundle, reflecting the fact that the overage is unforecast and outside the negotiated baseline. Estates that under-forecast the allocation pay the overage premium across the contract life.

The buyer-side protection is twofold. First, the allocation forecast should include realistic growth assumptions across the contract term, not just year-one consumption. Second, the contract should include an overage pricing clause that caps the per-credit rate for overage consumption at the contracted per-credit rate, removing the premium. The clause is negotiable at sign and largely unobtainable at renewal once SAP has the pattern of overage billing in hand.

The mid-term reallocation question

BTP consumption patterns change. Workloads shift from extension to integration, from CAP to Kyma, from analytics to AI. The credit allocation contracted at sign may match year-one consumption and diverge from year-three consumption. Standard RISE contracts do not permit mid-term reallocation of the credit pool; the allocation is fixed at sign and revised only at renewal.

Buyers with predictable workload evolution should negotiate mid-term reallocation rights. The typical formulation is an annual review window, in which the buyer can reallocate credits across service categories within the same total pool size, with SAP’s standard rate card applied to the reallocated portion. The provision is unusual but obtainable in larger deals. The bank mid-term renegotiation case file documents the pattern.

Reading the credit report

SAP provides a credit consumption report inside the RISE administrative interface. The report shows allocated, consumed, and remaining credits across the current period. The presentation is service-by-service rather than aggregated, which can obscure under-consumption at the pool level. Buyer-side monitoring should aggregate the consumption across all services into a single utilisation figure and track it against the time-elapsed portion of the period.

The monitoring should fire alerts at defined utilisation thresholds: an early-warning alert if utilisation tracks below forecast through the first six months, a mid-period alert if utilisation tracks above forecast, and a year-end alert if forfeiture risk emerges. The alerts inform the in-period actions: reallocation requests to SAP, workload shifts to consume more efficiently, or escalation to the procurement team for the next renewal cycle. The RISE contract negotiation tactics white paper covers the monitoring framework.

What to negotiate before sign

The buyer-side ask on BTP credits inside RISE should cover four provisions. The allocation size should match a documented consumption forecast rather than a SAP recommendation. The carry-forward provision should permit at least twelve months of carry-forward for unused credits, with multi-year carry-forward in larger deals. The rate-card lock should fix the per-credit consumption rates for the duration of the contract. The mid-term reallocation right should permit annual reallocation across service categories within the contracted pool size. The four provisions together transform the credit allocation from a default forfeiture risk into a managed entitlement. The RISE pricing model piece covers the broader contract architecture.