Introduction – Why Indirect Access Risk Matters
SAP indirect access is a hidden compliance threat lurking in many IT landscapes. It occurs when non-SAP systems or external users interact with SAP data or functions without logging into SAP directly.
In other words, if Salesforce, an e-commerce site, or a mobile app triggers an SAP transaction or updates SAP records in the background, that’s indirect use of SAP. This has become the number one SAP audit risk for many enterprises because it represents potential lost license revenue for SAP.
SAP actively pursues indirect usage in audits, knowing that integrations can bypass the traditional named-user licenses. For an overview of SAP licensing, read our guide SAP Licensing Models & Optimization.
The vendor’s motivation is clear: capture revenue from business value derived via SAP, even if users never log in. Industry observers note that SAP’s aggressive audit tactics mirror Broadcom-like behavior – using surprise compliance audits as leverage to push new sales.
CIOs and IT managers must therefore stay vigilant: indirect access can lead to multi-million dollar back-charges if not proactively managed.
High-profile cases like the SAP vs. Diageo lawsuit (where a customer owed about £54 million due to a Salesforce-to-SAP integration) have put every large SAP customer on alert. Indirect access is no longer a vague technicality; it’s a board-level concern that can hit budgets hard if ignored.
Identifying Indirect Access in Your Landscape
Many companies underestimate how much indirect SAP usage they have. Start by inventorying all the places where non-SAP systems connect to SAP.
Common integration points include: CRM systems (e.g. Salesforce) that create or update SAP sales orders, customer or dealer portals that push orders or pull pricing from SAP, eCommerce platforms feeding transactions into SAP, middleware or API gateways (SAP PI/PO, MuleSoft, etc.) shuttling data in and out, and mobile or field service apps accessing SAP via web services.
Even IoT sensors, robotic process automation (RPA) bots, or data warehouses might be reading or updating SAP behind the scenes. Every such connection is a potential indirect access channel.
Detection Checklist: To identify indirect use risks, follow a structured approach:
- Map all integrations: Document every inbound and outbound interface to SAP. Include third-party applications, cloud services, devices, and internal tools that read from or write to SAP.
- Identify document creation: Note which external systems actually create or modify SAP transactions or documents (such as sales orders, purchase orders, invoices). These are high-risk integrations.
- Distinguish external vs. internal activity: Determine if data is coming from outside your organization (customers, partners) or just from another internal system. External user activity (like a customer portal) is more likely to be viewed as chargeable indirect use.
- Review technical users: List the SAP system user accounts that these integrations use. Often, a generic account (e.g.
INTF_SALES_API) logs into SAP on behalf of external processes. Check if each of those technical users has an appropriate license or if your contract treats them specially (they might not count as a normal named user if defined as a “communication user” in contract terms).
Practical tools can assist in this discovery. SAP Solution Manager or the cloud-based SAP Cloud ALM can catalog interfaces and data flows.
On the SAP system, enable audit traces: transactions like ST03N (workload analysis) and SM19 (security audit log setup) help trace calls coming from external sources or technical users.
By analyzing these logs, you might spot an account creating hundreds of documents (a sign of an automated interface).
Additionally, third-party SAP license management tools (such as Snow, USU, or Aspera) can automatically detect indirect usage patterns and provide dashboards of where and how external systems are driving SAP activity. The key is to eliminate blind spots – you want no surprises about which non-SAP apps are touching your ERP.
Understanding the Risk Triggers
Not all indirect usage carries the same risk. Several triggers raise red flags in SAP’s eyes:
- User-Based Exposure: When large numbers of third-party users indirectly use SAP. For example, hundreds of sales reps use Salesforce, which in turn updates SAP customer or order data. From SAP’s perspective, each of those people is gaining benefit from SAP without a license. The risk is that SAP demands that each of those external users be covered by a named-user license.
- System-Based Exposure: Even without distinct users, a non-SAP system or application that creates SAP records can pose a risk. For instance, a custom order management app or an IoT platform that feeds data into SAP is essentially a “user” of SAP in a licensing sense. SAP will view the external system itself as an indirect user, and potentially the people or devices behind it as well.
- High-Volume Automation: APIs, bots, or sensors churning out thousands of SAP transactions daily amplify the exposure. Volume is a trigger – if an interface is creating a large number of SAP documents (sales orders, postings, etc.), the financial impact under SAP’s models could be significant. High volumes also draw attention during audits because they’re easily visible in SAP logs and can translate to large license fees (e.g., under document-based pricing).
- Contractual Ambiguity: Older SAP contracts often lack a clear definition of indirect use, or define “use of the software” so broadly that almost any access counts. This ambiguity is risky. If your agreements don’t explicitly address indirect scenarios, SAP auditors will default to the strictest interpretation (i.e., any access requires a license). Without protective language (discussed below), you’re exposed to SAP’s interpretation of indirect usage, which is notoriously all-encompassing.
- Audit Blind Spots: A major audit red flag is isa lack of traceability—if you cannot demonstrate which users or systems generated certain SAP transactions. During an audit, SAP may ask, “Who created these 20,000 sales orders?” If the answer is unclear (e.g., a generic account created them, or you haven’t logged the source), SAP will assume they were unlicensed external usage. In essence, the inability to attribute activity to properly licensed users can lead SAP to assume full commercial use by indirect users and present a bill accordingly.
Understanding these triggers helps you prioritize where to focus. A low-volume, read-only data extract is low risk, whereas a high-volume write interface or a popular external portal is high risk. Any scenario where SAP provides core business processing to non-SAP users/systems is what SAP wants to license.
Read our top10 tips on SAP license optimization, SAP Licensing Optimization: 10 Tactics to Reduce Cost & Risk.
Quantifying Potential Liability
Once you’ve identified possible indirect use channels, the next step is to estimate how big the exposure could be in monetary terms. This means translating technical usage into license metrics:
First, count the integrations and document volumes. For each external system that creates SAP business documents, estimate how many documents are created per year. Focus on the nine document types SAP’s Digital Access model uses (Sales Orders, Invoices, Purchase Orders, Service & Maintenance docs, Manufacturing orders, Quality docs, Time entries, Financial postings, and Inventory movements).
How many of each type might that system generate annually? For example, your Salesforce-SAP integration might create 250,000 sales orders per year in SAP.
Next, calculate the theoretical cost under different models:
- Named User model: Estimate how many individual external users or devices are behind those transactions. In the Salesforce example, maybe 500 salespeople use Salesforce, which feeds SAP. If SAP insisted each needed a license (say, a Professional user license), the cost could be significant (hundreds of users times the per-user license cost).
- Digital Access (Document) model: Calculate the number of documents. Using the example of 250,000 sales orders/year, this equates to 250,000 document licenses consumed annually. SAP sells document licenses in bundles (often 1,000 documents as a unit with a price). If, hypothetically, the price is around $0.20 per document, 250k documents would equate to about $50,000 per year in digital access fees. The actual pricing can vary, but having a ballpark figure is important.
This quantification is powerful. Even if you haven’t formally adopted SAP’s digital access model, SAP’s auditors will often perform a similar calculation behind the scenes during an audit.
They might say, “Your interfaces created X documents; that would cost $Y under our digital access price list,” and use that as a basis for an audit claim or an offer to migrate you to the new model.
By knowing your own numbers first, you control the narrative. For instance, if you calculate that under worst-case interpretation, your indirect use is worth $200k/year, you might negotiate a deal with SAP for future use at a fraction of that rather than paying a surprise $2 million audit penalty for several years of “unpaid” usage.
The exercise gives you leverage and prevents sticker shock. Essentially, it’s better to know your potential liability in advance and budget or negotiate accordingly than to be caught unprepared by SAP’s audit team.
Contractual Risk Management
Your best defense against indirect access surprises is a well-crafted contract. Proactively review and, if needed, amend your SAP agreements to define and limit indirect access.
Key contract clauses to focus on include:
- Clear Indirect Use Definition: Ensure the contract explicitly defines what counts as indirect use (and what doesn’t). You want language that narrowly scopes indirect access to scenarios where an external system creates or changes SAP transactions. Merely viewing or reporting on SAP data through a third-party tool should not require additional licenses. By clarifying this, you avoid SAP claiming that even passive data consumption is a breach.
- Named System Users / Technical Access: Carve out a provision for interface accounts. Define technical or system user IDs (used for integrations) as distinct from human users and exclude them from user-based licensing counts beyond a baseline. For example, state that an interface account used solely for data exchange counts as a single named user (regardless of the number of external users behind it). This prevents SAP from charging, say, 500 licenses for 500 portal users if all data flows through one SAP login account.
- No Retroactive Fees for New Metrics: Include a “no retroactive charge” clause. This means if SAP introduces a new licensing model or metric (like the Digital Access document model), any compliance will be measured prospectively from the adoption of that model, not back-billed for past usage. In practice, if you stick with your old contract and later move to digital access, SAP shouldn’t come after you for past document counts provided you were compliant under the old rules. Make sure your contract says that changes in licensing approach do not trigger back-dated costs.
- Conversion Credit: If you negotiate a switch to the Digital Access model or any new model, get credit for the investment you’ve already made in traditional licenses. For instance, if you previously paid for 1,000 named-user licenses and are now shifting to documents, include terms that credit a portion of those fees towards the new licenses. This prevents double-paying. SAP often has conversion programs – insist on written credit terms so you’re financially protected during any transition of models.
- Integration Whitelisting: It can be wise to explicitly list known third-party systems or use cases and state that these are permitted under your license. For example, write an addendum that names Salesforce, Workday, or your customer portal and clarifies that data exchange with these systems is allowed under certain conditions without additional licenses. While SAP won’t simply give blanket free rights, getting specific written acknowledgment for key integrations can shut down future disputes. Essentially, you’re “whitelisting” certain interfaces in the contract.
Include strong language to reinforce these points. For example, you might add a clause:
“Access by third-party systems shall not be considered indirect use unless such systems create SAP transactional documents for commercial purposes.”
This kind of clause makes it clear that things like viewing data or non-transactional interactions won’t count against you. The more you can pre-negotiate and document, the less gray area there will be during an audit.
Engage your legal team or a licensing expert to draft amendments if needed, especially before a renewal or major purchase. Tight contract terms turn ambiguous risk into defined, manageable scenarios.
Proactive Monitoring & Internal Controls
Managing indirect access risk is not a one-time project – it requires ongoing monitoring and governance. By instituting internal controls, you can catch issues early (or prevent them altogether) before SAP ever audits you.
Operational monitoring tactics include:
- Regular interface reviews: Establish a schedule (quarterly, for instance) to review all SAP integrations. Use tools or manual checks to ensure no new interfaces have been added without your knowledge. Compare current interfaces to your documented inventory.
- Track document creation volumes: If you’re able, set up a “Digital Access dashboard” internally. This could be a custom report or the use of SAP’s Digital Access Evaluation tooling to monitor how many of each document type are created by external systems month-to-month. Spikes or growth trends will alert you to potential compliance issues in time to react.
- Leverage SAP logs and tools: Continuously use SAP’s logs (ST03N workload stats, SM20 audit logs) to identify where high volumes of transactions originate. Some companies implement scripts or use SAP Solution Manager to parse these logs for RFC or API calls. If you see, for example, an unexpected external program calling SAP 10,000 times in a week, investigate it immediately.
- Ownership and accountability: Assign clear responsibility for indirect access compliance. Typically, the SAP Basis or security team can own monitoring the technical logs and maintaining the integration inventory. The IT asset management or licensing team should own reporting on license consumption (including indirect metrics). The procurement or contract management team should track your contractual rights (so they can quickly validate whether a certain usage is within bounds). By dividing these roles, you ensure continuous attention to the issue.
Preventive governance measures are equally important:
- Internal policy on indirect use: Develop a policy or guideline that defines what is considered indirect use in your organization and how it must be handled. For example, the policy might say, “Any project that integrates a third-party system with SAP must involve the IT licensing team to assess license impact.” Socialize this policy with all IT and business stakeholders.
- Architecture review for new integrations: Ensure that no new SAP interface goes live without a licensing check as part of your solution design process. Add a checkpoint in project approval: architects must evaluate whether the integration will create SAP documents or use SAP data in ways that require licenses, and obtain sign-off on how it will be licensed. Sometimes, a slight change in design (like using a different data flow or limiting write actions) can avoid indirect use problems.
- Documentation of usage and justification: Maintain documentation for each integration that explains its purpose, how it works, and what licensing assumption it falls under. For instance, if an interface uses a technical user licensed as a Developer, be sure to note that. If an external user group is allowed through a specific clause, keep that clause handy. In an audit, this binder of documentation becomes your evidence to show SAP that you’ve managed compliance. It flips the script: you can demonstrate exactly who/what is using SAP and under what license, leaving less room for SAP to make wild assumptions.
By monitoring continuously and governing proactively, you build an internal early-warning system. If an indirect usage spike occurs, you catch it and address it (perhaps by procuring additional licenses or throttling the usage) before SAP comes knocking. Consistent vigilance is your best defense.
Audit Defense & Communication Strategy
Despite best efforts, you may eventually face an official SAP license audit. How you handle the audit can greatly influence the outcome, especially concerning indirect access findings. It’s crucial to approach audits strategically and not as a passive victim.
Here are tactics for audit defense:
- Set the ground rules: The moment an audit is announced, engage your SAP account manager and/or SAP’s audit team to clarify scope and process. Do not blindly allow SAP to deploy tools or gather data beyond the agreed scope. For example, if SAP proposes running a script to scan for indirect use, insist on understanding exactly what it does and ensure it aligns with contract terms. If possible, run SAP’s own measurement tools yourself (like the standard USMM/LAW reports or the Digital Access evaluation tool) and provide the results, rather than giving SAP free rein to poke around. Controlling the data flow ensures you aren’t volunteering unnecessary information that could be misconstrued.
- Conduct an internal audit first: As soon as you know an audit is coming (or even better, as part of routine practice), do your own measurement of indirect usage. Use the same tools SAP would use. This way, you won’t be caught off guard by SAP’s findings because you’ll have your numbers in hand. Suppose your internal checks show some potential indirect use of non-compliance. In that case, you can prepare explanations or even quietly fix some issues (e.g., disable an obsolete interface) before the official audit begins.
- Maintain a united front in communication: Only designated spokespeople (perhaps your licensing manager or CIO) should communicate with SAP’s auditors. They should be well-versed in your contract and prepared to push back diplomatically. If SAP’s audit report claims “unlicensed indirect use,” do not immediately concede. Instead, ask for detailed clarification: Which systems? Which documents or users? What contract clause are they basing this on? Make SAP spell out its case in writing. This avoids misunderstandings and gives you time to analyze the claim.
- Don’t admit fault prematurely: In conversations, avoid statements like “We didn’t know about that” or “We might have missed those licenses.” Keep communication factual and neutral. If an auditor points out something, respond with “We will review these findings against our records and contract.” Any admission could be used against you in negotiations. It’s better to investigate and respond formally once you’re sure of your stance.
- Leverage your contract and data: If you followed the earlier advice on contract clauses and documentation, now is the time to use them. Provide SAP with the relevant contract excerpts or integration documentation that justify why you believe those uses are compliant or should not incur additional fees. For example, if you have a clause exempting read-only access, point out that the usage they flagged falls under that category.
- Negotiate a resolution – on your terms: If the audit does reveal genuine indirect use beyond your licenses, treat the outcome as a negotiation, not a fine. SAP’s goal isn’t to punish you; it’s to sell licenses. You can often transform the audit finding into a forward-looking deal. For instance, rather than paying a hefty back maintenance fee for three years of indirect use, propose to purchase an appropriate number of licenses or a digital access package for future use. Often, SAP will be amenable to waiving penalties if you commit to a new license purchase that covers the issue moving forward. Always aim to convert a retroactive compliance claim into a proactive licensing arrangement. This way, you close the compliance gap and SAP gets a sale – a win-win that avoids writing a check for nothing tangible.
- Document the settlement: Finally, any resolution with SAP should be put in writing (contract addendum or letter). Ensure it states that the agreed licenses or fees resolve the identified indirect usage, with no admission of wrongdoing, and that no further claims for that usage will be made. This protects you from SAP revisiting the issue later.
By handling an audit methodically – controlling scope, verifying everything, and negotiating firmly – you can emerge without the massive surprise bill that SAP indirect access horror stories are made of. Preparation and a cool head are your allies.
Alternatives to Reduce Indirect Use
A smart long-term strategy is to architect your systems in ways that minimize indirect access exposure. This doesn’t mean crippling your integrations, but designing them thoughtfully to reduce the need for external systems to directly interact with SAP through transactions.
Consider these approaches:
- Read from SAP, write outside when possible: If a third-party system only reads data from SAP (e.g,. checking inventory or customer info) and does not create records back in SAP, it generally doesn’t incur licenses under digital access. So, for analytics or data sharing scenarios, consider using a data warehouse, replication tool, or APIs that pull data out of SAP for external consumption. By providing data via a one-way feed, external users get what they need without each individual needing an SAP license. Reserve writes (creating or updating SAP records) when necessary.
- Use middleware as a buffer: Middleware or integration layers (like SAP Process Orchestration, MuleSoft, Boomi) can consolidate and batch interactions with SAP. For example, instead of 1000 separate external calls creating 1000 orders throughout the day, a middleware could batch them and send them to SAP in one go or a few controlled calls. This can reduce the number of document-creating events. Middleware often operates under a single technical account, making it easier to license and monitor. (Be careful: middleware doesn’t eliminate indirect use, but it can streamline it in a controllable way.)
- Offload high-frequency processes: If certain high-volume processes don’t truly need to run in real-time in SAP, consider doing them in another system and updating SAP in aggregate. For instance, an IoT setup might capture millions of sensor readings. Instead of logging each one in SAP, perhaps summarize key metrics and send a daily summary or only exceptions into SAP. Or use SAP just as an occasional system of record while the heavy-duty processing happens elsewhere. Fewer touchpoints into SAP means fewer potential license triggers.
- Leverage SAP’s own solutions strategically: Sometimes, using an SAP-provided tool can help because it comes with clear licensing. For example, SAP has products like SAP NetWeaver Gateway or SAP API Management. While these don’t give free passes, they can provide a governed way to expose data. Additionally, if you move to S/4HANA and formally adopt the digital access model, you can architect knowing exactly what counts. You might design an integration to create only one type of document instead of two, or use SAP’s recommended integration patterns optimized for the licensing model.
- Design with Digital Access in mind: If you’re planning a major upgrade or new implementation (such as a greenfield S/4HANA project), bake indirect access considerations into the design from day one. For each integration, ask, “Will this create any of the nine document types in SAP? How often? Is there a way to achieve the business goal with fewer document creations?” Sometimes, employing a little creativity can maintain functionality while minimizing counted events. For example, rather than having an external system create both a sales order and an invoice in SAP, maybe just create the order in SAP and let SAP’s own billing run handle the invoice (since follow-on documents triggered by SAP internally are not counted again under digital access).
In essence, indirect use reduction is about smart engineering. Provide data access and integration in ways that either keep external usage read-only or channel write access through as few SAP transactions as possible. Over time, these design choices can drastically shrink your compliance footprint without sacrificing capabilities.
Read about the costs of SAP licensing, SAP License Cost Structure: How SAP Pricing & Maintenance Work.
Risk Scenarios & Examples
To illustrate how indirect access risks manifest and how they can be resolved, here are a couple of real-world-inspired scenarios:
Scenario 1:
Manufacturing IoT Overkill – A global manufacturer hooked up thousands of IoT sensors and machines to its SAP ERP to feed live production and inventory data. SAP later claimed that each device’s data update was an indirect access instance requiring a license, which led to a significant exposure on paper.
Action Taken: The IT team regrouped. They introduced a dedicated technical gateway user in SAP for all IoT inputs and limited the frequency of updates. Instead of every machine writing to SAP directly, data was aggregated through a middleware, which then updated SAP periodically under that single user’s credentials.
They also ensured the IoT updates only added records that were covered by a specific license category they already owned.
Result: By demonstrating that all device communication was funneled through a properly licensed account (and by reducing the sheer number of SAP transactions via batching), they convinced SAP that the indirect use was under control. The audit claim was dropped without extra fees.
Scenario 2:
Service Portal Indirect Users – A financial services firm used ServiceNow as a front-end for employees and customers to submit support tickets, some of which would automatically create or update incident records in SAP (SAP was being used as a back-end IT service management module). SAP’s auditors flagged that all the ServiceNow users submitting or handling tickets were unlicensed indirect SAP users.
Action Taken: The company negotiated with SAP by showing that only their internal support team (already licensed SAP users) ultimately processed those tickets in SAP.
They adjusted the integration so that ServiceNow would pass data to SAP, but the final save in SAP was executed by a small number of named SAP support users who were fully licensed. They also added a contract clause in their next renewal explicitly permitting the ServiceNow-to-SAP integration for ticket updates.
Result: SAP accepted that the external portal users were not actually “using” SAP directly (since an SAP-licensed employee performed the actual transaction). The firm avoided an indirect access charge and clarified the rules for that integration going forward.
These vignettes show the importance of classification and proactive controls. In both cases, by reconfiguring how external systems interacted with SAP (either technically or contractually), the companies brought the usage back into compliance. The lesson is that indirect access risk can often be mitigated with clever technical changes or clear license assignments before it turns into an audit dispute.
5 Steps to Minimize SAP Indirect Access Exposure
- Map Every Integration: Create a complete inventory of all systems touching SAP. You can’t protect against what you don’t know about – list out every interface, API, and data feed into/out of SAP, and keep it updated as your landscape evolves. This map is the foundation of indirect use management.
- Define Contractual Boundaries: Don’t rely on hope or vague terms. Proactively negotiate contract clauses that specify what indirect use means for your organization. Make sure viewing data is free, technical interfaces are accounted for, and new licensing models won’t be back-billed. Get it in writing so there’s no ambiguity later.
- Monitor Continuously: Set up internal monitoring for indirect use. Track how many SAP documents external systems create each month. Use SAP’s tools or third-party solutions to get alerts on unusual activity. Regular monitoring lets you spot (and correct) a licensing issue before it snowballs into a major audit finding.
- Prepare Internal Reports: Treat every year as if an SAP audit could happen. Run your own “digital access” measurements and internal license audits. Document the results and understand your indirect usage profile. By having these reports on hand, you can respond to SAP’s inquiries with confidence and accurate data – often heading off contentions by showing that you’ve done your homework.
- Negotiate Protection Clauses: When engaging with SAP (for renewals, expansions, or true-ups), always include discussions on indirect access. Add clauses like no retroactive fees, permitted interfaces, and named user exemptions for technical accounts. Also negotiate fair terms if you ever transition to the digital access model (such as credits and buffers). By embedding these protections in your agreements, you significantly reduce the chance of an unpleasant surprise bill related to indirect use in the future.
Read about our SAP Services.
