CIO Playbook: Mitigating Indirect Access Risks in SAP ECC & S/4HANA

CIO Playbook: Mitigating Indirect Access Risks in SAP ECC & S/4HANA

Indirect Access Defined: Indirect (or “digital”) access refers to any scenario where SAP’s core (ECC or S/4HANA) is used by people or processes through a non-SAP application or interface.

In practice, this encompasses CRM/portal users, bots, IoT devices, and other devices that trigger SAP transactions without requiring a direct SAP login.

Under SAP’s licensing rules, any such use still counts as “use” of SAP software​.

In audits, SAP examines interfaces (RFC/API accounts, middleware, web services, etc.) and holds that if an external process triggers the ERP to “activate processing capabilities” (for example, creating or updating SAP documents), a license is required.

(One narrow exception is a true “static read”: e.g., a scheduled data export by a licensed user where no updates or triggers occur – SAP’s policy is that such strictly one-way reads do not require extra licenses​.)

Read SAP Indirect Access Licensing: What CIOs Need to Know.

Real-World Examples:

SAP considers many modern integrations as indirect access.

Common scenarios include:

• CRM/Portal to ERP: A sales team enters orders in Salesforce (or another CRM) that are automatically sent to SAP as sales orders. End users never interact with the SAP GUI, but SAP processes their orders.
• E-Commerce and B2B Portals: An online store or partner portal retrieves inventory and prices from SAP and posts new orders back into SAP. Shoppers or service reps drive SAP data indirectly.
• Warehouse & Logistics Systems: A WMS or barcode-scanning system queries SAP for stock levels or posts goods movements. For example, mobile barcode scanners update SAP inventory via middleware.
• HR/Payroll Systems: A cloud HR/payroll system updates employee or cost data in SAP’s HR module or vice versa. Changes flow through interfaces rather than SAP screens.
• Mobile/IoT/Partner Apps: Custom mobile apps or IoT devices (e.g., maintenance sensors, facility monitors) that use SAP APIs to create notifications or update asset data. RPA bots are a special case: if an RPA robot reads from or writes into SAP, SAP treats the bot user as an indirect user​.
• Finance Integrations: Third-party billing or treasury systems push invoices, payments, or journal entries into SAP. For instance, a bank integration that sends payment confirmations into SAP triggers the creation of new financial documents.

In each case, SAP’s position is that the external system is leveraging SAP’s intellectual property – the ERP is doing work on behalf of end users – and thus, licenses are due.

The infamous SAP vs. Diageo case (2017) reinforced this: a court held that Diageo’s Salesforce-driven orders constituted unauthorized use of SAP, exposing Diageo to significant fees.

Afterward, SAP introduced the Digital Access model to clarify billing; however, even under this model, every indirect business document created by an external system still incurs a charge (see below).

Legacy vs. Digital Access Licensing

SAP now offers two parallel models for indirect usage. In the legacy (user-based) model, every person or system account that directly or indirectly drives SAP is supposed to have a named user license.

In practice, this means that each CRM user, portal user, service account, RPA bot, and so on that triggers a license, such as Professional, Limited Professional, or Employee Self-Service, must be covered by SAP.

This model provides each licensed user with unlimited transactions; however, it is challenging to enforce, as companies often undercount, assign generic or middleware licenses, or only discover gaps at audit time. If a user’s license type is unknown, SAP typically assumes the most expensive (e.g., Professional)​.

By contrast, SAP’s Digital Access (document-based) model (introduced in 2018) charges only for business documents created in SAP by external systems. There are nine core document categories, including sales orders, purchase orders, invoices, deliveries, and service/maintenance orders.

Each time an external system creates one of these documents in SAP, it counts against the Digital Access license pool. Updates or reads of existing documents do not incur additional charges.

Bundles of documents are sold (e.g., blocks of 1,000) with volume discounts. This model eliminates the need to track every external user; instead, you focus on volumes of output.

Table 1. Licensing Models: Legacy vs. Digital Access

