SAP Licensing Guide for ITAM Practitioners

SAP Licensing Guide for ITAM Practitioners

• Named User Licenses: Individual-specific access
• Package Licenses: Based on usage metrics like the number of transactions or data volume
• Subscription Licenses: Monthly or annual payment model
• Engine Licenses: Based on system usage and capacity

SAP Licensing Guide for ITAM Practitioners

Introduction:

Managing SAP licenses is critical for IT Asset Management (ITAM) professionals. SAP’s product portfolio spans traditional on-premise ERP to modern cloud services, each with complex licensing models.

A proactive ITAM approach can prevent compliance pitfalls and optimize costs.

This guide offers a comprehensive overview of SAP licensing fundamentals and strategies, providing an independent and customer-centric perspective.

We’ll cover everything from license types and metrics to cloud subscriptions, indirect access concerns, audits, and optimization techniques, concluding with actionable recommendations for ITAM practitioners.

License Fundamentals: Perpetual vs. Subscription Models

Perpetual Licensing: SAP historically sells perpetual licenses, which grant the customer the right to use the software indefinitely.

Key characteristics include:

• One-Time Purchase: A large upfront license fee for perpetual use, often supplemented by an annual support fee (typically around 20–22% of the license cost) for maintenance and updates.
• Maintenance Contracts: Staying on maintenance requires ongoing support (bug fixes, upgrades). If support is dropped, the software can still be used in its last supported state, but without new patches or help from SAP.
• Ownership of Entitlements: The customer “owns” specific license entitlements (number of users, engines, etc.) as assets on their books. This can create shelfware if unused licenses accumulate, but it also provides flexibility to reallocate licenses internally as needs change.

Subscription Licensing:

With the shift to the cloud, SAP offers subscription-based licenses (SaaS and PaaS offerings) and newer S/4HANA contracts, such as RISE with SAP.

Features of subscription models:

• Pay-as-You-Go: Licenses are essentially rented. Customers pay recurring fees (monthly or annual) to access the software. There is no perpetual use right – if you stop paying, access is lost.
• All-Inclusive Bundles: Subscription fees often include software, support, and sometimes infrastructure. For example, SuccessFactors or Concur subscriptions bundle support costs, and RISE with SAP bundles cloud hosting and support with the software license.
• Operational Expenses (OPEX): These are easier to budget as predictable, periodic costs; however, over a long period, subscriptions may cost more than a one-time, perpetual purchase. ITAM must weigh the trade-offs (upfront CAPEX vs. long-term OPEX).
• Flexibility: Scaling up or down can be easier. For example, adding more users for a cloud service typically means adjusting the subscription count. However, reducing subscriptions might only take effect at renewal and is subject to contract terms.

License Acquisition and Documents: Regardless of model, all SAP entitlements are defined in formal ordering documents.

Typically, an SAP Order Form or contract Schedule will list the products, metric definitions, and quantities purchased.

ITAM practitioners should:

• Ensure they have copies of all SAP license agreements, order forms, and SAP Software Use Rights documentation for reference.
• Verify that the metrics and rights in the contract align with your understanding (for example, understand what a “Professional User” allows or what a package metric like “orders per year” entails).
• Track purchase history, including any special amendments (such as migration credits or special discount arrangements), since these affect how licenses can be used or exchanged later.

Real-world example: In 2018, a global manufacturer negotiated an SAP license contract for 500 Professional User licenses and several engine metrics. The ITAM team maintains the original order form and SAP Price List definitions, which prove invaluable when interpreting usage rights during an audit years later. By knowing the exact contract language, they avoided non-compliance when deploying a new SAP module, ensuring it was covered under their existing entitlements.

Read more about SAP License Models.

SAP License Types and Metrics

SAP’s licensing types are broadly divided into Named User licenses and Package (Engine) licenses, each with specific metrics:

• Named User Licenses: Almost all SAP environments require each human user to have a license. A Named User is authorized to use SAP software, and licenses are assigned by user type. User categories differ by level of access:
  • Professional User – Full operational access across SAP modules. This is the most powerful (and expensive) named user type, intended for users who perform a wide range of tasks (e.g., an SAP finance specialist or a supply chain manager who uses many transactions).
  • Limited Professional / Functional User – A moderate-level license for users who perform limited or specific functions. For example, a Functional User might be restricted to a specific domain (such as HR or procurement) without the broad permissions of a Professional. (Note: In S/4HANA, “Limited Professional” is phased out in favor of new categories like Functional and Productivity users – see the S/4HANA section below.)
  • Employee / ESS User – A low-level named user mainly for self-service scenarios. Often used for employees who perform basic tasks, such as time entry, expense submission, or viewing their HR data.
  • Developer User – A user license that includes rights to development tools (ABAP workbench, etc.). SAP typically requires any individual doing configuration or development in the system to have a Developer license (which also covers professional use of the system). This license type is more expensive but is limited to those who require programming access.
  • Other Specialized Users: Depending on the price list, there are variants like indirect access users, employee self-service, shop floor/worker, etc. Each has limitations—for instance, a Warehouse Worker user might only be able to allow transactions in logistics execution and not in finance. You also have Project user licenses.

Management Tip:

Maintain a clear mapping of job roles to SAP user license types in your organization.

This governance ensures, for example, that a customer service representative is assigned a “Limited” user license if appropriate, rather than a full Professional license, thereby preventing unnecessary costs.

Conversely, ensure that no one performing high-level tasks is assigned a low license (risking compliance).

Periodic reviews of user roles vs. license assignment are an ITAM best practice.

• Package (Engine) Licenses: In addition to users, SAP sells licenses for specific software modules or “engines,” measured by business metrics. These are typically the SAP add-ons or functional components (e.g., SAP modules for Payroll, SAP Industry solutions, databases, etc.). Common metric examples include:
  • Processor/Core Based – Some older metrics (and database licenses) count the number of CPU cores. For instance, SAP ERP packages on legacy price lists sometimes had “CPU” metrics. SAP HANA database licenses are sold in increments of 64GB of memory (effectively, hardware sizing).
  • Employee or Capacity-Based—SAP Payroll may be licensed per employee processed, SAP Supplier Relationship Management per number of vendors, SAP CRM marketing by number of contact records, etc.
  • Transactions or Orders—For example, an SAP Sales & Distribution engine could be licensed by the number of sales order line items processed annually, or SAP Environment Health & Safety licensed by the number of incidents recorded.
  • Revenue or Spend – Some licenses (especially industry solutions) are tied to financial metrics. For example, a retail industry engine might be licensed based on a certain revenue threshold managed through the system, or the Ariba Network is licensed by spend volume (more on Ariba later).
  • Concurrent Sessions—A few products (like older SAP BusinessObjects or SAP NetWeaver components) might use concurrent sessions or connection limits as a metric.

Example: An enterprise might license the SAP Treasury and Risk Management module as an engine with a metric “Number of Financial Transactions per year.” If they purchased 100,000 transactions/year and their usage grows to 120,000, they are out of compliance and need additional licenses. ITAM should monitor such usage metrics (often via reports or manual logs, as SAP may not automatically restrict access when limits are exceeded).

Combining User and Package Licenses:

Typically, a user license permits a person to use any licensed package that the company owns, within the rights granted to their user type. For instance, if you own the SAP Payroll engine and an HR Professional user license, that user can execute payroll transactions.

However, if you haven’t licensed the Payroll module, no user can use it.

ITAM must, therefore, manage both dimensions: ensure there are enough named users for all users accessing the system, and license each module/engine for the required usage levels.

Ordering and Documentation:

In practice, your SAP order form will list line items like “SAP ERP Package – 500 Professional Users” and “SAP Payroll Processing – Up to 10,000 Employees”, etc.

It’s crucial to read the definitions (often in SAP’s Software Use Rights document or footnotes on the order form) to know exactly how SAP defines each metric.

Keep an eye on special limitations in the footnotes (e.g., a package may include a restricted-use database license, or an engine may only be used with specific SAP components).

Read the Hybrid SAP Licensing Guide for Two-Tier Environments.

S/4HANA Licensing: New Models and Migration Considerations

SAP S/4HANA, the next-generation ERP, introduced updates to licensing that ITAM practitioners must navigate carefully:

• New User Categories: S/4HANA’s on-premise licensing has streamlined user types compared to ECC. The common S/4HANA named user licenses are:
  • Professional Use – Broad usage rights across the S/4HANA Enterprise Management suite (similar to the old Professional User).Functional Use – A tier below Professional. Functional users have full access to specific functional areas (e.g., sales, procurement, manufacturing, and finance individually), but not all areas. Many “Limited Professional” users in ECC can be mapped to Functional Users in S/4. For example, a salesperson who only works with sales and CRM functionality might be a Functional user. Productivity Use – A lighter user for basic tasks and self-service scenarios in S/4HANA. This might cover employees who need only casual access, approvals, or data inquiry, but not end-to-end transactions. (Sometimes also called Worker or Employee, used in literature.)Developer Use – A similar concept to before, covering development tools in S/4HANA.
  Mapping ECC to S/4: One challenge is that older ECC user types (e.g., Limited Professional, Employee Self-Service) don’t have one-to-one equivalents in S/4. Companies must analyze each user’s activities during migration to decide the appropriate S/4 license type. For instance, what was a “Limited Professional” may become either a Functional or Productivity user depending on actual usage. This is an opportunity to optimize (downgrade heavy users to cheaper categories if possible) and a compliance risk if not done correctly.
• Modular Engines and Digital Core: S/4HANA Enterprise Management (often referred to as the digital core) encompasses core ERP functionality, but many add-ons require separate licenses. For example, Extended Warehouse Management (EWM), Transportation Management, or Central Finance might be separate S/4 engines. Ensure you understand which functions are included in the base S/4 license and which require additional entitlements. SAP provides an S/4HANA price list, where engines are listed with metrics (some engines have changed metrics in S/4 versus ECC).
• Greenfield vs. Brownfield Licensing: “Greenfield” refers to new S/4HANA implementations (fresh start), whereas “Brownfield” is converting an existing ECC system in-place to S/4. From a licensing perspective:
  • Greenfield customers are negotiating a new S/4HANA contract. This is similar to any new purchase – you estimate the number of needed users and engines and buy accordingly (subscription or perpetual). There’s no direct credit for past ECC investments; however, customers often use competitive bidding or trade-in discussions to obtain discounts when replacing legacy systems.
  • Brownfield customers often engage in a license conversion program with SAP. SAP has offered conversion tools and programs that enable your existing ECC licenses to be mapped to S/4HANA equivalents. Typically, you migrate your contract; for example, your ECC Professional Users might be converted into S/4HANA Professional Use licenses. In many cases, SAP requires a contract conversion or, at the very least, a license exchange process – you don’t automatically receive S/4 usage rights simply by technically upgrading. ITAM should work closely with SAP on a License Conversion Agreement: often, there’s a fee or uplift for new functionality.
    • Some companies keep their existing ECC licenses and buy supplementary S/4 licenses for the new system in parallel (especially if running ECC and S/4 side by side during transition). SAP has pushed formal conversions in recent years to streamline contracts.
    • Beware of timing: Running ECC and S/4 simultaneously for migration can temporarily double usage. Ensure your licenses cover both environments, or negotiate temporary licenses for the duration of the project.
• S/4HANA and Database Licensing: One notable change is that S/4HANA requires the HANA database. For on-prem deployments, you must license SAP HANA (unless you go with a subscription model where HANA is included). HANA can be licensed as Runtime (cheaper, intended for use with SAP applications) or Full Use (if you plan to build non-SAP applications on the HANA platform). ITAM should verify if the S/4 contract includes HANA runtime licenses; if not, that’s an additional engine to account for (licensed based on memory size). The HANA database is included in the RISE with SAP subscription (covered next).
• Full Usage Equivalents (FUE): In some S/4HANA contracts, SAP introduced the concept of FUEs – a points-based system where each user type is a fraction of a “full” user. For example, 1 Professional = 1.0 FUE, Functional = 0.5 FUE, Productivity = 0.1 FUE (hypothetically). SAP might sell S/4 licensing in blocks of FUEs rather than fixed counts of each user type, giving flexibility in how you mix users. ITAM should understand if their contract uses FUE pools, as managing the mix of user types within that pool becomes important.

Example:

A large utility company planning a brownfield S/4HANA conversion discovered that many of its 1,000 ECC Limited Professional users could be covered by S/4 Functional Use licenses, which are more permissive in specific areas.

By cleansing unused accounts and adjusting license types before the contract conversion, they reduced their required FUE count by 20%, yielding significant savings on the S/4 license quote.

Conversely, they identified that a few new S/4 engines (like Embedded EWM) would be needed, which they negotiated to include in the conversion deal rather than paying full price later.

RISE with SAP: Bundled Subscription Offering

RISE with SAP is a relatively new offering (launched in 2021) that bundles SAP’s software and infrastructure into a single subscription contract.

It is often positioned as a pathway to S/4HANA in the cloud. Key aspects for ITAM:

• What’s Included: RISE with SAP is an all-in-one bundle. Typically, a RISE contract includes:
  • SAP S/4HANA Cloud—This can be the Public Cloud (a multi-tenant SaaS version of S/4) or the Private Cloud Edition (PCE), which essentially hosts S/4HANA in a private environment. The subscription covers the S/4 software licenses for your users. (There is no separate named user licensing to track—it’s embedded in the subscription via the FUE count or similar metric you contract for.)
  • Infrastructure & Technical Management – SAP partners with hyperscalers (Azure, AWS, GCP) or can use SAP’s data center to host your S/4 system. The cost of infrastructure and base technical services (backup, updates, monitoring) is included. This means you don’t need a separate hosting contract; however, you are tied to SAP’s provided service levels, and you relinquish some control over the environment (SAP manages the OS, Basis, and upgrades according to a schedule).
  • SAP Business Technology Platform (BTP) – RISE bundles a starter package of BTP (formerly SAP Cloud Platform) credits or services. BTP is SAP’s PaaS for extensions and integrations. Under RISE, SAP encourages keeping the core S/4 standard and doing custom extensions on BTP. The contract may include a certain amount of BTP usage (for workflows, integrations, and analytics), providing a platform for custom apps.
  • Additional Cloud Services: Depending on the deal, RISE often includes some ancillary SAP services:
    • SAP Signavio (Process Insights/Modeler) to analyze and model processes (a fixed user count might be included to help you optimize processes for the S/4 transition).
    • Possibly starter rights to SAP Business Network starter pack (Ariba Network basic access for suppliers, etc.), or other SAP cloud services as incentives.
  • Support & SLAs: RISE is subscription-based, so SAP provides support (Enterprise Support, cloud edition) as part of it. The contract will have cloud-specific SLAs for uptime, etc. You no longer pay separate maintenance – it’s baked into the subscription.
• Licensing Implications: With RISE, you stop counting individual licenses, such as users or engines, on-premise; instead, you commit to a specific scope within the subscription. For example, a RISE contract might be sized by “Full Usage Equivalent” users and system size. Indirect usage is also typically covered as part of the bundle (SAP’s stance is that digital access is included in RISE for S/4HANA Cloud). This can simplify license management day-to-day (fewer internal audits needed), but it shifts the model entirely to a service subscription:
  • You lose some flexibility – if you need a new SAP module or additional users mid-contract, you must amend the RISE subscription (usually at the set pricing). Conversely, if you over-provision, you may be stuck paying for unused capacity until the next renewal.
  • The contractual commitment is significant, often spanning multiple years (3-5 years). ITAM should forecast usage carefully to avoid overcommitting. Unlike perpetual licenses, which can be purchased incrementally, RISE often requires a broad commitment upfront (though additional purchases can be made later).
  • Cost structure: All costs are OPEX. Ensure that the total cost of RISE is evaluated against your current spend (license amortization + support + infrastructure + personnel). Some customers find that RISE can be more expensive over the long run, although it offloads a significant amount of internal overhead.
• Contract Considerations: RISE contracts differ from traditional licenses:
  • Conversion of Existing Licenses: SAP offers a program that allows you to convert your existing maintenance value into credits if you migrate to RISE. For example, if you have a significant investment in on-premises licenses, SAP might offset some cloud subscription costs (or allow you to park those licenses while on RISE). ITAM should ensure that any conversion or credit terms are documented. (Usually, on-prem licenses go into a hibernation state while on RISE subscription; if you revert off RISE later, you might be able to re-activate them, but this should be clarified in the contract.)
  • Exit Strategy: Understand what happens after the RISE term ends. Since you don’t own the licenses outright, if you choose not to renew, you will lose the rights to run S/4, unless you negotiate a conversion back to on-premises or another model. For risk mitigation, some customers negotiate contract clauses for a smooth transition (for instance, a right to convert to perpetual at the end of the term at a predetermined cost). This might not be standard, but it’s worth considering.
  • Customizations and Add-Ons: In a private cloud RISE, you can bring your custom code and even certain third-party add-ons. However, certain highly customized integrations may not be permitted or may incur additional managed service fees. Ensure that all critical components (e.g., third-party bolt-on software or specific integration servers) are allowed or accounted for under the RISE framework.
  • Scope of Services: Clarify which responsibilities SAP handles vs. your team or a partner. RISE includes basic Basis administration and system upgrades, but you may still need internal or partner resources for application-level support, custom code management, testing upgrades, and other related tasks. From an ITAM standpoint, you’ll manage fewer “technical” assets (servers, DB licenses). However, you still manage software usage rights for any systems not covered by RISE (e.g., if you still have some on-premises legacy SAP systems outside of RISE).

Example: A mid-sized enterprise with an aging ECC system opted for RISE with SAP to transition to S/4HANA with minimal infrastructure investment. Their RISE contract included S/4HANA Private Cloud for 250 FUEs (roughly covering 300 users of various types), SAP BTP, and Signavio.

The ITAM manager ensured their legacy ECC licenses were suspended and gave them the right to restart if needed (protecting the investment). After moving, license compliance became simpler (no more annual SAP audits on user counts).

Still, she diligently tracks the user count against the FUEs to ensure they don’t exceed contract terms. If their business grows beyond 250 FUEs, that triggers a contract expansion or true-up with SAP.

Indirect Access and Digital Access Licensing

One of the trickiest aspects of SAP licensing for ITAM is indirect access, when external systems or users use SAP to bypass the standard named-user login.

SAP’s position is that if third-party systems or automated processes interact with SAP, those interactions must be licensed.

This became notorious due to high-profile cases (e.g., the Diageo lawsuit), leading SAP to introduce a new model to address it.

Understanding Indirect Access: Indirect use can take many forms:

• Non-SAP systems read or write data to SAP through interfaces (such as APIs or intermediate tables).
• Users not logging into SAP directly trigger SAP transactions via another application. For example, a customer placing an order on a web portal that then creates an order in SAP is an indirect user of SAP.
• Robotics or automation (RPA) scripts that manipulate SAP data without a human user.
• Even simple scenarios, such as exporting data from SAP and then using it externally, could be considered uses if updates occur in SAP.

In the past, SAP’s license auditors would attempt to count all such scenarios under named user licenses. That could mean thousands of external users or devices needing pricey licenses, which was considered punitive and unclear.

Digital Access Document Model

In 2018, SAP introduced the Digital Access licensing option. Instead of licensing indirect interactions by user, it licenses by documents created.

SAP identified nine key document types that represent business outcomes in the ERP (such as Sales Order Creation, Invoice Creation, Purchase Order, Delivery, etc.).

Under Digital Access:

• When an external system creates one of these document types in the SAP system, it consumes a license count.
• Customers purchase a block of documents (often in packs of 1,000). For example, you might license 100,000 Digital Access documents/year. If external systems create 120,000 sales orders annually, you must true-up.
• Reading or querying data is typically not counted, and updates/deletes to existing documents are not counted – it’s mainly the creation of new business documents that triggers the metric. This model aligns licensing costs to business activity rather than raw user counts.
• The nine document types cover most indirect scenarios, such as sales Orders, Invoices, Purchase Orders, and service tickets (SAP provides the exact list in its policy documents). Many things in SAP eventually result in one of these documents, so they chose them as a proxy for system usage.

