SAP Licence Compliance for Subsidiaries and Affiliates: Group Licensing Rules Explained

How SAP Group Licensing Works

SAP licence compliance for subsidiaries is one of the most misunderstood aspects of enterprise licensing. Most companies believe their parent company's license agreement covers all subsidiaries. It doesn't—not unless the contract explicitly states it does.

The foundation of SAP group licensing is the Effective License Position (ELP). This is SAP's term for the total entitlements a customer holds across their entire corporate group. When SAP agrees to an enterprise licensing model, they're theoretically selling you rights that apply globally—but only if your group licensing clause is written correctly.

Here's what most enterprises miss: SAP's standard contracts define "your company" very narrowly. It means the legal entity that signs the agreement, plus those entities explicitly listed as affiliates. A subsidiary acquired after contract signature is almost never automatically covered. This is intentional. SAP drafts contracts to force expensive amendments when you grow through acquisition.

The Effective License Position (ELP) in Practice

Your ELP is calculated based on three factors:

• Named Users: The total count of all users (across all subsidiaries and affiliates) with rights to access SAP systems
• Named Developers: If applicable, developers with access to SAP development environments, counted globally
• System Landscape: Every production, test, and development system running SAP in every entity must be accounted for in the licensing model

The critical point: your ELP must account for every subsidiary, every user, and every system. Miss one subsidiary, and you have an audit exposure.

What "Affiliates" Means in SAP Contracts

SAP's definition of an affiliate is purely financial, not operational. In their standard terms, an affiliate is any entity in which the parent company holds 50% or greater ownership. This is typically buried in the definitions section of the contract—Section 2(c) or similar.

The Ownership Threshold

This 50% threshold creates a critical gap. If you own 49% of a subsidiary, it's not an affiliate under SAP's definition, and users there are not automatically covered. More importantly:

• Joint ventures below 50%: Not covered automatically. You need separate licenses.
• Minority investments: If you hold less than 50%, those entities need their own licenses
• Recently acquired entities: May not be listed in your contract's schedule of affiliates yet
• Holding company structures: Complex ownership chains can create ambiguity about who counts as an "affiliate"

This is where SAP auditors earn their bonuses. They request a complete organization chart and then argue that a subsidiary with 51% ownership—technically covered—wasn't explicitly listed in the contract addendum from 2018. Therefore, they claim, it requires a new license.

The M&A Compliance Trap: Subsidiaries and Inherited SAP Systems

The most dangerous scenario for enterprises is acquiring a company that already runs SAP. This happens constantly, and compliance is almost always deferred until a SAP audit surfaces the problem.

What Happens When You Acquire a SAP Customer

When Company A acquires Company B (which runs SAP), three things happen simultaneously:

1. Company B's original SAP license is still valid—for now. That vendor contract stays in force until it expires or is terminated.
2. Company A's group licensing clause may not cover the newly acquired systems—because Company B wasn't listed as an affiliate at the time the parent license was signed.
3. Company B's systems continue to run on their original license—creating a compliance gap where the acquired entity is neither fully covered by its old agreement nor by the parent's group license.

SAP's 30-day notification clause requires that customers notify SAP of changes in control within 30 days of acquisition. Most enterprises miss this deadline, accidentally creating a technical breach in their licensing position.

The Real Risk

What SAP calls "change of control" you should call a compliance deadline. If you acquire a SAP customer and don't formally notify SAP and amend your group licensing position within 30 days, you technically have unlicensed systems. When SAP audits you two years later (during a support renewal negotiation), they will find this gap and use it as leverage.

Named User Compliance Across Subsidiaries

Named User licensing (NU) is where subsidiaries create the most audit exposure. SAP counts named users globally. If you have a Named User license for 500 users, that 500 must cover users across all subsidiaries—not 500 per subsidiary.

How Named Users Are Counted

SAP's definition of a "named user" is broad: any person who has been given the technical ability to access an SAP system. This includes:

• Regular business users in ERP modules
• Read-only data analysts
• External consultants with system access
• Employees of subsidiaries
• Temporary contractors
• User accounts not actively used but technically enabled

SAP auditors will count every account that has ever been provisioned in SAP systems across all subsidiaries. Deprovisioned accounts, inactive accounts, and test accounts all count if they're still in the user master record.

The Subsidiary-Specific Problem

