Managing SAP Cloud Application Licensing

Managing SAP Cloud Application Licensing

Introduction

Managing licensing for SAP’s cloud application portfolio is a complex but critical task for Software Asset Management (SAM) managers and SAP licensing professionals. SAP’s Software-as-a-Service (SaaS) offerings — from HR and procurement to travel management — each come with distinct license models, usage metrics, and contractual nuances.

Without careful oversight, organizations can face unexpected costs or compliance risks, whether from overprovisioning users, exceeding transactional limits, or violating indirect usage rules.

This advisory article provides a detailed look at how major SAP cloud products are licensed, common pitfalls to avoid, and strategies to optimize contracts. It covers key SaaS solutions, including SuccessFactors, Ariba, Concur, Fieldglass, and others, highlighting how each is measured and where companies often run into trouble.

We also offer guidance on structuring agreements, including renewals, co-terming, and metric consolidation. This guidance covers considerations for integrating these cloud apps with core SAP ERP, real-world examples of financial impact, and region-specific issues such as EU data privacy.

Throughout, the tone is advisory and customer-focused, aiming to empower you to manage SAP cloud licenses proactively and negotiate with SAP from an informed position.

Overview of Major SAP Cloud Products and Licensing Models

SAP’s cloud application suite spans multiple business domains. Below, we outline each major product, how its licensing typically works, and its unique considerations:

SAP SuccessFactors (HR Management)

Licensing Model: SuccessFactors is SAP’s cloud Human Capital Management (HCM) suite (covering core HR, talent management, etc.). Licensing is generally based on the number of employees or users in the system.

Most modules are priced per user, typically per employee record or named user, on a subscription basis. For example, the Employee Central module may be licensed for each employee stored in the system, and this is typically calculated monthly per employee.

SAP often distinguishes between a Full User (an employee or HR staff member who logs in and uses the system) and a Functional User (an employee record that exists for processing but does not have direct login access).

Full users typically incur the standard per-user cost, while functional users (those with no login access) may be charged a lower rate. This distinction allows organizations to include the entire workforce in the system while paying a reduced fee for those who don’t actively use it, such as contractors or retirees tracked for data purposes.

Common Pitfalls: SuccessFactors licensing can be tricky in practice. Some pitfalls to watch for include:

• Indirect or Unlicensed Access: Even if employees primarily interact with SuccessFactors directly, there are scenarios where other systems or users access SuccessFactors data indirectly. For instance, managers in a different system might retrieve reports from SuccessFactors, or a third-party app might update employee info. Ensure that all human users with access (direct or indirect) are accounted for under the appropriate SF license; otherwise, you risk a compliance gap.
• Misclassification of User Types: Failing to properly differentiate between full and functional users can lead to over-licensing. For example, if you grant login access to every employee by default, you’ll pay full user rates even for people who never use the system. Conversely, classifying too many as “functional” (no access) when they do access any part of the HCM suite will violate license terms. Align your configuration with contract definitions — for example, in Employee Central, disable login for records intended to be functional-only. Regularly audit user lists to ensure that only those who are truly not accessing the system remain as functional users.
• Employee Count Changes: SuccessFactors contracts often lock in a certain number of employees or users. If your headcount decreases significantly (due to layoffs or divestitures), you may end up overpaying for unused licenses until the next renewal. Conversely, if headcount grows beyond your licensed volume, you may need to true-up (and potentially at a higher marginal cost). Negotiating flexible terms for adjusting user counts (discussed later) is important to avoid paying for “shelfware” and staying compliant.
• Module Overlaps: The suite’s modules sometimes have overlapping user bases (e.g., the same employee might be counted for core HR, performance, and learning modules). SAP typically doesn’t bundle these automatically — each module’s subscription is a separate one. A pitfall is over-licensing the same population for multiple modules that might not all be used. Companies should carefully assess which employee groups need which modules. You might not need enterprise-wide licenses for every module; for example, perhaps only 20% of employees use the Learning module. Right-size module licenses rather than blanket licensing everyone for everything.
• Unclear Integration Boundaries: Many customers integrate SuccessFactors with on-premise SAP ERP (ECC or S/4HANA) for payroll, time, or org management. It’s crucial to clarify which system is the system of record and how data flows, as this can impact licensing. For example, if you still run SAP Payroll on ECC and use SuccessFactors Employee Central for HR data, are the HR administrators counted in ECC’s user licensing or just SuccessFactors? Generally, each system requires its user licenses. However, if an SF user indirectly triggers transactions in SAP ERP, this can introduce indirect usage considerations on the ERP side, which are addressed later. Ensure that your contracts (and SAP’s understanding) delineate what is covered by the SuccessFactors subscription versus any required licenses in connected systems.

SAP Ariba (Procurement and Spend Management)

Licensing Model: SAP Ariba is a suite of cloud-based solutions for procurement and supply chain collaboration. Licensing for Ariba can vary by module, and it often uses transaction-based or spend-based metrics as well as user counts for certain components.

Key points include:

• Ariba Buying/Invoicing (Procure-to-Pay): Typically licensed based on annual spend volume processed through the platform. SAP often sets tiers (bands of spend) and charges a percentage of that spend as the subscription fee. For example, a contract might allow up to £78 million in spending per year at a rate of 0.21% of the spend. If your managed spend increases, fees will go up proportionally, or you may move into a higher band, possibly with a different percentage. Some Ariba P2P contracts use document counts (number of invoices, POs, etc.) as a metric instead or in addition.
• Ariba Sourcing and Contracts: These modules (used for running RFPs, auctions, and supplier contracts) are often licensed by the number of named users (e.g., sourcing managers, contracting professionals) who use the system. For instance, an Ariba Sourcing license might be sold in packs of 5 or 10 users. An example indicative price is around £ 30,000 per year for 5 Sourcing users. Sometimes, a concurrent user model is used (e.g., only 10 users can be logged in at once, even if you have 15 named accounts), although named user licensing is more common in SaaS solutions.
• Ariba Supplier Network (Business Network): When transacting with suppliers through Ariba, fees are associated with the Ariba Network. Buyers typically pay a subscription or transaction fee, and suppliers may also incur fees. Buyer-side network fees may be flat or tied to the number of documents. (SAP has various subscription levels for suppliers, but that’s more on the supplier’s concern; as a customer, be aware that pushing all your suppliers through Ariba could indirectly impose costs on them or you if you agree to cover those fees.)
• Other Ariba modules, such as Supplier Lifecycle and Performance, Supplier Risk, and Spend Analysis, are usually user-based or offer flat fees, sometimes sold as bundles. For example, Supplier Risk might require a certain number of user licenses for those performing risk assessments. Spend Analysis might be priced by spend volume, as it analyzes enterprise spend data.

