The first project is never the one that hurts

SAP BTP spending rarely gets away from anyone during the first project. That one has a business case, a defined scope, and a steering group that reads the invoice. The consumption is small, the number disappears into the rounding on the ERP budget, and nobody minds.

What follows is the part people miss. The platform becomes the default answer for the next several things. An integration here, a small extension application there, a workflow finance asked for, a data service somebody needed for a report. Each one is modest, each one is defensible on its own, and none of them goes back through the approval the first project went through.

Eighteen months later a finance business partner asks why a line that was never in the plan has become significant, and the platform team has no answer ready. Nobody did anything wrong. The spending grew in increments too small for anyone to have been asked to approve them.

Consumption moves the decision to the keyboard

The structural reason explains most of what follows. A licence agreement puts the spending decision inside a procurement event. Somebody negotiates, somebody signs, and the number holds until renewal. A consumption model spreads that same decision across a thousand small engineering choices.

So the people who now control the spending are the people writing the code. The developer who picks a runtime size. The integration consultant who chooses a polling interval. The architect who decides how long staging data sticks around. Every one of those choices carries a price, and nobody has told the person making it what that price is.

None of this makes consumption pricing a bad deal. Starting something on a Tuesday without a procurement cycle is a genuine advantage, and plenty of the work now running on the platform would never have survived a licence conversation. The flexibility that makes it easy to start is what makes it easy to drift.

The person who signed still owns the commercial relationship and still takes the questions from finance. They no longer own the thing that moves the number. Every control that works is an attempt to close that gap.

The things that keep running after everyone left

Non-production environments are the first place I look, and usually the easiest win. They get built at something close to production shape, because sizing them down takes effort and nobody wants the test to be the thing that fails. Then the project ends and they keep running at that shape, every night and every weekend, for years.

The second place is services that outlived the project that provisioned them. Something gets stood up for a proof of concept, the proof of concept succeeds or dies, the team moves on, and the service carries on billing. In every review I have done this is the most common finding, and it is rarely one large item. It is a dozen small ones that add up.

Neither needs a clever tool to find. They need somebody whose job it is to look, on a schedule, with the authority to switch things off. The same pattern shows up on the seat side of the house in the real cost of an unused license, and the fix is identical, a named person with a recurring calendar entry.

Design choices bill every day they run

Integration patterns are where the interesting money sits. A job that polls a source system every minute costs continuously, whether or not anything changed, and it costs the same on a quiet Sunday as at month end. An event-driven design costs when something happens. Both can be correct. The polling version often wins because it is faster to build and nobody priced the difference over three years.

Data volume and retention behave the same way. Somebody decides during build how much history to keep in the hot store, picks a generous number so nothing is ever missing, and moves on. That decision is never revisited, and it is charged every month for the rest of the platform's life. Retention is one of the few settings where asking the business produces a smaller answer than the technical team assumed.

A design decision costs money every day it runs, which is why reviewing the architecture repays more than any amount of after-the-fact reporting. The same argument runs through SAP clean core as a budget decision, where choosing where logic lives decides what it costs to operate for the next decade.

AI usage breaks the link with headcount

The newer driver is the one most cost models have not caught up with. AI and agent services charge for what gets used rather than for how many people hold a licence. Traffic growth and cost growth are now coupled in a way seat licensing never coupled them, because a busy quarter in the business becomes a busy quarter on the platform.

A successful agent makes this sharper. Adoption is what everyone wants, and adoption is exactly what moves the consumption. A team that doubles the documents it processes doubles a cost line that used to sit flat, and the business case that justified the agent assumed the older shape of the bill.

Whatever the specific rates are in your agreement, read them there rather than in a slide or an article, because the commercial detail varies by contract and by when you signed. We have covered AI token spend becoming a budget line in SAP estates, and the advice survives any change in the numbers, which is to forecast the volume before you forecast the cost.

You cannot control what you cannot attribute

Attribution comes first, and a subaccount and directory structure that maps to real owners is the highest-value piece of governance on offer. It turns one platform bill into a set of numbers with a name against each of them. Get it wrong at the start and every later control becomes guesswork. SAP BTP makes that structure cheap to change early and painful to change later, so it deserves an hour of argument in week one.

Showback to those owners changes behaviour on its own. A team that sees its own number every month asks different questions from a team that has never seen one. Chargeback is stronger and much harder to agree, so start with showback, make it accurate, and let the first awkward conversations do the work.

Somebody then needs to own the platform's commercial position by name. That person has to be technical enough to read the consumption and explain why it moved, and senior enough to stop something that should not continue. Splitting those two qualities across two people is the failure I see most, because the one who can read the data cannot act on it and the one who can act cannot read it. The same logic applies at renewal, which negotiating a multi-year SaaS renewal covers in more detail.

What holds when nobody is watching

Environment lifecycle rules with a real expiry date do more work than any policy document. Every non-production environment gets an owner and an end date when it is created, and it stops on that date unless somebody renews it. The renewal takes a minute, and the absence of one is a signal you were never going to get any other way.

Then review the patterns that cost the most, because that is where the real money is. Pull the top consumption lines, find the design decision behind each one, and ask whether it would be made the same way today. A polling interval, a retention window, a runtime sized for a load test that finished a year ago. The effort to change any of them is small and the saving repeats every month.

If you do one thing this month, take last month's consumption, sort it high to low, and put a human name against the top ten lines. Not a team name, a person. Whatever you cannot attribute is the part of the platform nobody is looking after, and that is where the next surprise is already growing.