SAP Developer and Technical User Licenses
In SAP environments, users who build, customize, or support the technical side of the system are typically assigned a Developer User license (also known as an SAP Application Developer license).
This license type is geared towards programmers, system configurators, and technical administrators who need access to SAP’s development tools and backend configuration transactions rather than day-to-day business operations.
A Developer User license allows the individual to use the ABAP Workbench (SAP’s development environment) and other development tools to create custom programs, reports, enhancements, or interfaces.
The individual can also write and debug ABAP code, create data dictionary objects, and set up workflows, among other tasks.
It also usually allows access to configuration transactions (SPRO and others) for setting up the system, as technical staff often handle system setup in their domain (for example, configuring a new company code or tweaking a workflow requires admin access, which a developer license typically permits).
The Developer license covers technical activities needed to maintain or extend the SAP software.
However, the Developer User license does not typically allow unlimited use of operational business transactions.
A person with only a developer license is not meant to execute regular business processes in production (except as needed for testing).
For instance, a developer can create and run a custom report for testing.
Still, they wouldn’t be posting invoices, creating sales orders for actual business, or performing month-end close tasks as part of their day-to-day work; those would require a Professional user license.
In many SAP contracts, the Developer license includes the rights of an ESS/Employee user.
This means developers are allowed the basic self-service functions for themselves (so they can record their own time, etc.).
Still, the license does not inherently include the full operational authority of a Professional User.
In practical terms, if a developer also takes on a functional role, that functional usage must be licensed separately.
It’s also important to note that SAP Basis administrators (those who manage the SAP system technically, handling user administration, transports, system monitoring, etc.) often use Developer licenses if they are not performing business transactions.
Basic tasks, such as adjusting system parameters or managing background jobs, are considered technical activities.
Many companies classify Basis admins under Developer licenses, as they utilize admin tools and authorizations similar to those of developers.
Some Basis actions (like creating users, which is a configuration form) are already within the scope of a Developer license (system management).
The SAP Professional license definition explicitly covers system administration roles, implying that a Professional license could also cover a Basis administrator.
The choice sometimes comes down to company policy – some treat all IT staff as Professional users to be safe, while others issue Developer licenses to purely technical staff to save costs.
Suppose a Basis admin also, for example, enters a financial transaction occasionally (maybe for testing or support). In that case, that’s fine for testing, but if they were doing it as part of operations, they’d need an appropriate license for that as well.
Cost and value: Developer licenses tend to be expensive, often on par with (or just slightly less than) Professional user licenses, since they enable high-level system changes.
They are typically fewer in number – only your IT developers and maybe a few power users would need them.
But they exist to ensure that you are compliant when giving people the keys to change the system. SAP wants anyone who can modify the software or create new functionality to have a proper license (hence the Developer license category).
Read about SAP Named User Licensing.
Technical/System Users and Licensing Requirements
Beyond human users, SAP landscapes often contain various technical accounts, including background job users, interface users, and test users.
SAP’s named-user licensing applies to all accounts that access the software, even if no person directly logs in.
This is a critical point: standard SAP licensing does not grant free passes for system or batch accounts.
Every distinct login credential that accesses SAP should be accounted for under a named user license.
Common types of technical users and how to handle them:
- Background/Batch User: An account used to run scheduled jobs (for example, nightly batch processing, data imports, or automated tasks in SAP). These users often have the SAP user type “System” or “Communication” (meaning they can execute tasks but not interact via GUI). Even though no human sits at a screen with these accounts, SAP still considers them named users. Typically, companies assign such accounts a Developer or similar technical license because the account performs technical tasks rather than business transactions. For instance, an automated job posting IDOCs (intermediate documents) into SAP might use a technical user; since it’s essentially performing a data load, one might classify it with a lower license, such as a “Technical User” (often just the Developer category).
- Interface or Integration User: External systems (like middleware, web portals, or other applications) use accounts to communicate with SAP via RFC or API. For example, you might have a user “EDI_USER” that an EDI system uses to create sales orders in SAP. In SAP’s eyes, each such interface user is a named user consuming a license. Customers often create one technical user per interface and reuse it for all transactions from that interface. You need to assign a license type to those users. If the interface is creating documents (e.g., sales orders), theoretically, that constitutes a business transaction – one could argue that a Professional license is needed. In practice, many assign these to the Developer/Technical category, as the account itself isn’t a person performing analytical work; it’s just pushing data. Some customers mitigate the cost by using SAP’s Indirect/Digital Access license model instead (paying by document counts). Still, if sticking to named users, each interface account should have an appropriate license. Importantly, SAP auditors will look for high-activity technical users. If an account without a proper license classification creates thousands of orders, it may raise a compliance flag.
- Test Users and Training Accounts: In non-production systems, companies often create generic test accounts (such as “TESTUSER”). These might not be counted in production license audits in a separate environment (SAP’s measurement typically focuses on active users in production clients, although all environments are subject to license rules). It’s wise to either delete such accounts or classify them as “Test” in some way, if possible. It’s best to use real named accounts for production testing by power users. Note that if a test account exists in production (even if it is only used for occasional troubleshooting), it technically requires a license. There isn’t a specific “test user license” in SAP ERP (unlike some software that has cheaper licenses for test environments). Thus, minimize the number of generic or duplicate accounts to avoid license counting issues.
Since SAP does not have a separate license type for “system” users, your technical accounts must be tagged as one of the existing license categories (e.g., Professional, Limited, Developer).
Read SAP Licenses For Engineers, Administrators, and Other Specialized Roles.
Developer Users and Their License Requirements
SAP’s Developer User license is intended for individuals who customize and support the SAP system rather than perform daily business transactions.
This license type grants access to development and administration tools, such as the ABAP Workbench for coding, SAP configuration (IMG) transactions, debugging, and technical monitoring tools.
A user with a Developer license can create or modify custom programs, build interfaces, set up workflows, and generally maintain the technical aspects of the SAP environment.
It encompasses tasks such as writing ABAP code, implementing changes, and configuring the system.
What a Developer license does not automatically cover is the broad execution of business processes.
In SAP’s licensing terms, a Developer user includes the rights of an SAP Employee User, which grants basic self-service rights (meaning the developer can record their own time or run personal reports).
However, it typically does not include the full operational authority of a Professional User. For instance, a developer can create a test sales order to verify their code, but that license alone isn’t meant to authorize them to enter live sales orders as part of a sales department role.
If a person with a Developer license also regularly performs operational tasks (say, they occasionally act as a buyer or accountant in the system), then additional licensing would be required for those activities. Companies often give such a user a Professional license to cover all bases.
In practice, many technical staff are given both development and broad functional access, so organizations either allocate two license types or choose the higher tier to be safe.
The key is to ensure that anyone with developer privileges is at least licensed as a Developer user; SAP often audits this via development tool usage.
From a cost perspective, Developer licenses are among the highest-priced user categories (often on par with Professional licenses. This reflects the high level of access and potential impact these users have.
Only those needing to build or configure the system (e.g., ABAP developers, BASIS administrators, technical consultants) should be assigned a Developer license.
Giving a Developer license to someone who never touches the development tools is a waste – they could be a lower type.
Conversely, it’s non-compliant to have someone actively coding or configuring in SAP while only holding an “employee” or limited license.
Technical, System, and Background Accounts
SAP systems also involve non-human accounts, such as background job users, integration accounts for interfaces, and other technical login IDs.
Importantly, SAP’s named user licensing model also applies to these accounts.
No separate “system user” license category automatically covers them.
Every active user ID should be assigned a license type, even if it’s not a person. It is often surprising that a generic account used for data uploads or system integration is counted as a named user.
Still, SAP considers that any account-consuming system functionality needs a license.
Typical technical accounts and how to license them:
- Batch/Background Job Users: These are accounts used to run scheduled jobs (for example, nightly data imports or report jobs). They usually have no interactive login (set as “system” or “communication” user type in SAP), but since they execute transactions in the background, they are still counted as usage. Companies often assign such accounts a Developer or Technical user license designation, reasoning that the account performs technical tasks (not business decisions). For instance, an account that automatically posts IDoc transactions might be classified under a technical user license. The chosen license should correspond to the nature of the job being done. If it’s purely about moving data or running internal processes, a Developer license may suffice. If it involves creating business documents (such as invoices) in volume, SAP might argue that a Professional license or handling via an engine or indirect metric is required. The safest approach is to have each batch user at least classified under an existing license type (avoiding the “unassigned = Professional” default pitfall).
- Interface Integration Users: Many external systems connect to SAP (such as middleware, web portals, and mobile apps) using a dedicated SAP user account for authentication. For example, a B2B portal might use an account INTF_CUSTOMER to create orders in SAP via API. Each such interface user needs a license assignment. If the interface interacts with core data (such as creating sales orders or shipments), you must license it similarly to someone performing those actions. A common strategy is to assign these accounts a lower-level license (such as a Limited Professional or Developer) to limit costs and ensure their usage stays within the scope of that license. Another strategy is SAP’s digital access model, where you license the documents created indirectly rather than for each user. If you have adopted this model, you might not need a named user for each external person. But if you haven’t, the integration account essentially acts on behalf of many external users, which can be a gray area. At a minimum, you should have as many integration accounts as needed (not a single account shared for everything, which could result in one user handling massive transactions). Also, document in your contract, if possible, how they will be treated. Without special terms, treat them as named users and assign the appropriate license type.
- Service Accounts and Others: Some accounts are used for monitoring, backups, or system management by third-party tools. Treat them similarly – assign a license type (perhaps inexpensive if they only perform read-only queries or health checks). If an account only reads data (no updates), it may fall under a more limited license, such as an SAP Business Information user. However, SAP doesn’t automatically exempt read-only accounts either – unless they contain truly read-only, static data (covered under indirect static read rules). When in doubt, err on assigning at least an Employee or similar license to any account that logs in.
A critical best practice is never leaving technical users unclassified in SAP’s license tables. If you do, the audit will flag them all as Professional users by default, possibly inflating your license requirement dramatically.
Go through your user list and make sure even system IDs have a license type (SAP allows categories like “Test” or “Reference” for certain purposes, but those have specific contractual meanings – most customers won’t have those except in special cases).
Usually, you’ll classify technical accounts as either Developer users (if they’re doing system tasks) or as some form of limited user if they’re doing a narrow set of business tasks.
Read SAP Employee Self-Service and Worker Licenses.
Proper Assignment and Counting of Technical Users
To manage compliance:
- Assign Developer licenses to all actual developers: Every ABAP programmer, integration developer, or technical configurator who works on your SAP system should have a Developer-named user license. This includes external consultants who log into your SAP system to perform development tasks. If they use a user ID in your system, they must be licensed (sometimes handled through partner agreements, but ultimately, the liability can fall on the customer in the event of an audit). Ensure these users are tagged correctly so they’re counted as developers, not mistakenly as professionals (unless they need both roles).
- Audit your system accounts: Inventory all background and interface users. Decide for each what the most appropriate license type is. For example, a Developer license classification is typically suitable for a user who executes nightly batch jobs and only runs internal reports and maintenance tasks. For an interface user who creates transactions, you might classify them as a Limited Professional user if the transactions are within a single module. Suppose any technical user defies easy classification (e.g., one account performing a high volume of cross-module transactions on behalf of external apps). In that case, that’s a red flag – you may need to engage SAP about an appropriate licensing approach (possibly the digital access route).
- Counting and LAW consolidation: During SAP’s license audit (LAW – License Administration Workbench – process), you can consolidate users across systems. Ensure that technical accounts present in multiple systems are matched correctly. Also, note that some SAP user measurement reports, by default, ignore certain user types (for example, SAP sometimes excludes “SAP*” or early login accounts). But don’t rely on that; proactively manage all accounts.
In summary, Developer licenses cover the needs of technical users who configure and develop in SAP, but they are not a catch-all for performing business work. Technical accounts are not free—they must be licensed and optimized like any other user.
You can remain compliant without overspending by carefully assigning each technical user the proper license type and monitoring their activities.
Many companies find it useful to periodically review whether some Developer-license users no longer need that level of access (for instance, if a project ends and a person shifts to a functional role, you might downgrade their license). Likewise, retiring obsolete system accounts can free up licenses.
Always remember that if a technical user ID is left without a designation, SAP will count it as a full Professional user in an audit, which could dramatically increase your compliance gap.
Thus, license assignments for developers and technical accounts should be treated with the same seriousness as those for business users.
Recommendations
- License all developers properly: Ensure that any user who develops ABAP code or configures the SAP system is assigned a Developer User license in SAP. This grants them the necessary tools while ensuring compliance. If those same individuals also conduct significant business transactions, consider granting them a Professional license in addition (or instead) to cover that usage.
- Classify technical accounts under named user types: Every background job account, interface user, or system login should be mapped to a license type. There is no special free pass for technical IDs. Based on the account’s function, determine the closest appropriate category (E.g., Developer, Limited) and set it in the user master. This avoids the audit defaulting to an “unclassified” account for an expensive professional license.
- Segregate and minimize technical IDs: Use distinct technical users for different integration or batch tasks, rather than a single super account. This way, you can assign each the lowest necessary license. For example, one account can be used for an HR interface (perhaps licensed as an employee self-service user if it only writes personal data) and another for a finance interface (perhaps a functional user for finance). Fine-tuning this prevents over-classification, where an account performing multiple tasks is assigned a higher license.
- Monitor developer usage and activities: Track the activities of Developer-licensed users. They should mainly use development transactions (SE80, SE38, SPRO, etc.). If you find a Developer user regularly executing business transaction codes in production, that’s a sign they may also need an operational license. Also, ensure only authorized people have developer access – this is not just a security risk but a licensing one (unnecessary Developer licenses cost money).
- Reclaim and recycle licenses for technical users: When a developer leaves the company or a project concludes, remember to remove or reassign their license. Named user licenses are typically transferable internally so that you can allocate that Developer license to someone else. Similarly, if a certain interface is decommissioned, retire the corresponding technical user in SAP so that it doesn’t count toward usage. Regular “license hygiene” for technical accounts can save costs.
- Consult SAP for ambiguous cases: If you have a use case where it’s unclear how to license a technical scenario (for example, a robotic process automation user that simulates many users), engage with SAP or a licensing expert. Special provisions or alternative metrics (such as document-based licensing) may be a better fit than a standard named user assignment. It’s better to clarify upfront than to assume incorrectly and face an audit finding later.
