SAP Indirect Access: Understanding and Managing Indirect Usage Risks

SAP Indirect Access – The Hidden Licensing Risk in SAP

Every SAP customer faces a hidden licensing threat called indirect access.

This occurs when users or third-party applications interact with SAP data or functions without directly logging into SAP.

In other words, if information flows into or out of SAP through another system (and triggers activity in SAP), that’s indirect usage. It often flies under the radar – and SAP can treat it as unlicensed use.

Typical sources of indirect access include:

• CRM systems (e.g. Salesforce): External sales or customer platforms reading or updating SAP data.
• E-commerce sites and portals: Online stores or supplier/customer portals that create SAP orders or pull SAP info in the background.
• IoT integrations and devices: Sensors or machines sending data to SAP (like automated inventory updates) without human users.
• Robotic Process Automation (RPA) bots: Scripts or bots performing SAP transactions via APIs instead of a person.
• Third-party reporting or HR tools: External applications querying SAP for data or feeding data into SAP.

This is controversial because customers see these as normal technical integrations, while SAP sees revenue opportunities. SAP’s stance is clear: if you derive value from SAP’s software – even indirectly – you must have a license for it.

Indirect access isn’t a technical glitch; it’s embedded in SAP’s licensing model. Indirect Access isn’t a technical problem – it’s SAP’s business model for your integrations.

In practice, this means that if an external system or user benefits from SAP data, SAP may require you to pay for it.

Why Indirect Access Matters

Ignoring indirect usage can lead to serious financial and compliance risks. SAP has audited companies and claimed millions in back license fees for unlicensed indirect use.

Even if you thought you were compliant, an indirect access claim can come as a shock:

• Financial Risk: SAP can demand license fees (and back-maintenance) for each unlicensed indirect user or transaction. This can amount to multi-million dollar/euro penalties retroactively. A single audit could blow your IT budget due to years of unnoticed indirect usage.
• Compliance and Legal Risk: Using SAP beyond your contract terms (even unintentionally) is a breach of contract. In the worst cases, it leads to legal disputes or the need to quickly purchase licenses under duress. Your organization could violate licensing terms, giving SAP strong leverage.
• Reputational Risk: There have been high-profile public cases where companies were caught in indirect access disputes. For example, a large beverage company (Diageo) was found liable for ~£54 million in license fees after integrating Salesforce to SAP without proper licenses. These stories spread through the IT world, warning others of the consequences and causing public embarrassment for the companies involved.
• Strategic Risk: SAP’s sales teams often use indirect usage findings as a negotiation lever. If you’re out of compliance, SAP might push you towards their preferred solutions (like switching to SAP’s Digital Access licensing or migrating to RISE with SAP cloud deals) as part of the settlement. In effect, an indirect access issue can corner you into buying more from SAP on SAP’s terms.

Checklist: Signs You’re at Risk – ask yourself if any of these apply in your environment:

• Multiple external systems are integrated with SAP, exchanging data regularly.
• You see high API, interface, or IDoc activity connecting non-SAP apps to SAP.
• There’s no internal tracking or classification of external usage (you don’t monitor which external users or devices access SAP).
• Your SAP contract’s definition of “user” or “use” is unclear or very broad, or you’ve never reviewed it with indirect access in mind.
• External users (customers, partners) or devices interact with SAP data, but you haven’t assigned them SAP licenses.

If these sound familiar, you likely have indirect usage exposure that needs attention.

Notorious SAP Indirect Access Cases

Real-world examples show how indirect access can become a costly headache:

• Global Beverage Company (CRM Integration): A multinational drinks company integrated Salesforce CRM with SAP. Salespeople and customers accessed SAP data via Salesforce without logging into SAP. SAP classified this as indirect use and pursued license fees, resulting in a multi-million pound dispute (widely reported in the Diageo case).
• Manufacturing Firm (IoT Devices): A manufacturing company deployed IoT sensors and automated systems that fed data into SAP and created transactions (like stock updates and auto-generated purchase orders). Each device-triggered transaction was considered an indirect use. SAP auditors counted thousands of such IoT-triggered documents, leading to a hefty license compliance claim.
• Pharma Company (Analytics Tool): A pharmaceutical firm used a third-party analytics platform to pull data from SAP for reporting. Dozens of analysts accessed SAP-stored information via this tool without SAP user logins. SAP asserted that those analysts (and the technical user of the tool) required SAP named user licenses, forcing the company to true-up licenses to cover this “indirect” data readership.

Insight: SAP audits often start with “interface mapping” – if they see a connection between SAP and another system, they will investigate it.

In each case above, what seemed like innocent integration turned into a licensing liability. These examples underscore that any external touch-point with SAP is a potential license exposure.

How SAP Detects Indirect Usage

SAP’s auditors have become adept at uncovering indirect use. They don’t rely on luck – they follow a systematic approach:

• Interface Inventory: Auditors will ask for diagrams or lists of all systems interfacing with SAP. This “interface mapping” is a red flag exercise – any system connected to SAP is a candidate for indirect usage. For each interface, they’ll inquire how data flows and who the end-users are.
• Log and Account Analysis: During an audit, SAP examines technical logs (for example, SAP’s system logs, RFC traces, IDoc logs) for activity by generic or background user accounts. If they find an account like SALES_PORTAL_USER Creating thousands of orders, they know an external application is funneling transactions into SAP.
• Transaction Tracing: Auditors identify documents or transactions created in SAP without a named user directly attached. They trace these to source systems. For instance, a spike in order creations via an integration user signals a third-party app (like an online store) is driving those – a classic indirect access scenario.
• User Count Estimation: Once a particular interface is identified, SAP will estimate how many individual users or devices are behind it. For example, if an e-commerce site created 10,000 orders, SAP might argue that those represent 10,000 customers who should have been licensed. Or if a sensor gateway account posted 500,000 readings, they might equate that to X number of device “users.”
• Compliance Claim: SAP then presents a compliance report. This often includes back-charges for past unlicensed use (sometimes going back several years), plus the requirement to purchase appropriate licenses in the future. These claims can balloon quickly – it’s not uncommon for them to reach into seven or eight figures in currency.

Importantly, SAP’s standard license measurement tools (like USMM or LAW) focus on named user counts and engine metrics; they do not automatically flag indirect use. Indirect usage detection tends to be a manual, investigative process during audits. That means if you’re not actively looking for it yourself, it can go unnoticed until the auditors arrive.

Insight: “If your system connects, SAP wants to monetize it.” Always assume that SAP will scrutinize any connection to SAP (no matter how minor) for potential licensing opportunities.

Checklist: Internal Detection Steps – Don’t wait for SAP to find indirect use. Proactively check:

• Inventory all SAP interfaces: List every third-party application, middleware, or external system that exchanges data with SAP (inbound or outbound).
• Categorize each integration: Determine which connections are read-only (just pulling data) and which create/update data in SAP (e.g., creating documents like orders or invoices).
• Identify technical accounts: Find any system or communication user IDs in SAP that are used by external systems (RFC users, BAPI service accounts, etc.). Monitor their activity for volume and type of transactions.
• Link users/devices to interfaces: For each external interface, estimate how many end users or devices drive that connection. (For example, a supplier portal might have 300 suppliers using it; an IoT platform might have 1,000 sensors connected.)
• Cross-check license assignments: Verify whether any existing SAP licenses cover those external users/devices. In many cases, they won’t be – which highlights the exposure.

By doing the above, you can spot indirect usage hotspots internally and address them on your terms, rather than letting SAP discover them first.

SAP’s Evolving Stance on Indirect Access

SAP’s approach to indirect access has shifted in response to customer backlash and industry pressure. It’s useful to understand how we got to the current state:

Framing Insight: SAP didn’t eliminate indirect access — it rebranded it into Digital Access. In other words, SAP acknowledged the outcry but still wants to monetize integrations, just through a different mechanism.

Today, SAP is less likely to drop an unexpected $10 million bill solely from an audit without offering an “out.” Instead, they’ll strongly encourage adopting the Digital Access document licensing model or moving to a cloud subscription that considers this requirement.

This evolution means customers have options to manage indirect use more proactively – but you need to understand those options (and their trade-offs) to leverage them in your favor.

Detecting and Measuring Indirect Access Internally

To take control of indirect access risk, organizations should identify and measure indirect usage themselves – before SAP does.

Here’s how:

• Use SAP’s own tools and logs: Leverage transaction logs (e.g., SAP ST03N workload analysis, STAD statistics, or custom audit logs) to see what external activities are occurring. Look for high-volume document postings or data reads by interface users. Some companies deploy SAP Solution Manager or dedicated monitoring tools to consolidate interface monitoring.
• Focus on “non-dialog” users: In SAP, users that aren’t regular people (such as background users, RFC users, or communication users) often facilitate indirect access. Identify all such accounts. For each one, find out which external system is using it and what activities it performs. For example, an account used by middleware might be creating thousands of sales orders – a clear indirect usage metric.
• Count documents and transactions: Quantify how many business documents (orders, invoices, deliveries, etc.) are created in SAP via each external integration. This helps estimate the “digital access” volume if you were to license by documents. Also count significant read actions (like number of queries) if they are heavy; while read-only access is less of a focus in SAP’s document model, it could still require named user licenses under classic rules.
• Estimate indirect “users”: Though difficult, try to approximate the number of unique external users behind each interface. For instance, if an external portal has 1,000 logins, that’s 1,000 people indirectly using SAP. This can be useful for risk quantification (e.g., “if SAP charged us a named user license for each, what would it cost?”).
• Perform an internal audit drill: Treat this like a self-audit. Document all findings – which interfaces exist, what volume of use they drive, and whether they’re compliant under your current licenses. This internal assessment should reveal your worst-case exposure in an SAP audit scenario. It’s far better that you discover a risky area (say, an unlicensed interface generating revenue-impacting transactions) than having SAP discover it first.

Checklist: Internal Indirect Usage Audit Plan

• Map integrations and external systems: Create a diagram or list of all external touchpoints to SAP, including what data they exchange.
• Determine data flow impact: For each integration, note if it creates or changes SAP documents (e.g., does it create a Sales Order or just read info?). Creation/update actions typically carry license requirements.
• Identify access pathways: Clarify whether external access goes through a middleware (like an integration platform) or direct API calls to SAP. Middleware might consolidate connections (reducing risk if properly licensed), whereas scattered direct calls might be harder to control.
• Review contract language: Check your SAP contracts for how “use” and “users” are defined. Do you have any clauses covering external or indirect use? Mark any vague areas that could be disputed. (You’ll want to address these in negotiations – see next section.)

By measuring and understanding your indirect usage, you can approach SAP discussions from a position of knowledge.

You’ll be able to say “we know exactly how many orders our website creates in SAP per year” and “we’ve identified X number of partner users accessing our SAP data.” This data is crucial for choosing the right mitigation strategy, whether that’s licensing changes or technical adjustments.

Contractual Ambiguity and SAP’s Leverage

One major reason indirect access causes so much angst is the ambiguity in contract language. Older SAP contracts (especially those from the pre-2010s) often never explicitly mentioned indirect usage.

They simply defined a “Named User” and “Use” in very broad terms. SAP has capitalized on this grey area during audits:

• If your contract doesn’t explicitly exclude certain types of indirect use, SAP will interpret it in the broadest possible way to cover any access. This means even a third-party system pulling a single data point could be deemed “use of SAP” requiring a license.
• Many customers feel this is unfair, as these integrations were not uncommon or malicious. But SAP’s leverage comes from the contract wording – and most legacy contracts gave them plenty of wiggle room.
• Newer SAP contracts (or recent amendments) sometimes include clauses about indirect use or “External Access” definitions. However, these are often written to protect SAP (ensuring you can’t bypass licenses via external systems) rather than to clearly protect the customer. Unless negotiated, they may still be too broad (“any access via third-party software requires an appropriate license” doesn’t actually solve ambiguity – it enshrines SAP’s broad view).

The key is to identify and narrow these ambiguities before you’re in a compliance dispute. When renewing or negotiating with SAP:

Negotiation Tactic: Define “use” narrowly. Insist on contract language that limits SAP’s definition of usage to direct, human, interactive use of the software by named individuals, excluding passive data exchange or system-driven transactions unless those result in defined, chargeable outcomes. The narrower and more concrete the definition, the less room there is for SAP to claim indirect use fees later.

You may also negotiate clauses that explicitly allow certain integration scenarios.

For example, a clause might state that access by up to 1,000 external portal users is permitted under a specific license type, or that read-only access via third-party BI tools is not counted as “use.” The goal is to remove surprises.

