SAP Licensing FAQ for IT Leaders, Procurement Teams, and SAP Administrators

SAP Licensing FAQ for IT Leaders, Procurement Teams, and SAP Administrators

SAP licensing can be complex. This FAQ provides clear, concise answers to common questions about SAP licensing models, user types, indirect access, and best practices.

The goal is to help IT leaders, procurement teams, and SAP administrators understand licensing and stay compliant.

Each question targets specific long-tail queries for easy reference.

General SAP Licensing Rules (ECC vs. S/4HANA)

Q: What are the general licensing rules for SAP ECC and SAP S/4HANA?

A: SAP ERP Central Component (ECC) and SAP S/4HANA are typically licensed based on named users and software packages.

Key points include:

• Named User Licensing: Both ECC and on-premise S/4HANA use named user licenses. Every individual accessing the system needs an appropriate user license. Licenses are purchased per user and assigned according to the person’s role and usage. Shared logins are not permitted.
• Software/Engine Licenses: Certain SAP functionalities or modules (like SAP Payroll, SAP IS-U, etc.) are licensed by metrics (such as number of employees, transactions, or records) in addition to named users. ECC and S/4HANA both have these engine-based licenses in their contracts.
• S/4HANA vs ECC Differences: S/4HANA is the next-generation ERP. For on-premise S/4HANA, the licensing model is similar to ECC (perpetual licenses + maintenance), but the user categories and product package names may differ. When migrating from ECC to S/4HANA, SAP provides conversion guidelines to help existing licenses be transitioned or credited toward S/4HANA equivalents. S/4HANA also introduces new modular offerings (e.g., embedded analytics) that may be licensed separately.
• Cloud Subscription (S/4HANA Cloud): Unlike ECC, SAP S/4HANA Cloud is usually sold as a SaaS subscription. Instead of a one-time license fee, you pay recurring subscription fees. Pricing is often based on the number of users (with tiers for different user types) or usage metrics. The subscription covers software, support, and cloud infrastructure. Contracts are time-bound (e.g., 3-year subscription).
• Standard Terms: In both ECC and S/4HANA, licenses are governed by SAP’s Software Use Rights document. This defines the capabilities and rules for license use for each user type. Generally, each user license is tied to an individual (cannot be shared) and grants access only to the SAP systems and modules covered by your contract.

SAP User License Types

Q: What are the differences between SAP user license types (Professional, Limited Professional, Employee, etc.)?
A: SAP offers different categories of named user licenses to align costs with usage needs. Common user license types include:

• Professional User: This is the most comprehensive user license. A Professional User can perform broad system activities across modules. They have full operational access, including creating, changing, and viewing data in all relevant modules for which they are authorized. For example, a finance manager or procurement specialist who performs transactions, runs reports, and updates configurations would need a Professional User license.
• Limited Professional User: A Limited Professional (also referred to as a Functional or Business User in some contracts) has a narrower scope of use at a lower cost. These users can perform only specific tasks or have limited access to certain modules. For example, a warehouse clerk who only records goods receipts or an employee who only creates purchase requisitions might be assigned a Limited Professional license. They can enter and view data in defined areas but do not have full access to all SAP modules.
• Employee (ESS) User: An Employee Self-Service (ESS) or Employee User license is intended for users who perform only self-service tasks. This is typically the least expensive named user category. It covers activities such as entering personal HR data, viewing pay stubs, submitting leave requests, and filing expense reports. For instance, an employee using SAP to record their timesheet or travel expenses would fall under this license type.
• Developer User: A Developer license is assigned to users who require access to development tools (e.g., ABAP workbench) in SAP systems. It grants rights to create and modify custom objects (code, programs) but is usually coupled with a Professional license for functional access. In many contracts, developers require a Professional User license; the “Developer” designation is an add-on that permits development work.
• Other Specialized User Types: Depending on the SAP product or suite, additional user types may exist. For example, SAP Professional Employee vs. Limited Employee (differentiating power users from occasional users) or module-specific users, such as a SAP CRM Sales User for CRM scenarios. The exact definitions are detailed in your contract and SAP’s user type definitions. The main idea is to align the user’s role with the appropriate license type so you pay only for the level of access needed.

Example: Suppose your organization has an SAP ERP system. A financial analyst who creates journal entries, runs financial reports, and approves budgets would likely need a Professional User license due to the breadth of transactions.

A shop floor worker who only enters production data might qualify as a Limited Professional User. Meanwhile, a regular employee who enters time sheets would be an Employee User.

Each category comes with different costs, with the professional category being the highest. It’s essential to classify users accurately to manage costs effectively and ensure compliance.

Indirect Access and Third-Party Integrations

Q: What is SAP Digital Access (Indirect Access) licensing?

A: Indirect Access refers to using SAP software’s functionality or data via a third-party application or interface rather than directly through the SAP GUI or SAP interfaces by a named user.

Historically, SAP required a named user license for anyone indirectly triggering SAP processes.

This became a pain point for customers integrating SAP with web portals, customer-facing apps, or other systems.

SAP Digital Access is a newer licensing model (introduced in 2018) to address this via a document-based approach:

• Document-Based Licensing: Instead of requiring a named user license for each indirect user, SAP lets you license indirect usage outcomes (documents). SAP identified nine document types (Sales Order Creation, Invoice Creation, Purchase Order, etc.) covering common business objects created or accessed indirectly. You purchase a quantity of these documents for Digital Access. For example, if an e-commerce system creates sales orders in SAP, you can license a certain number of Sales Order documents per year instead of licensing every web customer.
• Indirect Static Read vs Dynamic Use: SAP makes an important distinction. Indirect static read – e.g., a third-party app simply displaying SAP data that was previously stored (without changing it in real-time) – typically does not require additional licenses. It’s considered covered by the initial license that puts data into SAP. Indirect dynamic use – where a third party triggers SAP transactions or modifies data – requires a license (named users or Digital Access). Example: If a mobile app pulls current inventory levels from SAP (read-only), that’s usually license-free. However, if it also creates an order or updates a record in SAP, that interaction must be licensed.
• Digital Access Adoption: SAP has encouraged customers to adopt Digital Access by offering conversion programs. You can trade some existing user licenses for Digital Access documents. This model provides greater transparency and potentially leads to cost savings for complex third-party integrations. However, estimating the number of documents (e.g., orders, invoices) that your integrations generate requires analysis.
• Traditional Named User option: Customers cannot switch to document licensing. You can still license indirect usage by assigning named user licenses to the external systems or “technical users” making the connections. For instance, you might dedicate a few SAP-named user accounts to an interface and count those in your license tally. This can be viable if the number of external users or transactions is small. The Digital Access model is generally more efficient for high-volume or customer-facing integrations.

Example: Consider a scenario where an SAP ERP is connected to a Salesforce CRM. Salesforce queries SAP for customer data and also creates sales orders in SAP. Under old rules, every Salesforce user who performs those actions might need a SAP user license.

With Digital Access, the company can license the approximate number of sales orders and other documents that Salesforce creates in SAP, thereby avoiding the need for individual licenses for each Salesforce user.

Q: How does SAP handle third-party system integrations in licensing?

A: When integrating SAP with third-party systems, you must ensure all indirect usage is licensed to remain compliant.

Key considerations include:

• Licensing External Users/Systems: Any use of SAP functionality by non-SAP systems (customers, partners, or employees through a different interface) is not free. You have two main ways to cover it: named user licenses for those external users (or the technical interface user) or the Digital Access document-based licenses discussed above.
• Interface/Integration Software: Using SAP’s middleware (like SAP Process Orchestration/PI or SAP Cloud Platform Integration) to connect systems does not exempt you from licensing. The middleware may be licensed separately, but the end-use of SAP data still requires coverage. Always evaluate what data or processes the third-party system triggers in SAP.
• Contract Clarity: Ensure your SAP contract or agreement covers your integration scenarios. Sometimes, special provisions are included for specific integrations or third-party applications. For example, if you use a third-party warehouse management system that updates SAP inventory, SAP may offer a special license type for external workers updating SAP via that system. Always verify if SAP offers specialized licensing for your specific scenario.
• Monitoring Indirect Use: It is advisable to document and monitor all systems that interface with SAP. During audits (or annual measurements), SAP may ask how external systems connect and whether those users or document licenses are accounted for. Implementing interface governance (like assigning a dedicated SAP user ID for each interface and tracking what it does) can help demonstrate compliance.
• Example: If a supplier portal not built by SAP allows vendors to input data, and that data is then integrated into SAP ECC, those vendors are indirectly using SAP. You could give each vendor an SAP user license (which is impractical and costly for many vendors) or use Digital Access licensing for the documents (e.g., purchase orders or confirmations) they create. Most organizations prefer the document approach for large-scale integrations.

SAP License Management Tools

Q: What tools can we use to manage and measure SAP license usage (LAW, USMM, third-party tools)?

A: SAP provides built-in tools for license administration, and there are also third-party solutions to help optimize license usage:

• USMM (System Measurement Tool): USMM is an SAP transaction (System Measurement) used to measure license usage in each SAP system. It tallies the active users by license type and usage of certain SAP components (like engines or packages). Administrators run USMM periodically or as requested by SAP. The tool generates measurement reports that list user counts in each category and consumption of metric-based licenses (e.g., the number of SAP Payroll employees).
• LAW (License Administration Workbench): LAW consolidates data from USMM across multiple systems. One user might have accounts in each if you have multiple SAP systems (e.g., ERP, BW, CRM). LAW helps identify duplicate users (the same person with accounts on multiple systems), so you don’t double-count them. It aggregates the license compliance position across your landscape. LAW 2.0 (newer version) can automatically combine measurement files and produce an integrated report. This consolidated output is typically what you submit to SAP during an audit.
• SAP Engine Metrics Tools: For some engines or packages, SAP provides specific measurement tools or reports (sometimes as ABAP programs or in USMM) to count usage. For example, SAP Solution Manager can help measure metrics like user counts for SAP Solution Manager itself or other applications.
• Third-Party License Management Tools: Many organizations utilize specialized Software Asset Management (SAM) tools for managing SAP licenses. Solutions from vendors like Snow Software (Snow Optimizer for SAP), Voquz (samQ), Flexera, or Aspera can analyze your SAP user behaviour and license assignments. These tools often provide insights into actual transaction usage by each user, suggesting if a user is over-licensed (using less than their license allows) or under-licensed. They can simulate compliance audits, track license allocations, and even automate reclassification. While SAP’s tools provide raw data, third-party tools offer advanced analytics for optimization.
• Automation and Governance: Whichever tools you use, integrate license management into your user provisioning process. For instance, when creating a new user, assign the correct license type upfront. Periodically review user roles and usage. Some organizations schedule quarterly license reviews using USMM/LAW or their SAM tool, so there are no surprises at true-up time.

SAP Audits and Compliance

Q: What happens during an SAP license audit, and how can we prepare?

A: SAP license audits (often annually or per contract terms) are formal reviews of your usage versus what you purchased.

Here’s what to expect and how to prepare:

• Audit Process: SAP (or an authorized third-party auditor) will notify you of a license audit and request data. Typically, you’ll be asked to run the USMM tool on each system and consolidate results with LAW. You submit the LAW report to SAP, which displays the number of users in each license category and any package or engine usage. SAP might also inquire about indirect usage (interfaces) and specific products. In some cases, auditors might do on-site interviews or ask for additional evidence (like user lists or contracts for third-party apps).
• Common Audit Findings: The audit will verify whether your named user counts exceed your entitlement for each category and whether you have used any unlicensed software components. For example, if you have 120 Professional Users but only purchased 100, you’re under-licensed by 20. Or if you started using a module (say SAP Cash Management) that wasn’t in your contract, that’s a compliance gap. Indirect access is also scrutinized now – SAP might identify document creation by external systems and compare it to any Digital Access licenses you have.
• Preparation Steps:
  • Internal Measurements: Run your USMM/LAW measurements before the official audit. This allows you to identify potential compliance issues in advance. Review the output for anomalies (like old user accounts counting toward licenses).
  • Clean Up Users: Before measurement, cleanse your user base. Lock or delete accounts that are no longer in use (especially those of former employees). Ensure each remaining user is assigned the correct license type in the system user master record. SAP allows certain technical/system users (like background job users, depending on the contract) to be excluded from the count.
  • Review Classification: Verify that users are classified accurately (Professional vs. Limited, etc.) based on their job responsibilities. If someone has a higher license type than needed, consider reclassifying before the audit (with documentation). Conversely, if someone were using more than their license allows, they should upgrade their classification ahead of time to avoid non-compliance findings.
  • Document Indirect Use: Prepare a summary of your third-party interfaces and how you’ve licensed them (e.g., “CRM system creates sales orders – covered by Digital Access licenses” or “Shop floor terminals use a generic SAP user – counted as 5 Limited Professional users”). Being transparent and proactive can preempt audit questions on indirect access.
  • Engage with SAP: If the preliminary check shows shortfalls, you can discuss remediation options with SAP before the formal audit report. SAP may allow you to purchase additional licenses (a “true-up”) to resolve deficits without penalties. It’s often better to address gaps proactively than to wait for SAP to find them.
• During the Audit, provide the data requested promptly. Ensure management and your SAP account executive are aware of the audit. The findings will typically be shared with you – review them carefully. If you disagree (for example, you believe some users were counted incorrectly or some engine metrics are wrong), you can dispute and provide evidence. Audits are negotiable; SAP may be open to solutions such as migrating to a different license model or adjusting your contract rather than imposing a straight penalty.
• After the Audit, implement any needed changes (procure additional licenses, remove unneeded users, etc.). Conduct a lessons-learned meeting with your team to strengthen compliance processes. SAP audits can be annual or random, so treat compliance as an ongoing effort, not a one-time event.

Managing Licenses Across Multiple Systems or Regions

Q: How can we manage SAP licenses across multiple systems or global regions?

A: Managing licenses in a complex SAP landscape (multiple instances or global deployments) requires coordination and tools:

• Global vs Local License Pools: Determine whether your company has a global or region-specific license agreement. Many enterprises negotiate an Enterprise Agreement with SAP that covers all users worldwide under one contract. In that case, you must track total usage across all systems cumulatively. If separate subsidiaries have their own SAP contracts, you must manage compliance separately per contract, which can be more challenging to consolidate.
• Unique Named Users: Aim to assign each person a single SAP user ID (or link IDs) per system and reconcile duplicates. The same individual with accounts in ERP, BW, and CRM should ideally count as one named user in license terms. If possible, use a Central User Administration (CUA) or identity management system to maintain consistent user IDs. This makes it easier to identify one person across systems.
• Use of LAW for Consolidation: SAP’s License Administration Workbench (LAW) is crucial for managing multi-system licenses. It allows you to import measurement results from each system and reconcile duplicate users. For example, if “jdoe” exists in three systems, LAW can merge those into one counted user (assuming it’s the same person). To correctly identify duplicates, you’ll need to configure user matching rules (by username or personnel number/email) in LAW. Once consolidated, LAW will output the total unique user counts by license type for all systems combined.
• Regular Coordination: Have a centralized team or coordinator for SAP licensing. This person or group should oversee license assignments and audits across all SAP landscapes. They can enforce standard policies (such as classifying a power user versus a read-only user uniformly across all systems) and gather data from each system’s administrators to update the overall license position.
• Regional Considerations: Be aware of local practices when operating in multiple regions. Some regions may create additional user accounts for support or external contractors – ensure these are accounted for. Additionally, language or localization add-ons (such as double-byte support and country-specific functionality) typically don’t require extra licenses. However, the usage of the system in different countries should still align with the headcount you’ve licensed.
• Landscape Changes: Include a new SAP system (e.g., deploy a separate SAP instance for a new subsidiary or testing) in your license scope. Non-production systems (development, test) usually do not require separate licenses as long as the users accessing them are licensed for a production system. However, if you allow additional non-prod users who don’t have production access, that could violate the terms. It’s best practice to have a named user license covering every user in any environment.
• Example: A multinational company might have an SAP ERP in Europe, another in the US, and a global BW system. To manage licenses, they use LAW to merge user counts. Suppose an analyst in France and an analyst in the US use the global BW – if it’s the same person, count them once; if different people, count each separately. The company maintains a central spreadsheet or tool that lists users and their assigned license types to avoid regional overlaps. They also coordinate the purchase of additional licenses globally to obtain volume discounts, rather than having each region buy individually.

Licensing for Specific SAP Products (BW, CRM, Ariba)

Q: Are there special licensing considerations for SAP BW, SAP CRM, or cloud products like SAP Ariba?

A: In many cases, standard SAP-named user licenses cover access to various modules (like BW or CRM), but some products and modules have unique licensing models:

• SAP BW (Business Warehouse/BW4HANA): SAP BW is typically used for reporting and analytics. Users who access BW (e.g., to run reports or design queries) still need an SAP-named user license. The same Professional or Limited user license from ECC often covers BW usage if BW is part of your SAP ERP environment. However, if you have standalone BW users (who only use BW and not the core ERP), you might license them with a specific analytics user type. SAP historically offered “SAP Business Information User” or similar licenses for users limited to reporting. In modern contracts, you’d map these users to an appropriate license category (potentially a cheaper license type since they only consume reports). Additionally, BW has an engine licensing aspect: large deployments of BW may be licensed based on the volume of data or number of records (especially for BW on HANA, where an additional HANA cost may be incurred if not covered under runtime licenses).
• SAP CRM (Customer Relationship Management): SAP CRM (the on-premise CRM as part of SAP Business Suite) also uses named users. If your SAP CRM is integrated with ECC under the same license agreement, a user with an ECC Professional license can typically utilize CRM functionality if their contract includes the CRM component. In some cases, SAP sold CRM-specific user licenses (like “CRM Sales Professional User”), which were analogous to Professional users but for the CRM module. The key is to ensure that your contract includes the usage of the CRM application. CRM may also have engine metrics (for example, you might license a certain number of business partner records, depending on the version). The newer SAP C/4HANA (the suite replacing traditional CRM, including Sales Cloud, Service Cloud, etc.) is a cloud service sold by subscription. An ECC on-prem license would not cover them; instead, you purchase subscriptions for each user of C/4HANA cloud applications.
• SAP Ariba: SAP Ariba is a cloud procurement and supply chain collaboration platform. Its licensing is completely separate from SAP ECC/S/4HANA named users. Ariba modules (like Ariba Buying, Ariba Network, and Ariba Sourcing) are typically licensed by subscription, often based on metrics like the number of documents (e.g., purchase orders per year), spend volume, or suppliers involved. For example, Ariba Network charges fees based on the transaction volume between buyers and suppliers on the network. Users of Ariba (such as purchasers or suppliers) are covered under your Ariba subscription and do not consume SAP-named user licenses from your ERP. If you integrate Ariba with SAP ERP, treat it like any other third-party integration in terms of licensing the SAP side (the data exchange may require Digital Access if SAP documents are created). In short, each cloud product, such as Ariba, Concur, and SuccessFactors, has its licensing terms separate from the core ERP.
• Other Modules: Always verify whether a particular SAP product is included in your ERP license or is a standalone product. For example, SAP Solution Manager is technically free for SAP customers to manage the landscape (no extra license cost, as long as you have any SAP license). On the other hand, products like SAP BusinessObjects BI or SAP Analytics Cloud have separate licensing models (BOBJ uses named user or concurrent session licenses; Analytics Cloud is subscription-based by user). SAP’s price list and product documentation specify the licensing terms for each. If in doubt, consult SAP’s official licensing guide for that product or ask your SAP account manager to clarify.

License Reclassification and Optimization

Q: What is SAP license reclassification, and how can it help optimize costs?

A: License reclassification means changing the assigned license type of a user to better fit their actual usage.

This is a key part of SAP license optimization:

• Aligning License with Usage: Over time, a user’s role or usage of SAP may change. For example, an employee might initially need a Professional license but later only use limited functions after a job change. Reclassifying them to a Limited Professional (or appropriate lower tier) can reduce your license requirement for the high-tier licenses. Conversely, if users’ responsibilities grow and they start using more modules, you should upgrade their license category to stay compliant.
• Periodic Reviews: Companies should periodically review user activities to determine if the current license assignments remain appropriate. SAP’s audit tools (USMM) can list which transactions each user ran, which helps identify if someone with a “Limited” license executed transactions that are only allowed for Professional users. Third-party tools can also flag users with very limited activity (possibly candidates for a lower-priced license) or excessive activity for their current license.
• Process for Reclassification: The SAP license administrator can typically change the license type attribute in the user’s master record (SU01 in SAP GUI). Keeping an internal log or approval process for these changes is wise. If you downgrade a user’s license type, ensure they don’t have roles that conflict with the new classification (for instance, remove transaction codes from their role that are only applicable to Professionals). This sometimes involves collaborating with HR or department managers to confirm the tasks a user needs to perform.
• Timing and Audit Impact: Reclassification can be performed at any time; however, conducting a bulk cleanup before an audit is common. SAP audits are a snapshot in time; they count whatever license assignment is in place at the measurement time. It’s legitimate to reclassify users before an audit to match actual usage – that’s good license hygiene. Avoid last-minute changes that aren’t backed by actual usage changes (SAP auditors may question if you suddenly flip many users right before submission). A consistent, ongoing optimization process is better.
• License Optimization: This broader practice encompasses reclassification and other measures, such as cleansing inactive users, consolidating duplicate accounts, and potentially utilizing various license models. For example, suppose you find you have far more users than expected in high categories. In that case, you may want to evaluate whether SAP’s Enterprise Agreement or volume license options could be more cost-effective. Optimization can also mean negotiating license swaps with SAP (trading excess licenses for other products or types you need more).
• Example: Suppose you purchased 500 Professional User licenses, but your analysis reveals that 100 users never exceed basic read/display tasks. You could reclassify those 100 as Limited Users. In the next audit, you’d only consume 400 Professional licenses and maybe 100 Limited, potentially saving money on true-ups. Over-assigning everyone as a Professional “just in case” is expensive – optimization finds the right mix. Conversely, if someone is wrongly classified as a Limited User but regularly performs configuration changes, that poses a compliance risk – upgrade them to Professional to avoid audit trouble.

Common Licensing Pitfalls and Tips for Staying Compliant

Q: What are the common pitfalls in SAP licensing, and what are the tips for staying compliant?

A: SAP licensing mistakes can be costly. Here are frequent pitfalls and how to avoid them:

• Overlooking Indirect Usage: A major pitfall is ignoring indirect access. For example, allowing a third-party app or interface to use SAP data without proper licensing can lead to compliance issues. Some companies have faced hefty bills due to unlicensed indirect use discovered in audits. Tip: Inventory all systems that connect to SAP. Apply the appropriate licensing (named users or Digital Access documents) for those interactions. If using Digital Access, monitor the document counts to ensure you have sufficient licenses.
• Misclassifying Users: It’s easy to assign every user a professional license for convenience or, conversely, to assign a license that is too low in hopes of saving costs. Both are problematic. Over-licensing wastes the budget; under-licensing violates compliance. Tip: Develop clear guidelines for which roles in your company correspond to which SAP user license type. For instance, managers and core team members should be defined as professional roles, while clerical and support roles should be limited. Review actual system usage against these classifications at least yearly to adjust as needed.
• Dormant and Generic Accounts: SAP license counts can be inflated due to unused accounts (resulting from personnel who have left or changed roles) or generic accounts. Generic logins (shared user IDs) are against SAP policy – every user should have a unique ID. Tip: Regularly purge or lock inactive users. Implement an identity management process to ensure that when an employee leaves or no longer requires SAP, their account is promptly removed from license counts. Never use generic accounts for multiple people. If a shared function is needed (such as a common user for specific jobs), obtain approval from SAP and account for each actual user behind it.
• Not Tracking Engine Metrics: Some components (SAP engines/modules) have metric licenses (e.g., number of orders, revenue, employees). It’s a pitfall to deploy new functionality (like starting to use SAP Treasury or SAP SolMan ITSM) without realizing it requires a separate license metric. Tip: Before enabling a new module or functionality, check the contract or SAP price list to see if it has a separate license. Record these metrics (e.g., current employee count if you have an HCM package licensed per employee). This will prepare you for audits, enabling you to report accurate figures.
• Lack of Internal Audits: Many organizations wait for SAP to conduct audits rather than performing self-audits. Tip: Conduct internal license audits. Use the USMM/LAW tools or third-party solutions to simulate an audit. This practice will highlight issues early. It also keeps your team proficient in running audits, so the formal process goes smoothly.
• Ignoring Contractual Terms: Your contract may include special clauses (such as license use in non-production systems or guidelines for counting users for specific components). If these are overlooked, you might unintentionally breach terms. Tip: Maintain a summary of your SAP contract entitlements and use rights. Ensure your SAP admins and IT asset management team understand the key terms. For example, many contracts allow licensed users to use the software for development and testing at no extra cost, but don’t permit additional unlicensed users, even in test systems. Knowing such details helps avoid mistakes.
• Failure to Engage with SAP Proactively: Some treat SAP as an adversary in licensing, which can backfire if issues arise. Tip: Build a relationship with your SAP account representative or licensing specialist. If you’re unsure how to license a new scenario, ask beforehand. SAP can provide guidance or even specific license offerings for unique cases. When in doubt, obtain confirmation in writing (via an email or document from SAP) that confirms the licensing approach for a given situation – this can serve as a defense in an audit.
• Example Pitfall: A company utilized a third-party mobile app to extract customer information from SAP and generate service orders. They assumed only internal SAP users needed licenses, and none were assigned for the mobile app’s usage. In the next audit, SAP identified thousands of service orders created via this app (indirect use) with no corresponding licenses. To become compliant, the company had to purchase an unplanned batch of Digital Access documents. The lesson: even if users never log into SAP directly, if SAP works for them behind the scenes, you likely need to license it.

Tip Summary: Stay informed on SAP licensing updates, maintain clean user and usage records, and treat license management as an ongoing discipline. Regular reviews and adjustments will not only save money but also prevent compliance issues in the long run.