Mitigation and Strategy: As an ITAM professional:

• Identify Interfaces: Work with your SAP Basis team to inventory all interfaces connecting to SAP. Determine which non-SAP sources create or update data. This could include interfaces to Salesforce, websites, middleware such as MuleSoft, supplier systems, etc.
• Assess License Approach: Decide whether to stick with classic named-user licensing for those external users or adopt Digital Access:
  • Example: You have an e-commerce platform creating 50,000 orders/year in SAP. Licensing 50,000 documents via Digital Access might be more cost-effective than purchasing 5,000 named user licenses (if SAP classifies each end-customer as a user in the old model).
  • Many existing customers negotiated a one-time resolution with SAP. SAP ran an evaluation service to estimate the cost of documents and often granted a free allotment or discounts to transition to the document model (known as the Digital Access Adoption Program), which offered incentives such as credits for existing user licenses or discounted document packs.
• Prevent Surprise Audits: Indirect use is a common focus of audit attention. Auditors may request interface logs or utilize SAP’s “USMM/LAW” tools to identify data generated by interfaces. You can understand your exposure by proactively measuring your digital documents (SAP provides an estimation tool and “Passport” mechanism to help identify documents created by external vs. internal processes).
• Hybrid Licensing: If you adopt Digital Access for indirect consumption, you still maintain named user licensing for direct users. Digital Access covers scenarios where a user license is not typically allocated (such as an external user or system). Ensure there’s no double licensing: SAP policy states that if a document is created by a properly licensed named user (human), it doesn’t also count toward digital access. The intent is to cover only unlicensed external use.

Practical example:

A distribution company discovered that thousands of orders were generated in SAP through an EDI interface from customers. SAP’s audit team initially deemed each customer to require a license.

The ITAM team successfully negotiated the switch to the digital document model and licensed 200,000 documents/year for Digital Access.

This covered all EDI orders, and they could show compliance by demonstrating the count of EDI-created sales orders each year.

They also implemented a monitoring process: each month, the SAP team checks how many digital documents have been created so far to ensure they are within licensed limits or if they need to consider increasing the volume.

Bottom Line: If left unaddressed, indirect access can pose a significant financial risk. ITAM should incorporate interface reviews into regular compliance checks and ensure that either the appropriate user licenses are assigned or the Digital Access model is in place.

Educate business units that connecting new systems to SAP isn’t “free.” Always involve ITAM in evaluating the licensing impact of new integrations.

SAP Cloud Services (SuccessFactors, Ariba, Concur, Fieldglass)

In addition to its core ERP, SAP’s portfolio includes numerous cloud-based solutions that can be obtained via subscription.

Key ones include SuccessFactors, SAP Ariba, Concur, and Fieldglass.

Each comes with its own licensing metrics and compliance considerations:

• SuccessFactors (SF): SAP SuccessFactors is a cloud HR suite (for core HR, talent management, learning, etc.). Licensing is typically provided on a per-user (employee) basis, with subscriptions available. For example:
  • Employee Central (core HRIS) is often priced per employee record per year.
  • Recruiting, Performance & Goals, and Learning modules might be priced per seat (named user) who can access that module. Sometimes, Recruiting is licensed by the number of employees in the company (assuming all employees might apply for internal jobs) or by the number of recruiters.
  • Compliance Risks: SuccessFactors will automatically count active users in the system. If your company grows from 1,000 to 1,200 employees but only has 1,000 licenses, you’ll be out of compliance—usually addressed at renewal or through a true-up. The ITAM team should coordinate with HR to track headcount and module usage.
  • Note that SF being cloud means SAP tracks usage. It’s common for SAP to review your user count at renewal and adjust pricing accordingly. There’s little hiding from usage here, so it’s good practice to slightly buffer your subscription count or be prepared to pay for overages.
• SAP Ariba: Ariba covers procurement and supply chain collaboration (modules like Sourcing, Contracts, Procurement, and the Ariba Network for buyer-supplier transactions).
  • Ariba Network (for PO/invoice exchange with suppliers) uses transactional metrics. Often, it’s licensed by annual spending volume that goes through the network or the number of documents (e.g., the number of POs and invoice documents exchanged). There are tiers; for example, one tier might allow up to $50 million in spend through the network per year. Exceeding that moves you to a higher tier (and cost). Additionally, suppliers may pay fees on their side for network usage.
  • Ariba Applications (such as Sourcing, Procure-to-Pay, and Contract Management) may be licensed per named user (e.g., the number of procurement professionals using the system) or by enterprise spend. For instance, Ariba Sourcing could be priced by the number of events or users (this varies by SAP’s current packaging).
  • Compliance Risks: The usage can spike if procurement spend increases or more documents flow through. ITAM should work with procurement to monitor these metrics. (Often, Ariba provides admin reports on document counts and spend.)
  • Be cautious about connecting the Ariba cloud with your SAP ERP: ensure any integration doesn’t inadvertently cause indirect use issues on the ERP side (usually, standard SAP-to-Ariba integration is licensed as part of Ariba, but it’s worth confirming that no separate “SAP named user” is needed for users who only operate in Ariba).
• SAP Concur: Concur is for travel and expense management and is licensed as a SaaS per user.
  • Generally, Concur is priced per active employee user per month/year for Expense, and similarly for Travel. If you have 500 employees filing expenses, you pay for 500 Concur users annually.
  • Some Concur modules (like invoice processing for AP) might be licensed by document or transaction instead (e.g., per invoice processed).
  • Compliance Risks: Like other SaaS, Concur usage is tracked. Ensure that your HR provisioning and deactivation processes are thorough – if ex-employees are not removed from Concur, you may be incurring unnecessary expenses. Also, monitor if new divisions or contractors start using Concur; they should be included in license counts.
  • Concur integrates with SAP ERP (for posting expenses), but Concur users typically do not need an SAP ERP user license unless they directly log in to SAP for other reasons.
• SAP Fieldglass: Fieldglass is a cloud-based solution for managing external workforces and contingent labor.
  • Licensing is often based on the number of active external workers (contractors) managed in the system (e.g., if you contract 200 contractors through Fieldglass, you need licensing for 200).
  • There might also be components licensed per internal user (those managing the contractors or creating job postings). However, spend-based or worker-count metrics are commonly used.
  • Compliance Risks: An unexpected increase in contractor usage could exceed your licensed count. For instance, if a company suddenly hires 100 extra contractors for a project, the Fieldglass usage may exceed the contract. Good practice is to periodically reconcile the number of external workers in Fieldglass with the number purchased.
  • Integration: Fieldglass often connects to SAP HR or finance to feed data (timesheets, payments). Ensure those integrations are properly licensed (SAP usually covers the integration API as part of the product subscription).

General Advice for SAP Cloud Services:

• Centralized SaaS Management: Although these cloud services are separate from your SAP ERP, manage them under the ITAM umbrella. Maintain an inventory of all SAP cloud subscriptions, including their metrics, contract terms (such as user count), and renewal dates. These often auto-renew annually, and usage drift can result in additional costs if not adjusted at renewal.
• Watch for Over-Assignment: With named-user SaaS, avoid assigning more users than you purchased. SuccessFactors and Concur, for instance, will allow you to add users up to a certain point; although you might not incur an immediate penalty, SAP will invoice for the excess at the true-up. To stay efficient, disable or remove access for users who no longer need it.
• Data Volume and Tiering: For services like Ariba and occasionally SuccessFactors (which may offer tiered pricing for additional features or storage), ensure usage (such as documents and storage) is closely monitored. If you approach a threshold, consider negotiating an upgrade in advance rather than receiving a surprise bill.
• Cloud vs. On-Prem Licensing Alignment: Determine if any on-premises SAP licenses can be reduced due to migrating functionality to the cloud. For example, if you moved all HR processes to SuccessFactors Employee Central, you could reduce some on-prem HCM user licenses or consider terminating maintenance for on-prem HR modules (to save cost). However, be cautious: data integrations (such as syncing SF data to on-premises SAP for payroll or financial posting) may still require licensing on both sides. Always verify with SAP or your licensing advisor before dropping on-prem licenses after adopting a cloud module.

Non-Production Systems, Disaster Recovery, and the 10-Day Rule

SAP landscapes typically include multiple environments: development, test/QA, training, and disaster recovery (DR) systems in addition to production.

A common question is how licensing applies to these non-production instances:

• Development and Test Systems: SAP generally requires licenses for all usage, even non-production, but in practice, the named user model covers this more simply: If a person has an SAP named user license, that license allows them to use any
  • SAP systems under that organization’s license scope. There is no separate “dev license” for the same user. Therefore, an SAP developer with a Developer Named User license can work in development, testing, and production environments
  . It’s all covered by their one license. You do not need to buy duplicate user licenses for each system. Licensing is based on the user, not the
  • system. However, suppose you have additional people who only use non-prod systems (e.g., a dedicated testing team or external consultants who never log into production), technically. In that case, they still need to be licensed named users. Every individual using SAP software, even in a test client, should have a license of the appropriate type. There isn’t a special free license for “test-only user.” (One exception: SAP sometimes provides temporary license keys for training or evaluation systems, but those are time-limited and not for productive business use.)SAP’s policies often allow unlimited software installation for non-production as long as usage stays within licensed metrics. In other words, you can create multiple test clients or training systems without paying new engine license fees – the restriction is that the usage (users, or metrics like transactions) across these shouldn’t exceed what your license allows. This is usually fine since the licenses are sized for production needs, and test systems are ancillary.
  Good practice: Keep your user master records clean. Remove or lock users in test/dev that are not needed, or ensure they are mapped to a license type. Sometimes companies leave many generic accounts or old users active in a dev system, confusing an audit. Use SAP tools to mark a system as “Test” so that license measurement concentrates on counting unique users across systems (via SLAW consolidation).
• Disaster Recovery (DR) Systems: DR setups (like a standby instance in another data center or region) are special because they are not used daily, only during disasters or DR drills. SAP’s license stance:
  • If the DR system is completely idle (data is replicated but no users are actively using it), separate licenses are not required for that software installation. You’re essentially allowed to have a cold standby.
  • When you activate the DR system (e.g., during an outage failover or a drill), you effectively run a second instance of SAP. SAP expects that your licenses cover your usage on DR (since it’s the same users licensed in prod, presumably there are no “extra” users).
  • The question arises: Can you run both Production and DR simultaneously for an extended time? Generally, no, not without additional licenses. If, for some reason, you had to run them in parallel (active-active), you would be doubling capacity, which usually requires licensing both.
  • Remember: User licensing is done by a named individual. If all your users are already licensed, you won’t suddenly have new users when they use the DR system. The primary concern is whether the DR system doubles some licensed metric, such as the number of engine instances. In most cases for SAP ERP, engines are licensed per metric, such as order count or employees, which aren’t counted per system. So running a clone shouldn’t double-count those metrics as long as they are the same business operations.
• The “10-Day” DR Test Example: Many companies do annual DR tests for a few days. During that time, they might have production and the DR up to compare or simulate a cutover. From an ITAM perspective, maintain documentation of such tests (dates and duration). If ever challenged, you can show that any parallel use of systems was purely for a DR test under X days, which you believed to be within your rights. Proactivity: If unsure, get an agreement with SAP. Often, SAP will not charge for temporary test usage if informed, but it’s wise to have that acknowledgment.
• Separate Licensing for High Availability (HA): Note the difference between DR and HA. HA typically refers to a failover node in the same site (such as an ASCS cluster or HANA System Replication node) that may be on hot standby. SAP allows those setups without an extra license as long as only one node is actively used for production. If you briefly run both active during a failover, that’s fine, but you shouldn’t be serving users from both simultaneously beyond failover.
  • In SAP HANA’s case, if you have a secondary replica purely for HA, SAP does not require a second HANA license for it unless it’s used for active read queries (there is a concept of HANA “active/active read-enabled” which might require licensing both nodes). ITAM should clarify these details if managing HANA environments.
• Training Clients or Sandboxes: If you create a sandbox copy of SAP for a project or training, treat it like any other system – it’s allowed, but the users accessing it must be licensed. It’s common to use generic accounts for training; be careful, as generic accounts still consume a license (and SAP generally disallows sharing one named user among multiple individuals). Always assign proper temporary named users for trainees if needed, and then deactivate them after.

Summary: Non-production usage is generally liberal in terms of installations (no extra fee to install multiple systems), but not free in terms of user or engine usage.

A licensed user can use all systems; an unlicensed user can use none.

Disaster recovery requires clear internal policies and, possibly, written confirmation from SAP on how long a secondary instance can be run. Document all such scenarios to defend your position in an audit.

Common Compliance Pitfalls to Avoid

Over the years, certain licensing mistakes in SAP have occurred frequently.

Awareness of these pitfalls helps ITAM practitioners guard against compliance issues and unexpected costs:

• Named User Misclassification: This is a top issue. SAP audits often find users assigned to a less expensive license type than their activities warrant. For example, all users are given “Employee Self-Service” licenses by default, even though many perform transactions that require Professional licenses. Or classify a power user as a Limited Professional when executing broad transactions. Regularly review user roles vs. license assignments. A good approach is to utilize SAP’s license audit reports or third-party tools to identify users who have executed transactions outside the scope of their assigned license type. Adjust their license type accordingly (and purchase upgrades if needed). It’s far better to self-correct than to have SAP identify the issue and charge maintenance for those misclassified users.
• Generic or Shared Accounts: Some companies use a single SAP login for multiple users (e.g., a generic warehouse account used by five workers in shifts). This violates SAP’s agreement (each needs their own named user license) and is a red flag in audits. Ensure each person has a unique user ID. If there is a technical need for a generic ID (for background jobs or integrations), mark it as “technical” and confirm if SAP might consider it a named user. Usually, a technical interface account that isn’t tied to a person still consumes a license. You might allocate a low-level license to it (if it only does a specific task). Don’t assume technical users are free – clarify their licensing.
• Inactive Users Not Retired: In SAP license audits, counts often include all named users created in the system, unless they are locked and exempt. If employees leave or change roles and their SAP accounts remain active, you may be required to maintain a license for them. Implement a process with HR to lock or delete SAP users who depart and reclaim that license allocation. SAP’s audit tools allow you to exclude users who haven’t logged in within 90 days if you appropriately mark them, but it’s best to remove unneeded users entirely.
• Engine Overuse or Untracked Metrics: Many engines (packages) lack an automatic usage cap in the software. It’s on the honor system; for example, if you purchased licenses for “1,000 Concurrent Sales Users” in CRM but have 1,200 users using it, SAP won’t shut it off, but an audit will catch the discrepancy. Similarly, if you’re licensed for 10 million POS transactions/year and do 12 million, the system won’t stop at 10. Thus, ITAM needs to implement internal monitoring or periodic checks for such metrics:
  • For user-count-based engines, coordinate with functional teams to count actual users.
  • Receive reports from SAP or relevant business systems every quarter to view current volumes for transaction or revenue metrics.
  • Keep documentation of how you track these metrics so you can demonstrate control during an audit. If you exceed, proactively contact SAP to purchase additional capacity—that tends to go over better than being caught later.
• Indirect Access Overlooked: As discussed earlier, failing to account for indirect use is a big pitfall. For instance, an IT department builds a new mobile app that allows customers to create service requests that are sent to SAP, but doesn’t license those customers. A year later, in an audit, SAP asks, “Who are all these documents created by the user ‘WEBAPP’ account?” Suddenly, you have an exposure. Always include license impact in the design phase of integrations to ensure a seamless integration process. Sometimes, a simple solution is to utilize an existing licensed user as a proxy; however, if that account effectively serves multiple people, it triggers indirect use considerations anyway. It is better to be transparent and consider Digital Access or properly named licenses for business partners.
• Cloud Module Under-licensing: A common pitfall with cloud services (such as SuccessFactors) is not aligning the license count with actual usage. This isn’t hidden from SAP (they can see usage), but it can bust your budget if not anticipated. For example, if the Talent Management module was purchased for 500 users but invited all 800 employees to the performance review system, you’ve just exceeded your license by 300. You may not get stopped immediately (the system might allow it), but SAP will require payment for the additional 300 at true-up. Prevent this by:
  • Setting hard limits or controls in the admin console of those services if possible.
  • Educating the business owners of these systems to inform ITAM before expanding usage.
  • Utilizing any provided usage reports to reconcile against entitlements regularly (e.g., monthly check how many active SuccessFactors users vs. licensed count).
• Multiplexing and Third-Party Access Misunderstandings: “Multiplexing” refers to using an intermediate system to reduce direct SAP connections (e.g., a middleware that funnels 100 users’ actions through one SAP login). SAP’s contracts forbid this as a license avoidance tactic – those 100 users still need to be licensed. ITAM should be wary when architects propose such setups. The pitfall is thinking “only one SAP user is used, so we only need one license” – that’s incorrect. Similarly, allowing a business partner or affiliate company to use your SAP without them being covered under your contract can violate the contract if it restricts use to your entity. Always check affiliate use rights in the contract if other companies (even if related) access the system.
• Using Unlicensed Functionality: SAP software often comes with many modules, but not all of them are included in your purchase. For example, your SAP ERP might have transaction codes for SAP Plant Maintenance even if you didn’t license that module. Users could start using it unknowingly. That results in usage without entitlement. Regularly review transaction usage against what you’ve bought. It might be necessary to technically restrict access to unlicensed modules (through roles/profiles) to prevent accidental use. Some customers also inadvertently use SAP’s advanced features, requiring separate licenses – e.g., SAP Solution Manager’s focused insights (which may require a license) or SAP GRC components without purchasing them. Maintain a list of all SAP software engines to which you are entitled, and cross-check it against the modules active in your environment.

Real-World Anecdote:

An audit of a large automotive company revealed hundreds of “professional” users assigned. However, in SAP’s analysis, approximately 30 accounts were used solely for approving purchase orders and entering time. SAP pointed out that those could have been Employee Self-Service licenses.

The company still had to pay true-up for professional licenses, as that was what they were assigned (license compliance is about what is required for usage, not what was necessary in hindsight). Following the post-audit, the ITAM team implemented a strict process to properly classify users and downgraded dozens of users to a lower-cost license, thereby avoiding future overpayment.

Staying vigilant about these common pitfalls and addressing them proactively is a hallmark of mature SAP license management. It averts compliance issues and often reveals opportunities to optimize and save costs.

Read Top 10 SAP On-Premise License Compliance Issues.

Preparing for SAP Licensing Audits

SAP license audits (often termed “License Verification” or “measurement procedures”) are a regular part of the SAP customer experience.

Typically, SAP has the contractual right to conduct annual audits, although not every customer is audited annually.

ITAM practitioners should view audit readiness as an ongoing process, rather than a one-time annual scramble.

Key steps and tools include:

• Understand the Process: SAP usually sends a formal notice or request to run the measurement. For on-premise deployments, they’ll ask you to run USMM (User Measurement) in each system and consolidate results in SLAW (License Administration Workbench). For cloud services, they might simply review usage numbers in their system. After you submit data, SAP’s license compliance team analyzes it and reports any shortfalls or questions.
• Maintain Entitlement Records: Before any audit, ensure you have a clear record of your entitlements, including the number of each user type and package you own. It’s surprising how often companies don’t have the exact numbers and rely on SAP’s view. Keep a license inventory document updated whenever you purchase or change licenses. This includes special contract terms (e.g., “we have a contractual cap that Test users don’t count” or similar).
• Internal Audit (Simulation): A best practice is to run your measurement at least yearly (if not continuously). Use SAP’s USMM tool:
  • USMM will determine the number of users assigned to each license type in each SAP production system and measure certain engines (SAP provides measurement programs for some packages, such as HR and SD, which track transactions).
  • If you have multiple systems, use SLAW to aggregate them. SLAW helps consolidate duplicate users across systems. For example, the same person with two accounts in two systems can be counted as one named user (the license type should be the highest required among the two accounts). ITAM should ensure someone knowledgeable uses SLAW to consolidate properly; otherwise, SAP might double-count.
  • Analyze the SLAW output: Do you have more users classified than you own licenses for? If so, either reclassify some users to lower categories if appropriate, or prepare to buy more. Check engines: SLAW might indicate, for example, that you are using 120% of the licensed capacity on a package.
  • By addressing these issues internally (and not necessarily sharing them with SAP immediately), you have the opportunity to resolve them. For instance, you might discover 50 contractor accounts that were never license-assigned – you can delete or assign them a license before the official audit.
