SAP BTP Pricing and Consumption: Follow the Credit Drawdown
Four meters drove over 80 percent of credit drawdown in the SAP BTP estates we reviewed in 2024 to 2025, and the July 2025 AI repackaging added a second expiring pool. Model the drawdown by service before you commit a credit.
Prepared by Redress Compliance · June 2026 · Representative SAP BTP estate scenario throughout (benchmark scenario, not a quote)
Executive Summary
SAP BTP pricing looks like one number: the annual cloud credit commitment. It is not. The commitment is consumed by service level meters that each behave differently. Integration Suite bills by message, SAP HANA Cloud and Datasphere bill by capacity unit, and Build bills by developer and runtime usage. The pool is only as predictable as its worst meter.
The structure changed twice underneath clients. CPEA closed to new accounts on April 15, 2024, making BTPEA the contract for every new commitment. Then the July 2025 Business AI repackaging moved Joule and the AI capabilities onto AI Units, a second prepaid pool that expires on its own clock and cannot substitute into cloud credits.
The arithmetic punishes optimism. In our representative scenario, a $600K annual pool sized to the project roadmap burned $470K in year one, forfeiting $130K, about 22 percent of the prepayment. The same estate billed 3.0 million Integration Suite messages against 800K designed API calls, because the 250 KB message definition multiplied the volume.
Sized and papered correctly, the consumption model is negotiable. Across the SAP BTP commitments our practice worked in 2024 to 2025, the levers in section 7 recovered 15 to 25 percent against the opening proposal, before counting the breakage they prevented.
The BTP Commercial Model: One Pool, Many Meters
Under the consumption based commercial model, you prepay an annual pool of cloud credits and every activated service draws it down monthly at contracted rates. CPEA closed to new accounts on April 15, 2024; BTPEA is the paper for new deals, and new services land in BTPEA scope only.
The pool is uniform. The meters are not. Each service converts usage to credits through its own metric, published per plan in the SAP Discovery Center and summarized on the SAP BTP pricing page. Pricing a BTP commitment without modeling each meter is guessing.
| Service family | Billing meter | Cost behavior | Your side watch point |
|---|---|---|---|
| Integration Suite | Messages, counted per 250 KB of data | Scales with interface count, payload size, retries, and polling. | Billed volume routinely runs a multiple of designed call volume. |
| SAP HANA Cloud | Capacity units from memory, compute, and storage blocks | Memory dominates; 16 GB blocks step the cost up in increments. | Sizing creep: every memory upgrade re prices the whole instance. |
| SAP Datasphere | Capacity units per hour by configuration | Always on compute burns credits around the clock. | Idle development tenants quietly drain the pool. |
| Joule and Business AI | AI Units, a separate prepaid pool since July 2025 | Each AI interaction consumes a defined unit rate; rates vary by feature. | Separate expiry, separate commit, no substitution into cloud credits. |
| Build Apps and Build Process Automation | Developer users plus runtime consumption | Development seats are steady; runtime scales with automation volume. | Citizen developer rollouts multiply seats faster than value lands. |
Two contract mechanics matter before any sizing work. First, BTPEA bills at the lower price if a service list price drops mid term, which CPEA paper does not guarantee. Second, BTPEA innovation services in deprecation group two can leave the catalog on six months notice, so production workloads need swap rights in writing.
CPEA Consumption Sizing: Trajectory, Breakage, Protection
Credits sit in annual buckets. Whatever the estate does not consume by the contract anniversary is forfeited under standard CPEA and BTPEA terms. That makes the sizing procedure, not the discount, the consequential decision in the proposal.
The procedure is mechanical. Meter every workload on pay as you go or from existing balance statements. Model the deployment trajectory by quarter, not by year, because adoption ramps late. Then apply a breakage assumption: in the contracts we reviewed, estates consumed 60 to 80 percent of a roadmap sized first year pool.
Our representative estate is a 9,000 employee consumer goods group landing Integration Suite, HANA Cloud, Datasphere, and a Joule pilot behind an S/4HANA program. SAP proposed a $600K annual pool sized to the roadmap. The quarterly drawdown tells the real story.
| Contract quarter | Straight line plan | Actual drawdown | Cumulative consumed |
|---|---|---|---|
| Q1 | $150K | $80K | $80K |
| Q2 | $150K | $105K | $185K |
| Q3 | $150K | $130K | $315K |
| Q4 | $150K | $155K | $470K |
| Year 1 total | $600K | $470K | $130K forfeited at the anniversary |
Representative estate, year one. Benchmark scenario, not a quote. Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025.
The protection is contractual, not analytical. A ramped pool that steps up by quarter, rollover of unused credits into the next contract year, and a rate hold on incremental credits convert forecast error from forfeiture into runway. Every one of those is a signature day ask. None is available mid term.
Integration Suite: The Message Meter
Integration Suite is the most exposed meter in the estate because it scales with deployment growth nobody budgets for. The unit is the message, and a message is counted per 250 KB of data. A 520 KB payload bills as three messages. Payload design is therefore a pricing lever.
Start with an integration count audit: inventory every interface, its call frequency, its average payload, and its retry and polling behavior. Then forecast billed messages, not designed calls. The difference is the budget surprise.
| Forecast stage | Monthly volume | What moves the number |
|---|---|---|
| Designed API calls | 800K | The interface inventory as architected: 120 integrations at planned frequencies. |
| After 250 KB chunking | 2,400K | Average payload of 520 KB bills as three messages per call (800K x 3). |
| After retries and polling | 3,000K | Error retries and scheduled polling add 25 percent (2,400K x 1.25). |
Representative estate interface forecast. Benchmark scenario, not a quote. Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025.
Across the integration estates we audited in 2024 to 2025, billed message volume ran 2 to 4 times the designed call volume. The contract answer is volume protection: a banded message rate that steps down as volume grows, written into the order form, so estate expansion improves the unit price instead of detonating the pool.
Build Apps and Build Process Automation: The Maker Meter
The Build portfolio runs a split meter inside CPEA and BTPEA: development seats plus runtime consumption. The split matters because the two halves grow at different speeds and respond to different controls.
- Developer users. Steady, headcount shaped drawdown. The control is seat hygiene: reclaim inactive builder seats quarterly, the same discipline as any named user license.
- Runtime consumption. Scales with executed automations and deployed app usage, not with builders. A successful citizen developer program grows this line long after the seat count stabilizes.
- The trap. Pilots are sized on seats, but production bills on runtime. Forecast the runtime curve from the three busiest automations, not from the seat count.
Keep Build inside the credit pool rather than on fixed subscriptions until the runtime curve has six months of history. The pool absorbs forecast error across services; a fixed subscription locks the error in.
HANA Cloud and Datasphere: The Memory Meter
The data layer is the largest single drawdown for data centric estates. Both services meter in capacity units: SAP HANA Cloud converts memory, compute, and storage into capacity units, with memory provisioned in 16 GB blocks, and the capacity unit estimator publishes the conversion.
Memory dominates the unit math. Every 16 GB block added to an instance re prices the configuration, and instances rarely shrink once teams have them. Datasphere adds the always on problem: development tenants left running burn capacity units around the clock at the same rate as production.
Three controls hold the line. Size instances to measured working set, not to the migration team's comfort margin. Schedule non production tenants down outside working hours.
At renewal, secure a memory grandfather clause: the contracted capacity unit conversion holds for your configuration even if SAP rebases the estimator mid term. SAP has repriced capacity unit ratios before; the clause costs nothing at signature.
Joule AI: The Second Expiring Pool
The July 2025 Business AI repackaging moved Joule and the AI capabilities onto AI Units, priced on the SAP Business AI pricing page. AI Units are prepaid, expire 12 months from purchase, do not roll over, and are forfeited unused. They are a second pool with all the breakage mechanics of cloud credits and none of the substitution.
Consumption rates are the sizing hazard. Each AI feature draws a defined number of units per interaction, but SAP does not publish a comprehensive rate table, and rates change as the portfolio evolves. In the quotes we benchmarked, AI Units priced around 40 cents per unit at list before volume tiers.
Two sizing rules follow. Buy AI Units in small tranches against measured pilot consumption, never as a roadmap sized block, because the 12 month expiry punishes optimism twice as fast as cloud credits do. And align the AI Unit anniversary with the RISE or BTP anniversary, so every pool resizes in the same negotiation with the same leverage.
The BTP Contract Levers
Everything above converges on the order form. These are the clauses our practice negotiates on BTP paper, in priority order.
| Lever | What to secure | Why it matters |
|---|---|---|
| CPEA consumption ceiling | A cap on annual drawdown growth, with overage at contracted band rates rather than list. | Stops a hot meter (usually Integration Suite) from forcing a panic pool expansion at list price. |
| Credit substitution rights | Freedom to redirect committed credits across the BTP service catalog as the estate evolves. | Converts a wrong service bet from forfeiture into reallocation. Usually conceded, rarely volunteered. |
| Integration Suite volume protection | Banded message rates that step down with volume, fixed in the order form. | Billed volume runs 2 to 4 times design; the band makes growth improve the unit price. |
| HANA Cloud memory grandfather | The contracted capacity unit conversion holds for your configuration through the term. | Protects the largest single drawdown line from a mid term estimator rebase. |
| Joule consumption ceiling | A cap on AI Unit drawdown per quarter, with tranche purchases aligned to the BTP anniversary. | The 12 month AI Unit expiry makes oversizing a guaranteed loss, not a risk. |
| Data residency posture | Region and provider commitments for HANA Cloud and Datasphere written into the order form. | A forced region move mid term reopens pricing; papering it now keeps the leverage yours. |
| Executive escalation path | A named SAP executive sponsor and a defined escalation route for consumption disputes. | Balance statement disputes die in account team queues without a contractual route up. |
Recovered against the opening proposal.
Coordinated BTP negotiations recovered 15 to 25 percent against SAP's opening position across the engagements we benchmarked in 2024 to 2025. Right sizing the pool and the substitution clause delivered more of that recovery than the headline rate.
Billed messages versus designed calls.
Integration Suite billed volume ran 2 to 4 times the designed call volume in the estates we audited, driven by 250 KB chunking, retries, and polling. Volume protection in the order form is the only durable answer.
Benchmark ranges: Redress Compliance advisory engagement file, 2024 to 2025. Confirmed against your estate during delivery.
How We Engage
Model every drawdown line
Pull the balance statements, audit the integration inventory, size the data layer working set, and meter AI pilot consumption. The output is a billed volume forecast per meter, not a roadmap estimate.
Design the pools
Set the core pool to verified burn with a quarterly ramp, ceiling the Integration Suite and AI lines, and write the substitution, grandfather, and residency clauses before SAP sees a number.
Close the levers together
Take the sized pools to market against our band benchmarks, time the close to SAP's quarter, and land all seven levers in one signature. The rate is the last conversation, not the first.
Price the meters, then the pool, then the rate. Every BTP overspend we found traces to a commitment priced as one number: a pool sized to ambition, a message meter nobody forecast, a data layer that never shrinks, and an AI pool expiring on its own clock. The drawdown model is the negotiation.
- Forecast billed volume, not designed volume. Chunking, retries, always on tenants, and AI Unit rates are where the pool actually goes; model them per meter before committing.
- Land the seven levers at signature. Ceilings, substitution, volume bands, the memory grandfather, the Joule ceiling, residency, and escalation are signature day asks; none survive to mid term.
Redress Compliance runs this sequence on the your side only: meter, structure, negotiate. We are glad to tie a meaningful part of the fee to delivered value.
