Indirect Access Scenarios
Introduction: Indirect access has become one of SAP’s biggest licensing risks for modern enterprises.
This issue arises when third-party systems or external users interact with SAP data without directly logging into SAP – for example, an eCommerce site or a CRM system feeding information into SAP in the background.
Companies have learned the hard way that such “indirect” usage can trigger substantial license fees if not properly accounted for.
In recent years, several high-profile cases have brought indirect access to the forefront, highlighting that even well-intentioned integrations can lead to multi-million-dollar compliance surprises.
In this article, we present real-world SAP indirect access examples and case studies to help readers understand these scenarios and plan accordingly.
Each scenario highlights how the licensing risk materializes and, importantly, how enterprises addressed the challenge.
From eCommerce platforms to IoT sensors, these examples cover both the pitfalls and practical solutions organizations have implemented.
The goal is to equip you with lessons learned and actionable strategies to manage indirect use of SAP before it becomes a costly problem. Read our ultimate guide, SAP Indirect Access & Digital Licensing (2026 Guide): Risks, Costs, and Negotiation Tactics.
Scenario 1 – SAP Indirect Access Example: eCommerce Platform → SAP
Setup: A company’s eCommerce web store is integrated with SAP, automatically creating sales orders in SAP whenever customers place orders online.
This seamless setup improves efficiency – no manual re-entry of orders – but it introduces a tricky licensing gray area.
From SAP’s perspective, each shopper on that website who triggers an SAP transaction is an “indirect user.” If thousands of customers place orders, that could imply thousands of SAP user licenses – a clearly impractical solution.
Risk:
SAP may interpret every online buyer as an unlicensed user of SAP. In fact, some companies have been hit with massive audit penalties because their customer portals fed orders into SAP without proper licensing.
What seems like normal business activity (customers placing orders) can violate SAP’s terms if each user isn’t accounted for. For example, 10,000 shoppers generating SAP orders might equate to 10,000 named users in SAP’s eyes – an untenable exposure if left unaddressed.
Solutions: To avoid this indirect access pitfall, companies use a few strategies:
- Named Technical User for Integration: Route all web orders through one dedicated SAP user account (a technical service user). This way, only one named user license is needed for the interface. However, it must be explicitly allowed in your contract, as one account representing thousands of users can be a compliance risk if not agreed with SAP.
- SAP Digital Access (Document Licensing): Adopt SAP’s Digital Access model to license outcomes instead of individual users. Every sales order created by the eCommerce site counts as a document, and you purchase licenses for those documents (e.g., a block of Sales Order documents per year). For instance, 10,000 external orders would require licensing 10,000 sales order documents – often far cheaper than licensing 10,000 separate users.
- Negotiated Volume Caps or Flat Fees: Collaborate with SAP to incorporate this scenario into your contract, ensuring predictable terms. For example, consider negotiating a clause or add-on license that covers a specified number of online order documents per year for a fixed fee or cap. This ensures that as your online business grows, you won’t be surprised by exponential license costs.
The table below contrasts the two licensing approaches for this scenario:
| Aspect | Named User Licensing (each user needs a license) | Digital Access Licensing (documents-based) |
|---|---|---|
| Licensing Basis | Requires each external user (customer) to have an SAP named user license. (Often companies use one integration account for all orders, which is not officially compliant if thousands of end-users aren’t licensed.) | Based on the number of Sales Order documents created in SAP by the external system. (For example, 10,000 orders via the web store = 10,000 documents counted for licensing.) |
| Cost Implications | Prohibitive at scale. Buying SAP licenses for thousands of customers is infeasible. If unlicensed usage is ignored, an audit can yield huge back charges. | Scales with usage volume. Those 10,000 orders could be licensed as 10,000 documents, which – with volume bundle pricing – would cost far less than thousands of individual user licenses. |
| Compliance Risk | Very high if relying on one user to cover many. Unless your contract explicitly permits it, SAP auditors can flag non-compliance for the unlicensed customer activity. | Lower, provided you license the document volume. The main risk is monitoring volumes – if you exceed your purchased document count, you’ll need to acquire additional licenses (ideally pre-negotiated to avoid premium prices). |
Checklist: Before proceeding with an eCommerce-to-SAP integration, ensure:
- You have mapped how online orders flow into SAP (which interfaces and user accounts are used).
- You’ve estimated your annual online order volumes to plan for Digital Access document licenses.
- Your SAP contract or agreement includes provisions (such as caps, fixed fees, or exceptions) to cover these eCommerce transactions without unexpected charges.
Read how to measure Indirect access, Identifying Indirect Usage in Your SAP Environment (Before SAP Does)
Scenario 2 – SAP Indirect Access Case Study: Salesforce CRM Reading SAP Data
Setup: In this scenario, a company’s sales team uses Salesforce CRM, which is integrated with SAP to retrieve or update customer and order information.
For example, Salesforce might pull customer credit status or product pricing from SAP on-demand, or push new sales opportunities into SAP. Users work in Salesforce’s interface, not SAP’s, but behind the scenes, the CRM system queries and transmits data to the SAP environment.
Risks:
This integration blurs the line of SAP usage. SAP might argue that each Salesforce user who views or triggers SAP data is an indirect SAP user and therefore requires a license.
If 200 sales reps use Salesforce to access data stored in SAP, SAP could consider those 200 individuals as unlicensed users.
The audit risk is significant – companies have been caught off guard by compliance issues because their CRM was tapping SAP data without proper arrangements.
Even if the CRM primarily reads information (without creating SAP records), older contracts or strict interpretations could still put the usage in a gray area, leading to audit findings.
Solutions: Companies have taken a few approaches to enable CRM-SAP integration without violating licenses:
- Dedicated Technical User for Data Exchange: Set up a single named SAP user account to handle all Salesforce-to-SAP interactions. All queries and updates from Salesforce are sent to this account, which is properly licensed. This minimizes the number of SAP licenses needed and centralizes access. It’s straightforward and low-cost, but one must ensure this approach is transparently documented and permitted in the SAP contract (since one account is effectively serving many CRM users).
- SAP Cloud Platform Integration (CPI): Use SAP’s integration middleware as the bridge between Salesforce and SAP. By licensing SAP’s integration platform (e.g., SAP Integration Suite/CPI), data exchanges happen through a sanctioned layer. This means you’re paying SAP for the integration capability, which can cover the usage instead of requiring each Salesforce user to have an SAP license. It also provides better control and monitoring of what data moves between the systems.
- Digital Access Conversion (DAAP): Convert the licensing model for this interface to SAP’s Digital Access (document-based) model. SAP’s Digital Access Adoption Program (DAAP) offers a way to swap some traditional user licenses for document licenses at a discount. Instead of counting Salesforce users, you license the documents that the CRM generates in SAP (if any). For example, if Salesforce creates customer records or sales orders in SAP, you would license those document creations. This approach ensures compliance and can be cost-effective if the integration results in a significant reduction in the number of SAP transactions.
A comparison between using a single technical user vs. using Digital Access for the CRM integration:
| Factor | Technical User Integration | Digital Access Licensing |
|---|---|---|
| Pros | Simple and cheap setup (only one SAP user license needed); works well for one-way or read-heavy integrations. | Fully compliant with SAP’s rules; scales to any number of CRM users without extra user licenses; covers any SAP documents created via CRM properly. |
| Cons | Compliance risk if many people benefit – SAP may view it as under-licensing; can trigger audit penalties if not contractually allowed; one user account with broad access needs strict oversight. | Requires purchasing document licenses (additional cost); need to estimate and monitor usage volumes (e.g. count of records created from CRM); if the CRM mostly reads data and creates few documents, you might pay for capacity you don’t use. |
Checklist: To manage a CRM-to-SAP integration, make sure:
- Every data flow between Salesforce and SAP is documented (what is being read or written).
- You’ve mapped Salesforce-driven actions to SAP licensing (are those actions covered under named users or document licenses?).
- You have considered SAP’s offerings (such as DAAP or integration platform deals) to reduce exposure and secured any necessary contract terms for this integration.
Read how to negotiate SAP Indirect access, Negotiation Guide: Indirect Access Clauses and Protections in SAP Contracts.
Scenario 3 – SAP Indirect Usage Example: IoT Devices Updating SAP
Setup: Imagine a manufacturing company that installs smart sensors and IoT devices on its equipment.
These devices automatically send data and trigger transactions in SAP – for instance, creating maintenance notifications in SAP PM (Plant Maintenance) when a machine’s temperature exceeds a threshold, or updating inventory counts in SAP in real-time. IoT devices communicate with the SAP system through APIs or middleware, eliminating the need for human intervention.
Risks:
Each IoT sensor or device interacting with SAP could be considered an indirect “user” under SAP’s licensing definitions. If a factory deploys 500 sensors, does that mean 500 SAP user licenses are required? In a traditional model, potentially yes, which is neither technically nor financially feasible.
This poses a significant licensing liability: a mass deployment of devices might inadvertently result in what SAP considers unlicensed access. An audit could reveal thousands of unaccounted “users” (devices) sending data to SAP, leading to an astronomical compliance bill.
The risk is especially high because IoT setups often scale to hundreds or thousands of devices, and their transaction volumes can grow exponentially.
Solutions: Enterprises addressing IoT-to-SAP integrations have used tactics such as:
- IoT-Specific Licensing from SAP: Collaborate with SAP to establish a customized licensing arrangement tailored to IoT scenarios. SAP has recognized this emerging need and, in some cases, offers IoT-specific license types or add-ons. For example, there may be a license for devices or a limited-use “machine” user license that covers a set of sensors. Engaging SAP early about your IoT use case can lead to a tailored agreement that doesn’t treat every device as a full-priced user.
- Digital Access with Bundled Volume: Use SAP’s Digital Access model to license the transactions/documents generated by devices, rather than the devices themselves. Typically, IoT devices generate a high volume of small transactions – for instance, each sensor may create a maintenance event or an update record (a “document” in SAP terminology). Companies can estimate the annual volume of such documents and purchase Digital Access licenses in bulk (bundles of document counts). This way, whether you have 100 devices or 1,000 devices, you’re covered as long as the total documents they create in SAP is within your licensed volume. It’s a usage-based approach that aligns costs to actual system load.
- Negotiated Growth Caps: Given the likelihood of IoT deployments expanding, companies often negotiate contract terms to cap the cost exposure. For example, you might arrange a flat fee or a tiered license cost that covers up to a certain number of devices or transactions. If you plan to double the number of sensors next year, having a growth cap clause ensures your SAP costs don’t double in lockstep. Essentially, it provides budget predictability even as IoT usage grows, preventing “runaway” licensing expenses.
Let’s compare the cost impact of treating devices as named users versus using document-based licensing:
| Approach | Per-Device User Licensing | Document-Based Digital Access |
|---|---|---|
| What’s Licensed | Each individual device would need its own SAP user credential and license (as if it were a person accessing SAP). | The output of all devices is licensed in aggregate by counting the SAP business documents they create (e.g. maintenance notifications, sales orders, etc.). |
| Cost Model | Upfront cost scales with number of devices. 500 sensors might require 500 user licenses, an extremely costly proposition (plus ongoing maintenance on each license). | Cost scales with transaction volume. You purchase document licenses in bundles. For example, if those 500 sensors generate 100,000 SAP documents per year, you license that quantity. High volumes often come with volume-discount pricing. |
| Scalability | Poor – costs grow linearly with every device added. This model discourages expanding IoT usage because each new sensor directly adds licensing cost. | High – you can add many devices as long as your total document count stays within licensed limits. If IoT data increases, you can buy additional document capacity in chunks, often at marginal incremental cost due to pre-negotiated discounts. |
| Compliance Risk | High risk of non-compliance if devices are connected without individual licenses. An audit could identify “unnamed” device users and result in a massive true-up fee. | Lower risk when properly licensed via documents. The main task is monitoring document creation. As long as you track usage and adjust your license volumes accordingly, audits should align with expectations. |
Checklist: For any IoT integration with SAP, consider:
- Have you estimated the monthly or yearly volume of SAP transactions coming from IoT devices?
- Are there contract provisions or special licenses in place to cover a large number of devices (so they aren’t counted one-for-one as users)?
- Do you have a plan to periodically review IoT-driven document counts and adjust your Digital Access license volume before it exceeds your entitlement?
Scenario 4 – SAP Indirect Use Case Study: Subsidiary Access to Parent SAP
Setup:
A large organization’s SAP system is used not only by its own employees but also by people from outside entities – for example, a subsidiary company, a joint venture, or contractors/partners.
Consider a parent company that runs a global SAP instance and now wants a recently acquired subsidiary to start using the system, or perhaps external consultants need temporary access to perform work. These users will log in to the parents’ SAP system to perform their duties.
Risks:
SAP’s licensing is typically company-specific. Users are typically defined as employees of the licensed customer (and its majority-owned affiliates, if permitted by the contract). If individuals from a subsidiary that isn’t clearly covered, or from an external partner, access the system, they could be deemed unlicensed “indirect” users.
The risk is that during an audit, SAP finds dozens or hundreds of such logins (with email domains or IDs not belonging to the main customer) and flags them as unauthorized.
This can lead to a demand that each of those users be retroactively licensed – often at a premium, because they might require expensive External or Professional user licenses. In short, having a third party or loosely defined affiliate in your SAP without explicit licensing opens you to significant compliance exposure.
Solutions: Companies handling multi-entity or external access have a few options:
- Partner or External User Licenses: SAP offers special user license categories for external parties. Instead of using the standard internal user licenses, you can purchase “Business Partner” or “External Contractor” named user licenses for those individuals. Each such user is then legally licensed to use your SAP system. This solution is straightforward for a small number of outside users – you simply purchase licenses for each person – and it maintains compliance clarity (everyone has a license).
- Subsidiary Carve-Outs in Contract: When dealing with an entire subsidiary or affiliate company, the preferred approach is to negotiate your SAP contract to include that entity’s usage. This often means explicitly naming the subsidiary (or defining “Affiliated Companies”) in the contract so that their employees are treated as authorized users under the main license. If the subsidiary was acquired after the original contract was signed, you may need an amendment to extend your license footprint to them. While this may involve an additional fee or license count adjustment, it prevents the need to license each user separately as an “external” party. Essentially, it makes the subsidiary’s users “internal” from SAP’s perspective.
- Separate System or Tenant: In extreme cases, if neither of the above solutions is feasible (for instance, the external group’s usage is very large or subject to different regulatory needs), companies might deploy a separate SAP instance or client for the third party with its own licensing. This is a last resort due to its complexity, but it segregates access. Another variant is to provide the subsidiary/partner with limited interfaces (like a portal or API) instead of direct SAP GUI access, thereby controlling the scope of their use and possibly covering it via an integration license or Digital Access documents rather than full user licenses.
Here’s a comparison of using individual partner licenses versus negotiating a contract inclusion (carve-out) for a subsidiary:
| Option | Partner/External User Licenses | Contract Carve-Out for Subsidiary |
|---|---|---|
| Description | Buy specific SAP named user licenses for each external person (e.g. partner or contractor users). These licenses are often a different type meant for third-party users. | Extend the main SAP agreement to cover the subsidiary or partner organization’s employees. They are treated as authorized users under your existing license entitlement, as if they were your own employees. |
| Cost Model | Cost is per user. Each external user license has a fee (which can be similar to or higher than an internal user license, depending on type). Scales linearly with number of outside users. | Cost is negotiated as part of contract (could be a one-time uplift or an increased annual fee). Once included, the subsidiary’s users consume the pool of licenses you’ve licensed (or unlimited if you negotiated an enterprise metric). Potentially more cost-effective if many users are involved. |
| Pros | Clear and direct – every external user is properly licensed. Easy to count and audit (each user has a license assignment). Good for small numbers of external users or temporary contractor access. | Makes the subsidiary’s usage “legit” without per-user micromanagement. Simplifies user management (no special external accounts, they use the system like any other employee). Can be cheaper and administratively easier if you have dozens or hundreds of users at the subsidiary – you avoid buying separate licenses for each. Strengthens compliance by aligning with corporate structure. |
| Cons/Risks | Management overhead if there are many external users (each needs tracking). Can become expensive at scale (hundreds of partner users = hundreds of licenses). Some external licenses might be restricted in functionality compared to full internal user licenses. Risk of forgetting to license a new contractor and falling out of compliance. | Requires negotiation with SAP – they may charge a premium or impose conditions to include another company. You must clearly define which entities are covered; if your corporate structure changes, you need to update the contract. If the subsidiary is not wholly owned, SAP might not agree to treat them as internal, forcing you back to partner licenses. |
Checklist: When extending SAP access to outside entities, check:
- Does your contract define “Named Users” to include all the affiliates or partners that need access (if not, do you need an amendment)?
- Have you licensed each third-party user who isn’t covered by the contract (e.g., through a partner license)?
- Are you monitoring user lists to catch external domains or IDs, ensuring that no external user accesses SAP without proper licensing?
Lessons Learned & Key Takeaways
Across these indirect access scenarios, a few common lessons emerge. First, early identification of indirect usage is critical. The companies that avoided major surprises were those that proactively mapped out their system interfaces and usage patterns.
By understanding where eCommerce orders, CRM data, IoT signals, or external users interact with your SAP, you can address licensing needs proactively instead of reacting after an audit.
Second, SAP’s newer Digital Access model can be a powerful tool to manage indirect use, but it requires careful planning and negotiation. Simply switching to document-based licensing without understanding your document volumes could lead to over- or under-licensing.
Successful enterprises forecast their transaction volumes (like yearly order counts or sensor messages) and negotiate appropriate bundles or discounts. They also utilize programs like DAAP to transition cost-effectively.
Third, bundling and caps are your friends. Many case studies demonstrate that negotiating a flat-rate or capped arrangement for high-volume scenarios (such as orders and IoT transactions) provides budget certainty and prevents runaway costs.
SAP is often willing to find a compromise if you present a clear growth plan – it’s better for both parties than a nasty audit fight later.
Finally, continuous monitoring and governance are essential. Indirect access isn’t a “set and forget” topic. Leading companies implement tools and processes to track document counts, integration usage, and new interfaces on a regular basis.
This ongoing vigilance means that if indirect usage spikes or a new interface launches, they catch it and adjust licenses or architecture accordingly, long before it becomes an issue.
Checklist: To wrap up, here are the key checks based on the above lessons:
- Have you mapped all forms of indirect access across your SAP landscape (integrations, third-party apps, APIs, users outside your core team)?
- Do you have a forecast of expected document volumes (e.g., transactions from web, IoT, etc.) for the next 1-3 years to inform your licensing needs?
- Does your SAP contract include clear terms on indirect use (who/what is covered) and agreed measurement tools or audit procedures to avoid ambiguity?
5 Actionable Next Steps
- Map All Integrations: Create an inventory of every system, portal, mobile app, and third-party interface that connects to SAP. Identify what data or transactions each one is handling.
- Estimate Document Volumes: For each integration, estimate the number of SAP documents or transactions it generates. This will help simulate costs under Digital Access and reveal where your biggest usage lies.
- Review Your Contracts: Retrieve your SAP licensing agreements and review the fine print regarding indirect usage. Note any vague areas or missing clauses – these are potential risk points that should be addressed in negotiations.
- Negotiate Protections: Engage with SAP (or your software vendor) to implement safeguards. This could involve negotiating an indirect usage clause, securing volume caps or fixed pricing for specific document types, or obtaining written waivers for certain scenarios.
- Implement Continuous Monitoring: Put tools or processes in place to track indirect usage in real time. This might involve using SAP’s audit reports or third-party monitoring software to watch document counts and interface activity. By continuously monitoring, you can detect any surge in indirect use and respond (such as license updates or technical changes) before it triggers an audit red flag.
Read about our SAP Digital Access Advisory Service.