• Cleanup Before Submission: It’s generally allowed (and wise) to do some cleanup just before the official measurement:
  • Expire or lock any unnecessary accounts (especially if they haven’t been used – they inflate the count).
  • Ensure all users maintain a license type in their master record (SU01 user license field in SAP). In SAP’s eyes, users without a classification may default to Professional.
  • If you realize that some users require a higher license type than you planned, consider purchasing the upgrade before submitting data. SAP sometimes offers better pricing in a non-audit scenario than after they have identified non-compliance.
  • Validate that each engine measurement’s classification is accurate. Some engines require manual inputs (for example, the number of employees for HR). Check those figures for correctness.
• Audit Tools and Utilities: Besides USMM/SLAW, be aware of other SAP compliance tools:
  • SAP LAW 2.0 – a newer, improved version of the License Admin Workbench that can automate user consolidation across hybrid environments.
  • SAP Passport – helps to differentiate document creation sources (relevant for indirect use measurement, as discussed).
  • SOLMAN System Measurement – Solution Manager can centrally manage license measurement for multiple systems. If you have a complex landscape, investing time in Solution Manager’s License Management Workcenter could streamline audit data collection.
  • Third-Party Audit Support Tools: If you have a large environment, vendors like VOQUZ or Snow can simulate audits with more advanced analysis (e.g., suggestions to reclassify users optimally to fit your license allocations).
• Common Audit Findings: Know what SAP auditors look for:
  • Users with higher usage: They will review lists of transactions executed by “Limited” users to determine if any should be designated as Professional. It’s somewhat subjective, but if a user ran admin or configuration transactions, that’s not allowed under a lower license.
  • Test user misuse: SAP may flag instances where too many users are classified as “Test” or “Developer” without a proper reason. Developer licenses are of higher privilege, so it’s usually fine, but if you classify almost everyone as a “Test user” to avoid license counts, they’ll likely challenge that.
  • Engine counts: They’ll compare any measured metrics or your provided counts to what’s in the contract. If you have 100 SAP Payroll employees licensed and currently have 120 employees live in the system, that’s a finding.
  • Indirect access: Auditors will request interface lists and may question the flow of data. They could identify documents in tables that they suspect came from non-SAP sources and ask you to explain how those are licensed.
  • Unlicensed products: If they find usage of a module you didn’t license, they will list it and often propose that you purchase it or cease using it.
• Negotiation and True-up: If the audit reveals shortfalls, SAP typically issues a report and a quote to remediate (i.e., buy more licenses or subscriptions). ITAM should:
  • Review the findings carefully. Sometimes audits have errors (e.g., counting a user twice despite consolidation, or misidentifying an interface). You have the opportunity to discuss and contest points.
  • If additional licenses are required, treat the process as a standard procurement negotiation. You might negotiate the price or conditions, or even consider alternatives (e.g., instead of buying a large number of new user licenses for indirect use, you could negotiate a move to a digital access model).
  • Ensure any true-up purchase is accompanied by contractual clarity. If they sell you something due to an audit, have it added to your entitlement, and understand its metric. Also, try to address the root cause so you don’t keep addressing the same issue every year.

Audit Prep Example:

A multinational was due for an SAP audit. Three months prior, the ITAM team ran SLAW and found 300 more users classified as Professional than they had licenses for. They investigated many unused accounts and found some contractors who had left. They cleaned up 200 accounts and reclassified 50 others to a more fitting license.

They then purchased 50 additional licenses to cover the truly needed gap. When the official audit happened, they passed with no major findings, and SAP’s auditors even commented on the well-documented user mapping.

This proactive approach saved them from a potentially larger true-up bill and demonstrated good faith, which made negotiations with SAP smoother in that cycle.

Tools for SAP License Management

Managing SAP licensing manually can be a challenging task, especially in large organizations. Tools from SAP and third-party vendors can help track and optimize SAP license usage.

Understanding their capabilities and limitations helps ITAM leverage them effectively:

• SAP Native Tools:
  • USMM and SLAW: As discussed, these are SAP’s measurement tools. They are sufficient for basic compliance reporting, but don’t automatically optimize or give deep insights—they just present usage data.
  • If implemented, SAP Solution Manager (Licensing Workbench): SolMan has a License Management component that can collect user data from connected systems and apply rules to suggest license classifications. However, SolMan’s approach is still fairly static and rule-based and may need substantial configuration. Due to its complexity, not all companies use SolMan for this purpose.
  • SAP Global Trade Services for License Management: (Not to be confused with trade compliance—here, we mean internal license management.) SAP doesn’t offer a full-featured SAM tool for its licenses beyond the basics. It expects customers to either manage manually or use partner tools.
  • Embedded Analytics in S/4HANA: In S/4HANA, there are several Fiori apps for license assignment and user activity analysis. For example, administrators can get a quick view of active users, their last login, and other relevant information, which can help identify dormant accounts or unusual usage patterns.
• Third-Party SAP License Management Solutions: A niche industry exists for SAP license optimization tools. Some notable ones:
  • Snow Optimizer for SAP®: A popular tool that interfaces with SAP systems to analyze user behavior and engines. It provides suggestions for right-sizing user licenses (e.g., “user X has only executed display transactions, could be an ESS user instead of Professional”) and can automate some reclassification. It also helps simulate different scenarios, such as “if we were to migrate to S/4 user types, how many of each would we need?”
  • Voquz LicenseControl (samQ): Another specialized SAP license tool. It similarly reads SAP usage data, including transaction history, and applies logic to identify the optimal license type for each user. It can detect indirect usage patterns and even apply dynamic license allocation (assign the cheapest possible license to each user based on real usage).
  • USU (Aspera) and Flexera SAP modules: These big SAM players have SAP-specific modules. They often provide dashboards for compliance positions and integrate SAP data with broader IT asset data. These modules can be useful if you want one SAM tool for all software, but note that SAP licensing is so specialized that these modules are sometimes less granular than dedicated SAP license tools.
  • ServiceNow SAM for SAP: With the right configuration, ServiceNow has licensing management features that can cover SAP. It may rely on importing SAP Law data and then enabling entitlements and compliance management within the ServiceNow platform.
  • Custom Analytics: Some organizations develop in-house tools or scripts (such as ABAP programs) to collect usage statistics. For example, custom ABAP can log certain high-license transaction usage to identify if a Limited user ran a transaction beyond their allowance. This requires SAP expertise to develop, but can be tailored to your license definitions.
• Limitations to Note:
  • User Behavior vs. Contract Definitions: These tools can flag that a user has executed a certain transaction, but determining the required license type isn’t always straightforward. SAP’s user definitions are somewhat vague (“Limited users can do XYZ tasks”). So tools provide guidance, but ITAM must apply judgment or confirm uncertain cases with SAP. Auditors ultimately interpret usage, which might differ from tool recommendations.
  • Engines and Packages: Automatic tools struggle with engines that SAP doesn’t measure. For instance, if an engine is based on the “number of employees paid,” no tool knows your employee count unless you provide it. Or if you must input that by revenue. Tools help track those you configure, but won’t magically know business metrics not stored in SAP.
  • License Allocation Automation: Some tools can dynamically adjust a user’s license assignment based on recent usage (e.g., downgrading someone after 90 days of low usage). This is useful, but must be managed carefully to avoid constantly flipping users’ license types and confusing audit trails. It’s often better for planning and simulation than for day-to-day automatic changes.
  • Cost vs. Benefit: These tools come with their license costs. ITAM should do a cost-benefit analysis: for companies with thousands of SAP users or very expensive SAP estates, a tool can pay for itself by uncovering optimizations and avoiding the purchase of unnecessary licenses. Manual management with spreadsheets and SAP’s tools may suffice for smaller SAP customers.
• Integrating with ITAM Processes: If you have such tools, incorporate their use into regular processes:
  • Quarterly license compliance checks using the tool’s reports.
  • Before adding new users or go-lives, use the tool to simulate the impact (e.g., “We plan to add 50 new users with these roles, how many need Professional vs. Functional?”).
  • During S/4 migration planning, use the tool to map old licenses to new ones (if supported).
  • For audit defense, generate reports and documentation from the tool to show the steps you’ve taken to optimize and comply.

Example: A large retailer employed Snow Optimizer for SAP. The tool revealed that 300 out of their 2,000 SAP users never did more than display data and simple tasks, indicating they could use a lower license type.

By reassigning those licenses, they avoided purchasing additional licenses for a new project, freeing up the expensive licenses for users who truly needed them. The tool also tracked engine metrics, such as the number of materials in the system versus the licensed allowance, alerting ITAM when they were nearing limits so they could negotiate an extension in advance.

While the tool cost significantly, it identified optimizations that saved double its cost in the first year. It also made the annual audit a non-event because all the data was well-organized.

In summary, tools can greatly enhance visibility and control, but they are aids, not replacements, for informed decision-making.

ITAM professionals should still have a deep understanding of SAP’s rules and utilize these tools to analyze data and provide recommendations, which they then validate and act upon.

License Optimization Strategies

Effective SAP license management isn’t just about avoiding compliance problems.

It’s also about optimizing usage to minimize waste and maximize the value of your purchase.

Here are several strategies ITAM practitioners can employ to optimize SAP licenses:

• Reclassification & Right-Sizing Users: Regularly adjust license types assigned to users based on their actual use. This is often the quickest way to find savings:
  • Identify users with heavy access who might need an upgrade (to remain compliant) and, importantly, identify users with light usage who can be downgraded to a cheaper license type. For example, many users might originally be given professional licenses by default but only use a limited subset of functionality. They could be downgraded to functional or productivity licenses (in S/4) or ECC’s limited professional/employee licenses.
  • Real-world governance: Implement a quarterly review of all users added in that quarter. Validate that the assigned license type was appropriate. If someone’s role or activity levels change, update their license type in the system accordingly.
  • Engage department managers in this conversation. Sometimes, an end-user’s role evolves, but IT isn’t updated accordingly. A manager can confirm if a user doesn’t need certain SAP capabilities to support a downgrade.
• User Management Hygiene: Optimize the user count itself:
  • Proactively remove users without access (e.g., departed employees or users from completed projects like consultants). This frees up licenses for reuse. You control license growth if you operate a one-in, one-out policy (assign a new user only if an old one is removed when possible).
  • Consolidate duplicate user IDs for the same person (where feasible). If a person had multiple accounts for different job functions, consider using one account with appropriate roles to reduce license count, or at least count them as one in LAW by linking the accounts to the same Central User ID.
  • Monitor for “license hoarding” – cases where, say, every team member was given an SAP account “just in case” but only half use it. Consider reclaiming licenses from dormant accounts (after verifying they truly don’t need access).
• Shelfware Identification and Redeployment: Shelfware refers to purchased licenses that sit unused. In SAP contexts:
  • It could be spare named user licenses beyond current needs (e.g., you bought 1000 but only 800 active users), or engine rights for modules you installed but never fully implemented.
  • Identify shelfware by comparing entitlements to actual usage. For instance, if you have licenses for an SAP module that has not been installed, that’s clear shelfware.
  • Strategies to handle shelfware:
    • Redeploy Internally: Perhaps a different department could benefit from that unused module. If you own it, consider rolling it out to derive value (assuming maintenance is being paid, you’re spending money on it regardless).
    • Swap or Exchange: SAP typically has a no-refund policy on perpetual licenses. However, they sometimes allow swapping one product for another of equal value as part of a new purchase negotiation. For example, suppose you bought licenses for SAP CRM but decided not to use CRM. In that case, SAP may allow you to convert the investment into additional SAP BW licenses, if that suits your needs, during a deal (often requiring a new purchase or an SAP program, such as the Cloud Extension policy, described below).
    • Terminate Maintenance on Shelfware: If you’re confident that certain licenses will never be used, you can drop their maintenance at renewal to save on annual support costs (you retain the license but lose support/updates for that portion). Be cautious: SAP contracts often prevent partial termination easily, but if the shelfware is on a separate line item, you may be able to negotiate to end support. If you later want to use it, you’d have to back-pay or repurchase, so do this only for truly dead shelfware.
    • Document any shelfware and have a game plan – don’t just keep paying support on it blindly. Either plan to use it or drop it.
• Leverage the SAP Cloud Extension (SCE) Program: SAP’s Software Credit or Cloud Extension programs allow customers to trade unused on-premise licenses/maintenance for cloud subscription credits. For instance:
  • You have $1 million per year in maintenance on many SAP products, but plan to move to cloud equivalents. SAP has offered deals where you can reallocate some of that maintenance budget toward new cloud services (essentially a discount or avoiding double-paying maintenance and subscription during a transition).
  • This is highly negotiated and case-by-case. The benefit is that you can retire shelfware licenses and not pay maintenance on them by investing in the cloud. The caveat is that you typically need to sign up for a new multi-year cloud contract to utilize this.
  • ITAM’s role is to identify candidates (licenses that are not heavily used and could be candidates for conversion) and provide data to support negotiating favorable credit terms for them.
• Internal Governance & Approval Processes: Make optimization systemic by embedding checks in everyday operations:
  • An ITAM review is required for any new SAP license purchase requests. Before buying, consider reallocating or optimizing existing licenses to meet the need. Often, business units request new licenses, while other parts of the company have spares available.
  • Similarly, ITAM should be involved in planning new projects. If a new project requires enabling a specific SAP module, ITAM should verify whether it’s already licensed and budget accordingly. Early involvement can also arise if a non-SAP solution might eliminate the need for an expensive SAP engine, etc.
  • Create SAP License Guidelines for end-users and SAP security teams: for instance, a matrix of which license type aligns to which user roles. If security teams know that assigning a user role X will require a license type Y, they can flag any request that would escalate licensing.
  • Executive Awareness: Communicate with finance and execs about the cost of SAP licenses and the importance of compliance. When business leaders understand that an idle module still incurs support costs, they may be more willing to formally decommission it or utilize it.
• Negotiation and Relationship Management: Optimization isn’t just internal – it’s also about how you deal with SAP:
  • Keep a good relationship with your SAP account manager, but be ready to resist licensing proposals. For significant purchases, get multiple quotes or a second opinion.
  • If you feel that your current license mix is inefficient (e.g., having too many high-cost user licenses when a lower-tier license could suffice), consider approaching SAP about a contract restructuring. In some cases, SAP might allow converting some licenses to a different type if it aligns with your actual usage (especially if you’re also expanding or buying new SAP products – they may be flexible to secure more business).
  • Timely renewals: Use the support renewal time to negotiate. While SAP support fees are notoriously rigid, large customers have gained concessions by threatening to reduce their footprint or move to third-party support. SAP might offer a deal (like the cloud extension or discounts on new products) to keep you in the ecosystem. Arm yourself with data on usage and value of what you have.

Optimization Example:

An ITAM team in a healthcare company conducted a thorough license reconciliation and found they had 200 more SAP CRM user licenses than active CRM users.

They arranged with SAP to swap those 200 CRM user licenses for 100 licenses of a new SAP Analytics product the company wanted – effectively trading something unused for something useful (with some additional payment to cover list price differences).

They also implemented a policy that requires any new SAP user to be approved by an ITAM analyst, who checks if an existing license can be reassigned instead of purchasing a new one.

Over a year, this policy re-harvested 50 licenses from departing employees to distribute to new hires, thereby avoiding the need for new purchases. These measures ensured that they maximized the use of every dollar spent on licenses.

In short, continuous optimization is key. SAP licensing isn’t a set-and-forget asset – it needs active management to adapt to organizational changes.

With diligence, ITAM can often delay or reduce new purchases, negotiate better deals, and ensure the company only pays for what it truly needs.

Support Renewals, Shelfware, and Third-Party Support

SAP support (maintenance) renewals come annually and can be a significant budget item.

Managing this process wisely is another lever for cost optimization and risk management:

• Review What You’re Paying For: Each year, SAP will send a support renewal quote that lists all licenses under support and the corresponding fees. ITAM should:
  • Cross-check the list of licenses against current usage. Shelfware identification (from the previous section) directly feeds into this. Paying maintenance on licenses you don’t use is a waste.
  • Note that SAP often has “no partial cancellation” clauses, meaning you technically can’t drop certain licenses from support while keeping others, except at specific times (like contract anniversary or if it’s a separately identifiable line item). However, if you have unused licenses, bring them to the attention of SAP – sometimes they may allow for dropping or parking them (e.g., placing them in an inactive status that does not count toward maintenance, perhaps as part of a broader agreement).
  • Example: If you have 1,000 professional users on support, but only 800 are in use, highlight this to SAP. Request options: Can we reduce to 800 and lower maintenance? SAP might resist due to policy, but it starts a conversation. They might counter with a proposal to swap those 200 for another product (as mentioned) or to give some short-term concession.
• Cost Control Tactics:
  • Multi-Year Deals: If SAP pushes an expensive new purchase or cloud transition, you might negotiate to lock support costs for a couple of years as part of the package. Ensure any contractual caps on support fee increases (SAP usually increases support fees at a fixed rate or ties them to indices—know what yours is).
  • Support Level: Most SAP customers are on Enterprise Support (22% of licenses). SAP also offers Standard Support (typically 19%), but new contracts usually default to Enterprise Support. It’s rare to change from Enterprise to Standard (SAP doesn’t encourage it, and it offers less service). However, it might be a discussion point if you’re in a cost crunch and don’t need the extras of Enterprise Support. Some very large customers have negotiated custom support structures, but this is the exception.
  • Shelfware Maintenance Holiday: Occasionally, SAP might allow temporary relief. For example, during the COVID-19 pandemic, some customers negotiated delayed maintenance payments or scope reductions. These are not standard, but raising the issue could yield a one-time break if circumstances are extreme (like an industry downturn).
• Considering Third-Party Support (3PS): Companies like Rimini Street and others offer third-party support for SAP. This means:
  • You stop paying SAP annual maintenance, and pay the third party (often 50% of SAP’s fee) for support on your existing software. They provide help desk, bug fixes (often custom), and tax/regulatory updates. You forgo upgrades and new releases from SAP because you won’t have access to SAP’s latest patches or intellectual property. Typically, third-party support is chosen by companies that plan to stick to an older, stable version for a long time or are phasing out SAP but need support in the interim. Risks: SAP will consider you out of support – you cannot log official SAP support incidents.Additionally, if you ever wish to resume SAP support or upgrade to a newer version, SAP may charge back-maintenance for the gap years or may not allow re-entry easily. You’d have to rebuy licenses or pay a hefty fee to get back on maintenance after a long gap (negating some savings)., License Compliance and 3rd-Party Support: You must maintain license compliance with SAP’s terms, including third-party support. SAP may still exercise audit rights (though practically, they audit active customers more). If you are out of compliance, you would need to resolve it (you could purchase licenses without support, but SAP might insist on adding support to sell them – a catch-22 if you left support). Some companies use 3PS as a tactical move, e.g., to run on stable ECC 6 for 5 years on cheaper support while preparing to move to a different ERP. This can save a lot, but it essentially involves gradually exiting the SAP ecosystem
  .ITAM should advise leadership on the pros and cons. If cost savings are paramount and the SAP system is not evolving, 3PS could be a viable option. Always ensure it’s a well-informed decision, as it’s difficult to reverse without incurring costs.
• Support Contract Terms to Note:
  • Check if your SAP contract has a committed support term. Generally, it’s perpetual with annual renewal, but some deals bundle a few years of support prepaid or restrict dropping support for a specified number of years.
  • If you reduce usage (for example, by divesting part of a business using SAP), SAP’s standard policy doesn’t automatically reduce your maintenance; you pay for rights, not usage. However, in divestitures, you can sometimes negotiate a license transfer or termination for that portion, which can impact support.
  • Termination Liability: If you attempt to terminate support entirely (to switch to 3PS), some contracts include clauses that you lose the right to use any new versions obtained during support or that you must uninstall certain support packs. It’s a bit of a grey area, but essentially, after leaving support, you can keep using the last legally obtained version. Document the state of your system at that point (SAP version, patch level) to be clear on what you’re licensed for going forward.
• Shelfware Management at Renewal: The renewal cycle serves as a valuable checkpoint for trimming shelfware. For example, if an engine has been unused, consider formally phasing it out. Communicate to SAP: “We have no plans to use this component; can we remove it from the support contract?” If they say no due to contract, you might at least internally mark it, and maybe next time you buy something new, use it as a bargaining chip (“we’ll buy Product X if you let us terminate Product Y’s licenses”).
• Future of Support – SAP 2027/2030 Deadline: A strategic consideration: mainstream maintenance for SAP ECC ends by 2027 (with optional extended maintenance to 2030 for a premium). This means customers are encouraged to migrate to S/4HANA or at least plan for it. ITAM should factor this in:
  • If you intend to stay on ECC past 2027, SAP will likely charge more for support (if you opt in). Alternatively, you might consider third-party support after that date as a temporary solution.
  • For S/4HANA conversions, SAP might offer a break on existing support if you commit to S/4. There was a program where unused maintenance could fund the S/4 transition (cloud extension as above).
  • Communicate with stakeholders well in advance about these timelines—they have license and cost implications. For instance, “If we do nothing, in 2028 our ECC support cost might jump by 2-4% or more. Alternatively, we could be off ECC by then or on third-party support.” These discussions blend ITAM with IT strategy.

Example:

A manufacturing firm had $2 million/year in SAP support fees. They realized 25% of that was tied to modules they weren’t using. They attempted to remove those from support; SAP initially refused due to contract terms.

However, during a renewal discussion, the ITAM lead negotiated that they would purchase some needed additional licenses for a new plant if SAP allowed dropping support for the unused modules. SAP agreed as it was a net new sale for them.

This saved the company $ 200,000 per year in support for shelfware, even after accounting for the cost of new licenses. In another case, a company saved 50% of its support costs by switching to a third-party provider after concluding that its ECC system would not be upgraded and could run as-is for five years. That decision wasn’t taken lightly, but ITAM provided a thorough analysis of cost savings vs. risks, helping the CIO and CFO make an informed call.

In summary, treat the support renewal as more than a rubber-stamp payment.

It’s a recurring opportunity to optimize: prune what you don’t need, consider alternative support models, and ensure you’re getting value from the maintenance dollars spent (e.g., by actually utilizing SAP’s support benefits like upgrades, support notes, and new release, if you’re paying for Enterprise Support but not using any of its perks, that’s something to reconsider).

Key License Contract Terms and Programs

SAP license agreements are detailed documents. A good ITAM practitioner should be familiar with critical clauses and available SAP programs that can influence licensing.

Some key terms and concepts to review in your SAP contracts:

• Audit Clause: This typically grants SAP the right to audit your usage, typically with an annual frequency and a specified notice period. Look for:
  • The required notice SAP must give (commonly 30 days).
  • Your obligations (to run measurement programs, provide assistance, etc.).
  • The remedy for non-compliance. Usually, it states you must purchase necessary licenses at list price or cease usage. It might also mention paying back maintenance for unlicensed use (SAP sometimes asks for back support fees for the period during which you used something unlicensed).
  • There’s usually no cap on how far back they can claim usage, but they focus on current usage practically.
  • Action: Ensure internal audit readiness to minimize surprises. If negotiating a new contract, one could add a clause that any license shortfall will be purchased at discounted rates consistent with the original discount to avoid punitive list price buys. SAP may or may not accept that, but some clients have gotten such language for predictability.
• Affiliate and Third-Party Use: Check who is authorized to use the software:
  • Most SAP contracts define “Customer” to include named affiliates (usually those you control >50%). Ensure that all entities using SAP are covered by this definition. If your corporate structure has changed (e.g., mergers, new subsidiaries), update the contract via an amendment to include these changes. Using SAP in a company not under the agreement could technically be unlicensed.
  • Third-Party Service Providers: Often, companies have outsourced or contracted with service providers who operate SAP on their behalf. SAP allows this as long as the usage is for the customer’s business and the users are licensed under the customer’s licenses. Some contracts explicitly permit the use of third-party outsourcing. If you plan to have an outsourcer manage SAP (like an external call center using your SAP CRM), ensure the contract permits it. Usually, it’s fine, but SAP may want the third party to be bound by confidentiality and other terms when using the software.
  • Ensure there’s no restriction like “not for processing data of third parties” unless it’s your business service (some licenses have restrictions if you’re an SAP provider). If your company provides services to external clients on SAP, that can be a different licensing model (SAP’s Service Provider or OEM agreements).
• Multiplexing Clause: The contract often explicitly prohibits reducing license requirements by pooling users through a single account or other technical means. SAP covers indirect use scenarios, stating that you need proper licenses regardless of the technical access method. There’s not much to negotiate here – just be aware that it exists and educate IT that no clever technical workaround will evade licensing (and attempting to do so violates the contract).
• No Assignment / Transfer: Typically, you cannot freely sell or transfer SAP licenses to another company (except affiliates or with SAP approval). If your organization plans a divestiture, the SAP licenses for that part of the business usually can’t be transferred to the buyer without SAP’s consent. SAP often requires the new entity to sign a new agreement (possibly with additional fees). As ITAM, plan for this in M&A scenarios: engage SAP early if entities split or combine to sort out licensing implications and avoid post-deal surprises.
• Termination and Term License (TULs): SAP primarily sells perpetual licenses but also offers Term licenses (time-limited). Sometimes abbreviated as TUL (possibly “Time-Limited Use License”). This effectively rents the software for a period (e.g., a 2-year license for a project). Key points:
  • Term licenses typically have an end date by which you must cease using the software unless it is renewed. If your contract has any renewal dates, diary those dates and ensure that renewal or cessation is managed.
  • Term licenses often convert to perpetual if you pay a certain amount (some agreements allow a portion of term fees to count toward a perpetual buyout).
  • If SAP provides any temporary licenses (such as a temporary increase in user count for a project or test), be sure to track those and either remove the users or formalize the license if you retain them beyond the allowed term.
  • Example: SAP sometimes granted temporary engineering licenses or “evaluation” copies for 3-6 months. Those should not be used for production beyond their term. ITAM should ensure any such use is discontinued or converted to proper licensing.
• Cloud Extension Program (CEP/SCE): We touched on this in optimization, but contractually:
  • If you participate in an SAP cloud extension program, the terms will be documented in an addendum to this agreement. It might say you’re allowed to reduce on-premise maintenance by X as you ramp up cloud subscriptions, with the understanding that if you fall short on cloud spend, you might owe something. Read those terms carefully – ensure you meet any minimum cloud purchase commitment to avoid penalties.
  • Also, see if it includes a “right of return”; some programs allow reverting to on-prem licenses if the cloud journey doesn’t go as planned. Knowing your escape hatch (or lack thereof) is vital.
• License Metric Changes (Conversion Rights): Occasionally, SAP modifies a metric or product name. For example, SAP may deprecate a certain user type and introduce an alternative. Contracts may include clauses that allow SAP to replace a license with an equivalent new one. Generally, that works in the customer’s favor (e.g., you automatically get rights to the successor product). Ensure you obtain documentation from SAP of any conversions. For instance, SAP might say, “Your legacy SAP ERP Limited Professional User is considered equivalent to S/4HANA Functional User for conversion purposes at a ratio of 1:1.” Get that in writing.
  • When moving to S/4 or other new products, insist on a conversion checklist in the agreement that lists exactly how each old entitlement maps to the new ones. This prevents ambiguity later.
• Unused License Give-Back: As mentioned, standard SAP contracts forbid you from just returning licenses for a refund or maintenance reduction. There’s typically a clause that fees paid are non-refundable and licenses are non-cancellable. However, in negotiated large deals, a customer can sometimes insert a clause for flexibility – e.g., an option to drop a certain percentage of licenses at a specified time. If you have that, be mindful of the window (like “may reduce up to 10% of users at first anniversary”). Exercise it if needed, because such concessions are rare.
• Price Protections: Review your contract to determine if it offers price protection or discount tiers for future purchases. Some agreements state that any additional purchases made within an X time frame receive the same discount percentage as the initial purchase. This is valuable – it prevents SAP from quoting a much higher price later. If you have it, remind SAP of it when buying more if you don’t, consider negotiating it in the next big purchase (e.g., “for the next 2 years, any extra users will be at a discount of Y%”). SAP might limit it to similar license types.
• Test/Developer Use Terms: In some older contracts or specific product schedules, explicit allowances for development/test usage may exist. For example, SAP BusinessObjects had a note (as indicated in their usage rights) stating that non-productive installations are permitted. If your contract or SAP’s official use rights document for your product version states something like that (e.g., “customer may use the software on non-production systems for testing without additional license”), print that out and keep it handy for audit time or internal debates. It can settle arguments if someone claims you need a second license for a QA system – you can show the official policy.
  • Similarly, check if the contract defines what “Use” includes or excludes – some have clarifications, such as “Use does not include solely viewing data through a non-SAP application” (which was a point SAP added to clarify that read-only, indirect access is not charged). These small clauses are crucial in defending your stance on indirect usage or other scenarios.
• Named User License Transferability: While licenses are tied to individuals, contracts allow reassignment when roles change or people leave, as long as you don’t circumvent licensing by rotating a single license among multiple active users. Ensure your processes align: when an employee leaves, you can reassign their license to their replacement. If SAP were to ask (rare, but in theory possible, as they could check logs of user creation dates versus license count), you should be able to demonstrate that it wasn’t simultaneous usage beyond licensed users.

Conclusion on Contract Terms:

Always read the fine print of SAP agreements and keep them in a known repository. Engage your legal team to interpret any odd clauses.

The contract is ultimately what defines compliance, not just general SAP policy. Some customers have been grandfathered into existing terms or negotiated exceptions; you must be aware of these.

For example, suppose your contract explicitly allows a specific third-party interface with no additional license (perhaps as a one-time deal). In that case, that’s your get-out-of-jail card if an auditor questions that scenario. But if you don’t know it, you can’t enforce it.

Finally, keep updated: SAP occasionally updates its standard terms (like the yearly SAP Software Use Rights document). While your contract, as signed, is what you abide by, new products you license may come under different terms.

So periodically review SAP’s current licensing manuals – they give insight into SAP’s direction (and often contain clarifications that might help you even for older contracts if not explicitly contradicted).

Recommendations for ITAM Practitioners

SAP licensing can be complex, but ITAM professionals can make it a well-controlled domain through diligent management.

Here are actionable recommendations to maintain control, reduce risk, and align license use with entitlements:

1. Maintain a License Inventory and Document Repository: Keep an up-to-date inventory of all SAP entitlements – including license counts, types, metrics, and associated contract documents. This should be easily accessible to the ITAM team. When questions arise (e.g., “Can affiliate X use the system?”), You can quickly check the contract or use rights to find the answer. A centralized repository of SAP contracts, order forms, and SAP policies is essential for informed decision-making.
2. Implement Continuous License Monitoring: Don’t treat SAP compliance as an annual event. Set up a schedule (monthly or quarterly) to review user license assignments and key usage metrics. Leverage automation or scripts to flag anomalies (such as a user with unusually high activity who might need a different license). The earlier you catch a compliance drift, the easier it is to correct it without drama.
3. Integrate License Checks into IT Processes: Embed SAP license management into onboarding, offboarding, and project rollout.
   • New employees or contractors must be assigned the correct license type and logged into a tracking system when they need SAP access.
   • When people leave, ensure their SAP account is removed or reassigned promptly to recycle licenses.
   • For new SAP functionality deployments (new modules or interfaces), make it a requirement that the project team consults with ITAM on licensing before going live. This way, indirect access or extra engine license needs are identified and resolved in advance.
4. Educate and Communicate: Where appropriate, provide training or cheat sheets about licensing to SAP application owners, security administrators, and even end-users. For example, educate security teams that assigning certain roles might necessitate a Professional license. Educate department heads that adding 50 contractors to SAP isn’t “free”—they need licenses. The more stakeholders understand the basics, the fewer surprises they will encounter, and the more they will involve ITAM at the right times.
5. Use Tools and Data for Decision Support: Invest in an SAP license management tool (or fully exploit SAP’s tools) to gain visibility. Use data from these tools to drive decisions – for instance, a dashboard showing license utilization percentages for each module can highlight where you have headroom or a shortfall. Data also strengthens your hand in negotiations (e.g., showing SAP a trend of declining user count in a module to justify reducing licenses).
6. Optimize Before You Buy More: Make it a policy that before purchasing additional SAP licenses, the ITAM team must confirm that existing licenses are being used optimally. This includes reassigning unused licenses, downgrading where possible, and confirming that no internal reallocation can solve the need. Only after this analysis should you approach SAP for more licenses. This prevents unnecessary purchases and encourages internal discipline.
7. Plan for S/4HANA and Future Transitions: If you are not already on S/4HANA, start mapping out the license transition strategy now. Understand how your current licenses align with S/4 and identify any gaps or surpluses. Engage SAP early to explore conversion options—sometimes, there are time-limited programs or better deals for early movers. Also, keep an eye on SAP’s roadmap (e.g., new cloud services, changes in pricing) so you can anticipate impacts on your license landscape.
8. Stay Informed on SAP Licensing Changes: Subscribe to SAP user group communications or SAP’s licensing updates. SAP occasionally refines its policies (for example, clarifications on indirect access and new licensing bundles, such as Rise or GROW programs). Awareness of these changes enables you to proactively adjust your strategy or capitalize on new offerings. Networking with peers (through ITAM forums or SAP user groups) can also provide insights into how others handle common challenges.
9. Audit Yourself Before SAP Audits You: Run a full internal audit simulation at least once a year. Address any issues found, and document the actions taken. This prepares you for an actual SAP audit and builds evidence of good governance. If an official audit occurs, you can demonstrate your proactive compliance efforts, which may make SAP more cooperative or lenient in negotiations.
10. Engage in Proactive Dialogue with SAP: Cultivate a working relationship with SAP’s account team outside of just sales pitches. For instance, if you foresee a potential compliance issue, it might be better to discuss it with SAP to find a resolution rather than wait for them to catch it. They may offer solutions like a temporary license or a discount on required licenses in advance. Also, negotiating from a position of transparency (with data in hand) can build trust. Just be cautious to never over-share internal data without understanding the implications – share enough to get help, but not so much that it exposes you to unnecessary scrutiny.
11. Evaluate Third-Party Support vs. SAP Support Strategically: Don’t default into renewing SAP support without analysis. Periodically evaluate if third-party support could make sense (financially and operationally) for your context, especially as products near end-of-life. Even if you stay with SAP, knowing your options gives you leverage. If you stick with SAP support, maximize its value by using the support resources (e.g., opening tickets, utilizing SAP’s support tools, attending SAP’s support advisory sessions) – get your money’s worth.
12. Governance and Policy: Develop internal SAP licensing policies approved by management. For example, a policy that “All production SAP users must be assigned an appropriate license type as per ITAM guidelines; using a generic login for multiple people is prohibited.” When these rules are officially endorsed, it’s easier for ITAM to enforce them. Additionally, a governance body or periodic meetings should be established between ITAM, SAP Basis/Security, procurement, and finance to review the SAP licensing status. This cross-functional approach ensures alignment and visibility at the right levels.
13. Budget for Growth and Change: Companies often grow or change their optimization, leading to new SAP requirements. Plan a contingency in your budget for SAP license expansion or audits. That way, if you do need to true-up or buy additional licenses, it’s not a fire drill to get funding. Being financially prepared allows you to negotiate without panic and potentially secure more favorable purchases (e.g., aligning them with SAP’s year-end for better discounts, if you have a budget earmarked).
14. Leverage Expert Help if Needed: SAP licensing is a specialized area. Consider consulting with SAP license experts or firms specializing in SAP contract negotiations if undergoing a big change (like a merger, S/4 migration, or an audit dispute). While this guide empowers you with knowledge, sometimes an outside perspective or benchmark data can unlock additional savings or protect you from pitfalls others have experienced.

By following these recommendations, ITAM practitioners will strengthen their command over SAP licensing.

The goal is to minimize surprises (avoid unbudgeted compliance penalties), maximize efficiency (utilize fully what you pay for), and maintain flexibility (ensure licensing doesn’t become a barrier to business innovation).

In essence, SAP licenses should be treated as strategic assets to be managed, not just as cost items.

With careful oversight, you can support your organization’s SAP-driven initiatives while reducing costs and risks, fulfilling the role of a true internal license advocate and guardian.

FAQs about SAP Licensing

SAP licensing can be complex and confusing. Here are some common questions and misconceptions about SAP licensing:

Q: How are SAP licenses priced? A: Pricing varies based on factors like license type, deployment model, and the size of your operation. Specific quotes are obtained through SAP or authorized partners.

Q: Can SAP licenses be transferred between users or systems? A: Transfers are generally restricted and subject to SAP’s policies, which may require formal approval and compliance checks.

Q: What happens if you exceed your licensed usage? A: Exceeding licensed usage can lead to additional charges or needing more licenses, as determined by an audit.

Q: How does SAP audit license compliance? A: SAP conducts periodic audits on its customers to ensure compliance with licensing agreements, involving self-reporting and direct inspections.

Q: Are there any discounts available for SAP licenses? A: Discounts may be available based on volume, long-term commitments, or promotional offers, but specific arrangements vary.

Q: How do you upgrade your SAP license? A: Upgrades may require purchasing additional licenses or converting existing ones, which are often discussed with SAP sales representatives.

Q: What are the consequences of non-compliance with SAP licensing? A: Non-compliance can lead to financial penalties, legal actions, and the requirement to purchase additional licenses. Work with an SAP licensing expert to avoid the risk.

Q: Can SAP licenses be leased or rented for short-term projects? A: SAP offers flexible licensing options, including short-term leases or subscriptions, particularly for cloud services.

Q: How is indirect access handled in SAP licensing? A: Indirect access refers to users or systems accessing SAP software through a third-party interface, requiring appropriate licensing.

Q: What is the difference between standard and professional SAP user licenses? A: The main difference lies in the scope of access and functionality, with professional licenses typically offering broader access.

Q: How does SAP licensing work for multinational companies? A: Multinational companies may require global licenses and agreements tailored to their international operations and legal requirements.

Q: Is there a minimum purchase requirement for SAP licenses? A: The minimum requirement can vary depending on the specific SAP product and licensing agreement.

Q: How do cloud deployments affect SAP licensing? A: Cloud deployments may offer more flexible and scalable licensing options than traditional on-premise installations.

Q: What are the options for SAP licensing in a virtualized environment? A: SAP supports virtualized environments, but specific licensing terms may vary, requiring careful planning and consultation with SAP.

Q: How frequently does SAP update its licensing models and terms? A: SAP periodically reviews and updates its licensing models to reflect new technologies and market conditions, but major changes are typically announced well in advance.

Further Reading

• SAP License Compliance Tools and Metrics
• Hybrid SAP Licensing Guide for Two-Tier Environments
• Managing SAP Licensing Risk