SAP Practice — White Paper

SAP Indirect Access & Digital Access Licensing: Eliminating the Hidden Liability Before It Finds You

Indirect access is SAP's most profitable audit finding and least understood licensing concept. This paper maps the complete liability landscape, provides a risk assessment methodology, and delivers a negotiation framework for quantifying, capping, and resolving exposure before SAP raises it.

$3.4B+
SAP Spend Under Advisory
85+
Indirect Access Reviews
60–90%
Typical Claim Reduction
9
Exposure Categories Mapped

Executive Summary

Every enterprise running SAP carries indirect access liability. It is not a question of if, but of magnitude. Every third-party application, RPA bot, integration middleware, custom portal, or API that reads from or writes to SAP creates a licensing obligation — regardless of whether the end user ever logs into SAP or even knows SAP exists. This liability is cumulative, retroactive, and in most cases completely unmeasured until SAP's audit team identifies it for you — on their terms, at their valuation.

This white paper is drawn from Redress Compliance's experience across more than 85 indirect access and digital access engagements, representing over $3.4 billion in cumulative SAP spend. It provides a comprehensive analysis of the indirect access liability landscape, the Digital Access model SAP introduced as a purported simplification, the specific risk categories your organisation likely carries, and a proven negotiation framework for quantifying, capping, and resolving indirect access exposure in commercial agreements before SAP raises it in an audit.

1
92% of SAP customers have unquantified indirect access exposure. In Redress engagements, only 8% of organisations had conducted any form of indirect access assessment prior to an audit notification. The remaining 92% had no visibility into the scope, magnitude, or financial exposure of their indirect access landscape.
2
SAP's initial audit claims average 3–8× the commercially reasonable resolution. SAP's audit methodology calculates indirect access liability at list price using the most expensive applicable Named User licence type. In every Redress engagement, the initial SAP audit claim was reduced by 60–90% through structured negotiation — indicating that SAP's opening position is a commercial anchor, not a compliance finding.
3
Digital Access (document-based licensing) solved one problem and created another. SAP's 2018 introduction of Digital Access pricing — charging per document created by non-SAP systems — eliminated some Named User exposure but introduced a new metering complexity. Organisations on S/4HANA without a Digital Access agreement are exposed under both the legacy Named User model and the new document model simultaneously.
4
RPA and integration middleware are the fastest-growing exposure categories. Robotic Process Automation deployments (UiPath, Automation Anywhere, Blue Prism, Microsoft Power Automate) that interact with SAP create licensing obligations for every bot and every process. A single RPA bot that creates purchase orders in SAP can generate more indirect access liability than 500 Named Users.
5
Proactive resolution costs a fraction of reactive audit response. Organisations that quantify and resolve indirect access exposure proactively — before an SAP audit — achieve outcomes that are 40–65% more favourable than those that negotiate under audit pressure. The audit creates leverage for SAP, not for you.

How SAP Indirect Access Works

SAP's licensing model is fundamentally user-based. Every individual who "uses or benefits from" the SAP system requires a Named User licence. This principle is uncontroversial when applied to employees logging into SAP GUI or Fiori. It becomes deeply problematic when SAP extends it to individuals who interact with SAP data through intermediary systems — systems that SAP did not build, does not operate, and often did not know existed until an audit.

The Contractual Basis

Indirect access liability originates in SAP's standard licence agreement, specifically the definition of "Use" and "Named User." SAP defines Use broadly: any act of accessing, connecting to, or deriving benefit from the SAP system, whether directly or indirectly, through any means. A Named User is any individual authorised by the customer to Use the system in any manner. The critical expansion is the phrase "in any manner" — which SAP interprets to include any human who triggers a read or write operation in SAP, regardless of how many intermediate systems sit between that human and the SAP database.

Consider a customer service representative using a CRM system (Salesforce, for example) that retrieves pricing data from SAP in real time via an API integration. That representative never sees SAP, doesn't know SAP exists, and has no SAP credentials. Under SAP's interpretation, that representative is an SAP Named User requiring a licence — typically a Professional User licence priced at approximately $3,700–$4,600 per year. If your Salesforce deployment has 5,000 CRM users who access SAP-sourced data, SAP's position is that you owe 5,000 SAP Professional User licences. At list price, that is $18.5–$23 million in licence fees alone.

The Multiplier Problem

Indirect access exposure is multiplicative, not additive. Each integration point creates a separate exposure vector, and the populations overlap. Your Salesforce CRM users may also be your ServiceNow ITSM users, who may also use a custom web portal that reads SAP master data. Under SAP's audit methodology, each interaction channel is counted independently unless the customer can demonstrate — with auditable evidence — that the same named individual is already licensed for the highest-tier access across all channels.

This multiplier effect is how indirect access claims reach tens or hundreds of millions of dollars. It is also why SAP's initial audit claims are commercially unreasonable by design: they are calculated to maximise leverage, creating an anchor against which any subsequent negotiated resolution feels like a concession — even if the final figure still represents a significant overpayment.

Static Read Access

Systems that only read SAP data (e.g., reporting, BI, data warehousing) create exposure but are typically licensable at lower-tier rates. SAP's audit teams frequently reclassify static reads as dynamic access during the audit process.

Dynamic Write Access

Any system that creates, modifies, or deletes SAP data (orders, invoices, master data) triggers the highest licence tier. This includes RPA bots, EDI interfaces, e-commerce platforms, and integration middleware.

Transitive Access

System A reads from SAP. System B reads from System A. Under SAP's broadest interpretation, users of System B have indirect access to SAP — even though they are two systems removed from the SAP database.

Machine-to-Machine Access

Automated interfaces with no human in the loop (batch processing, scheduled data extracts, IoT sensor feeds) create licensing questions that SAP's Named User model was not designed to address — but SAP asserts licensing claims regardless.

SAP Digital Access: The New Exposure Model

In 2018, following the landmark Diageo and AB InBev disputes, SAP introduced a new licensing construct: Digital Access. Marketed as a "simplification" that would bring clarity to indirect access licensing, Digital Access introduced a document-based pricing model where customers pay per document created in SAP by non-SAP systems, rather than per Named User who triggers the document creation.

The theory was sound: instead of counting the unknowable population of humans behind a Salesforce integration, SAP would count the measurable volume of sales orders, purchase orders, invoices, and other documents created through that integration. In practice, Digital Access created a new set of complexities that many organisations found equally opaque.

The Nine Document Types

SAP's Digital Access model defines nine document categories, each with a separate per-document price. Understanding which of your integration-created documents fall into which category — and which are counted at all — is the foundation of any Digital Access assessment.

Document Type Examples Typical Price Range
Order-to-Cash Sales orders, delivery notes, customer returns $0.09–$0.30 per document
Procure-to-Pay Purchase orders, goods receipts, service entries $0.07–$0.25 per document
Plan-to-Produce Production orders, process orders, planned orders $0.05–$0.20 per document
Request-to-Service Service orders, service confirmations, notifications $0.05–$0.15 per document
Finance Financial postings, journal entries, payment documents $0.03–$0.10 per document
Inventory / Warehouse Material movements, transfer orders, physical inventory $0.03–$0.08 per document
Sourcing & Procurement RFQs, contracts, scheduling agreements $0.06–$0.18 per document
HR / Payroll Payroll results, time recordings, travel requests $0.03–$0.12 per document
Generic / Other IDocs, custom document types, master data changes $0.02–$0.10 per document

The Dual-Exposure Problem

For organisations migrating to or already on S/4HANA, Digital Access creates a dual-exposure risk. If you have not signed a Digital Access adoption agreement, SAP's position is that your indirect access exposure is calculated under the legacy Named User model — which is typically more expensive. If you adopt Digital Access without a comprehensive volume assessment, you risk committing to per-document pricing that may exceed your Named User liability for high-volume integration scenarios.

The optimal approach is to calculate your exposure under both models before committing to either, and to negotiate a transitional arrangement that caps your total liability while you complete the migration assessment. This is a negotiation SAP will resist but one that Redress has successfully concluded in the majority of our Digital Access adoption engagements.

"Digital Access was positioned as simplification. In practice, it added a second measurement axis to an already complex licensing model — and most customers adopted it without modelling the financial impact of both approaches."

— Redress Compliance, SAP Practice Lead

The Complete Indirect Access Liability Landscape

Through our work across 85+ indirect access engagements, Redress has mapped nine distinct categories of indirect access exposure. Most organisations carry exposure in at least five of these categories simultaneously, creating a compounding liability that grows with every new integration, every new third-party application, and every new automation initiative.

1
CRM Integration

Salesforce, Microsoft Dynamics, HubSpot, or any CRM that reads pricing, availability, customer master data, or order status from SAP — or writes orders, quotes, or customer records back to SAP. This is the most common and typically the largest single exposure category. A global CRM deployment with 10,000 users accessing SAP data represents $37–$46 million in potential Named User liability at list price.

Exposure: Very High Typical Finding: $5M–$50M+
2
E-Commerce Platforms

Shopify, Magento, SAP Commerce Cloud, custom B2B portals, or any web-based ordering system that creates sales orders, checks inventory, or processes payments through SAP. Every customer who places an order through your website may constitute an SAP Named User under the legacy model. Under Digital Access, every order document is counted. High-volume e-commerce can generate millions of documents annually.

Exposure: Very High Typical Finding: $2M–$30M+
3
RPA & Automation

UiPath, Automation Anywhere, Blue Prism, Microsoft Power Automate, or any robotic process automation platform that interacts with SAP. Each bot that reads or writes SAP data creates a licensing obligation. A single RPA process that creates 10,000 purchase orders per month generates more document volume — and potentially more indirect access liability — than an entire department of human users. SAP's position on RPA is particularly aggressive because bots create auditable transaction logs that prove the access occurred.

Exposure: High & Growing Typical Finding: $1M–$15M+
4
Integration Middleware

MuleSoft, Dell Boomi, Microsoft Azure Integration Services, Informatica, Talend, or any iPaaS/ESB/ETL tool that connects SAP to other systems. The middleware itself doesn't create the liability — the systems and users on the other end do. But middleware makes the access possible, creates auditable logs, and is the first thing SAP's audit team examines to map your integration landscape.

Exposure: Medium-High
5
EDI & B2B Interfaces

Electronic Data Interchange with suppliers, logistics providers, and trading partners. Every trading partner that sends purchase orders, invoices, or advanced shipping notices into SAP via EDI creates document-based exposure under Digital Access. Organisations with 500+ EDI trading partners often carry significant unquantified liability in this category.

Exposure: Medium
6
Custom Portals & Mobile Apps

Employee self-service portals, supplier portals, customer-facing applications, mobile apps — any custom-built interface that accesses SAP data. These are particularly dangerous because they are built by your organisation (not a commercial vendor), often without licensing consultation, and can expose populations of thousands of external users to SAP licensing obligations.

Exposure: High
7
BI, Analytics & Data Warehousing

Power BI, Tableau, Qlik, Snowflake, or any analytics platform that reads data extracted from SAP. SAP's position on read-only analytical access has evolved: they increasingly assert that users consuming SAP-sourced data in non-SAP analytics tools require SAP licences, even when the data has been replicated to a non-SAP data warehouse.

Exposure: Medium
8
IoT & Machine Interfaces

Manufacturing sensors, connected devices, telematics systems, and IoT platforms that feed data into SAP for processing, quality management, or predictive maintenance. SAP's Named User model has no sensible way to account for machine-generated access, but SAP's audit teams have asserted claims based on the humans who "benefit from" the IoT data once it's processed in SAP.

Exposure: Emerging
9
AI & Generative AI Integrations

AI platforms (OpenAI, Azure OpenAI, SAP Business AI) that read SAP data for analysis, generate content based on SAP data, or write AI-generated recommendations back to SAP. This is the newest and least defined exposure category. SAP has not published clear guidance on how AI-mediated access is licensed, creating a regulatory vacuum that will be filled by audit findings.

Exposure: Undefined & Growing

Risk Assessment Methodology

Quantifying indirect access exposure before SAP does is the single most important defensive action an SAP customer can take. The following methodology, refined across 85+ Redress engagements, provides a structured approach to identifying, measuring, and prioritising indirect access risk across your environment.

Step 1 — Integration Inventory

Map Every SAP Touchpoint

Conduct a comprehensive inventory of every system, interface, API, batch process, and manual data exchange that reads from or writes to your SAP environment. This includes RFC connections, BAPIs, IDocs, OData services, JDBC/ODBC connections, flat file interfaces, and any middleware connectors. The inventory must cover production, development, QA, and sandbox environments — SAP's audit scope typically includes all landscapes.

Key output: A complete integration map showing every external system connected to SAP, the data flow direction (read, write, or bidirectional), the SAP transaction codes or tables accessed, and the frequency and volume of data exchange.

Step 2 — User Population Analysis

Identify Who Touches SAP Data Through Each Channel

For each integration identified in Step 1, determine the human population that interacts with SAP data through that channel. This requires collaboration between IT, business units, and the system owners. For CRM integrations, identify every CRM user who can view or modify SAP-sourced data. For e-commerce, quantify the customer population. For RPA, document every bot and the business process it executes.

Critical distinction: Identify overlaps. A user who appears in both the CRM population and the portal population should be counted once at the highest-tier licence level, not twice. Building the overlap matrix is essential for reducing SAP's ability to multiply your exposure across channels.

Step 3 — Document Volume Quantification

Count the Documents That Digital Access Would Meter

Extract transaction data from SAP to quantify the document volume created by non-SAP systems across each of the nine Digital Access document categories. This requires analysis of SAP transaction tables (VBAK for sales orders, EKKO for purchase orders, BKPF for financial documents, etc.) filtered by creation source — identifying documents created by batch interfaces, RFC calls, or API integrations versus those created by direct SAP users.

Key output: An annualised document count by category and by source system, providing the baseline for a Digital Access cost model that can be compared against Named User exposure.

Step 4 — Dual-Model Financial Exposure Calculation

Calculate Liability Under Both Licensing Models

Using the user population data and document volume data, calculate your total indirect access exposure under both the legacy Named User model and the Digital Access model. For Named Users, apply the appropriate licence tier (Professional, Limited Professional, Employee) based on the access type. For Digital Access, apply the per-document pricing from SAP's published rate cards or your negotiated rates.

Key output: A side-by-side financial exposure comparison that quantifies your liability under each model and identifies the break-even point. This analysis is the foundation of your negotiation position — you negotiate from the model that gives you the lower total cost.

Risk Assessment — Critical Data Points
Total number of RFC/API connections to SAP (production + non-production)
Complete inventory of IDocs processed annually by type and direction
CRM user count with SAP data access (even read-only)
E-commerce order volume flowing into SAP annually
RPA bot inventory with SAP transaction map per bot
EDI trading partner count and document volume
Custom portal/mobile app user population with SAP data access
BI/analytics user count consuming SAP-sourced data
Document creation volume by SAP transaction type and source system
Current SAP Named User licence inventory (type and count)

SAP Audit Mechanics & What Triggers Them

SAP's audit programme — formally called the "Licence Audit" or "Software Asset Management Review" — is a commercial function operated by SAP's Global Licence Audit & Compliance (GLAC) team. Understanding how audits are triggered, how they proceed, and what SAP's team is specifically looking for is essential to managing your exposure.

What Triggers an Audit

SAP reserves the contractual right to audit any customer annually, but resource constraints mean they target selectively. The following triggers increase your audit probability significantly:

Renewal or Renegotiation Activity

The single most common audit trigger. When you approach SAP for a renewal, contract restructuring, or renegotiation, SAP's account team routinely requests a GLAC engagement to "baseline your current position" — which is functionally an audit initiated at your request. Approximately 60% of SAP audits are triggered by the customer's own commercial activity.

Defence: Never agree to an audit or "self-assessment" as a precondition for commercial discussions. Conduct your own assessment privately before engaging SAP.
S/4HANA Migration Conversations

SAP views S/4HANA migration as both a commercial opportunity and a compliance event. Any discussion about migrating to S/4HANA triggers internal flagging that can result in a "deployment review" that functions as an indirect access audit. SAP's stated position is that S/4HANA migration requires Digital Access adoption — creating a commercial lever tied to a technical migration.

Defence: Separate your technical migration planning from your commercial negotiation. Do not allow SAP to bundle licence compliance resolution with migration pricing.
USMM / LAW Data Anomalies

SAP customers are contractually required to submit annual licence measurement data via the SAP User and System Measurement (USMM) or Licence Administration Workbench (LAW). Anomalies in this data — sudden increases in user counts, large IDoc volumes, spikes in RFC connections — trigger automated flagging at GLAC. Submitting accurate USMM data is important, but submitting data that reveals integration activity without context gives SAP's audit team a roadmap to your exposure.

Defence: Review your USMM/LAW submission with licensing counsel before transmitting. Understand what the data reveals and prepare your position before SAP asks questions.
Third-Party Intelligence

SAP's audit team monitors public information — job postings for "SAP integration developer," press releases about digital transformation initiatives, technology partner announcements, and conference presentations — to identify customers with likely indirect access exposure. A press release announcing a new e-commerce platform integrated with SAP can trigger an audit inquiry within weeks.

Defence: Be aware that public communications about your SAP landscape reach SAP's audit team. This doesn't mean you should hide your technology initiatives — it means you should resolve your licensing position before announcing them.

The Audit Process

A formal SAP audit typically proceeds through four stages: notification (SAP asserts its contractual audit right), data collection (SAP requests USMM data, system extracts, and integration documentation), analysis (SAP's GLAC team calculates your exposure using their methodology), and findings presentation (SAP presents a compliance gap with a financial claim). The entire process typically takes 3–6 months, during which your negotiating leverage decreases progressively as SAP builds their case. This is why proactive assessment — before SAP's process begins — is critical.

Negotiation Framework: Quantifying, Capping, and Resolving Exposure

Whether you are proactively resolving indirect access exposure or responding to an SAP audit claim, the negotiation follows a predictable structure. SAP's audit team operates with defined commercial targets and settlement authority tiers — understanding these allows you to set realistic objectives and negotiate effectively.

Principle 1: Never Negotiate from SAP's Numbers

SAP's initial audit claim is calculated to maximise leverage, not to reflect commercially reasonable liability. It uses list pricing, applies the most expensive licence tier to every user, counts populations without overlap deductions, and includes no volume discounting. Your response must be anchored in your own independently calculated exposure — using the methodology described in Section 05 — not in a discount percentage against SAP's inflated starting position.

Principle 2: Separate Backward and Forward Liability

Indirect access claims have two components: backward-looking liability (the historical unlicensed access that has already occurred) and forward-looking coverage (the ongoing licence requirement for continued integration access). These must be negotiated separately. SAP prefers to bundle them because the backward liability creates urgency that drives acceptance of unfavourable forward terms. Redress consistently separates these negotiations to achieve optimal outcomes on both.

Principle 3: Use the Dual-Model Comparison as Leverage

If your exposure is lower under the Digital Access model than the Named User model, negotiate adoption of Digital Access with a backward liability amnesty. If your exposure is lower under Named Users, resist Digital Access adoption and negotiate a Named User true-up at deeply discounted rates. The ability to model both approaches — and to demonstrate that modelling to SAP — is your primary leverage tool.

SAP's Position Your Counter-Position Typical Resolution Range
Every CRM user requires a Professional licence Only users with write access require licensing; read-only access at Limited Professional tier or excluded 60–80% reduction from initial claim
Historical liability at list price Backward liability settled as a one-time fee with volume discount and amnesty for pre-measurement periods 70–90% reduction from list calculation
Each integration channel counted separately Named User overlap deduction: individuals already licensed are not counted again per additional channel 30–50% population reduction
Digital Access at published rates Negotiated per-document rates with volume tiers, annual caps, and growth corridors 40–65% discount from published rates
RPA bots require per-bot licensing RPA covered under Digital Access document pricing, not per-bot Named User licensing Structural reclassification; 50–80% cost reduction

Settlement Authority Tiers

SAP's GLAC team operates with defined settlement authority. The initial audit analyst can settle at 30–40% of the initial claim. Their manager can authorise 50–60% reductions. Regional GLAC leadership can go to 70–80%. Global escalation — triggered by enterprise-wide strategic account value or credible legal challenge — has reached 85–95% reduction from initial claims in Redress engagements. Knowing which tier you're negotiating with determines whether further escalation will yield material improvement.

"In every indirect access engagement we've managed, the final settlement was between 60% and 90% below SAP's initial audit claim. The initial number is not a finding — it's an opening position. Treat it as such."

— Redress Compliance, SAP Practice Lead

Recommendations: 7 Priority Actions

Based on our experience across 85+ indirect access engagements, we recommend the following priority actions for every SAP customer.

Conduct a Proactive Indirect Access Assessment — Now
Do not wait for an SAP audit to discover your exposure. Commission an independent assessment that maps every integration, quantifies the user population and document volume for each channel, and calculates your exposure under both Named User and Digital Access models. The cost of a proactive assessment is a fraction of the cost of reacting to an audit claim.
Build Your Overlap Matrix Before SAP Builds Theirs
SAP's audit methodology counts populations per channel. Your defence requires a named-individual overlap analysis that demonstrates how many of those "indirect access users" are already licensed SAP Named Users through direct access. This single data point typically reduces SAP's claim by 30–50%.
Model Digital Access Economics Before Adopting
Do not adopt SAP's Digital Access model without first modelling the cost at your actual document volumes. For high-volume integration environments (e-commerce, EDI-heavy, RPA-intensive), Digital Access can be more expensive than the Named User model it replaces. The right model depends on your specific integration profile.
Implement Integration Licensing Governance
Establish a governance process that requires licensing impact assessment before any new integration with SAP is deployed. Every new CRM integration, RPA bot, e-commerce connector, or custom portal that touches SAP creates new exposure. Your IT architecture decisions are licensing decisions — treat them as such.
Never Agree to a "Self-Assessment" as a Precondition for Commercial Discussions
SAP's account teams routinely request a self-assessment or "deployment review" before discussing renewals, migrations, or renegotiations. This is functionally an audit that you are volunteering for. Conduct your own private assessment, but never hand SAP the data before you've developed your negotiation position.
Separate S/4HANA Migration from Compliance Resolution
SAP's preferred strategy is to bundle indirect access compliance resolution with S/4HANA migration commitments — "we'll waive your indirect access liability if you commit to S/4HANA." This creates a forced coupling where you accept an expensive, multi-year migration commitment to resolve a licensing dispute. Negotiate each issue independently on its commercial merits.
Negotiate Contractual Indirect Access Protections at Every Renewal
Your renewal is the one moment when SAP needs something from you. Use it to negotiate contractual provisions that cap indirect access liability, define acceptable integration patterns, establish Digital Access rates and volume tiers, and create a dispute resolution mechanism that doesn't involve SAP's audit team. These protections must be in the contract — not in side letters or verbal assurances.

How Redress Can Help

Redress Compliance is a 100% independent enterprise software advisory firm. We carry zero vendor affiliations, no reseller agreements, and no referral fees. Our recommendations are driven entirely by our clients' commercial interests.

Our SAP Practice has managed over 85 indirect access and digital access engagements representing more than $3.4 billion in cumulative SAP spend. We have reduced SAP indirect access audit claims by 60–90% in every engagement and have never had a client pay more than 40% of SAP's initial claim.

Indirect Access Assessment

Comprehensive mapping of your integration landscape, user population analysis, document volume quantification, and dual-model financial exposure calculation. Delivered as a confidential, attorney-client privileged report when conducted through legal counsel.

SAP Audit Defence

Full-scope representation in SAP licence audit proceedings. We manage the data collection response, challenge SAP's methodology, build your counter-position, and negotiate the settlement — from initial notification through final resolution.

Digital Access Adoption Advisory

Cost modelling, rate negotiation, and transitional arrangement structuring for organisations adopting SAP's Digital Access model. Includes document volume forecasting and backward liability amnesty negotiation.

S/4HANA Licensing Strategy

Licensing assessment for S/4HANA migration including indirect access resolution, Digital Access adoption, RISE with SAP evaluation, and total cost of ownership modelling for the target architecture.

Renewal & Renegotiation Support

End-to-end SAP commercial negotiation including indirect access cap negotiation, Digital Access rate structuring, contractual protection clauses, and total-value optimisation across your SAP portfolio.

Integration Licensing Governance

Design and implementation of an ongoing governance framework that assesses licensing impact before new SAP integrations are deployed — preventing future exposure from accumulating.

"We have reduced SAP indirect access audit claims by 60–90% across every engagement. The initial number is not a finding — it is an opening position. Our job is to ensure our clients never pay the opening position."

— Redress Compliance Client Impact Report, 2025

Book a Meeting

Ready to quantify and resolve your indirect access exposure? Schedule a confidential consultation with our SAP Practice. We'll assess your integration landscape, identify your highest-risk exposure categories, and outline a strategy for proactive resolution — before SAP's audit team finds it first.

Schedule a Consultation