What Creates Indirect Access Obligations
SAP's licence agreements require that any individual who accesses SAP functionality — whether through SAP's own user interface or through a third-party system that connects to SAP — must hold an appropriate named user licence. This principle underpins indirect access: when a third-party system "acts on behalf" of a user or population of users to interact with SAP data, the historical position was that each of those users required a licence.
The scenarios that most commonly create indirect access obligations are:
Customer and partner portals. An e-commerce platform, customer self-service portal, or supplier portal that creates SAP orders, reads inventory data, or updates customer records in SAP. The customers or partners using the portal are not SAP named users — but their actions trigger SAP transactions. Under the historical indirect access model, this created potentially unlimited licence exposure proportional to the portal user population.
Integration middleware and API connections. Middleware platforms (MuleSoft, Dell Boomi, SAP Integration Suite) that connect SAP with other enterprise systems — CRM, HR, finance — create bidirectional data flows that trigger SAP transactions. The users of the connected systems may not have SAP access, but the system-to-system integration creates indirect access.
Robotic Process Automation (RPA). RPA bots that automate SAP transactions — purchase order creation, invoice processing, master data updates — interact with SAP programmatically. SAP has taken the position that RPA bots accessing SAP require appropriate named user licences (typically Professional User) for each bot, regardless of whether a human is directly involved in the transaction.
IoT and operational technology. Manufacturing systems, supply chain sensors, and operational technology platforms that write production data, goods movements, or quality records to SAP create indirect access obligations that many enterprises have not quantified.
Business intelligence and reporting tools. Third-party analytics and reporting platforms (Tableau, Power BI, Qlik) that query SAP data directly through ODBC, JDBC, or RFC connections can create indirect access obligations depending on whether the query interface triggers SAP transactions or reads data from a replicated layer.
The most dangerous indirect access scenarios are those that enterprises built before 2018 — when the commercial implications were less clearly understood — and have never formally addressed. If your SAP estate was built before Digital Access existed, you almost certainly have undocumented indirect access exposure that requires structured assessment.
The Diageo Case and Why It Still Matters
In 2017, the UK High Court ruled in SAP's favour in an action against Diageo, finding that Diageo's third-party applications that accessed SAP data created indirect access licence obligations. Diageo subsequently settled with SAP for £54.3M. The broader settlement that followed affected thousands of SAP customers globally and prompted SAP to introduce the Digital Access licensing model.
The Diageo case matters in 2026 for three reasons. First, it established legal precedent confirming that SAP's indirect access position is contractually enforceable. Second, it triggered SAP to formally develop the Digital Access model — which means the commercial framework now exists, and SAP will use it as the basis for audit findings and conversion conversations. Third, many enterprises that were in discussions with SAP about indirect access in 2018–2020 signed conversion agreements that may not have adequately covered all their integration scenarios — and those gaps are now resurfacing in SAP licence reviews.
SAP Digital Access: The 2018 Framework
SAP introduced Digital Access in April 2018 as a document-based licensing model for indirect access scenarios. Rather than requiring named user licences for every person who indirectly accesses SAP, Digital Access licences the volume of specific business documents created in SAP through indirect channels — effectively shifting the measurement from "who accesses SAP" to "what documents does SAP create."
Digital Access applies to a defined list of document types. When a document of a covered type is created in SAP through an indirect channel (any channel other than the direct SAP user interface), a Digital Access licence obligation is triggered. The licence is priced per document — with volume discounts — and is typically structured as an annual fee based on the estimated annual document volume.
SAP positioned Digital Access as a commercial simplification of the indirect access problem. In practice, it shifted the complexity from counting users to counting documents and classifying integration flows — a different analytical challenge, but not necessarily a simpler one.
Digital Access Document Types and Prices
SAP's Digital Access model covers nine primary document types, each with its own pricing metric. The current covered document types are: Sales Order, Purchase Order, Service Order, Production Order, Plant Maintenance Order, Goods Movement, Financial Accounting Document, Billing Document, and Customer Contract.
Each document type is priced per "Digital Access Document" — a unit defined by SAP's LAW measurement tool. Pricing varies by document type and, significantly, by enterprise — SAP negotiates Digital Access pricing individually with large customers rather than publishing fixed list prices for all tiers.
The list price for Digital Access documents ranges from approximately €0.002 to €0.05 per document depending on type, with substantial volume discounts available for large enterprises. However, the list price baseline is SAP's opening position — not a fixed floor. Enterprises that engage expert advisory support in Digital Access conversions consistently achieve prices 30–60% below SAP's initial proposal.
Document Classification Disputes
A significant source of negotiation complexity in Digital Access conversions is document classification. SAP's measurement tools identify documents by type, but the technical interpretation of what constitutes a "Digital Access Document" for each type is not always straightforward. Disputes commonly arise around: whether a document creation triggered by a third-party system versus an internal SAP workflow constitutes a Digital Access event; whether document corrections and reversals count as separate documents; and whether documents created during system testing and development count against the production licence.
Independent analysis of document classifications — before accepting SAP's measurement output — is essential to an accurate and fair Digital Access conversion.
Assessing Your Indirect Access Exposure
The first step in managing indirect access risk is a structured assessment of your integration landscape. This assessment should cover:
- Integration inventory. Identify every third-party system with a technical connection to SAP — including middleware platforms, API integrations, database replication feeds, reporting tool connections, RPA deployments, and any legacy point-to-point integrations. Many organisations have 50–200 integration points; large enterprises frequently have 500+. The inventory needs to be comprehensive because a single large-volume integration can create very significant Digital Access exposure.
- Document flow analysis. For each integration, identify whether the integration creates, reads, or modifies SAP data, and whether the data interaction triggers the creation of Digital Access document types. Read-only integrations (reporting queries against a data warehouse layer, for example) typically do not create Digital Access obligations. Integrations that create or modify production-system business documents do.
- Volume measurement. For integrations that create Digital Access documents, measure the annual document volume by type. This measurement should use SAP's LAW tool in your production system — not estimates. SAP will use LAW during any formal review, so your measurement should be based on the same tool to avoid discrepancies.
- Contractual review. Review your existing SAP licence agreements for any indirect access provisions or Digital Access licences already in place. Many enterprises signed partial Digital Access conversions in 2018–2021 that covered some integrations but not others. Identifying the gaps in existing coverage is as important as identifying new exposure.
- Prioritise by exposure value. Once document volumes are quantified, prioritise integrations by estimated Digital Access cost — focusing remediation and negotiation attention on the highest-value exposure items first. The Pareto principle typically applies: 20% of integrations create 80% of the Digital Access exposure.
Negotiating a Digital Access Conversion
A Digital Access conversion negotiation is one of the most technically complex commercial exercises in the SAP relationship. It requires simultaneous expertise in SAP's licence agreement terms, the technical operation of SAP's LAW tool, the commercial structure of Digital Access pricing, and SAP's account team negotiation tactics.
The key negotiation principles that consistently produce better outcomes:
Do not accept SAP's initial document count. SAP's measurement of your Digital Access exposure is a starting point, not a definitive finding. Independent analysis of the measurement methodology, document classification rules, and system scope frequently identifies material reductions in the counted document volume. Reductions of 20–40% against SAP's initial count are common in our engagements.
Negotiate the per-document price aggressively. Digital Access document pricing is highly negotiable, particularly for large enterprises with high document volumes. SAP's account teams have significant pricing authority for large Digital Access conversions, and the per-document price is typically the highest-value lever in the negotiation. Volume commitment in exchange for pricing is a legitimate and often effective strategy.
Structure the conversion to include future-proofing. Your integration landscape will change. New third-party systems will be integrated; existing integrations will be modified; new digital transformation programmes will create new document flows. Negotiate Digital Access agreements that include provisions for volume bands (so that modest volume increases do not trigger additional licence fees), clear rules for what constitutes a "new integration" requiring additional licensing, and defined processes for adding new document types or integrations without a new commercial negotiation.
Use the conversion as leverage in the broader SAP relationship. A Digital Access conversion is a large commercial transaction. Use the opportunity to bundle other commercial objectives — support rate reduction, S/4HANA conversion credit improvements, product scope additions — into the same commercial discussion. SAP's account team will be motivated to close the Digital Access deal; that motivation creates leverage for the broader relationship.
RPA, AI and Emerging Indirect Access Risks
The indirect access landscape is evolving rapidly as enterprises adopt new automation and AI technologies. Several emerging scenarios are creating new commercial risk that the 2018 Digital Access model does not fully address.
AI agents and LLM integrations. AI platforms that retrieve data from SAP or trigger SAP transactions through natural language interfaces or agent-based automation create indirect access scenarios that SAP's current licensing framework does not clearly classify. As AI integration with ERP systems matures, SAP's commercial position on AI-mediated SAP access is evolving — and enterprises that build significant AI-SAP integrations without addressing the licensing implications may find themselves in future exposure situations analogous to the pre-2018 indirect access landscape.
RPA at scale. As RPA deployments have scaled from single-process automations to enterprise-wide digital workers, the bot population interacting with SAP has grown significantly. SAP's current position — that each RPA bot interacting with SAP requires a Professional User licence — can create very significant licence costs for large RPA programmes. This is an active area of commercial dispute, and several enterprises are challenging SAP's RPA licensing position in the context of Digital Access conversion discussions.
For related guidance, see: SAP Licensing Complete Guide, SAP Audit Defence, Digital Access Model Explained, and our white paper: Vendor Audit Defence Handbook.