The nine document types, what counts, and what does not. 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 twelve. Last time we covered why indirect access exists, the two cases that made it famous, and the two pricing models that now coexist. We ended on the observation that one model prices people you cannot see and the other prices records you can count. Today is the counting. Digital Access in detail: the nine document types, the four rules that govern how they are counted, the exclusions, how to produce your own number, and how the price behaves. This is the most arithmetic heavy session so far and I want to be clear about why that is worth your time. Once you can calculate this yourself, indirect access stops being the topic people avoid and becomes a line in a plan. Not a comfortable line, necessarily, but a known one. And the single rule on slide five is worth the whole session on its own, because getting it wrong inflates an estimate by a factor of two or three. Three knowledge checks. Let's start.
Five things by the end. First, name the nine document types the model counts, and understand why the sales and purchase sides usually dominate the total. Second, apply the counting rules: counted once, at creation, on the initial document, which is the rule that stops one order becoming several charges. Third, know the exclusions, because they can move an estimate by a very large margin and they are easy to miss. Fourth, measure your own, which means producing a defensible document count from your own system and understanding what SAP's estimation service does differently. And fifth, read the price curve: why the model is tiered, and what that implies for how much you buy and when you buy it.
Four things to frame this. Nine types: the whole model rests on nine document types, and everything else your integrations do is out of scope. That is a much smaller surface than most people expect when they first hear about this. Once: a document is counted once, at creation, on the initial document, and follow on documents in the same chain are not counted again. Forecastable: document volume tracks business volume, which your finance team already forecasts, so this is the first licence metric you can genuinely put in a plan. And tiered: the unit price falls as volume rises, so the shape of the curve matters as much as the count when you come to buy. Here is the framing for the session. The reason customers prefer this model is not that it is always cheaper. It is that you can calculate it yourself, in advance, and be confident in the answer. Let's play a clip on that.
Guest analyst clip. I want to explain why I like this model, and it is not because it is cheap. Sometimes it is and sometimes it is not. I like it because it is the first SAP metric you can genuinely put in a three year plan and be roughly right. Think about what you are counting. Documents. Sales orders, invoices, purchase orders, goods movements. Your finance team already forecasts every single one of those, because they are the business. They will tell you how many orders you expect next year, because that is their job and they have been doing it for decades. So for the first time, a licence metric maps directly onto a number the organisation already produces. Compare that with the alternative. Under the named user reading, you would be trying to count how many people at a customer might conceivably view SAP data through a portal this year. That is not a forecastable quantity. It is barely a knowable one, and every conversation about it becomes an argument about definitions rather than about numbers. So when people ask me whether Digital Access is a good deal, I say that is the wrong question. The right question is whether you would rather negotiate about a number both parties can calculate, or a number neither party can. And I would take the calculable one almost every time, even at a slightly worse price.
Would you rather negotiate about a number both parties can calculate, or a number neither party can. That is a genuinely useful way to evaluate any licence metric, not just this one, and I would keep it for the negotiation module. A metric both sides can compute produces a disagreement about price, which is a normal commercial conversation. A metric neither side can compute produces a disagreement about reality, and those go on for months. So let's look at what actually gets counted.
The nine document types, grouped by where they come from. The sales side: sales documents and billing documents. Usually the largest single source, because customer facing portals and CRM integrations generate them continuously and in volume. The purchase side: purchase documents and invoices. Supplier portals and procurement integrations sit here, and the volume follows your supplier count and your transaction frequency. The logistics side: material documents, service and maintenance documents, and quality management documents. Warehouse systems, plant systems and field service tools generate these. And the finance and people side: financial documents and manufacturing documents. Often lower volume, and worth checking anyway, because automated postings can be surprisingly high in an estate with a lot of interfaces. One instruction that matters more than the grouping: read the current list in your own agreement rather than from memory or from a slide, including this one. The composition has been adjusted over time and it is the wording in your paper that binds.
Four counting rules. Counted once: a document is counted a single time, when it is created, so reading it later, changing it later or reporting on it adds nothing at all. Initial document only: the first document in a chain counts and the follow ons do not, so one order that creates a delivery and an invoice is one count rather than three. Creation, not access: the trigger is the creation of a record rather than a query against one, which means read only integrations and reporting extracts are a genuinely different question. And per year: the count is annual and it resets, so this is a run rate metric, and growth matters far more than any single year's figure. Now, the second of those is the one people miss, and missing it inflates an estimate by a factor of two or three. Count the chain once, at its head. Let's play a clip on exactly that, because it is the difference between a frightening number and a real one.
Guest analyst clip. If there is one rule to take away from this session, it is the initial document rule, because getting it wrong is the difference between a number that is frightening and a number that is real. Here is what happens. Somebody is asked to estimate the document exposure. They go to the system and count sales documents, and deliveries, and billing documents, and material movements, and they add all of those together. And the total is enormous, and there is a difficult meeting, and somebody starts talking about millions. But look at what they actually counted. One customer order came in through the portal. That created a sales document. The sales document generated a delivery. The delivery generated a goods issue. The goods issue generated an invoice. That is one business event, and it produced four records, and they counted it four times. Under the rules it is one. The chain counts once, at its head. So when you see an estimate that seems disproportionate to your business, before you do anything else, check whether somebody has counted the chain. In my experience that single correction takes the number down by a factor of two or three, and it takes about an afternoon to establish. That is the highest return afternoon in this module.
First knowledge check. A portal order creates a sales document, then a delivery and an invoice follow automatically. How many documents count? A, three, since each document is a separate record. B, one, the initial document, with the follow ons in the same chain. C, two, the sales document and the invoice, but not the delivery. D, none, since they were created by a process rather than a person. Pause here and pick one.
The answer is B, one. The initial document in a chain is what counts, and the documents that follow from it in the same process are not counted again. A is the most common way an estimate gets inflated, and it is usually exactly how a frightening first number gets produced, which is why we spent a clip on it. C invents a distinction the rules do not make, and I mention it because people do sometimes reason their way to a partial count. And D is last session's error returning: creation by a process is precisely what this model exists to price. The absence of a person is the point of Digital Access rather than an exemption from it.
Now the exclusions, which is where a first estimate usually loses most of its bulk. Documents created by licensed users: if one of your named users creates it through the SAP interface, it is already covered, because the model prices indirect creation rather than all creation. Follow on documents: everything downstream in the same chain, and I am restating it deliberately because it is the largest single reduction in most estimates. Reads without creation: a portal that only displays order status creates nothing at all, so query traffic is a different conversation from document creation. Non production systems: test and development volume should not be in a production count, and it frequently is when nobody checks which system the query ran against. And documents outside the nine: anything not on the list is not counted, and your integrations generate a great deal of activity that is not on that list. Add those five together and the honest number is typically far below the first frightening one.
Second knowledge check. Your first estimate comes out at four hundred thousand documents a year and it feels far too high. What is the most likely cause? A, the business genuinely creates that many, so accept it and plan. B, follow on documents are being counted, and test data may be included. C, the nine types have been read too broadly. D, the count is per quarter rather than per year. Pause here before you continue.
The answer is B. Those two errors together account for most inflated first estimates, and both of them are mechanical rather than interpretive, which means both are quick to check and quick to fix. A accepts a number you have not validated, and that is precisely what session nine told you never to do with a consumption figure, whichever axis it sits on. C does genuinely happen, and reading the types too broadly is a smaller effect than double counting a chain, so check the chain first. And D is worth ruling out in about thirty seconds and it is rarely the answer, because most reports of this kind are already annual. Check it anyway, because thirty seconds is cheap.
Three ways to get a number. Your own query: a count you built, from your own system, with a method you control. Use it first, always, because nothing else gives you a position you can defend. SAP's estimation service: SAP's reading of your volume, produced by their tooling, and genuinely useful. Use it after you have your own number, so that you are comparing rather than reacting. And a third party assessment: an independent count, usually with the exclusions applied carefully, which is worth the fee when the two numbers disagree materially and the sum at stake justifies it. The order is the entire point of this slide. Run the estimation service before you have your own figure and you have handed over the framing, in exactly the way session ten warned about. Let's play a clip on why the sequence matters so much.
Guest analyst clip. There is an order of operations here that matters more than anything technical, and it is the same principle from the baseline session wearing different clothes. Produce your own number first. SAP offers an estimation service. It is genuinely useful, the tooling is decent, and I am not suggesting you avoid it. But think carefully about the sequence. If you run their estimate first, whatever it produces becomes the number in the room. Every conversation after that is you explaining why their figure is too high. You are checking their arithmetic, questioning their exclusions, asking whether test systems were included. And even when you are completely right, you are the party arguing against an established position. Now reverse it. You produce your own count first, with your own documented method and your own exclusions applied. Then you run theirs. Now you have two numbers and a comparison, and if they differ you have a specific technical conversation about why, on equal footing, from a position you can defend line by line. Same tooling, same underlying data, possibly the same eventual figure. Completely different conversation, because of one decision about what order to do things in. And that decision costs you nothing except the discipline to do your own work first.
It costs you nothing except the discipline to do your own work first. That is the third time this course has landed on the same idea, and I am not going to apologise for the repetition, because it keeps being the highest value habit available. Session five said it about the measurement. Session ten said it about the baseline. It says it here about the document count. Whoever produces the number first defines what the conversation is about, and producing it first is almost always within your control.
So how does the price behave? Four things, and I am not going to put rates on a slide, because yours are yours and they are confidential. What you can know in advance is the shape. It is tiered: the unit price falls as annual volume rises, which means small blocks are the most expensive possible way to buy documents. It is a run rate: you license an annual volume, so the question is never today's count, it is the count three years from now. Growth is the risk: document volume follows business volume, so a good year moves you up the curve without anybody deciding anything, which is exactly the engine axis problem from session nine. And adoption terms exist: moving from the named user reading into this model has its own commercial programme, with conversion credits in play, and session fourteen covers that properly. Put the tiering and the annual run rate together and one conclusion follows: buying once with headroom usually beats buying three times reactively.
Five ways a document estimate goes wrong. Counting the whole chain: the single biggest error, inflating the number by a factor of two or three before anybody notices, and we have covered it twice for that reason. Including licensed user activity: documents your own named users create in SAP are already covered, and sweeping them into the count can double the figure on its own. Test systems in the count: non production volume in a production number, so always check which systems the query actually ran against. A snapshot month annualised: multiplying a busy month by twelve, which seasonality makes wrong in both directions and which is never defensible when somebody asks how you got there. And no growth assumption: sizing to today's volume, then crossing a tier boundary in year two and buying again at a worse price. Notice that the first four make the number too high and the last one makes it too low. Both directions cost you.
Last knowledge check. Your verified count is one hundred and eighty thousand documents and growing twelve percent a year. What volume do you negotiate for? A, a hundred and eighty thousand: buy what you use and revisit when you exceed it. B, enough to cover the growth across the term, bought at the better tier. C, as much as the budget allows, since the unit price falls with volume. D, wait until you exceed it, then negotiate with the real number. Pause here, and think about what tiered and annual together imply.
B. Twelve percent compounded over three years is about two hundred and fifty three thousand, so buying a hundred and eighty thousand guarantees a second purchase, made reactively, at a worse tier, outside any negotiation. A is exactly that mistake stated as prudence, which is how it usually arrives. C is the opposite error and it produces shelfware, which session ten taught you to treat as real money rather than as safety. And D hands the timing to your growth curve rather than to your calendar, which removes the single advantage a forecastable metric gives you. If you can see the date, you should be choosing the date. Let's hear that argument made properly.
Guest analyst clip. Two features of this model interact in a way that catches people, and understanding the interaction is worth real money. The first feature is that it is tiered. The more annual volume you license, the lower the unit price. The second is that it is a run rate: you are licensing an annual quantity, not a one off purchase. Now put those together with the fact that document volume grows with your business. If you size to today's count, you have bought at a worse unit price than you needed to, and you have guaranteed that you will be back within about two years, buying again, reactively, in a small block, at the worst rate on the curve, outside any negotiation. That is the expensive path and it feels like prudence the day you choose it. The alternative is to model your growth across the term, buy the volume you will actually need by the end of it, and get the better tier for the whole period. Yes, you are buying ahead of consumption. But you are buying at a lower unit price, once, inside a negotiation where you have other things to trade. I am not telling you to buy as much as possible, because unused entitlement is real money too. I am telling you to buy the curve rather than the snapshot.
Buy the curve rather than the snapshot. And to do that you need the number to stay honest, so five things. Own the query: one documented method, rerunnable, with the exclusions applied, and it goes into the entitlement baseline like any other consumption figure. Refresh quarterly, on the same cadence as the engine register, because document volume moves with the business and a yearly look is too slow to be useful. Track the tier boundary, not just the count: how far you are from the next threshold and when you reach it at current growth. Review new integrations, because every new interface adds documents, and the architecture question from last session feeds directly into this number. And keep the exclusions written down: which systems, which document types, which populations, and why. That note is what makes the figure defensible next year, when somebody else is looking at it.
Three sentences. Nine document types, counted once at creation on the initial document, which is the rule that keeps one order from becoming three charges. The exclusions are large and easy to miss, so the first honest estimate is usually well below the first frightening one. And the model is tiered and annual, which means you are buying a run rate three years out rather than today's count, and that makes it a planning decision rather than a licensing one. Next session we work a real estimate end to end: taking a document count from raw query to a figure with evidence attached, which is the practical companion to everything we have just covered in principle.
Homework before session thirteen, about an hour. One, find the nine in your paper: the document types as your own agreement lists them. Compare that list to slide four and note any differences, because yours is the one that binds. Two, count one type. Pick sales documents. One year, production systems only, initial documents only. That single number teaches you the method better than reading about it. Three, subtract the licensed users: how many of those were created by your own named users through SAP? That portion is already covered and it comes straight off the total. Four, check the systems your query ran against, and if test or development is in there, run it again. And five, project three years using your business growth rate. That figure, rather than today's, is what any negotiation would actually be about.
Five guides, all on redresscompliance dot com. The complete guide to SAP Digital Access covers the document model end to end, including the current list behind slide four, which is the one to check your own paper against. The indirect access and Digital Access licensing piece sets this model against the named user reading from last session, so the two sessions have a written companion. The Digital Access cost calculator works the arithmetic on your own volume, including the tier behaviour from slide twelve. The guide to the Digital Access Adoption Program covers the commercial route from the older model into this one, and the traps in it, which is session fourteen's subject. And the Digital Access audit defence guide is what to do when the count you are shown is not the count you produced, which is a specific and quite common situation.
That is session twelve. You can now calculate this model yourself, which is the thing that turns indirect access from a topic people avoid into a line in a plan. Next time we work an estimate end to end, from raw query to a defensible figure. See you then.