Digital Access and Indirect Access

When you start thinking about RISE with SAP, GROW, or SAP Cloud ERP (Public/Private), an issue arises that often remains “under the radar” – until it becomes expensive: digital access or indirect access. This refers to access to SAP systems via third-party applications, interfaces, portals, bots, or automations, i.e., not via classic named users in SAP GUI/Fiori. The problem: Technically, this is often “just integration.” However, in terms of licensing, it can mean that transactions or documents in the SAP system are triggered by non-SAP systems – and that can be relevant for licensing (depending on the contract). If you check this too late, you may experience unpleasant surprises during audits, contract renewals, or cloud transitions. This article provides a clear, practical overview: What is indirect access, what is digital access, why is it particularly relevant in the cloud, and how can you take a structured approach to identifying, measuring, and effectively managing risks?

Contact us now!

Indirect access describes access to SAP functionality without a SAP user logging in directly, e.g. when:

• a CRM (not SAP) creates an order in SAP,

• an e-commerce store writes orders to SAP ERP,

• an MES/shop floor system posts feedback or material movements,

• a data lake/BI tool pulls or writes data,

• RPA/bots execute transactions.

Important: It is not a question of whether someone “uses SAP,” but rather how SAP functions are consumed. From a licensing perspective, it is precisely this indirect use that has historically been the focus of discussions, because classic named user models were originally built for a world in which “SAP = user logs into SAP.”

Digital Access is a licensing model that addresses indirect access via a document-based principle. Instead of licensing every indirect “user” according to named-user logic, the model looks – in simplified terms – at which business result objects (documents) are created in the SAP system when they are triggered by non-SAP applications.

The benefits (if implemented correctly):

• Better planning for integration and platform scenarios

• Clearer discussion of “business outcomes” instead of technical access paths

• Fewer gray areas than with a pure named-user approach

But: Digital Access is not a free pass. You need to know which document types count, how they are counted, and how to cleanly separate internal vs. external triggers – otherwise the BOM (license bill of materials) will be inaccurate.

In cloud programs, indirect access increases almost automatically because they are more integrated and automated:

• more APIs and event-based integrations,

• more side-by-side extensions (e.g., on SAP BTP),

• more self-service front ends (portals, apps, partner access),

• more automation (workflows, bots, integration flows).

In Public Edition in particular, “clean core” is often the goal: customizations are moved out into extensions and integrations. This makes sense from a technical standpoint – but in terms of licensing, you then need even more transparency about which processes external systems trigger in the SAP core.

If you are evaluating Cloud ERP, these pages will help provide context:

• Public Edition

• Private Edition

To make it more tangible, here are some examples that I see in almost every company:

1. E-commerce → SAP SDOrder is entered in the shop, SAP generates order/delivery/invoice.

2. 3rd-party CRM → SAPQuotes/opportunities trigger quote or order creation.

3. MES/IoT → SAP PP/MMConfirmations, goods receipts, and material movements are posted automatically.

4. Partner portal → SAPSuppliers or customers enter data that generates “real” business documents in SAP.

5. RPA/botsBots run through transactions at night and generate documents – technically “no user,” but relevant in terms of licensing.

If you want to set up integration architecture or interface management, this is a useful place to start:

• Business Process Integration

Named User typically licenses access to SAP functionality for one person (or one technical user).

Digital Access typically addresses the indirect triggering of business documents by external systems.

In practice, the crucial question is:

• “Do we license people, systems, or results?”

And that's exactly why you need a clean, program-controlled view:

• Role model and authorizations (user side),

• integration inventory (system side),

• document/transaction evaluation (outcome side).

If you want to solve the issue pragmatically, proceed in three waves:

This is where the most expensive mistakes happen in projects:

• “We have integration, so we're safe.”Integration is good from a technical standpoint – but in terms of licensing, it can generate new metrics.

• Non-prod is forgotten.Dev/test/sandbox and project peaks (cutover/hypercare) generate volume and access that must be taken into account in governance and contracts.

• RPA is underestimated. Bots can generate “more business outcomes” in a very short time than entire teams.

• Scope drift in the cloud transition. Today 20 interfaces, tomorrow 80 – if you don't set governance from the start, the BOM will be worthless after 6 months.

• Public/private is understood as black and white. In reality, you decide per domain. Digital access must reflect this reality, otherwise the licensing logic becomes contradictory.

For an overview of cloud ERP programs:

• SAP ERP Cloud / S/4HANA

How to remain capable of acting:

1. Establish an “Integration Design Authority”Each new interface is evaluated in terms of architecture and licensing.

2. Set up a clear role model + IAMNo uncontrolled growth of technical users, clear rules for partner access.

3. Document your extension strategyWhat stays in the core, what goes side-by-side – and what are the licensing/operational consequences?

4. Version your BOM like engineeringv0.9 Plan → v1.0 Contract → v1.1 Go-live → v1.2 Stabilization.This keeps digital access controllable.

5. Quarterly review as standardInterfaces, document volume, bots, new countries/processes. Not optional.

Indirect access is standard today because modern ERP landscapes are integrated, automated, and API-driven. Digital access can make this more predictable in terms of licensing, but only if you take transparency and governance seriously: interface inventory, document/outcome view, role model, and regular reviews. Setting this up properly early on protects your business case and compliance – and allows you to scale cloud ERP public or private in a much more relaxed manner.