
Key Components of SAP Licensing for CIOs and CTOs
SAP’s licensing framework is notoriously complex, blending various user types, add-on “engine” metrics, and contract models that can significantly impact IT budgets.
CIOs and CTOs must understand the key components of SAP licensing, including named user licenses, package licenses, cloud subscriptions, indirect access, and support terms, to optimize costs and avoid compliance pitfalls.
This executive guide breaks down the major SAP license elements and offers real-world examples to help technology leaders navigate negotiations and manage their SAP estate effectively.
Named User Licenses and Types
The foundation of SAP licensing is the named user license. Every individual who accesses SAP software needs a specific user license type aligned to their role and usage.
Common user license categories include:
- Professional User – Full unrestricted access across SAP modules. This is the most powerful (and most expensive) user license, designed for power users such as system administrators or senior analysts. SAP auditors often classify any undefined usage as Professional by default, so these should be assigned sparingly where truly required.
- Limited/Functional User – A role-based license with narrower permissions. Sometimes referred to as “Functional” or “Worker” users in S/4HANA contracts, these roles allow a subset of the capabilities of a Professional user. For example, a procurement clerk or HR specialist might only need limited functionality. Limited users are offered at a lower price than Professional users due to their more restricted scope.
- Employee Self-Service (ESS) User – A low-cost license for basic self-service tasks by employees. ESS users can perform personal activities, such as entering timesheets, viewing pay stubs, or filing expense reports, but cannot transact on behalf of others. Large organizations assign ESS licenses to thousands of employees, enabling self-service without requiring full licenses for each person.
- Developer User – A specialized license for technical staff who build or customize SAP (e.g., ABAP developers, basis administrators). Developer licenses grant deep access to development tools and are often priced on par with or higher than Professional licenses, given their broad authorizations. Only those actively developing or maintaining the system should have these.
Rightsizing user licenses is critical.
Regularly audit how each user uses SAP and match them to the appropriate license tier. For instance, not every finance team member requires a Professional license if they only run reports – they could be downgraded to a less expensive user type.
One company discovered 30% of their users were over-licensed; by reassigning many to lower-cost licenses, they saved hundreds of thousands of dollars annually in maintenance fees.
Cost Example:
SAP’s price list is not publicly available; however, a Professional Named User license can cost around $2,500–$3,000 each, while a limited user license may be roughly half that price. ESS licenses are a small fraction (perhaps 5–10%) of a Professional user’s cost.
These are one-time license fees for on-premise software, to which annual support of ~22% is added.
For example, 100 unused Professional licenses purchased “just in case” at $2,500 each would tie up $ 250,000 in shelfware, plus approximately $ 50,000 per year in support fees that deliver no value. This illustrates why aligning license types with actual needs – and eliminating or reallocating shelfware – is crucial for cost optimization.
Table: Common SAP User License Types and Approximate Costs
License Type | Typical Use Case | Approx. One-Time Cost (List)¹ |
---|---|---|
Professional User | Broad, unrestricted “power user” (e.g. controllers, IT admins) | ~$3,000 per user license |
Limited/Functional User | Specific functional role (e.g. clerk, analyst with limited scope) | ~$1,200–$1,500 per user |
Self-Service (ESS) User | Self-service only (own data entry, time, HR self-service) | ~$150–$300 per user |
Developer User | Developers/technical administrators (deep system access) | ~$3,000+ per user |
<small>¹ List prices are ballpark estimates; actual negotiated prices may vary. Annual maintenance (≈20–22%) is additional.</small>
Package and Engine Licensing
In parallel to user licenses, SAP sells packages or “engine” licenses for specific software components and modules.
If named user licenses are the keys for individual access, engine licenses are like permits to use certain SAP functionalities or capacities.
- What Are Engines? An engine (or package) is an SAP product or technical component (for example, SAP HANA database, SAP Payroll, Extended Warehouse Management, etc.) that is licensed based on a usage metric rather than per user. Engines grant the rights to use that particular feature up to a certain capacity.
- Common Metrics: Each engine has a defined metric aligned to its business use. SAP’s catalog includes hundreds of metrics – examples include number of employees (for HR or payroll modules), annual revenue (for sales or ERP financial engines), number of orders processed, or database size (for SAP HANA, typically licensed per 64GB of memory blocks). For instance, an SAP Invoice Management engine might be sold in blocks of 1,000 invoices per year; if each block costs a few hundred dollars, buying 500 blocks (~500,000 invoices capacity) could cost on the order of $125,000.
- Dual Licensing (Users + Engines): Purchasing an engine license does not eliminate the need for user licenses. Both layers work together. For example, you might license the SAP Payroll engine for up to 5,000 employees (the engine metric). However, the HR clerks and payroll administrators who operate the payroll system still each need a named user license to use SAP. Think of the engine license as the capacity, and user licenses as the keys that grant access to that capacity. When budgeting for a new SAP module, account for both the engine cost and the requisite user licenses.
- Shelfware and Overage: It’s common for companies to end up with underused engines – e.g. owning rights for far more transactions or volume than they use (shelfware). Conversely, if usage exceeds the licensed metric (for example, if you process more employees or orders than licensed), it can trigger compliance issues and hefty true-up fees during an audit. It’s wise to regularly measure engine usage against entitlements. If an engine is consistently underutilized, consider negotiating a reduction or swap at renewal (if contract terms allow) to avoid paying maintenance on unused capacity. If usage is growing, proactively increase your licensed metric or negotiate flexible headroom to stay compliant.
Real-world example: A manufacturer licensed an SAP production planning engine for an assumed volume of 100,000 finished products/year.
After business changes, they only produced 50,000, meaning half the licensed capacity went unused.
At renewal, the CIO negotiated with SAP to exchange the excess engine capacity for other necessary licenses, thereby avoiding waste and improving ROI. Lesson: Track actual usage vs. licensed volume and leverage that data in discussions with SAP.
Perpetual vs. Subscription License Models
SAP offers multiple licensing models, which affect how you pay and the flexibility of your contract.
The two primary models are perpetual licenses and subscription licenses, plus hybrid options:
- Perpetual Licenses (On-Premise): A one-time purchase that grants the right to use the software indefinitely. This traditional model for SAP on-premise software involves a large upfront license fee, after which you pay annual maintenance (typically ~20–22% of the license value) for support and updates. Perpetual licenses are treated as capital assets – you own the usage rights outright. You can continue using the software even if you stop paying maintenance (though you’d forego upgrades and support). The downside is the high initial cost and the ongoing maintenance that, over the years, can exceed the original license cost. For example, a $1 million license purchase will typically cost ~$200k per year in support, meaning after five years, you’ve paid another $1M in maintenance.
- Subscription Licenses (Cloud or Term-Based): A recurring subscription (annual or quarterly fees) to use the software for a defined term. This model is standard for SAP’s cloud offerings and newer programs, such as RISE with SAP. Subscription licensing is an Opex (operational expense) model that bundles software rights and support services together. If you stop renewing, your rights to use the software end. Subscriptions offer more flexibility – you can often adjust user counts or modules at each renewal, and you avoid a large upfront spend. However, over a long period, subscriptions can end up costing more than a one-time perpetual license (analogous to leasing vs. buying). It’s essential to consider the 5- to 10-year total cost of ownership. A cloud subscription may appear cheaper in year one but could surpass on-premise costs by year five if not negotiated effectively.
- Term Licenses (Temporary Use): In some cases, SAP provides time-limited licenses for on-premises software (sometimes referred to as Temporary Use Licenses or TULs). For example, a 3-year license for a module might be priced at a fraction of the perpetual price. This essentially involves renting the software on-premise for a specified period. Term licenses can be useful for short projects, pilots, or transitional periods (such as during migration to a new system). At the end of the term, you must either renew, convert to perpetual, or stop using the software. Always clarify whether a quote is for a perpetual or term license – the long-term cost implications differ significantly.
Contract Considerations: With perpetual models, you’re often locked into paying maintenance if you want continued support (which tends to rise 3-4% per year).
With subscription models, you have built-in renewal points where you can potentially renegotiate or walk away (e.g., after a 3-year cloud contract, you could switch vendors or drop a service if it’s not delivering value).
Each model has advantages: perpetual gives you more control and a lasting asset, while subscription gives flexibility and includes infrastructure/hosting in the case of SaaS.
Many enterprises use a mix, keeping core ERP on-premise (perpetual) while adopting subscriptions for new cloud modules.
S/4HANA and New Licensing Concepts
SAP’s flagship ERP, S/4HANA, introduced some new licensing approaches to simplify the landscape and encourage customers to migrate from older SAP ECC systems:
- Simplified Package Bundles: In S/4HANA on-premise, SAP consolidated many formerly separate modules into the core S/4HANA Enterprise Management license. This means the base S/4 license covers a broad set of ERP functions that might have been à la carte add-ons in the past. However, certain advanced capabilities (like extended warehouse management, advanced planning, etc.) still require separate licenses or an “extended” edition of S/4HANA. If you are converting from ECC, you’ll need to map your existing licenses to S/4HANA equivalents. SAP provides conversion guides, but they can be complex – you must ensure that all the functionality you rely on is covered under the new S/4 contract (either included in the base contract or via additional licenses).
- Full Usage Equivalents (FUE): For S/4HANA Cloud deployments (especially under RISE with SAP), SAP introduced the FUE metric. Instead of buying fixed counts of each user type, you purchase a pool of “full usage equivalent” units. Different user roles consume different fractions of an FUE. For example, 1 Professional user might equal 1.0 FUE, a Functional user 0.2 FUE, and a Self-Service user 0.033 FUE. If you contract for, say, 100 FUEs, you can cover a variety of users as long as the weighted total remains within 100. This model gives flexibility to adjust the mix of user types without needing contract changes for each minor role change. Essentially, it bundles all users into one metric where heavy users “cost” more units and light users less. CIOs should ensure they understand the FUE conversion formulas and monitor how user counts translate into FUE consumption over time.
- RISE with SAP (Subscription Bundle): RISE is an all-in-one offering (introduced in 2021) where SAP provides S/4HANA as a service, including cloud infrastructure and managed services, under a single subscription contract. In a RISE deal, you typically commit to a certain number of FUEs per year rather than buying software licenses outright. The subscription includes the S/4HANA software, the HANA database, hosting (in SAP’s cloud or hyperscaler of choice), and basic technical support. The appeal is a simplified, cloud-like experience and one hand to shake for service. However, CIOs should weigh the trade-offs: RISE contracts are usually 3-5 year commitments and can carry a premium. You may lose some flexibility (since SAP is running the show end-to-end), and you’re essentially “locked in” to SAP’s cloud unless you negotiate exit provisions. Always compare the total cost of a RISE subscription to a self-managed approach (licenses + a cloud infrastructure of your choosing). Make sure to negotiate things like price escalators (cap annual increase%), conversion options if you exit RISE (e.g. can you get perpetual licenses to run S/4 on your own if needed), and credits to avoid double-paying during migration (SAP often offers a cloud extension policy where you can redirect some maintenance spend toward the new RISE subscription).
Insight: If you’re planning a move to S/4HANA (whether on-prem or cloud), engage SAP early for any migration incentive programs (they sometimes offer credits or discount bundles). At the same time, do an internal assessment of what you truly need.
Many organizations have leveraged the migration as an opportunity to clean up unused licenses and renegotiate more favorable contracts. For example, some CIOs have secured deals where they get a period of overlap with both ECC and S/4 systems live (without double cost) or the ability to swap old licenses for new ones.
The key is to approach S/4HANA licensing as part of the project strategy, not an afterthought – it can significantly affect the business case.
Indirect Access and Digital Access
SAP licensing tip: Review contract terms, ask questions, and clarify what triggers indirect usage fees.
One of the thorniest areas in SAP licensing is indirect access – when people or systems that do not directly log into SAP still interact with SAP data or functions.
In the past, SAP took the stance that any use of SAP data, even via a third-party interface, requires an SAP license.
This led to high-profile disputes where customers were hit with massive claims for indirect use:
- In one famous case, a manufacturing company was charged for every sales rep and customer accessing SAP data through a non-SAP web portal (Salesforce in front, SAP in the back). SAP argued that each of those external users needed an SAP license, resulting in a multi-million-dollar compliance claim.
- Essentially, contracts prohibit the use of “middleware” or intermediary systems to bypass licensing (an anti-multiplexing clause). Therefore, if an app or API allows non-SAP users to trigger transactions in SAP, SAP considers those indirect users licenseable.
Due to customer backlash, SAP introduced the Digital Access model in 2018 as an alternative to the traditional model. Digital Access shifts from user-based licensing to a document-based approach for indirect scenarios.
SAP identified 9 document types (like Sales Order, Invoice, Purchase Order, etc.) that cover common business transactions. Under Digital Access, you are licensed to create a certain number of documents per year (regardless of who or what creates them).
For example, if an e-commerce platform creates 10,000 sales orders in SAP via an API, you need enough digital access licenses for 10,000 documents. Reading data or queries don’t count; it’s focused on new records created.
Choosing a Model:
Existing SAP customers often have a choice between sticking with traditional indirect use (covering all external users with named user licenses or special “platform” user licenses) vs. adopting Digital Access.
There was even a Digital Access Adoption Program to help estimate document counts and offer discounts for switching to digital access. The best option depends on your integration landscape:
- If you have numerous non-SAP systems generating transactions in SAP (through many interfaces, customer or partner portals, etc.), the Digital Access document model may be more cost-effective and clearer.
- If indirect usage is minimal or mostly internal (e.g., involving only a few third-party systems and primarily read-only interactions), you may be able to cover it with existing user licenses and avoid the complexity of counting documents.
Important: Indirect use is never free. Regardless of the route you choose, ensure that your contracts explicitly address it. If you opt for Digital Access, ensure you have tools to track those document counts.
SAP provides an estimation tool, and auditors will verify your SAP systems’ document logs. If you opt for named user licensing for indirect scenarios, maintain an inventory of all external users or devices accessing SAP data, and assign the corresponding licenses.
Example: A utility company implemented a customer web portal that allowed consumers to view their bills and submit service requests, which ultimately generated records in SAP. Initially, they feared every portal user might need a costly SAP account.
By negotiating a Digital Access license, they instead paid for a block of, say, 50,000 documents per year, which comfortably covered all portal transactions.
This approach capped their exposure and eliminated the risk of a surprise audit bill for thousands of unlicensed external users.
Cloud (SaaS) Products and Metrics
Beyond the core ERP, SAP’s product portfolio includes many cloud-based services (SaaS), each with its own licensing model and metrics.
CIOs need to account for these when planning overall SAP spend:
- SAP SuccessFactors (HR Suite): Typically licensed per employee on an annual subscription. For Core HR (Employee Central), you may incur an annual fee for each employee in the system. Talent modules (recruiting, learning, performance) could be priced per named user or event. For instance, you might be quoted $X per employee per year for core HR covering 5,000 employees, plus separate fees for a recruiting module covering 500 hiring managers or a learning module for all employees. Ensure the contract defines the employee count or user count, and negotiate provisions if your workforce shrinks or grows (true-down or tiered pricing). SuccessFactors pricing is tiered – the per-user cost often drops at higher employee counts.
- SAP Ariba (Procurement Network): Often based on spend volume or transaction volume through the Ariba network. For example, a procurement license might cost a percentage (e.g., 0.2%) of the total spend managed through Ariba, with tiers (spend up to $50M, next tier up to $100M, and so on). Other Ariba modules, such as Sourcing, may be priced per named user (e.g., per buyer) or by the number of sourcing events. Watch out for minimum fees and overage charges – if you exceed your contracted spend or transaction count, fees can spike. It’s prudent to negotiate some buffer or an adjustable model and to forecast usage so you buy the right amount.
- SAP Concur (Travel & Expense): Typically charged per active user per month or year. For example, if you have 1,000 employees submitting expense reports or using the travel booking, you pay for those users (often in bundles or tiers). Some Concur fees are transactional (e.g., $X per expense report or trip booking) or additional services (like integration or support). Key point: clarify what counts as an “active user” (some contracts only count a user if they log an expense in a given year, which can save money if many employees travel infrequently). Align the license with your travel policy – you may not need to license all employees, only those likely to use it.
- SAP Fieldglass (Contingent Workforce): Often based on the number of external contractors managed or total spend on contingent labor. For example, you might pay $Y per contractor managed through the system, or a % of the dollar value of contractor engagements. As with Ariba, ensure you have flexibility if your use of contractors fluctuates. Additionally, consider integrating Fieldglass with SAP ERP. Internal managers approving contractor timesheets in SAP would need to be licensed on the SAP side; however, Fieldglass itself may cover external users.
- Analytics & Platform (SAC, BTP, etc.): SAP Analytics Cloud (SAC) is a subscription per user (with different user tiers for viewer vs planner capabilities) and possibly capacity limits for data. SAP Business Technology Platform (BTP) offers a pay-as-you-go credit model or service subscriptions (pay for what you consume in terms of runtime, storage, etc.). These cloud platforms require careful monitoring; for example, BTP credit consumption can run away if multiple applications or integrations are enabled without oversight. Always understand the metric – whether it’s the number of users, memory size, API calls, or dollars of consumption – and build governance to track it. SAP often bundles these in larger deals (e.g., including some SAC licenses if you’re purchasing S/4HANA Cloud, or offering a discount on BTP credits if you commit to a certain spend).
Tip: When evaluating SAP SaaS contracts, read the service descriptions carefully to understand what is included.
Cloud licenses typically bundle the necessary infrastructure and support, but they might introduce limitations like data storage caps or require that you license your entire employee base for certain modules.
Negotiate definitions (for example, if you only want to cover full-time employees in SuccessFactors, be explicit if you want to exclude contractors or part-timers from the count).
Also, plan for growth – it’s easy to add more cloud users or transactions mid-term, but make sure you’re aware of how that will be priced (and try to lock in rate cards for additional volume upfront).
Managing Compliance and Optimizing Value
SAP licensing is not a “set-and-forget” exercise – it requires active management to stay compliant and cost-effective:
- Audit Rights: SAP, like most enterprise software vendors, reserves the right to audit your license compliance. Typically, your contract’s audit clause will allow SAP to audit with advance notice (e.g., 30 days) and require you to deploy SAP’s measurement tools (like LAW – License Administration Workbench). Ensure you are familiar with the terms of your contract regarding audit frequency and process. You usually can’t remove SAP’s audit rights, but you might negotiate some constraints (e.g. at most one audit per year, or use of a third-party auditor if there’s a dispute). The standard outcome of an audit is that you must purchase any shortfall of licenses; SAP’s contracts generally do not impose monetary penalties beyond buying the necessary licenses to cure non-compliance.
- SAP License Measurement Tools: Make use of SAP’s tools like USMM and LAW to get a snapshot of your license usage across systems. LAW consolidates data from across your SAP landscape to identify how many named users are assigned of each type and whether engines are in use. Be aware that some metrics (like engines tied to business metrics) might not be fully measured by LAW and require manual effort to check (e.g., LAW might flag that a system is using a module, but you have to verify how much of the metric is consumed, like revenue or order count). Many companies run internal “mock audits” annually to catch any compliance gaps before SAP does. There are also third-party tools from firms like VOQUZ, Snow, and others that can automate license optimization. These tools can identify dormant users, suggest better license categorizations, and simulate audit results. Consider investing in such tools or services, especially if you have a large SAP footprint; they can pay for themselves by uncovering savings of 5-10% or avoiding compliance issues.
- Shelfware Management: Continuously monitor for shelfware – unused licenses that you’re maintaining. For named users, periodically remove or reassign inactive accounts. (SAP requires each license be assigned to an individual, so you can’t “share” one license among multiple people concurrently, but you can reassign a license when someone leaves or changes roles – keep documentation of reassignments for the auditors.) For engines, compare your actual usage (orders processed, employees, GB of database, etc.) to what you’ve licensed. If you find significant unused capacity, plan to address it. You may negotiate a swap or termination at your next renewal, or even consider dropping maintenance on that component if it’s truly shelfware you won’t use.
- Global Licensing Agreements: Large enterprises operating SAP across multiple regions should consider consolidating their contracts into a single global agreement or an enterprise agreement. A single global license agreement (GLA) allows a parent company and its affiliates to share licenses, standardize terms, and often achieve volume discounts that would be impossible in separate, smaller deals. By aggregating all SAP spend into one negotiation, CIOs can negotiate deeper discounts (50%+ off the list price for a large, multi-million-dollar deal, versus perhaps 20-30% in isolated deals) and ensure consistent terms worldwide. Global deals also align all renewals to one date, simplifying management and preventing SAP from using “divide and conquer” tactics across subsidiaries. If you have many different SAP contracts due to regional purchases or acquisitions, evaluating a GLA could unlock savings and flexibility (e.g., the ability to transfer licenses globally to where they’re needed).
Recommendations
- Centralized License Management: Establish a dedicated team or owner for SAP license management. Treat licenses as valuable assets – maintain an accurate inventory of entitlements, track usage regularly, and serve as the primary point of contact for any licensing-related questions within the organization.
- Conduct Regular Internal Audits: Don’t wait for SAP’s official audit. At least once a year, run your license audit using SAP’s tools or third-party software. Identify inactive users, misassigned license types, and any engine usage over the licensed limits. Proactively correct any shortfalls or reclaim excesses. This preparation ensures there are no big surprises if SAP audits you, and you can address issues on your terms (for example, purchasing a few needed licenses quietly at a discount, rather than under audit pressure at list price).
- Optimize Before You Buy More: Before purchasing new licenses or subscribing to additional SAP products, fully utilize what you already have. Reassign unused user licenses, downgrade users who don’t need higher-level access, and consider trading in shelfware at renewal time. This avoids unnecessary spending. It also strengthens your negotiation position – SAP is more likely to offer a deal if they know you’re squeezing value from existing investments and could consider alternatives.
- Negotiate Flexible Terms: When negotiating contracts or renewals, push for flexibility clauses. For example, seek the right to swap license types (convert some Professional users to Functional, etc., as needs change), transfer licenses across affiliates, or reduce quantities if certain projects are shelved. Try to cap maintenance fee increases (e.g., no more than 5% annually) and get clarity on indirect access in writing (choose a model and document it in the contract). If you’re moving to the cloud or S/4HANA, negotiate transition assistance, such as temporary dual-use rights or pricing credits, to avoid paying double during the migration. Never rely on verbal assurances – get every special term explicitly written into the agreement.
- Educate Your Stakeholders: Licensing touches architecture, procurement, project management, and compliance teams. Provide basic SAP licensing training for your IT staff and procurement officers. Simple design decisions – such as how an interface is set up or how user accounts are provisioned – can have significant licensing implications. Make it standard practice to review the licensing impact of any new SAP-related project or integration. When everyone understands the “why” of licensing rules (e.g., why sharing an account is not allowed or what counts as indirect usage), they are more likely to comply and avoid creating risks.
- Plan Major Moves with Licensing in Mind: If you are evaluating a big change, such as a move to S/4HANA, adopting RISE, or adding a new cloud module, involve your licensing experts early. Build the license costs into the business case. Talk to SAP about any promotional programs (they often have carrots for moving to cloud or the latest products), but also weigh the loss of flexibility or vendor lock-in. For example, if you consider third-party support to save on maintenance costs for an older SAP system, understand the pros and cons (no new updates from SAP, and potential fees if you return to SAP support later). Use the prospect of third-party support or alternate solutions as a bargaining chip only if you’re genuinely willing to go that route. Major transitions are the ideal time to review and realign your license portfolio to align with the future state, so take a strategic approach.
- Stay Assertive and Informed: Ultimately, remember that you, as the customer, hold the leverage. SAP sales reps are incentivized to sell more – it’s your job to ensure you’re buying only what you need at a fair price. Be prepared to push back on proposals that don’t make sense. Leverage user groups, independent advisors, or benchmark data to counter unreasonable terms. Maintain a professional but firm stance in negotiations: SAP, like any vendor, will yield on price and terms if you present data-driven arguments, demonstrate willingness to walk away from extras, and coordinate your organization’s asks through a single voice (especially in a global deal scenario). Staying informed of SAP’s product roadmaps, licensing changes, and industry best practices will empower you to make savvy decisions and avoid costly mistakes.
FAQ
Q1: What are the main components of SAP licensing that CIOs and CTOs should know?
A: The key components include named user licenses (for each individual using the system, with types like Professional, Functional, ESS, etc.), package/engine licenses for specific modules or technical components (licensed by metrics like users, revenue, transactions, etc.), and the overarching license model (perpetual on-premise vs. subscription cloud contracts). Additionally, indirect access rules, annual maintenance fees, and special programs (such as RISE or enterprise agreements) are also important components of the puzzle. Understanding each of these elements helps you manage both compliance and cost.
Q2: How can we reduce SAP license costs without risking compliance?
A: Start by auditing your current usage to find any over-licensing or shelfware – for example, users with higher-tier licenses than necessary or unused engine capacity. Reassign or reclassify those to eliminate waste (ensure to document compliance changes). Negotiate with SAP at renewal to swap or drop truly unused licenses (sometimes you can get credit toward new purchases). Additionally, consider options such as a global enterprise agreement to secure better volume discounts if you have multiple contracts. Finally, keep a close eye on indirect usage – choose the most cost-effective model (named users vs. digital access) and right-size that as well, so you’re not paying more than needed.
Q3: What is “indirect access,” and how do we address it in our SAP contract?
A: Indirect access refers to scenarios where users or applications that do not directly log into SAP still consume SAP data or trigger transactions in SAP. For instance, a mobile app that creates a sales order in SAP or a third-party system pulling data from SAP both count as indirect use. SAP requires that this usage be licensed either by covering external users with SAP user licenses or by utilizing SAP’s Digital Access (document-based licensing) model. To address it, you should first map out all systems interfacing with SAP and determine the nature of access. Then ensure your SAP contract explicitly covers how those interactions are licensed. Many companies now opt for the Digital Access approach if they anticipate a high volume of document transactions from external systems, as it can simplify compliance. Regardless of the model, document it in the contract to avoid ambiguity during an audit.
Q4: How do SAP cloud solutions (like SuccessFactors, Ariba, etc.) differ in licensing from on-premise SAP?
A: SAP’s cloud products are sold on a subscription basis, typically billed annually, and the metrics can differ from on-prem. For example, SuccessFactors (HR) might be priced per employee per year, Ariba by spend volume or number of suppliers, Concur by active user per month, and so on. In contrast, on-premise SAP ERP was traditionally a one-time license plus maintenance. Cloud subscriptions bundle the software, hosting, and support into one fee and offer more flexibility at renewal, but you don’t “own” the software outright. Also, cloud contracts often have their usage metrics and limitations (storage limits, API call limits, etc.). CIOs should read each cloud service’s terms carefully – you may need to true-up if you exceed certain thresholds (like more employees or more spend than you contracted). The benefit of cloud SaaS is that you can scale users up or down more easily, as the vendor manages the infrastructure. The trade-off is ongoing subscription costs and less control over the environment.
Q5: What are some negotiation best practices for SAP contracts?
A: Do your homework – know your current license deployment and future needs in detail, so you only buy what’s necessary. Engage early with SAP (or their partners) when major changes are coming (e.g., a S/4HANA migration) to see what incentives you can leverage, but don’t accept the first offer. Bundle and leverage volume – if you can consolidate purchases (for example, negotiate one large deal for multiple projects or global units), you typically get much higher discounts. Insist on flexibility in writing: include clauses to adjust license mix, protect against price hikes (cap maintenance or subscription increase rates), and cover transitional use (like dual-use rights during a migration). Always time big negotiations around SAP’s end-of-quarter or fiscal year – vendors are more inclined to give concessions to close deals. And, consider getting independent licensing advisors or legal counsel to review terms for traps (like indirect use clauses or restrictive termination terms). Remember, once signed, the contract governs your relationship for years, so push for terms that safeguard your interests, not just SAP’s.
Read more about our SAP Licensing Services.