SAP Licensing and Modifications in ECC

SAP Licensing and Modifications – What is Allowed?

Executive Summary: SAP licensing agreements permit certain modifications to the software, but only within specific boundaries.

Global IT asset managers must understand what types of customization, add-ons, and code changes are permitted under SAP contracts.

This advisory clarifies the distinction between allowed configurations and true modifications, outlines SAP’s rules for software alteration, and provides guidance on how to stay compliant, control costs, and avoid pitfalls when tailoring SAP to meet business needs.

Key Concepts: Customizations, Add-Ons, and Modifications

In SAP terms, not all system changes are treated equally. It’s critical to distinguish between standard customizations, add-ons, and modifications:

• Customization (Configuration/Parameterization): Adjusting SAP’s settings or using provided tools (like transaction codes in the IMG) to fit business processes. These are not considered “modifications” in the sense of the license. For example, configuring a new company code or tweaking workflow rules is fully allowed and expected – it’s part of standard SAP implementation.
• Customer Add-Ons (Enhancements): Building new, independent functionality that extends SAP, typically using SAP’s published APIs or development framework (such as creating a custom Z-program or using the enhancement framework/user exits). Add-ons do not alter SAP’s delivered source code. They are allowed under SAP licensing as long as they use authorized methods and don’t bypass any license restrictions.
• Modifications (Core Code Changes): Changing SAP’s standard delivered software code or metadata. This means altering SAP programs, screens, or objects directly. Modifications extend beyond configuration – for example, editing an SAP program’s source code to alter how payroll calculations work. SAP permits modifications only in limited scenarios, and with significant caveats, which we’ll explore below.

Understanding these definitions is more than semantics – it determines what you’re allowed to do without breaching contract, and how much support and risk you take on by changing the system.

What Modifications Are Allowed Under SAP Licensing

SAP’s on-premise licensing (e.g., SAP ECC 6.0 or S/4HANA on-premise) does allow customers to make certain modifications and custom developments.

Key permissible activities include:

1. Using SAP’s Development Tools and APIs: Customers can develop custom add-ons or even make modifications using the official toolsets provided (such as the ABAP Workbench, SAP SDKs, or published APIs). If SAP has delivered source code (as with ABAP modules), you have the right to adjust it to meet your internal business requirements. For example, you might modify a calculation routine in the finance module to comply with local tax laws. This is allowed only because SAP provides that code and an interface (you usually register the change with SAP via an SSCR registration).
2. Building Enhancements Instead of Direct Changes: SAP encourages the use of extension frameworks (user exits, BADIs, enhancement points) or the SAP Business Technology Platform for extensions. These methods are within the allowed scope – they don’t count as core “modifications” and keep your changes upgrade-friendly. Utilizing these is fully permitted and helps maintain compliance.
3. Custom Programs and Z-Objects: Creating your programs, database tables, transactions (often named with a “Z” or “Y”) is allowed. This original development doesn’t modify SAP’s code; it runs alongside it. As long as these custom programs don’t violate usage rights (for instance, they must not enable unlicensed users to access SAP functionality), they are within your license rights.
4. SAP-Delivered Source Code Adjustments: If a part of SAP is delivered in ABAP source, you can technically modify it for your use. The license stipulates this is permitted only for the SAP software you’ve licensed and received in source code form. It’s essential to note that such modifications should be made cautiously and thoroughly documented. (In contrast, if the code is not provided – e.g., proprietary binaries or code in SAP Cloud – you cannot alter it.)

Important: Any modifications or add-ons must be used only within your licensed environment and by your users. You can’t take an SAP-based development and use it to service third parties or circumvent SAP’s user licensing.

Also, suppose SAP (or an SAP partner) develops a custom solution or add-on for you, which typically comes with its license or agreement. In that case, it’s not automatically covered by your standard license.

Restrictions: What You Cannot Do (or Should Avoid)

SAP’s agreements also spell out clear restrictions on modifications. ITAM professionals should ensure the following activities are off-limits or approached with caution:

• Circumventing License Metrics: No modification is allowed to bypass contractual usage limits. For example, you cannot alter user-count checks or create a workaround to let unlicensed users access the system. Suppose a custom add-on accidentally enables broader access (e.g., a web portal pulling data from SAP for external users). In that case, you must account for that with proper licensing (typically this falls under indirect/digital access rules).
• Modifying Without SAP’s Tools/Authorization: You are not permitted to decompile, reverse-engineer, or modify SAP code that you don’t have in source form. For instance, hacking the kernel or database layer, or altering SAP-provided executables, is strictly forbidden. Similarly, changing cloud-based SAP S/4HANA SaaS solutions is not allowed – those can only be extended via the provided APIs (no access to core code in the SAP S/4HANA Cloud public edition).
• Unregistered Core Modifications: In on-premise environments, if you do modify SAP standard objects, you’re expected to register these changes with SAP (via OSS note or the SSCR system). Failing to do so might violate support agreements. It also means SAP might override your changes in patches because they aren’t aware of them.
• Third-Party Distribution: You cannot take SAP’s software (modified or not) and redistribute it. This includes sharing custom modifications that include SAP source code with other companies without SAP’s permission. All usage must remain internal, as per the license.
• SAP Intellectual Property Rights: Remember that even if you develop a clever modification, SAP retains ownership of its software. You cannot claim IP rights on SAP’s code or modifications of SAP code. And SAP itself is free to develop similar features in future releases – you can’t prevent them by saying “we did it first” in our system.

In short, stick to the rules of engagement: only modify what you’re allowed to, document your changes, and never use a change to cheat licensing terms. If you are unsure, consult your SAP agreement or ask SAP for clarification before proceeding with any questionable alteration.

Risks and Implications of Modifying SAP Software

Making modifications in an SAP system isn’t just a technical decision – it carries business and compliance implications.

Key risk areas include:

• Support Limitations: SAP will support its standard software, but if an issue is caused by your modification or custom code, you own that problem. SAP’s support team may ask you to reproduce issues on an unmodified system or simply declare that the custom code lies outside their support scope. For example, if a performance issue or error stems from a modified SAP program, SAP isn’t obligated to fix that – your team (or a third-party) must do so. This can slow down issue resolution and incur extra costs if outside consultants are needed.
• Upgrade and Compatibility Challenges: Each time SAP releases updates or upgrades (e.g., migrating from ECC 6.0 to S/4HANA or applying enhancement packs), modifications can become incompatible or break. SAP doesn’t guarantee that custom changes will work on future versions. This means heavy modifications often lead to difficult upgrade projects – you might have to redo or adjust all those changes. In essence, today’s quick fix could become tomorrow’s technical debt. Enterprises with numerous core modifications often delay upgrading due to fear of breaking things, which can lead to running outdated software or incurring additional costs for extended maintenance with SAP.
• System Integrity and Security: Poorly designed add-ons or modifications can introduce vulnerabilities or compromise system stability. For example, a custom add-on that hasn’t been thoroughly tested may cause memory leaks or expose a security vulnerability in your SAP environment. Since you’re responsible for custom code, you must also handle its quality assurance. This risk highlights why using SAP-certified tools and adhering to development best practices is crucial.
• License Compliance and Audit Exposure: Custom integrations often blur the lines of SAP’s licensing rules. One major example is indirect access – if you build an interface that allows non-SAP systems or users to retrieve/update SAP data, you may trigger additional license requirements. SAP now offers a Digital Access model (based on document transactions) to license such scenarios. If your modifications inadvertently allow usage beyond what you’ve licensed (e.g., an external app creating sales orders in SAP), you could face compliance issues and back-charges in an audit. Always evaluate the licensing impact of any interface or extension.
• Future Roadmap Misalignment: SAP’s strategy (especially with the push to S/4HANA and cloud) is to minimize core modifications. A system heavily tailored over the years might run fine now, but it could diverge from SAP’s standard so much that moving to new platforms becomes a huge undertaking. For IT asset managers, this is a strategic risk: the more you modify, the more you might be locking the enterprise into the current state unless significant reinvestment is made later. It can also reduce the value of software maintenance, as you may be unable to easily take advantage of new features or fixes that SAP provides (without redoing your custom work).

Bottom line: Always weigh the business value of a modification against these risks. In many cases, alternative approaches (such as using standard configurations or officially supported enhancements) can achieve the goal with less long-term pain.

Cost Implications and Contract Considerations

Every modification or custom development has potential cost impacts – some direct, others indirect.

ITAM professionals should keep an eye on how tailoring SAP influences the total cost of ownership and what to negotiate in contracts:

• Development and Maintenance Costs: Building custom solutions isn’t free – you invest time and resources (developers, testers, ongoing maintenance). There’s also an opportunity cost: custom code can tie up staff to support it indefinitely. When negotiating, consider asking SAP for credits or support if a missing feature forces you to custom-build something that SAP later includes in a product.
• Licensing for Developers and Test Systems: Ensure you have the right user licenses for those who will do development. SAP offers a Developer Named User license (often required for anyone using the development workbench/tools). These tend to cost more than a basic user license. Ensure your contract covers a sufficient number of developer users, or that your Professional users are properly licensed to perform development tasks. Also, if you create additional non-production systems for development or sandbox testing, review if those require separate licenses or if they’re covered under your agreements.
• Indirect Access Costs: As mentioned, custom integrations can increase licensing requirements. When planning such projects, engage SAP early to clarify whether a special license (such as the SAP PI/PO engine or the Digital Access documents package) is required. Sometimes you can negotiate a better deal for these licenses before an audit forces the issue. Proactively addressing this in the contract (for example, by including external user or API access rights) can prevent unpleasant surprises.
• Third-Party Support vs SAP Support: If your SAP system is highly customized, you might consider third-party support providers when SAP’s standard support ends or becomes too costly. These providers (e.g., Rimini Street, Spinnaker) often support custom code as part of their offering and charge lower fees than SAP support. The trade-off is that you won’t get new SAP upgrades or fixes. This can be a cost-saving strategy for stable, heavily modified environments. From a contract view, if you plan to use third-party support, ensure you’re not signing away rights – for example, avoid clauses that lock you into SAP’s cloud transitions if you intend to stay on your modified on-prem system longer.
• Contract Pitfalls: Always read the fine print in SAP agreements regarding modifications. Key areas to watch:
  • Support clauses: Verify if the contract mentions any limitations of support when modifications are present. (SAP usually includes that it’s not responsible for issues caused by mods – just know it’s there.)
  • Audit and compliance terms: Ensure you understand how your custom usage will be measured. If you negotiate any specific terms for indirect use or have an add-on, ensure it is in writing and clearly states how it’s licensed.
  • SAP intellectual property: If you pay SAP or an SAP partner to develop a custom solution for you, clarify who has rights to it and if you need a separate license. Otherwise, you might pay maintenance on that custom solution separately.

To summarize these cost factors and pitfalls, below is a quick comparison table highlighting allowed vs. not allowed modifications, and their impact on cost and contracts:

✅=Permitted, ❌=Not permitted, ⚠️=Permitted only via separate licensing or with caution.

This table highlights that while SAP licensing provides flexibility to tailor the software, it also imposes limits and may incur additional costs. Always factor these into your IT asset management strategy.

Recommendations (Expert Tips)

To manage SAP licensing and modifications effectively, consider these expert recommendations:

• Prioritize Configuration First: Exhaust SAP’s standard customization options before resorting to code modifications. The more you can achieve with native configuration or approved enhancement frameworks, the better – it keeps you in safe territory and provides full support.
• Document Every Change: Maintain detailed documentation of all custom objects and modifications. This helps in audits, troubleshooting, and future upgrades. If SAP support is engaged, you can quickly identify if an issue might stem from a modification and provide the necessary details.
• Register Modifications with SAP: Always use SAP’s recommended procedure (such as OSS notes/SSCR keys for ABAP changes) to register core code modifications. It’s often required under the support agreement and helps SAP identify that a program was altered (so they won’t overwrite your change without warning).
• Avoid License Workarounds: Never attempt to use custom code to circumvent licensing – for example, splitting one user’s actions among multiple IDs to skirt user license counts, or building an interface that indirectly allows unlicensed users to input transactions. SAP audits are sophisticated at catching these patterns, and the short-term gain is not worth the compliance risk.
• Assess Impact Before You Modify: Implement a formal review process in your change management. Whenever a modification or custom integration is proposed, involve licensing and support stakeholders to ensure alignment and seamless implementation. Assess how it will impact your license compliance (do we need extra licenses?), support (can SAP still support us?), and upgrade path. This cross-functional review can save headaches in the future.
• Leverage SAP’s Guidance and Tools: Use SAP-provided tools (like Code Inspector, SAP Cloud Platform Extension Factory, etc.) to ensure your custom code adheres to best practices. SAP even offers services to analyze your custom code for S/4HANA readiness – consider using these to gauge how challenging an upgrade will be, given your current modifications.
• Negotiate Future Flexibility: During contract renewals or new purchases, negotiate terms that acknowledge your customizations. For instance, if you plan to transition to S/4HANA, consider negotiating credits or the inclusion of similar functionality that you have built as custom in ECC. If you rely on heavy integrations, negotiate a reasonable model for indirect access (SAP has offered some customers discount bundles for Digital Access licenses to resolve this). Use your knowledge of your system’s custom usage as leverage in negotiations.
• Consider Third-Party Support for Stable Systems: If your SAP ECC system has been heavily modified and is stable (and you are not yet ready to move to S/4HANA), third-party support can be a viable interim strategy once SAP’s mainstream maintenance ends. It can save costs and cover custom code. Weigh the pros/cons carefully: no new features from SAP versus significant cost savings and extended life for your tailored system.

Checklist: 5 Actions to Take

Ready to ensure your SAP modifications are under control? Here’s a quick action plan:

1. Inventory Your Customizations: Compile a list of all custom developments and core modifications in your SAP landscape. Include details like when they were made, why, and by whom. This is your baseline for risk assessment.
2. Review License Impact: For each custom interface or add-on, determine if it introduces any indirect access or additional usage that isn’t covered by your current licenses. Consult your SAP account rep or licensing expert to verify. Address any gaps proactively.
3. Evaluate Support Status: Check which modifications might be affecting SAP support. If you have unresolved SAP OSS incidents, ensure none are stalled due to custom code. Plan to update or refactor high-risk mods (especially before major upgrades).
4. Implement Governance: Establish an internal policy for SAP modifications. For example, require a business case and architecture review for any change to the SAP standard. Have a governance board with ITAM, architects, and business leads to approve exceptions. This prevents unnecessary mods.
5. Plan for the Future: Align your modification strategy with your SAP roadmap. If you plan to move to S/4HANA or RISE (cloud) in the future, start reducing your dependency on core modifications now – favor extensions that will transition to the new environment. Include remediation of custom code in your migration project plan, with a budget and resources allocated accordingly.

Following this checklist will put you in a strong position to manage SAP licensing compliance and maximize the value of your SAP investments, avoiding unwelcome surprises.

FAQ

Q1: Can we legally modify SAP’s standard software code under our license?
A: Yes, for on-premise SAP (like ECC or S/4HANA on-prem), you are allowed to modify delivered source code for your internal use. SAP provides mechanisms (like developer keys) for this. However, you must stick to SAP’s rules – only modify what’s delivered, and don’t violate any usage terms. In cloud editions, direct modifications are not allowed at all (you’d use extensions instead).

Q2: Do modifications void our SAP support agreement?
A: Not automatically, but SAP’s support may exclude anything caused by the modification. You’ll still receive support for standard functionality, but if a problem is traced to your custom code, SAP may refuse to fix it. In extreme cases, unapproved modifications could breach support terms; however, generally, SAP will ask you to undo the modification or work around it rather than cancel support outright.

Q3: Is using custom add-ons or third-party tools considered “indirect access”?
A: It can be. If a third-party application or a custom tool you built is accessing data or triggering transactions in SAP on behalf of users who aren’t logging in directly, that’s classic indirect access. SAP now licenses this via the Digital Access model (counting documents like Sales Orders, etc.). Always evaluate whether a given integration needs additional SAP licensing. In some cases, if the add-on is purely within SAP (e.g. a custom Z-program run by licensed SAP users), it’s not indirect access. However, an external app or website interacting with SAP is likely to be.

Q4: We plan to move from SAP ECC to S/4HANA Cloud – what happens to our modifications?
A: In S/4HANA Public Cloud, you cannot carry over custom ABAP modifications because customers can’t change the cloud software. You would need to reimplement the functionality using SAP’s cloud extension tools (such as SAP BTP or in-app extensibility) or check if S/4HANA now provides that capability as a standard feature. If you go to S/4HANA Private Cloud (RISE with SAP), you have more flexibility – it’s similar to on-prem and you can do modifications, but SAP still advises minimizing them. It’s crucial to start planning early: identify which ECC mods are truly needed and look for standard alternatives or extension approaches in the new environment.

Q5: How can we ensure compliance during an SAP audit if we have many customizations?
A: Preparation is key. Maintain clear documentation of how each custom solution is utilized and which SAP-named users or systems are involved. Before an audit, run SAP’s license measurement tools (USMM and LAW) and ensure all users are correctly classified (e.g., users with developer access have developer licenses). For interfaces, gather data on document counts if using Digital Access. During an audit, be transparent and demonstrate control by showing that you monitor custom usage and have procedures in place to prevent unauthorized access. If you’ve proactively addressed potential indirect use (maybe by purchasing a digital access package or moving to user-based licensing for connected systems), you’ll be in a good position. The goal is no surprises – you don’t want SAP’s auditors to discover a “hidden” application using SAP data that you haven’t licensed.

Read about our SAP License Optimization Service.

Why Enterprises Choose Redress Compliance for SAP License Optimization

Do you want to know more about our SAP License Optimization Service?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit