On-Premise License Credits for Cloud ERP: Credit Types and Mechanics

Organizations moving from an on-premise SAP landscape to RISE have spent years investing in maintenance. That investment does not have to be written off entirely at the point of transition. Through the Cloud Extension Program, SAP makes three credit types available that can be applied against the new RISE contract.

The challenge is not the concept itself, it is the mechanics: Which credit type covers which contract position? How are credits applied against the Annual Contract Value? And why does the timing of your enrollment significantly affect the negotiable amount? These questions structure this article.

Three Credit Types: Different Origins, Different Applications

SAP distinguishes three credit types within the Cloud Extension Program. They differ not only in where they come from, but also in how they can be used.

Maintenance Credits originate from ongoing on-premise maintenance fees. Organizations paying annual maintenance on SAP ERP, on-premise S/4HANA, or associated add-ons have built up a basis for Maintenance Credits. These credits are typically applied against future on-premise maintenance invoices for as long as parallel operations continue.

Service Credits are designated for SAP Services SKUs. Customers who have purchased SAP Consulting services, SAP Activate packages, or Migration Advisory can apply a portion of previously paid service amounts as a credit balance. This is particularly relevant for organizations that commissioned SAP-side migration preparation in the years leading up to the transition decision.

Cloud Credits are the most direct form of credit application: they are applied against cloud contract invoices, specifically the RISE ACV. This reduces the actual payment amount during the early phases of the new contract.

The governance moment for credit types lies in correct allocation. Using Maintenance Credits against cloud invoices is not supported, and applying Cloud Credits against Service SKUs is equally out of scope. Knowing the boundaries between types enables deliberate planning rather than leaving allocation to be resolved during contract negotiations.

Eligibility: Who Qualifies and Through Which Program

Eligibility for credit application is open to existing SAP customers with active on-premise licenses on SAP ERP (BS7) or on-premise S/4HANA. The entry point is the Cloud Extension Program, which SAP provides for transitions to RISE and GROW.

Two conditions apply: First, an active customer relationship with SAP must exist, meaning a valid maintenance contract. Second, the transition path must go through RISE or GROW, not through a pure on-premise S/4HANA contract without a cloud component.

Customers who subscribed to a Transition Option or an early RISE contract before the end of 2025 may have a more favorable starting position, because the Transition Option surcharge does not apply to this group. That is a separate contract layer, however, not part of the credit application itself.

The critical point: eligibility is not a given that automatically appears in the RISE offer. It has to be actively enrolled with the SAP Account Executive. This is the first governance moment in this process.

How Credits Are Applied Against the ACV: The Mechanics

Cloud Credits are not applied as a blanket discount on the total contract amount. The application targets specific line items in the RISE contract, typically the Annual Contract Value during the ramp-up phase.

The ACV is the annual contract sum made up of FUE licensing, BTP entitlements, hyperscaler operations, and other services included in the package. Credits can reduce this amount during the first contract periods, but cannot eliminate it entirely. SAP typically sets a floor below which the ACV cannot be reduced further.

The amount of credits that can be applied is not fixed. It is the result of negotiation between the customer and the SAP Account Executive, influenced by several factors: How long has the customer relationship existed? What is the historical maintenance base? When was the transition announced? What contract term is being offered for RISE?

A concrete example in abstract terms: if the annual maintenance base has been EUR 500,000 and the proposed RISE ACV is EUR 600,000, Maintenance Credits can close part of that gap. The exact ratio is not published; it varies by customer profile and negotiation status.

The governance moment "costs" from the FinOptory framework applies directly here: ACV tracking, credit application, and ramp-up profile belong in the same contract governance logic. Organizations that do not actively map credits during the start-up phase do not lose them immediately, but the window for later corrections narrows.

Why Timing Affects Your Negotiating Position

The credit amount depends not only on the historical maintenance base, but also on when the transition is registered with the SAP Account Executive.

SAP has an interest in planning migrations well in advance. Customers who signal their intention early give SAP the planning certainty that can support a more favorable credit arrangement. Organizations that wait until shortly before the maintenance end date in 2027 negotiate under time pressure, which consistently weakens their position.

In addition, the Cloud Extension Program itself operates within a time window. It is not open-ended. Organizations planning a RISE migration for 2026 or 2027 should not defer credit enrollment to the final quarter before contract close. Early enrollment means more room to maneuver.

One more factor: SAP can reward commitments during negotiation. Customers who agree to a longer RISE term, say five years instead of three, typically have more flexibility on credit recognition.

