SAP Licensing Glossary and Key Definitions

SAP Licensing Glossary and Key Definitions

Introduction: This reference-style glossary provides clear definitions for key terms and concepts in SAP software licensing. It covers on-premises licensing (SAP ECC, SAP S/4HANA On-Premise) and cloud subscription models (RISE with SAP, SAP Ariba, SuccessFactors, Concur).

Terms are organized into categories (User License Types, Licensing Models & Metrics, SAP Products/Offerings, and Compliance Tools) and listed alphabetically within each category.

Short examples and notes illustrate real-world licensing context. Use this glossary as a reference for understanding SAP’s licensing terminology and ensuring compliance and optimal license management.

User License Types and Roles

• Developer User: A named user license for individuals who develop or customize SAP software. It grants broad access to development tools and is one of the most comprehensive (and expensive) user licenses. For example, SAP developers writing ABAP code or building custom reports need a Developer User license to access the development workbench.
• Employee User (Employee Self-Service User): A low-level named user license for employees performing self-service tasks or basic functions. An Employee user is limited to actions for the individual’s use (such as entering timesheets or viewing personal data) and cannot perform tasks on behalf of others​. In practice: This license suits users who only access HR self-services or simple inquiry screens.
• Limited Professional User: A legacy named user license for people with restricted operational roles. A Limited Professional User is authorized to perform a subset of the activities of a full Professional User​. It was often used to license users who didn’t need the full range of SAP functionality. Note: SAP phased out the Limited Professional license for new contracts after 2015–2016, so new customers must use other user categories. Existing SAP customers with this license type could continue to procure it under prior agreements.
• Named User: In SAP’s model, every individual or system that accesses SAP software (directly or indirectly) must be assigned a unique Named User license. A named user is any employee of the customer (or affiliate or third-party) authorized to use the SAP software, regardless of the technical interface​. That user’s specific role then determines which license category is required (e.g., Professional, Employee, etc.)​. Named user licenses make up the foundation of SAP licensing – they are non-transferable and not shared, unlike “concurrent” user models in other software. Each named user license grants the person certain permissions defined by that license type.
• Professional User: The standard high-level named user license that grants full operational access to SAP. Professional Users are authorized to perform broad business and administrative tasks across SAP modules​. This includes activities like executing transactions in finance or logistics, running reports, and even basic system administration. In SAP’s classic model, if a user is not explicitly assigned a lower license type, they default to a Professional User (among the most expensive categories). Example: A finance manager or system administrator typically needs a Professional User license to carry out their day-to-day work in SAP.

Licensing Models and Metrics

• Concurrent User License: A licensing model where usage is limited by the number of users accessing the system (sessions simultaneously) rather than by specific named individuals. Important: SAP generally does not use a concurrent user model for its core products – SAP requires named user licenses for each person. However, certain cloud products or contract provisions may allow concurrent usage. For example, some SAP Ariba contracts have allowed a limited number of users to be logged in simultaneously (concurrent sessions), even if more user accounts exist. This is an exception and must be explicitly agreed upon in the contract. Assuming SAP licensing is named-user-based unless a specific “concurrent user” clause is provided.
• Digital Access: SAP’s document-based licensing model for indirect use of SAP ERP (introduced in 2018). Under Digital Access, customers license SAP by the number of specific documents created by any indirect or external system interaction rather than by named users​. SAP identified 9 Document Types (e.g., Sales Order, Invoice, Purchase Order, etc.) that count toward Digital Access. Whenever an external system (or non-named user/bot) triggers creating one of these document types in the SAP system, it consumes Digital Access licenses. This model is SAP’s response to indirect access concerns – it covers certain indirect usage scenarios with an outcome-based metric (documents) instead of requiring a named user for each external user/system. Example: If an e-commerce website not directly on SAP creates 1,000 sales orders in SAP ERP, those would count as 1,000 documents against a Digital Access license. (Viewing or reporting on data typically does not count, only document creation). Digital Access is an optional model – customers can stick with traditional indirect usage licensing or adopt Digital Access (often with incentives via SAP’s Digital Access Adoption Program).
• Document Type (Digital Access): In the context of SAP Digital Access, a Document Type is one of the nine categories of business documents that SAP counts for licensing purposes. These include Sales, Invoice, Purchase, Service & Maintenance, Manufacturing, Quality Management, Time Management, Material, and Financial documents. Only documents of these types, when created indirectly, fall under the Digital Access license. Each document type may be weighted or priced differently, but they all represent the measurable digital access units. Note: If an indirect activity in SAP does not create one of these document types, it may not require a Digital Access license​ (though standard named user rules could still apply if users are involved).
• Engine (Package) License: In SAP terminology, an “engine” (or package) refers to a specific add-on software component or module that is licensed based on a metric other than named users. Engine licenses are modular: they provide access to particular SAP functionality (for example, SAP Payroll, SAP CRM, or a database engine) and are measured by their usage metrics. Common engine metrics include the number of employees (for an HR module), orders processed, annual revenue, system capacity, or other business metrics​. Each engine has a unique metric and sometimes threshold levels. For instance, an engine license might allow up to X records or transactions before moving into a higher license band. Hundreds of SAP engines are defined in the price list with a specific unit of measure​. Managing engine licenses requires monitoring those usage metrics continuously since exceeding licensed amounts (over-utilization) can lead to compliance issues or additional fees. Example: A company using SAP Payroll (an engine) might license it for up to 10,000 employees. The company must purchase additional engine capacity if its employee count grows beyond 10,000.
• Full Use Equivalent (FUE): A metric used primarily in RISE with SAP S/4HANA Cloud licensing to normalize different types of users into a single consumption currency. Under the FUE model, each user is not licensed individually; instead, the customer purchases a pool of FUEs and allocates them to various user roles. Each role “costs” a certain fraction or multiple of an FUE. For example, in the current RISE model:
  • 1 Advanced Use user = 1 FUE (per user).
  • 1 Core Use user = 0.2 FUE (i.e., 5 Core users per 1 FUE).
  • 1 Self-Service Use user = ~0.033 FUE (30 Self-Service users per 1 FUE)​.
  • 1 Developer user = 2 FUE (developers consume more from the FUE pool)​.
    Using these ratios, an organization might purchase, say, 100 FUEs and then allocate them to, for instance, 50 Advanced users (50 FUE), 100 Core users (20 FUE), 300 Self-Service users (10 FUE), and 10 Developers (20 FUE) = a total of 100 FUE. The FUE system allows flexibility to reassign capacity as user counts change, but it introduces complexity in ensuring you have the right mix. Key point: FUE is essentially the “currency” of user licensing in a RISE subscription, encapsulating various user types under one metric​.
• Indirect Access: A usage scenario where a person or application uses SAP’s data or functions without directly logging into the SAP system through the standard GUI/API. In other words, SAP is indirectly accessed via a third-party interface, middleware, automated process, or non-SAP front-end. According to SAP policy, any use of SAP software (even indirect) requires a license​. Classic examples of indirect access include data entered into SAP via a customer web portal or SAP data being retrieved by a third-party reporting tool. Traditionally, SAP expected customers to cover indirect users with named or software licenses as direct users. This became a hot topic after some high-profile compliance cases. In modern terms, indirect access is often addressed by SAP’s Digital Access model (document-based licensing) to provide an alternative way to license this use. However, not all indirect scenarios are covered by Digital Access (only those creating the 9 document types). Others may still require named user licenses or separate agreements. Important: SAP has an Indirect Static Read exception – if data is exported out of SAP and accessed in read-only form by another system or user (with no real-time transaction back into SAP), SAP does not require a license for that read-only usage​ (e.g., a static report or data warehouse extract). However, any create/update actions coming back into SAP from external systems would be indirect usage that needs licensing.
• License Metric: In SAP licensing, a “license metric” is the unit by which usage is measured for licensing purposes. Named user licenses use users as the metric (per individual). Engine/package licenses use business metrics (orders, revenue, employees, etc.) or technical metrics (CPU cores, memory, SAPS) as the measure. For cloud SaaS, metrics can be subscriptions per user or employee per year (in SuccessFactors) or documents (in Digital Access). Understanding the metric for each SAP product or component is critical for compliance. For example, SAP SuccessFactors commonly uses a metric called Per Employee Per Year (PEPY), meaning you pay for each employee account annually​. SAP Ariba might use spend volume (dollars of spend) or the number of documents as a metric for certain modules. Always check the SAP price list or contract for the precise metric definition of each license.
• Perpetual License: The traditional SAP licensing model, where a customer buys a software license with a one-time fee and owns the right to use that software indefinitely. Perpetual licenses are typically accompanied by an annual maintenance fee (usually ~20–22% of the license price), which covers support and updates​. This model has been common for on-premise SAP products like SAP ECC or SAP Business Suite. Under a perpetual license, the customer’s rights to use the software do not expire, but staying on maintenance is required to get upgrades and stay compliant with support contracts. Example: A company might purchase 100 Professional User licenses and 1 SAP ERP package license perpetually, paying a large upfront cost, then pay annual maintenance on those licenses. They can use the software indefinitely (even if they stop paying maintenance, they won’t get support or updates).
• Subscription License: A licensing model where the software’s rights are provided for a defined term (e.g., yearly or monthly) in exchange for recurring fees. In SAP, subscription licensing is typical for cloud offerings and newer models (like RISE with SAP, SAP Ariba, SuccessFactors, and Concur). The subscription fee often includes software usage rights, support, and cloud infrastructure​. Unlike a perpetual license, if you stop paying for the subscription, your rights to use the software end. Subscription licensing turns software cost into an operating expense (OPEX) rather than a capital investment. It also usually ensures you are on the latest version (since cloud services are updated by SAP regularly). Example: SuccessFactors might be sold at $X per employee per month – the customer is billed annually for active employee accounts, which cover software and maintenance. Subscription models offer flexibility and lower upfront costs, but over a long period, the total cost can exceed a one-time purchase if not managed.

SAP Products and License Offerings

• SAP Ariba: A cloud-based procurement and supply-chain collaboration platform from SAP. Licensing for SAP Ariba uses a hybrid model – it combines user-based subscriptions with transaction-based fees. For modules like Ariba Sourcing or Supplier Lifecycle, licenses are often sold per named user (e.g., a certain number of “Buyer” or “Category Manager” user seats). Meanwhile, transactional modules like Ariba Buying and Invoicing (Procure-to-Pay) may be licensed based on annual spend volume or documents processed through the system (for example, a fee as a percentage of procurement spend or a tiered price for the number of invoices)​. Additionally, the Ariba Network (now part of SAP Business Network) introduces fees for suppliers; large suppliers pay subscription fees based on the number of documents or total sales volume with customers on the network. In summary, SAP Ariba licensing can involve (1) internal user licenses, (2) fees based on procurement spend or document count, and (3) supplier-side charges on the network. This requires careful attention to usage metrics to avoid overage costs.
• SAP Concur: SAP’s cloud Travel and Expense Management solution is offered as SaaS. Concur is generally licensed on a per-user subscription basis, but with an important nuance: it often counts active users and transactions rather than a simple named user count​. Typically, a company will pay a base subscription fee that includes a certain number of active users (or expense reports per month), and beyond that, there are per-transaction fees (e.g., $X per expense report processed) or charges for each additional active user over the base. For instance, a Concur contract might allow up to 100 active users and 500 expense reports per year for a fixed price, and if those numbers are exceeded, extra fees apply per additional report or user. This model aligns cost with actual usage (e.g., if fewer employees file expenses in a given month, costs stay lower). Tip: Companies must proactively deactivate ex-employees or idle accounts in Concur since any active account may incur subscription fees. Monitoring usage (users and number of expense reports) is key to managing Concur licensing.
• SAP ECC (ERP Central Component): The core on-premises ERP system from SAP’s earlier generation (part of SAP Business Suite, predecessor to S/4HANA). SAP ECC 6.0 includes Finance, HR, Logistics, Sales, etc. modules, providing an integrated enterprise resource planning suite. Licensing SAP ECC is done via the classic model: perpetual licenses for the software, a set of Named User licenses for all users, and additional package licenses for add-on modules. In an ECC environment, you might purchase user licenses in categories (Professional, Limited Professional, etc.) and engines like SAP Payroll, CRM, etc., each with its own metrics. ECC licenses are usually governed by a SAP Price List (SAP Software Use Rights) document that defines what each user type or package includes. Note: SAP ECC is nearing end-of-life regarding mainstream support (support until 2027), and SAP encourages customers to move to S/4HANA. However, many SAP customers in 2025 still run ECC and thus manage licenses under the older definitions.
• SAP S/4HANA: SAP’s next-generation ERP suite was released in 2015, which runs on the in-memory HANA database. S/4HANA can be deployed on-premise or in cloud variants, and SAP’s licensing for S/4HANA has evolved from the ECC model. For S/4HANA on-premises, the license is still primarily based on Named Users and packages, but the user categories have been simplified in newer contracts. SAP has reduced the number of on-prem user types to a few standard roles (for example, Professional, Functional, and Productivity users in S/4HANA) with role-based entitlements. These are generally aligned with what the user is authorized to do in the system (and SAP tools can measure user authorizations to classify them).
  Additionally, S/4HANA introduced the Digital Access option for indirect usage (document licensing). For S/4HANA Cloud, which is often sold via RISE with SAP, the licensing is subscription-based – customers don’t buy “S/4HANA licenses” per se but rather subscribe to the service (with user counts measured in FUEs as described above or by module bundles). The S/4HANA Cloud (public edition) is sold as SaaS and includes automatic updates, whereas S/4HANA Private Cloud (RISE) is a subscription but more similar in function to on-prem (just hosted by SAP). In either case, moving to S/4HANA usually means a contract conversion – SAP will transition your existing ECC licenses into a new S/4 license contract, which may change how user counts are calculated (often based on roles/authorizations rather than historically named user mapping). Key takeaway: S/4HANA continues the named-user tradition with fewer user license types and emphasizes proper user role classification, especially for on-premise deployments.
• SAP SuccessFactors: SAP’s cloud-based HXM (Human Experience Management) suite, which covers HR and talent management functions (such as Employee Central, Recruiting, Learning, etc.). SuccessFactors is licensed in a Software-as-a-Service model. The primary metric is users (employees) per year, often called Per Employee Per Year (PEPY) licensing​. Customers subscribe based on the number of employees or worker accounts that will be managed or have access to the system. For example, a contract might be for 5,000 employees for a 3-year term, meaning the annual subscription fee is based on 5,000 active employee records in SuccessFactors. If the employee count grows, typically, a “true-up” is required to add more, and if it shrinks, reductions usually have to wait until renewal. In practical terms, SuccessFactors licensing means:
  • You pay a recurring subscription fee (often annually) based on workforce size and modules subscribed​.
  • It includes standard support and regular system upgrades (no separate maintenance fee as on-premise).
  • You must monitor the number of active user accounts (employees) because even inactive employees might count if loaded in the system, depending on contract terms. SuccessFactors contracts commonly define an Active User or Assigned User as any employee record in the system that can log in or have data managed. Administrators often disable login for users not intended to use the system (to classify them differently and not count toward the license).
    Example: A company with seasonal workers might negotiate a license that allows a certain high water mark of employees per year or dynamic adjustments to avoid overpaying when headcount fluctuates. The move from on-prem SAP HR (licensed by named users or CPU) to SuccessFactors (licensed per employee as a subscription) is a significant shift in the cost model​.
• RISE with SAP: A comprehensive subscription offering (launched in 2021) that bundles SAP’s software and cloud services into a single contract. SAP positions RISE as “Business Transformation as a Service,” essentially a convenient way for customers to move to S/4HANA in the cloud with minimal hassle. With RISE, instead of buying perpetual licenses for S/4HANA, database, and infrastructure separately, the customer signs one subscription contract that includes the S/4HANA software (Cloud edition or private edition), the underlying infrastructure (on SAP’s cloud or hyperscalers like AWS/Azure, managed by SAP), basic technical management services, and support​. It’s often summarized as “one offer, one price, one contract,” covering all these elements. RISE with SAP operates on a subscription (term license) basis – you no longer own the software licenses; you pay an annual subscription fee for the package. Licensing in RISE: Instead of named user counts, SAP uses the Full Use Equivalent (FUE) model (see above) to measure users, which provides flexibility in assigning different users under the subscription. RISE subscriptions also include certain cloud platform services and credits; customers can add extra cloud services as needed. Real-world note: Adopting RISE usually means converting your existing SAP contract to a new one, relinquishing old perpetual licenses in favor of the RISE subscription. SAP touts simplification and a TCO reduction with RISE since it can potentially reduce infrastructure and operational costs by bundling them​. However, customers must carefully evaluate the long-term subscription costs and the specifics of what is included (some peripheral products might still require separate licenses). RISE is a popular option for SAP ERP customers moving to the cloud since it covers many aspects (license, hosting, support) under one agreement.

License Compliance and Audit Tools

• License Administration Workbench (LAW): A tool SAP provides to facilitate the annual license audit/measurement process. LAW aggregates and consolidates license usage data from across the SAP landscape​. Here’s how it works: Each SAP system is first measured using transaction USMM (User and Session Measurement Management), which counts the number of users by license type and any package usage in that system. The LAW tool (accessible via transaction SLAW in SAP) then combines the USMM results from all systems into one unified report​. Critically, LAW helps de-duplicate users – if the same person (same user ID) exists in multiple systems, LAW can identify that and count them only once for licensing purposes​. The output of LAW is used to compare against the licenses you have purchased. Companies typically run LAW when preparing their annual compliance audit submission to SAP. Key benefit: LAW prevents over-counting of the same user and provides SAP (and the customer) a consolidated view of license consumption across a whole SAP environment.
• License Audit: The formal process by which SAP reviews a customer’s usage of SAP software to ensure compliance with license agreements. Under most SAP contracts, customers must undergo an annual audit (sometimes called system measurement)​. In a standard audit, SAP’s Global License Auditing and Compliance (GLAC) team will ask the customer to run measurement tools (USMM and LAW) and submit the results. The aim is to verify that the number of users classified in each license category and the usage of package metrics do not exceed what the customer has contracted. An SAP license audit typically checks the number of licenses purchased matches the number used​. If the audit finds over usage (more usage than licenses owned), the customer is expected to purchase additional licenses (a “true-up”) to cover the gap, possibly with back maintenance. If the customer is underusing (has licenses they paid for but aren’t using), there’s no refund, but it highlights shelfware. Audits also help protect SAP’s intellectual property rights by ensuring customers are not using software beyond what they paid for. Note: There are two levels of audit – a basic self-declaration audit (yearly) and a possible enhanced audit (every few years) where SAP might get more deeply involved or on-site verification. Preparing with proper license records and performing internal reconciliation via LAW/USMM will make the audit process smoother.
• License Measurement: In SAP parlance, this refers to the routine process of measuring and recording the usage of SAP licenses within an organization. This is often done using SAP’s measurement programs. USMM (the system measurement tool) is executed in each system to count users and engine usage, and LAW/SLAW consolidates these counts. SAP typically requests customers to perform this measurement annually (or in some cases, quarterly for certain products) and report the figures. From the customer’s perspective, license measurement is a crucial practice for internal compliance – by classifying users correctly and identifying unused accounts, companies can optimize their license allocations before an official audit. After measurement, companies can reassign or reclassify licenses (for example, if a user was assigned a Professional license but only uses ESS functionalities, they might be reclassified to an Employee user to free up an expensive license). Regular license measurement and reconciliation help avoid last-minute surprises in an audit and can save costs by identifying inactive users or over-provisioned licenses. Many organizations now use specialized SAM tools or services to assist with ongoing SAP license measurement rather than relying on the once-a-year USMM run.
• SLAW (System Landscape Audit Workbench): This is essentially the transaction code and acronym used for the SAP License Administration Workbench. SLAW is the older name (and transaction) for LAW in SAP systems, whereas newer systems use SLAW2 for the updated version of the tool. SLAW and LAW refer to the same concept – consolidating system measurements. SLAW allows you to import measurement results from satellite systems, reconcile user lists, and prepare the consolidated audit report. See License Administration Workbench (LAW) above for details.
• USMM (User Measurement System): The SAP transaction for system measurement. USMM is run in each SAP system (client) to tally up usage. Specifically, USMM will determine the number of users classified in each license type in that system and count certain “engine” metrics (like the number of documents or objects pertinent to package licenses)​. Administrators must ensure all users in the system are assigned the correct license type before running USMM. When executed, USMM produces a measurement log/file that lists how many Professional users, Limited Pro users, etc., are found (based on the assigned classification in user master records) and how much of each package metric is consumed. These USMM results are then input into LAW for cross-system consolidation.
  In summary, USMM is the local data collection step for SAP license audits, while LAW/SLAW is the global aggregation step. Using USMM properly includes cleaning up obsolete user IDs, consolidating duplicate users, and mapping each user to the appropriate license type before running the measurement. This ensures accurate results that reflect actual usage and compliant classification.