Skip to main content

Calling all SAP customers: here’s what you need to know about the new pricing model for Indirect Access

(Image credit: Image Credit: 360b / Shutterstock)

Last year, SAP famously pursued two of the world’s largest drinks companies - Anheuser-Busch InBev (AB InBev) and Diageo - for unpaid license costs. These widely publicised legal disputes have caused uproar within SAP’s wider customer base, who fear that they too could be hit by hidden or Indirect Access charges – and customers have every right to be concerned.

The risk of unpaid license costs is not something SAP customers can ignore. For example, AB InBev settled its licensing dispute for a whopping $600 million earlier this year. You may also remember that last year, a UK court ruled in SAP’s favour against Diageo, in which it claimed £54 million (US $70 million) in unpaid fees for Indirect Usage of SAP systems by third-party applications. The reality is, any SAP customer is as much at risk of falling victim to Indirect Access as Diageo and AB InBev.

So, how is SAP addressing the concerns of its user community following their legal crackdown on these high-profile customers? Well, unless you’ve been living under a rock for the past couple of months, you’ve probably heard about SAP’s new pricing model for Indirect Access. But what exactly is changing? How do you identify whether you have systems that enable users to indirectly access SAP?

Defining indirect access

Indirect access occurs when a non-SAP system triggers the creation of processes and documents within an SAP system. Until very recently, in the user-based indirect licensing model, just reading data from an SAP system in an interactive way constituted Indirect Access. For example, a system like Salesforce could trigger a sales order in SAP, or a purchase at Amazon could create an EDI (Electronic Data Interchange) document. Today however, Indirect Access is not considered to occur if the customer uses other SAP applications such as Fieldglass, Hybris, SuccessFactors, Concur or Ariba to access data from the main SAP system.

What exactly has changed?

More recent changes to SAP’s pricing model for Indirect Access come as little surprise following Bill McDermott's address (opens in new tab) at SAPphire last year. During his opening keynote, McDermott announced that SAP would like to change the policy around Indirect Access, specifically around two types of orders: procure-to-pay and order-to-cash. However, it was obvious that something was missing from McDermott’s presentation as it really doesn’t make sense to only count orders.

Fast forward to April 2018, and SAP has evolved the proposition, coming up with nine different objects that need to be counted. What we now see is a comprehensive pricing model for Indirect Access. The existing user-based license models – with the “platform user” as the designated license type in SAP’s price list – is being replaced in its present form. This new licensing model is designed to focus on the value added that SAP customers generate by creating certain documents in the SAP system.

Whether, and to what extent, these are advantageous for a customer cannot yet be assessed. The new model is difficult to evaluate, especially as the prices have yet to be fixed. But even were prices fixed, companies would first have to check whether switching to the new model would be worth their while. This is not an easy task, especially for organisations still using older versions or Service Packs from SAP. The SAP tools that help with the measurement might not be available for them.

SAP also snuck into recent announcements some changes in their internal organisation: the audit team is now separate from the sales team. This is likely to result in an increasing number of audits because the audit team is no longer dependent on the sales team, and their performance will be linked to the revenue generated from an audit and not from additional SAP sales.

With this increased reliance on audits to squeeze more money out of their customer base, SAP risks becoming increasingly unpopular among its customer base. Not wanting to draw too much attention to this situation probably explains why any talk of pricing models was conspicuous by its absence in McDermott's SAPphire keynote this year.

Getting to grips with the new pricing model

Companies with legacy contracts in which license fees for indirect access have not yet been created, as well as companies that still have contracts with SAP for user-based license types such as NetWeaver Foundation for third-party applications or platform users, should carefully examine whether the new regulation is advantageous or disadvantageous for their SAP landscapes.

It's a smart move for SAP, because in general, it will potentially make things a lot simpler: as SAP will provide a measurement tool that enables customers to check for themselves how many objects will be counted. Ultimately, even if it’s not cheaper than the old model, SAP’s customers may still prefer to move to the new model as it is more transparent.

Looking ahead

Businesses should look at what external systems are connected to the SAP environment, how many users are connected, and what they pay for each user depending on their specific license type. You will also need to consider the future direction of the company. For example, are more suppliers and customers likely to become networked in the future? The more data is exchanged, the higher the fees may be.

Using the new model, organisations can immediately use the new measurement routine, and based on what they can see make some small adjustments to their license allocation based on usage. As a consequence, they can see how much they will owe SAP. As the reporting is now transparent, SAP no longer has to replicate the customer’s analysis and the audit team will find it more straightforward to assess whether any true up is needed.   

However, I wouldn’t recommend existing SAP customers automatically adopt this new pricing model as whether it will benefit them depends on their specific situation. They should carefully assess whether they should move onto to this new model or stay with the old.

Joachim Paulini, Lead Architect, Snow Optimizer for SAP Software (opens in new tab)
Image Credit: 360b / Shutterstock

For more than a decade, Joachim has specialised in SAP. His practical experience covers development, consultancy, project management, SAP add-on development, software architecture design as well as implementing license management, contract management and Software Asset Management systems for a large number of major customers. He designed the Snow Optimizer for SAP Software and is leading its development.