Why the exposure that made the headlines never appears in a user count. 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 eleven, and this opens module three. Last session closed module two with the entitlement baseline: users counted, engines counted, gaps calculated, evidence attached. A complete picture of your position. Today we look at the thing that document cannot see. Indirect access. The exposure created by systems and people who never log into SAP at all, and which has cost SAP customers more in headlines than any other topic in this course. This is a two session pair. Today is the history, the principle and the risk: why access through another system can be chargeable, what the two famous cases actually turned on, the six architectures where this appears, and the two pricing models that now coexist. Next session is Digital Access in detail, the nine document types and the arithmetic. I want to set expectations honestly: today has more history in it than most sessions, and that history is load bearing, because it explains why the model looks the way it does. Three knowledge checks. Let's start.
Five things by the end. First, state the principle: explain in one sentence why access through another system can be chargeable, and understand why that is not a loophole somebody invented. Second, know the two cases, what Diageo and AB InBev actually turned on, and what each one changed about the industry. Third, spot the shapes: the six architectures where indirect use appears, almost none of which were built for licensing reasons. Fourth, read the two models: the classic named user exposure and the Digital Access document model, and know which one your contract puts you on. And fifth, choose a posture. Ignore it, map it, or price it. Only one of those three is actually a decision, and the other two include the one most organisations are on by default.
Four things to frame this. No login: the people creating the exposure never log into SAP. They use a web shop, a portal, a CRM, or they are not people at all. Headlines: two court cases made this famous in 2017, and the numbers reported were large enough to change how every SAP customer thinks about integration. Built by IT: every interface in your estate was created by somebody solving a real business problem, and not one of them was designed with a licence metric in mind. And two models: older contracts read on named users, while Digital Access prices documents instead, and which one applies to you is a contractual question rather than a chronological one. So here is the frame. This is the third thing SAP charges for. Your users are counted, your engines are counted, and this is the thing that connects to both while appearing in neither. Let's play a clip on exactly that.
Guest analyst clip. Here is what makes this topic genuinely different from everything in the last ten sessions. Every exposure we have discussed so far is visible in a list somewhere. Users appear in a user table. Engines appear on an order form with a metric next to them. You can go and look at them, and once you have built the baseline you have. This one appears in no list at all. The people generating it do not log into SAP. They are customers on a web shop, or sales staff in a CRM, or suppliers on a portal, and quite often they are not people at all, they are a nightly job moving records in bulk. Nobody involved thinks of it as SAP access, because from where they are standing it simply is not. They are using a different system that happens to be connected to something. So when a client tells me confidently that they have no indirect exposure, my first question is not about their contract. It is how many systems write into SAP. And the answer is almost always more than they think, because the list has never been written down, and the person who could write it works in integration rather than in licensing. Those two people, in my experience, have often never had a conversation.
Those two people have often never had a conversation. That is the actual root cause of this entire topic, and it is worth stating plainly because it tells you where the fix lives. It is not in a report or a tool. It is a meeting between the person who knows what connects to SAP and the person who knows what that costs. In most organisations those are different teams, different reporting lines, and different vocabularies. Which is good news, in a way, because meetings are cheap. So let's look at the principle they need to discuss.
Why can access through another system be chargeable? Four points, and I want to make the case properly rather than dismissively, because organisations that treat this as absurd tend to prepare badly for it. You license use, not logins: the agreement grants the right to use the software, and a login is one way of using it. It was never defined as the only way. The value is the data: if a person or a system gets SAP data, or creates an SAP record, then the software did work for them, whatever screen they happened to be looking at. The intermediary is not a shield: putting a portal in front of SAP changes the interface rather than the underlying use, and that is the whole of the argument in one line. And it is in the contract: most agreements say this explicitly, in wording about access by any means, direct or indirect. So it is rarely a surprise in the paper. It is only ever a surprise in practice. You may disagree with the commercial outcome, and that is a negotiation you can win. You are unlikely to win the principle.
Now the history, briefly, because it explains the model. Diageo, 2017: Salesforce users reaching SAP data through an integration without SAP named user licences. What changed after it is that indirect access stopped being theoretical. Every CIO with a CRM integration asked the same question that quarter, and most of them did not like the answer. AB InBev, also 2017: a large claim covering integrations and third party access across the estate. What that confirmed is that the exposure was not a one off, and that the sums involved could be very large indeed. The reaction: customers demanded a model that could be predicted and budgeted, because the named user reading was neither. And SAP introduced Digital Access in 2018, pricing by document rather than by user. Where that leaves you is the important line on this slide. Two models now coexist, older contracts were not automatically converted, and which one applies to you is determined by your paper and not by the calendar. The legacy of both cases is not the amounts. It is that pricing moved from a per user argument to a per document one, and a document is something you can count in advance.
First knowledge check. A warehouse system creates goods receipts in SAP automatically. Nobody in the warehouse has an SAP account. What is the position? A, no exposure, since no SAP users means nothing to license. B, this is indirect use, and it is chargeable under either model. C, it depends entirely on how many warehouse staff there are. D, only the technical interface account needs licensing. Pause here and pick one.
The answer is B. SAP records are being created, so the software is doing work, and the absence of logins is the definition of indirect rather than a defence against it. A is the assumption that produced the headline cases, and it is probably the most expensive sentence in this module: no users, nothing to license. C matters for how much under the older named user reading, and not at all for whether, so it is answering the second question before the first. And D is session eight's technical account error wearing a different hat. The interface account is the pipe. The documents flowing through it are the licensable thing, and one technical user licence does not cover thirty thousand goods receipts.
So where does this actually show up? Six shapes. The customer facing portal: a web shop or self service site reading stock, prices or order status from SAP, and creating orders in it. The CRM integration: Salesforce or similar, showing SAP customer and order data to people who have no SAP account. That is the Diageo shape precisely. The supplier network: vendors submitting invoices or confirming deliveries through a portal that writes into your system. The middleware layer: an integration platform moving records in bulk, where the volume is high and the visibility is low and nobody thinks of it as access at all. The reporting warehouse: extracting SAP data for analysis consumed by hundreds of people who will never see an SAP screen. And the bot or agent: automation, and increasingly AI agents, reading and writing SAP records. That last one is the newest shape and the fastest growing. Let's play a clip on how all six of these got built.
Guest analyst clip. I want to say something in defence of the people who build these integrations, because there is a tendency to talk about indirect exposure as though somebody was careless. Nobody was careless. Think about who builds an interface. It is an architect or a developer solving a real business problem. Customers want to see their order status online, so we build a portal. The sales team needs SAP data in the CRM they actually use, so we integrate it. Suppliers should submit invoices electronically rather than by email, so we open a channel. Every one of those is good work, and every one of those made the organisation better. At no point in any of those projects did a licence metric appear in a design document, and I would not expect it to. It is not the architect's job to know that creating a sales order from a portal has a price attached, and honestly, in most organisations, nobody has ever told them. So the fix is not to be more careful. The fix is one line in the architecture review, asked of every new integration: does this create or read SAP records, and roughly how many a year? That is a question an architect can answer in thirty seconds. It just has to be asked, by somebody who knows why it matters.
One line in the architecture review, asked by somebody who knows why it matters. I would take that literally, because it is genuinely the cheapest control in this entire course. You are not asking architects to become licensing experts, which would not work and would not be reasonable. You are asking one factual question that they can answer instantly and that nobody currently asks. And the reason it works is timing: at design stage the answer can still change the design, and at audit stage it can only change the price.
Second knowledge check. Your contract predates 2018 and has never been amended. Which model applies to your indirect use? A, Digital Access, because SAP introduced it for everybody. B, the named user reading in your existing contract, unless you have moved. C, whichever produces the lower figure. D, neither, because pre 2018 contracts predate the concept. Pause here before you continue.
The answer is B. Digital Access was offered, not imposed. Existing customers had to adopt it, usually through a programme with its own commercial terms attached, so your paper is what decides which model you are on. A is a very common and very expensive assumption, and I have watched organisations model an entire exposure on the wrong metric because of it. C is not how contracts work: you do not get to select the more favourable model at each measurement, however reasonable that sounds. And D confuses the model with the principle. The indirect use wording long predates 2018, and it is the wording rather than the model that creates the exposure in the first place. Let's play a clip on that distinction, because it is the one that costs people money.
Guest analyst clip. There is a question I ask early in any indirect access conversation, and a surprising number of organisations cannot answer it. Which model are you on? Because there are two, and they price the same architecture in completely different ways. Under the older reading, which is what most pre 2018 agreements say, the exposure attaches to the humans behind the integration. Every person who benefits from SAP data through that portal potentially needs a named user licence. That is very hard to count, very hard to forecast, and it is the reading that produced the numbers people remember from the court cases. Under Digital Access, you pay for documents created rather than for people. It is countable. You can forecast it. You can budget for it. Now here is the part that catches people out. Digital Access was offered, it was not applied to everybody automatically. If your contract predates it and nobody signed anything, you are still on the older reading, whatever you may assume. And I have sat in rooms where a customer confidently described their document exposure and then discovered, when we read the paper, that documents were not the metric their contract used at all. So before you calculate anything, find out which model your agreement actually puts you on. That single question changes every number that follows it.
So, the two models side by side. The named user reading: older agreements, where the humans behind the integration need named user licences. Hard to count, hard to predict, and it is the reading that produced the headline cases. Digital Access, from 2018: you pay for documents created rather than for the people behind them. Countable, forecastable, and the subject of the entire next session. The difference in one line: one model prices people you cannot see, and the other prices records you can count. That is why most customers who examine both end up preferring the second, even when the arithmetic is not obviously cheaper. And the move between them is a commercial negotiation, usually with an adoption programme attached, which we cover in session fourteen. I want to be careful here: neither model is automatically cheaper. The document model is predictable, and predictability is worth a great deal when the alternative is an open ended argument about who counts as a user.
Three postures, and what each costs. Ignore: no inventory of integrations, no document count, no position. What it costs you is whatever the number turns out to be, discovered by somebody else, on their timing. Map: you know every integration and roughly what volume each one generates. That costs a few days, and it converts an unknown into a number you can plan around. Price: you have modelled the exposure under both models and you know which one you would rather be on. That costs a few weeks, and it turns the topic from a threat into a negotiating position. Now, the observation that matters. Ignore is not really a posture. It is what happens when nobody chooses, and it is the only one of the three where somebody else decides when this conversation takes place. Everything in this course comes back to that, and it is particularly true here, because the discovery event for indirect access is usually not a friendly one.
Five reasons this expands while nobody notices. Integration is the goal: every architecture strategy of the last decade rewards connecting systems, so the exposure grows as a side effect of doing the right thing. Nobody in the project knows: the people building interfaces are solving business problems and licensing is not in the design review. It has no counter: users appear in a user list, but documents arriving from an interface appear in a business process, and nobody reads a business process as a licence metric. Volume follows success: a portal that works gets more traffic, so the better the project the faster the exposure grows, which is a genuinely uncomfortable relationship. And automation multiplies it: one bot can create more documents in a night than a department creates in a month, and it never appears as a person anywhere. Notice that not one of those five involves anybody making a mistake. That is what makes this different from most of the exposures in this course.
Last knowledge check. You find an integration nobody had documented, creating thirty thousand documents a year. What do you do first? A, report it to SAP immediately, before it grows further. B, add it to your integration inventory and quantify it under both models. C, switch it off until the licensing position is clarified. D, nothing, since it has run for years without anybody raising it. Pause here, and think about what you actually know at this point.
B. You have found a fact, and you do not yet have a position, and those are genuinely different things. Quantifying under both models tells you the size of it and which model you would rather be on, and everything you do later depends on those two answers. A discloses a number you have not verified, and as we will see next session there are exemptions and exclusions that may reduce it substantially, so you may be volunteering for a bill you do not owe. C breaks a working business process over a licensing question, which is almost never proportionate at the discovery stage and will make you extremely unpopular. And D is the ignore posture, chosen deliberately this time, which is at least honest, and it still hands somebody else the timing.
Five things that stop this being a surprise. Build the integration inventory: every system that reads from or writes to SAP, with an owner and a rough volume. Most estates have never had that list at all. Add a licensing question to design: one line in the architecture review asking whether this creates or reads SAP records, and at what volume. Read your own clause: find the indirect use wording in your agreement and know exactly what it says before somebody quotes it back at you. Count documents now, even roughly, because a number you produced yourself is worth considerably more than a precise one produced by somebody else later. And watch the automation, because bots and AI agents are the fastest growing source and they are usually deployed by teams who have never heard of this topic. Let's hear why the first of those five matters more than the other four.
Guest analyst clip. If you do one thing after this session, build the integration inventory. It is unglamorous and it takes a few days and it is the single highest value artefact in this entire module. What goes in it is simple. Every system that reads from or writes to SAP. For each one: what it is, who owns it, what it does, and roughly how many SAP records a year it touches. That is four columns. You do not need precision at this stage. An order of magnitude is enough to tell you which three integrations matter and which twenty do not. Now, two things will happen when you build it, and both are useful. The first is that the list will be longer than anybody expected. There is always at least one integration nobody in the room knew about, usually built for a project that ended years ago and quietly still running. The second is that you will find the volume is extremely concentrated. Typically two or three integrations generate the overwhelming majority of the records, and everything else is noise. That concentration is good news, because it means the analysis you have to do properly is small. And once you have that list, you have converted this topic from an unbounded anxiety into a bounded piece of work, which is most of the value right there.
From an unbounded anxiety into a bounded piece of work. That is what the inventory buys you, and it is worth more than the numbers in it. Indirect access has a reputation that makes people avoid looking at it, and avoidance is the one response that guarantees the worst version of the outcome. Four columns and a few days converts it into a list where two or three lines matter. And notice that the concentration point is genuinely good news: you do not have to analyse thirty integrations carefully. You have to analyse three.
Three sentences. You license use rather than logins, so access through another system can be chargeable, and that principle sits in the paper rather than having been invented after the fact. Two cases in 2017 turned a theoretical clause into a board level topic, and the industry response was Digital Access, which prices documents instead of people. And which model applies to you is a contractual question, while the posture that costs the most is the one nobody actually chose. Next session is Digital Access in detail: the nine document types, what counts and what does not, what is excluded, and how the model is genuinely calculated. If today was why this exists, next time is how the arithmetic works.
Homework before session twelve, about an hour. One, list the integrations: every system that reads from or writes to SAP. Ask the integration team rather than guessing, and expect the list to be longer than you thought. Two, find your clause: the indirect or third party access wording in your agreement. Read it exactly, and note which version of the paper it comes from. Three, check which model: have you signed anything adopting Digital Access? If nobody knows, establishing that is the first job, and it is a five minute question to the right person. Four, pick the biggest: whichever integration creates the most SAP records, and get one rough annual volume for it. That is enough to start. And five, ask about bots: any automation or AI agent touching SAP. This is the newest shape and it is usually completely invisible to whoever owns licensing.
Five guides, all on redresscompliance dot com. The indirect access pillar puts the whole topic in one place, including the history behind slide five in more detail than we have time for. The indirect access and Digital Access licensing guide explains how the two models relate and what determines which one applies to you, which is the question from the second knowledge check. The indirect access liability report covers current exposure patterns across real estates and where the volume actually sits, which is useful for sanity checking your own inventory. The case study on indirect access resolution at a tech firm is a worked example of a claim and how it was resolved, end to end. And the piece on API and indirect access changes covers the newest shapes from slide eight, including automation and API driven access, which is the part of this topic still moving.
That is session eleven. You now know why this exposure exists, where it comes from, and which two models could price it. Next time we take the model most people would rather be on and go through it properly: the nine document types, the counting rules, and what is excluded. See you then.