Make Recognizing Indirect Access to SAP a Key Priority

SAP customers need to ensure that identifying and tackling Indirect Access risk is a key priority. So, what does Indirect Access entail, and how do you know if you’re exposed to the risk of fines? How do you identify whether you have systems which enable users to indirectly access SAP?

Last year, SAP famously pursued two of the world’s largest drinks companies for unpaid license costs. The court ruling against Diageo initially proved the legitimacy for SAP to charge for Indirect Access to SAP systems. At the time of writing we are aware Diageo is appealing this decision.

However with Anheuser Busch also declaring that the enterprise software giant is pursuing an arbitration process of up to $600 million, it is highly unlikely that SAP is going to change its stance at any point soon.

SAP customers need to ensure that identifying and tackling Indirect Access risk is a key priority. So, what does Indirect Access entail, and how do you know if you’re exposed to the risk of fines? How do you identify whether you have systems which enable users to indirectly access SAP?

Defining Indirect Access 

Amongst other methods, SAP customers pay per named-user licence. This grants their users access to the SAP system. The license type determines what actions they are entitled to perform and in which modules (HR for example). A named user license can vary from $70 up to $4,500. 

Indirect Access occurs when the SAP system is accessed or queried by a third-party or bespoke application. For example, anyone using a web interface that interacts with the SAP system through a third-party system, such as Salesforce, is indirectly accessing SAP. If that third-party system has the capability to read or manipulate the SAP data in any way, all authorized users of said system must have a named-user license.

Since it is now clear that SAP has the intention to audit customers for Indirect Access, it’s important to quickly discover where third-party and bespoke systems are accessing SAP so that you can mitigate the risk before you’re audited and caught out.

Post the court ruling in the UK, SAP customers felt increasingly anxious around the unpredictability of indirect access licensing fees and via the SAP users groups, they started to put pressure on SAP to provide clarity.

As a result, at last year’s SapphireNow Conference a new way of licensing for the Procure to Pay and Order to Cash scenarios was announced by Bill McDermott, SAP CEO.

SAP proposed to license P2P and O2C indirect access scenarios based on outcomes i.e. based on number of orders.


Although there will be systems which are immediately known to access SAP, in large organizations there can often be multiple stakeholders and administrators working on disparate parts of the system, so it can become impossible to identify all Indirect Access risk. The most effective way of identifying Indirect Access across the entire system is to monitor for behavior that is beyond the capability of a human user.

Until recently, however, identifying such anomalous behavior patterns has been a labour-intensive task, especially when managing multiple SAP systems. Fortunately, it’s now possible to automate much of this process by flagging indicators. 

Cross-component usage in miniscule timeframes and long work time should both raise flags, for example, as accessing multiple systems within a very short timeframe is unusual behaviour for a “real” user, and even the most conscientious of users tend not to work continuously without a break. Additionally, unusually large volumes of work should serve as an indicator, as any “named user” whose workload is significantly above average suggests activity being carried out by a third-party system. 

Once compiled, anomalous users should be linked to the third-party or bespoke system. Following this, one should identify which of them represent low and high financial exposure. Some access points, for example, may be system-to-system integrations that only involve internal SAP applications and, considered to be low to no financial exposure, can be discounted. 

The owners of the applications must be identified and interviewed to determine and document what an application is, what it does, and who its users are. By knowing this, the organization can validate the business case for each application. Does it really need to access SAP data in real time? If it does, users must be cross-checked against all SAP named users and establish whether they already have an SAP licence and, if so, the type of licence they have.


To avoid being hit with heavy audit penalties during 2018, you must have full visibility of your SAP estate, and scrutinize how all “users” use SAP. 

It’s imperative that, unless otherwise stated in their contract or as part of an amendment to the organization’s agreement, any individual who accesses SAP-stored data in real time, either directly or indirectly, must have an SAP Named User licence of the correct type provisioned for them. 

To be compliant, all users of a third-party application that indirectly accesses the SAP system must also have a Named User licence assigned to them or have appropriate licensing for the third-party usage i.e. license based on outcomes (orders), regardless of whether or not they need to access the SAP-held data. To avoid paying for licences they don’t require, organizations should reconfigure third-party applications so that access to SAP-stored data is partitioned off to only those who need it. 

Ignorance won’t shield anyone from the potentially severe consequences of Indirect Access, so it’s important that organizations take steps to address the matter now, before they too find themselves being pursued through the courts for unpaid licence costs.

 To understand how to gain full visibility of your SAP estate and understand how all ‘users’ human or otherwise use SAP why not read Snow’s eBook: Four Steps to Reduce SAP Indirect Access Risk.