SAP UK v Diageo – an important ruling for customers with indirect access issues


SAP has just won in its SAP UK v Diageo test case determining the right of software vendors to charge license fees to users on indirect access to SAP generated data.

Justice statue with blue sky and white clouds © davis – Fotolia.comLate last week, a UK court ruled in favor of SAP in the case of SAP UK v Diageo. This is a rare occasion where SAP has chosen to take its efforts to secure license fees for what is commonly termed ‘indirect access’ through the legal system. I spent the weekend digesting the text of the ruling, which I found remarkably lucid and devoid of mind numbing legalese.

In the analysis that follows, I will avoid much of the technical detail, sticking to a relatively simple way to explain the problem and what the judge in this case determined.

How does indirect access arise?

The ‘indirect access’ issue has been a running sore among SAP customers for some years. Essentially it boils down to this: SAP wants paying additional license fees where a third party system accesses data generated by SAP systems. This normally happens through a machine-to-machine interface but will likely mean that users who are not licensed by SAP on the originating system get access to data generated by the SAP system, albeit inside the third party system. To that extent, those additional users are not necessarily aware that they are accessing SAP data.

Diageo represents a fairly typical case where SAP systems generate data that is subsequently fed into Salesforce systems for the purpose of self service by customers rather than routing via SAP systems to Diageo call center agents.

In order to win, SAP had to show that the terms and conditions of the contract with Diageo contained language which allows SAP to make an additional charge. The judge ruled that is the case. Diageo for its part argued that the manner in which the data was transferred to Salesforce meant that the SAP enabling technology was acting as a ‘gatekeeper’ for the data rather than providing a means to access the data by additional users.

The pertinent points in SAP UK v Diageo

The ruling goes through the pertinent contract terms and from my point of view  and regardless of any other argument, it seemed clear to me that SAP is on good ground. In defining a named user, (the basis upon which SAP can levy fees), the appropriate clause says that a named user is:

“…an individual representative (e.g. employee, agent, consultant, contractor) of the Customer, a Group Company, an Outsource Provider or a Supply Chain Third Party who is authorised to access the Software directly or indirectly (e.g. via the Internet or by means of a hand-held or third party device or system). The extent to which a Named User is authorised to use the Software depends upon his user category as set out in the schedule.”

In the ruling, the judge said:

“Only named users are authorised to use or access the mySAP ERP software directly or indirectly. Named user pricing is the only basis on which the mySAP ERP software was and is licensed to Diageo.”

So far so good. But the judge chose not to rule on the quantum of fees that apply in this case, saying that:

“In my judgment, there is no applicable named user category for the Connect customers… They do not have access to source or object code. They do not have access to the functionality provided by mySAP ERP in support of the wider operation of Diageo’s business. They access business process functions and information from the database for the purpose of ordering products and managing their own personal accounts only.”

You might be forgiven for asking that if the judge could not determine the user type from the list of types included in the contract than how could she rule in SAP’s favor? That may well be a question for appeal although the judge was equally clear that SAP’s original claim of some £54 million, based upon Diageo’s 5,800 customers who access via Salesforce (and hence to SAP data) was not sustainable.

The more fundamental problem for customers is that while software license contracts are usually written in terms that favor the licensor, the Diageo contract originated at a time when few people anticipated connecting SaaS applications to traditional on-premise applications provided by third parties.

SaaS land v on-premise pricing

In SaaS land, there were early debates about who owned what and specifically the data generated by SaaS systems. Over time, contract terms were refined to the point where it is generally understood that customers are licensing access to software but that the data held by the SaaS provider is owned by the customer. That still leaves open the question of what happens when one system attaches to another.

In the case of Salesforce, it operates a fairly straightforward model that puts the cost onus upon the third party ISV. In other words, if you or I choose to develop a system that runs on the and so take advantage of access to Salesforce generated data, then you’ll pay Salesforce an annual fee, usually based upon revenue. That eventually gets passed on to buyers but remains largely hidden to the buyer.

In the on-premise word, the situation is different and in SAP’s case, it prices a mixture of components but which always come back to the concept of the ‘named user.’ Unfortunately, that may not be the best way to license in an internet enabled SaaS world and, will likely get even more complex in an Internet of Things world. Why?

In the on-premises world, the number of users who have access to back office systems is often a modest fraction of the whole workforce. SaaS that delivers newer capability can readily put functionality into the hands of an extended group of users. In Diageo’s case, this included their customers. It is an example of what Phil Wainewright might term ‘frictionless enterprise.’

While the on-premises ERP world envisaged a full, end to end business process environment contained within a single system, it never fully delivered on that concept. It couldn’t and was never designed to achieve that goal anyway. All of which still leaves the problem of pricing for indirect access.

Buyer advocates speak up

Buyer advocates argue that companies like SAP are simply being greedy and that there needs to be an alternative regime in place that better reflects the realities of 21st century internet based operations. Constellation Research’s Chris Kanaracus for example said this of the judgment:

Constellation sides with the generally accepted industry parameters of indirect access, which should include the ability to process batch data; aggregate information into a data warehouse or other data store; access data for use in another system via data integration; and to enter data from a third party system.

The difficulty with Constellation and other arguments is that they are emotionally led and not necessarily rational. However, there is little denying the angst customers feel and which Kanaracus describes in the following terms:

Constellation believes that overreaching pursuit of additional money for indirect access fees is anti-customer, and at odds with the friendlier, easier-to-work-with image SAP has sought to project under the leadership of CEO Bill McDermott.

It’s also counterproductive in the long run, as more viable options to move off SAP ERP emerge from competitors. And needless to say, it’s horrible for a vendor’s public relations and at odds with today’s forward-thinking enterprise IT shops, which are looking to generate innovation and efficiencies through the combination of systems from multiple vendors—as Diageo did.

Vinnie Mirchandani, a long term and vociferous SAP critic goes further, believing that the decision may have important consequences:

If this emboldens SAP to become more aggressive in going after more customers, I am fairly certain it is going to accelerate the “coping strategies” – diversification away from SAP and partners – I have described in SAP Nation. Except that this time, they will also extricate SAP from the core. The reality in many SAP customers is that for all the talk of “wall to wall” coverage, the functionality actually delivered by SAP is pretty small. Lots of surround systems deliver the industry specific and other impactful functionality. Customers have tolerated SAP at the core, but the financial and emotional pain from constant threats of audits is a bit too much to bear.

Yes, it will cost those customers to migrate away from that core so in that sense it is “mutually assured destruction” for both sides.

Over the weekend, I took to Facebook to see what others have to say. The consensus view was that it is likely too hard, risky and costly for customers to rip and replace their SAP systems. Customers and SAP therefore need to come to an accommodation on this problem.

While I understand that argument, I am not quite as convinced – at least not in some cases. I have already seen examples where what would normally be considered ‘core’ ERP is being moved away from the hegemony of SAP and Oracle. Some (and it is only a few right now) customers are finding coping strategies, but it is far from easy at the center of large, central deployments where many years of development have been put into honing efficient business processes.

My take

SAP will want to tread carefully. They will have known that the initial claimed quantum was going to fail but if there is to be an agreed price for what amounts to data transfer, then it will need to be pennies on the pound/euro/dollar. It isn’t reasonable, let alone sustainable to expect customers to pony up large amounts, however useful that data access might be.

I discovered this over 10 years ago when trying to price a particular system that had POC, small, medium and large per user pricing models. In our case, we simply couldn’t price well on a named user basis for a system that was starting with 500 users but which expected to reach 135,000 users over time. We eventually found a compromise but it was far from ideal.

As far as I know, no-one has figured out a good way to price for this kind of scenario when taken in the context of a much broader reach of the data generated by back office systems for third party application usage or, in the future, IoT.

It is important to note that this case only affects Diageo in the UK. There may well be other cases lurking out there where CxO’s will be nervously poring over their contracts to assess potential risk. My sense is that the SAPUK & Ireland User Group needs to get involved in order to both establish who is at risk and formulate plans to address a problem which, far from going away, has taken a fresh turn.

Examining contracts may, of itself, not be enough. I have long complained about the dearth of good lawyers who can provide solid advice on this topic. To that extent, the providers – in this case SAP – have a distinct advantage in creating contracts that are not always scrutinized as well as they might be for terms that give the vendor an unfair advantage. And like it or not, when you sign a contract, that cements a position that can come bite you later on.

Finally; this case is not over and while Diageo may appeal, I expect SAP to endeavor to reach a settlement that doesn’t rancor.

UPDATE: I received the following statement from SAP UK & Ireland User Group in response to this story:

“This case highlights the growing concern around indirect access. It’s a topic we raised at our annual conference in November, calling on greater simplicity and clarity from SAP on what constitutes indirect usage and the implications for licensing. We have also warned all our members to be vigilant and consider their individual licensing positions. 

We are actively engaging with SAP at a global level as part of the SUGEN license charter team, and locally we have been running a number of events and webinars to help our members better understand the challenge and share best practice. However, clearly there is a lot of work to do, customers don’t like surprises and without greater clarity from SAP that is exactly what we could get. This is why we have two members of our board participating in the SUGEN charter and why we continue to raise the issue both globally and locally with SAP.”

Philip Adams, chairman UK & Ireland User Group

Clarification: A number of commenters are getting hung up on the ‘data’ and ‘ownership’ issues. These are important misconceptions because:

  1. The judge did not consider this is an issue about data but about software usage by certain individuals. This is a critically important point. This view may change if Diageo chooses to appeal.
  2. When you acquire software you are (usually) acquiring a perpetual license for a specific number of named users. Once you go beyond that number then the vendor is usually entitled to be paid an additional sum based upon whatever user type is specified in the contract. This point was not the subject of the judgment.

Image credit - Story image: © davis – fotolia, featured story image: @fotolia

