• Named User Licenses: Each user must have a license based on their role.
• User Categories: Includes Professional, Limited, Developer, and Employee Self-Service (ESS).
• Indirect Access: External systems that use SAP data require a license.
• Digital Access Model: Charges based on document creation instead of users.
• Audit Compliance: SAP regularly audits usage for compliance.

SAP Licensing Guide

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 provides a comprehensive overview of SAP licensing fundamentals and strategies, with an independent, 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 also provides flexibility to reallocate licenses internally as needs change.

Subscription Licensing: With the shift to the cloud, SAP also offers subscription-based licenses (SaaS and PaaS offerings) and newer S/4HANA contracts like 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 Expense (OPEX): This is easier to budget for as predictable periodic costs, but 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 to 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 metrics and rights in the contract match understanding (for example, know 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.

SAP License Types and Metrics

SAP’s licensing is 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 wide-ranging tasks (e.g., an SAP finance specialist or a supply chain manager using 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 certain domain (HR, procurement, etc.) 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 just perform basic tasks like 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 costs more but is limited to those needing 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 allow transactions in logistics execution and nothing in finance.

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 rep is assigned a “Limited” user license if appropriate, rather than a full Professional license, preventing unnecessary cost. Conversely, ensure no one doing high-level tasks is mistakenly on a low license (risking compliance). Periodic reviews of user roles vs. license assignment are an ITAM best practice.

• Package (Engine) Licenses: Besides 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 per 64GB of memory (effectively, hardware sizing).
  • Employee or Capacity Based—SAP Payroll might 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 per $X revenue managed through the system, or 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 since SAP may not automatically restrict when limits are exceeded).

Combining User and Package Licenses:

Typically, a user license permits a person to use any licensed package the company owns, within the rights of their user type. For instance, if you own the SAP Payroll engine and an HR Professional user license, that user can execute payroll transactions. But if you haven’t licensed the Payroll module, no user is allowed to use it. ITAM must therefore manage both dimensions: have enough named users for all people accessing, and have each module/engine licensed 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 might include a restricted-use database license, or an engine might only be used with certain SAP components).

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 users who were “Limited Professional” 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 use in literature.)Developer Use – Similar concept as 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. During migration, companies must analyze each user’s activities 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 called the digital core) includes core ERP functionality, but many add-ons are 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 changed metrics in S/4 vs 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 negotiate a brand new S/4HANA contract. This is like any new purchase – you estimate the needed users and engines and buy accordingly (subscription or perpetual). There’s no direct credit for past ECC investments, though customers often use competitive bidding or trade-in discussions to get discounts if they replace legacy systems.
  • Brownfield customers often engage in a license conversion program with SAP. SAP has offered conversion tools and programs where your existing ECC licenses can be mapped to S/4HANA equivalents. Typically, you migrate your contract: for example, your ECC Professional Users might convert into S/4HANA Professional Use licenses. In many cases, SAP requires a contract conversion or at least a license exchange process – you don’t automatically get S/4 usage rights just 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 during 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, only to use with SAP applications) or Full Use (if you plan to build non-SAP apps on the HANA platform). ITAM should check if the S/4 contract includes HANA runtime licenses; if not, that’s an extra engine to account for (licensed per memory size). The HANA database is included in the subscription in RISE with SAP (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 their 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 newer offering (launched in 2021) that packages 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 (multi-tenant SaaS version of S/4) or the Private Cloud Edition (PCE), which is essentially S/4HANA hosted 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 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, analytics), so you have 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 like users or engines on-premise; instead, you commit to a certain scope in 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 flexibility to some extent – if you need a new SAP module or additional users mid-contract, you must amend the RISE subscription (usually at set pricing). Conversely, if you over-provisioned, you might be stuck paying for unused capacity until renewal.
  • The contractual commitment is significant, often multi-year (3-5 years). ITAM should forecast usage carefully to avoid overcommitting. Unlike perpetual licenses, which you could buy gradually, RISE often expects a broad commitment up front (though you can add more 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 RISE can be more expensive over the long run, though it offloads a lot of internal overhead.
• Contract Considerations: RISE contracts differ from traditional licenses:
  • Conversion of Existing Licenses: SAP has a program where, if you move to RISE, you can convert existing maintenance value into credits. For example, if you have a big investment in on-prem licenses, SAP might offset some cloud subscription cost (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 licenses outright, if you choose not to renew, you would lose rights to run S/4 unless you negotiate some conversion back to on-prem 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 extremely customized integrations might not be allowed or incur extra 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 might still need internal or partner resources for application-level support, custom code management, testing upgrades, etc. From an ITAM standpoint, you’ll manage fewer “technical” assets (servers, DB licenses). However, you still manage software usage rights for anything not covered by RISE (e.g., if you still have some on-prem legacy SAP systems outside of RISE).

Example: A mid-size enterprise with an aging ECC system opted for RISE with SAP to move into 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 actual user count against the FUEs to ensure they don’t exceed contract terms, because 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 in a way that bypasses 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 from high-profile cases (e.g., the Diageo lawsuit) and led 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 via interfaces (APIs, intermediate tables, etc.).
• 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 – the customer is an indirect user of SAP.
• Robotics or automation (RPA) scripts that manipulate SAP data without a human user.
• Even simple scenarios, like exporting data from SAP and then using it externally, could be considered uses if updates occur back 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: 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, Service Tickets, etc. (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 be interfaces to Salesforce, websites, middleware like 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 buying 5,000 named user licenses (if SAP would classify 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 documents and often granted some free allotment or discounts to move to the document model (known as the Digital Access Adoption Program, which offered incentives like credits for existing user licenses or discounted document packs).
• Prevent Surprise Audits: Indirect use is a common audit focus. Auditors may ask for interface logs or use SAP’s “USMM/LAW” tools to detect data created 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 normally allocated (like 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 unlicensed external use only.

Practical example: A distribution company found that thousands of orders were created in SAP via an EDI interface from customers. SAP’s audit team initially deemed each customer as requiring a license. The ITAM team negotiated switching to the digital document model, 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 more volume.

Bottom Line: If ignored, indirect access can pose significant financial risk. ITAM should incorporate interface reviews into regular compliance checks and ensure 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 core ERP, SAP’s portfolio includes many cloud-based solutions 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 per user (employee) on a subscription basis. 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 licensed 1,000, you’ll be out of compliance—usually addressed at renewal or through 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 good practice is to slightly buffer your subscription count or be ready 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 – e.g., 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 (like Sourcing, Procure-to-Pay, and Contract Management) might 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 by 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 tight – if ex-employees are not removed from Concur, you might be paying for them unnecessarily. 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 solution for external workforce and contingent labor management.
  • 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). But commonly, spend-based or worker-count metrics are used.
  • Compliance Risks: Unexpected ramp-up in contractor usage could exceed your licensed count. For instance, if a company suddenly brings on 100 extra contractors for a project, the Fieldglass usage might exceed the contract. Good practice is to periodically reconcile the number of external workers in Fieldglass to what was 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, their metrics, contract terms (user count, etc.), and renewal dates. These often auto-renew annually, and usage drift can cost money 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 point; you might not get an immediate penalty, but SAP will invoice for the excess at 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 sometimes SuccessFactors (which may have tiered pricing for additional features or storage), ensure usage (documents, storage, etc.) is monitored. If you approach a threshold, you may negotiate an upgrade in advance rather than getting a surprise bill.
• Cloud vs On-Prem Licensing Alignment: Understand if any on-prem SAP licenses can be reduced due to moving 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 (like syncing SF data to on-prem SAP for payroll or financial posting) might mean you still need some licensing on both sides. Always verify with SAP or your licensing advisor before dropping on-prem licenses after adopting a cloud module.

Virtualization and Cloud Infrastructure Considerations (BYOL)

Most SAP customers run their systems on virtualized infrastructure or in cloud environments today.

It’s important to understand how Bring Your Own License (BYOL) works and the implications of virtualization on SAP licensing:

• Hardware Independence: The good news is that SAP’s software licenses are generally agnostic to underlying infrastructure. If you have a valid SAP license, you can deploy the software on physical servers, virtual machines (VMware, Hyper-V, etc.), or in the public cloud (AWS, Azure, Google) as long as the environment is SAP-certified for the software. Moving an SAP ERP from on-prem hardware into AWS, for example, doesn’t inherently change your SAP license requirements – you continue to cover the same named users and engines.
• BYOL to Cloud: Hyperscalers like AWS/Azure have SAP-certified instance types. A common scenario is migrating your existing SAP ECC or S/4 system to cloud VMs. With BYOL:
  • You reuse your existing SAP licenses and pay the cloud provider for the VM compute and storage. SAP even has reference architectures and quick-starts for deploying SAP in the cloud.
  • Ensure your SAP maintenance stays active. If you run SAP on a cloud VM and need support, SAP will only help if you have a support contract and are on a supported platform. All major clouds are supported, but double-check the versions and OS/DB combinations against SAP’s PAM (Product Availability Matrix).
  • SAP does not charge an extra fee for running in someone else’s data center. However, the SAP license key might need to be reinstalled (license keys are tied to hardware ID, which changes when you move servers or to the cloud—SAP provides new keys through their support portal for this).
• Counting Cores for Engine Metrics: While SAP named users aren’t affected by virtualization, certain CPU-based engine licenses could be. For example, if you had an older metric like “SAP ERP Limited Professional User – CPU” or a NetWeaver foundation by core count:
  • In a virtual environment, you should hard-partition or cap the VM to the number of licensed cores. If the VM can float across a larger cluster dynamically, be careful – SAP (and particularly database licenses like Oracle) might consider you using all underlying cores.
  • Solution: use technologies like VMware’s CPU pinning or dedicate a host for SAP VMs to ensure you aren’t accused of using more cores than licensed. Document your VM configurations as evidence in case of an audit that core-limited engines were indeed restricted.
• Public Cloud Marketplace vs. BYOL: Some cloud providers offer SAP software images “with license” (especially for SAP HANA or Solutions like SAP Business One). Generally, for enterprise SAP ERP, you would BYOL. If you spin up a marketplace instance of SAP HANA, ensure you understand if that includes a temporary license. Many enterprises prefer to use their SAP-issued license keys on generic VMs rather than marketplace images to avoid confusion.
• SaaS vs. IaaS: Don’t mix up SAP’s cloud products (SaaS) with hosting your own SAP on IaaS. Running your SAP ECC on Azure is infrastructure-as-a-service – you still need your regular SAP licenses. Whereas subscribing to SAP S/4HANA Cloud or RISE is SaaS/subscription – no perpetual license needed in that case, it’s included in the fee. ITAM might manage both: e.g., a company might run some SAP systems on Azure (BYOL) and simultaneously use some SAP SaaS products.
• Impact on Database and Third-Party Licenses: Another angle: If your SAP runs on a database like Oracle or MS SQL (underlying DB not licensed through SAP), moving to the cloud can trigger different licensing rules for that database. For example, Oracle’s infamous licensing on AWS/Azure could require licensing all vCPUs with certain factors. While this is not a SAP license per se, an ITAM practitioner overseeing SAP must account for database license compliance in new environments. SAP offers a database-as-part-of-license for some products (SAP’s own ASE, MaxDB, or HANA runtime). Review your contract: if you had an Oracle license through SAP (OEM license), check if it allows usage on cloud VMs or if there are restrictions (OEM licenses are often tied to specific usage and might not allow certain cloud deploys without approval).
• Containers and New Tech: Running SAP in containers (Docker/Kubernetes) is not mainstream for the core applications, but SAP is developing cloud-native solutions. If you ever containerize an SAP app, treat it like a VM for licensing—ensure the deployment doesn’t exceed licensed capacity. Always keep a one-to-one mapping of deployments to license entitlements.

Example:

An ITAM analyst oversaw moving SAP ERP to VMware farms. They ensured the SAP Central Instance VM was restricted to 4 cores, matching the 4-CPU license the company had for an older integration engine component. They documented this setup in case of an audit. Later, when shifting that environment to Azure, they opted for a VM size with four vCPUs and disabled auto-scaling, so the license metric remained compliant. They also coordinated with the Oracle DBA to ensure the Oracle database license (purchased independently) was correctly accounted for under Oracle’s cloud policy. This holistic approach avoided both SAP and database license pitfalls during the migration.

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. So, an SAP developer with a Developer Named User license can work in development, test, and production – it’s all covered by their one license.You do not need to buy duplicate user licenses for each system. Licensing is per user, not per system. However, if 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 they still need to be licensed named users. Every individual using SAP software, even in a test client, should have a license of 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 own policies often allow unlimited installation of the software 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.
  • As ITAM, it’s safer not to rely on unwritten rules. If you anticipate using a DR environment for an extended period (e.g., during a data center migration, when you might switch to DR for a few weeks), discuss this with SAP or get a written clause that permits it.
  • On the technical side, SAP provides temporary license keys for DR systems when activated (for example, in cloud environments, a 28-day temporary key can be generated when you start a production clone). However, note that the temporary key is just a mechanism to keep the system running; it doesn’t override the legal licensing requirement beyond that grace period.
  • Remember: User licensing is done by a named individual. If all your users are already licensed, you’re not suddenly having new users when they use the DR system. The main concern is whether the DR system doubles some licensed metric, such as instances of an engine. In most cases for SAP ERP, engines are licensed per metrics like 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 both production and the DR up to compare or simulate 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 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 means a failover node in the same site (like an ASCS cluster or HANA System Replication node) that might 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 you can run a secondary instance. Document all such scenarios to defend your position in an audit.

Common Compliance Pitfalls to Avoid

Over the years, certain SAP licensing mistakes 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 cheaper license type than their activity warrants. For example, all users are given “Employee Self-Service” licenses by default, even though many perform transactions that require Professional licenses. Or classifying a power user as a Limited Professional when they execute broad transactions. Regularly review user roles vs. license assignments. A good approach is to use SAP’s license audit reports or third-party tools to flag users who 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 have SAP find it and charge back-maintenance on those misclassified users.
• Generic or Shared Accounts: Some companies use one SAP login for multiple people (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 unique user IDs for every person. 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: SAP license counts in audits often include all named users created in the system, unless locked and exempted. If employees leave or change roles, and their SAP accounts remain active, you could be seen as needing 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) do not have an automatic usage cap in the software. It’s on the honor system – e.g., if you bought licenses for “1,000 Concurrent Sales Users” in CRM but you 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.
  • Get reports from SAP or relevant business systems each quarter to see 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 go into 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. Sometimes, a simple solution is to utilize an existing licensed user as a proxy, but if that account effectively serves multiple people, that triggers indirect use considerations anyway. Better to be transparent and consider Digital Access or properly named licenses for business partners.
• Cloud Module Under-licensing: With cloud services (SuccessFactors, etc.), a common pitfall 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 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 has many modules installed, but not all 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 might need a license) or SAP GRC components without buying them. Maintain a list of all SAP software engines you are entitled to, and cross-check with 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, about 30 accounts were used only to approve purchase orders and do time entry. SAP pointed out that those could have been Employee Self-Service licenses. The company still had to pay true-up for professional licenses since that’s what they were assigned (license compliance is about what is required for usage, not what was necessary in hindsight). Post-audit, the ITAM team implemented a strict process to classify users properly and downgraded dozens of users to a cheaper license, 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.

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 audit annually, though not every customer is audited yearly in practice.

ITAM practitioners should treat audit readiness as an ongoing process rather than a once-a-year 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: how many 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:
  • In each SAP production system, USMM will determine how many users are assigned to each license type and measure certain engines (SAP provides measurement programs for some packages, such as HR, SD, etc., which count transactions).
  • If you have multiple systems, then use SLAW to aggregate. 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 show, say, you used 120% of licensed capacity on a package.
  • By doing this internally (and not necessarily sharing with SAP immediately), you get a chance to fix issues. 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). Users with no classification might default to Professional in SAP’s eyes.
  • If you realized some users need a higher license type than you planned, consider purchasing the uplift 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 scan lists of transactions executed by “Limited” users to see if any should be 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 might flag if too many users are classified as “Test” or “Developer” without a proper reason. Developer licenses are higher privilege, so usually it’s fine, but if you classify almost everyone as a “Test user” to avoid license counts, they’ll 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 ask for interface lists and might question how data flows. 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 needed, treat it as a normal procurement negotiation. You might negotiate price or conditions, or even alternatives (e.g. instead of buying a huge number of new user licenses for indirect use, maybe negotiate moving to 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 turning up for 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 challenging, especially in large organizations. Tools from SAP and third-party vendors can assist in tracking and optimizing 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.
  • SAP Solution Manager (Licensing Workbench): SolMan, if implemented, 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 some Fiori apps for license assignment and analysis of user activity. For example, administrators can get a quick view of active users, last login, etc., 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, like “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 allowing entitlements and compliance management in the ServiceNow platform.
  • Custom Analytics: Some organizations build in-house tools or scripts (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 executed a certain transaction, but determining the license type needed isn’t always black-and-white. SAP’s user definitions are 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 “number of employees paid,” no tool knows your employee count unless you feed 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 switch a user’s license assignment based on recent usage (say, downgrade 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 might suffice for a smaller SAP customer.
• 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 (if it supports that).
  • 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 buying additional licenses for a new project, freeing up the expensive licenses for truly needed users. The tool also tracked engine metrics like the number of materials in the system vs. licensed allowance, alerting ITAM when they were nearing limits so they could negotiate an extension in advance. While the tool cost a significant amount, it identified optimizations that saved double its cost in the first year, and it made the annual audit a non-event because all 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 deeply understand SAP’s rules and use these tools to crunch data and provide recommendations, which the professional then validates and acts on.

License Optimization Strategies

Effective SAP license management isn’t just about avoiding compliance problems – it’s also about optimizing usage to reduce waste and get more value from what you’ve purchased.

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, and IT isn’t updated. 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 might allow you to convert that investment into, say, additional SAP BW licenses, if that suits your needs, during a deal (often requiring a net new purchase or an SAP program like the Cloud Extension policy, described below).
    • Terminate Maintenance on Shelfware: If you’re confident certain licenses will never be used, you could drop their maintenance at renewal to save annual support costs (you keep the license but lose support/updates for that portion). Be careful: SAP contracts often prevent partial termination easily, but if the shelfware is on a separate line item, you might 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 $1M/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 caution is that you usually have to sign up for a new multi-year cloud contract to utilize this.
  • ITAM’s role is to identify candidates (licenses not heavily used that could be candidates for conversion) and provide data to support negotiating a good credit 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, see if you can reallocate or optimize existing licenses to fulfill the need. Often, business units request new licenses while other parts of the company have spares.
  • Similarly, ITAM should be involved in new project planning. If a new project wants to enable a certain SAP module, ITAM should verify whether it’s already licensed and budget accordingly. Early involvement can also surface if a non-SAP solution might avoid needing 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 giving a user role X will mean they must be licensed type Y, they can flag if a request comes in 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 costs support dollars, they might be more willing to formally decommission it or use 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 your current license mix is inefficient (e.g., too many high-cost user licenses where a lower tier could suffice), approach SAP about a contract restructure. 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 any new SAP user must be approved by an ITAM analyst who checks if an existing license can be reassigned instead of buying a new one. Over a year, this policy re-harvested 50 licenses from departing employees to give to new hires, avoiding purchases. These measures ensured they maximized the use of every license dollar spent.

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 listing all licenses under support and the fee. ITAM should:
  • Cross-check the list of licenses against current usage. This is where shelfware identification (from the previous section) directly feeds in. 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 up with SAP – sometimes they may allow dropping or parking them (e.g., put them in an inactive status not counting toward maintenance, perhaps as part of a broader agreement).
  • Example: If you have 1000 Professional Users on support but only 800 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 has Standard Support (typically 19%), but new contracts usually default to Enterprise. It’s rare to change from Enterprise to Standard (SAP doesn’t encourage it, and it offers less service). But it might be a discussion point if you’re in a cost crunch and do not need the extras of Enterprise Support. Some very large customers have negotiated custom support structures, but that’s exceptional.
  • Shelfware Maintenance Holiday: Occasionally, SAP might allow temporary relief—e.g., during COVID-19, some customers negotiated delayed maintenance payments or scoped 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 who plan to stick on an older stable version for a long time or are phasing out SAP but need support in interim. Risks: SAP will consider you out of support – you cannot log official SAP support incidents. Also, if you ever want to resume SAP support or upgrade to a newer version, SAP may charge back-maintenance for the gap years or 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 3PS: Even on third-party support, you are still obligated to maintain license compliance with SAP’s terms. SAP may still exercise audit rights (though practically, they audit active customers more). If 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. 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’s essentially exiting the SAP ecosystem gradually.
  ITAM should advise leadership on the pros and cons. If cost savings are paramount and the SAP system is not evolving, 3PS could be considered. Always ensure it’s a well-informed decision, as it’s hard to reverse without cost.
• 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 pre-paid or restrict dropping support for X years.
  • If you reduce usage (say you divest part of business using SAP), SAP’s standard policy doesn’t automatically reduce your maintenance – you pay for rights, not usage. But in divestitures, you can sometimes negotiate a license transfer or termination for that portion, affecting support.
  • Termination Liability: If you tried to terminate support entirely (to go 3PS), some contracts had clauses that you lost the right to use any new versions obtained during support or had to 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 is a good checkpoint for trimming shelfware. For example, if an engine has been unused, consider formally end-phasing it. 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 pushed to S/4HANA or at least to 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). Or you might consider third-party support after that date as a bridge.
  • 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, 2028 our ECC support cost might jump by an extra 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 $200k/year in support on shelfware, even after the cost of new licenses. In another case, a company saved 50% of support costs by switching to a third-party provider after concluding their ECC system would not be upgraded and could run as-is for 5 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 releases—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 gives SAP the right to audit your usage, often with an annual frequency and some 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 on unlicensed use (SAP sometimes asks for back support fees for the period 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 attempt to 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%). Make sure all entities using SAP are covered by that definition. If your corporate structure changed (mergers, new subsidiaries), update the contract via an amendment to include them. Using SAP in a company not under the agreement could technically be unlicensed.
  • Third-Party Service Providers: Often, companies outsource or contract companies that 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 allow third-party outsourcing use. 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 might want the third party to be bound by confidentiality, etc., in 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 it exists and educate IT that no clever technical workaround will evade licensing (and trying 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 transfer to the buyer without SAP’s consent. SAP often will require the new entity to sign a fresh agreement (possibly with 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 usually have an end date by which you must stop using the software unless renewed. If your contract has any, diary those dates and ensure 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 provided any temporary licenses (like 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:
  • The terms will be documented in an addendum if you participate in an SAP cloud extension program. 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): Sometimes, SAP changes a metric or a product name. For example, SAP might deprecate a certain user type and introduce another. Contracts may have clauses that SAP can 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). Make sure you get 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: listing exactly how each old entitlement maps to 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, sometimes a customer can insert a clause for flexibility – e.g., an option to drop a certain % of licenses at a certain 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: Check your contract to see if it has price protection or discount tiers for future purchases. Some agreements say any additional purchases within X time get 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 seen in their use rights) that said that non-productive installations are allowed. 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, see if the contract defines what “Use” includes or excludes – some have clarifications like “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 little clauses matter 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 ever asked (rare, but in theory they could check logs of user creation dates vs license count), you should be able to show it wasn’t simultaneous usage beyond licenses.

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 grandfathered terms or negotiated exceptions; you must be aware of those. For example, suppose your contract explicitly allowed a specific third-party interface with no extra license (maybe as a one-off 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 at signing is what you abide by, new products you license may come under newer 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 turn it into a well-controlled domain with 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.
   • When new employees or contractors need SAP access, they must be assigned the correct license type and logged in a tracking system.
   • When people leave, ensure their SAP account is removed or reassigned promptly to recycle licenses.
   • For new SAP functionality deployments (new module or interface), make it a requirement that the project team consults with ITAM on licensing before go-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, and the more they will involve ITAM at the right times.
5. Use Tools and Data for Decision Support: To gain visibility, invest in an SAP license management tool (or fully exploit SAP’s own tools). 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 optimally used. 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 would map to S/4 and identify 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 policies (for example, clarifications on indirect access, new licensing bundles like Rise or GROW programs). Awareness of these changes allows you to proactively adjust your strategy or take advantage of 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, sometimes making 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. Also, a governance body or periodic meetings between ITAM, SAP basis/security, procurement, and finance should be set up to review SAP licensing status. This cross-functional approach ensures alignment and visibility at the right levels.
13. Budget for Growth and Changes: Companies often grow or change despite optimization, leading to new SAP needs. 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 perhaps time purchases more favorably (e.g., aligning them with SAP’s year-end for better discounts, if you have the budget earmarked).
14. Leverage Expert Help if Needed: SAP licensing is specialized. 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 (no unbudgeted compliance penalties), maximize efficiency (fully use what you pay for), and maintain flexibility (ensure licensing doesn’t become a blocker 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 keeping costs and risks at bay, fulfilling the role of a true internal license advocate and guardian.

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

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit