Detecting Indirect Access in SAP – Why Early Detection Matters
Indirect use of SAP – often called indirect access or digital access – happens when SAP is accessed via third-party systems, APIs, or bots without a direct user login. These hidden interactions can create SAP documents or transactions behind the scenes.
If you don’t detect this activity early, SAP’s auditors will – and they’ll treat every unseen interface as a revenue opportunity for licensing fees. Early detection means fewer surprises, faster remediation, and better leverage in license negotiations.
In short, you can’t negotiate what you can’t see, so it’s critical to identify indirect usage before SAP does.
In the short term, finding indirect use protects you from compliance surprises. Read our ultimate guide, SAP Indirect Access: Understanding and Managing Indirect Usage Risks.
In the long term, it lets you shape the narrative during audits. SAP often begins audits by asking for a list of all third-party interfaces. Whoever controls that narrative is in a stronger position.
By proactively uncovering indirect usage, your team can address any licensing gaps on your own terms rather than scrambling under audit pressure.
Understanding What Constitutes Indirect Use Technically
In technical terms, indirect use means an external system triggers an action in SAP or creates documents without a person logging into SAP directly.
In other words, SAP is being used behind the scenes via an interface. Common examples include: an e-commerce portal pulling pricing data from SAP through an API, a CRM system like Salesforce pushing a new sales order into SAP, or a software robot (RPA) updating records in SAP automatically.
In all these cases, SAP is working for users who have never logged in via SAP GUI.
Typical interfaces that enable indirect use:
- RFC/BAPI calls: Remote Function Calls or BAPIs from external programs that execute SAP functions.
- IDocs: SAP’s Intermediate Documents, often used by middleware to post transactions (e.g., updating orders or sending invoices).
- Web APIs/OData services: REST or OData calls to SAP (for example, a web app querying SAP data).
- File imports/exports: Automated data loads into SAP from IoT sensors, CSV files, or external scheduling systems.
Common risk sources for indirect access:
- Middleware platforms – e.g. SAP PI/PO, MuleSoft, Dell Boomi – that shuttle data into SAP.
- External portals – supplier portals, HR self-service sites, e-commerce storefronts – that read or write SAP data.
- RPA bots or scripts – automated processes performing transactions in SAP without human intervention.
- Analytics and reporting tools – third-party BI tools or Excel macros pulling data from SAP.
Any of the above can generate SAP transactions or documents without a named user explicitly logged in.
Each of these scenarios might require a license under SAP’s rules (historically, named user licenses for anyone benefiting, or nowadays document licenses under Digital Access). The key is to uncover all these indirect paths in your environment.
Checklist: Common Indirect Access Paths
- SAP RFC user accounts are being used by external programs.
- External applications (CRM, portals) write data into SAP.
- Automated data loads from IoT devices, bots, or integrations.
- Third-party BI/reporting tools pulling large data sets from SAP.
- Any process where SAP data is consumed or updated without a direct SAP login.
Tools & Methods to Detect Indirect Use
Detecting indirect use requires digging into both SAP’s own audit tools and the logs of your integrations.
A strategic combination of SAP transactions and interface reviews will reveal where unseen consumption is happening.
SAP’s Own Tools for Indirect Use Detection:
SAP provides several administrative transactions that, while designed for general monitoring or license management, can help spot indirect usage patterns:
- USMM (User Measurement Tool): Run USMM to get a baseline of all users and license types in the system. While USMM by itself doesn’t flag indirect use, it identifies all active accounts. Look for generic or technical usernames here (for example, accounts named
RFC_USERorPORTAL_SRVC). These could be service accounts used by interfaces. - LAW (License Administration Workbench): LAW aggregates user license data across systems. After consolidating USMM data, check for any “communication” or “service” users in LAW results with significant document counts or usage. Such non-dialog users with high activity may indicate a background interface or a job doing work in SAP.
- ST03N (Workload Analysis): Use ST03N to view workload statistics and user activity. Focus on metrics like RFC calls, background tasks, and transactions executed by user ID. If an account that’s supposed to be a system interface is showing hundreds of transactions (e.g., VA01 create order) or a high number of RFC calls, that’s a red flag for indirect usage. ST03N can be filtered by user name or task type to find these anomalies.
- SM19/SM20 (Security Audit Log): If Security Audit Logging is enabled, it can trace events like RFC logins, external IP addresses connecting, and changes made by certain accounts. Analyze SM20 logs for unusual patterns, such as many logon entries from a particular external IP or events triggered by a technical user at odd hours. These logs can reveal which external hosts or systems are calling into SAP and what actions they perform.
Strategies for managing SAP Indirect Access, SAP Indirect Access Compliance Strategies: How to Stay Audit-Proof.
Integration Logs and Inventory Reviews:
Beyond SAP’s built-in tools, a thorough review of your integration landscape is necessary:
- Interface Inventory: Maintain an up-to-date list of every external system interfacing with SAP. This includes middleware connections, third-party applications, data feeds, etc. Check transaction SM59 for configured RFC destinations and external connections. Compare this inventory to what’s actually happening in the system.
- Middleware & API Logs: Look into logs from middleware (SAP PI/PO, integration hubs) and any SAP gateway or API management platform. These logs show which interfaces have been calling SAP, how often, and if they encountered errors. For example, SAP PI might have interface monitoring that records every IDoc sent to SAP and its status.
- Transaction Code Analysis: Identify what transaction codes or function modules system accounts are executing. Tools like SE37 (for function modules) or the analysis of ST03N data can show if an account is calling functions like BAPI_SALESORDER_CREATE or posting IDocs. A technical user running transaction codes meant for business users is a strong indicator of indirect activity.
- SU01 User Type Review: List out all users in the system (SU01 or SUIM) and filter for non-dialog users (system, communication, etc.). These accounts should typically be for interfaces or background processes. Ensure each has a known purpose. If a “system” user is creating sales orders or invoices, it might be considered indirect use that requires a license.
- Interview and Confirm: Sometimes you need to go old-school. Talk to integration owners and application teams. Ask: “Does your interface create or update anything in SAP? How many records per day?” These conversations often uncover shadow integrations or small tools (like a script or Excel macro using an OData service) that don’t show up in big system logs but still count as indirect usage.
By combining SAP’s tools with external checks, you build a 360° view of indirect access. Think of it as performing an internal SAP interface audit. You’re gathering evidence of every system-to-SAP interaction.
Checklist: Indirect Use Data Points to Examine
- RFC/BAPI call volumes per external system (from ST03N or STAD logs).
- IDoc exchange frequency and which external systems are sending/receiving (from PI/PO monitors or SAP transaction WE02/WE05 for IDoc logs).
- Background job activities and their executing user IDs (SM37 for batch jobs – are any interface accounts running scheduled jobs?).
- Non-human user accounts (system/communication users in SU01) are involved in transaction execution or document creation.
- Source IPs/hosts in logs (SM20 or ST03N can sometimes reveal the originating IP of external calls) to identify external systems hitting SAP.
Mapping Your SAP Integration Landscape
To stay ahead of SAP auditors, document your entire SAP integration landscape. Start by listing all systems connected to SAP: CRM, e-commerce, warehouse management, HR systems, supplier portals, BI tools, etc.
For each, classify the integration’s nature and risk:
- Integration type: Is it an API call, an IDoc message, a direct database link, or a batch file import?
- Data direction: Is it read-only (pulling data from SAP), write (pushing data into SAP), or bi-directional?
- Transactional impact: Does it just query data or actually create/update transactions in SAP (like creating orders, changing records)?
- Trigger and users: Who or what initiates the process – an internal user, an external partner, or an automated schedule?
Next, diagram the data flow for each interface: e.g. External System A → Middleware → SAP → outcome. Note what gets created or updated in SAP and how that data is used. This exercise helps pinpoint which integrations carry indirect usage risk (especially those that create documents).
Below is an example of an integration map with risk assessment:
| External System | Integration Type | Action in SAP | Risk Level |
|---|---|---|---|
| Salesforce CRM | API via PI | Creates sales orders | High |
| Vendor Portal | IDoc | Updates delivery status | Medium |
| Power BI Dashboard | OData (read-only) | Extracts SAP report data | Low |
SAP calls every system-to-system handshake a potential revenue event — classify yours before they do.
High-risk integrations (those creating SAP documents or updating critical data) are likely to draw auditor attention and may require additional licensing (e.g., SAP’s digital access documents).
Low-risk ones (read-only queries, very low volume interactions) are less likely to incur fees under current rules, but you should still log them.
By mapping out all interfaces and categorizing their risk, you create your own indirect use register.
This becomes your reference when SAP asks, “Do you have any interfaces to non-SAP systems?” You can confidently answer and provide details, showing that you are on top of it.
What clauses should you negotiate? – SAP Indirect Access Contract Clauses: How to Protect Your Organization from Hidden Risks.
How SAP Auditors Detect Indirect Use
When SAP’s audit team comes in, they are increasingly savvy about indirect access.
Typically, their process to uncover indirect usage looks like this:
- Request architecture and interface documentation: They will ask for diagrams or lists of all systems interfacing with SAP. If you provide a clean integration inventory (as above), it sets a positive tone. If you don’t have one, auditors will dig deeper on their own.
- Review system connections and logs: Auditors often request output from USMM and LAW. They look for discrepancies, like users that exist in the system but weren’t declared in the LAW report. A common red flag is a service account with high transaction counts that wasn’t listed as a dialog user.
- Analyze RFC connections and background users: Auditors may ask for a list of RFC destinations (SM59) or active integrations. They’ll check if any technical user accounts (like interface users) have been executing a lot of transactions. They might correlate SAP workload statistics (ST03N data) with your interface list. If an interface isn’t declared but ST03N shows significant activity from a technical user, expect questions.
- Correlate data volume to licensing: If an external interface is creating thousands of SAP documents (sales orders, invoices, etc.), auditors will estimate the associated license cost. Under the digital access model, they might calculate how many documents were created indirectly. This could translate into a hefty bill if those documents aren’t licensed.
Red flags that SAP auditors look for during indirect use reviews include:
- Service or technical accounts with unusually high transaction volumes (e.g., an account that ran 10,000 transactions last month).
- IDocs or transactions in SAP that were triggered by external IP addresses or hosts (indicating an external system feeding data).
- Users or activities in SAP’s logs that don’t appear in official license counts (suggesting undeclared usage).
- Unmapped interfaces – integrations not documented in the architecture diagrams but evident from log data.
If auditors find these, they will assume you have indirect usage that needs licensing. By knowing these red flags yourself, you can address them proactively.
Building an Internal Indirect Use Detection Routine
Detecting indirect access isn’t a one-time project – it should be an ongoing part of your SAP compliance routine.
Here’s how to set up a self-audit playbook for continuous monitoring:
Self-Audit Steps:
- Run USMM and LAW regularly: Do a quarterly user count (USMM) and aggregate with LAW. This keeps your named user inventory up to date. Investigate any unknown accounts or spikes in user counts immediately.
- Review RFC/IDoc logs: Each month, check system logs (ST03N workload, SM21 system log, or STAD) for external activity. Identify which accounts or interfaces are busiest. For example, if an interface user suddenly processed 5000 IDocs in a week, it is important to find out why.
- Cross-check integrations: Compare the active connections you see in logs with your documented integration list. If something shows up in logs that’s not on your list, track it down. There may be an unofficial integration or a new tool someone enabled without telling IT.
- Interview system owners: Speak with owners of each integration or interface periodically. Confirm that the data flow and usage frequency haven’t changed. This human touch can reveal changes (like a partner increasing order volumes, or a new reporting script) that might not be obvious from system logs alone.
- Log and classify indirect usage: Maintain an internal log or spreadsheet of all indirect usage instances you identify. For each interface or technical user, note what type of activity it performs and assign a risk level (as done in your integration map). This log will be invaluable for compliance reviews and audit preparation.
Ongoing Maintenance:
- Quarterly compliance checks: Dedicate time every quarter to run through the above steps. Regular audits ensure any new indirect usage is caught early.
- Change control for integrations: Institute a policy that no new system-to-SAP interface goes live without a licensing impact review. Make it part of your change management to involve the license compliance team whenever an integration is added or modified.
- Keep evidence and history: Document your findings and actions. Keep an audit log of what indirect usages were found and how they were addressed (licensed properly, re-architected, or retired). This history shows a pattern of compliance if you ever need to demonstrate it.
- Stay educated on SAP rules: SAP’s indirect access policies can evolve (for example, the shift to digital access licensing). Keep your team updated on the latest SAP licensing notes or changes, so your detection criteria remain current.
Policy example: “No system-to-SAP integration shall be activated without a compliance review of its licensing implications.” Enforcing such a rule helps prevent untracked indirect usage from slipping in under the radar.
With a routine like this, indirect use will go from a hidden risk to a well-managed aspect of your SAP environment. It turns surprises into planned events. When SAP’s auditors come knocking, you won’t be scrambling; you’ll be presenting a binder of your own audit findings.
Reporting Findings & Next Steps
After detecting and analyzing indirect usage, the final step is to report your findings internally and take action.
Compile a report or dashboard that includes:
- Summary of all interfaces and indirect use cases: A list of each third-party system interfacing with SAP, along with what it does.
- Risk categorization: Label each interface or usage as High, Medium, or Low risk (based on volume and type of data/actions). For example, “Salesforce – High risk (creates orders)” or “BI Tool – Low risk (read-only queries)”.
- Estimated licensing impact: For each high or medium-risk interface, estimate what license requirement it might trigger. This could be the number of digital documents created or the number of users indirectly using SAP. You don’t need exact figures, but a ballpark helps prioritize. E.g., “Portal X creates ~2000 sales orders/year → likely requires digital access documents or 1 professional user license per external user.”
- Remediation or mitigation plan: Outline what you’ll do about each indirect use case. Options include purchasing additional licenses (or adjusting license types), technical changes (like switching to an SAP-delivered interface that might be covered under existing licenses), or negotiating terms with SAP in the next agreement. In some cases, you might restrict or turn off an integration until it’s properly licensed.
Share this report with IT leadership, SAM (Software Asset Management) teams, and relevant business stakeholders.
The goal is to decide on the next steps before an external audit forces the issue.
Perhaps you’ll true-up some licenses in advance, or maybe you’ll approach SAP to discuss moving to a different licensing model (such as SAP’s digital access document licensing) if it makes more sense given your usage patterns.
Finally, use your findings during SAP renewal or audit discussions. Showing SAP that you actively monitor and manage indirect use demonstrates good faith and can improve your credibility.
It signals that you’re not hiding usage; on the contrary, you’re on top of it. That often leads to more collaborative negotiations rather than punitive audits.
Remember, the best audit defense is an internal audit you run first. By reporting and addressing issues internally, you remove the element of surprise and maintain control over the outcome.
5 Steps to Detect Indirect Access Before SAP Does
- Monitor technical logs monthly: Proactively review SAP workload and security logs (ST03N, STAD, SM20) every month for signs of external activity. Regular log scrutiny will spotlight any system or user making remote calls or creating documents in SAP behind the scenes.
- Map and document all integrations: Maintain a living map of every SAP integration. Continuously update it with new interfaces or changes, documenting data flows and identifying if each is read-only or creates transactions. This SAP interface audit document ensures no connection goes unnoticed.
- Identify unlicensed system users: Use SAP user reports to find accounts that are not assigned licenses (e.g., communication users) but are performing work. Any indirect user identification like this should be flagged – determine who or what is using that account and why.
- Review with compliance and legal teams: For each indirect use case discovered, involve your licensing experts. Determine if the activity is covered under existing licenses or if you need to adjust contracts. It’s better to clarify licensing needs now than during an audit penalty phase.
- Update compliance reports quarterly: Treat indirect usage as a key part of your SAM compliance reporting. Every quarter, refresh your indirect usage report and send it to stakeholders. Consistent updates ensure that when SAP comes knocking, you have a recent, data-backed story to tell and a plan in hand.
Read about our SAP Advisory Services