Disclosure - SAP, Salesforce and Oracle are premier partners at time of writing

    Comments are closed.

    1. CD says:

      Hi Den,

      The use rights talk about “who is authorised to access the Software directly or indirectly”. I would suppose “software” includes the run-time database that is typically bundled with the ERP by SAP and supplied by SAP as part of their software.

      What happens if a client brings their own full use database licensed directly from the database vendor to the SAP ERP instance and accesses data from such database directly using database calls without going through SAP software? Would that still constitute indirect access from SAP perspective?

    2. says:

      This was a case where the underlying DB is Oracle. They used PI which makes sense in the context of needing to keep data in synch on both sides. There’s clearly a case for considering an intermediary hub but then the cost/benefit of maintaining yet another cog in an already brittle system may well not be worthwhile.

    3. says:

      The legal case was based on contract wording.

      The emerging question is: “what is the fair value for indirect access?” This is something that all enterprise software vendors need to consider in the web services era.

      1) It is clear that Diageo gains some value from indirect access in this case by having partners make orders directly rather than via the call centre.
      2) It is also clear that the functionality provided to partners is far less than that granted to “named users”.
      3) The value of SAP is enhanced through the integration with Salesforce in this case. The opposite view is also true – the value of Salesforce is also enhanced.
      4) The real value to Diageo for indirect access is related to efficiency and error reduction, so licensing based on value ought to consider the number of transactions processed rather than the number of users because the partner users are likely occasionally use the system. Occasional users or even concurrent users are more coherent licensing mechanisms than named users. This seems to be more in line with industry standards, although that might just be anecdotal.
      5) It’s a warning when enterprise software vendors only supports named users. This is also short-sighted because buyers will reduce the number of users that could get value as occasional users.
      6) The overall question of who should get paid for indirect access ought to consider the costs to Diageo to integrate the solution.
      7) SAP customers should note that the cost for 5,800 named licenses for indirect access is more than the cost to develop a single industry ERP application. In other words, a proper design and a similar budget could have enabled Diageo to write COTS software that could have been sold to partners. And, the 22.5% annual maintenance charges that SAP likes would handle software maintenance as well.

    4. Perhaps everyone concerned can let off the hook by offering concurrent access licensing for very large systems.

      Imagine for a moment a very small SaaS ERP vendor with 250,000 customers having 1 to 5 users. Assume 1 user for simplicity, spread across multiple time zones in Europe, UK, USA, South America and Asia. Probably looks similar to Diageo’s demographic employee profile. Accordingly only 25,000 are typically accessing the SaaS database at any one moment in time. Thus the important provisioning is concurrent database connections, not named users. Although telecoms math would say the system needs designing for “the busy hour” often 3x typical or 90,000 concurrent access (again not 250,000).

      Bottom line is named users belong to on-premises or low system seats, say up to 1000 users. Then concurrent licensing (that may be more expensive than named users) generally make more sense for modern business systems.

      Check Microsoft and Oracle’s licensing of SQL Server and Oracle DB.

    5. Den, most customers I deal with complain about the “entitlement” mindset that indirect access implies. SAP has had many chances with its own developed and acquired CRM, HRM, SRM and many areas to be the provider in many surround areas. Customers evaluated their offerings and decided to build their own or go with other vendors, and report SAP feels entitled to be compensated even after losing the opportunity. When SAP loses the 3rd, 5th, later straight opportunity at some customers it is a miracle they get invited again.

      I know people think I am tough on SAP. I am just the messenger of what customers have been saying for years. Indirect access has been one of the most toxic elements of the relationship with many customers

      What is shocking is how various user groups have abdicated their responsibility to push against something so many customers feel is unfair. And that SAP’s R&D has not woken up and called those customers where they repeatedly lose and ask what they need to do to make sure the next deal is locked up.

    6. Ced says:

      Hi Den,

      We have a SAP BO platform based on a MS SQL Server. For some reason we decided recently to add a Dataviz tool to our architecture (QV, Tableau, Power BI…pick one) and directly connect to SQL Server without accessing SAP BO. Are we in diageo situation or not?

      1. Nick says:

        Hi Ced,

        Be careful here … I assume you mean SAP BW on MS-SQL? If so, theoretically you would need the OpenHub distribution licence. It’s not a technical licence (although it does include the use of SAP BW OpenHub replication software), it’s more of a distribution licence.

        If you just have BO accessing the SQL Server (and the warehouse is populated via other non-SAP systems, then I think you are OK.

        Maybe worth checking out.

        (Disclaimer: I am merely offering my opinion based on my experience.)

        1. says:

          What Nick said +1 – but to the more general point, it is vital that customers fully understand the licenses they hold and the impact that indirect access might (or might not) have. Sadly, this often means a combination of consulting, legal and negotiation with SAP.

    7. Mark says:

      Long blog post on this case by Shaun Snapp by on LinkedIn –

    8. Shehryar says:

      I do agree with the judgment. Having written, sold, and maintained software for a living some time ago, I won’t be comfortable if someone put a UI layer on top of my product using the exposed APIs without compensating me for the additional usage and value being generated by my product. As highlighted in the article, it is not a case of accessing data only, rather business logic developed by SAP was in use by Diageo without paying the licensing fee for this usage. As per licensing agreement, they should pay. An amicable settlement with SAP is due in my view.

      1. Fran says:

        Shehryar, it depends what you are making.

        If your business is creating softare that companies (distributors, manufacturers, wholesalers) are going to use run their inventory and accounting, (like SAP) you should expect that they will probably run an ecommerce site or use a sales app to make orders.

        If you expect businesses to pay a $1,500-3,000 license fee (SAP BO) per each random customer that purchases on their site, your software will not sell, at all. It would be by nature, a non-option. Unsustainable.

        You are assuming that these guys built a UI layer over their complex ERP. They didn’t. They simply gave inventory information and pricing and sent orders direct to the ERP. Much like any ecommerce does. They didn’t use SAP’s search function, financial modules, etc. They didnt use any SAP functionality actually.

        What does this mean for ecommerce giants that run on SAP? Forget giants, what does this mean for small 10M revenue distirbutors with 1,000 clients that use their ecommerce site?

        SAP is no longer an option if you plan to run an ecommerce store.

        1. The giants have fostered the Apache Software foundation for e-commerce demand-driven systems.

          No surprises if another foundation builds the infrastructure for core ERP innovations

          IBM and Intel and R3 all have made significant open source contributions to Hyperledger … (

        2. Shehryar says:

          Thanks for your comments. This is where the commercial and legal departments, in addition to external advisory partners, bring value. If you are looking to run an e-commerce business and chose a 3rd party product to be the frontend for SAP ERP, you need to agree with SAP how you’ll pay for their part of the process which runs on SAP ERP. Diageo either misunderstood or chose to overlook the contract they had signed with SAP. If an amendment was needed, they should have made it in agreement with SAP. We don’t know what actually happened before a decision on using Salesforce as the frontend was made. I am simplifying the Salesforce element as that is not relevant to this conversation other than being the 3rd party system accessing SAP. It could be any other product.

          SAP are entitled to be paid for their part of the process as they coded it, and need to maintain it for the customers. If that part of the process failed, the customers would log a call with SAP to get it fixes. An engine license for SAP PI does not cover issues on SAP ERP.

          Reading data from SAP should not be charged in my view, unless some engines are being used to generate values being read. Writing data into SAP which uses business logic from SAP, should be charged. If you want, volume licensing deals for SAP, like transaction based rather than per user, are available in most cases. If not, the decision needs to be based on the total economic value offered by the solution and what is accepted by the business. You’ll run into the same issues with any supplier when it comes to consumption of data. They’ll try to charge you for it, some more some less.

          1. Fran says:

            Shehryar, we agree that the info they get out of SAP is not SAP dependent and should not be charged.

            A business can mantain prices lists on an excel sheet or on a separate database with a simple GUI.

            Obviously companies decide to store it in SAP because the system uses that static information (prices, busienss partners info) to THEN process the business logic.

            The thing is that this business logic only happens when there is a transaction. (order is placed, invoice is posted, journal entries are posted, etc) This is after the fact.

            The reason people buy SAP is because it processes this business logic well. Not because it read it from a database and gives you a nice GUI.

            SAP is basically telling its clients that their ERP is not built for using that information outside of the SAP infrstructure on an modern world/online businesses. If not that, then basically it’s telling anyone that needs a B2B/B2C commerce platform to sell products to look elsewhere. Last I found, that’s a pretty large part of all businesses.

            Are they really telling us that we cannot put systems in place to improve our sales process?

            Diageo literally just made a B2B app to allow customer to place order that WILL be processed by SAP later. The business logic will happen correctly, SAP will not need to give support for SAP. That’s why they have an API and strict guidelines.

            You can’t affect the SAP source code with it, so no, they will not conflit with SAP data. SAP is still their ERP.

            This is serious.

            One thing is taking benefit of all the SAP business logic to run a separate GUI to defraud license payments. Another thing is allowing your customers to place orders online and SAP expecting you to pay-up for each one of those customers. That’s absolutely crazy in 2017.

            ERP’s should use ecommerce as a selling point, not as a hinderance. Implementing an ecommerce project is expensive enough because it’s a completely separate platform with a different business logic.

            And please, 55 million? The only reason this is not downright laughable is because Diageo is a $10BN/year company. But this same $54 million would apply to a small 100m/ year distributor or clothing brand.

            Now I need to hire a good legal team to purchase a product that is among the most complicated and riskiest things a company can buy? Talk about adding friction to the buying process.

            This can be very, very simple to clarify. Yet, AP has decided to leave it as a surprise factor.

          2. Shehryar says:

            Hi Fran,

            “Are they really telling us that we cannot put systems in place to improve our sales process?”.

            Not really, all SAP are saying that as per the agreed contract between both parties, customers must pay license fee to SAP for both direct and indirect access. The value of the fee is in question here, not the validity.

            I am sure SAP would take the industry feedback on board to optimise its contracts and reflect the latest developments in the market. The API economy and XaaS models are certainly shifting ground for traditional ISVs. This was recognised by SAP some years ago and a lot of discussion has already taken place to position SAP for the future. There is definitely room for improvement as indirect access licensing does impact goodwill.

          3. Mathias Mond says:


            I broadly agree with you, however let’s try to dissect this a little further:

            (1) Agreed that writing data to SAP requires a license, especially because it usually involves triggering some SAP business logic (at the very least some data validation & permissions check).

            (2) We probably all agree that original customer data that the customer himself created, especially if it was created outside of SAP in the first place, belongs to the customer. An important question behind much of the argument in the Diageo case, and one that is never really explicitly exposed, seems to be if the customer has the right to export _all_ of his data out of SAP, or only data that has not been processed (or altered ?) by any SAP business logic ?
            In other words, does the process of manipulating data in SAP via standard (or custom) SAP business logic result in that data no longer exclusively being owned by the customer, with data ownership transferring to SAP ? If yes then SAP can rightfully require a customer to have a license even for reading data from SAP (mass data or atomic data).
            I find it a bit hard to make a case for this view, but the UK Diageo ruling unfortunately glosses over this point completely when the judge states in #98 “At each stage of these interactions, the Gen2 user is accessing or using mySAP ERP indirectly through SAP PI” – where the series of interactions just involves batch loading to and pulling from SAP, without direct user interaction. So she seems to imply that even the reading of a simple set of data in a 3rd party system is “indirect use” if the data was previously stored in SAP.
            I hope that this aspect will get clarified in case Diageo should appeal, otherwise it is food for thought for future discussions with SAP and other vendors.

            Let me say that I have sympathy for SAP’s position in general, but the monetary demand is clearly excessive. A software vendor rightfully requests their customers to have a valid license for any interactions that uses functionality of the software they have provided. However, I find it really difficult to come up with a hard and fast rule for all of the scenarios including the ones discussed above where we are entering grey areas. But now that the ruling is public it is high time that we in the software industry, including the customers, work towards a common understanding that could underpin the concept of fairly paying for the use of commercial software.

            I am leaving the question of the proper license type aside, that would be a different discussion.

    9. George Marble says:

      This is just the tip of the iceberg. IoT is what is lurking under the water. It will be very interesting to follow this going forward.

      1. says:

        We have raised that as a question going forward

    10. GA says:

      SAP UK and indeed Norhern EMEA has become extremely assertive in enforcing license audits and pursuing customers, over the last 2-3 years. The audit team is the fastest growing and one of the biggest contributing “sales” teams in SAP UK. They may well be legally correct, but one wonders how well this almost-adversarial stance sits with the global leadership who are touting Customer Empathy, Openess, Connectivity, amongst other core values. Any word from SAP executives on this yet?

      My other observation, as a recently departed SAP UK account director, is that the motivation for the above is very clearly about improving the competitive position when bidding for new projects in the cloud and non-core lines of business. It is not (primarily) about IP protection – that may well be the legal argument used, but indirect access is a sabre rattled by SAP sales managers wanting to create fear, uncertainty and doubt in the minds of any prospective customer considering Salesforce, Workday, etc. instead of SAP price list products.

      1. says:

        We have asked the question on behalf of users about SAP’s position on ‘choice.’

    11. says:

      SAP contracts contain numerous dormant or latent compliancy risks. Indirect Acess being one of them. @Fran, SAP will continue to sell, as SAP clearly dont illustrate the long term implications to their customers. Diageo paid for XI thinking that was enough. SAP would have sold XI knowing they only had to bide their time until the solution reached maturity (Global roll-out) and then comes the named-user sting, and the dormant volcano erupts. @GA I admire your honesty as from my experience SAP Audit is a revenue driving machine with customer care and satisfaction not a consideration. Typically deployed strategically as you alluded to. @Den Howlett and @Sheyrar, my firm has successfully defended against SAP’s Indirect Access claims through the principle of incremental value where the fee payable/suitable is agreed to be proportionate to the business benefit gained. You simply cant charge 54 million for the privaledge of moving sales and order functions from call centre to a web platform, when the total investment in SAP over 13 years amounts to 61 million. This is a very powerful concept particularly when SAP, deliberately to hide the risk, doesn’t make pricing for this type of usage clear as per the Diageo judge’s comments.

      1. Shehryar says:


        Thanks. Can you please clarify:

        “…my firm has successfully defended against SAP’s Indirect Access claims through the principle of incremental value where the fee payable/suitable is agreed to be proportionate to the business benefit gained….”

        Have you defended against the claims of indirect access through not paying or have you negotiated a lower price? If earlier, then your case can be used as a reference in Diageo’s case. If later, then I agree that SAP should reach at an amicable settlement with the customer. Once there is an agreement on the “Connect” user type by the judge, that will clarify matters also.

    12. Den Howlett says:

      All good…nothing new here….

    13. Brian Leapman says:

      Interesting thread of comments.
      Couple of quick thoughts.
      If a company is misleading in its selling, then it cannot make a claim after the fact for payment; so there could be a robust defence against SAP for any past claims on these grounds. It does not mean that for going forward that it would need to negotiate with each client, for services going forward.
      Second thought.
      In B2B pricing and product information is often shared through the use of Excel spreadsheets, which the receiver then manipulates into their own local systems (generally using their own Microsoft licence) Are their similar potential issues here? Similarly word documents, or powerpoint etc?

      1. says:

        That wasn’t the case here. The contract was clear. The second point is moot. Wasn’t a talking point.

    14. Mathias Mond says:

      This is an established model that indeed makes sense – but then you need to define what “run on” means. Clearly, that definition would not apply to the Diageo case, so the example doesn’t really help.Reference

    15. Ghengis says:

      Imagine I write an application that simply acts as an overlay/interface for all of the data housed in my ERP solution, and uses a service account to access that ERP. Now imagine that I gave all 10,000 of my employees access to this new interface, but did not give them accounts in my ERP application. When the ERP vendor does an audit of my systems, they will find only one account accessing the data – thousands of times a minute. Should they be concerned that I am only paying for one user license?

      1. says:

        This really goes to the question of the business model. Are we charging per user or some other measure in these scenarios. This is the question that SAP has to ask itself and then come up with an answer that leaves customers feeling they got a fair deal.

        1. SAP looks caught between two different business models ushered in by the shift from R/3 client-server computing to S/4 cloud computing. Handling unsupported access at the contract level almost always leaves everyone feeling equally screwed because usage changes but contracts don’t.

          We saw this coming by way of building e-commerce and a contact dispute with Redmond over database licenses. Settled by building a custom license server to administer contract prolongation down at the API level (lower than users). Although we had to support users concept for sales to sell.

          A multi-year detailed and invasive engineering implementation spanning very large code bases supporting hundreds of thousands of customers both on-premises and online. I think, “leaving customers [and sales] feeling they got a fair deal”.

      2. CD says:

        You bet they will be greatly concerned. In fact this kind of an arrangement would be seen as a deliberate attempt to defraud the ERP vendor. That could affect the settlement price for the worse when all this comes out in the audit.