Contents
Key takeawaysWhat SAP BTP isPricing and CPEACost of a wrongly sized poolWhere spend runs awayChecking your consumptionWhat we have seenAnswering the account teamOrder form termsPilot, renewal or RISEWhat to do nextFAQSAP BTP is a consumption priced cloud platform, not a perpetual license. Credits drain as services run, so size the pool to costed use cases and track who consumes what every month.
- Consumption priced. SAP BTP is a pay for use platform for integration, extension, data and AI, with no perpetual right to use.
- Credits fund most contracts. The Cloud Platform Enterprise Agreement (CPEA), and now its successor BTPEA, funds a pool of credits that services draw down each month.
- Pay as you go costs most per unit. It is flexible and needs no commitment, but credit agreements lower the rate.
- Unused credits are lost. Credits left at term end are typically forfeited, so an oversized pool wastes money unless you negotiated rollover.
- Idle services burn budget. In our reviews, idle and over provisioned services consumed 15 to 30 percent of the pool.
- Attribution comes first. Tagging and budgets per team are the main controls that keep BTP spend visible.
- Forecast from real plans. Size the credit pool against costed use cases and their go live dates, and add the platform vision later through planned top ups.
SAP Business Technology Platform is the cloud platform SAP sells for integration, extensions, data and AI around your ERP. You do not buy it once and own it. You fund a consumption agreement, services draw it down as they run, and the bill grows wherever use goes unplanned.
I worked inside SAP before moving to the customer side. BTP is where I see the widest gap between how carefully a deal is negotiated and how loosely it is run afterwards. This guide covers both halves: what the platform is, and how to keep its cost predictable.
What exactly is SAP BTP?
SAP BTP is SAP's cloud platform for integration, application extension, data management and AI. You build around the core ERP system on it, and the core itself stays where it is.
SAP positions BTP as the technical foundation for extending S/4HANA and its other cloud products without modifying the core. That matters commercially, because SAP's clean core message steers more and more custom code onto BTP, and every workload you move there runs on a meter.
The four capability areas
SAP groups BTP services into four areas. Most customers start with integration and extension, then add data and AI once the first projects are live.
- Integration. Connect SAP and non SAP systems, mainly through SAP Integration Suite.
- Extension. Build apps and workflows around the core with SAP Build and the BTP runtimes, so custom logic stays out of S/4HANA.
- Data and analytics. SAP HANA Cloud, SAP Datasphere and SAP Analytics Cloud for reporting, data marts and planning.
- AI. SAP AI Core, generative AI services and intelligent services that sit behind Joule and embedded AI features.
What BTP is not
BTP is not a one time license, and it does not replace your S/4HANA core. There is no perpetual right to use it, so when the agreement ends, access to the services ends with it.
It also has no single price. Each service has its own metric, such as messages for integration, memory and compute for HANA Cloud, or users and runtime for SAP Build. That is why a BTP forecast has to be built service by service.
How is SAP BTP priced, and what is CPEA?
BTP is consumption priced. Most enterprise customers fund a pool of cloud credits under a credit agreement, and each service draws down credits as it runs. CPEA, the Cloud Platform Enterprise Agreement, is the best known version of that agreement.
CPEA and its successor, BTPEA
Under CPEA you commit to an annual amount of cloud credits at a negotiated rate. Each month SAP deducts the cost of the previous month's consumption from the balance. Credits left unused at the end of the term are typically lost, so the model rewards accurate forecasting.
SAP now sells new credit contracts as the SAP BTP Enterprise Agreement (BTPEA), which works the same way: prepaid credits, monthly drawdown, overage invoiced monthly at list price. Existing CPEA customers can renew on CPEA or move to BTPEA at renewal. Everything in this guide applies to both.
Pay as you go and subscription
Pay as you go has no upfront commitment and no minimum. SAP bills the services you used one month in arrears, at list price, which makes it the most expensive rate per unit. Some services also come as fixed subscriptions: a flat fee for a set capacity, whatever you consume.
You can run a subscription and a consumption agreement side by side, in separate global accounts or in the same one. You cannot mix two consumption flavors, such as BTPEA and pay as you go, in one global account. Compare all the options against your planned use before you choose.
| Model | How it bills | Best fit | Main risk |
|---|---|---|---|
| CPEA or BTPEA credits | Monthly drawdown from a funded pool | Planned use across several services | Forfeiting unused credits |
| Pay as you go | Actual consumption, one month in arrears | Pilots and unknown demand | Highest unit rate |
| Fixed subscription | Flat fee per service | Stable use of a single service | Paying for idle capacity |
| Mixed | Pool or subscriptions plus on demand use | Most real SAP customers | Needs active governance |
SAP RISE Negotiation Guide
RISE pricing benchmarks and the contract terms to push on, useful when BTP credits arrive inside a RISE offer.
Get the white paper →What does a wrongly sized credit pool cost?
An oversized pool usually costs more than an undersized one, because forfeited credits are lost at the full price you paid, while overage only costs the discount you miss on the excess. A hypothetical example shows how far apart the outcomes can be.
Say your costed roadmap has three use cases for next year: 14 interfaces moving to Integration Suite at $180,000 in list value, a finance data mart on HANA Cloud at $150,000, and three SAP Build extensions at $70,000. That is $400,000 of consumption at list, and assume it is exactly what you use.
| Option | Commit and discount | Paid up front | Unused or overage | Total paid | Cost per $1 of use |
|---|---|---|---|---|---|
| Sized to a platform vision | 800,000 at 35 percent | $520,000 | 400,000 forfeited | $520,000 | $1.30 |
| Roadmap plus headroom | 440,000 at 25 percent | $330,000 | 40,000 forfeited | $330,000 | $0.83 |
| Roadmap minus a buffer | 360,000 at 25 percent | $270,000 | $40,000 overage at list | $310,000 | $0.78 |
| Pay as you go | None | $0 | 400,000 billed at list | $400,000 | $1.00 |
The pool sized to a vision has the best discount on paper and the worst result. It costs $210,000 more than the smallest commit and 30 cents more per dollar of use than having no agreement at all. The smaller commit comes out cheapest even after paying list price for the overage.
Why a bigger commitment for a better rate is the wrong default
The usual advice is to commit to a large BTP credit pool, because the rate improves with volume and a big commitment signals intent to SAP. We disagree. In the accounts we reviewed, oversized pools left credits unused and forfeited at term end, and their effective rate was worse than a smaller pool topped up as needed.
Size the pool to the costed roadmap and govern consumption with tagging and budgets. Treat any top up as a planned decision, with its price fixed in the order form before you sign.
Where does BTP spend run away?
BTP spend grows without warning because nothing forces a stop. Idle services, over provisioning and untracked use all drain the pool without producing anything the business needs.
Idle and over provisioned services
Services left running after a project ends keep consuming credits. A HANA Cloud instance sized for a migration load, a test tenant no one switched off after go live, or a runtime kept warm for a pilot all bill every month. Over provisioned capacity bills for headroom no one uses.
Blind spend
Without tagging, no team owns its consumption. The pool drains for months before anyone investigates, even though SAP's BTP documentation sets out the account structure and reporting that make governance possible.
- Idle services. Shut them down when projects end, and make decommissioning part of every project close.
- Provisioning. Size capacity to real load, then check it again after the first quarter in production.
- Attribution. Tag every consuming team so each line of the bill has an owner.
- Free plans. Run pilots on free tier plans where they exist, and check the cap before a pilot turns into production.
How do you see what your BTP account is consuming?
Start in the SAP BTP cockpit. At global account level, the Costs and Usage view shows consumption and cost by service, directory and subaccount, and you can export the data to a spreadsheet for finance.
Structure the account so costs can be attributed
Group subaccounts into directories by business unit or program, and give each directory and subaccount labels such as a cost center or internal order number. SAP's own account model guidance describes labels for exactly this. Without that structure, the cockpit can only tell you which service consumed credits, not which team.
Set budgets, alerts and a monthly report
In the cockpit you can create monthly budgets, each with up to three alert thresholds set between 1 and 120 percent of the budget amount. You can opt in to email every global account administrator when a threshold is crossed.
For automated reporting, the SAP Usage Data Management service exposes the same usage and cost data through APIs, so you can feed it into your own finance tools.
- Costs and Usage view. Consumption by service and subaccount, plus the export for finance.
- SAP for Me. Your contracts, order forms and invoices, which you need when you reconcile consumption against what you bought.
- SAP Discovery Center estimator. Prices a planned service mix before you commit, which is how you cost each use case on the roadmap.
The first month of attribution usually surfaces services no one remembered running. Treat that list as your first round of savings.
What have we seen in SAP BTP reviews in 2024 and 2025?
Between 2024 and 2025 we reviewed BTP use at roughly 25 to 35 SAP customers; our engagement file for the period records 30. The platform was usually bought with enthusiasm and run with little discipline. The credit pool was either oversized and partly forfeited, or undersized and topped up at a worse rate.
- Idle burn. Idle or over provisioned services consumed 15 to 30 percent of the credit pool with no business output. The median was 22 percent.
- Vision sizing. Pools were sized to a platform vision rather than a costed roadmap of use cases, so the forecast was guesswork.
- No attribution. Spend had no team level tagging, so no one could attribute or challenge consumption until the pool ran low.
None of the standard agreements we reviewed offered a refund on forfeited credits. The only protection was a clause negotiated before signature.
A better rate on credits you forfeit is not a saving.
What will SAP's account team say about BTP credits?
Expect pressure toward a larger pool and the standard terms. These are the lines we hear most often, with a reply for each.
- "A bigger commitment gets you the next discount tier." Show the cost per dollar of actual use at your forecast, as in the table above, and ask for the better tier with a ramp instead.
- "Credits work for any service, so headroom is never wasted." Under standard terms, unused credits are lost at term end. If SAP is confident you will use them, ask for rollover in writing.
- "Your AI and data plans will fill the pool." Ask which use case, which service and which go live date. If there is no costed plan, the credits belong in a later top up.
- "Take the BTP credits inside the RISE bundle." Ask for the BTP credits priced as a separate line, so you can see what they cost and size them on their own.
What should the BTP order form say?
The terms that protect you sit in the order form, and they are negotiated deal by deal. Check the SAP cloud agreements for the standard credit and term rules, then ask for these:
- Rollover. A share of unused credits carried into the next period, which caps the cost of a forecast error.
- Top up at the contracted rate. Extra credits during the term at your discount, so an undersized pool is not punished.
- Overage rate. Overage billed at your discount rather than list, which removes most of the penalty for sizing low.
- Ramp. A commitment that steps up by year in line with go live dates on the roadmap.
- Conversion. The right to move spend between subscriptions and the credit pool when a workload stabilizes.
How does the approach change for a pilot, a renewal or a RISE deal?
Commit in proportion to the consumption data you have. A pilot needs flexibility, a renewal can be sized on a year of real use, and a RISE deal needs the BTP line priced apart from the rest of the bundle.
First use or pilot
Start on pay as you go or free tier plans while demand is unknown. The higher unit rate is the price of learning what your use cases consume, and that data is what you size the first credit pool on.
CPEA renewal
At renewal you have the evidence. Pull at least a full year of consumption by service, strip out idle services and one off migration spikes, and size the new pool to what remains plus the costed roadmap. Decide whether to stay on CPEA or move to BTPEA based on the services you actually run.
BTP inside a RISE with SAP contract
SAP often includes BTP credits in RISE with SAP offers. Model the two together with the SAP RISE TCO calculator, and read our guide to negotiating BTP credits inside an S/4HANA deal before you accept the bundled amount.
For more on credit economics, see our SAP BTP licensing strategy guide and the SAP Knowledge Hub, which holds the full SAP licensing library. Our SAP Practice provides independent SAP advisory.
What to do next
- List the use cases. Write down the BTP use cases you actually plan to run and cost each one in the Discovery Center estimator.
- Choose the model. Pick CPEA or BTPEA credits, pay as you go, subscriptions, or a mix, based on how stable each workload is.
- Size the pool. Fund the credit pool against the costed roadmap and leave the platform vision for later top ups.
- Turn on tagging. Put directories and labels in place so every consuming service has an owner.
- Set budgets and alerts. Give each team a budget with alerts, and review consumption monthly.
- Clean up. Shut down idle services and rightsize over provisioned capacity.
- Plan top ups. Treat any credit top up as a deliberate decision, priced in the order form in advance.
- Get an independent review. Engage independent SAP advisory before you commit the credit pool.
Frequently asked questions
What is SAP BTP in simple terms?
It is the set of SAP cloud services you use to connect systems, build apps and workflows, run analytics and add AI around your ERP. S/4HANA stays the system of record, and BTP holds the integrations and extensions around it. You pay for what those services consume each month.
How is SAP BTP priced?
Through consumption. Most enterprises prepay a credit pool under CPEA or BTPEA and draw it down monthly. Smaller or experimental users pay as they go at list price, and some services can be bought as fixed subscriptions. Each service converts its own metric, such as messages, memory or users, into a credit charge.
What is the CPEA in SAP BTP?
CPEA stands for Cloud Platform Enterprise Agreement. It is a prepaid commitment to cloud credits at a negotiated discount, usable across eligible BTP services. SAP now offers BTPEA for new credit contracts, and CPEA customers can renew as they are or switch to BTPEA when the current term ends.
Why does SAP BTP spend grow unexpectedly?
Consumption billing has no natural ceiling. A service keeps charging until someone switches it off or scales it down, and SAP deducts it from the balance a month later. When no team owns the line, the first signal is often a low balance warning rather than a question about value.
Should I commit to a large BTP credit pool?
Not by default. Commit to what your costed use cases will consume in the first year, and negotiate a top up at the same rate and a ramp for later years. A larger pool only makes sense when you have a year of consumption data that supports it.
What happens to unused BTP credits?
Under standard terms they are typically lost at the end of the term, with no refund and no carry forward. A rollover clause can change that, but it has to be written into the order form before signature, so raise it early in the negotiation rather than at the end.
How do I keep BTP cost under control?
Give every subaccount an owner and a cost center label, set monthly budgets with alerts in the cockpit, and review the Costs and Usage view each month. Close services when projects end and resize anything provisioned for a peak that has passed.
Is SAP BTP required for S/4HANA?
No. S/4HANA runs without it. SAP does recommend BTP as the way to extend and integrate the core without modifying it, and many RISE offers include BTP credits. Whether you need it depends on your integration and extension requirements.