SAP Licensing for Non-Production Systems: Development, Test, QA, Training, and DR

SAP Licensing for Non-Production Systems

Introduction

SAP landscapes typically include multiple environments beyond the live production system. These non-production systems – development, testing/QA, training, and disaster recovery instances – are essential for implementing changes and safeguarding operations.

However, understanding SAP’s licensing rules for these environments is crucial. Misinterpreting the licensing terms can lead to compliance risks or unnecessary costs.

This article provides a comprehensive overview of SAP licensing for non-production systems. It is written for IT decision-makers and licensing professionals, but maintains plain language so general readers can follow along.

In non-production scenarios, we will cover how SAP’s standard licensing applies to major SAP software (including S/4HANA, ECC, SAP BW, and SAP BusinessObjects). We will also explain key distinctions between environment types (development vs. test vs. disaster recovery, etc.).

We’ll clarify whether additional licenses are required for these systems and under what circumstances. Real-world examples will illustrate common scenarios, like having multiple QA systems or activating a DR system during an outage, and how licensing works in each case.

We’ll also highlight common mistakes and audit risks related to non-production usage. Finally, a recommendations section will offer practical advice on staying compliant and optimizing your SAP licensing costs.

Non-Production SAP Environments

In SAP terminology, any system not performing live business operations is considered non-productive.

These environments serve various purposes in the software lifecycle without being part of day-to-day production transactions. The main types of non-production SAP systems include:

• Development (DEV) Systems: Functional and technical teams use to configure, customize, and develop enhancements or new programs. Developers write code (ABAP or otherwise) and customize settings here. Development systems often have multiple clients (sub-environments) for sandbox experimentation, configuration, and unit testing.
• Quality Assurance / Test (QA) Systems: Also called test or staging systems, QA systems are where QA analysts or key users test new developments and configurations. They provide a safe environment for integration testing, user acceptance testing (UAT), and volume or performance tests using realistic data (often a copy of production data). In many landscapes, “QA” is one system; larger projects might maintain multiple test systems (e.g., an integration test system and a separate UAT system).
• Training Systems: These systems train end-users and new team members on SAP processes. A training system might be a recent copy of production (with sanitized data) where users can practice transactions without impacting the real business. Training environments ensure users are comfortable with SAP before they get production access.
• Sandbox Systems: A sandbox is an isolated development system used for prototyping or experimenting without affecting the main development system. It’s purely for trying out new ideas or learning, and it is often wiped and refreshed frequently. Sandboxes are non-productive by nature.
• Disaster Recovery (DR) Systems: A DR system is a standby instance of SAP that is kept in sync with production (through backups or replication) and can be activated in case the production system becomes unavailable (due to disaster, major outage, etc.). Depending on the DR strategy, the DR instance may be “cold” (completely offline until needed), “warm” (on standby and periodically synchronized, but not serving users), or “hot” (running in parallel for instant failover). DR systems are not used for daily operations unless an emergency failover occurs.

Non-Productive vs. Productive Use: These environments are typically labeled as “non-productive” installations in SAP contracts. They are not to be used to carry out productive (live business) processing.

For example, entering real sales orders or executing financial postings that count as official company records should only happen in the production system.

Non-productive systems are for supporting activities (development, testing, training, backup), and any data or transactions are generally for temporary or internal use only.

Understanding these definitions is important because SAP’s license agreements often use terms like “Non-Productive Use” or “Non-Productive Installation.”

Now, let’s examine how SAP licenses cover (or exclude) these systems.

Standard Licensing Terms for Non-Production Environments

SAP’s General Policy:

The general rule for traditional on-premises SAP software is that SAP does not charge separately for non-production systems.

In other words, if you have a valid license for an SAP product in production, you are typically entitled to set up any development, test, QA, or training systems for that product at no additional license cost as long as they are used for non-production purposes.

SAP’s official use rights definition confirms this, stating that a customer may use the software on an unlimited number of non-productive installations (e.g., dev, test, DR), provided the usage in those systems doesn’t exceed the licensed metrics of the production system (such as number of users or sessions).

Non-production systems must not be used in a “productive manner,” meaning they shouldn’t be used to execute live business processes that generate revenue or run the company’s day-to-day operations.

In practical terms, this policy means you can install SAP S/4HANA or ECC on a development server and a QA server without buying extra software licenses for those installations.

The same applies to SAP Business Warehouse (BW) or SAP BusinessObjects BI Platform. If you own licenses for the product, you can deploy test or development servers for internal use. SAP’s contract language typically ties licenses to users or metric quantities, not to the number of system installations in non-productive scenarios.

Named User Licensing in Non-Prod:

The Named User license is the cornerstone of SAP on-prem licensing. Each individual who accesses SAP must have an appropriate user license type. This requirement applies across all environments – production or non-production.

You don’t need extra user licenses specifically for a dev or QA system, but the people using those systems must be covered by a named user license in your organization.

In other words, if John Doe is a tester logging into the QA system, John Doe should have an SAP user license (of a type that covers his activities) just as he would if logging into production.

There is no concept of “free user licenses” for test systems; all human access to SAP software is supposed to be licensed.

Users are typically licensed for the overall SAP environment, not per system. So, the same user license that lets John Doe use production also entitles him to use dev and QA. You do not need to purchase a user license again for John to use a second system.

Your SAP-named user license entitles one person to use the software, and that person can use multiple systems as needed. SAP’s measurement tools (SAP USMM and LAW) are designed to count each named individual once across the landscape (we’ll discuss this in the audit section).

License Metrics and Non-Prod Usage:

In addition to user licenses, some SAP products have package or engine licenses. For example, SAP might license a module based on concurrent sessions, transactions, or hardware size (like SAP HANA memory).

Generally, license metrics apply to productive use. Non-production installations are usually allowed to use the software within the same bounds. For instance, if you purchased an SAP engine that allows 100 concurrent sessions in production, you can use that engine in a dev system as long as you stay within 100 concurrent sessions in that dev system.

You can’t use non-prod systems to expand beyond what you purchased, but you aren’t charged for simply having those systems. Test and dev usage is not counted separately toward license entitlements for most metrics (users, concurrent sessions, records processed, etc.). They are effectively covered under the production license umbrella.

Example – SAP S/4HANA or ECC (ERP):

Traditional SAP ERP systems (ECC 6.0 or the newer S/4HANA) are primarily licensed by named users and sometimes by modules (e.g., a payroll engine license).

Under a standard SAP contract, if a company buys 50 Professional User licenses and 20 Limited Professional User licenses for SAP ECC, those licenses cover the users in production and also allow those same users to access ECC development and QA systems.

The company can install ECC on multiple servers (development, QA, sandbox) without buying extra ECC licenses as long as only authorized (licensed) users access those systems. SAP does not impose a fixed limit like “only one dev and 1 QA” – you could set up, for example, separate QA systems for different project streams.

The key restriction is that you cannot exceed the scope of what you licensed (e.g., you still only have 50 Professional Users in total across all systems).

Example – SAP Business Warehouse (BW):

SAP BW is often used alongside ERP. In many cases, the SAP BW license (as part of SAP NetWeaver) is included in the ERP license for internal use.

Regardless, using SAP BW for development or testing follows the same principle. If you’re licensed to use BW (via named users or a package), you can have a BW development system and a BW test system without extra license fees.

All the data modeling and test reports you create in non-prod are covered if your use is internal and non-productive. The user licenses (those who log into BW) must be in place, but there is no separate charge for having a BW sandbox vs. a BW production.

Example – SAP BusinessObjects (BI):

SAP BusinessObjects is licensed by named users or concurrent sessions (for the BI platform). SAP explicitly allows unlimited non-production BusinessObjects servers, so the number of users or sessions active on each non-production server cannot exceed what you’ve licensed.

For instance, if you purchased 100 concurrent session licenses for BusinessObjects, you could set up a test BI server and a development BI server. Still, you shouldn’t have more than 100 sessions active at a time (since you only own 100).

In effect, you’re not paying for two servers; you’re paying for 100 sessions, which you can use on any number of servers as long as you don’t exceed 100 on any one server​.

This lets companies have separate BI environments for development and testing (to try new reports or universes) without additional cost, as long as they don’t suddenly double the usage beyond licensed limits.

No Additional License Keys Required (just License Entitlement):

Technically, when installing SAP software on a new system (even a dev box), you must install a license key to activate it. SAP provides license keys for each system installation through its support portal.

However, obtaining a dev/test system license key is part of your maintenance agreement and does not incur extra fees – it’s an administrative step. You typically register the system (e.g., as a “development” installation) under your customer ID, and SAP issues a key for that system.

The key will be valid if you have licensed the corresponding product. For example, if you have an SAP ERP license, you can request a key for an ERP dev system. The presence of a license key in a test system doesn’t mean you bought something new; it’s just SAP’s way to enable the system.

It’s important to note the distinction between a license key (technical activation) and a license entitlement (the legal right to use the software). You must have the entitlement (through purchase or contract) for any system you install, but once you do, SAP will allow you to deploy non-prod instances freely.

Distinctions Between Different Non-Production Systems

SAP’s licensing treats all non-production environments similarly in many respects – they all fall under “non-productive use.”

However, there are a few nuanced distinctions and best practices for specific types:

• Development vs. Test: From a licensing perspective, there is no cost difference between a dev and test system. Both are non-productive. However, SAP does offer different user license types that align with these environments. For example, SAP has a “Developer” named user license (usually lower cost than a full Professional user) intended for programmers who only build and test programs and do not execute end-to-end business transactions. A Developer user license allows broad access to development tools and customization (so a developer can do their job in DEV and even perform tests in QA). Still, typically, that user isn’t supposed to perform productive tasks.
  In contrast, a “Professional User” license is needed for someone performing real business operations. So, while the dev and test systems don’t need separate licensing, the user licenses you assign can reflect their roles (developers, testers, etc.). This is a way to optimize cost: e.g., your full-time ABAP developers might only need Developer licenses if they are not end-users of the live system, whereas business power users involved in testing should have Professional licenses since they’ll use the production system too.
• Training Systems: A training system is essentially another non-prod instance, so there is no separate license fee for having it. One thing to consider: the trainees or trainers accessing the system should be licensed users. In internal corporate training, employees who are being trained will eventually use the production system in their jobs, so that they will be assigned an appropriate license (perhaps not immediately, but by go-live). From SAP’s perspective, if an employee uses SAP software, even just for training, they should have a named user license. In practice, during pre-go-live training, companies might use temporary training user IDs. These should still correspond one-to-one with real individuals and be accounted for in license counts. Important: If you run a training environment for external users (say, you are a vendor training your client or a partner training your subcontractors on your SAP system), those external users would also technically require an appropriate SAP license under your agreement (or you must arrange a special training use agreement). Generally, internal training is covered by normal licenses. The key is that people who have no license should not use training systems – don’t assume “it’s just training; anyone can log in.” Each login should map to an authorized user. That said, SAP isn’t policing this in real-time, but it could come up in an audit if there are accounts in the system that aren’t tied to licensed individuals.
• Quality Assurance/Test Systems: These are treated the same as development systems regarding licensing. Whether you have one consolidated QA system or multiple testing environments, SAP’s rules don’t put a specific limit on them. Some SAP customers maintain, for instance, a separate performance testing environment to conduct stress tests (so as not to disrupt the regular QA where functional testing happens). Others might have a pre-production or staging system that is a final dress rehearsal copy of the production. All of these are non-productive instances and permissible. Just ensure that any usage of additional systems is indeed for testing or staging purposes, not serving extra users in production capacity. Also, each environment will need its own installation number and license key from SAP (to function technically), but that’s included in support.
• Sandbox Systems: Sandboxes are essentially development systems used for exploration. Licensing-wise, there is no difference – a sandbox is non-productive. One consideration is that sometimes sandbox systems might be set up on separate hardware with lax security for convenience. Even though it’s a sandbox, it falls under the license agreement if it’s running SAP software. Ensure it’s only accessible to licensed individuals. Occasionally, companies use sandbox systems to try out new SAP products or modules they haven’t licensed yet – strictly speaking, you should have a license or a trial license for installing a new SAP module. Using your existing SAP installation to run an unlicensed component “just for sandbox testing” could be a compliance issue. The safe approach is to get an evaluation license from SAP if you want to experiment with something you haven’t purchased.
• Disaster Recovery Systems: DR systems are unique because they could become production if a disaster strikes. Under standard on-premise licensing, an SAP DR instance is considered non-productive if it does not actively serve users. You are generally allowed to maintain a complete copy of your production system for DR without paying for another set of licenses, with the expectation that it’s idle or only used for emergency failover. If a disaster happens and you switch to the DR system, you’re not suddenly required to purchase new licenses – the same licenses “cover” the DR system now acting as production. However, there are a few caveats:
  • The DR system should not be used concurrently with production for normal operations. You shouldn’t have both production and the DR environment actively serving users simultaneously permanently; that would effectively be running two production environments, which your license probably doesn’t allow unless you have licensed two production instances. In a real disaster scenario, typically, the primary goes down, and DR takes over (one or the other is active, not both).
  • If you have a hot standby (very minimal RTO) running alongside production in real-time replication, ensure it’s truly in standby mode (read-only or waiting) and not being used for, say, load balancing or read queries. Using a “DR” system for reporting or extra capacity while production runs could be viewed as using an unlicensed additional production system.
  • DR Testing: Companies often perform disaster recovery tests (switchover drills) to ensure the DR system works. During these tests, you activate the DR system and perhaps let some users log in to simulate operations. SAP generally permits this as part of non-productive use (it’s a test of your recovery process, not normal business operation). It’s wise to keep such tests time-bound and documented. It’s also a good practice (though not a formal requirement) to inform SAP in your annual audit notes if you had a period where DR was activated for testing or real incidents, to clarify any records of the two systems running.
  • Under some SAP contracts, particularly older ones, language clarified that one production license could cover one production and one fail-over (DR) installation. Modern contracts fold DR under non-productive installations. The bottom line is that you do not need to purchase a duplicate SAP license for your DR server as long as it’s truly for backup/emergency use.

One scenario to be cautious of: If your organization wants to permanently run two productive systems (for example, two active data centers for high availability or active-active load distribution), that is not a “non-prod” scenario – that’s having two production instances, which would typically require licensing both (or licensing a clustered configuration).

One license covers high availability within one production (like an application server cluster against one database). Still, a single license contract without special terms would not cover two separate production systems doing different tasks. We mention this to distinguish it from DR, which is normally one production at a time.

In summary, SAP’s standard license terms treat development, test, QA, training, sandbox, and DR servers as non-chargeable as long as they are used internally and not for live business operations.

The main control is that your usage in those systems (users, etc.) stays within the limits of what you’ve licensed for production.

Are Additional Licenses Required for Non-Production Systems?

Generally, No Additional License Fees:

In most cases, you do not need to buy additional SAP software licenses for non-production systems.

Once you have licensed an SAP product (e.g., S/4HANA enterprise, SAP BW, or SAP BusinessObjects) for your organization, that license allows you to deploy the software in multiple environments for development, testing, etc., without extra cost. SAP’s documentation explicitly states that non-productive use is permitted on unlimited systems as part of the license​.

Thus, installing an SAP application on a development server doesn’t trigger a new license purchase, and you won’t see a line item on your SAP invoice for a “QA system license.”

However, there are important conditions and exceptions to keep in mind:

• Users Must Be Licensed: While you don’t buy a license for the system, you do need licenses for the people or external systems accessing it. If you set up a new test system and give 10 people access, those 10 people must be covered by your existing named user licenses. If they were already licensed (e.g., they are your existing employees using SAP), you’re fine. Suppose new people (like external consultants or temporary testers) don’t have licenses. In that case, you may need to purchase additional named user licenses for them (or assign spare ones you have). Sometimes, companies bring in many contractors to help with testing during projects. Every contractor logging into SAP will also need a named user license unless they are using a customer-shared user, which is not allowed by SAP’s “one named user per human” rule. The proper approach is to license those contractors (perhaps with a Developer or Limited license if appropriate) or have the consulting firm use their SAP login credentials under your license (which still counts towards your named users).
• Matching License Type to Use: Non-production use does not exempt anyone from licensing. However, if someone only ever uses non-prod systems, you might consider assigning them a less expensive license category. For example, a pure developer or test user who will never execute transactions in production could be given a “Developer” license. That is valid and keeps costs down. But be careful: if that person later needs to use production (even for an emergency fix or data check), their license type might be insufficient. Ensure license types align with actual usage to avoid compliance issues if roles change.
• SAP Packages/Engines: If an SAP product or add-on is sold as a separate package (like SAP Treasury module, SAP APO, etc.) when you license it, it covers your use of that module in any system. You wouldn’t need to license the module separately for dev/test. But you do need to have licensed it at least once. In other words, you cannot legally install an SAP add-on in a test system you haven’t licensed to “try it out” beyond a trial period. Aside from official trial arrangements, using an unlicensed component, even in dev, is not permitted. If you want to evaluate a new SAP solution in a sandbox, talk to SAP about a trial license or demo license (SAP often provides temporary evaluation keys or cloud trial systems for this purpose).
• Third-Party Software in SAP Landscapes: Remember that SAP’s generous non-production policy applies to SAP’s software licenses. Suppose your SAP system uses third-party software (for example, an Oracle database or Microsoft SQL database underlying SAP ECC or a third-party GUI or tool). In that case, those vendors might require separate licenses for non-production instances. For instance, Oracle requires full licensing for any installed database, dev, or prod. This is outside SAP’s control. So, while SAP won’t charge you for an extra ECC instance, you might incur costs from the database side or other components. (We won’t dive into those details here, but it’s a consideration when planning total cost.)
• Cloud (Subscription) Models: The discussion is about traditional on-premise licenses (perpetual licenses with maintenance). The concept is a bit different in SAP’s newer cloud subscription models (such as RISE with SAP or S/4HANA Cloud). In a subscription, you typically pay for a service that includes a certain number of environments. For example, a RISE with SAP S/4HANA Private Cloud subscription might include one production instance and two non-production instances (dev and test) of the system as part of the package. If you want additional systems beyond the subscription, that can incur extra fees because you’re asking SAP to provide more cloud resources. Disaster Recovery in a cloud context is often an add-on service. SAP’s RISE contracts explicitly state that a DR environment is optional and comes at an additional cost in the subscription model. Likewise, extra QA systems or higher availability tiers might cost extra in cloud subscriptions since they represent additional infrastructure or services beyond the base offer. For on-premise licenses, you can add systems; for SAP’s cloud SaaS/PaaS licenses, check the contract to see how many systems are included. In any case, the user licensing concept still applies (you wouldn’t get extra user rights just because you have more systems). Always clarify with SAP how non-prod is handled in subscription agreements to avoid surprises.
• When Might You Need Additional Licenses? Under normal use, you don’t buy “dev licenses” for the system. The scenarios where licensing costs could increase are:
  • Suppose you exceed your licensed metrics while using non-prod systems. Example: you have 50 licensed users, but you allow a 60th person to access a test system – that person technically needs a license, meaning you’re under-licensed by 10 users.
  • If you inadvertently use a non-prod system for something that counts as production. Example: using a QA system as an active backup for reporting. In an audit, SAP might say you’re effectively using two systems productively and may require you to license the usage accordingly (though this is a gray area, it’s best to avoid pushing the boundary).
  • If you want to set up a separate training environment for a long-term purpose, like a training center that is not just for internal employees but maybe an external training service, that might need a special arrangement (most customers don’t do this unless they are an SAP training partner).
  • As mentioned, in the cloud, if you request additional landscape components beyond the standard offering (e.g., a second QA system in a public cloud edition), you may pay for them because they are outside the default quota.

In summary, additional licenses for non-prod systems are generally not required except to ensure all users are licensed and the contract covers any unique scenario outside typical internal use. For most SAP customers, no extra license line items are needed for dev, QA, or DR systems.

Real-World Scenarios and Examples

To illustrate how these principles play out, let’s look at a few typical scenarios:

• Scenario 1: Multiple QA Systems – Company A runs SAP S/4HANA and has two parallel projects, each requiring an integration testing cycle. They set up QA1 for Project Alpha and QA2 for Project Beta, as well as DEV and Production systems. SAP’s licensing permits this easily – QA1 and QA2 are non-productive installations. There is no extra license cost for having a second QA system. Company A requests license keys from SAP’s support portal for both QA systems (often using separate system IDs). Both systems are used by the same pool of 50 users who are already licensed. The key thing Company A does is ensure that when they run SAP’s license measurement, they mark both QA1 and QA2 as test systems so that users in them are not double-counted. All 50 users also have production access, so they were licensed under the 50 S/4HANA user licenses the company purchased. During an audit, SAP sees two test systems, but no issue arises because the user count is within the licensed number and properly consolidated. Result: Company A achieves its testing needs without extra license fees – they just needed hardware and basic effort to set up the extra system.
• Scenario 2: Training Clients – Company B is rolling out SAP ECC to new subsidiaries and needs to train hundreds of employees. They create a dedicated training client within the QA system (or a separate training system) loaded with mock data. Over 3 months, different batches of employees log into this training client to practice transactions. All these employees will eventually use SAP for real, so Company B has purchased the necessary named user licenses for them (perhaps many are “Employee” or “ESS user” license types if they only do self-service). Access to the training system is considered part of their license usage. Company B does not pay anything extra for using SAP in training mode. They refresh the training client periodically with production data (scrambled for privacy) – this does not affect licensing but is a data management task. The only watch-out is to avoid using generic shared accounts for training; each user should use their login so it’s clear that they’re licensed. Result: The training sessions run smoothly under the existing licenses. When those users go live, they continue to use the same user IDs in production.
• Scenario 3: Disaster Strikes, DR Activation – Company C runs SAP BusinessObjects BI for critical reports. They maintain a cold standby BI server for Disaster Recovery. Unfortunately, the data center hosting the production BI server experiences a flood, knocking it out completely. Company C activates the DR server in an alternate location and restores the latest backup. Users are redirected to this BI server to continue reporting. The DR system serves as the production BI system for two weeks while the primary data center is rebuilt. Company C is covered from a licensing perspective: they had 200 concurrent session licenses for BI, and they continue to use up to 200 sessions on the DR system. They did not need to purchase anything additional when activating DR – their existing licenses were carried over to the system, which is now in operation. Once the primary system is rebuilt, they switch back. In their records (and perhaps in the next audit), they note which system is production vs. non-prod for that period, ensuring no misunderstanding. Result: Company C uses its DR system without licensing hiccups or extra fees. SAP’s concern is that they don’t permanently run two systems with 200 sessions each simultaneously (which they did not – one was offline while the other ran).
• Scenario 4: Improper Use of Non-Prod – Company D has a performance issue in production ECC during the month-end. To alleviate it, they decided to run some heavy financial reports on their QA system (which has a copy of last week’s production data) so that finance users can get their info without slowing down production. This starts happening regularly every month – finance logs into QA to run certain reports on near-real data. Technically, QA is used concurrently with production for a business function (reporting). This blurs the “non-productive use” line since those reports are for real business decisions. If SAP were to assess this, they might say Company D effectively uses two production environments (one for operational transactions and one for reporting analytics). There is no automatic detection, but it’s a gray area. In a strict sense, this could violate the agreement that QA is not for productive use. In extreme cases, SAP could require licensing for that second system or ask for additional license fees for that usage. The better solution for Company D would be to license a proper reporting solution (like a BW or a secondary instance under a license) or use the SAP early watch reporting functionalities rather than repurposing QA for production tasks. This example shows that while SAP is flexible about non-prod, a customer should not abuse a QA or dev system as a full-fledged production workaround. Lesson: Keep non-prod usage truly non-prod. Don’t make a habit of using non-prod systems to offload normal business processing beyond short-term exceptions.
• Scenario 5: External Testers – Company E is working with a third-party software vendor to build an integration to SAP. The vendor’s consultants must test their product by logging into Company E’s SAP QA system. Company E has two options: (1) Create SAP user IDs for these consultants in QA and assign them temporary named user licenses from their pool (if available), or purchase a couple of extra named users for this purpose; or (2) see if the vendor has an SAP Test and Demo license that could cover their access (unlikely – normally the customer licenses all access). The simplest path: treat the consultants like any other user under your license count. Perhaps reallocating a spare license or buying a few “Project User” licenses (SAP sometimes offers short-term project user licenses). They should not share someone else’s login, violating SAP’s named user policy. Companies often use their existing licenses since these external folks are temporary. After the project, they remove those accounts. Result: Company E remains compliant by ensuring that Even
  External people who log into their SAP are within their licensed user count.

Each scenario shows that if you stay within SAP’s licensing guardrails, non-production systems can be used freely to support your projects and operations. Issues only arise if you start using those systems in ways beyond internal testing/training or if you lose track of who is accessing them.

Common Mistakes and Audit Risks

Even though SAP’s rules for non-production usage are straightforward, organizations can still run into compliance pitfalls. Here are some common mistakes and risks to watch out for:

• Assuming Non-Prod Usage Doesn’t Count at All: Some might think, “It’s just development, it doesn’t count toward licenses.” This is wrong – every user needs a valid license, regardless of which system they use. A classic mistake is having a bunch of test user accounts that represent real people who weren’t accounted for in license counts. For example, creating separate logins for a user in dev and QA with different names – SAP’s audit tools might count them as separate people if not properly consolidated. The fix is to use consistent user IDs or map them in the License Administration Workbench (LAW) tool so that each person is counted only once. Remember: Non-production systems must be included in the annual license measurement (LAW) so SAP can see they exist, even if their users are later grouped. Don’t hide a system; mark it correctly as a test.
• Not Grouping/Flagging Systems Correctly in Audits: SAP provides tools to classify systems as production or test for license auditing. If you fail to mark a QA system as a “test” in LAW, the users might be counted as if it were an additional production system. This could double-count your users and make it seem like you need more licenses than you do. A common oversight is not maintaining the LAW configuration – ensure that your Basis or License Administrator designates which system is production and which is non-prod in the LAW tool grouping. Typically, only production systems contribute to the named user count, while non-prod systems are grouped for deduplication. If you skip this step, you could be overcounted in an audit report.
• License Classification Errors Across Systems: This is related to user types. If the same person is given different license-type assignments in different systems, it can confuse them. For example, in the DEV system, you classify John as a Developer user, but in Production, he’s classified as a Professional. In an audit, SAP usually takes the highest classification (Professional in this case) and applies it to John overall. That could be fine (just a consistency issue), but if it were the opposite (Professional in test, Limited in production), you might have under-licensed John’s usage. The best practice is to keep a centralized record of user license assignments and apply it uniformly across systems so that when consolidated, it’s accurate.
• Keeping Unnecessary Users Active in Non-Prod: Over time, test systems accumulate many user IDs – including old project accounts, consultants who left, generic “TEST1/TEST2” accounts, etc. If these remain active (not locked or deleted), the audit might pick them up. While properly flagged non-prod systems shouldn’t count those as separate licenses if they don’t map to real people, it still creates extra work to justify or exclude them. Additionally, any account that isn’t tied to a real licensed user is a red flag. It’s a common audit finding that companies have more user IDs than licenses because they never cleaned up non-prod. Solution: Periodically purge or lock unused accounts in dev/QA and ensure all accounts correspond to actual individuals who have a license. Dummy accounts for testing are generally not allowed unless you assign a real user to them (which defeats the point). If you need to perform automated testing (like scripts simulating users), you might do that with one or two dedicated test user IDs – make sure you count those IDs as needing a license (perhaps assign them to a test team member).
• Using Production Data in Non-Prod Without Safeguards: Loading production data into test/training is fine from a licensing standpoint. The risk here is more about inadvertently enabling indirect access or external use. For example, if a non-production system with production data is connected to other systems, someone might start using it thinking it’s production. Or, if you clone production for testing a third-party interface, that interface might continue sending data to the test system – this could be considered “indirect use” that should be licensed (though if purely test data, likely not an issue). Just be mindful of interfaces: ensure non-prod systems aren’t unintentionally feeding other systems that assume it’s live usage.
• DR System Misuse: One mistake is running your DR system in an active-active scenario without telling SAP. If you are effectively load-balancing between two installations serving users, you are exceeding your license (one license = one production environment at a time, generally). Another mistake is forgetting to revert the DR system’s status after a test—e.g., leaving it running and accessible when not needed. Always double-check that the secondary system is back to standby mode after a DR drill.
• Not Reading the Contract Details: While most SAP contracts align with the standard approach, some customers have unique clauses. Perhaps your contract explicitly says you’re allowed one development and one test system (this would be unusual nowadays, but it’s possible older or special contracts had specific terms). If so, be aware of those limits. Or maybe your contract names something like “Not more than X users in non-prod beyond prod count,” – which is the same rule we discussed. The point is, don’t assume – verify. The SAP Software Use Rights document and your individual license agreement paperwork will outline these terms. It’s a mistake to rely only on tribal knowledge; always confirm against the official sources.
• Overlooking Cloud Subscriptions Limits: If you transitioned to a cloud subscription (like S/4HANA Cloud), don’t assume the on-prem rules all carry over. For instance, thinking you can spin up a second QA in a SaaS environment without talking to SAP could be a mistake – you might find an unexpected charge. In one real case, a customer under SAP’s private cloud edition wanted an additional test system for a new project. Later, they discovered it increased their subscription cost because only two systems were included by default. Avoid surprises by planning the landscape you need with SAP in advance.
• Ignoring Indirect Access in Non-Prod: Indirect access (when external systems interact with SAP data) is generally a production issue (e.g., a third-party app creating a sales order in production SAP requires a license). In non-prod, indirect access can occur, too (e.g., a test middleware posting to QA). While SAP focuses on audits on production usage of indirect access, you should still monitor any non-prod integrations. If, for example, you have a non-prod scenario where many test documents are created via an external system, ensure that when that moves to production, you have the licenses (either named users or document licenses) in place. Indirect use licensing is complicated enough; just be consistent that any interface user IDs or systems in non-prod correspond to something you’ll license in prod.

In summary, the biggest risk area in non-production licensing is user management. Most compliance issues arise from user accounts – either too many, not being mapped properly, or the wrong license type.

The key to avoiding trouble is good governance: treat non-prod systems with the same diligence as production regarding user access and license assignment (even though they don’t directly generate revenue, they can generate compliance issues if not managed).

Recommendations for Compliance and Cost Optimization

Managing SAP licenses across multiple environments can be challenging, but a few best practices can help you stay compliant and save costs.

Here are some practical recommendations:

• Document Your SAP Landscape: Keep an up-to-date record of all SAP systems you have, including their designated role (Production, Dev, QA, Training, Sandbox, DR, etc.). This should tie into your SAP customer portal entries as well. By knowing your landscape, you can ensure each system is accounted for in licensing discussions and audits. It also helps new project teams understand where to deploy changes and ensures no “rogue” SAP instances appear without your knowledge.
• Review Your SAP License Contract for Non-Prod Terms: While the general rule is clear, make sure to read the sections defining “Non-Productive Use” or “Non-Productive Installation” in your SAP agreement. These will spell out what you are allowed. For example, SAP’s definition clarifies that development, test, and DR installations are allowed as long as user counts don’t exceed licensed numbers​. Knowing this language can be useful if you ever need to explain your rights to an auditor or internal stakeholder questioning if you can add a system.
• Assign the Right Named User Types: Optimize costs by aligning user licenses with actual usage. If you have team members who strictly develop or test and never use production for business, consider giving them “Developer” licenses (which tend to be cheaper than “Professional” licenses). Conversely, do not under-classify a user in production because they mostly test in QA. If they perform any significant tasks in production, they should have the appropriate license level. Regularly audit your user list and license assignments. This can prevent both compliance issues and overpaying. If someone was given a Professional license but their job changed to a read-only role, you might downgrade them to save license value for someone else.
• Use LAW (License Administration Workbench) Properly: Ensure that your Basis team runs the SAP measurement tools on all systems as required (typically annually, sometimes more). Before submitting measurement results, use LAW to consolidate users. Verify the grouping: all non-prod systems should be grouped with their corresponding production system to count each user once. Mark which system is the “primary” production in each group. SAP’s audit guidelines often state that only production usage counts towards the license, so you want the LAW report to reflect that. Invest time cleaning up the LAW results (deduplicate and map users with different usernames belonging to the same person). This preparation can save you from false compliance gaps.
• Clean Up Users and Clients Regularly: Establish a routine (perhaps quarterly or biannually) to review user accounts in all systems:
  • Remove or lock accounts that are no longer needed (especially in project systems once the project is done).Remove generic accounts used in testing (if they were created against policy).Update license classifications across systems for consistency.
  Also, if you copy clients or refresh systems from production, do a post-copy cleanup: you might inadvertently copy all production user accounts into a QA system. After a system refresh, lock or delete users that shouldn’t be active in that environment (particularly if it’s a full prod copy). Only open the accounts needed for testing/training in that environment.
• Train and Communicate Internally: Make sure your SAP project teams and basis administrators understand the licensing basics. Often, technical folks might spin up a new sandbox or clone a system to a new server for a project without informing the license manager. Have a governance step that reviews any new SAP instance deployment for compliance (even if it’s likely fine, you at least record it). Likewise, educate testers and trainers to use their logins and not share credentials “because it’s just QA.” Instill the concept that license compliance matters in non-prod, even if SAP isn’t actively monitoring those systems daily.
• Leverage SAP’s Tools for Non-Prod (Solution Manager, etc.): SAP Solution Manager is included with your SAP maintenance and can manage and monitor your landscape. While not directly a licensing tool, Solution Manager can help you track users and systems. It also comes with a basic license for certain scenarios. Additionally, SAP provides test IDs or clients in some products (for example, SAP Learning Hub for training or SAP CAL for trial systems) – these are separate from your license but can be used for experimentation if you don’t want to affect your licensed landscape.
• Plan for Disaster Recovery in Advance: If you have a DR setup, include a section in your internal license documentation about how DR is handled. For example, note that “DR system (System ID DRP) is a non-productive installation only to be used during outages; no license required unless activated.” This helps in audits – you can proactively explain, “This system is our DR, normally offline.” If you ever use it for a real disaster, consider notifying your SAP account manager as a courtesy (not necessarily required, but it shows transparency). They almost certainly won’t charge you for using it due to an emergency, but recording why that system might have user activity logs during that period is good.
• Be Cautious with External Access in Non-Prod: As seen in the examples, if third parties need access to your non-prod, ensure there’s a licensing arrangement. Usually, the simplest is to include them under your named users temporarily. Another approach is if the third party is an SAP partner, sometimes they have their license entitlement to access client systems (like an SAP consultant will have an S-user license that might be used for support). But never assume an external person can use your system license-free. Work it out beforehand – a few extra temporary licenses cost far less than potential audit issues later.
• Monitor Usage and System Purposes: Sometimes landscapes grow organically. After a few years, you might have more systems than you need (each costing infrastructure and maintenance effort). While not directly a license cost, simplifying your landscape can reduce complexity in compliance. For instance, if a training system is rarely used, you might decommission it and use a client in QA for training. Fewer systems mean fewer places to manage users.
  On the other hand, don’t hesitate to create additional non-prod systems if needed under the false fear of licensing. If your project truly needs a separate environment (like a sandbox to test an upgrade), you can create it without license cost. Just remember to tear it down when done and remove users.
• Negotiating with SAP: When negotiating your SAP license contract or cloud subscription, explicitly discuss non-production needs. Ensure the contract language meets your expectations (it usually does by default, but if you have unusual needs, clarify them). For the cloud, negotiate how many test systems are included. For on-prem, you might ask for written confirmation that multiple non-prod systems are allowed (this is standard, but noting it can be comforting to stakeholders). If you ever encounter an SAP salesperson suggesting you need to pay for a dev system, that typically is a misunderstanding – refer back to the SAP Software Use Rights document and get clarity.
• Stay Informed on Policy Changes: SAP’s policies can evolve. They release updated versions of their Software Use Rights periodically. For example, if SAP were to change how they treat DR licensing or introduce a new license type for, say, “Test-only users,” you’d want to know. As of this writing, the established approach has been consistent for years. However, keep an eye on release notes or ask at SAP user group meetings if any licensing terms for non-prod have changed, especially as cloud offerings become dominant.

Following these recommendations ensures that your use of development, QA, training, and DR systems remains compliant and cost-efficient.

In summary, treat non-production systems with the same discipline as production regarding user management, and leverage SAP’s flexibility to create as many support environments as you need. This will minimize compliance risk and maximize the value you get from your SAP licenses.

Conclusion

Non-production systems are indispensable in any SAP deployment – they enable continuous improvement, testing, and protection of your production environment.

SAP’s licensing model generally accommodates these needs: you won’t pay additional license fees to have a development or test system, and you’re allowed a reasonable number of such installations to support your business.

The main licensing consideration is to ensure your existing licenses cover all individuals and usage in those environments and to avoid inadvertently treating a non-prod system like a second production.

All major SAP software – from ERP (ECC or S/4HANA) to analytics (SAP BW, SAP BusinessObjects) – follow the same fundamental rules for non-prod usage, albeit with product-specific metrics. By understanding SAP’s definitions and maintaining good license governance, you can confidently operate multiple development and test systems, a training client, and a standby DR instance without breaching your agreements or incurring extra costs.

In practice, companies run into trouble not because SAP charged them for a QA system but because of internal account mismanagement or misunderstandings of the terms.

Thus, compliance is largely in your hands: keep your user licensing in order, mark your systems correctly in audits, and don’t try to game the system by using unlicensed functionality in a “hidden” way.

If you do this, an SAP license audit for non-prod usage should go smoothly – your non-production systems will be recognized as legitimate and properly licensed under your main agreement.

Ultimately, SAP’s flexibility for non-production environments encourages customers to fully test and develop their solutions (and be prepared for disasters) without penalty. Use those environments to their fullest—they are your sandbox to ensure the production system runs optimally and securely.

Just accompany that technical freedom with sensible license compliance practices. This balance will allow IT decision-makers to optimize their SAP landscape (adding or removing non-prod systems as needed) while keeping financial officers and SAP auditors happy.

With careful planning and adherence to SAP’s licensing guidelines, you can maintain a robust multi-system SAP landscape that supports development, testing, training, and disaster recovery – all without unwelcome licensing surprises.