In a multi-subsidiary structure, user counts often spiral across entities. A parent company with 1,000 named users might actually have 3,500 when you count subsidiaries, contractors, and regional offices. The audit finding reads: "You are licensed for 1,000 named users but have provisioned 3,500. This is a material breach requiring license purchase or contract renegotiation."

Worse, if subsidiaries have autonomous IT departments, they often provision users without coordinating with the parent's licensing team. Each subsidiary thinks they're within limits; the parent's licensing team has no idea.

System Landscapes in Subsidiaries: Development, Test, and Production Rules

A critical compliance error: assuming subsidiary systems follow the same licensing rules as the parent. They don't—technically.

SAP's System Landscape Requirements

SAP's standard license grants:

• Production systems: Full license required for the number of users/CPUs/transactions
• Test systems: Usually licensed at 50% of production cost (but still require a license)
• Development systems: Usually licensed at 50% of production cost, often with named developer licensing

The trap: many enterprises think "If we're licensed for production, we don't need to separately license test and dev." Wrong. SAP charges separately for each system type. If a subsidiary runs a production system (even if it only has 100 users while the parent has 5,000), you need separate licensing for that subsidiary's test and development systems.

System Duplication in Subsidiary Landscapes

Complex corporate groups often create redundancy. Company A (parent) has production, test, and development systems. Company B (acquired subsidiary) also has production, test, and development systems—for a total of six systems. All must be licensed.

SAP auditors have found instances where companies believed they had one licensed system landscape but actually had two or three operating across different subsidiaries, with only one set of systems properly licensed.

The "Group License" Concept: What Covers All Affiliates and What Doesn't

SAP uses the term "group license" loosely, and that ambiguity is profitable for them. There is no standardized SAP product called a "Group License." Instead, what's usually meant is an enterprise agreement that includes language stating it applies to the "customer and its affiliates."

When Group Language Actually Covers Everyone

True group coverage typically requires:

• A specific clause stating "this agreement applies to Customer and all affiliates (as defined as entities where Customer holds 50% or more ownership)"
• A schedule of affiliates attached to the contract, updated whenever a new affiliate is added
• Named User counts and system counts that aggregate across all affiliates, not per affiliate
• A process for amending the affiliate schedule when acquisitions occur

Most enterprise agreements have something close to this. The problem: they were negotiated years ago, when the company had fewer subsidiaries. Since then, acquisitions have expanded the group, and the affiliate schedule hasn't been updated.

When Group Language Is Worthless

Some enterprise agreements say "this applies to Customer and its affiliates" without defining what "affiliates" means. In such cases, SAP will argue that "affiliates" means only those explicitly listed in the contract—and if a subsidiary isn't listed, it's not covered.

Even worse, some contracts say "this applies to Customer" and then separately state "additional affiliates may be added by written amendment, at SAP's discretion." This gives SAP veto power over whether your new subsidiary is covered. SAP's discretion always favors SAP.

What Happens When You Acquire a Company Using SAP: The 30-Day Window

Acquisition is when your SAP compliance risk becomes acute. Here's the timeline SAP imposes:

The 30-Day Notification Requirement

Your group licensing agreement almost certainly contains a change-of-control clause. This typically states: "Customer must notify SAP of any change of control of Customer or its material affiliates within 30 days of the change."

Change of control means:

• You acquire a majority stake in another company
• You acquire a company that runs SAP systems
• A company holding 50% or more of your company is acquired by a third party

The 30-day window is a trap. Most M&A teams don't even know this clause exists. By the time the integration team gets around to notifying SAP (often 6-12 months post-acquisition), you're already technically in breach.

What SAP Does With Your Notification

When you notify SAP of an acquisition, they will:

1. Request a detailed audit: They want to see the acquired company's existing SAP licenses, systems, and user counts
2. Demand a change order: If the acquired company's systems or users aren't covered by your group license, SAP will draft an amendment requiring you to purchase additional licenses or expand your existing license
3. Claim past non-compliance: They will often argue that from the date of acquisition (day 1) to the date of notification, you were running unlicensed systems. This creates "make-good" obligations

The leverage is asymmetrical. You're typically in the middle of integrating systems, your legal team is occupied, and SAP knows you won't want support renewal delays. This is when they push for unfavorable amendments.

Indirect Access Exposure in Subsidiaries

Indirect access is SAP's biggest growth area in audits, and subsidiaries amplify this risk dramatically. If a third-party application (ERP system from another vendor, a data warehouse, a business intelligence platform) connects to a SAP system in a subsidiary, every user of that application may need an SAP Named User license.

How Indirect Access Works Across Subsidiaries

Example: Company A's supply chain system (subsidiary 1) pulls real-time inventory data from Company B's SAP system (subsidiary 2) through an API. All users of the supply chain system in subsidiary 1 are gaining "indirect access" to SAP. Each of those users requires an SAP Named User license.

In large corporate groups with multiple subsidiaries, these integration points multiply. A finance system, a procurement system, a customer service system—all pulling data from SAP systems across different subsidiaries. Each creates indirect access exposure.

Why SAP Targets Indirect Access in Audits

Indirect access is difficult to track and hard to defend. Most enterprises can't produce a complete map of which applications connect to which SAP systems across which subsidiaries. SAP auditors ask for this map, and when you can't produce it, they estimate the exposure—usually conservatively in SAP's favor.

We've seen audit findings where SAP estimated 2,000 additional named users through indirect access alone, costing the enterprise $500,000+ in licensing fees.

Building a Practical Framework for Group-Wide SAP Compliance Management

If you operate multiple subsidiaries with SAP systems, you need a centralized compliance framework. This means:

1. Maintain an Authoritative Affiliate Schedule

Create and maintain a single source of truth: a list of all subsidiaries, their ownership percentages, and whether they're covered under your group license. Update this quarterly, especially after M&A activity. When a new acquisition happens, amend your SAP contract proactively—don't wait for 30 days to pass.

2. Implement Group-Wide User Provisioning Controls

Don't let subsidiary IT teams provision users independently. Create a centralized approval process where new user accounts (across all subsidiaries) are validated against your total Named User entitlement. This prevents accidentally exceeding your license.

3. Map All Systems and Connectivity

Conduct a quarterly audit of:

• Every SAP system (production, test, dev) in every subsidiary
• Every third-party application that connects to SAP in any subsidiary
• User counts in each system
• Any changes since the last audit

4. Establish Clear Ownership of Compliance

Assign one person or team responsibility for group licensing. They should report directly to the CFO or Chief Procurement Officer—not buried in IT. This ensures SAP licensing gets the executive attention it deserves and doesn't fall through cracks during organizational churn.

5. Document Your ELP Calculation

Create a documented model showing how your Effective License Position is calculated. Include:

• Total named users across all subsidiaries
• Named developers across all subsidiaries
• All production systems with user counts
• All test and development systems
• Any indirect access exposure identified

When SAP audits you, being able to produce this document immediately shifts the negotiating power in your favor.

Negotiation Strategy: Pushing for Consolidated Group Licensing

When you're renewing your SAP agreement, your negotiating team should push for true consolidated group licensing language. This means:

1. Define Affiliates Broadly and Permanently

Don't accept "affiliates as listed in Schedule A." Instead, negotiate: "Customer and all entities in which Customer holds 50% or greater ownership, whether listed in Schedule A at the time of contract execution or acquired during the term."

This shifts the burden. Future acquisitions are automatically covered. You don't need to renegotiate every time the company grows.

2. Get Explicit Indirect Access Language

SAP will try to expand Named User licensing to cover indirect access. Push back with language that defines indirect access narrowly: "Indirect access applies only where a third-party application allows unfiltered access to SAP data and functions, not where data is accessed through read-only APIs or aggregated reporting interfaces."

This is negotiable, but only if you bring it up during renewal, not during an audit.

3. Secure a Change-of-Control Waiver

Propose waiving the 30-day notification requirement for acquisitions below a certain size threshold (e.g., less than 500 users or less than X systems). This gives you breathing room to integrate acquired companies without triggering immediate SAP licensing changes.

4. Lock in ELP Calculations for Defined Periods

Push for language stating: "The Effective License Position is [X named users, Y systems] through [date]. Adjustments to ELP require written agreement and will be made only upon material changes to the customer's business structure."

This prevents SAP from arbitrarily reinterpreting your ELP mid-contract.

5. Negotiate Support for Future Acquisitions

Before your next big acquisition, secure amendment language in your current contract that covers future group additions without requiring separate amendments. Some customers negotiate "free" affiliate adds up to a certain number per year.

Key Takeaways