What types of customisation, add-ons, and code changes are permitted under SAP contracts? A practical guide covering the boundaries between configuration, enhancement, and core modification, plus the compliance risks, cost implications, and governance strategies every enterprise needs to manage.
This guide is part of our SAP Licensing Knowledge Hub. See also: Understanding SAP Licence Types | SAP Digital Access Complete Guide | SAP Audit Defence Service.
| Change Type | Definition | Allowed? |
|---|---|---|
| Customisation (Configuration) | Adjusting SAP settings or using provided tools (IMG transaction codes) to fit business processes. Not considered a "modification." Examples: configuring company codes, tweaking workflow rules, setting up pricing conditions | Fully allowed and expected as part of standard implementation. Fully supported by SAP |
| Customer Add-Ons (Enhancements) | Building new, independent functionality extending SAP using published APIs or the enhancement framework (Z-programs, user exits, BADIs). Does not alter SAP's delivered source code | Allowed under SAP licensing as long as using authorised methods and not bypassing licence restrictions |
| Modifications (Core Code Changes) | Changing SAP's standard delivered software code or metadata directly: editing SAP programs, screens, or objects | Permitted only in limited scenarios with significant caveats: SSCR registration required, no support for issues caused by the change, potential upgrade incompatibility |
| SAP/Partner Add-On Products | Custom solutions developed by SAP or an SAP partner for your specific needs | Not automatically covered by standard SAP licence. Treated as new product purchase with additional licence and maintenance fees |
| Allowed Action | Detail |
|---|---|
| Using SAP's development tools and APIs | Develop custom add-ons or make modifications using official toolsets (ABAP Workbench, SAP SDKs, published APIs). If SAP delivered source code (ABAP modules), you can adjust it for internal business requirements. Register via SSCR |
| Enhancements via extension frameworks | SAP encourages user exits, BADIs, enhancement points, or SAP Business Technology Platform for extensions. Within allowed scope, do not count as core "modifications," and keep changes upgrade-friendly. Fully permitted and recommended |
| Custom programs and Z-objects | Creating your own programs, database tables, and transactions (Z or Y namespace) is allowed. Original development runs alongside SAP code without modifying it. Must not enable unlicensed users to access SAP functionality |
| SAP-delivered source code adjustments | If part of SAP is delivered in ABAP source, you can modify it for your use, but only for licensed software received in source form. Must be documented and registered. Proprietary binaries and 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.
| Restriction | Detail |
|---|---|
| Circumventing licence metrics | No modification is allowed to bypass contractual usage limits. Cannot alter user-count checks or create workarounds for unlicensed users. If a custom add-on enables broader access (web portal pulling SAP data for external users), you must account for that with proper licensing under indirect/digital access rules |
| Decompiling or reverse-engineering | Not permitted to decompile, reverse-engineer, or modify SAP code you do not have in source form. Hacking the kernel, altering executables, or changing cloud-based S/4HANA SaaS solutions is strictly forbidden. Cloud can only be extended via provided APIs |
| Unregistered core modifications | On-premise modifications to SAP standard objects must be registered with SAP via SSCR system. Failing to do so may violate support agreements. SAP might override changes in patches without warning |
| Third-party distribution | Cannot take SAP software (modified or not) and redistribute it. Sharing custom modifications that include SAP source code with other companies without 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 allowing non-SAP systems or users to retrieve/update SAP data, you may trigger additional licence requirements. SAP's Digital Access model now licenses such scenarios. If modifications inadvertently allow usage beyond what you have licensed, you could face compliance issues and back-charges in an audit.
| Risk | Detail |
|---|---|
| Support limitations | SAP supports standard software but if an issue is caused by your modification, you own that problem. SAP may ask you to reproduce on an unmodified system or declare custom code outside support scope. Can slow resolution and incur consultant costs |
| Upgrade and compatibility challenges | Each SAP update can make modifications incompatible. Heavy modifications lead to difficult upgrade projects. Today's quick fix becomes tomorrow's technical debt. Enterprises with numerous core modifications often delay upgrading, incurring extended maintenance costs |
| System integrity and security | Poorly designed add-ons can introduce vulnerabilities or compromise stability. You are responsible for custom code quality assurance. Use SAP-certified tools and development best practices |
| Licence compliance and audit exposure | Custom integrations can trigger SAP audit findings. An external app creating sales orders could face back-charges if indirect access was not licensed. Evaluate licensing impact of any interface before building it |
| Future roadmap misalignment | SAP's strategy (push to S/4HANA and cloud) is to minimise core modifications. A heavily tailored system may diverge so much from standard that moving to new platforms becomes a huge undertaking, reducing maintenance value and locking the enterprise into its current state |
| 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 | Yes, with SSCR 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 | Extensions only via SAP BTP or in-app extensibility |
| Cost Factor | Detail |
|---|---|
| Development and maintenance costs | Building custom solutions requires investment in developers, testers, and ongoing maintenance. Custom code can tie up staff indefinitely. Consider asking SAP for credits if a missing feature forces custom development that SAP later includes in a product |
| Developer licences and test systems | SAP offers Developer Named User licence (required for anyone using development workbench), typically more expensive than basic user licence. Creating additional non-production systems may require separate licences. Review contract coverage |
| Indirect access costs | Custom integrations can increase licensing requirements. Engage SAP early to clarify whether special licences (PI/PO engine, Digital Access document package) are required. Proactively addressing this in the contract prevents unpleasant audit surprises |
| Third-party support vs SAP support | If SAP system is highly customised, third-party support providers may cover custom code at lower fees. Trade-off: no new SAP upgrades or fixes. Cost-saving strategy for stable, heavily modified environments. Ensure contract does not lock you into SAP cloud transitions |
| Step | Action | Detail |
|---|---|---|
| 1 | Inventory your customisations | Compile a list of all custom developments and core modifications. Include: when made, why, by whom, whether registered with SAP. This is your baseline for risk assessment |
| 2 | 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 licensing expert. Address gaps proactively before audit |
| 3 | Evaluate support status | Check which modifications might affect SAP support. If unresolved incidents, ensure none stalled due to custom code. Plan to update or refactor high-risk modifications before major upgrades |
| 4 | Implement governance | Establish internal policy for SAP modifications. Require business case and architecture review for any change to SAP standard. Governance board (ITAM, architects, business leads) to approve exceptions. Prevents unnecessary modifications |
| 5 | Plan for the future | Align modification strategy with SAP roadmap. If moving to S/4HANA or RISE, start reducing dependency on core modifications now. Favour extensions that transition to the new environment. Include remediation in migration project plan |
Yes, for on-premise SAP (ECC or S/4HANA on-prem), you can modify delivered source code for internal use. SAP provides mechanisms (developer keys, SSCR registration). 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.
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 custom code, SAP may refuse to fix it. In extreme cases, unapproved modifications could breach support terms, but generally SAP asks you to undo the modification or work around it rather than cancel support outright.
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.
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), you have more flexibility similar to on-prem, but SAP advises minimising modifications. Start planning early: identify which ECC modifications are truly needed and look for standard alternatives.
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 audit, be transparent and demonstrate control. See our SAP Audit Defence Service.
Whether 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. 100% vendor-independent. Fixed-fee engagement.
SAP Audit Defence ServiceIndependent SAP advisory. Modification risk assessment. Indirect access negotiation. Audit defence. 100% vendor-independent, fixed-fee engagement.