The two axes SAP charges on, and why almost every surprise starts by misreading one of them. 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.
Alright, welcome in. This is SAP Licensing Mastery, session one of forty. Over the next twenty hours or so we are going to take apart the entire SAP commercial relationship, piece by piece. The counting rules, the contracts, named users, engines, indirect access, S/4HANA, RISE, the audits, and the negotiation at the end of all of it. I should tell you up front, this course has a point of view, and it is yours. Everything here is taught from the buyer's side of the table. Here is how a session works. I teach, and then I check. Three times today a question goes up on the screen with four options, and I want you to actually stop the video and pick one before I give you the answer. There is a short homework list at the end as well, about an hour of work, and it is the homework that turns this from watching into doing. Today is the map. By the end of it you will know what SAP charges for, which documents decide what you owe, and the five places enterprises reliably get hurt. Let's start.
Five things you should be able to do when this session ends. First, read both axes. SAP does not price on one dimension, it prices on two running in parallel, and you need to hold both in your head at once. Second, know the paper. There is a small stack of documents that actually binds you, and a much larger pile that only looks like it does. Third, place the estate. ECC, S/4HANA, RISE, GROW, BTP, and the SaaS applications are licensed differently from each other, and most of you are running several at the same time. Fourth, see the measurement. You should be able to say what USMM and LAW produce, what you declare yourself, and when SAP asks for it. And fifth, spot the five burns before they show up in a measurement result. Those five recur in almost every estate I have worked on. None of this goes deep today. Today is the map, and the detail comes in the thirty nine sessions after it.
Here is why this matters, in four ideas. Two axes. Named users by type on one side, packages and engines on their own business metrics on the other. You are licensed on both, always, and the gap between them is where the money hides. Type. The user question is almost never how many users you have, it is which type each of them holds. A Professional user and a self service user differ severalfold in price, so classification, not head count, decides the bill. Documents. Indirect and digital access charge for documents created by other systems, not for the people behind them. That is the signature SAP exposure and it gets a whole module later in the course. And once. The annual measurement counts all of it, one time a year. Whatever you have not right sized by the day you run USMM is what you are going to pay for. Read those four together. A clean user count over an unmeasured engine estate, or a tidy engine list over misclassified users, is half a picture, and SAP prices the whole one. Before we place your estate on that map, let's play a clip.
Guest analyst clip. Let me give you the view from the outside. When I walk into an SAP customer for the first time, I ask two questions. What do you own, and where is it running. Almost nobody can answer either one from a single document. What I usually find is an ECC system that has been in place for fifteen years, a set of order forms nobody has read since the people who signed them left, and a cloud subscription somebody bought separately, on a different renewal date, with a different metric. That fragmentation is not an administrative problem. It is a commercial one. SAP sees your estate as one relationship with one number attached to it. If you can only see it in pieces, you are negotiating with less information than the other side of the table, every single time. And the twenty twenty seven deadline sharpens all of it, because the decision it forces, stay, convert, or move to the cloud, is not really a technical decision. It is the moment your entire contract gets reopened. The customers who come out of that well are the ones who knew exactly what they owned before the conversation started.
Two things there worth underlining. The first is the question she opens with. What do you own, and where is it running. And the fact that almost nobody can answer it from a single document. That is not a filing problem, it is a negotiating position, and it is exactly why module two spends five sessions building an entitlement baseline. The second is what she said about twenty twenty seven. That deadline gets discussed as a technical migration date. Treat it as a contract event instead, because that is what it is. Everything you already own gets revalued in that conversation. Which brings us neatly to the map itself.
Five places SAP software lives, and five different commercial models. ECC on premise: perpetual licenses you already bought, plus support at twenty two percent every year. Mainstream maintenance ends in twenty twenty seven, with extended maintenance to twenty thirty at a premium, and that deadline is the single biggest lever SAP holds over its installed base right now. S/4HANA on premise: still perpetual, but with the Full Use Equivalent user metric, and a conversion path that reprices entitlements you already own. RISE and GROW: subscription ERP in SAP's cloud, software and infrastructure and services in one bundle, sized in Full Use Equivalents. BTP: the platform, bought as consumption through CPEA, pay as you go, or cloud credits. Easy to start, easy to overspend, and almost never governed. And the SaaS estate: SuccessFactors, Ariba, Concur, Fieldglass, Signavio, each with its own contract, its own metric, and its own renewal date. The two axes rule the ERP core. The cloud portfolio runs on subscription metrics instead, which is why a hybrid estate has to be read on both models at once.
Now the paper, because this is the part that settles arguments. Your software license agreement is the framework: definitions, use rights, and SAP's measurement and audit rights. Your order forms are the transactions, and each one references a specific version of the price and condition list. That price list matters more than people expect, because it carries the metric definitions, and SAP revises it over time. The version your order incorporates is the one that binds you, not the one on SAP's website this morning. Software use rights, incorporated by reference, say what each user type may actually do and how each engine is counted. The support schedule sets Enterprise Support at twenty two percent of net license value, how it is indexed, and the limits on terminating part of a license set. And anything in the cloud has its own order form with a term, a volume, service levels, and a renewal uplift. Everything else, and I mean the policy pages, the sales decks, the licensing explainers, binds nobody. So when an account team quotes something at you, the first question is always the same. Which signed document does that come from?
First knowledge check. Your account team cites the current price list to justify a higher user requirement than your contract implies. What decides what you actually owe? A, the current SAP price and condition list. B, the signed agreement and order forms, with the price list version they reference. C, the measurement output from USMM and LAW. D, SAP's published licensing guides and policy pages. Pause here and pick one.
The answer is B. Only signed paper creates an obligation. The current price list is SAP's own document, it changes over time, and the version your order form incorporates is the one that governs you, which is exactly why you need to know which version that is. A is the common trap, because the newest list is the one the account team is holding. C confuses measurement with entitlement: USMM counts what is deployed, it does not decide what you are entitled to. And D binds nobody at all, however official the document looks. Get comfortable saying one sentence out loud in those meetings. Show me where that is in my agreement.
So let's put the two axes side by side, because almost everything in the next thirty nine sessions hangs off this table. Named users count people. Every individual with access, licensed by type, whether or not they ever log in. The math is head count by type, and because a Professional costs several times a self service user, classification decides the bill. Your administrators declare it in the user records, USMM reads it, LAW consolidates it across systems. The usual trap is everyone created as Professional to be safe, and that is the most common single overspend in the SAP estate. Packages and engines count the business. Revenue, orders, employees, spend, documents, cores, memory. The math is metric times rate, measured every year, so your requirement grows as the business grows even when nobody deploys anything new. You declare most of it yourself, which means your own numbers become the evidence. And the trap on that side is engines nobody remembers buying, or a metric that quietly outgrew its entitlement between two measurements. Notice where digital access sits. On the second axis. It prices documents created by systems rather than people, which is why a spotless user count gives you no protection from it. Before we do the arithmetic, let's play a clip.
Guest analyst clip. In twenty years of sitting in SAP negotiations, the pattern almost never changes. The customer walks in with a user count. SAP walks in with a measurement. The gap between those two numbers is where the entire commercial conversation happens. What surprises people is that the user count is rarely the expensive part. It is the second axis, the packages and the engines, that moves the number, because those are measured on the business itself. Revenue, orders, employees, spend. Your estate can be perfectly stable and your license requirement still grows every year. And then there is the part nobody sees coming. The documents your other systems create inside SAP. No people involved, no logins, and it can still be the largest single line in a settlement. The customers who handle this well all do one unglamorous thing. They read their own estate on both axes before anybody from SAP asks them to. So read your entitlement on both axes, and read your interfaces before SAP reads them for you.
Three things in there worth holding on to. The first is the gap. You arrive with a user count, SAP arrives with a measurement, and the entire commercial conversation happens in the space between those two numbers, which means whoever prepared better owns that space. The second is that growth on the engine axis is automatic. Nothing has to be installed for your requirement to rise, and that is the part that surprises finance every single time. And the third is the interfaces. Documents created by your other systems, no people involved, no logins, and it can still be the largest single line in a settlement. Keep all three in mind, because the arithmetic we are about to do is where the first one gets decided.
Second knowledge check, and this one is arithmetic. A RISE sizing has four hundred Advanced Use users, one thousand Core Use users, and three thousand Self Service users. How many Full Use Equivalents is that? A, four thousand four hundred, one per user. B, seven hundred. C, one thousand four hundred. D, six hundred. Pause and work it out before you continue.
The answer is B, seven hundred. Advanced Use counts as one point zero, Core Use as nought point two, and Self Service at roughly one thirtieth. So four hundred, plus two hundred, plus one hundred, gives you seven hundred Full Use Equivalents. Now look at what that means commercially. The same four thousand four hundred people cost you seven hundred units or four thousand four hundred units depending entirely on how their roles are mapped, and that mapping happens in a sizing workshop, usually early, usually quickly, and usually with SAP holding the pen. Session twenty two does this properly. For now the rule is simple. Never let anyone size a RISE deal before you have mapped your own roles to those three categories.
How does SAP find out what you are running? Four mechanisms. USMM is the per system measurement program. It classifies users from the license type on their user record and counts what can be counted automatically, which means it counts what your administrators typed in years ago, not what people actually do today. LAW, and its newer form SLAW, consolidates the results across systems and deduplicates the people who exist in several of them. That deduplication is worth real money and it only works if you run it. Self declaration covers the engines a program cannot measure. You supply the numbers, which means your own numbers become the evidence in every later discussion, so treat that as a submission, not as a chore. And STAR is SAP's classification support, proposing user types from actual activity. Useful input, never a verdict, and no substitute for your own role mapping. Then there is the annual request. SAP asks once a year. What you send back is a negotiating document, and it should never be the first time you have looked at those numbers. On which, let's play a clip.
Guest analyst clip. The annual measurement is the most misunderstood event in the SAP calendar. Most customers treat it as a compliance chore. Somebody in Basis runs the program, exports the file, sends it off, and everyone moves on. Here is what it actually is. It is the opening position in a negotiation nobody has told you that you are in. Every number in that file becomes the baseline for the next conversation about money, and once you have submitted it, arguing with it is very hard. So the sequence matters enormously. Run it yourself first. Look at what it says. Fix the things that are wrong, the dormant accounts, the misclassified users, the engine you decommissioned two years ago that is somehow still being declared. Then submit. And do it early enough that fixing is still an option. A month before the request is not early enough. A quarter is. The cleanup itself is administrative work, no negotiation, no approvals, but it has to happen before the file goes out, because afterwards it stops being cleanup and starts being an argument. I have watched the same estate produce two completely different numbers three months apart, with no change to the software at all. The only difference was that somebody looked at it first.
The sequence she describes is the whole point. Run it, read it, fix it, then submit. Most organisations do run, submit, and then discover. And notice what she said about the same estate producing two completely different numbers three months apart with no change to the software at all. That gap is not a compliance issue. It is the cost of not looking. The measurement is one of the very few moments in this entire relationship where the work is completely inside your control and costs you nothing. Take it.
Here is the lifecycle, and where the money leaks at each stage. At purchase, the discount looks generous against the price list and everyone in the room is focused on the percentage. The metric definitions and the true up clause nobody read are what actually price the next decade. At deployment, users get created as Professional because it is the safe default, interfaces multiply, and engines get switched on for a project and never switched off. Entitlement and reality separate within months. At measurement, that drift turns into a number, and that number is where SAP opens the conversation. And at conversion or renewal the whole contract gets repriced, on SAP's valuation of what you already own. Every stage has a default outcome and the default favors SAP. Watch the cost curve though. Fixing a classification problem at stage two is free. Fixing exactly the same problem at stage four, with a signature date in the diary, costs real money, because by then it is not a cleanup, it is a concession.
The five burns. One, indirect and digital access. Non SAP systems creating SAP documents, charged for whether or not a person is involved. The largest single exposure in most estates and the reason module three exists. Two, user overclassification. Professional as the default type for everybody. Reclassification on its own routinely takes a double digit share off the user bill, and it needs no negotiation at all, just work. Three, engine drift. Package metrics track the business, so revenue grows, orders grow, head count grows, and your license requirement grows with them while nobody deploys a thing. Four, HANA runtime confusion. A runtime license covers the SAP application it came with and nothing else. Point any other workload at that database and you need full use, and that gap surfaces in audits. Five, the conversion moment. Contract conversion to S/4HANA retires your old entitlements at SAP's valuation of them. Walk in unprepared and you buy rights you already paid for once. If you remember one slide from today, this is a good candidate.
Last knowledge check. In a heavily integrated estate, which finding is typically the most expensive? A, dormant users left active in the user records. B, a self declared engine measured above its entitlement. C, digital access documents created by connected non SAP systems. D, HANA runtime used for a non SAP workload. Pause here, and think about which of those scales with integration rather than with head count.
C, digital access. And the reason is scale. Dormant users are real money, but bounded by how many people you employ. An engine overage is bounded by the metric. Runtime misuse is narrow and specific. Digital access scales with the document volume your integrations create, so it grows with the business and with every new interface anyone builds, and none of it appears in a user count. That is how a customer with a genuinely clean user position still opens a letter with an eight figure number in it. Module three is five sessions on this one topic, and it is the module I would not skip.
So what do the estates that do not get hurt actually do differently? Five things. One owner, named, with sourcing and IT and legal in a defined loop. Not the Basis team by accident because they happen to hold the passwords. An entitlement baseline: every agreement, order form, and price list version in one place, reconciled into a single statement of what you own. Module two builds that with you. Measurement rehearsal: you run USMM and LAW on your own schedule, months before SAP asks, and you fix what it shows while fixing is still free. A document flow map: every non SAP system that reads from or writes into SAP, and what it creates. Draw yours before SAP draws it for you. And a calendar. SAP's fiscal year ends the thirty first of December, and your measurement date, your renewal dates, and your conversion decision are the leverage points. Put them on one page and you start seeing your own year the way SAP already sees it. One last clip before we wrap up.
Guest analyst clip. If you asked me what separates the customers who consistently do well from the ones who get hurt, it is not size, and it is not how clever their negotiators are. It is preparation that started long before the deal. The ones who do well can tell you, on any given day, what they own, what they are running, and what their next three commercial dates are. That sounds mundane. It is worth millions. The ones who get hurt are usually reacting. A letter arrives, or a deadline lands, and suddenly there are six weeks to understand a twenty year relationship. In that position you are not negotiating, you are responding, and the price of responding is always higher. And the asymmetry is worth being honest about. SAP runs this conversation continuously, with people who do nothing else. You run it once every few years, alongside your day job. You will not close that gap with cleverness in the room. You close it with work done in the quiet months, when nothing is at stake and nobody is waiting on an answer. The good news is that the work itself is not complicated. An inventory, a measurement you run yourself, a map of your interfaces, and a calendar. None of that requires permission from anyone. It just requires somebody to own it before the next letter arrives.
That asymmetry is the honest frame for this whole course. SAP runs this conversation continuously, with people who do nothing else. You run it every few years, alongside your actual job. You do not close that gap with a clever moment in the room. You close it with an inventory, a measurement you ran yourself, an interface map, and a calendar, all of it done in the quiet months when nothing is at stake and nobody is waiting on your answer. That is the entire operating model, and none of it needs anyone's permission. Let's land the session.
Three sentences to take away. SAP prices two axes at once, named users by type and packages and engines by business metrics, and you are measured on both every single year. A small stack of signed documents decides what you owe, and price lists, licensing explainers, and account team assertions do not. And the estate drifts by default at every stage, from purchase through measurement to conversion, which makes the rest of this course one long answer to the question of how you hold it still. Next session we go into the first axis properly. The user type catalog, the classification rules, and why classification is the whole game.
Before session two, about an hour of work, and please actually do it, because sessions two and three assume you have. One, pull the paper. Find your SAP license agreement and your three largest order forms, and note which price list version each one references. Just locate them, no analysis yet. Two, count the users. Export user counts by license type from your production systems. Rough totals are fine, the split by type is the whole point. Three, list the engines on those order forms and the metric each one is measured on. Four, map the interfaces. Every non SAP system that writes into SAP. That is the first sketch of your digital access exposure, and it is usually the most uncomfortable list in the pile. Five, find the support bill. Last year's invoice, the percentage applied, and the license base it is calculated on. That is your starting position, and everything we build over the next thirty nine sessions sits on top of it.
Five guides if you want to go deeper before next time, all on redresscompliance dot com and all written from the buyer's side. The SAP licensing guide is this session in written form. The named user license types guide is your preparation for session two. Managing package and engine licenses covers the second axis in the detail we skipped today. The complete digital access guide is worth reading before you draw that interface map. And the piece on USMM, LAW, SLAW and STAR walks through the measurement tooling with the run order and what each output actually proves. Read the first two at minimum. That is session one. See you in session two.