What the platform is, the four ways it is bought, and who owns the bill. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real SAP negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back. Session twenty six, and this opens module six, which covers the SAP cloud and SaaS portfolio around the core. We start with BTP, the Business Technology Platform, and there is a good reason it comes first. Every session in module five ended with something moving onto BTP: RISE extensions, GROW's side by side model, integration for the rest of the estate. This is where all of those decisions turn into money. So today: what the platform actually is, the four ways it gets bought, why consumption drifts upward on its own, and how to get control without becoming the department that says no. Three knowledge checks. Let's begin.
Five objectives. First, say what BTP is, which is not one product but a catalogue of services covering integration, extension, data, analytics and AI, each metered its own way. Second, tell the four models apart: CPEA, pay as you go, subscription and cloud credits, because which one you are on changes what overspend actually costs you. Third, explain why it drifts, since consumption platforms grow through small technical decisions made by people who cannot see the price. Fourth, get control without blocking, meaning alerts, quotas, chargeback and a named owner, so governance that developers can live with. And fifth, negotiate it properly, because BTP is usually the least negotiated line in an SAP deal and the discount structures are real.
Four things to frame it. A catalogue: dozens of services with different meters, so there is no single BTP price, only the sum of what you switched on. Consumption: spend follows technical decisions rather than purchase orders, and a developer can move the number on a Tuesday afternoon. Four models, because the same service costs different amounts depending on which commercial construct you bought it under. And unowned, which is the one I want to dwell on, because licensing watches user metrics, infrastructure watches capacity, and the platform bill sits in the gap between the two. Let me be specific about that gap.
Guest analyst clip.
One named person who sees it monthly and is expected to explain it. That is the fix, and notice how modest it is. No new function, no new tooling, no reorganisation. Just an answer to the question of whose number this is. If you take one action from this session, make it that one, because every other control we discuss today depends on somebody being there to act on it. Now, what is actually in the platform.
Four service families. Integration: connecting SAP to SAP and SAP to everything else, which is usually the first thing switched on and the steadiest consumer. Extension: where your custom development lives now that the core is standard, so runtimes, services and the tooling around them. Data and analytics: Datasphere, Analytics Cloud and the data services, which are storage and compute meters, and they grow with your data rather than your users. And AI services: the newest family and the fastest growing line on most platform bills, metered by usage and extremely easy to switch on. The practical consequence of a catalogue is this. There is no single question you can ask to find out what BTP costs. You have to ask which services are switched on, at what rate, and who turned them on.
Now the four buying models. CPEA is a prepaid annual commitment that you draw down against any service, and it suits you when you know roughly the total but not the mix. Pay as you go has no commitment, list rates, billed on what you use, and it suits experimentation at small volumes. Subscription is a fixed price for a fixed service and quantity, which suits one service running predictably in production. And cloud credits are a prepaid balance, often discounted, spent across services, which suits you when you have scale and want the discount tier. CPEA is the common answer for a mixed estate because it buys you flexibility across the whole catalogue. The trade is that the same flexibility makes drift easier, since any team can consume the same pool without asking anybody.
First knowledge check. Under CPEA, what happens to a prepaid commitment you do not consume by year end? A, it rolls forward automatically into the next year. B, it is typically forfeited, so use it or lose it. C, it is refunded against your next invoice. D, it converts into user licences of equivalent value. Pause here and pick an answer before you continue.
The answer is B. Prepaid consumption commitments generally expire at the end of the contract year, so unused balance is simply lost. And that makes oversizing a CPEA commitment the exact mirror image of the shelfware problem from session twenty two: you are paying up front for capacity you never draw down. A does sometimes happen, and only if you negotiated it, which is precisely the point I want to make. C and D are not how these constructs work at all. So the practical rule is to size the commitment to realistic consumption, ask for rollover in writing, and review the figure every year rather than renewing the same number out of habit, which is what most organisations do.
So why does platform spend grow quietly? Five reasons. The decision maker cannot see the price, because a developer choosing a service is solving a technical problem and the rate card is not on their screen. Switching on is trivial, with no purchase order, no approval and no procurement, which is the point of a platform and also the exposure. Nothing turns off, so test environments, abandoned prototypes and superseded integrations keep consuming long after anyone remembers them. AI services move fast, being the newest family and the easiest to consume heavily, so a single enthusiastic project can reshape your annual figure. And the bill arrives late, meaning that by the time an overage is visible in an invoice, the consumption pattern is months old and embedded in production. I want to push back on how people usually explain this.
Guest analyst clip.
Not carelessness, just a spending decision with no price attached. That reframe matters because it points at a completely different set of controls. If you think it is a discipline problem you write a policy, and policies do not change behaviour that nobody knew was costing anything. If you think it is a visibility problem you put the number in front of people, and that does.
Second knowledge check. Your BTP consumption is running forty percent above forecast in month four. What is the first move? A, buy more commitment now, before the rate goes up. B, find out which services and which teams, before buying anything. C, freeze all new BTP usage until the year end. D, move the workload to a hyperscaler instead. Pause here before you continue.
B. A meaningful share of consumption overruns turn out to be a handful of services, and often that includes something nobody meant to leave running. Buying more commitment before you know that is simply buying the mistake at scale, which rules out A. C treats every project as guilty, and it will earn you a reputation that makes governance harder for years afterwards. D is a genuine architectural option and it is not a month four answer. So diagnose first: which services, which teams, since when, and is anything running that should not be. In my experience the answer is frequently a great deal cheaper than the purchase order somebody wanted to raise.
Right, governance. Four controls, and the aim is visibility rather than approval gates, because gates get routed around. Alerts at thresholds: fifty, seventy five and ninety percent of commitment, sent to a named person, which is cheap, immediate, and converts a year end shock into a decision you can still make. Quotas per subaccount: a ceiling per team or project, which is not a block on work but a limit on how wrong any single team can go before somebody notices. Chargeback: consumption reported to the team that caused it, and this is the single most effective control on the list. And a named owner, one person accountable for the platform bill, which is session twenty two's lesson again. Let me explain why I am so against the gate.
Guest analyst clip.
Same outcome, no friction, and you keep the visibility. That is the argument, and the two month figure is about right in my experience. What actually happens is that a team lead sees their own consumption line at their own budget review, asks what a particular service is for, discovers nobody remembers, and switches it off. Nothing was blocked and nothing was escalated. The information simply arrived at the person who could act on it.
On negotiating the platform line, five points, and this is genuinely the least negotiated part of most SAP deals. Ask for the rate card, per service rather than a blended figure, because you cannot forecast a catalogue you have only seen summarised. Push on the discount tier, since larger prepaid commitments attract better rates and you want to know where the tier boundaries sit before you size the commitment. Ask for rollover, meaning unused balance carrying into the next year, which is frequently refused, occasionally granted, and costs nothing to ask for. Fix the rates for the term, because otherwise your per unit price can move underneath a commitment you have already paid for. And separate it from the RISE credit, because the allowance inside a RISE bundle is not your BTP budget, so know both numbers and do not let one hide the other.
Five traps. Treating the RISE allowance as the budget, when it is a starting allowance sized for modest use and real integration work exceeds it routinely. Oversizing the prepaid commitment, because unused balance is usually forfeited, so an overcautious commitment is money spent for nothing at all. No owner, so no forecast, since the bill sits between licensing and infrastructure and both assume the other is watching. Leaving non production running, meaning prototypes and test landscapes consuming for months after the project ended, which is common and entirely avoidable. And never renegotiating, because BTP tends to get bought once and rolled forward, when it is a consumption line that should be reviewed and repriced every year.
Last knowledge check. Which single control most reliably reduces BTP consumption growth? A, an approval gate before any new service is enabled. B, chargeback of consumption to the team that caused it. C, a quarterly report to the steering committee. D, reducing the prepaid commitment at renewal. Pause here, and think about who actually makes the spending decision.
B. The spending decision is made by a developer or an architect, so the control has to reach them. Chargeback does exactly that, because it puts consumption in front of the budget holder who owns the team, and behaviour changes without anybody being blocked. A sounds rigorous and it reliably fails, since gates slow work down, teams route around them, and you lose visibility as well as time. C informs people who are not making the decisions, which is comforting rather than useful. And D caps the invoice without changing the consumption, so you simply get the overage instead of the commitment. Make the cost visible where it is created. And here is the specific thing to go and do this week.
Guest analyst clip.
The highest return hour available on the platform side. So, five things for running the bill. Review monthly rather than annually, because consumption moves far too fast for an annual cycle, and a monthly look at the top five services catches most of it. Report by team rather than in total, since a single number tells you there is a problem and a breakdown by subaccount tells you where it is. Sweep non production quarterly to find what is running that nobody needs, and that one pays for itself the first time you do it. Forecast before you commit, using twelve months of actuals plus known projects, and then size the commitment slightly under rather than over. And reprice every year, because rates, tiers and your own mix all change, and a commitment rolled forward unexamined is money left on the table.
Three sentences. BTP is a catalogue rather than a product, spanning integration, extension, data and AI services with a separate meter on each, so there is no single price and you have to ask which services are switched on and by whom. It is bought four ways, and CPEA is the common answer for a mixed estate, with the important detail that unused prepaid balance is typically forfeited, so size the commitment slightly under and ask for rollover in writing. And consumption drifts because the people creating it cannot see the price, so the fix is visibility rather than approval gates: alerts, per team quotas, chargeback, and one named owner for the bill. Next session stays in module six and moves to SuccessFactors, so HCM SaaS licensing, per employee against per subscriber, and what happens to that model when your population churns.
Homework before session twenty seven, about ninety minutes, and the first one is more revealing than it sounds. One, find your BTP number: what did the platform cost last year in total? A surprising number of organisations cannot answer that inside a day, and how long it takes you is itself the finding. Two, list the top five services by consumption, because that list is usually shorter and more surprising than anybody expects. Three, name the owner, so who is accountable for this bill, and if the answer takes more than one sentence you have found your first action. Four, check what is still running, meaning any non production subaccount with consumption and no active project, and switch off one thing this week. And five, ask for the rate card: per service, current rates, and where the discount tiers sit, because you need all three before your next commitment renewal.
Five guides, all on redresscompliance dot com. SAP BTP consumption and CPEA covers the four models in much more detail, with worked examples of each one. BTP cost control and governance expands slide eleven, so alerts, quotas and chargeback as they actually work in practice. RISE hidden costs explains why the bundled BTP allowance is not a platform budget, which is the trap on slide thirteen. SAP AI services and pricing covers the fastest growing line on most platform bills and how it meters, which is worth reading before somebody in your organisation starts a project. And the SAP cloud portfolio overview is the map of the whole SaaS estate, which is exactly where module six goes next.
That is session twenty six. The thing to take away is that the platform bill is a consumption line with no natural owner, so name one, and make the cost visible where it is created. Next time, SuccessFactors. See you then.