Why S/4HANA Licensing Is Fundamentally Different From ECC

The transition from SAP ECC to SAP S/4HANA is not a simple upgrade. It is a complete reimagining of how SAP licenses, measures usage, and calculates fees. Organizations that treat S/4HANA licensing as an incremental shift from ECC invariably face nasty surprises during implementation and beyond.

In SAP ECC, licensing was relatively straightforward: you purchased user licences based on actual named users, module assignments, and usage patterns. The cost was predictable. With S/4HANA, SAP has introduced a measurement framework that is authorization-centric, cloud-first, and backward incompatible with ECC licensing models.

Here's the fundamental shift: SAP now licenses based on assigned authorizations in S/4HANA, not on named user counts or actual usage. This means that a single user with broad access to multiple modules now consumes licences across each of those modules simultaneously. On ECC, that user might have been licensed once. On S/4HANA, they consume multiple Professional Use licences—one per module. This alone can inflate licence costs by 20-35% during migration.

The second major shift is the Document Driven Licence Charge (DDLC), which creates a separate, metered licensing layer for indirect digital access. If you have suppliers accessing your purchase orders, customers accessing delivery documents, or partners viewing financial data through portals, you now owe SAP a charge per document processed. This is entirely new to most organizations.

Third, SAP's support cost structure has formalized at approximately 22% of net licence value annually. This is no longer optional or negotiable. Unlike ECC where maintenance might have been 15-20%, S/4HANA contracts lock in support as a direct line item from day one.

Understanding these three shifts—authorization-based measurement, DDLC, and fixed maintenance—is the foundation for any responsible S/4HANA licensing strategy.

Need expert guidance on your S/4HANA migration?

Download our free guide to avoiding the 12 most costly licensing mistakes.
Download Guide →

The S/4HANA Licensing Architecture: An Overview

SAP S/4HANA's licensing architecture consists of three primary components:

1. User Licence Types

S/4HANA defines four core user licence types, each with different authorization profiles and price points:

  • Professional Use (PU): Full-breadth access to S/4HANA modules. These are expensive, typically the baseline for power users, finance staff, procurement specialists, and supply chain planners. A single Professional User can access sales, purchasing, inventory, and finance simultaneously, consuming licences across all assigned modules.
  • Functional Use (FU): Module-specific access. A Functional User can access one or two modules in depth but has no cross-module rights. Functional Use is 30-50% cheaper than Professional Use and is ideal for specialists.
  • Productivity Use (PrU): Self-service and approval workflows. Employees who only approve purchase requisitions, submit expense reports, or view their payroll are licensed as Productivity Users. These are the cheapest licences—typically 10-15% of Professional Use cost.
  • Developer Use: Developers building custom functionality get a separate licence tier with access to development systems only.

The critical point: these are assigned based on the user's authorized roles in the system, not their actual job function. If an accountant has the technical authorization to access procurement even though they never use it, they consume a Functional Use licence for procurement. This is the authorization-based measurement trap.

2. Full User Equivalents (FUEs) in Cloud Editions

SAP's cloud editions (RISE with SAP, formerly RISE, now SAP Cloud ERP Private Edition) use a metric called Full User Equivalents (FUEs). Instead of counting individual user types separately, you purchase an allotment of FUEs, which can be deployed across Professional, Functional, and Productivity users in whatever combination fits your organization.

This gives you pricing flexibility during cloud implementations but makes annual true-ups a complex billing exercise. SAP audits your system monthly, and if your actual users exceed your contracted FUE allotment by 10% or more in any quarter, you owe an overage charge.

3. Digital Licenses (Indirect Access Layer)

S/4HANA introduces Digital Access, which meters indirect usage. Unlike Professional, Functional, and Productivity users who are named and assigned roles, Digital Access users are unmanaged—they access S/4HANA through portals, APIs, or integrations without roles in the system itself.

Digital Access is priced via the DDLC metric, which we'll explore in depth in the next section.

User Licence Types in S/4HANA: Professional, Functional, Productivity, Developer

Each licence type in S/4HANA aligns with a specific authorization profile. Understanding the boundary between them is critical for licensing optimization and audit defense.

Professional Use (PU) Licenses

A Professional User has broad authorization across one or more modules. In practice, a Professional User is:

  • A finance manager with access to general ledger, accounts payable, accounts receivable, and asset accounting
  • A supply chain manager with authorization in procurement, inventory management, and production planning
  • An order-to-cash manager with rights in sales, order fulfillment, and revenue recognition

Each module assignment incurs a separate Professional Use licence cost. A single user assigned to three modules costs three Professional Use licences. This is the core mechanism of S/4HANA's cost inflation.

Professional Use licences are not capped by user count. If you have 500 employees but 600 role assignments across the system due to job transitions, role matrix misalignment, or role creep, you owe SAP for 600 Professional User licences.

Functional Use (FU) Licenses

A Functional User has deep access to one specific module but minimal cross-module rights. Examples:

  • A warehouse worker with access only to Inventory Management and Material Documents
  • A recruiter with access only to Human Capital Management
  • A quality inspector with access only to Quality Management

Functional Use is 30-50% cheaper than Professional Use in most SAP price lists. Organizations that consolidate their user licensing strategy often downgrade users from Professional to Functional where possible, reducing licence count and total cost of ownership.

Productivity Use (PrU) Licenses

A Productivity User has no transactional access to S/4HANA data entry or reporting. They can only:

  • Approve requisitions in SAP Workflow
  • Review and approve leave requests in SuccessFactors
  • Submit expense reports
  • View dashboard content (read-only)

Productivity Use licences are often 10-15% of Professional Use cost. Every employee in your organization who touches S/4HANA in an approval or self-service capacity needs a Productivity User licence. Underestimating this population is a common audit finding.

Developer Use

Developers working on custom S/4HANA extensions, FIORI app development, and API integration need Developer Use licences. These licences are tied to development and test systems, not production, and are typically priced as a flat-rate tier rather than by module.

The mistake: organizations often license developers as Professional Users in production systems because they need to test. This inflates licence cost significantly. Best practice is to maintain strict system separation and license developers only in non-production.

"The biggest S/4HANA licensing mistake I see is role bloat. Organizations copy ECC user profiles directly into S/4HANA without cleaning up unused authorizations. This creates phantom Professional Users that don't exist in reality but still incur licence fees."

The Authorization-Based Measurement Trap

This is where most S/4HANA licensing disputes originate. SAP does not measure actual usage. It measures assigned authorizations.

During an audit, SAP runs a query that extracts every user role assignment from the system. If user JSMITH has roles SD_CHIEF (sales), MM_CHIEF (materials), and FI_CHIEF (finance), SAP counts three Professional User licences, regardless of whether JSMITH actually uses materials management.

SAP's audit methodology is binary: authorization present = licence owed. There is no allowance for "dormant" roles, "test" accounts, or "inactive" users still in the system. If the role exists and the user is active, you owe the licence fee.

Here's the financial impact: A typical ECC user migrated directly to S/4HANA with all their legacy roles intact often consumes 2-3x more licences than they did on ECC. We've defended organizations against SAP audit claims where a single user was billed for 8 different Professional Use licences because they inherited roles from previous jobs over a decade.

The Three-Part Audit Test

SAP's audit procedure follows this logic:

  1. Extract all active users from USERTAB. SAP queries the system's user table and counts every user with UFLAG = 0 (active).
  2. For each user, extract their assigned roles. SAP examines the USROLES table. Every role with valid authorization data counts as a separate licence.
  3. Map roles to user types and modules. SAP's license tools match each role to Professional, Functional, or Productivity type and multiply by the price list.

The defense strategy in disputed audits is role reconciliation and remediation. Organizations that remove dormant roles, consolidate overlapping role assignments, and rebuild user profiles from job-based requirements rather than legacy inheritance can often reduce their audit exposure by 15-25%.

Common Traps in Authorization-Based Measurement

  • Inherited roles: Users retain roles from previous positions that are never formally removed.
  • Template roles: New hires are assigned "full access" template roles that include modules they'll never use.
  • System accounts: Background job users, interface users, and technical service accounts are counted as full user licences.
  • Inactive users: Employees who have left or transitioned roles remain active in the system with all historical authorizations.
  • Overlapping role matrices: Organizations with poor role governance assign users to multiple overlapping roles, duplicating authorizations.

Prevention requires governance discipline. Many organizations now implement quarterly role reviews, automated role cleanup, and role-based governance workflows that flag unauthorized role assignment attempts before they hit the audit queue.

The DDLC: How Digital Access Works in S/4HANA

The Document Driven Licence Charge (DDLC) is SAP's metering framework for indirect usage in S/4HANA. It is fundamentally different from traditional user licensing and operates on a consumption basis.

What Is the DDLC?

The DDLC quantifies indirect access to S/4HANA data through unmanaged channels: B2B portals, customer self-service, supplier collaboration, partner networks, and API integrations. Unlike a Professional or Functional User who has roles in S/4HANA, DDLC users do not.

For example:

  • A supplier viewing their invoices in your supplier portal = DDLC usage
  • A customer checking their order status online = DDLC usage
  • A partner retrieving shipment data via API = DDLC usage
  • A service provider downloading delivery receipts = DDLC usage

SAP measures DDLC in document transactions. Each time a user accesses, views, or downloads a document in one of the nine DDLC categories, SAP counts it toward your annual DDLC allocation.

How DDLC Pricing Works

DDLC pricing is typically structured as an annual allocation. Your contract might specify:

  • 5 million DDLC transactions per year
  • Overage at $0.0012 per transaction if you exceed allocation

SAP's audit methodology counts every document access in the nine categories and checks your actual consumption against the contract. If you've consumed 6 million documents but only purchased 5 million, you owe 1 million × $0.0012 = $1,200 in overages, plus potential underpayment penalties.

The mechanics: SAP's audit tools read the S/4HANA document flow logs (CDCLS, CDCL1, etc.) and count every document access by non-named users. These numbers typically surprise organizations because portal usage and API consumption are often invisible to the business.

The Nine Document Categories That Trigger DDLC

SAP's DDLC framework covers nine distinct document types. Any indirect access to these documents incurs DDLC charges:

  1. Sales Orders: Customer order access, order status, pricing visibility
  2. Purchase Orders: Supplier order visibility, receipt confirmation, invoice matching
  3. Production/Process Orders: Manufacturing schedules, job tracking, capacity planning
  4. Service Entry Sheets: Service receipt, time tracking, labor visibility
  5. Material Documents: Goods movements, inventory transactions, warehouse actions
  6. Plant Maintenance Orders: Work order visibility, asset history, maintenance scheduling
  7. Quality Notifications: Defect tracking, quality inspections, compliance records
  8. Financial Documents: Invoice visibility, payment status, statement access
  9. Delivery Documents: Shipment tracking, proof of delivery, carrier integration

Each category is tracked separately, and overage pricing can vary. A typical S/4HANA contract allocates DDLC across all nine, but some contracts allow flexibility—you can use 80% of your allocation on sales orders if needed, then buy additional allocation for other categories.

The DAAP Amnesty

SAP introduced the Digital Access Adoption Programme (DAAP) to provide a grace period for pre-DAAP indirect usage. If your organization was already using indirect access channels before the DDLC framework was formally introduced, you may qualify for amnesty on historical usage.

However, DAAP amnesty is not automatic. You must declare your pre-DAAP usage and negotiate amnesty terms with SAP. Organizations that fail to do so risk discovery of years of undisclosed DDLC usage during audits.

The window for DAAP amnesty is closing. SAP's current audit methodology aggressively pursues DDLC underpayment, even for historical usage. If you have deployed portals, APIs, or B2B channels connected to S/4HANA, it is critical to assess your DDLC exposure now.

S/4HANA Migration and the Licence Baseline Reset

This is the most critical and often misunderstood aspect of S/4HANA licensing. When you migrate from SAP ECC to S/4HANA, your licence baseline does not carry forward unchanged. SAP treats the migration as a contract reset opportunity.

Why the Baseline Changes

There are four fundamental reasons:

  • Authorization architecture: S/4HANA's authorization structure is completely rebuilt. Roles are different, modules are reorganized, and the mapping from ECC to S/4HANA is many-to-many, not one-to-one. Your ECC licence baseline cannot directly translate.
  • Organizational change: Most S/4HANA migrations include business process re-engineering. Users who had certain access in ECC often get different roles post-migration. What looked like optimization can actually inflate licence cost if new roles are broader than old ones.
  • Module consolidation: S/4HANA consolidates ECC modules (MM, SD, PP, FI/CO) into a single digital core. Users who were licensed separately for different modules on ECC now access an integrated data model. SAP's position is that you need broader licences.
  • Digital access new requirement: ECC had limited indirect access scenarios. S/4HANA assumes you'll deploy portals, APIs, and integrations. This adds DDLC to your licence baseline as a new cost line.

The 35% Cost Inflation Reality

Organizations we've advised report an average 35% increase in licence cost during S/4HANA migration, assuming migration of the same user base on equivalent terms. Here's why:

  • Authorization bloat during migration: 15-20% increase from inherited roles and poor role cleanup
  • DDLC new baseline: 8-12% increase as you license new indirect access channels
  • Module reassignment optimizations: 2-5% increase as broader user profiles require higher licence tiers
  • Support cost formalization: 22% annual maintenance (vs. 15% on ECC) = 7% effective increase in total cost

This is not a coincidence. SAP's licensing strategy for S/4HANA is deliberately engineered to expand the addressable market per customer. The migration is the inflection point where SAP can reset baselines without customer resistance (because "it's a new system").

Contract Conversion vs Product Conversion: Which Path to Take

SAP offers two pathways from ECC to S/4HANA, and they have radically different licensing implications.

Contract Conversion Path

In a Contract Conversion, SAP allows you to migrate your ECC licence agreements to S/4HANA with your existing user count and support terms preserved. Your ECC licence baseline becomes the floor for S/4HANA.

Advantages:

  • Your existing licence count does not increase automatically
  • Your support rate remains at ECC-era levels (~15-17%) rather than S/4HANA standard (22%)
  • You maintain volume discount tiers if you have them
  • No formal contract reset; terms carry forward

Disadvantages:

  • You cannot benefit from S/4HANA's more granular user types (Productivity Use) without renegotiating
  • DDLC is still added as a new line item; the conversion does not exclude it
  • You are locked into your ECC user profile; any net growth over migration requires amendment

Product Conversion Path

In a Product Conversion, you retire your ECC agreement entirely and sign a new S/4HANA contract. SAP re-establishes your licence baseline from scratch, typically using either:

  • Your authorized role count in the target S/4HANA environment
  • A new requirements analysis based on your anticipated post-migration user population

Advantages:

  • You get the benefit of S/4HANA's cheaper Productivity and Functional user tiers
  • SAP can restructure your agreement for volume discounts if your user base has grown
  • RISE with SAP offerings (cloud) may become available, with different economics
  • Maintenance rates can be negotiated as part of the new contract

Disadvantages:

  • Your baseline can increase 20-40% based on role recount and module realignment
  • SAP will pressure you toward their list prices; legacy discounts do not carry forward automatically
  • You lose lock-in value from your existing agreement

Which Path Should You Choose?

The decision hinges on three factors:

  1. Your ECC licence discount history: If you have deep legacy discounts (40%+ off list), Contract Conversion preserves that value. If you're at list price or near it, Product Conversion is less painful.
  2. Your anticipated user growth: If you're not adding users, Contract Conversion locks in your baseline. If you're growing 10%+ annually, Product Conversion may be cheaper overall because you can negotiate volume discounts upfront.
  3. Your desire for cloud migration: Contract Conversion is on-premise only. If you want RISE with SAP (SAP Cloud ERP Private Edition), you must do Product Conversion because SAP no longer offers RISE on converted ECC agreements.

Our recommendation: Model both scenarios. Calculate the five-year total cost of ownership for each path, including maintenance escalations, DDLC growth, and any planned user additions. The path that yields lower TCO is your answer.

RISE with SAP (SAP Cloud ERP Private Edition): What's In and What's Not

RISE with SAP was rebranded to SAP Cloud ERP Private Edition in mid-2025, but the economics and inclusions remain largely consistent. This is SAP's primary cloud offering for S/4HANA, and it represents a fundamental shift in how you license and deploy.

The RISE/Cloud ERP Private Edition Model

Under RISE (now Cloud ERP Private Edition), you do not license users per se. Instead, you purchase a "cloud native" package that includes:

  • S/4HANA software: Cloud-hosted, fully managed, with automatic patch and upgrade cycles
  • Infrastructure provisioning: Compute, storage, backup, disaster recovery
  • Full User Equivalents (FUEs): An allotment of user capacity (not tied to specific user types) that you deploy across your organization
  • Core apps: Analytics, Fiori, extensibility frameworks, and integrations
  • Standard support: Included in the contract (not priced separately as 22%)

Pricing is typically structured as a 3-5 year contract with fixed annual fees. A typical RISE contract for a 500-person organization might cost $2.5-4M annually, all-inclusive.

Critical RISE Inclusions

  • S/4HANA Cloud Enterprise Edition
  • Up to the contracted FUE count in production (e.g., 300 FUEs)
  • One test environment with 50% of production FUEs
  • SAP Analytics Cloud (embedded analytics)
  • FIORI user experience layer
  • Core SuccessFactors integration (limited)
  • Standard security and compliance certifications
  • Basic integrations via SAP Integration Suite (limited capacity)

What RISE Does NOT Include

This is where organizations get surprised:

  • Advanced analytics: Embedded analytics are included, but SAP Analytics Cloud premium features, predictive analytics, and embedded Datasphere cost extra
  • SuccessFactors: Only basic HR integration. Full SuccessFactors licensing is separate (PEPM pricing model)
  • Ariba: Procurement network access is not included. Ariba subscription is sold separately
  • Extended Warehouse Management (EWM): RISE includes basic inventory management but not advanced WM; EWM is an add-on module priced separately
  • Advanced Supply Chain Planning: Core planning is included, but demand-sensing and multi-tier planning require SAP IBP subscription
  • Managed Services: RISE includes infrastructure managed services but not application managed services (AMO). If you want SAP to manage your custom code, you pay for that separately.
  • Third-party software: Any non-SAP integrations (MuleSoft, Informatica, etc.) are billed separately
  • DDLC: You still pay DDLC charges if you have indirect access; they are not included in RISE pricing
  • Business process services: Consulting, implementation, and optimization are sold as professional services, not included in RISE

The RISE model is attractive for organizations seeking simplicity and fixed costs, but the scope creep from excluded modules and add-ons often inflates the total cost significantly. We've seen organizations sign a $3M/year RISE agreement only to discover they need another $1.2M in annual add-ons for SuccessFactors PEPM, Ariba, EWM, and integration services.

RISE Contract Terms and True-Ups

RISE contracts are typically 3-5 years. You commit to a fixed FUE count for the term. SAP monitors your actual users quarterly.

If your quarterly average exceeds your contracted FUEs by 10% or more, SAP requires an amendment. The amendment locks in an increased FUE count and corresponding price increase for the remainder of the contract. You cannot scale down; only up.

This creates budget risk. An organization that doesn't carefully manage their user population can face a mid-contract true-up that adds $500K+ in annual cost.

SAP BTP in S/4HANA Context

SAP Business Technology Platform (BTP) is SAP's cloud development and integration framework. In an S/4HANA context, BTP serves two critical functions:

1. Integration and Data Connectivity

BTP provides the middleware layer that connects S/4HANA to your other systems. SAP Integration Suite, running on BTP, handles API management, event processing, and workflow orchestration. In a RISE contract, you typically get a basic allocation of BTP integration capacity (e.g., 500 API calls per day, 10 integrations). Beyond that, you pay per capacity unit.

The licensing surprise: Organizations often underestimate their integration needs. APIs for data sync, workflow, and real-time reporting can exceed your allocation within 3-6 months post-go-live, at which point you owe additional BTP charges.

2. Custom App Development

If you build custom applications on BTP (CAP, FIORI, Extensibility), you need BTP developer capacity. This is separate from your S/4HANA user licensing. SAP charges for:

  • Developer runtime (compute hours)
  • Database capacity (data stored outside S/4HANA)
  • BTP security and identity management services

A typical custom app can cost $50-150K annually in BTP infrastructure, depending on usage and data volume.

BTP as a Cost Multiplier

During S/4HANA implementations, BTP costs often represent 15-20% of total software cost over a three-year period. Organizations that assume "it's all in RISE" are surprised when integration and custom development bills arrive.

The 22% Maintenance Cost in S/4HANA

SAP's support cost for S/4HANA is standardized at approximately 22% of net licence value annually. This is a significant increase from ECC (typically 15-17%) and is non-negotiable in most circumstances.

What 22% Covers

  • Software patches and security updates
  • Defect resolution and bug fixes
  • Phone and email support with specified SLA
  • Access to SAP's knowledge base and forums
  • Incident management and escalation

What 22% Does NOT Cover

  • Implementation consulting (new features, system design)
  • Custom code development
  • Performance tuning
  • Data migration
  • Training

Maintenance Cost Trajectory

Once you stop adding new users, maintenance cost becomes your single largest annual SAP expense. On a typical $10M licence value, you're paying $2.2M annually just for support. Over 10 years, that's $22M.

SAP's fiscal year ends December 31. All annual support invoices are due on January 1 of each year for the following 12 months, creating a significant cash flow impact in Q1.

Organizations often miss the opportunity to negotiate maintenance. SAP will not advertise it, but there are limited circumstances where support rates can be adjusted:

  • Major contract amendments (adding a new module, significant user growth) can trigger a renegotiation of support terms
  • Third-party maintenance providers (HCL, Rimini Street, Accenture) offer managed support plans at 40-60% of SAP list price; these can be negotiated into your ECC-to-S/4HANA transition
  • Multi-year prepayment commitments occasionally yield a 2-3% discount on support

Common S/4HANA Licensing Mistakes

Based on 80+ SAP licensing disputes we've defended, here are the mistakes that cost organizations the most:

Mistake 1: Role Bloat During Migration

The single most costly error. Organizations copy ECC user profiles wholesale into S/4HANA without role cleanup. Users inherit 10+ years of accumulated authorizations, most of which they don't need. Result: 15-25% licence cost inflation on day one. Prevention: Role rebuild from scratch based on job-based requirements, not legacy inheritance.

Mistake 2: Underestimating DDLC Usage

Portal usage, API calls, and B2B integrations grow exponentially post-go-live. Organizations that allocate minimal DDLC on contract signature face mid-year overages and surprise invoices. Prevention: Audit your portal and API usage on ECC, extrapolate to S/4HANA scope, and contract for 120% of projected usage to avoid overages.

Mistake 3: Ignoring Maintenance Cost Growth

Organizations budget for licence cost but forget that maintenance also grows. If you add 50 users post-migration, your licence cost grows 5%, but your maintenance cost also grows 5% ($110K to $116K annually). Prevention: Model maintenance cost in your financial projections; it's not optional.

Mistake 4: Productivity User Undercount

S/4HANA introduces Productivity Users as a new, cheap licence type. Organizations often forget to count employees who access self-service workflows, approvals, and expense reports. The audit catches 50-100 unlicensed Productivity Users, resulting in retroactive fees. Prevention: Conduct a comprehensive user population analysis; count every employee who touches S/4HANA in any capacity.

Mistake 5: RISE Add-On Shock

Organizations sign a RISE agreement assuming all modules and integrations are included, only to discover SuccessFactors, Ariba, Advanced WM, and integration services are extra. Prevention: Detailed scope document before RISE negotiation; explicitly list every module and service that you need and confirm it's either included or priced separately.

Mistake 6: Forgetting System Accounts

Background jobs, interface users, RFC connections, and technical service accounts are all counted in your user licence baseline. A single organization might have 30-50 system accounts. Prevention: Segregate system accounts into a dedicated user group; negotiate a flat fee for system accounts instead of per-user licensing.

Mistake 7: Not Addressing Pre-DAAP DDLC Usage

If you've had indirect access channels (portals, APIs) on ECC, you likely owe DDLC retroactively under SAP's audit rules. SAP's position is that DDLC always applied; you just didn't know about it. Prevention: Self-declare your pre-DAAP usage and negotiate amnesty before SAP discovers it in an audit.

Mistake 8: Choosing the Wrong Contract Conversion Path

Organizations often default to Contract Conversion or Product Conversion without modeling the TCO. A 10% wrong choice can cost $1M+ over five years. Prevention: Model both paths; calculate the true cost including user growth, DDLC, and maintenance escalations.

Eight Recommendations for CIOs and SAM Teams

If you're leading an S/4HANA migration or managing SAP licensing post-go-live, here are the eight actions that will protect your organization:

1. Clean Your Role Library Before Migration

Do not copy ECC roles into S/4HANA 1:1. Audit every role; eliminate obsolete roles; consolidate overlapping roles. A clean role library can reduce your licence cost by 15-20% from day one. Budget 60-90 days for this activity during implementation.

2. Implement Quarterly Role Governance Reviews

After go-live, lock down role management. Implement a quarterly process where business owners review their users' role assignments. Deactivate unused roles, remove orphaned authorizations, and prevent role creep. This prevents 5-10% licence cost growth annually.

3. Segregate System Accounts and Negotiate Flat Fees

SAP will count every system account as a user licence. Instead of accepting per-user charges, negotiate a flat annual system account fee with SAP. This typically saves 20-30% on system account costs.

4. Audit Your Portal and API Usage; Contract Conservatively on DDLC

Identify every portal, API, and integration channel that touches S/4HANA. Estimate document traffic conservatively (add 20-30% buffer). Contract for that amount. DDLC overages are expensive and often discovered in audits; it's cheaper to over-allocate upfront.

5. Negotiate Maintenance Terms Aggressively

The 22% standard is not immutable. For large organizations (500+ users), third-party support providers can deliver equivalent SLAs for 40-60% of SAP list price. Include this in your contract negotiation. Even a 2-3% discount saves $220K annually on a $10M licence value.

6. Model Both Contract and Product Conversion Paths; Choose Based on TCO

Do not default to Contract Conversion just because it sounds simpler. Model the five-year cost of both paths, including maintenance escalations, user growth, DDLC, and BTP costs. Choose the path with lowest TCO, not simplicity.

7. If You Choose RISE, Scope Every Module and Add-On Explicitly

Create a detailed scope document that lists every module, service, and integration you need. For each, explicitly state whether it's included in RISE or priced separately. This prevents surprise bills post-signature.

8. Self-Declare Pre-DAAP Usage and Negotiate Amnesty

If you have indirect access on your current system, SAP will find it in an audit. Instead, self-declare your pre-DAAP usage and negotiate amnesty terms. This is always cheaper than being discovered.

Conclusion

SAP S/4HANA licensing is complex, expensive, and deliberately engineered to expand SAP's revenue per customer. The path from ECC to S/4HANA is not a straightforward upgrade; it's a contract reset opportunity where SAP can re-establish your baseline at higher cost.

The three most critical points to remember:

  1. Authorization-based measurement means your licence baseline will increase. A 35% cost increase during migration is not unusual. This is built into SAP's S/4HANA licensing architecture.
  2. DDLC is a new, metered cost layer that can exceed your licence cost if not managed. Indirect access to nine document categories creates ongoing consumption charges that are audited quarterly.
  3. Maintenance cost at 22% is substantial and grows with your user base. Over ten years, maintenance is often 2-3x your initial licence cost. This must be included in every financial model.

Organizations that approach S/4HANA licensing strategically—with role cleanup, DDLC planning, governance discipline, and aggressive contract negotiation—can mitigate 10-15% of the natural cost inflation. Those that migrate without a licensing strategy face 35-50% cost increases and ongoing audit exposure.

The single most important action you can take now is to model your baseline, audit your current system's usage patterns (roles, users, portals, APIs), and design your S/4HANA licensing strategy before you commit to a migration path.