SAP Group Licensing and Affiliates: How to Extend Your ELP Across the Corporate Group

How SAP Defines "Affiliate" in Standard Terms

SAP's definition of "Affiliate" appears in its standard Master Agreement Terms & Conditions. The definition typically reads: "Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is under common control with Customer, where 'control' means ownership of more than fifty percent (50%) of the voting equity interests."

This definition has critical nuances that most licensees miss:

1. Majority Ownership (>50%) is the Threshold

The 50% threshold is not 50% equal treatment. SAP measures control. A company that owns 51% of a subsidiary is its affiliate. A company that owns 49% is not, even if it is the largest shareholder. This matters when the corporate structure is complex—minority investments, joint ventures, or SPVs (special purpose vehicles) used in financing structures may fall outside the affiliate definition.

2. Direct or Indirect Control

Affiliate status extends through multiple levels of corporate structure. If Parent Co owns 100% of Sub Co, and Sub Co owns 100% of Sub-Sub Co, all three are affiliates of each other. However, if Sub Co owns only 49% of Sub-Sub Co, Sub-Sub Co is not an affiliate of Parent Co, even though Parent Co indirectly controls it. This creates loopholes for companies structured to minimize affiliate relationships.

3. "Common Control" Relationships

Two companies under common control (e.g., both owned by the same private equity firm or parent holding company) are affiliates of each other. This has important implications for roll-ups or portfolio companies managed by the same PE sponsor. All entities in the portfolio may be considered affiliates for licensing purposes, even if they operate independently.

However, SAP's interpretation of "control" varies. Some SAP contracts define control more narrowly (voting equity only), while others extend it to beneficial ownership or de facto control. This ambiguity is often in SAP's favor—they can argue for a broader affiliate definition if it generates higher fees.

Named User Licences: Person-Specific, Not Entity-Specific

This is the most misunderstood aspect of SAP group licensing. A Named User license is portable within the corporate group—but the user is what is licensed, not the entity.

What This Means in Practice

Suppose you have purchased 500 Named User licenses for SAP ECC under your parent company's Master Agreement. These 500 users can work anywhere within the affiliate structure, as long as they are accessing the same SAP system instance (or linked instances in a system landscape). They can move between subsidiaries without violating the license terms.

However, SAP applies what's called "reasonable use" conditions to this portability. The key questions SAP asks:

• Are the 500 users all accessing the same license pool (same Master Agreement)?
• Are they accessing the same system landscape or different systems?
• Are the Named Users being shared across unrelated use cases?

SAP will argue that if you have 500 Named Users but 1,000 people need access, you've violated the license. The fact that some users work for subsidiaries doesn't matter—you still need to license everyone who uses the system.

The Named User License Does Not Extend to Separate System Instances

Critical limitation: Each Named User license covers access to a specific SAP instance (e.g., production ECC system). If you have two separate SAP instances—one for the parent company and one for a subsidiary—you typically need separate licenses for each, even if they are running the same module (e.g., both are ECC).

This is where SAP squeezes significant money from groups with multiple instances. The 500-user Named User license for Parent's ECC instance cannot extend to Sub's separate ECC instance. Sub needs its own Named User licenses.

Some Master Agreements include "instance bundling" clauses that allow a single Named User license to cover multiple instances, but this is rare and typically reserved for large customers negotiating enterprise-wide agreements.

Affiliate Licensing Provisions and When They Apply

Most SAP Master Agreements include a clause that extends affiliate rights to subsidiaries and group companies. The standard language is: "Affiliate may use Customer's licenses under this Master Agreement, provided that Affiliate's usage is aggregated with Customer's usage for sizing and compliance purposes."

This sounds like affiliate licensing is automatic. It is not. Affiliate usage is only included in the "Effective License Position" (ELP) calculation if certain conditions are met.

Conditions for Affiliate Licensing Rights

1. Entity must meet the definition of "Affiliate": As discussed above, control ownership must exceed 50%. Minority stakes, JVs, and contractually controlled entities typically do not qualify.
2. Usage must be aggregated with parent's usage: Affiliate usage counts toward the parent company's license position for audit and compliance. This is critical: if the parent is audited, SAP will include affiliate usage in the calculation of whether the parent is in compliance.
3. Affiliate's usage must be under a single Master Agreement: All affiliate licenses typically fall under the parent company's Master Agreement, not separate agreements. This means all affiliates are bound by the same T&Cs, renewal terms, and pricing as the parent.
4. Affiliate is not a customer of SAP for separate modules or products: This is a trap. If an affiliate licenses SAP Analytics Cloud, SuccessFactors, or another SAP product separately, that affiliate is now a separate customer for that product. Its usage of the parent's ECC license may no longer qualify for affiliate treatment under the main Master Agreement.
5. Named User licenses are clearly assigned: For Named User licensing models, affiliate usage requires tracking which users belong to the affiliate. If you cannot demonstrate a clear roster of affiliate-specific users, SAP may challenge the affiliate designation and demand additional licenses.

The ELP (Effective License Position) Across Group Structures

The Effective License Position (ELP) is SAP's proprietary calculation of how many licenses a customer needs to own based on actual usage. When calculating ELP across a corporate group, the following rules apply:

Aggregation Rule

All affiliate usage is aggregated for ELP calculation. This means if the parent has 1,000 users and the subsidiary has 500 users, the combined ELP is 1,500 users, regardless of which entity is licensed.

However, aggregation cuts both ways: If the parent is licensed for 1,200 Named Users and the combined group usage is 1,500 users, the group is out of compliance by 300 users. SAP will demand payment for the 300 additional licenses, or it may argue that the parent must acquire an additional 300-user block.

System Landscape Aggregation

If the corporate group runs multiple SAP instances, the ELP calculation typically includes all instances across the group that are part of the same Master Agreement.

Example: Parent runs ECC in North America, subsidiary runs ECC in Europe, subsidiary-of-subsidiary runs ECC in Asia. If all three are licensed under parent's Master Agreement as affiliates, the total user count across all three instances is aggregated for ELP purposes. Even if each instance has low user counts individually, the combined ELP could trigger higher licensing fees or audit exposure.

The "Reasonable Sizing" Trap

SAP often challenges the ELP by claiming that affiliate usage represents "potential" or "forecasted" usage rather than actual usage. SAP then argues the customer should be licensed for the higher number.

For example: A subsidiary has 200 active users but could potentially accommodate 400 if business grows. SAP may argue the ELP should be 400, not 200. This is pure SAP overreach, but it happens frequently in contracts without clear "actual usage" definitions.

System Landscape Implications: Which Systems Need Coverage

Affiliate licensing works within a defined system landscape. SAP requires that you clearly specify which systems are part of the licensed environment.

Single Master Instance

If the entire corporate group uses a single SAP instance (one production, one test, one dev), all affiliate users of that instance fall under the same licensing agreement. This is cleanest from a compliance perspective.

Distributed Instances (Separate by Entity or Geography)

If each entity or region runs its own instance, the question becomes: Are all instances licensed under the parent's Master Agreement (meaning affiliate licensing applies), or do they have separate Master Agreements?

Separate Master Agreements mean each entity is independently licensed and independently auditable. Affiliate licensing under a single Master Agreement means all entities are jointly auditable and licensing decisions cascade across the group.

The choice has major implications:

• Single Master Agreement (Affiliate Model): Simpler compliance, easier user portability, but if one entity is out of compliance, the entire group is exposed to audit. Parent is liable for affiliate licensing violations.
• Multiple Master Agreements (Separate Entities): More complex management, but isolates licensing risk. If a subsidiary violates licensing, the parent's agreement may not be affected. However, SAP often discounts rates for large groups, so separate agreements may mean losing volume discounts.

Group Licensing Agreements vs Entity-by-Entity Approach

Approach 1: Parent-Sponsored Group Licensing

The parent company holds the Master Agreement; all affiliates use licenses under that agreement. Advantages:

• Single negotiation with SAP; volume discounts apply across the group.
• Simpler user and system management; no need to maintain separate license pools.
• Affiliate usage is automatically aggregated for ELP and pricing.

Disadvantages:

• Parent is liable for all affiliate compliance. If a subsidiary violates licensing, the parent is responsible.
• Affiliate's growth is limited by the parent's overall license budget. Adding new subsidiaries or expanding usage can trigger renegotiation of the entire group license.
• Separating from the group (divestiture) is complex; the divested entity may not have standalone SAP licenses and must renegotiate.

Approach 2: Subsidiary-Specific Master Agreements

Each subsidiary signs its own Master Agreement with SAP. Advantages:

• Liability is isolated. If Sub A violates licensing, Sub B is not affected.
• Easier to divest or acquire a subsidiary; it brings its own licensed environment.
• Subsidiaries can negotiate independently if they have leverage (e.g., a large subsidiary in a strategic market).

Disadvantages:

• No volume discounts. Each subsidiary pays full market rates unless it is large enough to negotiate.
• Complexity multiplies. Managing 10 subsidiaries with 10 separate SAP Master Agreements requires dedicated resources.
• Cannot share licenses or users across entities (or highly restricted).

Approach 3: Tiered Group Structure (Holding Company Model)

Large enterprises often use a hybrid: A regional holding company holds the Master Agreement for all subsidiaries in that region. Advantages:

• Balances volume discounts with liability isolation. The holding company aggregates volume but subsidiary relationships are secondary.
• Reduces complexity compared to managing all affiliates under a single parent agreement.
• Supports geographic or business-unit based licensing models.

Common Traps: Subsidiary SAP Debt, Shared Service Centres, Intercompany Usage

Trap 1: Newly Acquired Subsidiaries Running Unlicensed SAP

A common scenario: Company A acquires Company B, which is running SAP with an expiring or invalid Master Agreement. Company A assumes Company B is licensed under its parent Master Agreement. It is not.

If Company B's SAP agreement has expired and Company A does not immediately update its Master Agreement to include Company B, Company B is technically running SAP without valid licenses. This creates:

• Audit exposure for the unlicensed period.
• Potential claims for back-maintenance and support fees.
• Forced negotiation to add Company B retroactively, at SAP's pricing advantage.

Solution: At acquisition closing, update the parent Master Agreement to explicitly include the acquired entity as an affiliate, backdated to the acquisition date if possible.

Trap 2: Shared Service Centres and Named User Counting

Many corporate groups operate shared service centres (SSCs) that provide SAP support, finance, HR operations to multiple affiliates. Named User licensing requires that you have a clear list of who is licensed.

The trap: If SSC employees access SAP on behalf of multiple subsidiaries, who owns those Named User licenses? The parent? The SSC entity? The individual subsidiary?

SAP's answer: All subsidiaries that are served by SSC users must be counted in the overall license allocation. If the SSC has 50 staff supporting 5 subsidiaries, and those 50 staff have access to ECC, all 50 must be Named Users in the group's overall license count.

This is often discovered during audit and leads to significant true-up fees. Avoid the trap by clearly documenting which subsidiary each SSC user is assigned to and licensing accordingly.

Trap 3: Intercompany Transactions and Indirect Access

If Company A enters purchase orders, invoices, or payment information into SAP on behalf of Company B, is Company B an indirect user of SAP?

Under SAP's indirect access licensing rules, the answer is often yes. Indirect access occurs when a non-licensed entity generates data that is processed by SAP systems they do not directly access.

In a corporate group with shared finance operations, this happens constantly. Company B's invoices are entered by Company A's finance team. Company B's inventory is managed by Company A's supply chain. These interactions can trigger indirect access licensing claims.

Solution: Clearly define intercompany workflow and ensure all entities processing data on behalf of others are properly licensed. If the data is truly internal (within the affiliate group), it may not trigger indirect access, but this must be documented and SAP-approved.

How to Negotiate an Affiliate Schedule That Protects the Whole Group

If your company operates a corporate group with multiple SAP-using subsidiaries, your Master Agreement should include a detailed "Affiliate Schedule" that specifies:

1. Clear Definition of What Constitutes an Affiliate

Negotiate a crisp definition. Do not use SAP's default. For example:

"Affiliate means a legal entity in which Customer owns, directly or indirectly, more than 50% of the voting equity and which is listed on Schedule A (Affiliate List). Entities acquired or divested during the term shall be added or removed from Schedule A with 30 days' written notice to SAP, with no change to the licenses or fees until the next renewal period."

2. Affiliate Schedule (Attachment A)

Attach a detailed schedule listing all current affiliates. This serves multiple purposes:

• It forces SAP to acknowledge which entities are covered.
• It gives the parent flexibility to add/remove entities without triggering renegotiation.
• It provides clear documentation for audit defense.

3. System Landscape Schedule (Attachment B)

Specify which SAP systems are covered. For example:

"Licensed Systems: SAP ECC Production (SID: PR1), SAP ECC Development (SID: DE1), SAP BW/4HANA Production (SID: BW1). Affiliate usage of these systems is covered under this Master Agreement. If an Affiliate deploys additional SAP systems not listed, separate licensing is required."

4. Usage Aggregation and Portability Language

Negotiate explicit language on user portability:

"Named User licenses purchased under this Agreement may be used by any employees of Customer or its listed Affiliates who access the Licensed Systems. Users may move between Customer and its Affiliates without reassignment of licenses. The total number of Named Users across Customer and all Affiliates shall not exceed [X] at any time. Usage is aggregated for sizing, compliance, and audit purposes."

5. Affiliate Liability Limitation (if you can negotiate it)

Push back on affiliate liability. Ideally:

"Customer is responsible for licensing of Affiliate usage. However, if an Affiliate breaches this Master Agreement, SAP's remedy is limited to: (a) termination of that Affiliate's licenses, or (b) true-up fees for the breaching Affiliate only. SAP may not terminate Customer's Master Agreement based on a single Affiliate's breach."

SAP will resist this, but it's worth asking. Large customers often get some limitation.

6. Divestiture and Acquisition Provisions

Include specific language on what happens when affiliates are acquired or divested:

"If Customer divests an Affiliate, that Affiliate's licenses shall terminate 30 days after divestiture unless the divested entity separately licenses with SAP. If Customer acquires a new Affiliate, Customer may add it to the Affiliate Schedule with 30 days' notice; licensing costs shall be adjusted at the next renewal period. No interim licensing fees or renegotiation shall be required for acquisitions or divestitures."

What This Means For You

If you manage SAP licensing for a corporate group, the following actions will protect you:

• Document your corporate structure: Create a clear org chart showing ownership percentages. This proves affiliate status to SAP.
• Negotiate an Affiliate Schedule: Get explicit agreement from SAP on which entities are covered. Do not rely on the default Master Agreement language.
• Clarify system landscape: Specify which SAP instances are part of the licensed environment. Document any systems that are not covered.
• Track Named Users by entity: If you use Named User licensing, maintain a roster showing which users belong to each entity. This defends against audit challenges.
• Document shared service centre usage: If SSC staff access SAP on behalf of multiple entities, make sure they are counted in the overall license allocation and clearly assigned.
• Review acquisition/divestiture clauses: Before acquiring or divesting a subsidiary that uses SAP, understand the licensing impact. Update the Master Agreement immediately.

Summary: Key Takeaways

SAP affiliate licensing is designed to extend the parent's licenses to subsidiaries without duplicating fees—but only under careful contract management. The definition of "Affiliate" matters; it is typically >50% ownership but varies by contract. Named User licenses are person-specific and portable within the group, but each separate SAP instance typically requires separate licenses. The Effective License Position (ELP) aggregates usage across affiliates, which can inflate compliance risk if multiple entities are included.

The best defense is a detailed Affiliate Schedule attached to your Master Agreement that specifies which entities are covered, which systems are included, and what happens if entities are acquired or divested. Without this, you risk being held liable for affiliate compliance violations you did not anticipate.

Most importantly: Affiliate licensing is not "set and forget." It requires active management as your corporate group evolves—especially during acquisitions, divestitures, or system landscape changes.