Under either model, CIOs must stay vigilant. Even with Digital Access, SAP expects customers to purchase sufficient entitlements for expected document growth. (SAP’s adoption program has offered incentives to switch, but you must accurately forecast document counts or risk overages.)

Governance Strategies for Indirect Access

• Inventory All Integrations: Build and maintain a catalog of every third-party system, interface, or API that connects to SAP​. Include middleware platforms, cloud services, batch feeds, EDI channels, mobile apps, etc. Record the purpose (e.g., “Order import from CRM”), the SAP technical users/accounts involved, and the business owners. This visibility is the foundation of control.
• Assign Ownership: Designate a license compliance owner, often part of IT/SAM or a CIO office, to oversee indirect access. That role should liaise with SAP Basis, security, and line‑of‑business leads. Maintain an Indirect Access Risk Register that lists each interface, its license risk (e.g., volume of use, unresolved license gaps), and mitigation status. Update it regularly as projects add or retire connections.
• Integrate into IT Governance: Make licensing impact a formal checkpoint for any new SAP integration or interface project. Require architects to assess license implications (named vs. document) during design reviews. For example, when adopting a new eCommerce platform or RPA solution, include a review of “SAP access licensing”. By baking indirect‑access checks into portfolio governance, you avoid surprises.
• Monitor Continuously: Don’t wait for SAP to audit you. Treat indirect access tracking as an ongoing internal audit and ITAM task. Regularly run SAP’s usage reports (USMM/LAW) and new notes/scripts to see which interfaces and technical users are active. Map each interface’s system ID to the SAP logs: If your CRM uses an RFC user named “CRM_INTERFACE,” check which transactions or documents it generates. Look for anomalies, such as very high document counts from a few service accounts.
• Document and Report: Maintain clear documentation of indirect flows (“System A creates X orders per month in SAP”). Use dashboards or reports (SAP or third-party tools) to track volumes by interface. These data help in audits or negotiations. For example, if SAP audits your system and inquires about “Salesforce orders,” you can present metrics and demonstrate that they were created under a block purchase. Also, ensure that all interface user accounts are properly classified in SAP (e.g., “Business” or “Application” types, rather than generic “human”) to ensure accurate reports.
• Establish Controls: Implement formal change control procedures for all new SAP integrations. New interfaces should only go live after license review and account provisioning. Educate project teams: emphasize that indirect access isn’t an “automatic free ride.” Update internal policies to state that adding any automated SAP feed requires oversight of licensing and compliance. This institutionalizes awareness and prevents unauthorized growth​.

Technical Controls and Monitoring

• Use Middleware/Hubs: Where possible, funnel all external connections through a centralized integration platform, such as SAP PI/PO, CPI, or MuleSoft. This allows you to govern and throttle usage in one place. For each distinct interface, create a dedicated service user account in SAP rather than using ad hoc IDs. That way, you know exactly which account corresponds to which upstream system.
• Segregate Accounts: Keep system or service accounts separate from human user IDs. In SAP, classify interface users as technical or “BI” users. Do not allow multiple people to share an SAP user account, and avoid enabling third-party apps to call SAP under individual named-user logins, as this defeats segmentation. Assign minimal roles to each service account: e.g., only the specific BAPI or OData calls needed. This reduces unnecessary document creation and makes auditing cleaner.
• Logging and Auditing: Enable extensive logging of interface activity. Many middleware tools let you log every call and response. In SAP, use the Audit Information System or solution manager to report on external RFC/API calls. SAP’s newer Passport technology (if available) can tag calls from non-SAP sources​. Log volumes and errors: A surge in API errors may indicate a misconfigured integration that is causing spam in SAP. Review these logs regularly for spikes in document creation or unauthorized access attempts.
• Monitor Performance: Use monitoring tools, such as SAP Cloud ALM for Integration Suite or third-party APM, to track integration flows. Unexpected increases in interface activity can signal the emergence of a new indirect-access hotspot. For example, if a batch job was mis-scheduled to run hourly instead of daily, you could be generating ten times the licensable documents.
• Technical Authorization Controls: Implement role-based security for service accounts as well. For example, when using a barcode scanner for inventory updates, give the scanner account only “Goods Movement” authorization, not full sales-order access. This prevents an interface from inadvertently triggering unrelated transactions.

Best Practices (Traditional/User Model)

For SAP customers still under a user‑license regime (not yet on Digital Access):

• Scope and Throttle Interfaces: Limit access to SAP data from external systems. For instance, configure the CRM so that only sales clerks can push orders, not all client-facing users. If a third-party system has multiple logins, consolidate or restrict them to only the ones needed. In practice, some customers license a small pool of “middleware” users to cover many indirect users – this approach can be effective, but it must align with SAP’s terms.
• Favour Asynchronous/Static Reads: Where real-time access isn’t needed, use scheduled exports. SAP allows Indirect Static Read scenarios without extra license if all criteria are met​ (data is pre-fetched by a licensed user on schedule, and no updates or triggers occur). For example, instead of a portal querying SAP in real-time, have SAP dump needed data nightly to the portal database. Carefully document these processes to demonstrate that they meet the static-read rules.
• Appropriate License Types: Assign SAP licenses to interface users carefully. If an external user only views data (e.g., via a portal), an SAP Employee Self-Service license might suffice. For integration users (like an RPA or scanner), you may need a “Service” or a minimal Professional license. Avoid defaulting to giving a full Professional license to all interface accounts.
• Eliminate Duplication: If a real person has an SAP license, there’s no need to license them again via a connector. For example, if an internal user logs in to SAP Fiori and also uses a connected mobile app, only one license is required. Remove any duplicate accounts. Conversely, if multiple people share a single service account, this violates the terms – a license should cover each indirect user who is using SAP data.
• Contractual Safeguards: Before renewing or expanding, negotiate clarity in contracts. Demand definitions of “indirect use” and carve-outs for static reads​. Ensure that old contracts don’t suddenly allow SAP to retroactively count documents. If you extend ECC or migrate to S/4HANA on-premises, ensure you lock in the terms for measuring or capping indirect access.
• Audit Readiness: Conduct regular internal license audits to ensure compliance. Simulate SAP’s audit (run USMM/LAW plus any indirect-use notes) and review for “smoking guns” (e.g., a small number of interface users generating huge volumes). Correct issues on your terms before SAP asks. In audits, be prepared to explain your architecture and have data available (“System X generates Y records per period, covered by Z license bucket”).

Best Practices (Digital Access Adoption)

For organizations that have (or plan to) adopt SAP’s Digital Access model:

• Track Document Consumption: Establish regular reporting on digital document volumes to monitor usage trends. Use SAP tools (LICENSE ADMINISTRATION WORKBENCH/LAW, usage reports, or the SAP Passport trace) to count how many Sales Orders, Purchase Orders, Delivery documents, etc., are created by interfaces. Create dashboards or reports that show trends by document type and integration source. (Remember, only the creation event counts – editing or querying a document does not trigger a new charge​).
• Know What Triggers Licenses: Understand which interactions generate billable documents. There are nine categories (e.g., sales, purchases, invoices, manufacturing orders, service orders, quality notifications, time confirmations, financial postings, and material documents). For example, posting a new invoice via a non-SAP billing app will be counted, but simply reading an invoice will not. Configure interfaces to avoid unnecessary document creation (e.g., don’t create duplicate documents “just in case”).
• Use SAP’s tools: Run SAP’s Digital Access Estimation or Passport tools (Notes 2992090 for ECC and 2999672 for S/4HANA) to measure usage. SAP also offers a free Digital Access Evaluation Service to estimate counts. However, treat these as starting points – validate their outputs internally before purchasing licenses. Be aware of tool limitations: for instance, older tools may not distinguish SAP-driven vs external documents, so cross-check your logs.
• Align Purchase to Usage: Only license the volume you need. If possible, utilize SAP’s adoption programs (e.g., past DAAP options) to purchase upfront blocks of documents, then track them against that block. Maintain a buffer to allow for growth, but avoid over-provisioning excessively. Negotiate with SAP to define what counts as a “document” in your context (some contracts allow excluding minor doc types or use flat tiers for predictability).
• Optimize Integrations: Even with digital access, limit unnecessary document creation. For example, if a system needs to check stock levels, design it to create a new Material Document or inquiry record only when necessary. Use custom code or middleware logic to aggregate transactions (e.g., batch creating one bulk purchase order instead of many small ones). Regularly review whether any interface is generating an unexpected document type.
• Regular Reviews and Audits: As in the legacy model, conduct quarterly or semiannual audits of interface activity. Ensure that any new interface or process that could create SAP records is evaluated for its impact on your digital licenses. Update your documentation (interface catalog) with any changes. If an unexpected spike in a document type occurs, investigate it immediately; it could signal a new integration or a bug.
• Educate Teams: Train developers and integrators on digital access. They should be aware of which SAP APIs or BAPIs generate billable documents. Encourage them to implement non-chargeable patterns whenever possible (e.g., read-only queries, static extracts) and to consult SAP licensing or architecture experts early in the design process.

CIO-Level Recommendations

• Treat Indirect Access as Enterprise Risk: Elevate indirect access to a board-level IT compliance topic, not just a technical detail. Include it in enterprise risk registers and compliance dashboards. Make sure C-level and finance leadership understand the potential exposure (audits can lead to multi-million-dollar demands). This ensures budget and attention are allocated to compliance efforts.
• Integrate with License Governance: Fold indirect-use management into your overall SAP license governance framework (alongside direct user licenses and engine metrics). Assign a specific owner (or team) with resources to track and manage it. Use automated tools (SAM software), if available, to continuously monitor your SAP estate. Standardize the process: e.g., whenever a new SAP user or interface is provisioned, update the license governance registry.
• Leverage Contracts Strategically: Use contract negotiation to reduce risk. When purchasing new SAP licenses or renewing maintenance, insist on clauses that protect you (e.g., caps on indirect usage fees, clear definitions, and static-read carve-outs). Secure rollback or exchange options (e.g., converting unused user licenses to document licenses)​. Do not agree to open-ended terms that allow SAP to charge heavily later. In short, negotiate with data: come prepared with usage reports and forecasts, not just faith.
• Collaborate Across IT and Business: Ensure tight coordination between SAP Basis, security, application teams, and the business units driving integrations. Form a steering committee or establish a regular touchpoint to review upcoming integration projects, digital transformation initiatives (including IoT, AI, and B2B portals), and their licensing implications. Involve procurement and legal in vendor evaluations (e.g., if selecting a new CRM or SCADA system that connects to SAP, assess license implications in the RFP).
• Invest in Tools and Expertise: Consider third-party audit tools or consulting to supplement in-house capabilities. Many enterprises use SAP License Management tools or engage SAP license specialists to discover hidden interfaces and recommend optimizations. These investments often pay off by avoiding penalties.
• Continuous Education and Training: Keep your organization up to date on SAP’s licensing changes. For example, SAP may alter its definition of indirect access or its DA pricing. Provide refresher training to IT architects and managers to prevent them from falling back into old assumptions. A well-informed team is your first line of defense.
• Maintain an Audit-Ready Stance: Before any SAP audit or license review, run your internal checks (“audit the auditor”)​. Have all documentation and usage data in order so that any issues can be explained and resolved collaboratively. If SAP sales or auditors initiate a discussion about indirect usage, enter negotiations with hard data and, if necessary, consult with legal or licensing counsel rather than going on the defensive.

By treating indirect access as a managed compliance program – with clear inventory, policies, monitoring, and executive oversight – CIOs can turn a potential audit risk into a predictable governance process.

The goal is not only to avoid surprise license bills but also to align SAP access rules with the company’s digital strategy, enabling innovation (e-commerce, IoT, automation) without incurring unexpected costs.

Read more about SAP Licensing Services.

Schedule a meeting with us to discuss our SAP Advisory Services.

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit