Intellectual Property and Licensing Rights in SAP Contracts
Introduction
SAP contracts are not just about cost and compliance – they also define what you can and cannot do with the software. Yet, many companies focus on pricing and neglect the fine print around intellectual property (IP) and usage rights.
Failing to consider these clauses can create significant risks down the road. Who really owns that custom report your team coded in ABAP?
Are you permitted to utilize a backup SAP system for disaster recovery without incurring additional fees? Can your outsourced support team log into SAP under your license? These questions need clear answers before you sign. Read our guide to SAP Contract Terms & Clauses to Negotiate: Protecting Flexibility and Reducing Risk.
This guide takes a strategic, procurement-focused look at the key IP and licensing rights in SAP agreements.
We’ll explain how to secure a favorable license scope, assert ownership over custom work, ensure third-party access is permitted, retain IP control in the cloud, and demand proper indemnifications.
The goal is to help CIOs, IT procurement leaders, and legal teams ensure that they own what they build and can use SAP on their terms.
1. Defining License Scope
The first key area is the scope of your SAP license – essentially, where and how you are allowed to use the software.
Many standard SAP contracts focus on production use by default, which can leave gray areas for other environments, such as development, testing, training, or disaster recovery systems.
If your agreement only explicitly mentions the production system, you might later face disputes or surprise costs when SAP discovers you have a standby DR instance or multiple test servers.
To avoid this, negotiate language that explicitly permits the use of SAP in non-production environments. Ensure that your licenses clearly cover typical scenarios, such as development sandboxes, QA/testing systems, backups, and failover environments.
For on-premises licenses, SAP’s general policy is to allow non-production installations as long as they’re for internal use and not running live operations – but don’t assume this is automatically granted.
In cloud subscription contracts (like RISE with SAP), additional systems (extra test tenants or a DR environment) often cost extra unless you negotiate them upfront.
The goal is to leave no ambiguity. When the contract specifies that you can use SAP for development, testing, training, and maintaining a passive backup copy for emergencies, you eliminate a common source of audit friction. Otherwise, a vague scope clause could lead SAP to recommend purchasing new licenses or services for what you thought was already covered.
Checklist:
☐ Dev/test and training environments explicitly included
☐ Backup and disaster recovery usage rights documented
☐ Any extra instances (e.g., additional QA systems or sandboxes) negotiated upfront
2. Custom Code Ownership
In any SAP project, your team might develop custom ABAP programs, enhancements, or reports to fill gaps in the standard software.
You – not SAP must own anything your team builds. Standard contracts can be somewhat unclear on this, sometimes categorizing customizations as “derivative works” of SAP.
You want clear wording that all custom code, configurations, and developments created by or for your company remain your intellectual property.
Owning your custom code means you have the freedom to modify, enhance, or even migrate that code independently of SAP if needed.
Imagine down the road you switch to another platform or want to reuse a clever algorithm your team wrote – you shouldn’t need SAP’s permission. Likewise, if you pay a consultancy (or SAP’s own services team) to write code for you, make sure the contract assigns that IP to your company. SAP should have no claims on extensions or add-ons that are built on their software but created by you.
Benefits:
- Full control of business-specific functionality and IP
- Flexibility to maintain or port your custom code outside of SAP if necessary
Risks if Unclear:
- SAP later claims ownership of your custom extensions or integrations
- Restrictions on using or migrating your own code to other systems or platforms
Checklist:
☐ Contract explicitly defines all custom-developed software as customer-owned IP
☐ No SAP rights or “derivative work” claims over your enhancements
☐ Rights to extract and migrate custom code (e.g., during upgrades or re-platforming) are confirmed
Negotiate SAP SLAs, SAP Cloud SLAs: How to Negotiate Uptime, Support, and Penalties.
3. Third-Party Access Rights
Modern enterprises frequently rely on third parties – outsourcing providers, contractors, consultants, or BPOs – to support or run parts of their SAP environment.
But standard SAP licenses are typically for internal use only, meaning only your employees (and named affiliates) are covered by default.
If you want your partners or service providers to log in to your SAP system, you must ensure the contract allows it. Otherwise, SAP can object or insist that those users be licensed under a separate agreement.
The contract should include a clause authorizing “Named Third-Party Users” (or similar terminology), which states that external individuals operating on your behalf can access the software under your licenses (still subject to each person having a valid named user license in your system).
This makes sure an outsourced administrator or a BPO staff member isn’t considered an unauthorized user. You’ll still need to assign SAP user licenses to these people. Still, SAP won’t be able to forbid their access on a technicality or force you into more costly license categories than necessary.
When negotiating third-party access, consider your current operating model and future needs. For example, if you plan to use a third-party support team or have contractors on a major project, clarify that upfront in the contract.
Also, evaluate the cost impact – can you accommodate those users with your existing license pool, or will you need additional (possibly lighter) license types for them? Be wary of any contract language that restricts non-employees, as it could be a tactic to drive more license sales by forcing you into extra purchases.
Decision Criteria:
- Do your service providers or contractors require ongoing SAP access to perform their duties?
- Can your current licensing model cover these external users affordably (e.g., by utilizing spare named user licenses or less expensive user types)?
- Is SAP’s contract language restricting third-party use in a way that could force extra licenses? If so, push back and get explicit permission for partner access.
Checklist:
☐ Third-party (consultant/outsourcer) access rights clearly permitted in the contract
☐ Licensing requirements for external users defined (so you can properly license those users)
☐ No undue SAP restrictions on partner access beyond normal license compliance
What are your exit plans? – Exit Clause Essentials: Protecting Your Company if SAP Doesn’t Deliver
4. Cloud Service IP Ownership
When you move to SAP’s cloud offerings (such as RISE with SAP S/4HANA, SuccessFactors, or other SaaS products), the question of “who owns what” becomes critical.
In these models, SAP provides the software as a service, but you still generate a lot of unique assets within that service.
It should be unambiguous that you own your data, configurations, and any custom extensions you develop, while SAP retains ownership of the underlying platform and standard software. Don’t assume this is obvious – get it in writing.
Why does this matter? Consider that you’ve built some specialized extensions or workflows in SAP’s cloud platform to support your business.
If you ever decide to leave that cloud service or switch to a different solution, you need the ability to take your creations with you (at least the intellectual property and data, if not the exact code runtime).
Negotiate for data portability and rights to export your configurations and custom code. Ensure the contract says that upon termination, you can retrieve all your data in a usable format, and that any custom code or content you added can be obtained or migrated. Otherwise, you risk being “locked in” – unable to reuse your own innovations outside of SAP’s cloud.
Below is a simple breakdown of IP ownership in an SAP cloud scenario:
| Item | Typical Owner | Key Risk if Unclear |
|---|---|---|
| Customer Data | Customer | SAP retaining or limiting access to your data after exit |
| Custom Extensions | Customer | Locked into SAP’s platform; cannot reuse or transfer your code |
| Core Platform | SAP | (Expected – you have usage rights, but no ownership of SAP’s software) |
Checklist:
☐ Contract guarantees your ownership of all data, configurations, and custom-developed functionality
☐ Data export and portability rights are in place (you can take your data and any custom assets with you if you exit)
☐ Post-termination rights documented (e.g., SAP will provide your data and then delete it, and will not assert any IP claim over your extensions)
Maximize your flexibility. Usage Flexibility in SAP Contracts: Caps, True-Up Clauses, and Buffers.
5. Indemnification Against IP Claims
Even with usage rights and ownership clauses locked down, you need protection in case something goes wrong with the IP under the hood. This is where a strong indemnification clause comes in.
Simply put, SAP should stand behind its product – if a third party sues you claiming that SAP’s software infringes on their patent or copyright, SAP should be the one handling that fight, not your company. Your contract should require SAP to indemnify (defend and cover losses for) any IP infringement claims related to the SAP software.
A solid indemnification clause will state that SAP will: provide or pay for your legal defense, cover any settlements or damages awarded, and, if necessary, procure a license for or replace the infringing portion of the software so you can continue using it.
Ensure that too many exceptions don’t dilute this protection. For example, SAP should also assume responsibility for any third-party components embedded in its solution. You don’t want a scenario where SAP says, “We’re not responsible for that part,” if the vendor of an embedded library or module comes knocking.
Risks Without Indemnity:
- Your company could end up bearing the legal costs and damages for IP issues originating in SAP’s product
- No guaranteed remedy if a third party challenges the software you’re using – you’d be on your own despite having licensed it in good faith.
Checklist:
☐ Broad IP indemnification from SAP is included (covering any claims of patent, copyright, etc. infringement)
☐ Clause explicitly covers legal defense costs, settlements/damages, and provides a fix or replacement if needed
☐ Third-party components or modules in the SAP solution are included in SAP’s indemnification responsibility
6. Pulling It All Together – A Licensing & IP Strategy
All the above points should be viewed as negotiation priorities, not afterthoughts. Too often, companies rush to sign SAP contracts, focusing on price or go-live timelines, only to discover later that they ceded important rights.
To prevent that, take a holistic approach: map out your license and IP rights strategy before finalizing the deal. This means identifying what protections you need (across license scope, custom code ownership, third-party use, cloud portability, etc.) and ensuring each is addressed in the agreement.
It’s helpful to create a simple checklist or “rights matrix” during negotiations. For example, list each key area – such as the ones we covered above – and confirm that the contract language is favorable for each.
Involve stakeholders from IT, procurement, and legal in this review. IT knows how the systems will actually be used (and where loopholes might bite you), procurement drives the negotiation and pricing, and legal can tighten up the wording.
By collaborating, you can catch gaps or ambiguous terms before they become expensive problems.
In the end, a well-negotiated SAP contract should let you sleep easier. You’ll know you have the freedom to use the software as needed, ownership of what you build, flexibility with partners and cloud services, and safety nets if IP issues arise.
That’s a strategic win – it turns the contract from a potential minefield into a solid foundation for a stable, long-term partnership with SAP.
Final Checklist:
☐ License scope is clearly defined across all environments (production, non-prod, backups, etc.)
☐ All custom code and configurations are affirmed as the customer’s IP
☐ Third-party users are authorized to access SAP under your licenses
☐ Cloud data and extensions are portable (you can exit without losing your assets)
☐ Strong indemnification protects you against intellectual property claims
Read about our SAP Negotiation Service
