Introduction – Why SAP Indirect Access Exists
Modern enterprises connect SAP systems with many third-party applications. SAP indirect access refers to situations where users, systems, or devices use SAP data or functions without directly logging into SAP.
In simple terms, if your SAP software is being triggered by an external tool or automation, that counts as indirect usage. SAP’s policy is that any use of its software – even via APIs or non-SAP interfaces – is access that may require a license. Read our ultimate guide, SAP Indirect Access: Understanding and Managing Indirect Usage Risks.
Why does SAP enforce indirect access fees? From SAP’s perspective, every time an external system processes data using SAP’s software, it creates business value. SAP believes this value should be licensed, even if no human user opened the SAP GUI. Indirect access has become a major audit trigger for SAP license compliance.
Framing Insight: Indirect access isn’t a technology problem – it’s a licensing strategy. SAP uses it to monetize integrations that customers assumed were free.
SAP’s Definition of Indirect Access
SAP defines “use” very broadly. Essentially, any user or system that initiates the processing of data in SAP may need a license. This covers reading, writing, or triggering transactions through any non-SAP interface.
A simple rule of thumb is: if an external system makes SAP do something (create or change data), SAP considers it a licensable event.
Not all interactions are treated equally. Simply viewing or extracting SAP data (read-only access) is typically allowed without extra licenses. However, creating or updating records in SAP via an external system is what raises red flags.
For example, pulling an SAP report into Excel is fine, but using a web app to create an SAP order is not.
Quick checklist to gauge indirect access risk:
- Does a third-party system connect to SAP (directly or via middleware)?
- Does it create or modify SAP data (transactions, records, etc.)?
- Are the users or devices behind it unlicensed in SAP?
If the integration writes to SAP and those initiators aren’t licensed, you likely have an indirect access scenario to manage.
Typical Indirect Access Scenarios
Indirect usage can creep into your landscape in many ways. Here are some common real-world examples:
- CRM integration (Salesforce, etc.): A cloud CRM like Salesforce is linked to SAP. When a deal closes in the CRM, it automatically creates a sales order in SAP. No one logged into SAP, yet an SAP order was generated – a classic indirect access scenario.
- Supplier or customer portal: An external vendor or customer portal sends data into SAP to create or update records. Those users never log into SAP, but their actions still trigger SAP transactions.
- IoT devices: Sensors or machines (IoT devices) send data to SAP, such as a sensor creating a maintenance order in SAP. A device (not a person) triggered SAP to record something, which SAP counts as usage.
- Robotic Process Automation (RPA): RPA bots that perform tasks in SAP (via scripts or APIs) act like virtual SAP users. SAP often insists that each bot needs a user license if it executes transactions in SAP.
In all these cases, SAP is doing work at the behest of something or someone outside of SAP. Auditors focus on the flow of data and transactions, not just interactive logins. In essence, if SAP’s engine is running due to an external input, SAP considers it a licensable event.
Why Indirect Access Is Controversial
Many customers argue they already paid for SAP and their other software, and being charged again for connecting those systems means paying twice.
SAP counters that any external user or system deriving value from SAP must be licensed. Vague contract terms fuel this disagreement – many contracts never explicitly define indirect use.
SAP’s Audit Focus – What They Look For
SAP audit teams are trained to sniff out indirect usage. During an audit, they typically examine:
- Interface connections: All external connections (APIs, middleware, etc.) to SAP are scrutinized. Any link to a CRM, e-commerce, or other system is a potential indirect use.
- Document creation: SAP checks who or what creates SAP documents (orders, invoices, etc.). If a technical account (not a named user) is creating documents, the team suspects an external system is behind it.
- System accounts: They look for SAP user IDs meant for integrations (e.g., containing “SYSTEM” or “RFC”). Heavy activity on such an account suggests an automated external process.
- Unusual volume: A spike in transactions or documents that doesn’t match human usage is a red flag. For example, if one background account posted tens of thousands of records, an external process is likely at work.
Beyond these clues, auditors will ask about common integration points: CRM software, e-commerce sites, supply chain or warehouse systems, HR platforms, and reporting tools. Any widely used external system in your landscape will prompt SAP to ask how it interfaces with SAP.
Audit trigger example: If SAP finds that an interface account (e.g., “RFC_USER”) created thousands of sales orders that weren’t linked to a named user license, they will flag it and likely issue a compliance claim for unlicensed SAP use.
How to detect SAP Indirect Access: Detecting Indirect Access in SAP: How to Find Hidden Licensing Risks.
The Financial and Contractual Impact
If SAP finds indirect use, they may demand back payment for unlicensed usage (a “true-up”).
In extreme cases, they might calculate several years’ worth of fees, leading to a shockingly large bill.
SAP calculates these fees based on licensing rules:
- Named user licenses: They might insist you purchase additional Named User licenses for every person or device that indirectly accessed SAP.
- Digital Access documents: Alternatively, SAP may count the business documents (orders, invoices, etc.) created by external systems under its Digital Access model and charge per document, or require a package of Digital Access licenses.
These claims can easily run into hundreds of thousands or even millions of dollars if, say, five years of Salesforce-to-SAP orders were unlicensed. However, SAP often prefers a negotiation over an outright bill.
They might encourage you to adopt the Digital Access model or move to a modern contract (like SAP’s cloud subscription) that includes these scenarios, rather than enforcing pure penalties.
For example, here are a couple of scenarios and how SAP might frame the charges:
| Scenario | What Triggers It | SAP’s Licensing Claim |
|---|---|---|
| Salesforce integration creates SAP orders | External write (CRM auto-creates orders in SAP) | Count each order under Digital Access, or require SAP user licenses for those Salesforce users. |
| IoT sensors posting to SAP | Automated input (device sends data into SAP) | Charge per document/event under Digital Access, or require a special license for high-volume IoT data. |
Financially, SAP may use the audit to push a deal rather than just demand money.
They might offer to waive some back charges if you agree to a licensing adjustment in the future (for instance, purchasing Digital Access licenses or moving to a new package).
The goal for SAP is often to turn compliance issues into a sales opportunity.
How to Identify Indirect Access in Your Landscape
To avoid surprises, proactively look for indirect access in your SAP environment. Use this simple framework:
- Inventory integrations: List every external system, application, or tool that connects to your SAP system.
- Flag write access: Mark which integrations only read data and which actually create or update data in SAP.
- Find trigger points: For each write-enabled integration, identify what it’s doing (e.g., creating sales orders, updating employee data).
- Identify the actors: Determine who/what initiates those actions – an internal user, an external partner, or a machine account. Are those actors already licensed in SAP?
- Check your contract: Review your SAP license agreements to see if these scenarios are covered. If the contract is silent on external use, assume SAP would require licenses for those activities.
What clauses should you negotiate? – SAP Indirect Access Contract Clauses: How to Protect Your Organization from Hidden Risks.
Avoiding Accidental Indirect Access
Preventive measures can save you from indirect access surprises. Consider this checklist:
- Maintain an integration log: Keep an updated record of all interfaces to SAP and their purpose.
- Favor read-only interfaces: Where possible, let external systems pull data from SAP but not push changes. Use data exports or a data warehouse for external reporting needs to avoid direct writes.
- Use middleware controls: Route third-party connections through a middleware platform that can log and throttle activity. This creates an extra layer of control and documentation for external access.
- Audit technical accounts regularly: Routinely review SAP background user IDs and system accounts. Make sure you know what each account does. Remove or lock any integrations that are not needed and verify that active ones are authorized.
- Clarify licensing in contracts: When negotiating with SAP, address indirect usage explicitly. For example, define rules for APIs, bots, or partner access. Getting it in writing can prevent disputes later.
By instituting these practices, you reduce the chance of unknowingly violating SAP’s rules. Make sure your IT teams understand that any system connecting to SAP must be evaluated for licensing impact, not just technical feasibility.
Example policy: “External applications may access SAP data for viewing/reporting only. No external system may create or update SAP transactions without a proper license check.”
5 Questions to Identify Indirect Access in Your SAP Landscape
- Do any external systems automatically create or update SAP records?
- Are third-party applications using SAP APIs or interfaces?
- Do external users or partners interact with SAP data indirectly?
- Are there SAP “system” user accounts not tied to real people with licenses?
- Have you reviewed your SAP integrations and license terms in the last year?
Read about our SAP Advisory Services
