BTP Consumption Data as Negotiation Input for SAP Renewal
BTP credits are part of every RISE Enterprise Agreement. They are built into the contractually defined credit structure, measured monthly, and they document actual cloud platform usage at a level of granularity below FUE metering. Even so, they are rarely prepared as structured negotiation input for renewal discussions.
That is a missed governance moment: BTP consumption data is the most direct available evidence of actual RISE package utilization at the platform level. If you have not prepared this data before your renewal, you are negotiating the credit volume for the next contract term without a factual foundation.
This article explains what BTP credit data reveals, how to build a time series for renewal purposes, and what the data implies for the credit volume in your next contract term.
What BTP Credit Data Reveals
BTP credits in a RISE Enterprise Agreement are billed by Depreciation Groups. Group 1 covers base infrastructure services, while Group 2 covers advanced and integration services with a higher credit consumption per unit of capacity used. This distinction matters for your renewal data foundation, because it shows which portion of your BTP consumption falls into which service category, and therefore how to calibrate credit volume if your usage strategy changes.
AI Units represent a separate consumption stream. In the RISE context, they are billed as PUPM (Per Use Per Month). If you have activated SAP Business AI Services, there is an additional layer of credit consumption that must be visible in the time series. Without it, you risk miscalibrating your AI unit allocation entering the next contract term.
What BTP data does not show directly: it does not automatically distinguish between productive use, test and development environments, and exploratory projects. That classification has to be done manually, because it depends on your specific subaccount structure. A consumption figure without an assignment to productive versus non-productive systems has limited value for renewal purposes.
There is a second governance moment within BTP analysis: unused credits. Subaccounts or service instances where credits are regularly reserved but no consumption occurs are solid evidence of overallocation. This is not a criticism of how the platform is run. It is a factual basis for a conversation about volume planning in the next term.
How BTP Data Feeds into Your Renewal Foundation
Time Series: 12 to 18 Months as a Minimum
A point-in-time value shows what was consumed on the day you pulled the report. For renewal purposes, you need a time series, because consumption can vary seasonally: project phases, release cycles, and business processes all create patterns in BTP usage that a single data point cannot capture. A time series of twelve to eighteen months lets you identify peak and low-load periods and calibrate credit volume for the new term to reflect actual operational needs, without systematically building in a buffer that expires at contract end.
Monthly Balance Statements are the source for this time series. If you have not been archiving them consistently, you will find during renewal preparation that historical data cannot be fully reconstructed after the fact. The governance moment for building the data foundation does not happen in the renewal year. It happens during ongoing contract management.
Usage Classification: Productive vs. Test and Development
A solid renewal data foundation requires BTP consumption broken down by usage type. That breakdown only works if the subaccount structure was set up to separate productive systems, development and test environments, and exploratory projects into distinct subaccounts. If that separation is not in place, disaggregating the data retroactively is labor-intensive and may only be achievable approximately.
For the renewal negotiation, this classification matters for two reasons. First, if a significant portion of BTP consumption comes from non-productive environments, the credit volume required for productive use can be determined with greater precision. Second, any planned expansion of productive BTP usage, such as additional integration scenarios or a broader rollout of AI use cases, requires a baseline built on productive consumption, not on total consumption including test environments.
Cost Center Assignment: Foundation for Internal Reporting
BTP consumption that is assigned to subaccounts and projects can be mapped to internal cost centers. This mapping is relevant for controlling, but it is also a prerequisite for valid budget planning in the next term. If you can give your controlling team reliable data on BTP consumption by department or project, you give the renewal process an internal legitimacy that is otherwise hard to establish.
What BTP Data Implies for Your Next Contract
Calibrating Credit Volume for the New Term
The most important output of a complete BTP time series is a recommendation for the credit volume in the next contract term. This calibration is its own governance moment in the cost dimension: a volume set too high generates credits that expire at contract end, while a volume set too low leads to overages charged at a 15 percent surcharge with no SLA protection during the overage period.
The starting point for calibration is average monthly consumption from the time series, adjusted to remove non-productive portions and supplemented by a growth assumption for planned expansions. If your roadmap includes expanded use of SAP Business AI, the PUPM consumption from the current term is the only reliable baseline for AI unit demand planning in the next period.
Quantifying Overage Risk for the New Period
Beyond calibrating the baseline volume, quantifying overage risk is a separate governance step. Which service families have generated peak loads in the past? Under which usage scenarios could the credit volume of the new term be exceeded? If you can derive these scenarios from the time series, you can have a substantive conversation about buffer options during the renewal discussion, rather than reacting to overages once you are already in production.
Planning AI Unit Requirements
If SAP Business AI Services are to be expanded, the BTP time series is the foundation for AI unit planning in the new term. PUPM consumption from the current period shows which services are used and at what intensity, enabling a projection onto planned scenarios. A detailed explanation of the SAP Business AI licensing structure and the PUPM mechanism is available in the [Pillar 2 Hub: SAP Business AI Licensing].
Governance of BTP Data Before Renewal
Preparing BTP consumption data for renewal purposes requires three organizational prerequisites.
Monthly Balance Statement as a mandatory document. The Balance Statement is the only complete source for BTP credit consumption per period. It must be archived throughout the entire contract term. If you only begin systematic archiving during renewal preparation, you have an incomplete time series.
Subaccount structure as the reporting foundation. A subaccount structure that separates productive, test, and development environments is not just a BTP operational best practice. It is the prerequisite for BTP consumption data to hold up as renewal input. If that structure is not in place, it is something to build into the next term, not a limitation that blocks the current renewal.
Clarify ownership of BTP operational data. BTP operational data typically sits with the platform or architecture team, not with contract management or procurement. Renewal preparation requires that this data be delivered in a coordinated way. The question of who in your organization can produce a reliable BTP consumption analysis should be answered no later than eighteen months before renewal.
FAQ
What specific BTP data do I need for renewal preparation?
For a solid renewal data foundation, you need: monthly Balance Statements covering twelve to eighteen months, consumption broken down by Depreciation Group (Group 1 and Group 2), PUPM consumption for AI Units if Business AI Services are active, and a breakdown by productive versus non-productive subaccounts. This data provides the basis for credit volume calibration and overage risk assessment for the new term.
What if I do not have a complete BTP time series?
Without a complete time series, credit volume calibration can only be based on current point-in-time values. That is a limited foundation, because seasonal variation and project phases are not visible. In this situation, a conservative projection based on the available period, supplemented by a clearly reasoned buffer, is the pragmatic approach. The structured approach for the next term starts with consistent archiving of Balance Statements from today forward.
How do Depreciation Group 1 and Group 2 differ for BTP credits?
Group 1 covers base infrastructure services with lower credit consumption per unit of capacity. Group 2 covers advanced and integration services that consume more credits per unit used. Understanding how your own BTP consumption is distributed across these two groups shows what share is attributable to infrastructure and what share to higher-value services, which directly influences how the total volume should be calibrated for the new term.
How do BTP credits relate to the overall contract credit balance?
BTP credits are part of the total credit balance defined in the RISE Enterprise Agreement. They are drawn from the overall balance, meaning that higher BTP consumption reduces the credits available for other components. This interdependency makes the BTP time series an integral part of the overall consumption data analysis, not a separate data stream.
Next Steps
Build or consolidate your BTP time series. Check whether your monthly Balance Statements are fully archived and whether your subaccount structure allows for an assignment to productive and non-productive environments. That is the first governance moment in preparing your BTP data foundation.
Assess your complete renewal data foundation. BTP consumption data is one of four data categories that make up a complete renewal data foundation. The other three, contract data, market data, and quality data, are covered in [Cluster 2: Building the Data Foundation for SAP Renewal Negotiations].
Contract Check as a structured starting point. The FinOptory Contract Check assesses your SAP contract position in four weeks: consumption data assessment, data foundation analysis, and renewal readiness evaluation. Fixed price EUR 7,900. An initial conversation is available without lead time.
Created 2026-05-21. Version v1, status: draft, approved for Bernhard review. Source basis: SAP_RISE/02, SAP_RISE/04, SAP_RISE/07 (partner-visible), FinOptory-Strategy-Brief-v2.md, Pillar-5-Outline-Renewal-Negotiation.md. SAP_RISE/08_rise_negotiation_playbook.md was not used.
Next Steps
If you would like your current SAP contract reviewed for risks and available commercial levers: the FinOptory Contract Check is a fixed-price engagement that delivers a structured basis within four weeks.
This article is part of our topic hub on the SAP renewal negotiation framework. To have one specific contract assessed, the FinOptory Contract Check delivers a structured basis within four weeks.
Last updated: July 2026