Checklist for Contract Review:

• Locate definitions of “Use” and “User”: What exactly does your contract say? If “use” includes language like “accessing the software directly or indirectly,” flag it. You may need to refine this.
• Identify any exclusions or special terms: Sometimes contracts have addenda or notes about specific scenarios (e.g., a “Test” or “Evaluation” license that allowed some external access, or a clause for “Business Partners”). Make sure you know what is and isn’t covered explicitly.
• Assess indirect use coverage: If indirect access is mentioned, is it tied to specific conditions (like creating SAP documents)? Preferably, the contract should specify that only certain high-level interactions (e.g., creation of financial records or sales documents by an external system) count as licensable events. Avoid blanket statements that any data exchange is a licensable event.
• Plan for updates: If your contract is old and murky, plan to address this in the next negotiation. Come up with proposed language that clarifies these points (SAP may not accept all your suggestions, but not addressing them guarantees continued ambiguity in their favor).

Remember, SAP sales and audit teams will use any ambiguity to their advantage. Cleaning up the contract language can dramatically reduce your risk.

It’s much easier to defend “our contract says read-only access by third-party systems is permitted” than to argue after an audit that you “assumed it was okay” with no contractual support.

Mitigation Strategies for Indirect Access Risk

Managing indirect access risk requires a combination of technical controls and commercial/contractual strategies.

Below are several approaches to consider:

Technical Controls:

These aim to limit or monitor how external systems interact with SAP, reducing unauthorized or excessive usage.

• Gatekeep integrations: Restrict which external systems can connect to SAP and how. For example, funnel all third-party access through a controlled middleware or API gateway. This way, you have a single choke point to monitor, and you can enforce rules (like rate limits or usage logs) for all external calls.
• Read vs. write segregation: If possible, design integrations so that external systems either read data or write data exclusively through certain accounts. For purely read-only scenarios, you might use a reporting database or replicate SAP data to avoid hitting the core SAP system directly. For write scenarios, ensure that only specific, minimal accounts have permission to create documents, keeping the scope limited.
• Regular system audits: Use SAP’s measurement tools periodically (plus custom scripts if needed) to check indirect use. Run USMM/LAW for direct users and supplement it with internal analysis of interfaces. Set up alerts for unusual activity by interface users – for instance, if a normally quiet interface suddenly creates thousands of records, you’d investigate immediately.
• Disable unused integrations: An often overlooked risk is the presence of old interfaces that are still technically active. Switch off or remove access for any third-party connections that are no longer needed. Each open door to SAP is a potential compliance issue if someone starts using it again down the line.

Commercial and Contractual Controls: These strategies focus on your agreements with SAP and how you structure your licensing to account for indirect use.

• Amnesty/clarity clauses: When renewing contracts, negotiate an amnesty for past indirect use or a clear reset. Essentially, get SAP to agree not to pursue past indirect usage if you move forward with a mutually acceptable licensing model. At a minimum, clarify how any newly identified indirect use will be treated (e.g., “SAP and Customer agree to discuss in good faith” rather than immediate penalties).
• Indirect use caps or licenses: If completely avoiding indirect access fees isn’t possible, negotiate a cap or fixed allowance. For example, include a clause that up to X number of documents or X external users are covered by your current license fees. This way, if you inadvertently exceed something, you have some contractual wiggle room before extra costs kick in.
• License the integration user appropriately: In some cases, SAP offers specific license types for external access (like a “External Party User” or a “platform user” license). Purchasing a handful of these to cover key integration accounts might be more cost-effective than a post-audit true-up. It’s not as clean as the Digital Access model, but it can be a pragmatic patch for known interfaces.
• Selective Digital Access conversion: You don’t have to convert your entire SAP environment to document-based licensing. Consider hybrid approaches. For high-risk interfaces (like that e-commerce site generating tons of orders), it might be worth licensing by documents (Digital Access) to cover them. Meanwhile, keep traditional user licensing for internal users. SAP’s sales team can help craft a tailored approach – just be careful to only buy what you need.

Strategic Tip: Pay for control, not uncertainty — negotiate metrics, not surprises. In practice, this means you’d rather pay a predictable fee (e.g., for a known quantity of documents or a block of external user licenses) than live under vague terms that could lead to a nasty surprise audit bill.

It might feel like you’re “giving in” to SAP by paying something, but think of it as buying insurance against even bigger, unpredictable costs.

Digital Access as a Mitigation Option

SAP’s Digital Access licensing model is the company’s answer to the indirect access challenge – offering a structured way to license indirect use by counting documents instead of people. Introduced in 2018, it was meant to eliminate the need to license every possible indirect user. Here’s how it works and what to consider:

What is Digital Access?
Under Digital Access, certain SAP business documents (e.g., Sales Orders, Invoices, Purchase Orders, Material Documents, etc.) generated by indirect activity are counted and licensed. Instead of needing a named user license for each external user or device, you pay for the total number of documents created (or, in some cases, viewed) through indirect interactions. SAP defined 9 document types that cover common business transactions. Each document (say, a sales order created from an external storefront) consumes a license from your purchased quota.

Why consider it:
Digital Access can simplify compliance. For example, you no longer worry whether 100 or 10,000 customers are using your portal – you just track how many orders or invoices they generate in SAP. If you handle 50,000 external orders per year, you buy a license bundle for that volume. This model aligns cost to actual system usage and prevents absurd scenarios like needing 10,000 named users for 10,000 one-time customers.

It also brings transparency. Document counts can be measured (SAP provides tools to estimate document counts). It’s more straightforward to audit “we created 50k sales orders” than to figure out “who are all the people behind these integrations.”

However, Digital Access is not a silver bullet. Consider the following:

• Cost implications: You must analyze your document volumes carefully. If your integrations create huge volumes of documents, the cost of Digital Access could exceed traditional licensing. For instance, a company with millions of transactions might find that the per-document cost leads to a higher bill than licensing a set of users. Digital Access is like compliance insurance — but at SAP’s premium.
• Counting complexities: You need to accurately count only the relevant documents. Miscounting can happen – for example, an external event might trigger multiple SAP updates (a sales order that then triggers a delivery and an invoice). Generally, SAP’s model might only charge for the primary document (sales order), but if you don’t set your counting rules correctly, you might over-count and overpay. Using SAP’s Digital Access Evaluation Tool (DAET) or similar programs is crucial to get a reliable baseline.
• Negotiation is still key: Digital Access pricing can be negotiated. SAP sells document licenses often in bundles (e.g., per 1,000 documents with volume discounts at higher tiers). You should negotiate the rate per document and, if possible, what constitutes a chargeable document. Also, if you’ve already invested heavily in named user licenses, ask for credit – for example, trade some of your existing licenses’ value towards the cost of Digital Access. Early adoption programs (like SAP’s now-ended Digital Access Adoption Program) often allowed such exchanges.
• Volume caps and flexibility: Try to incorporate volume caps or grace into your Digital Access agreement. You don’t want an unexpected surge in transactions to skyrocket your costs. For instance, negotiate that if you exceed your purchased volume, you can true-up at the same rate (instead of a penalty rate), or that SAP will alert you at a threshold. Some customers secure a clause to allow a certain overage percentage before requiring more purchases.
• Partial adoption strategy: You might choose to license certain document types via Digital Access and keep others under named user licenses. For example, cover high-volume customer orders with Digital Access, but leave low-volume internal documents under existing licenses. SAP can accommodate mixed models, but make sure it’s clearly defined to avoid double-counting or gaps.

Before committing to Digital Access, do your homework:

Checklist for Transitioning to Digital Access:

• Measure current document usage: Run SAP’s Digital Access estimation tools (or scripts via SAP notes) to see how many of each document type you generate indirectly in a year. Include all systems – e.g., orders from web shops, invoices from partner systems, IDoc entries from interfaces, etc.
• Validate and adjust counts: Scrub the data to ensure it’s accurate. Remove purely internal transactions from the count and ensure you’re not counting one business process multiple times. (This is where that DAET tool and perhaps consultant help come in handy.)
• Get credit for existing licenses: Don’t pay twice. If you have surplus named user licenses that covered some indirect use, negotiate to repurpose that investment. SAP has been amenable in some cases to convert value from shelfware licenses into document licenses.
• Negotiate price and protections: Treat Digital Access like any other big purchase. Aim for volume discounts, lock in the per-document price for a few years, and ensure maintenance fees (if any, for perpetual licenses) are understood. Clarify how future growth is priced – for example, can you pre-purchase additional documents at the same discount?
• Plan the switch and monitoring: Implement any required SAP notes or updates to track document counts in production. Set up an ongoing monitoring process for your document usage so you can course-correct if volumes rise. You want no surprises when true-up time comes.

In summary, Digital Access can mitigate the classic indirect access “license surprise,” but it introduces a capacity planning exercise.

You trade one kind of risk (unbounded audit exposure) for another kind (managing and paying for document volume). Many find that trade worthwhile, but it requires active management. Always run the numbers and scenario-plan before you leap.

Related articles

• Notorious SAP Indirect Access Cases & What Customers Should Learn
• SAP Indirect Access Compliance Strategies: How to Stay Audit-Proof
• Detecting Indirect Access in SAP: How to Find Hidden Licensing Risks
• SAP Indirect Access Contract Clauses: How to Protect Your Organization from Hidden Risks
• SAP Indirect Access 101: Definition and Common Scenarios

5 Defensive Actions to Manage Indirect Access Risk

Finally, here are five concrete actions you can take to defend against indirect access risks in your SAP environment.

These steps distill everything above into practical next moves:

1. Map All External Integrations Annually: Maintain an up-to-date inventory of every system, application, or device interfacing with SAP. Know the data flows and document volumes. An annual review keeps you aware of new integrations (e.g., that new SaaS app your marketing team plugged into SAP) before they become a surprise liability. You can’t manage what you haven’t identified.
2. Define and Document “Use” in Your Contracts: Don’t leave SAP’s definition of usage to chance. In your next SAP agreement or renewal, explicitly document what counts (and doesn’t count) as valid use. For example, write in that read-only access by third parties is excluded, or that only the creation of specific documents constitutes chargeable use. Having this in black and white will protect you later on.
3. Run Internal Indirect Use Audits Before SAP Does: Proactively audit your own system for indirect usage. Use SAP’s measurement tools, check interface logs, and simulate an audit. By doing this before SAP’s official auditors arrive, you find issues on your terms. If you discover unlicensed use, you can strategize – whether that’s quietly purchasing a few licenses to cover it, or restructuring the integration – without the pressure of an active audit.
4. Negotiate Limits or Amnesty Clauses Proactively: Don’t wait for an issue to negotiate relief. When you’re in a position of leverage (like a big purchase or renewal), bring up indirect access. Seek an amnesty for past indirect use (wipe the slate clean) or at least a pre-agreed framework for handling it. For instance, negotiate a clause like “SAP will not penalize indirect use up to X volume, and both parties will meet to discuss a resolution if exceeded.” It’s much easier to get these concessions before there’s a problem on the table.
5. Consider Selective Digital Access (Don’t Over-Convert): Evaluate SAP’s Digital Access license, but adopt it selectively. You might find it beneficial for certain high-risk areas (like customer-facing processes) while unnecessary for others. Avoid blindly converting everything to the new model – you could end up over-paying. Instead, pilot it or use it where it clearly reduces risk/cost, and keep traditional licensing where it’s already sufficient. This hybrid approach ensures you “pay as you go” for known risks, without buying a whole new licensing structure you don’t fully use.

By taking these defensive actions, you put your organization in control of the indirect access issue. You’ll transform indirect access from a lurking threat into a manageable aspect of your SAP license strategy.

With vigilance, clarity, and proactive planning, you can integrate systems and innovate in your business without unwelcome surprises from SAP.

Read about our SAP Advisory Services

fredrik.filipsson

Fredrik Filipsson is the co-founder of Redress Compliance, a leading independent advisory firm specializing in Oracle, Microsoft, SAP, IBM, and Salesforce licensing. With over 20 years of experience in software licensing and contract negotiations, Fredrik has helped hundreds of organizations—including numerous Fortune 500 companies—optimize costs, avoid compliance risks, and secure favorable terms with major software vendors. Fredrik built his expertise over two decades working directly for IBM, SAP, and Oracle, where he gained in-depth knowledge of their licensing programs and sales practices. For the past 11 years, he has worked as a consultant, advising global enterprises on complex licensing challenges and large-scale contract negotiations.

See Full Bio