None of this comes with guarantees; these are negotiation dynamics. The point is that the negotiating position at RISE entry is not a fixed value. It is shaped by timing and preparation.

What Is Not Automatically Credited

There are positions where credit application seems intuitive but is not automatically included in the Cloud Extension Program.

Add-on maintenance costs: Customers pay maintenance not only on the core SAP ERP system, but also on add-ons. Whether add-on maintenance generates credits depends on the specific add-on contract and its place within the maintenance bundle. Not all add-ons are eligible under the Cloud Extension Program. This is one of the positions that must be explicitly checked during preparation.

Application Management Services (AMS): Organizations purchasing external AMS services pay an implementation partner, not SAP directly. These payments do not generate credits within the SAP program. AMS remains a separate contract circle.

Third-party maintenance contracts: Some customers use independent maintenance providers alongside or instead of SAP Enterprise Support. Payments to third-party providers generate no SAP-side credits.

Ongoing consulting engagements: Service Credits refer to SAP-owned Services SKUs, not consulting engagements with system integrators.

Understanding these boundaries matters because they feed directly into the business case calculation for the RISE transition. Overestimating the credit base creates an unexpected gap during a later contract check. Knowing the limits allows alternatives to be factored in early.

Shelfware as a Complementary Factor in Credit Negotiations

Beyond the credit types in the Cloud Extension Program, there is another negotiating resource: unused on-premise licenses that have been paid for but are not productively deployed.

This shelfware can be brought into the negotiation in two ways. First, through targeted license surrender: formally returning unused usage rights before the RISE transition reduces the maintenance base and, with it, the surcharge under Extended Maintenance. Second, through negotiation itself: shelfware is an argument that strengthens your position by demonstrating that the paid base exceeds actual usage.

Shelfware utilization is its own topic, covered in depth in Cluster 6 of this pillar. For credit application, the key point is that shelfware and credits are separate mechanisms, but they work in the same direction. Bringing both to the table in a structured way creates a broader negotiating base.

What the Contract Text Must Say About Credits

Credits discussed during negotiations are only secure once they are anchored in the contract text. This sounds obvious; in practice, it is not always the case.

The contract text should explicitly address at least the following items related to credits:

The credit type (Maintenance, Service, or Cloud) and the corresponding reference value
The application period: in which contract periods is the credit deducted?
The expiration rule: which credits lapse if not used by a specific date?
The link to the ramp-up profile: how does credit drawdown align with the agreed FUE ramp-up curve?

The contract language around credits is not standardized. SAP uses different designations, and the actual effect depends on the precise wording in the contract annex. A negotiated but unclearly worded credit arrangement can behave differently from expectations when billing begins.

This is not an isolated case. It is a pattern that recurs in practice: investing in contract clarity before the signature is the most effective form of cost governance after the signature.

The Four Governance Moments in Credit Application

The FinOptory framework distinguishes four governance moments: usage, entitlements, infrastructure, and costs. For license credit application, the weight falls clearly on the governance moment "costs," but all four areas are indirectly involved.

Usage: The FUE baseline influences the ACV and, with it, the basis against which credits are applied. Organizations that complete a reliable FUE analysis before the RISE transition negotiate on the basis of verifiable numbers.

Entitlements: Role structure determines the FUE mix. Overly broad roles increase FUE demand and, consequently, the ACV. Cleaning up role design before contract close reduces the credit base needed to bring the ACV to an acceptable level.

Infrastructure: Hyperscaler choice affects the infrastructure component of the ACV. This portion is not reducible through credits. Credits typically apply only to the license and service components.

Costs: This is the core. ACV tracking, credit allocation, ramp-up profile, and maintenance demarcation during the dual-use period are tasks that continue after contract signature. They require a data structure that keeps these positions visible on an ongoing basis, not only at the point of close.

Conclusion: Credit Application Is Not Automatic

Existing maintenance investments are not lost in a RISE transition. Three credit types are available that can be applied against different contract components. The amount is not fixed; it is the outcome of negotiation.

What enables systematic governance: fully capturing the credit base before negotiation, deliberately choosing when to enroll, knowing the limits of what qualifies, and anchoring the result in the contract text.

Organizations that manage SAP contracts systematically after the signature recognize the governance moment "costs" not as a one-time negotiation task, but as an ongoing discipline. Credit application is the starting point; continuous ACV monitoring is the continuation.