Key Concepts: Customisation, Add-Ons, and Modifications
In SAP terms, not all system changes are treated equally. Understanding the distinction determines what you are allowed to do without breaching contract and how much support and risk you take on. For a broader overview of SAP licence types, see our dedicated guide.
Customisation (Configuration)
Adjusting SAP's settings or using provided tools (IMG transaction codes) to fit business processes. This is not considered a "modification" — it is fully allowed and expected as part of standard SAP implementation. Examples: configuring a new company code, tweaking workflow rules, setting up pricing conditions.
Customer Add-Ons (Enhancements)
Building new, independent functionality that extends SAP using published APIs or the enhancement framework (Z-programs, user exits, BADIs). Add-ons do not alter SAP's delivered source code. They are allowed under SAP licensing as long as they use authorised methods and do not bypass licence restrictions.
Modifications (Core Code Changes)
Changing SAP's standard delivered software code or metadata directly — editing SAP programs, screens, or objects. SAP permits modifications only in limited scenarios and with significant caveats: registration with SAP (SSCR), no support for issues caused by the change, and potential upgrade incompatibility.
SAP/Partner Add-On Products
If SAP or an SAP partner develops a custom solution for you, it typically comes with its own licence or agreement. It is not automatically covered by your standard SAP licence — budget for additional licence and maintenance fees.
What Modifications Are Allowed
Using SAP's Development Tools and APIs
Customers can develop custom add-ons or make modifications using official toolsets (ABAP Workbench, SAP SDKs, published APIs). If SAP has delivered source code (as with ABAP modules), you can adjust it to meet internal business requirements — for example, modifying a calculation routine in the finance module for local tax compliance. You register the change via SSCR registration.
Enhancements via Extension Frameworks
SAP encourages the use of user exits, BADIs, enhancement points, or SAP Business Technology Platform for extensions. These methods are within the allowed scope, do not count as core "modifications," and keep changes upgrade-friendly. Using these is fully permitted and is the recommended approach.
Custom Programs and Z-Objects
Creating your own programs, database tables, and transactions (Z or Y namespace) is allowed. This original development runs alongside SAP's code without modifying it. As long as these custom programs do not enable unlicensed users to access SAP functionality, they are within your licence rights.
SAP-Delivered Source Code Adjustments
If a part of SAP is delivered in ABAP source, you can technically modify it for your use — but only for SAP software you have licensed and received in source form. Such modifications must be thoroughly documented and registered. Code not provided in source form (proprietary binaries, SAP Cloud code) cannot be altered.
Any modifications or add-ons must be used only within your licensed environment and by your licensed users. You cannot take an SAP-based development and use it to service third parties or circumvent SAP's user licensing. All usage must remain internal, as per the licence agreement.
Restrictions: What You Cannot Do
- Circumventing licence metrics. No modification is allowed to bypass contractual usage limits. You cannot alter user-count checks or create workarounds to let unlicensed users access the system. If a custom add-on enables broader access (e.g., a web portal pulling SAP data for external users), you must account for that with proper licensing — typically under indirect/digital access rules.
- Decompiling or reverse-engineering. You are not permitted to decompile, reverse-engineer, or modify SAP code you do not have in source form. Hacking the kernel, altering SAP executables, or changing cloud-based S/4HANA SaaS solutions is strictly forbidden. Cloud can only be extended via provided APIs.
- Unregistered core modifications. If you modify SAP standard objects on-premise, you are expected to register changes with SAP (via SSCR system). Failing to do so may violate support agreements and means SAP might override your changes in patches without warning.
- Third-party distribution. You cannot take SAP software (modified or not) and redistribute it. Sharing custom modifications that include SAP source code with other companies without SAP's permission is prohibited. All usage must remain internal.
- Intellectual property claims. SAP retains ownership of its software. You cannot claim IP rights on SAP's code or modifications of SAP code. SAP is free to develop similar features in future releases.
Custom integrations often blur the lines of SAP's licensing rules. If you build an interface that allows non-SAP systems or users to retrieve/update SAP data, you may trigger additional licence requirements. SAP's Digital Access model (based on document transactions) now licenses such scenarios. If your modifications inadvertently allow usage beyond what you have licensed, you could face compliance issues and back-charges in an audit.
Risks and Implications
- 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 may ask you to reproduce issues on an unmodified system or declare custom code lies outside their support scope. This can slow resolution and incur extra costs for outside consultants.
- Upgrade and compatibility challenges. Each SAP update or upgrade can make modifications incompatible or break them. Heavy modifications often lead to difficult upgrade projects — today's quick fix becomes tomorrow's technical debt. Enterprises with numerous core modifications often delay upgrading, incurring additional costs for extended maintenance.
- System integrity and security. Poorly designed add-ons can introduce vulnerabilities or compromise stability. Since you are responsible for custom code quality assurance, using SAP-certified tools and adhering to development best practices is crucial.
- Licence compliance and audit exposure. Custom integrations can trigger SAP audit findings. An external app creating sales orders in SAP could face back-charges if indirect access was not licensed. Always evaluate the licensing impact of any interface or extension before building it.
- Future roadmap misalignment. SAP's strategy (especially with the push to S/4HANA and cloud) is to minimise core modifications. A heavily tailored system may diverge so much from SAP's standard that moving to new platforms becomes a huge undertaking — reducing the value of software maintenance and locking the enterprise into its current state.
Modification Scenarios: Quick Reference
| Scenario | Allowed? | Cost / Contract Impact |
|---|---|---|
| Standard configuration (no code change) | ✅ Yes | Covered by existing licence. Fully supported by SAP. |
| Custom reports or Z-transactions | ✅ Yes | No direct licence cost. Support is internal/own risk for custom code. |
| Modifying SAP's delivered ABAP code | ✅ With registration | No extra licence fee, but maintenance risk: may increase upgrade effort and consulting costs. |
| Using SAP APIs to build an integration | ✅ Yes | Potential indirect access cost: may require additional licences for external users or Digital Access documents. |
| SAP/Partner-developed add-on product | ⚠️ Separate agreement | Treated as new product purchase. Additional licence and maintenance fees apply. |
| Changing software to unlock unlicensed functionality | ❌ No — contract breach | Non-compliance: audit penalties, forced licence purchase. Severe financial and legal risk. |
| Modifying code in S/4HANA Public Cloud (SaaS) | ❌ No — technically impossible | N/A. Extensions only via SAP BTP or in-app extensibility. |
Worried about how your SAP modifications will affect an S/4HANA or RISE migration?
RISE with SAP Guide →Cost Implications and Contract Considerations
Development and Maintenance Costs
Building custom solutions requires investment in developers, testers, and ongoing maintenance. Custom code can tie up staff to support it indefinitely. Consider asking SAP for credits or support if a missing feature forces you to custom-build something SAP later includes in a product.
Developer Licences and Test Systems
SAP offers a Developer Named User licence (required for anyone using the development workbench), which tends to cost more than a basic user licence. Ensure your contract covers sufficient developer users. If you create additional non-production systems for development/sandbox testing, review whether those require separate licences.
Indirect Access Costs
Custom integrations can increase licensing requirements. Engage SAP early to clarify whether a special licence (PI/PO engine, Digital Access documents package) is required. Proactively addressing this in the contract — for example, including external user or API access rights — prevents unpleasant audit surprises. See our Digital Access Advisory Service.
Third-Party Support vs SAP Support
If your SAP system is highly customised, third-party support providers may cover custom code as part of their offering at lower fees than SAP support. The trade-off: no new SAP upgrades or fixes. This can be a cost-saving strategy for stable, heavily modified environments — but ensure your contract does not lock you into SAP cloud transitions if you intend to stay on modified on-prem longer. See our guide on SAP support costs.
5-Step ITAM Action Checklist
Inventory Your Customisations
Compile a list of all custom developments and core modifications in your SAP landscape. Include details: when made, why, by whom, and whether registered with SAP. This is your baseline for risk assessment.
Review Licence Impact
For each custom interface or add-on, determine if it introduces indirect access or additional usage not covered by current licences. Consult your SAP account rep or a licensing expert. Address gaps proactively before SAP audits force the issue.
Evaluate Support Status
Check which modifications might affect SAP support. If you have unresolved SAP incidents, ensure none are stalled due to custom code. Plan to update or refactor high-risk modifications, especially before major upgrades.
Implement Governance
Establish an internal policy for SAP modifications. Require a business case and architecture review for any change to SAP standard. Have a governance board (ITAM, architects, business leads) to approve exceptions. This prevents unnecessary modifications and keeps changes documented.
Plan for the Future
Align your modification strategy with your SAP roadmap. If you plan to move to S/4HANA or RISE, start reducing dependency on core modifications now — favour extensions that will transition to the new environment. Include remediation of custom code in your migration project plan.
Frequently Asked Questions
Can we legally modify SAP's standard software code under our licence?
Yes, for on-premise SAP (ECC or S/4HANA on-prem), you can modify delivered source code for your internal use. SAP provides mechanisms (developer keys, SSCR registration) for this. However, you must follow SAP's rules — only modify what is delivered, and do not violate usage terms. In cloud editions, direct modifications are not allowed; you use extensions via SAP BTP instead.
Do modifications void our SAP support agreement?
Not automatically, but SAP's support may exclude anything caused by the modification. You still receive support for standard functionality. If a problem is traced to your custom code, SAP may refuse to fix it. In extreme cases, unapproved modifications could breach support terms, but generally SAP will ask you to undo the modification or work around it rather than cancel support outright.
Is using custom add-ons or third-party tools considered "indirect access"?
It can be. If a third-party application or custom tool accesses data or triggers transactions in SAP on behalf of users not logging in directly, that is classic indirect access. SAP licenses this via the Digital Access model (counting documents like Sales Orders). A custom Z-program run by licensed SAP users is generally not indirect access, but an external app or website interacting with SAP likely is.
What happens to our modifications when we move to S/4HANA Cloud?
In S/4HANA Public Cloud, you cannot carry over custom ABAP modifications — you must reimplement using SAP's cloud extension tools (SAP BTP, in-app extensibility) or find standard alternatives. In S/4HANA Private Cloud (RISE with SAP), you have more flexibility similar to on-prem, but SAP advises minimising modifications. Start planning early: identify which ECC mods are truly needed and look for standard alternatives.
How do we ensure compliance during an SAP audit with many customisations?
Maintain clear documentation of how each custom solution is used and which SAP named users or systems are involved. Run SAP's licence measurement tools (USMM and LAW) to ensure all users are correctly classified. For interfaces, gather data on document counts if using Digital Access. During an audit, be transparent and demonstrate control — the goal is no surprises. See our SAP Audit Defence Service.
Need Help Managing SAP Modifications and Compliance?
Whether you are assessing the licensing impact of custom integrations, preparing for an SAP audit, negotiating indirect access terms, or planning an S/4HANA migration with heavy customisations — our independent advisory team helps enterprises stay compliant, reduce risk, and optimise costs.