Common Pitfalls: Ariba’s licensing complexity means several potential pitfalls:

• Underestimating Spend or Transaction Volume: If you license Ariba Buying based on a certain spend threshold and your actual spend exceeds it, you could incur significant overage fees or be forced to a higher subscription tier mid-term. For example, if you contracted 0.21% up to a £78M spend and you run £100M through the system, that extra £22M might be charged at a higher marginal rate or require immediate renegotiation of the contract. Always analyze your spend forecasts carefully and build in a buffer or flexible terms for growth. Conversely, overestimating spend (licensing far more than you use) means you’re overpaying – but often you’re locked into a minimum fee. Recommendation: Negotiate the ability to true-down or get credit if actual spend is lower than anticipated, and avoid rigid caps that don’t scale.
• Hidden Supplier Fees and Adoption Issues: Your organization might focus on its licensing costs and overlook that Ariba’s model can shift costs to suppliers through network fees. Suppose suppliers, especially smaller ones, are asked to pay to transact with you on Ariba. In that case, they may resist or not fully adopt the platform, leading to compliance gaps (orders and invoices reverting to email). Some companies negotiate to cover supplier network fees themselves or choose subscription models that minimize supplier cost to encourage adoption. Failing to plan for supplier enablement and the fee structure can derail the ROI of Ariba. It’s a licensing consideration: while it’s not your direct fee, it’s part of the total cost of ownership and the system’s success.
• Concurrent vs. Named User Confusion: Ensure clarity on user licensing for sourcing and contracts. Some contracts stipulate concurrent users, which can allow you to create more named accounts than licenses, assuming not all will be used simultaneously. In contrast, others are strict on named user counts. Misunderstanding this can lead to compliance issues – for example, if you thought you could have 15 users on a 5-concurrent user license but the contract limits it to 5 named users, you would be out of compliance. Always get the definitions in writing. The SAP community has noted models like concurrent logins for Ariba Sourcing​, but SAP’s contracts should explicitly define it.
• Over-licensing Users: Ariba modules often have minimum user bundles, as seen in pricing examples with a 5-user minimum pack. Some companies blindly purchase the default bundle even if they only have 2 or 3 people who will use the tool, leading to shelfware. Perform a role-by-role analysis to determine who truly needs access. If you have a small team, try negotiating for a smaller bundle or see if those users can share accounts (not generally advisable due to audit reasons, but some companies do it). Alternatively, consider a different product edition, such as Ariba SNAP for mid-size firms, which may be more cost-effective. Ariba SNAP is designed for smaller spends and often has different pricing (e.g., a higher percentage of spend but a lower minimum).
• Integrations with SAP ERP: Ariba is often tightly integrated with SAP ECC or S/4 (for purchase orders, invoices, and master data synchronization). If Ariba creates a purchase order in your SAP ERP system, SAP may view that as indirect use of SAP ERP. In the past, indirect access concerns were mostly related to third-party systems, but even cloud-to-SAP on-premises integrations with SAP require attention. Ensure you have the appropriate SAP ERP user or document licenses to cover documents created by Ariba in the ERP (for instance, if using SAP’s Digital Access licensing for ERP, procurement documents arriving from Ariba should count under your document allowance – see Integration section for more). Don’t assume your Ariba subscription alone covers the ERP side of the process.

SAP Concur (Travel & Expense Management)

Licensing Model:

SAP Concur is a popular travel booking and expense management software as a service (SaaS). Its licensing is generally on a per-user subscription basis, but often with a twist: Concur frequently charges based on the number of active users and transactions (expense reports) rather than a flat fee for all employees. For instance, a common model is an annual or monthly base fee plus a charge per expense report or travel booking processed.

In some pricing schemes, Concur might be, say, $8 per user per month for an Expense module license, or structured as $X per expense report submitted.

In enterprise deals, a hybrid model is common: you pay a fixed base fee that covers a certain number of users or transactions, and then an incremental fee per transaction beyond that​. Travel booking fees may be separate, often a transaction fee per trip booked.

To illustrate, an example package for Concur Expense might include a base subscription of around £826 per month (covering up to 100 users or a set number of reports) and then approximately £10 per expense report processed, with volume discounts reducing the per-report fee as volumes increase. Larger enterprises might negotiate an all-you-can-use user-based model, but the pay-per-use element is common, aligning cost with actual usage.

Common Pitfalls: Managing Concur licensing involves monitoring both users and usage:

• Inactive or Ex-Employee Accounts: Concur charges per active account (usually monthly active users or any user enabled in a given period). A classic mistake is failing to promptly deactivate users who leave the company or no longer require Concur access. Each active account could incur a monthly fee. Regularly reconcile Concur user accounts with HR rosters. Implement automated deprovisioning when employees leave, and consider policies for deactivating idle users (e.g., those who haven’t filed an expense in 6 months).
• Unanticipated Transaction Volume: If your contract includes per-expense or per-trip fees, a surge in travel or expense activity can blow past budget. For example, after a period of travel freeze, a rebound in business travel could result in far more expense reports than anticipated. If each report costs $X, finance could face a large variable bill. Mitigate this by negotiating volume bands in advance – e.g., if you expect 10,000 reports/year, price out tiers for 12,000 or 15,000 so you know the marginal cost and perhaps lock in discounts. Also, promote practices that consolidate expenses (fewer, larger reports per person) if appropriate, to reduce the number of transactions.
• Module Creep and Add-Ons: Concur offers multiple modules, including Expense, Travel, Invoice (for AP automation), and Duty of Care, among others. Each may have its own licensing. Ensure you’re not double-paying for overlapping capabilities. For example, if you license Concur Invoice for AP automation and also have Ariba Invoicing, avoid paying for two solutions that manage the same invoices. And if you enable add-ons like Concur Detect (for fraud detection) or TripLink, be aware of how they are priced (some are flat add-ons, while others are user-based). It’s easy to sign up for extra features during implementation that later show up as additional recurring fees.
• Geography and Policy of Usage: Not every employee will use Concur equally. Some companies initially license Concur for all employees, assuming everyone will file expenses. In reality, perhaps only a subset travels or incurs reimbursables. Over-licensing can occur if you pay for 100% of employees but only 60% file any reports. A better approach is to start with the population that needs it (e.g., those with corporate cards or frequent travelers) and then expand if needed. Concur’s flexible user model can allow scaling up, but be mindful of any contract minimums. Avoid committing to enterprise-wide counts unless required; instead, map out who truly needs access.
• Integration and Financial Posting: Concur is often integrated with SAP ERP for posting expense reports to FI/CO modules (and to HR for employee data). If Concur automatically creates accounting entries in SAP S/4HANA or ECC, those entries might be considered indirect use of SAP ERP. Ensure you have sufficient SAP ERP licensing (e.g., “Financial” or “Employee” user licenses, or the digital document license) to cover those transactions. While the Concur side is covered by its subscription, SAP could argue that every expense report that generates a journal entry is an external document creation in SAP ERP, requiring a license. (SAP’s newer Digital Access model would count those financial documents – see Integration section for details on mitigating this.)

SAP Fieldglass (Contingent Workforce Management)

Licensing Model: SAP Fieldglass is a cloud solution for managing external labor, including contractors, temporary staff, and the procurement of services (SOW-based services). Licensing is typically tied to the volume of external workers or the spend on those workers. In practice, this can be structured in a few ways:

• Per External Worker (Seat): A common model is charging per active contingent worker managed in the system. For example, if you have 500 contractors on Fieldglass at peak, you may need a license for 500′ worker profiles”. This could be priced per worker per month or as an annual subscription allowing up to a certain number of workers. There might be tiers (e.g., 0–500 workers, 501–1000, etc., with increasing fees).
• Spend-Based: Alternatively, Fieldglass licensing can be based on spend throughput, similar to procurement. The contract could specify a percentage fee on the total spend on contingent labor managed via Fieldglass (or a flat fee for a certain spend range). For instance, a Managed Service Provider (MSP) might include a Fieldglass cost of, say, 1% of contractor spend. In some models, the supplier or MSP pays a portion of the fee (supplier-funded vs buyer-funded models). SAP sometimes leaves the commercial arrangement such that the staffing suppliers effectively “pay” to participate (via a cut of their bill rates). However, if you’re self-managing Fieldglass, you, as the buyer, might pay the subscription directly.
• Module Distinctions: Fieldglass has modules for Contingent Workforce and Services (SOW) procurement. Pricing for SOW management might be separate, potentially based on the number of SOWs or their value. Ensure you understand if both modules are included or costed separately in your contract.
• Flat Enterprise Fee: Large organizations can negotiate a flat annual fee for Fieldglass that covers a specific scope (e.g., unlimited contractors or a very high cap). This can simplify things, but the fee will be based on expected usage, so you still need to forecast correctly.

Common Pitfalls: Fieldglass brings its own set of licensing challenges to manage:

• “Idle” Contractor Profiles: One of the most common pitfalls is not properly off-boarding external workers in the system. If a contractor’s assignment ends, but their profile remains active in Fieldglass, it may count toward your licensed total. Companies have found hundreds of inactive contractors still listed in Fieldglass because project managers or vendors failed to formally close out their work orders. This inflates your active user count and could push you into a higher licensing tier or over the contracted limit. SAM managers should implement a process with procurement and vendor management to routinely purge or deactivate inactive contractors. Fieldglass provides reporting on workers with no recent time or active engagement – use these to keep license usage accurate.
• Seasonal or Project Spikes: Many organizations use contingent labor seasonally or for major projects, causing spikes in usage. If your license is based on a steady-state number but you occasionally double the workers for a big project, you might violate terms during that spike (or incur extra fees). For example, you are licensed for 200 contractors but ramp up to 300 during the holiday season – those extra 100 might require an urgent license expansion. To avoid this, negotiate burst capacity or a flexible tier that allows temporary increases (perhaps with notice to SAP). Alternatively, structure the contract based on annualized averages or anticipated peak usage.
• Spend vs User Model Confusion: Be clear on how you’re being charged. If you assumed it was per worker, but the contract has a spend percentage, you will need to track your spend meticulously. Conversely, if spending plummets (e.g., due to budget cuts for contractors) but you have a fixed per-user fee, you could overpay relative to your usage. Align the model with how you plan to use Fieldglass. If you have tight control over several contractors but their rates vary, a per-worker model might be safer. If the count varies but total spend is your main concern, a spend-based model could map better to value.
• Integration Licensing (SAP HCM/SF): Fieldglass often integrates with SuccessFactors or on-premise SAP HR to exchange worker information. Notably, if you bring contractor data from Fieldglass into SuccessFactors (using SAP’s Total Workforce Management integration), SAP does not require those contingent workers to have full SuccessFactors licenses. In Employee Central, they can be tagged as contingent workers from Fieldglass and do not count toward SF user counts​. The pitfall is that if you don’t configure this correctly, you might accidentally double-pay by also licensing these contractors in SuccessFactors as “functional users.” Ensure you use the integration as intended, so you only pay for them in Fieldglass.
  On the other hand, check if any internal users, such as managers or timesheet approvers, interacting with Fieldglass require any specific licenses. Typically, anyone logging into Fieldglass needs a license (for example, an HR manager who views contractor information is usually a user in Fieldglass as well). Still, sometimes those roles are not counted the same way as workers.
• MSP Agreements: If you outsource contingent labor management to an MSP, the MSP may provide access to the Fieldglass system as part of their service (and pass the cost on to you indirectly). In such cases, you might not have direct visibility into the licensing. A pitfall is a lack of transparency — you could be paying a markup for Fieldglass through the MSP without knowing the exact license counts or terms. Ensure your MSP contract spells out the licensing model and that you retain audit rights or at least get usage reports. Even if you’re not directly responsible for SAP, if usage increases, the MSP will pass on the cost. So, all the same vigilance is needed, just one step removed.

Other SAP Cloud Applications (S/4HANA Cloud, CX, etc.)

In addition to the above LoB solutions, SAP’s cloud portfolio includes several other major SaaS products that SAM professionals should be aware of:

• SAP S/4HANA Cloud (ERP): S/4HANA Cloud is SAP’s next-gen ERP delivered as a cloud service (available in multi-tenant public cloud or single-tenant private cloud editions). Licensing for S/4HANA Cloud is primarily user-based, similar to traditional SAP ERP. You purchase multiple user licenses of different types (e.g., Professional User, Functional User, Self-Service User) for the modules in scope. Each user type is associated with specific permitted actions. For instance, a Professional User (broad use) might be, say, $1000/year, while a Self-Service (limited use) is much less.
  Additionally, S/4HANA Cloud contracts often have a minimum annual fee and specific add-ons for extra modules or digital access. Pitfall: The named user approach means indirect access still matters – for example, if non-SAP applications create documents in S/4HANA Cloud, you may need digital access document licenses. Also, be mindful of the distinction between the private cloud (RISE with SAP) model, where S/4 licensing is bundled with infrastructure in a subscription, versus pure public cloud SaaS. In RISE deals, metrics like Full-Time Equivalent (FTE) or CPEA credits may come into play, adding complexity. Align S/4HANA Cloud user counts with actual usage and consider optimizing license type mixes, as not everyone needs a full Professional license if they only run reports or approvals.
• SAP Customer Experience (CX) Suite: This includes products like SAP Sales Cloud and Service Cloud (formerly SAP Cloud for Customer, C4C), SAP Commerce Cloud (formerly Hybris Commerce), SAP Marketing Cloud, and others. Each has its licensing metric:
  • Sales/Service Cloud: Typically licensed per named sales or service employee user (per month). Similar to CRM systems, you pay for each agent or salesperson using the tool. There may be different tiers, such as full sales users vs. read-only or partner users.
  • SAP Commerce Cloud: Often licensed based on peak page views or gross merchandise value (GMV) for ecommerce, rather than per user (since end customers use it). For example, you might pay a certain amount for up to $X million in annual web sales processed or a certain number of visits. Pitfalls here include underestimating web traffic or sales. If your online store runs a big promotion, exceeding those limits can result in overages or require an upgrade. Also, if you run multiple regional web shops, ensure the license covers all sites or domains as needed.
  • SAP Marketing Cloud: Commonly licensed by the number of contacts in your marketing database (and sometimes the number of emails/messages sent). If you have 1 million consumer contacts, you might be in a certain pricing tier. Pitfall: contact counts often grow over time (and include inactive contacts unless purged), so companies can exceed their licensed contact tier. Good governance on data retention and contact cleansing can save real money.
  • SAP CPQ (Configure Price Quote) and other smaller CX apps: Usually user-based or quote volume-based.
  • In general, the CX suite requires careful reading of the order form to determine which metric is used. Indirect use can arise if, for example, a website (non-SAP front-end) calls Marketing Cloud APIs – ensure that those API calls are licensed via the contact count or user metric appropriately.
• SAP Analytics Cloud (SAC): SAP Analytics Cloud is a cloud-based BI and planning tool. It’s licensed per user, with different types such as Business Intelligence users vs. Planning users, and sometimes with a capacity component for planning (e.g., memory for data models). Pitfalls: If you plan to use models that consume more resources, you may need the higher license tier for those users. Also, sharing dashboards with a wide audience might tempt organizations to create generic or shared logins, which breaches licensing. Instead, consider the cost-benefit of interactive licenses vs just distributing static reports for casual viewers.
• SAP Business ByDesign: A full cloud ERP for mid-market, licensed per user per month by role (similar to S/4HANA Cloud). Although not as common in large enterprises, SAM managers in subsidiaries using ByDesign should apply similar principles: optimize user types and be aware of indirect access when integrating with corporate systems.
• SAP Cloud Platform / Business Technology Platform (BTP): This is more of a Platform as a Service (PaaS), but it often underpins integrations and extensions for SaaS applications. BTP is usually licensed through a consumption model (cloud credits or a “CPEA” – Cloud Platform Enterprise Agreement, where you purchase a pool of credits). The main licensing pitfall is exceeding your credit pool by running usage (CPU, memory, services) beyond your allocated limits, resulting in additional charges. From a SAM perspective, monitor BTP usage, especially if you build custom extensions for SuccessFactors or integrations with Ariba. Ensure your deals for the SaaS apps clarify whether BTP usage (if any) is included or not.

Each of the SAP cloud products could warrant a deep dive, but the unifying theme is the variety of metrics, including users, spend, transactions, revenue, etc. Overall, the Pitfalls for these other apps mirror what we’ve discussed: misjudging the key metric (be it users or volume), not monitoring the growth of that metric, and complexities when integrating with other systems.

Summary Tip: Always obtain the SAP product usage rights and definitions for each cloud service you use. These documents (often an appendix to your contract) define the metric and what counts toward it.

Many issues arise simply from not knowing that, for example, “10k contacts” means all contacts, including inactive ones, or that a “professional user” for S/4HANA Cloud allows XY&Z but not ABC. Knowing these definitions lets you set up governance (for example, archiving marketing contacts periodically or ensuring that each e-commerce transaction is logged properly for Commerce Cloud counting).

Contract Structuring and Negotiation Guidance

With an understanding of how each SAP cloud solution is measured, the next step is optimizing the contract itself. Negotiating SAP SaaS agreements requires careful attention to specific terms that can significantly impact cost and flexibility over time.

Here we cover strategies for renewals, aligning contract dates, and consolidating metrics or agreements.

Renewal Considerations: Price Uplifts and True-Downs

Most SAP cloud contracts are annual or multi-year subscriptions. Renewal time is your primary opportunity to adjust terms and costs, as mid-term changes are often not allowed or come at a premium.

Key points to consider:

• Price Increase Caps: SAP cloud agreements often include an annual price escalation, such as 5-7% per year or one tied to an index. Negotiate this cap as low as possible at the outset. Better yet, for multi-year deals, try to lock pricing for the term or agree on a modest fixed uplift. For instance, push for a 0% increase for a 2-3 year term or a cap, such as “shall not exceed 3% per year.” Gartner research has noted that controlling future SaaS price increases is crucial to avoid budget surprises. If SAP won’t budge on a standard uplift, consider pre-paying multiple years or committing to an extended term in exchange for price protection.
• Renewal Transparency: Have the contract specify how renewal pricing will be determined. If you received a significant discount in the initial term, ensure that the discount (or better) carries forward. Otherwise, SAP might quote the renewal at list price, resulting in a huge jump. A clause like “renewal rate will be based on the then-current fees with at least the same discount percentage as the initial term” can save you from a nasty shock. Also, engage with SAP well in advance of renewal (6-12 months) to start discussions – last-minute renewals typically favor the vendor.
• True-Down Rights: Unlike perpetual licenses, cloud subs are typically “use it or lose it” – you pay for the subscribed quantity whether or not you use it fully. However, you can negotiate true-down provisions at renewal, meaning if your usage or needs have decreased, you can reduce the quantity (and cost) accordingly. This is especially relevant if your business has potential downsizing events or divestitures on the horizon, or if you initially overestimated. For example, if you purchased 1,000 SuccessFactors users and, after a year, only 800 are needed (perhaps due to a headcount reduction), a true-up clause would allow you to renew for 800 (often without penalty). SAP may resist, but you can argue for flexibility given the variable nature of business, perhaps agreeing that you’ll give notice or that true-down can only be a certain percentage max. Even having the option to reduce licenses by 10-20% can be valuable.
• Carry-Forward of Unused Entitlement: If true-down is not achievable, another option is to negotiate the right to apply unused licenses to other areas. For instance, if you overlicensed Ariba users but underlicensed Concur users, see if at renewal you can shift some investment from one product to the other (if both are co-terminous, which we discuss next). This effectively repurposes your spend rather than reducing it, which SAP might find more palatable than an outright drop in subscription revenue.
• Benchmark and Right-size: Before renewal, perform a thorough usage analysis. Audit how many users logged in, how many documents/spend you consumed versus licensed. Use this to right-size your ask. If you are only consuming 50% of what you pay for, you have a strong case to adjust terms (or at least demand other concessions). Also, gather external benchmarks if possible – knowing what similar companies pay (per user or as a percentage of spend) can give you leverage to negotiate better rates, especially if you threaten to scale back or not renew certain modules.

Aligning and Co-Terminating Cloud Contracts

Many SAP customers gradually adopt multiple cloud products over the course of several years. Without intervention, you could end up with a patchwork of contracts, each with different start and end dates and terms.

Co-termination refers to aligning contract end dates so that all (or many) of your SAP cloud subscriptions renew at the same time.

This can be a powerful strategy, but it needs careful handling:

• Negotiation Leverage: Having a single renewal date for a large bundle of SAP products can increase your leverage. SAP knows that you could potentially drop or swap out any of them at renewal, and you can use the total contract value to your advantage. If SuccessFactors, Ariba, Concur, etc., all come up together, the stakes are higher for SAP to offer a good deal to keep everything in place. You might negotiate an enterprise agreement that covers all, potentially yielding cross-product discounts.
• Administrative Simplicity: From a SAM perspective, managing one renewal is simpler than managing five. Co-terming means you can run one internal approval process, one legal review, and one budgeting cycle. It also means you can more easily reallocate unused funds or licenses between products at renewal, as mentioned above. Many organizations aim to coordinate their fiscal year-end dates.
• Challenges of Co-terming: To achieve co-termination, you may need to either short-term extend some contracts or vice versa. For example, if Concur ends in June 2025 and SuccessFactors in December 2025, you might negotiate a 6-month extension for Concur to sync both to Dec 2025. Be prepared: short extensions might be at list price or a prorated cost that’s relatively higher (since vendors dislike short terms). Plan and budget for a possible premium to get alignment, or try to time new purchases to existing end dates. Another challenge is if one product is not performing or you’re considering replacing it, co-terming ties it to the others – you lose flexibility to independently terminate one service without potentially impacting a larger agreement.
• Master Agreements and Bundles: SAP may offer to consolidate your separate cloud contracts into a single Cloud Services Agreement or an enterprise subscription. This can simplify legal terms and co-term by default. If you go this route, scrutinize the new consolidated contract – ensure that no unfavorable terms have been added and that product-specific usage definitions have carried over properly. Also, check if co-terming affects any special pricing you had. Sometimes, bundling can dilute a discount you had on one product if it wasn’t negotiated properly.
• Exit Strategy: While co-terming gives leverage, it also means that if negotiations fail, theoretically, all those services would expire at once. That’s a big risk to operational continuity. Mitigate this by having renewal discussions early and at a high executive level. If you sense trouble, you might stagger one or two key ones as a fallback. But in general, with good relationship management and early negotiation, co-terming is beneficial.

Unified Metrics and Contract Consolidation

SAP historically sold products in silos, but as customers, you can try to consolidate metrics or contracts to achieve a more favorable deal:

• Consolidating User Metrics: If the same users are counted across multiple cloud services, try to avoid paying twice for the same person. SAP’s standard practice is to charge separately for each service; a user in SuccessFactors and the same user in Concur are counted and paid in both contexts. However, in large deals, you might negotiate an enterprise metric. For example, you could propose, “We have 10,000 employees. We want to license SuccessFactors, Concur, and Fieldglass for all of them under a unified per-employee price.” SAP might not readily agree, but sometimes they do offer enterprise subscription agreements where, for a single price per employee, you get a bundle of cloud products. This often happens in strategic deals or when SAP wants to showcase a broad adoption. The upside is simplicity and potentially cost savings; the downside is you pay for everyone, even if not all use all products (true enterprise license). Consider this if your utilization of each product will indeed be high across the board, and you want simplicity.
• Volume Bundling: Even if metrics can’t be unified, you can bundle the sales motion. For instance, leverage the spend on one product to get a better price on another. “If we add Ariba now (based on spend metric) to our portfolio, we expect $Y million in spend through it – we want a commensurate discount on our SuccessFactors renewal as part of this larger partnership.” Essentially, trade-offs: SAP as a vendor looks at total account value. If you commit to increasing that by adopting another cloud product, ask for concessions on existing ones.
• Enterprise Cloud Agreements: SAP has, in some cases, offered a contract similar to Microsoft’s enterprise agreements, which is akin to an all-in-one cloud contract. These might involve a committed annual spend on SAP cloud, a pool of money that you can allocate to different services as needed. For example, you commit to $5 million per year that can be used across any of SAP’s cloud products, with the ability to flex your usage. If you go over in one, you draw more from the pool; if you go under, you may use credits for another. This model is not common, but if you’re a very large customer, it’s worth inquiring about. It provides flexibility to move licenses between products without needing to renegotiate each time. If such an agreement is available, carefully review how consumption is measured for each product, as different metrics need to be converted into a common currency for your commitment.
• Co-Termination Discounts: Another approach to consolidation is to explicitly request a discount or incentive from SAP for co-terming and bundling. SAP knows that giving you a single renewal gives you power, so they might preempt that by offering a better upfront deal if you sign a combined contract. For example, “sign a 3-year contract for SF, Ariba, and Concur all together and we’ll give an additional 10% bundle discount on each.” Always ask – the worst they can say is no.
• Watch Out for Locked-In Waste: The flip side of consolidation is inflexibility. If you bundle too many services, what if one of them no longer meets your needs? You don’t want to be stuck with an indivisible contract if, say, you decide to switch Concur to another vendor but can’t drop it because it’s tied into an enterprise bundle. One solution is to negotiate carve-out options, such as the ability to drop or replace one component at renewal without canceling the entire deal. Or keep some less critical services on separate contracts if you anticipate possible replacement.

In summary, structure your SAP cloud contracts with the long term in mind: minimize automatic cost escalations, maximize your ability to adjust to actual usage, and use the weight of your combined spend to get better terms. Every percentage point of discount or flexibility can translate to significant savings or avoided costs over time.

Integration and Indirect Use Considerations

One often overlooked aspect of SAP cloud licensing is how these cloud applications interact with your core SAP systems and other third-party systems. Indirect use (also known as indirect access) has historically been a significant issue in SAP licensing.

It occurs when users or systems that are not directly licensed on SAP ERP nonetheless access SAP ERP data or functions via an interface. In the context of the cloud, there are two main scenarios to consider:

1. SAP Cloud → SAP On-Premise (or Private Cloud) ERP Integration: For example, SuccessFactors or Ariba is integrated with SAP ECC or S/4HANA (on-premises). If the cloud application automatically creates or modifies data in the ERP, SAP might consider that an act that requires an ERP license. A classic example is Ariba creating a purchase order in ECC – previously, SAP might have said that each Ariba user needed an ECC user license or that this was indirect access. To resolve confusion, SAP introduced the Digital Access Document Model a few years ago. Under digital access, you license ERP by the number of documents (business objects, such as Sales Orders, Purchase Orders, Financial Journal Entries, etc.) created by external systems. So, if Ariba is feeding 10,000 purchase orders into S/4HANA annually, you need to have a digital access license covering those documents (or equivalent named user licenses).
   • Mitigation: Check if your organization has adopted SAP’s digital access licensing; many were given a trade-in option. If so, ensure you track documents from cloud integrations. If not, you must strictly ensure that any access to SAP ERP from cloud users is licensed. Often, the simplest approach is to have a blanket “SAP Platform User’ license for any system ID or integration user that it covers. Still, SAP’s auditors may push the document model. Clarify with SAP in writing how they treat the specific integration. Sometimes, SAP will explicitly waive indirect use claims for its cloud products (since you’re already paying for Ariba or SF), but don’t assume this – get it documented. A positive sign: SAP’s literature differentiates between “direct/human” and “indirect/digital” access and tries to clarify the rules. Still, many customers have been caught off guard.
   • Audit Readiness: If you get an SAP license audit, be prepared to demonstrate how cloud systems connect to on-prem ones. Show that you have licenses for any high-volume interface. For example, if Concur is creating expense documents in S/4, show that you accounted for those either under an Employee Self-Service license or digital document count. This proactive stance can prevent audit findings of unlicensed use.
2. Third-Party → SAP Cloud Integration: Conversely, if you have non-SAP systems accessing data in an SAP cloud application via APIs, you should check the cloud app’s terms. Generally, SAP cloud products are licensed by metric regardless of how the data is accessed. For example, if you pull data from SuccessFactors via API into a custom app, as long as the users pulling data are properly licensed in SF (or it’s an internal integration), you are fine – there’s no separate “indirect SF” concept to worry about; you just can’t exceed your user count or use the data beyond allowed purposes. But ensure that integration users (API service users) are also licensed if required. Some cloud APIs allow service technical users who don’t count toward the license, but others might require a named user for API access. Check the SAP cloud application’s policy on APIs.
   • One special integration consideration: using SAP Integration Suite (CPI). If you use SAP’s integration middleware to connect apps, it is a licensed cloud service (usually part of BTP) in itself. While not “indirect use” in license terms, remember that high volumes of messages or transactions through your integration platform can increase your integration service subscription cost, as the number of messages or connections often determines these costs. So, indirect costs can creep in via the integration layer.

Data Residency and Privacy: Region-specific integration issues can arise, too. For instance, European privacy laws (GDPR) mean you must control where personal data flows. If you integrate SuccessFactors (EU data center) with a US-based third-party system, you might violate data transfer rules.

While not a licensing issue per se, it can impact how you architect solutions. Sometimes, companies choose to disable certain logging or data export features to comply with privacy regulations, but this can also result in losing some usage tracking that could help with license compliance. It’s a balancing act. Always document integrations and any assumptions about licensing.

Summary of Indirect Use Best Practices:

• Map out every integration between SAP cloud apps and other systems. Classify each as SAP-to-SAP vs third-party-to-SAP.
• For SAP-to-SAP (cloud to on-prem), involve your SAP account team to get written clarification on license needs. If they indicate digital access documents cover it, ensure you have that license. If named users are required (which is less common now), budget for them.
• Monitor document counts generated by integrations. SAP provides tools and notes for counting documents, especially if you opted for digital access licensing. You may have a certain number of documents included and need to know if you’re nearing the cap.
• Consider technical controls: If a certain integration could create unbounded documents, put limits or alerts (e.g., if an error in a non-SAP system could spam SAP with thousands of transactions, inadvertently causing a license headache, you’d want to catch that).
• Finally, include in your contracts or Order Forms any assurances about the use of integration. For example, some customers have negotiated clauses like, “Use of SAP SuccessFactors Employee data by the customer’s SAP ERP for payroll processing shall not require an additional SAP ERP named user license.” Getting such clauses is ideal (though not always granted). It at least shows intent that SAP shouldn’t double-charge for their integrated scenario. If you can’t get that, then be very clear on how you’ll license both ends.

Real-World Examples and Scenarios

To illustrate the concepts above, here are a few anonymized examples based on real situations where SAP cloud licensing (or lack thereof) had a significant financial or compliance impact:

• Example 1: Overestimating HR Licenses Leads to Wasted Spend – A global manufacturing company purchased SuccessFactors Employee Central for 50,000 employees, paying for full user licenses for all of them. After a year, the analysis showed that only around 35,000 employees had ever logged in or used any SF features; the rest were production line workers who never accessed the system. The company had essentially over-licensed by 15,000 users, equating to several hundred thousand dollars in unused subscriptions. Unfortunately, the contract had no provision for adjustment, so those licenses remained paid for through the term. At renewal, the SAM team used this data to negotiate a true-down to 35,000 users and shifted the remaining budget toward Talent Management modules for the active users. The lesson: start with realistic user counts (perhaps core HR for all, but additional modules only for relevant populations) and push for flexibility to reduce counts if usage is lower than expected.
• Example 2: Indirect Access Surprise from Ariba Integration – A services company integrated SAP Ariba with their on-prem ECC system to automatically create Purchase Orders and Goods Receipts from Ariba Network transactions. During an SAP audit, the auditors flagged that approximately 20,000 documents had been created in ECC by “Ariba users” who did not have ECC licenses. SAP initially assessed a hefty license fee for these indirect users. The customer had assumed the Ariba subscription covered everything. After negotiations, the outcome was that the customer purchased SAP’s Digital Access licenses for documents, converting their usage to the new model and avoiding individual named user charges, which would have been even more expensive. It was a costly lesson – roughly $ 250,000 in unplanned spending – that could have been avoided had the integration licensing been clarified and budgeted upfront. Post-incident, the company carefully metered all SAP interfaces and ensured compliance under digital access entitlements in the future.
• Example 3: Concur Volume Spike and Lack of True-Down – A multinational firm signed a 3-year Concur Expense deal in 2019 based on 5,000 active users. In 2020, global travel halted, and only about 1,000 people filed expenses (and very few reports at that). The company was paying for 5,000 users regardless, essentially overpaying for two years. They hoped to reduce the user count, but the contract didn’t allow for mid-term adjustments. At renewal in 2022, SAP even attempted to impose the standard uplift on the 5,000-user price, despite the customer’s utilization being only 20% of that. The SAM team used this as leverage, arguing for a price decrease or at least a reset of the baseline. They managed to re-sign for 3,000 users at a lower unit price, with an agreement that if travel resumes to full 5,000, they can ramp up at the same per-unit cost. This scenario underlines the importance of pandemic or unforeseen event clauses – some vendors offered relief, but not all. Having a flexible contract can save money in sudden usage downturns.
• Example 4: Fieldglass Compliance Risk via MSP – A large energy company outsourced its contractor management to a Managed Service Provider (MSP), which used SAP Fieldglass. The MSP was responsible for licensing Fieldglass. During an internal review, the energy company discovered the MSP had been allowing project managers direct access to Fieldglass to approve timesheets. Still, those managers were not declared as licensed users under the MSP’s contract. Essentially, more than 50 internal managers were using Fieldglass without proper licenses, as the MSP had only counted the contractors. This exposed both the MSP and the company to compliance risk with SAP. Ultimately, the company had to work with the MSP to purchase additional “buyer user” licenses for those managers and implement a process to track anyone given access. The incident showed that even when you offload operations to a third party, you still need to maintain visibility into license compliance. The customer added contract language, making the MSP liable for any license violations and requiring regular reports on system access.
• Example 5: Multi-Cloud Co-Termination Yields Negotiating Win – A consumer goods firm had separate contracts for SuccessFactors, Concur, and an SAP Commerce Cloud solution. Each had a different end date and was handled by a different SAP sales team. The firm’s CIO noticed they were spending a lot in total but not getting enterprise-level discounts. The SAM manager orchestrated aligning all three renewals to the same date. In the consolidated negotiation, they leveraged the total annual spend (several million dollars) to get SAP to agree to a global 3% cap on price increases (down from 5 %+ in some contracts) and a 15% bundle discount applied to each product’s fees. In exchange, the firm signed a 4-year committed term for all products together. This saved an estimated $500K over the term compared to the status quo. The risk was that they had to commit to a long-term solution even if one underperformed, but they mitigated that by securing strong SLAs and governance in the contract. This case exemplifies using co-termination as leverage to treat the relationship more holistically,y rather than a one-by-one product purchase.

Each of these scenarios highlights key themes: know your usage deeply, don’t assume anything about SAP’s leniency regarding indirect usage, and use hard data to negotiate. Financial and compliance impacts can be significant, but with proactive management, they can be turned around or avoided entirely.

Region-Specific Considerations

SAP’s licensing policies are generally global, but some regional practices and regulations can affect how you manage and negotiate cloud licensing:

• EU Data Privacy and Sovereignty: In the European Union, laws like the GDPR restrict how personal data (including user IDs, names, and usage logs) can be handled. European customers and workers’ councils may object to detailed monitoring of user activity due to concerns about privacy. This can impact SAM in that you might not be allowed to use a tool that tracks named user login frequency, if it’s seen as employee surveillance. A way to handle this is to anonymize or aggregate data when analyzing usage (e.g., focus on license counts and overall login rates rather than who did what). Also, EU customers often require that data be hosted and supported from within the EU. SAP offers an “EU Access Only” option for many cloud services, which ensures that all support and processing stay in Europe to comply with sovereignty needs. However, this comes at a premium (up to a 15% add-on cost)​. If your organization needs this, be sure to budget for it and include it in the contract. It’s better to negotiate it upfront than to realize later you need to add it (which could give SAP leverage to charge even more).
• Works Councils (Germany and beyond): Especially in countries like Germany, works councils may need to approve software that affects employees. They might insist on contract clauses that protect employees, for example, ensuring that if an employee doesn’t use the software, the company isn’t forced to keep their license, which could encourage turnover and avoid wasteful spending that could impact jobs. While SAP may not directly entertain works council input, if you have such internal requirements, use them as justification in negotiations (“Our works council will only approve if we include XYZ usage flexibility…”). On the other hand, works councils might also slow down user provisioning, which could affect rollout. This could mean you ramp up licenses more slowly. If deployment will be staggered due to approvals, try to include ramp-up phases in the contract.
• Local Pricing and Currency: SAP sells in local currencies and sometimes has regional price lists. If your organization operates globally, you may have separate contracts per region. There’s a potential arbitrage or fairness issue: maybe your European division pays a higher per-user price than your US division, due to when contracts were signed or local list differences. A strategy here is to consolidate globally to get the best price for everyone, taking into account currency exchange rates if needed. If global consolidation isn’t feasible, at least benchmark across regions and push SAP to harmonize pricing. Also, watch out for currency clauses – if you sign a contract in euros but your budget is in dollars (or vice versa), consider fixing the exchange rate or setting caps if the currency fluctuates, to avoid budget surprises.
• Regulatory Requirements for Cloud (Public Sector): If you operate in a regulated industry or the public sector, additional provisions may be required. For example, the US public sector requires FedRAMP authorization for cloud services – SAP Concur has a FedRAMP environment for government. In such cases, ensure you’re on the correct, compliant version, which may be more expensive or have certain limitations. Similarly, some countries require data localization (e.g., Russia in the past, or China has strict rules) – SAP might offer local instances with different terms. Always align your contract with any regulatory compliance needs in each region to avoid legal issues that could force a costly change later.
• Tax Implications: In some countries, the licensing of software (user vs. service) can have tax implications, such as VAT or GST. While not usually a negotiable item with SAP (tax is what it is), it’s worth consulting with tax specialists. For instance, if you’re importing a service, there might be a withholding tax. SAP might gross up prices to account for it, or you might be responsible. Clarify these responsibilities in the contract, specifically in the “Taxes’ section of the cloud agreement.
• Support and Response Times: Different regions may have default support Service Level Agreements (SLAs) due to time zones or support center locations. If you need 24/7 support globally, ensure the contract specifies that. It might not change licensing cost, but failing to do so could mean downtime or issues in one region if support is only 9-5 elsewhere. Some customers in the Asia-Pacific region have found that they felt they were second-tier in support priority. The solution was to negotiate a premium support package or a named support contract. These can cost extra, but you may be able to negotiate some of them for free when making a big purchase.

In essence, familiarize yourself with the local landscape, including legal requirements, customary business practices, and internal policies, in each region where you operate. Incorporate those into your SAP cloud licensing strategy.

What works as a standard clause in one country might be unacceptable in another. By addressing these region-specific issues upfront, you can avoid compliance problems and ensure that software usage is optimized and accepted by all stakeholders, including employees.

Recommendations

In conclusion, managing SAP cloud application licensing requires a combination of technical expertise, contractual knowledge, and proactive governance.

Below is a summary of key recommendations for SAM managers and SAP licensing professionals to successfully navigate this space:

• 1. Inventory Your SAP Cloud Usage: Maintain an up-to-date inventory of all SAP SaaS products in use (SuccessFactors, Ariba, Concur, Fieldglass, etc.), including modules enabled, user counts, and key usage metrics (spend, transactions, etc.). Regularly review this alongside your entitlements to spot over- or under-utilization.
• 2. Establish Internal License Owners: Assign clear ownership for each cloud application’s licenses. For example, HR operations for SuccessFactors, procurement for Ariba, and the finance and travel team for Concur. These owners should work with SAM to forecast usage, flag organizational changes (such as acquisitions or divestitures) that affect licenses, and promote compliance (e.g., ensuring user offboarding processes are in place).
• 3. Leverage Available Tools and Reports: Use the compliance tools provided by SAP (such as SuccessFactors License Compliance reports) and analytics. Many cloud products have admin dashboards showing active users or documents processed. Implement internal dashboards that track license consumption vs purchased quantities in near real-time. This data is gold during renewal negotiations.
• 4. Implement Strict User Lifecycle Management: Integrate your HR and IT processes with license management. When an employee is hired, determine if they need access to each SAP cloud system and assign it accordingly (not everyone may need access to all systems). When an employee leaves or a contractor’s project ends, immediately remove or deactivate them from all SAP systems. This prevents “license creep” of inactive users consuming licenses. Automation (through an IAM system) can be very effective here.
• 5. Negotiate Flexibility in Contracts: Whenever possible, include clauses for flexible growth and shrinkage. Push for things like: ability to increase users mid-term at predetermined rates (so you’re not stuck renegotiating under pressure), ability to temporarily exceed spend/transaction limits with notice (perhaps paying true-up after), and as mentioned, rights to reduce at renewal. If standard true-down is denied, consider asking for pool licenses (e.g., a pool of 1000 users that can be shared between SF and Concur, etc.) or other creative arrangements.
• 6. Co-Term and Consolidate Wisely: Plan a roadmap to co-terminate contracts when it makes sense to leverage them, but time it strategically. Don’t co-term simply for ease if you’re not prepared to negotiate the bundle firmly. Do it when you have executive buy-in to possibly drop or substitute products if SAP doesn’t come to the table with a good offer. And whenever you add a new SAP cloud service, try to align its end date with the rest, even if it means doing a shorter initial term or a longer one. This gives you one bite at the apple for all.
• 7. Monitor Indirect Usage and Get Clarity in Writing: Do a thorough analysis of data flows between your systems. For each integration involving SAP data, determine if indirect use licenses apply. Engage with SAP early to confirm the rules (and get it in writing, such as via email or a contract addendum). It’s easier to handle indirect licensing proactively (possibly negotiating a discount on digital access if you bundle it) than to deal with it during an audit under pressure. Also, keep evidence (such as system logs) that shows the volumes of documents from integrations – this helps size any digital access licenses correctly, rather than overbuying “just in case.”
• 8. Optimize License Types and Tiers: Many SAP cloud products offer different license tiers or types (as we saw: full vs functional users, professional vs self-service, etc.). Regularly review if users are on the appropriate type. Perhaps some heavy users don’t need to be, or vice versa. Also, revisit your spend or transaction bands – if your usage consistently falls at the low end of a band, you might consider negotiating down to a smaller tier at renewal. Conversely, if you’re close to a threshold, address it before an audit forces you over it. Fine-tuning license allocations can yield significant savings with no impact on operations.
• 9. Engage Stakeholders with Real Examples: Use scenarios like the ones above to educate procurement, finance, and IT leaders about the importance of license management. Sometimes budget holders balk at spending effort on SAM until they see what can go wrong. Sharing a case where a company paid millions in audit penalties (or, positively, saved millions through good negotiations) can build support for your efforts. Internally, treat SAP SaaS just as seriously as on-prem license compliance – it’s not “all you can eat” just because it’s cloud.
• 10. Stay Current on SAP Licensing Policies: SAP frequently updates its cloud services and sometimes its licensing models. Subscribe to SAP’s official licensing updates or join user groups (like ASUG or SAP user community forums) where licensing is discussed. For instance, if SAP decides to change Ariba pricing or offers a new unlimited model for one of the products, you want to know early to consider taking advantage of or avoiding pitfalls. Similarly, keep an eye on any upcoming SAP audits or contract renewal cycles – mark calendars well in advance.

By following these recommendations, SAM managers and SAP licensing professionals can mitigate the most common risks associated with SAP’s cloud licensing, keep costs aligned with actual business usage, and maintain a strong negotiating position with SAP.

The goal is to transform what is often seen as a daunting, vendor-favoring area into a well-managed and transparent part of your IT asset portfolio. With diligent management and a customer-advocate mindset, you can ensure your organization gets full value from SAP’s cloud solutions at the lowest necessary cost and with minimal compliance risk.

Do you want to know more about our SAP Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit