FAQ: SAP Contract Governance

SAP Contract Governance is the ongoing, systematic governance of SAP contracts after signature, across the full contract term and across all SAP product types. It connects the contractual, operational, and commercial perspectives in one continuous governance model. The objective is for organizations to maintain a complete view of their SAP obligations, usage rights, and cost development at any point in time, and to be able to act proactively on that basis.

Classic SAP license management focuses on measuring and classifying users, primarily in on-premise environments and typically on an annual cadence. SAP Contract Governance goes further: it establishes the connection between the contractual basis, actual consumption, and financial planning across the full contract term in a continuous process. In cloud contract models such as RISE, license management alone is not sufficient to manage the complexity of credit mechanics, consumption logic, and clause risks.

A start twelve to eighteen months before the planned contract end date is recommended (sources: saplicensingexperts.com, saprisenegotiations.com). That lead time is needed to fully compile consumption data, analyze clauses, define negotiating objectives, and align internal stakeholders before SAP presents a renewal offer. Starting later means negotiating under time pressure and from a weaker data position.

If the termination window before contract end is missed, the contract renews automatically on existing terms, typically for another year. In RISE contracts with multi-year terms, the termination window can fall well before the nominal contract end date. The specific deadline is defined in the contract and should be tracked proactively (sources: saprisenegotiations.com, saplicensingexperts.com).

Full Use Equivalents (FUE) are the unit of measure for user licensing in S/4HANA Cloud under RISE with SAP. An Advanced user corresponds to a higher FUE equivalent than a Core user or Self-Service user. Classification is based on authorizations: a user holding an authorization corresponding to an Advanced license type is counted as Advanced, regardless of whether that authorization is actually used. Overly broad authorization roles therefore have a direct impact on license costs.

BTP credits under the CPEA or BTPEA model typically expire at the end of the contract year if unused. AI Units (PUPM: Per User Per Month) typically expire monthly. Governance responses include: ongoing monitoring of credit consumption at the service level, early identification of credit surpluses, accelerating planned BTP projects before year-end, and where appropriate, using unused credits for internal development or test purposes. Proactive steering requires a monthly consumption view, not an annual one (sources: SAP Help Portal, SAP Community Blogs, saplicensingexperts.com).

Digital Access is the SAP licensing model for scenarios where third-party systems access SAP data or trigger SAP transactions without direct human user involvement. CRM systems, e-commerce platforms, and IoT interfaces can trigger additional licensing obligations depending on the architecture and contract scope. In RISE contracts, certain Digital Access scenarios are included in standard scope; others are not. Documenting the integration landscape and continuously reviewing it for license relevance is a governance task that remains relevant throughout the contract term, not only at initial licensing (sources: redresscompliance.com, saprisenegotiations.com).

RISE with SAP guarantees a standard system availability of 99.7 percent. The common enterprise cloud industry standard is 99.9 percent. The difference corresponds to approximately 17 hours of tolerable annual downtime at 99.7 percent, compared to approximately 8.7 hours at 99.9 percent. For organizations with production-critical systems on RISE, this is a relevant negotiation argument. SLA upgrades are available in some contract configurations but are not a standard offering (sources: SAP Help Portal, saprisenegotiations.com, The Register).

In acquisitions, mergers, or carve-outs, existing SAP contracts are directly affected. Affiliate licensing clauses define which affiliated entities are permitted to use SAP under the existing contract. Acquired companies can bring existing license issues with them. A contract due diligence review of the SAP contract landscape before closing is an established best practice to identify compliance exposure from the acquired portfolio (sources: redresscompliance.com, saprisenegotiations.com).

The Annual Contract Value (ACV) is the annual contract value of a SAP agreement. It is the basis for many contract-relevant calculations, including percentage price adjustments (CPI clause), overage fees, and governance pricing models. The Total Contract Value (TCV) is the aggregate contract value over the full term. For a five-year RISE contract, the TCV equals five times the ACV plus planned price adjustments. Both figures are relevant for budget planning and renewal preparation.

Reactive governance acts when SAP takes a step: renewal offer, invoicing, measurement result. The internal team responds without a prepared data foundation. Proactive governance builds a data foundation on an ongoing basis and acts ahead of events: consumption data is evaluated monthly, renewal preparation begins twelve to eighteen months in advance, and clause risks are understood before they take effect. The difference lies not in expertise but in structure: organizations with a continuous governance foundation have a better starting position at every one of these governance moments.

Governance offerings in the market are structured differently. FinOptory prices the Self-Service model ("You steer.") at 1.5 percent of the ACV of contracts under management per year. The Managed Service model ("We steer. You decide.") is priced at 2.2 percent of ACV per year. The entry point is the Contract Check at a fixed price of EUR 7,900 (four weeks, one contract). Fifty percent of the Contract Check fee is creditable toward the first year of a Self-Service or Managed Service engagement. Floor and cap for ongoing governance engagements are agreed individually.

Both are possible, and the answer depends on internal capacity and portfolio complexity. Internally built governance works well when dedicated capacity is available, when the organization wants to develop SAP contract knowledge in-house, and when a clear governance process with defined responsibilities can be established. External support is appropriate when the portfolio is more complex than the available capacity can address, when a renewal is imminent, or when an M&A situation has sharply increased complexity. The two approaches are not mutually exclusive: starting with external support can be the starting point for building internal competence over time.

Pre-signature consulting is designed for the contract conclusion. It ends with the signature. Post-signature governance begins after the signature and extends across the full contract term. It steers usage, authorizations, infrastructure, and cost on an ongoing basis, and prepares the renewal on the basis of a reliable data foundation. Both disciplines complement each other; neither replaces the other.

Governance moments arise monthly, quarterly, and annually. Monthly: PCE Metering evaluation, BTP credit consumption, invoice reconciliation. Quarterly: overall contract performance, budget perspective. Annually: full inventory, assessment of all upcoming renewals. Situational governance moments also arise from organizational changes, new product types, or M&A events.

Yes, when dedicated capacity is available and the organization wants to develop SAP contract knowledge in-house. The Self-Service model ("You steer.") is designed precisely for that. The platform provides the data foundation; the internal team governs. Organizations that find portfolio complexity exceeding internal capacity can switch to the Managed Service model at any time, without data loss.

The structured entry point is the Contract Check: one contract, four weeks, EUR 7,900 fixed price. It clarifies the starting position, identifies governance moments, and gives an assessment of which follow-on model fits the organization. Particularly well-suited when a renewal is due within the next twenty-four months or when contract responsibility has been newly assumed.

- Hub: SAP Contract Governance: Governing SAP Contracts After Signature - Understanding Governance Moments in SAP Contracts - SAP Contract Governance Across All Nine Product Types

Notice periods are contract-specific and documented in the Order Form and its Schedules. SAP contract specialists describe a typical range of 90 to 180 days before the contract end date, as referenced by sources including saplicensingexperts.com and saprisenegotiations.com. Your own contract wording is the only authoritative reference. Published sources provide orientation, not a substitute for a contractual review.

A termination notice that arrives after the contractually specified deadline is generally ineffective and triggers the automatic renewal. The renewal period is defined in the contract and is often one full year. Any further termination before the new end date is again subject to the notice requirements in the contract.

Yes. SAP RISE contracts typically include a written form requirement for all contractually significant communications, which includes termination notices. The required form, addressee, and delivery method are specified in the Order Form or the Schedules. Email may be sufficient if the contract explicitly permits it, but receipt should be confirmed in writing and retained with a timestamp.

Yes. This is a recognised approach in complex contract negotiations. Timely written notice creates negotiating leverage without necessarily ending the commercial relationship. Parallel discussions can continue up to the contract end date. The specific contractual conditions of your agreement should be reviewed carefully before adopting this approach.

An AI Unit is SAP's consumption-based metering unit for Business AI services. Customers purchase a prepaid annual allowance. Every AI service call, whether a Joule conversation, an embedded Finance capability, or an agent execution, consumes a defined number of AI Units, published by SAP in conversion factors per service. Unused AI Units expire at the end of the contract year unless an explicit rollover clause is agreed in the Order Form (source: SAP Help Portal, Metering and Pricing).

PUPM packages (Per-User-per-Month) assign each user a fixed monthly request allowance via SAP Identity Service. Unused allowances can be redirected within a package to other users in the same package; this is the permitted pooling. Cross-package pooling is not available. All allowances in a PUPM package expire at month-end without carryover (source: SAP Learning, PUPM Pricing Model).

A RISE or SAP Cloud ERP Private contract typically includes certain embedded AI features such as Predictive Accounting and Intelligent AP Automation, fixed transaction quotas, and a Joule view-only access with limited conversation sessions. This base scope is not adequate for production AI adoption across larger user populations. Joule Power User Seats, additional AI Units, and extended capability packages are add-ons (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

AI Units are the consumption unit for Business AI services such as Joule and AI Core. Capacity Units (CU) are the consumption unit for BTP platform services such as Integration Suite, application development, and database services. BDC Credits measure data volume and data products in the Business Data Cloud. The three pools are not interchangeable, are measured separately, and are procured separately (source: SAP Help Portal).

SAP discontinued RISE with SAP Premium Plus in June 2025. The former top tier RISE was renamed SAP Cloud ERP Private. AI capabilities previously included in Premium Plus were partly elevated into Cloud ERP Private and partly repositioned as separate add-ons. In particular, Embedded AI Units are no longer automatically included in Cloud ERP Private but must be separately acquired. Existing customers with old Premium Plus contracts should assess what changed in the repackaging (sources: Redress Compliance, CIO Magazine).

The aggregation trap refers to the SAP standard contract clause by which AI consumption across all system environments, meaning development, test, and production, is collectively counted against the monthly allowance. Organizations running active AI features in non-production environments can generate unexpectedly high consumption. A dev/test exclusion from AI Unit counting is negotiable and should be reviewed at the next contract negotiation or renewal (source: SAP Licensing Experts).

The Generative AI Hub provides access to foundation models from multiple providers, including SAP-proprietary models for ABAP development and process contexts as well as models from major external providers. Available models vary by region, contract version, and SAP release cycle. SAP updates the model portfolio on a rolling basis. For governance purposes, the current model list should be drawn from SAP documentation, not from marketing material (source: SAP Help Portal, Generative AI Hub).

A Joule Skill is a deterministic, predefined operation that executes a single action. A Joule Agent is an autonomous system that orchestrates multiple skills, develops a plan, and executes it independently. The consumption difference is substantial: agents consume significantly more AI Units in complex multi-step plans than individual skill calls. This distinction is central for budget planning and sizing (source: SAP Learning, Introducing Joule Agents).

On 2 August 2026, the full effect of the EU AI Act for high-risk AI systems takes effect. Organizations operating AI systems in high-risk categories in production must from this date be able to demonstrate a completed conformity assessment, full technical documentation, an established risk management system, defined human oversight mechanisms, and active logging and monitoring. As the deployer of these systems, the responsibility rests with the customer, not with SAP as the provider (source: European Commission, SAP Trust Center).

According to SAP standard AI Terms, customer business data is not used to train SAP-proprietary models. This commitment is anchored in the AI Terms of the SAP cloud contract. For external foundation models offered via the Generative AI Hub, the contract between the model provider and SAP applies. For sensitive data categories, an explicit review of the data protection clauses of the respective model provider is advisable (source: SAP Trust Center, Data Sovereignty).

SAP does not publish a public AI Unit price list. The effective per-unit price depends on the chosen procurement path, contract size, and individually negotiated conditions. As an orientation: standalone BTP contracts typically carry the highest per-unit price. RISE or Cloud ERP bundle contracts typically offer more favorable conditions. The SAP AI Pricing Estimator in the Discovery Centre provides volume estimates, not euro amounts. Actual costs emerge only from the per-unit price fixed in the Order Form (source: SAP Pricing Page, SAP Licensing Experts).

For production AI use cases in regulated areas or with high-risk classification under the EU AI Act, a dedicated governance capability is required. Without structured inventory, classification, and observability of the AI systems deployed, neither compliance requirements can be met nor can consumption and cost development be steered in a plannable way. The SAP AI Agent Hub (GA Q3 2026) provides a technical foundation. The organizational anchoring of the governance capability rests with the customer.

No. The expiration rule applies specifically to the monthly request quota within PUPM packages. The central annual AI unit quota (the prepaid volume from the contract) expires at year-end, not monthly. Both pools follow their own rules and should be observed separately. Source: SAP Help Portal, Metering and Pricing for SAP AI Core.

No. A rollover of PUPM requests across month boundaries is not provided for in the standard. Within the current month, pooling is possible within a package, meaning active users can draw requests allocated to other package members that have not yet been used. At month-end, unused volume expires permanently.

The first governance moment is the consumption review: how much of the PUPM package volume was utilised per package? The second governance moment is user assignment: are all assigned users still active and correctly mapped to the right packages? The third governance moment is the overage review: has any package exceeded its monthly quota and drawn additional AI units from the annual quota? These three checkpoints can be consolidated into a monthly routine and form the basis for a substantiated sizing decision in the next contract period. Source: SAP Learning, Analyzing the SAP Per-User-Per-Month Pricing Model.

The Contract Manager tracks package assignments and validates that PUPM structures reflect the current contract scope. Procurement uses consumption data to prepare the sizing recommendation for the next renewal. Controlling maps monthly PUPM costs to departmental cost centres and flags budget deviations early. The Executive reviews the consolidated picture at renewal: is the current package portfolio aligned with planned AI deployment across lines of business?

Yes. The EU AI Act distinguishes between provider and deployer. SAP is the provider of the AI systems and carries corresponding obligations, which SAP demonstrates through its certifications (ISO/IEC 42001, SOC 2). The customer, as deployer, is responsible for the concrete operation: use case classification, conformity assessment, human oversight, logging and monitoring. These deployer obligations cannot be delegated to SAP (source: European Commission, SAP Trust Center).

For every productive AI use case in a high-risk category, the following elements should be in place by 2 August 2026: a documented classification of the use case, a completed conformity assessment, an established risk management system, defined human oversight mechanisms, and active logging and monitoring. Inventorying all AI use cases in operation is the most practical first step (source: Secure Privacy EU AI Act 2026 Compliance).

The AI Agent Hub addresses several EU AI Act requirements directly: inventory of all agents (registration obligation), observability with logging (Article 12), policy management for human oversight, and verification for controlled operation. It is a technical foundation, but does not replace the customer's organizational governance function. Use case classification, conformity assessment, and sector-specific reviews remain with the customer (source: SAP Insider Sapphire 2026 AI Agent Guardrails).

The first governance moment is use case inventorying: which AI features in SAP Business AI are being used in production? Which of these potentially fall under a high-risk category of the EU AI Act? This foundation determines the entire compliance effort. Without it, a sound assessment of the organization's own obligations is not possible. For SAP customers with complex contract portfolios, this step is closely linked to contract analysis: which AI capabilities are contractually licensed, and which of those are actually in productive use?

- Hub Pillar 2: SAP Business AI: Licensing, Consumption, and Governance - Cluster 4: Joule, Skills, Agents and Foundation Models

Yes. The EU AI Act addresses the deployer, meaning the organisation that brings an AI system into operation and uses it. Whether SAP acts as technical processor or controller is a data protection question and is separate from AI Act liability. As deployer, you remain responsible for risk classification, human oversight, and documentation.

No. SAP's certification demonstrates SAP's provider-side processes. Your deployer obligations, including use-case classification, technical documentation, and human oversight at the application level, must be documented and evidenced by you. SAP's Trust Center documents are a useful starting point for system descriptions, but they do not substitute for your own governance documentation.

The EU AI Act provides for fines of up to 30 million euros or 6 percent of global annual turnover for high-risk systems without complete documentation. More significant than the fine level: supervisory authorities can prohibit use of a non-compliant system. Organisations that can present a structured, traceable documentation register by August 2026 are in a substantially stronger position than those with no governance layer in place.

SAP's AI Agent Hub (Q3 2026, based on LeanIX) provides discovery, verification, and observability for AI agents and is designed primarily as a compliance instrument. BTP audit logs are configurable and cover the logging obligation at infrastructure level. For application-level documentation and the risk management system, there is no SAP standard tool. That responsibility lies with the customer.

A Joule Skill is a deterministic, predefined single action: predictable consumption, limited risk. A Joule Agent is an autonomous system that orchestrates multiple Skills and plans independently. The consumption difference is substantial: agents consume three to twenty times the AI Units compared to pure copilot deployments, based on observations from practice (source: SAP Licensing Experts). This distinction should be on the agenda in every AI Unit sizing discussion.

The Generative AI Hub provides access to Foundation Models from multiple providers, including SAP-proprietary models such as SAP-ABAP-1 and SAP-RPT-1 as well as models from major external providers. SAP abstracts the model API, so no direct contract with the model vendor is required. The right model depends on the use case: SAP-proprietary models are optimized for SAP-specific tasks and carry lower token rates. External models provide more flexibility for generic tasks (source: SAP Help Portal, Generative AI Hub).

The Model Context Protocol is an open standard that can connect SAP agents and external AI toolchains. SAP has supported MCP since Q1 2026. Contractually relevant: the SAP API Policy v4/2026 does not permit autonomous third-party AI agents at SAP APIs. Third-party components may provide Skills but may not act independently. Organizations planning hybrid architectures should have this boundary clarified in the Order Form.

SAP provides free design-time access to Joule Studio through end of 2026 under fair-use conditions. This covers the development environment, not production operations. Runtime licenses for customer-built agents running in production must be procured separately. Organizations building agents in Joule Studio during 2026 should factor runtime costs for 2027 into budget planning early.

AI Unit entitlements purchased in the classic prepaid model expire at the end of the contract year. PUPM request entitlements expire monthly. That is a shorter cycle with more frequent expiry events. Organizations purchasing PUPM packages while ramping up adoption gradually lose budget not once a year but every month.

No. Packages are solution-area-specific. Finance packages cover Finance capabilities, Spend Management packages cover Procurement capabilities. Cross-package pooling is not part of the model. A user who requires both areas needs two separate packages.

Consumption beyond the package entitlement is drawn from the organization's central AI Unit pool. If sufficient entitlement is not available there, overage charges apply. This is an additional reason to monitor package utilization and the central AI Unit pool together. A governance moment that affects Contract Managers and Controlling alike.

The assignment is technically unlimited. The commercial boundary lies in the request pool: the more users share a package, the lower the average share available per user. Package dimensioning should therefore be based on expected usage volume, not solely on the number of potential users.

SAP Business AI is the umbrella brand for all AI functions in the SAP ecosystem, consisting of three layers: Context Layer (AI Foundation, Knowledge Graph, foundation models), Build Layer (Joule Studio 2.0 for customer-built agents), and Governance Layer (SAP AI Agent Hub for policy and observability). Joule sits on top as the shared frontend, and the SAP Autonomous Suite offers 224 pre-built agents. Each layer has its own licensing logic and metering points.

Since June 2025, RISE with SAP Premium Plus no longer exists as a standalone tier. Contracts that still reference this name point to a discontinued contract subject. Which capabilities are currently included in SAP Cloud ERP Private and what must now be procured as an add-on should be actively reviewed before the contract expires or is renewed.

The free design-time access to Joule Studio runs out at end of 2026. Those who develop agents during this phase are building a technical dependency on runtime licenses that must be separately procured from 2027 onward. The commercial conditions for these runtime licenses are negotiable today; after the agents are deployed, they are substantially harder to negotiate.

The SAP AI Agent Hub will be generally available in Q3 2026. It is the central governance instrument for agent inventory, policies, and compliance documentation under the EU AI Act. Organizations that do not deploy the Hub will need to build agent governance manually, which is not a practical approach for regulated industries or high-risk use cases.

A RISE or SAP Cloud ERP Private contract typically includes certain embedded AI features such as Predictive Accounting and Intelligent AP Automation, fixed transaction quotas of 10,000 to 50,000 AI transactions per month depending on tier, and a Joule view-only access with limited conversation sessions. This base scope is adequate for initial orientation. For productive AI adoption across real user populations, Joule Power User Seats, additional AI Units, and extended capability packages are required as add-ons (source: SAP Licensing Experts, SAP AI in RISE Contracts 2026).

SAP standard contract clauses provide that AI consumption across development, test, and production environments is collectively counted against the monthly allowance. Organizations running active AI features in non-production environments can generate higher consumption than planned. A dev/test exclusion from AI Unit counting is negotiable and should be explicitly addressed at the next contract renewal (source: SAP Licensing Experts).

Once the contractually fixed AI Unit allowance is exceeded, the overage clause of the Order Form applies. Up to 20 percent above the allowance, typically without surcharge. Between 21 and 50 percent above the allowance, 1.5 times the contract rate typically applies. Beyond 50 percent overconsumption, two to four times the contract rate or a service suspension are possible, depending on contract wording. An explicit cap agreement and an approval requirement belong in every AI contract negotiation (source: SAP Licensing Experts, Negotiating SAP AI Contracts; Redress Compliance, RISE with SAP Tiers 2025).

The Order Form review is a coordinated governance moment across four roles. Contract Manager reviews contract structure and compliance clauses. Procurement evaluates conditions and negotiation potential. Controlling assesses overage risks and budget relevance. Executive approves strategic decisions such as contract type choices. Without this coordination, individual sections, such as the Aggregation Scope clause or rollover provisions, are regularly discovered only after contract signing.

Not by default. Unused AI Units expire at the end of the contract year. A rollover right of 10 to 20 percent of unused AI Units can be introduced in many contract negotiations, but it is not a standard condition and must be explicitly anchored in the Order Form (source: SAP Licensing Experts, AI Units Explained 2026).

The user pays for each package separately. Unused allowances from one package cannot be credited against another package. Cross-package pooling is not part of the PUPM logic (source: SAP Learning, Analyzing the PUPM Pricing Model).

Whenever Joule capabilities or AI agents are to be grounded on proprietary context, whether via custom model grounding, Company Memory, or the SAP Knowledge Graph. At that point, BDC becomes an active consumption pool that must be procured and governed separately.

There is currently no native SAP tool that aggregates all three pools and reflects them against the contract framework. SAP for Me shows aggregated AI Unit consumption, the BTP Cockpit shows Capacity Unit consumption at subaccount level, the BDC Cockpit reports BDC Credits. Consolidation rests with the customer and requires a dedicated governance capability.

Premium Plus as a tier has been deprecated. Whether an existing contract continues under the original Premium Plus terms, or whether a transition to the new structure takes place at renewal, depends on the specific contract conditions and the renewal timing. Relying on existing wording without reviewing the current Order Form introduces gaps in planning.

There is no universal answer. Some existing customers retained Joule through the repackaging; others renegotiated it as an add-on or lost access. The only reliable answer comes from the current Order Form and a comparison with the original contract.

Commercial efficiency depends on the overall portfolio. Standalone BTP is generally the least favourable model. The RISE or Cloud ERP Private bundle tends to be the most commercially advantageous at relevant volumes, as AI Units are priced at a subsidy within the bundle. The decision can only be made on the basis of comparing actual consumption structures.

Under CPEA contracts, unused credits expire at the end of the consumption period. An automatic carry-over into the following year is not part of the standard model. Whether a carry-over provision is included in the contract can be verified in the Contract Schedules. Source: SAP Help Portal, CPEA contract logic; saplicensingexperts.com.

CPEA (Cloud Platform Enterprise Agreement) is the older BTP contract model, still active in many running contracts. BTPEA (BTP Enterprise Agreement) is the current successor model. Both operate with annual credit budgets but differ in service catalog, billing logic, and how remaining balances are treated. For organizations on an existing CPEA contract, evaluating a migration to BTPEA as part of the next renewal is worth considering. Source: SAP Community; saplicensingexperts.com.

SAP Business AI Units consumed through the Generative AI Hub or AI Services on BTP follow a different consumption logic than the general CPEA balance. Per-User-Per-Month requests (PUPM) typically expire at month-end, not at year-end. This means unused AI requests within a month do not carry over to the following month. Organizations that have deployed AI services but are not yet in productive operation should monitor monthly consumption data separately. Source: SAP Community Blog; SAP Help Portal.

BTP consumption data can be evaluated at subaccount level in the SAP BTP Cockpit. Allocating costs to individual projects or cost centers requires a deliberate subaccount structure in which BTP resources are operated in separate subaccounts by business unit or project. This structural decision needs to be made early: reorganizing a subaccount hierarchy retroactively involves significant effort. Source: SAP Help Portal, BTP Account Model Documentation.

Without subaccount separation, a directly consumption-based allocation is not possible. As a transitional approach, usage-based proration based on transaction volumes or user shares per business unit is a practical option. In parallel, the subaccount structure for new projects should be built consistently by attribution unit from the outset. Retroactively restructuring existing subaccounts is technically feasible, but requires care with entitlement reassignment (Source: SAP Help Portal, Monitoring Usage and Consumption Costs).

Showback makes BTP costs transparent to cost centers and projects without triggering internal bookings. Chargeback actually allocates those costs against the budgets of the business lines. Showback builds cost awareness; chargeback creates cost ownership. Many organizations start with showback and introduce chargeback once internal acceptance of the cost structure has developed (Source: FinOps Foundation, FinOps Framework 2025).

Monthly, because BTP balance statements are delivered monthly and the relevant consumption components are billed on a monthly basis. Quarterly aggregation is sufficient for budget reviews, but it misses intra-year shifts that matter for renewal preparation or overage management.

Four components are required: first, the monthly balance statements per subaccount from the BTP Cockpit; second, the contractually fixed credit price from the Order Form; third, the mapping between subaccounts and internal cost centers or projects; and fourth, a defined approval and booking procedure for the monthly allocation. The most time-consuming part is typically the mapping, because it connects the internal organizational structure with the BTP architecture decision (Source: SAP Help Portal, Monitoring Usage and Consumption Costs).

A transitional approach is to use a proportional allocation key: the total consumption of a subaccount is split according to a pre-agreed formula, for example, based on the share of active users per business unit or the share of transaction volumes. In parallel, any new BTP projects should start with a clean subaccount assignment from day one. Restructuring existing subaccounts after the fact is technically possible but requires careful planning around entitlement reassignment (source: SAP Help Portal, Monitoring Usage and Consumption Costs).

No. The right level of granularity depends on your organization's size and controlling requirements. Too many subaccounts increases administrative overhead for entitlement assignment and monitoring. Too few subaccounts limits allocation precision. A workable starting point for mid-size organizations is separation by business unit, supplemented by an environment split (production, test, development) for the highest-consumption projects.

The contractually fixed credit price from your Order Form is the correct basis. The list price systematically overstates actual costs because it does not account for volume discounts from the Enterprise Agreement. For internal allocation, the contract credit price should be used so that internal costs reflect actual contract costs.

Monthly, because BTP Balance Statements are delivered monthly. Quarterly aggregation is sufficient for budget reviews, but it misses intra-year consumption shifts that can be relevant for governance purposes.

Indirect Access was the historical term for any access to SAP data through third-party systems, without a clear definition of exactly when a licensing obligation arose. Digital Access is the successor model in effect since 2018. It replaces the imprecise access concept with a clear document logic: a licensing obligation arises from creating one of the nine defined document types in SAP, not from access as such.

The nine document types are: Sales Order Items, Purchase Order Items, Service Order Items, Manufacturing Order Items, Invoice Items (Billing/AR), Payment Items (Incoming Payments), Goods Movement Items, Journal Entries, and Inbound Delivery Items. This list is exhaustive.

For internal integrations within the scope of the Enterprise Agreement, Digital Access is frequently included without limit in RISE contracts. "Internal" is defined in a contract-specific way. External systems, customer portals, supplier platforms, and IoT integrations generally do not fall under this inclusion. The contract text, specifically the Digital Access Supplement, is the authoritative reference.

Named User is typically economically superior when the users of the third-party system are known, identifiable, and limited in number. When a small group of internal employees triggers SAP postings through an external tool, Named User is often the simpler path. With anonymous users, high transaction volume, or automated processes, Document-Based Licensing is superior.

The Digital Access Adoption Program is a voluntary SAP program that allows the transition from historical Indirect Access obligations to Document-Based Licensing. It is formally an amendment to the existing SAP contract. Existing customers with contracts concluded before 2019 may not yet have completed the DAAP. Completion is not mandatory but provides planning certainty and audit protection.

It depends on the configuration. SAP has defined free-of-charge license categories for its own IRPA bots (Type 68) and certified third-party RPA bots (Type 69). Bots correctly classified under these categories do not trigger a Digital Access obligation. Bots outside these categories or using different authentication models can create document items in SAP and thereby trigger a licensing obligation. Every RPA deployment should be reviewed for Digital Access relevance before the productive rollout.

Static Read describes the exclusively read-only access of a third-party system to SAP data, where the system writes or creates nothing in SAP. Since Digital Access attaches to the creation of documents rather than the reading of data, pure data retrieval does not create a licensing obligation. A dashboard that reads and visualizes SAP data without creating any postings therefore falls under Static Read and is unproblematic from a licensing perspective.

In an Enhanced Audit, SAP requests a complete list of all third-party systems with SAP interfaces. Transaction logs and document volumes are analyzed. Systems that create document items in SAP without a Named User license or a DAAP Supplement as the basis are flagged as compliance gaps and can trigger retroactive additional charges.

The Export Rule states that when a licensed SAP user has defined and initiated an automated process that subsequently runs automatically, no additional Digital Access obligation arises for the automatic execution. The condition is that the licensed user has set up the process and the authorization exists in the context of that user. For complex multi-step workflows running across multiple system boundaries, the applicability of the Export Rule is not always clear-cut and should be confirmed contractually.

The integration register is the central tool. For each interface it captures: the external system, the direction of data flow, the document types generated, the monthly volume, the user base, and the licensing basis (Named User, Digital Access Supplement, or exception). This register should be maintained as a living document, updated when new integrations are added and reviewed quarterly for completeness.

Yes. When the document quota agreed in the DAAP Amendment is exceeded, the overage rules of the Order Form apply. The specific overage rate is contract-dependent. An overage cap is negotiable but is not part of SAP's standard terms. A concrete overage cap should be addressed in every Digital Access negotiation.

Three questions are relevant. First: which integrations exist in your inventory, and which document types do they generate? Second: are these integrations covered by Named User licensing or another licensing basis? Third: is the DAAP program an economically sensible option for your inventory? A contract check addresses these questions systematically and provides a solid starting point for the next renewal negotiation.

That depends on the size of your integration landscape. Organizations with ten to twenty integrations can work through Steps 1 to 6 within a few weeks. For complex portfolios with multiple ERP systems, international entities, and extensive RPA use, a structured inventory is a multi-month project. That is a strong argument for treating these steps not as a one-time project but as a recurring governance moment embedded in your regular operating cadence.

Start by aligning internally: IT, procurement, and legal should coordinate before the first response goes to SAP. Then review the scope of the notification: which systems and time periods are named? From there, use your integration register (Step 9) to assess your current position and identify any gaps that can still be addressed before data is handed over to SAP.

The SAP General Terms and Conditions require you to cooperate with the measurement process for systems within the contract scope. Systems outside the scope and contractually excluded environments are not automatically part of the audit. What exactly must be provided depends on the specific contract language. If the scope is unclear, a legal review before transmitting any data is advisable.

A gap you identify yourself and proactively close is a significantly stronger negotiating position than a SAP finding. If there is time to close a DAAP amendment or purchase Named User licenses before data is handed over, that materially improves your starting position. If time is short, having solid internal documentation and a substantiated estimate of your exposure is still a meaningful foundation going into the negotiation phase.

SAP sends a formal audit notification including scope, timeline, and point of contact. The customer runs USMM across all relevant production systems and consolidates the results using LAW (SLAW2). In an Enhanced Audit, SAP additionally requests information about the integration landscape and actively analyzes transaction logs. The process typically takes three to six months for complex environments. SAP's audit department (Global License Auditing) then presents findings identifying compliance gaps. A negotiation phase follows.

USMM (User and System Measurement Management) is a standard SAP program (transaction USMM) available in every SAP system. It measures Named User counts and engine metrics per individual system. Results are exported as a measurement file and consolidated across systems in LAW (SLAW2). The consolidated report is the document submitted to SAP. USMM counts all Named Users regardless of activity. Inactive accounts and duplicates inflate the measured count.

SAP flags the affected system as a compliance gap and quantifies the exposure: retroactive purchase of missing document quotas at current list price, retroactive license fees for the audit period (typically two to three years), and back-maintenance. The finding is used as the starting point for a negotiation on the true-up scope. Every finding can be evaluated internally and challenged where your own documentation supports a different assessment.

The obligation to participate in the annual measurement is established in SAP's General Terms and Conditions. Full refusal is a breach of contract. However, the scope of that obligation is bounded by the contract. Systems outside the contract scope and environments contractually excluded from audit (test systems, sandboxes) are not automatically part of the audit.

Before your next renewal conversation and before your next Enhanced Audit. Ideally, remediation is not a separate project but part of an ongoing governance cadence: maintaining the integration register, reviewing new integrations before go-live, executing the DAAP Amendment, or completing Named User true-ups for identified gaps. The earlier a gap is closed, the lower the retroactive exposure in a subsequent audit.

Indirect Access was the historical term for all access to SAP via third-party systems, without a clear definition of when a licensing obligation arose. Digital Access is the successor model in effect since 2018. It replaces the vague access logic with a document-based model: a licensing obligation arises from the creation of one of the nine defined document types in SAP, not from access itself.

The Digital Access Adoption Program is a voluntary SAP program that enables a formal transition from historical Indirect Access obligations to Document-Based Licensing. It attaches to the existing contract as a DAAP Amendment and Digital Access Supplement and enables a retrospective settlement of historical compliance gaps. Existing customers whose contracts predate 2019 may not yet have completed the program.

The program is voluntary. It does, however, provide planning certainty and audit protection for the covered document types. Existing customers without a DAAP Supplement are operating under the historical Indirect Access gray zone, which can lead to retroactive demands in an Enhanced Audit. Whether the DAAP makes economic sense depends on your integration inventory and the ratio between your user base and document volume.

Yes. Named User remains a fully valid licensing path for third-party access. For scenarios with a small number of identifiable users, it is often the simpler option. Document-Based Licensing is economically stronger for anonymous users, high transaction volumes, or fully automated processes.

For internal integrations within the scope of the Enterprise Agreement, Digital Access is frequently included without limits in RISE contracts. "Fully included" is not accurate, however: external systems, customer portals, supplier platforms, and IoT integrations typically fall outside this inclusion. The contract text is the authoritative reference.

"Internal" in the Digital Access Supplement typically refers to the direct contracting party and its own systems. "Affiliate" is a separate category for associated entities that must be explicitly included in the contract. Whether group companies qualify as affiliates, and whether affiliates are covered by the EA inclusion, depends on the specific contract.

Yes. The RISE migration does not automatically carry over the licensing bases from the on-premise contract. Integrations that relied on Named Users or historical Indirect Access rules require a fresh assessment in the RISE contract context. A middleware change, for example from SAP PI to BTP Integration Suite, can alter the Digital Access profile of an integration.

For external integrations outside the EA inclusion, the contractual basis for Document-Based Licensing is then missing. Those integrations are in a licensing gray area. In an enhanced audit, SAP can identify that gap and assert retroactive claims. A DAAP amendment can be signed after the fact and typically includes a retrospective true-up.

The nine document types are: Sales Order Items, Purchase Order Items, Service Order Items, Manufacturing Order Items, Invoice Items (Billing/AR), Payment Items (Incoming Payments), Goods Movement Items, Journal Entries, and Inbound Delivery Items. This list is exhaustive. Documents outside these nine do not create a Digital Access obligation.

Three conditions must be met simultaneously: the third-party system creates one of the nine defined document types in SAP via an SAP interface. The user of the third-party system does not have a Named User license for SAP. The third-party system is not operating under a recognized exception (Static Read, Export Rule).

Per document item. The metric is the volume of line items created, not the number of interfaces or systems. A Purchase Order with ten line items generates ten licensable items.

No. If a third-party system exclusively reads SAP data without creating document items, no Digital Access licensing obligation arises. SAP calls this Static Read.

Not necessarily. SAP has defined free license categories for its own IRPA bots (Type 68) and certified third-party RPA bots (Type 69). Bots correctly classified under these types do not create a Digital Access obligation. Bots outside these categories must be assessed separately.

With Named User, the users of the third-party system are licensed as SAP users. With Document-Based Licensing, the document volume is licensed. Named User is suited for a small number of identifiable individuals. Document-Based Licensing is economically superior when access involves many users, anonymous users, or fully automated processes.

For internal integrations within the defined scope of the Enterprise Agreement, Digital Access is often included without limit. "Fully" is not quite accurate: external systems, customer and supplier portals, externally operated SaaS platforms, and IoT environments outside the EA scope generally fall outside the inclusion. The contract text, specifically the Digital Access Supplement, is the authoritative reference.

In the Digital Access Supplement, "internal" typically refers to the direct contracting party and its own systems. "Affiliate" is a separate category for associated companies. Whether group companies qualify as affiliates, and whether affiliates are covered by the EA inclusion, depends on the specific contract. Affiliate clauses vary considerably across contract versions.

Yes. The RISE migration does not automatically carry over the licensing basis from the on-premise contract. Integrations that relied on named-user licenses or historical indirect access rules need a fresh assessment in the RISE contract context. A middleware change in particular can alter the Digital Access profile of an integration.

For external integrations outside the EA inclusion, there is then no contractual basis for document-based licensing. Those integrations exist in a licensing gray zone. SAP can identify this gap in an enhanced audit. A DAAP amendment can be executed retroactively and typically includes a retrospective true-up.

No. Digital Access is triggered only when a third-party system creates one of the nine defined document types in SAP via an SAP interface. Systems that only read SAP data (Static Read) do not create a governance moment.

For internal systems, meaning systems belonging to the same legal contracting entity, the RISE Enterprise Agreement often includes unlimited Digital Access rights. External systems, partner portals, customer integrations, and IoT platforms are generally not included. What "internal" means in a specific case is defined in the contract.

Yes. RPA systems structurally have no Named User. When a bot creates documents in SAP via an SAP interface (invoices, journal entries, purchase orders), a Digital Access obligation arises. Document-Based Licensing through a DAAP Supplement is the standard path.

SAP provides a Measurement Tool for the DAAP program that measures historical document volume by document type and source. SAP transaction logs and middleware logs can supplement this with a more detailed analysis.

Ariba transaction fees are Ariba-Network-specific charges for document exchange on the Ariba network. Digital Access is the SAP-side license obligation for creating documents in SAP. Both can apply at the same time. Whether Ariba integrations fall under the RISE EA inclusion is a contract-specific question that requires review.

Structured preparation begins no later than 18 months before contract end. The reason: the data foundation required for a well-grounded negotiating position cannot be built quickly. Usage time series covering 12 to 18 months, complete contract documentation, stakeholder alignment, and clause review all require lead time. In addition, SAP typically begins the renewal dialog on its side 12 to 18 months before the term ends. Starting later means meeting a counterparty that is already fully prepared.

The contract renews automatically at term end, typically for the original contract duration. SAP may increase the price for the new period, provided the increase was announced at least 45 days before the renewal start date. Renegotiation without a new opening is not possible. The customer's right to terminate remains available even after renewal, provided SAP announces a price increase.

Four data categories: usage data (FUE utilization by user type, BTP credit history, CAS consumption), contract data (Schedule 5, Balance Statements, special agreements), market data (public DSAG reports, specialized sources), and quality data (SLA compliance, ticket volumes, unresolved escalations). With all four categories complete, you can answer any question about volume, pricing, or clauses with facts.

SAP must announce any intended price increase for the renewal period at least 45 days before the renewal start date (Schedule 5). If the notification is late, the increase applies only to the period after next. The customer has the right to terminate for convenience upon receipt of the notification. This window is a structured governance moment: those who know it can position proactively.

Yes, subject to the contractually defined restrictions. Cloud Managed Services and Cloud Software have a minimum term of six months; CAS packages, twelve months. No new Managed Service or Software subscriptions can be added in the last six months before contract end, and no new CAS units in the last twelve months. Third-party software is generally not decommissionable. Volume adjustments must be completed before the applicable lock-out periods.

CPI clauses govern the extent to which price adjustments are permissible at renewal. The publicly communicated framework in Schedule 5 allows a maximum increase of 3.3 percent per renewal period. The specific clause language in the individual contract, including the reference index, calculation period, and cap formulation, determines the actual adjustment room. An interaction exists with the credit reduction mechanism: SAP standard terms allow for a discount adjustment when volume is reduced.

Remaining credit at the end of the contract term expires entirely. The degressive roll-over mechanism allows a portion of credit to be carried forward in prior years (30 percent in year one, 20 percent in year two, 10 percent from year three onward), but roll-over is excluded in the final year. This mechanic is a structural reason why credit planning must begin in the penultimate contract year, not the final one.

The four roles of the SAP contract governance model: Contract Manager (from M-18, deadline owner and clause review), Procurement (from M-12, negotiation leadership and budget mandate), Controlling (from M-12, usage analysis and budget scenarios), and Executive (from M-12, strategic decision and release of the negotiation mandate). The stakeholder team should be formally constituted no later than Phase 2.

Exit rights govern the conditions for ending the contract, including notice periods, data portability, and cost allocation. The best time to negotiate them is at renewal: addressing exit options during renewal means they do not need to be introduced later through an amendment. Key items to negotiate actively include data portability in standardized formats, transition periods after contract end, and cost allocation for export services.

BTP credit data provides the granular picture of cloud platform usage below the FUE level. A time series covering 12 to 18 months with project attribution and cost center structure is the minimum requirement. From this series, you can calibrate the credit volume for the next term, quantify overage risk, and project AI Unit demand if an expansion of Business AI usage is planned. BTP data is therefore directly actionable negotiation input, not just internal reporting.

Schedule 5 defines the formal framework: up to 3.3 percent increase per renewal period, notice required 45 days before the renewal start date. The CPI clause in the narrower sense is the individual formulation in your Order Form or amendment that specifies whether and how this framework is modified through a reference index, a specific cap, or a different calculation mechanism. Both together give you the complete picture.

Under Schedule 5, 3.3 percent is the defined ceiling per renewal period. Whether your contract deviates from this, for example through individual language in your Order Form, is something to verify in your own contract documents. For planning purposes: Schedule 5 is the publicly documented standard.

A notice given outside the required window has a clear consequence: the announced increase applies to the period after next, not the immediately following one. Monitoring the notice deadline gives you a governance moment here.

When credit volume is reduced, SAP may adjust the discount that was originally granted based on the prior volume under standard terms. This means: reducing volume at renewal can trigger a discount adjustment that stacks on top of the CPI increase. Evaluating the two mechanisms separately understates the total price impact of the new term.

In Phase 3 of the renewal process, meaning nine to six months before contract expiry. At this point, a clause review is conducted across all six critical clause areas: price adjustment clause, auto-renewal clause, SLA structure, exit rights, divestiture clause, and subscription flexibility. The output of this review is the clause delta that feeds into your negotiation position.

There is no one clause that is equally relevant for every organization. The price adjustment clause is central because it directly affects how costs develop over the next term. The auto-renewal clause is operationally critical because missing its deadline leaves no room for correction. Which clause matters most depends on your current contract situation, your planned changes, and your organization's circumstances.

SAP standard contracts are a starting point, not a ceiling. What ends up in an individual contract depends on the negotiation and your position going in. A solid data foundation, a clearly formulated clause delta analysis, and sufficient lead time are the prerequisites for running that conversation with structure.

You extend the status quo. That is not necessarily a problem if the current terms meet your needs. Where gaps exist, for example around data portability or transition windows after contract end, they are structurally harder to address after renewal than before it.

The first step is complete contract documentation: the Order Form, all Schedules, all Amendments. The clause areas described in this article are typically found in Schedule 5 (price adjustment, auto-renewal), Schedules B and D (SLA and credits), Schedule C (DPA and exit), and the Order Form itself (special agreements, minimum terms, lockout periods).

After contract end, SAP is required under the Data Processing Agreement (Schedule C) to return or delete personal data. For operational data and configuration data not covered by the DPA, the contractually agreed terms apply. Without an explicit transition period clause, there is no automatic right to continued data access.

A transition period with defined access, scope, and cost allocation is generally negotiable. Renewal is the right governance moment for this. What can actually be agreed depends on your negotiating position and your specific requirements.

The SAP Data Export Service enables structured export of customer data from SAP systems. For a credible exit plan, what matters is which data is exported in which format and to what extent that data can be used for onward migration. These points should be defined contractually, not clarified after the need arises.

Yes. Exit clauses define your room to maneuver for the entire contract term and beyond. Organizations with documented exit options negotiate follow-on contracts from a fundamentally different starting position than those for whom switching would be technically and legally prohibitive. Whether to exercise those options is a separate decision entirely.

Four categories make up the complete data foundation: consumption data (FUE utilization by user type, BTP credit history, CAS usage, Cloud Managed Services against purchased volume), contract data (Schedule 5, balance statements, special agreements), market data (public industry sources, DSAG reports), and quality data (SLA compliance, ticket volume, open escalations). A well-grounded negotiation position requires all four categories.

The data foundation cannot be built quickly. Consumption time series covering twelve to eighteen months, complete contract documentation, and coordinated data delivery across multiple organizational functions require at least eighteen months of lead time. Organizations without that lead time enter renewal with an incomplete foundation.

Shelfware refers to components for which credits are being spent without the agreed scope of use being fully utilized. Identifying shelfware is the foundation for two renewal scenarios: volume reduction based on documented underutilization, or activation planning for previously unused capacity. Both options require a documented consumption history.

Under the RISE Enterprise Agreement, the obligation to report overages rests with the customer. Consumption beyond the contracted credit must be reported before it occurs. Unreported overages are invoiced at a 15 percent surcharge on the standard consumption fee, and no SLA guarantee applies during the overage period.

Data foundation and negotiation tactics are not alternatives. They operate on different levels. Negotiation tactics without a reliable data foundation depend on the persuasiveness of the argument. A complete data foundation allows every question about volume, price, and contractual terms to be answered on the merits, regardless of how the counterpart chooses to conduct the conversation.

Contract Manager, Procurement, Controlling, and Executive. Each role owns a specific dimension of the renewal process: deadline management and clause review (Contract Manager), budget mandate and negotiation leadership (Procurement), usage analysis and budget scenarios (Controlling), strategic decision and framework approval (Executive). When one role is missing, a decision gap opens up that becomes visible during the negotiation phase.

No later than 12 months before contract expiry (M-12). The Contract Manager enters the process actively at M-18. The full team is formally constituted at M-12: responsibilities documented, communication cadence established, data requirements defined per role. Organizations that assemble the team only at M-6 forfeit the lead time needed for scenario analysis, clause review, and budget planning.

Procurement enters the SAP conversation without an approved negotiating framework. Decisions must be obtained during the negotiation, which slows the pace and creates information asymmetries. The strategic direction for the next term is set under time pressure rather than as a prepared decision.

Yes, particularly in smaller organizations. What should not be combined: negotiation leadership (Procurement) and approval of the negotiating framework (Executive) in the same person. This separation ensures that the negotiation lead has a clear principal and a defined mandate.

Phase 2, between M-12 and M-9. At that point, the data foundation is in place, scenarios are being defined, and an independent perspective on the contract position is still actionable. External expertise brought in during the negotiation phase (M-6 to M-0) no longer has time to build its own analysis.

No later than 18 months before contract expiry. The reason: the data foundation needed for a well-grounded negotiating position cannot be built on short notice. Consumption time series spanning 12 to 18 months, complete contract documentation, and stakeholder alignment all require lead time. Beyond that, SAP typically begins the renewal dialogue on its side within this same window.

The contract renews automatically, typically for the original contract duration. SAP may increase the price for the new period, provided the increase was communicated at least 45 days before the renewal date. Renegotiation without a new opening is not possible. The right to terminate still applies if SAP announces a price increase, but the time available to act is then significantly shorter. The governance moment for a proactive negotiating position has already passed by that point.

If the renewal date is less than 18 months away, the model needs to be adapted to the available time. Priority then is: build the data foundation (Phase 1), constitute the stakeholder team (Phase 2), complete the clause review (Phase 3). Phase 4 requires at least six months because the lock-out periods for new subscriptions apply before that. Organizations entering preparation with less than six months of lead time already have constrained options.

The contractual consequence is the 15 percent uplift on excess consumption, invoiced on the following month's bill. In addition, the SLA guarantee is suspended for the duration of the overage period. The self-reporting obligation is a contractually defined customer responsibility, and failure to fulfill it can become relevant in the context of a contract audit.

Monthly. That is the minimum frequency for a functional overage governance process. SAP provides the Balance Statement monthly. Reviewing less frequently leaves no reliable basis for projecting the remaining credit balance through to contract end.

PCE Metering is SAP's internal measurement of FUE usage. It does not replace your own measurement, because it provides no basis for validating SAP's results. Your internal measurement and SAP's measurement run in parallel. If discrepancies arise, your internal measurement history is the prerequisite for a substantive resolution.

Yes, provided the lock-out periods allow it. New Cloud Managed Service or software subscriptions are available up to six months before contract end. New CAS units can be added up to twelve months before contract end. Organizations that identify a developing overage early have sufficient options available. In the final quarter before contract end, those options are structurally constrained.

Unresolved items from the current contract term consume resources in renewal discussions. Well-maintained overage documentation, by contrast, is a factual input into the renewal data foundation: it shows which components were structurally under- or overallocated and what volume would be appropriate for the next term.

Authorization-based classification means a user's FUE type is determined by the roles and authorizations assigned to them, not by their actual system usage. The highest authorization in a user's role combination determines their FUE type.

In a usage-based model, the actual scope of transactions a user executes would serve as the basis for the license type. S/4HANA Cloud uses the authorization-based model instead: assigned authorization overrides actual usage.

PCE Metering runs monthly, triggered automatically by SAP. Role optimizations must therefore be completed before the respective metering cutoff to take effect in the current month.

Role creep is the gradual expansion of authorizations beyond the licensed scope. It typically results in users being measured at a higher FUE type than their actual work activity requires. The cause is usually the assignment of additional roles without validating the license type implication.

The STAR analysis (S/4HANA Trusted Authorization Review) is an SAP tool for analyzing the authorization structure. It shows which authorizations are assigned. Important: always cross-reference raw STAR data internally with usage logs and optimize authorizations before using that data foundation for any external purpose.

Every user who can be downgraded from Advanced to Core saves 0.8 FUE. From Advanced to Self-Service, that is 0.967 FUE. From Core to Self-Service, it is 0.167 FUE. Across larger user populations, these savings add up to a substantial lever for shaping the contract baseline at the next renewal.

S/4HANA Cloud applies an authorization-based classification model: a user's FUE type is determined by the roles and authorizations assigned to them, not by the transactions they actually execute. What a user could do is the measuring criterion, not what they actually do.

Advanced (1.0 FUE) is five times more expensive than Core (0.2 FUE) and roughly thirty times more expensive than Self-Service (0.033 FUE). The saving per user when downgrading from Advanced to Core is 0.8 FUE; from Advanced to Self-Service, 0.967 FUE; from Core to Self-Service, 0.167 FUE.

Role optimizations reduce FUE consumption and therefore improve the headroom situation within the current pool. Reducing the contractually agreed FUE pool size mid-term is not possible under most RISE contracts. Optimizations therefore primarily serve as negotiating leverage for the next renewal, not as an immediate cost reduction.

Install SAM4U (SAP Note 3646933) in your customer system and activate Enhanced Usage Tracking. This builds the usage baseline per user. Run a STAR analysis internally in parallel and compare both results. That comparison shows where assigned authorizations and actual need have drifted apart.

Most organizations start somewhere between level 1 and level 2: a basic documentation of the license baseline exists, but no ongoing governance cadence. USMM is run occasionally, SAM4U is not installed or not actively used. Misclassifications are known or suspected but not systematically addressed. A structured contract check is typically the first concrete step to clarify this starting situation.

The general model (described in Pillar 1 of this content series) covers all four governance moment areas: usage, authorizations, infrastructure, and costs, as well as the coordination of all four roles. The license maturity model goes deeper on the license dimension specifically: named users, FUE, measurement tools, authorizations, and audit readiness. Both models complement each other: running both self-assessments gives you a complete picture.

Significantly. In an on-premise environment, level 2 (annual USMM) was long considered an acceptable baseline. In a PCE context, with monthly automated metering by SAP, level 2 is structurally insufficient: classification errors become visible 12 times faster. The governance moment around authorizations effectively becomes a monthly governance moment. For PCE customers, the move to level 3 is more urgent than for on-premise organizations.

It depends on the price difference between license types and the duration of under-licensing. A practical example from SAP compliance: 100 users with a Limited license who are actually performing Professional transactions, at a price difference of roughly EUR 1,500 per user, results in EUR 150,000 in additional purchase cost. Add three years of back-maintenance at 22 percent per year and the total exposure reaches approximately EUR 249,000. This illustrates why ongoing classification review is more economically sound than reactive remediation in an audit context.

Named User is the classic license metric for on-premise systems: every person with SAP access requires an individually assigned license of a specific type. FUE (Full Use Equivalent) is the license metric for RISE with SAP and GROW with SAP: customers purchase a pool of weighted units and distribute them internally across user types. The essential difference lies in the compliance check: under the named user model, every type must be individually compliant. Under the FUE model, compliance is assessed at the pool level, meaning the weighted sum of all users must not exceed the purchased FUE pool.

Advanced User: 1.0 FUE. Core User: 0.2 FUE (5 Core Users = 1 FUE). Self-Service User: 0.033 FUE (approx. 30 Self-Service Users = 1 FUE). Developer User: contract-specific, in practice 0.5 or 2.0 FUE depending on the contract version. The specific contract must be reviewed.

In most RISE contracts, a mid-term reduction of the FUE count is excluded. Organizations that purchase too many FUEs pay for unused capacity until renewal. A true-up/true-down clause allowing adjustment after 18 to 24 months is negotiable.

The nomenclature changes, and SAP made adjustments to the mapping of roles to user types in 2025. Certain transactions that counted as Limited Professional in ECC may require Professional in S/4HANA. A reclassification analysis before go-live is advisable.

In practice, typically only 10 to 20 percent of all users in an organization need Advanced access. Organizations that do not analyze the precise distribution pay structurally more than necessary.

No. A practical prioritization follows ACV share and licensing model complexity. RISE and BTP warrant more intensive governance than a small Concur allocation. The right approach is a governance layer that keeps all product types visible, while calibrating the depth of operational management to volume and risk.

Treating renewal dates as isolated events. When RISE, SuccessFactors, and Ariba are renewed independently, without a shared strategy, negotiating opportunities are lost that cannot be recovered. Coordinated governance moments begin before the renewal, not when the renewal letter from SAP arrives.

Co-termination is not offered automatically by SAP. The first step is consolidating the current end dates of all active SAP contracts and analyzing the gap to a shared renewal date. This shows which contracts would need to be extended and at what cost. That analysis forms the basis for the negotiation with SAP or your advisory partner.

The consumption logic for CPEA, BTPEA, and AI Units is covered in depth in Pillar 2 (SAP Business AI and BTP Governance) and Pillar 3 (BTP FinOps). This article addresses BTP from the portfolio perspective; the detailed mechanics are intentionally left to the dedicated pillars.

FinOptory brings together contract, usage, and cost data across all SAP product types and surfaces governance moments for each one. The platform allows you to track renewal dates, credit consumption, and classification variances in a single shared view. For more information about the platform and the managed service, visit finoptory.ai.

A Basic Audit is the annual standard measurement: self-executed, limited depth of review, moderate risk. An Enhanced Audit is an in-depth review by SAP GLA, covering deep role analysis, transaction usage, and Indirect Access, with a three-to-six-month timeline and significantly higher financial exposure.

Routinely every two to three years for the Enhanced Audit. On a cause-related basis: before renewals and RISE migrations, during M&A activity, following prior non-compliance findings, or when the Basic Audit shows anomalies.

Quarterly self-audits with USMM and SAM4U, combined with continuous cleanup of inactive accounts. Organizations that keep their license base clean on a regular cadence have little to correct when an Enhanced Audit arrives.

The data contractually owed: USMM measurement files and the consolidated LAW report. Additional data may be requested in an Enhanced Audit; every request should be checked against the contractual scope.

Back-maintenance is the retroactive maintenance fee for the period of underlicensing. SAP typically calculates it at approximately 22 percent of license value per year, applied retroactively for two to three years. With 100 misclassified users and a USD 1,500 price difference per user, the total exposure comes to roughly USD 249,000 (repurchase USD 150,000 plus back-maintenance approximately USD 99,000).

No. Sandbox systems can be contractually exempt, but they do not have to be. The exemption must be explicitly stated in the contract, specifically in the attached "Product and Pricing Definitions" document. There is no general SAP rule that exempts sandbox systems by default.

It depends on the scope of access. A tester running full end-to-end process tests and executing Professional-level transactions needs the same type as in the production system. If the contract includes a dedicated Test User type, it may be used, provided the usage conditions are met.

The RISE FUE model does not include a standalone Test User FUE type in the standard definition. Users engaged in testing fall into one of the four FUE types based on their scope of access. Contractual special arrangements for test accounts are possible, but must be explicitly negotiated.

The Test User license type covers access exclusively to designated test systems. An account that generates production system access requires the corresponding production license type for that access. A single production system access event by a Test User-licensed account is a compliance finding.

The SAP software agreement includes the "Product and Pricing Definitions" supplement. All available license types and their usage conditions are defined there. If that document is not on file, it can be obtained through the SAP Account Executive or the SAP Support Portal.

Yes. USMM counts every Named User regardless of activity. Inactive test accounts increase the measured license count. Cleanup after 90 days without login is an established best practice.

USMM is SAP's classic standard tool for single-system measurement: it counts named users and engine metrics per system and generates a measurement file for the Annual Measurement or Enhanced Audits. SAM4U goes further: it analyzes actual usage, identifies optimization opportunities for FUE classification, and as of Q4/2025 also allows simulation of authorization changes before implementation. USMM measures; SAM4U governs.

LAW and SAM4U handle different consolidation tasks. LAW is the officially submitted consolidation document for the Annual Measurement, and in PCE metering it serves as the technical infrastructure for data transfer. SAM4U consolidates internally for optimization purposes but is not the submission document for SAP. Both are needed: LAW for the official compliance perspective, SAM4U for the internal governance perspective.

In an on-premise context, once a year was the decisive measurement point. PCE metering triggers monthly and automatically. That means SAP for Me should be reviewed monthly, role optimizations should be completed before the metering cycle, and discrepancies between your own understanding and SAP's metering result should be documented on an ongoing basis. The governance moment around authorizations is not an annual topic in a PCE context; it is a monthly one.

Yes. SAM4U is not a cloud service; it is installed directly in the customer system via SAP Note 3646933. Analysis data remains within the customer's network. Starting in Q1/2026, a Data API will be available to export SAM4U data into external platforms. The export is optional and under the customer's control.

SAM4U is free and specialized in SAP license measurement. It covers FUE classification, Enhanced Usage Tracking, Optimization Opportunities, and as of Q4/2025 Authorization Simulation. Commercial Software Asset Management tools have a broader scope covering all software products, but typically lack comparable SAP-specific depth for FUE classification and authorization-based analysis. For SAP license governance, SAM4U is the purpose-built instrument, designed specifically around SAP contract and governance requirements.

The system continues to run. What ends is Mainstream Maintenance: Legal Changes, Support Packages, and error correction in the standard are no longer provided automatically. From January 1, 2028, continued operation requires either an Extended Maintenance addendum or operation under PCE/RISE, which includes Extended Maintenance in the subscription price.

Extended Maintenance costs two additional percentage points on the Maintenance Base. The Maintenance Base covers all BS7 Core Applications, add-ons, and runtime databases. By deliberately surrendering no-longer-needed use rights, the base can be reduced before Extended Maintenance begins, which substantially reduces the surcharge in absolute terms.

Extended Maintenance applies to the entire on-premise BS7 landscape. Cherry-picking by system is not possible. When you apply for Extended Maintenance, you apply for it across all BS7 systems.

The Transition Option is a time-limited cloud operating model for SAP ERP EhP 7 and EhP 8 in SAP ERP Private Edition. Service start is January 1, 2031; the end date is December 31, 2033. The subscription window runs from 2028 to 2030.

The Transition Option carries a 20 percent surcharge over the comparable price of a regular SAP ERP Private Edition. In addition, the Max Success Plan Transition Services is mandatory. Customers who subscribed before end of 2025 do not pay the surcharge.

Yes, through the Cloud Extension Program. Three credit types are available: Maintenance Credits, Service Credits, and Cloud Credits. The amount depends on negotiation and is not publicly tabulated. Early negotiations typically strengthen the negotiating position.

SAP permits dual-use operation for a contractually defined transition period. The typical range in practice is six to 18 months. The exact duration and the usage rules during parallel operation must be established in the RISE contract.

Add-ons without an S/4HANA equivalent can still be operated in the Transition Option if they appear on the available add-on list. They must, however, be migrated to alternative solutions by end of 2033 at the latest. The S/4HANA Compatibility Pack applies only through end of 2030 for cloud subscriptions.

Shelfware consists of licenses for which maintenance is paid without the use rights being exercised. When moving to RISE, shelfware can be used as an additional argument in the credit negotiation. The prerequisite is a complete inventory via the SAP Readiness Check and license register.

Available add-ons span categories including Supply Chain (APO as connector, EWM), Finance (Revenue Accounting, Treasury), HCM (HR Renewal, SuccessFactors EC Integration), Compliance (GINVOICING), and Integration. The complete list is accessible in the SAP Help Portal and in SAP Customer Evolution documentation. Only EhP 7 and EhP 8 are supported.

For customers whose entire system landscape is operated in SAP ERP Private Cloud Edition by January 1, 2028, Extended Maintenance is included in the subscription price without additional surcharge. That is the structural simplification RISE offers compared to on-prem Extended Maintenance.

Ongoing contract governance after go-live covers the four governance dimensions: usage (FUE development, BTP credits), authorizations (role design, license classes), infrastructure (SLA monitoring, sizing), and cost (ACV tracking, derived charges, renewal preparation). A structured 14-day review process ensures governance moments are identified before they become budget deviations.

Extended Maintenance is relevant exclusively for on-premise operation. Organizations that remain on-prem with Extended Maintenance make no hyperscaler decision. The choice between Azure, AWS, and Google Cloud only becomes relevant when moving to RISE or the Transition Option. This decision should be anchored in the contract and affects both complementary services and the long-term cost structure.

After end of 2030, there is no structured SAP maintenance for on-premise BS7 systems without the Transition Option. Organizations that by that point have neither completed Extended Maintenance nor subscribed to the Transition Option and have not yet migrated to S/4HANA are in an operating state without a contractual basis for regular SAP support. Third-party maintenance is a possible option but requires its own contract structures and typically does not cover the full scope of SAP support.

SAP provides several tools that are relevant in the decision preparation phase: the SAP Readiness Check delivers technical system data for sizing and custom code analysis. SAP Signavio Process Navigator supports fit-to-standard alignment. SAP Cloud ALM is the ALM tool for RISE operations after go-live. These tools are included in the RISE contract but in practice are frequently activated only after go-live rather than during the preparation phase.

SAP license management is focused on the compliance dimension: are the SAP products actually being used correctly licensed? It is a verification and documentation task, typically reactive and oriented toward audit avoidance. Strategic vendor management goes further. It governs the entire SAP vendor relationship across all four governance domains: usage, entitlements, infrastructure, and cost. It is proactive, continuous, and oriented toward governance moments in the vendor relationship, not only compliance. A further distinction lies in the time horizon. License management is focused on the current state. Strategic vendor management is focused on how the vendor relationship develops over the full contract term and across future contract cycles.

Quarterly is the appropriate cadence for formal reviews with SAP contacts, typically the CSM and AE. These reviews provide a structured opportunity to discuss open topics, clarify the status of the contract relationship, and agree on next steps. In addition, there are occasion-based conversations: during escalations, renewal preparation, and M&A events. These conversations are not on a fixed schedule but respond to concrete governance moments.

The SAP vendor relationship should be owned by a dedicated Contract Manager role that holds the end-to-end contract view. In practice, this role is often not explicitly assigned in many organizations. Responsibilities are split between IT, procurement, and finance without any single person holding overall accountability. The recommendation is not necessarily a separate headcount but a clear role assignment: who holds end-to-end responsibility for the contract view, who coordinates the four roles, and who is the first point of contact for SAP and internally?

Retaining knowledge requires ongoing documentation discipline, not a one-time handover shortly before someone leaves. The knowledge base must be continuously maintained: contract structure, usage history, change history, SAP contact map, and open items. A structured handover at the point of a personnel change is still necessary and should include a review of all open governance moments, an introduction to currently active SAP processes, and a formal introduction to the SAP contact.

The escalation path begins with written documentation of the SLA deviation through the SAP Support Portal with a priority upgrade. If standard support does not produce an adequate response, the CSM and TAM are formally engaged. If that still does not produce a resolution, the AE is engaged with complete written problem documentation. If all of these steps do not produce a resolution, executive escalation is the next step. Written documentation of every escalation step is essential. That documentation is a governance moment that is relevant for future SLA negotiations.

Executive escalation at SAP refers to involving SAP's leadership in an escalation situation. It is appropriate when all normal escalation paths have been exhausted without producing an adequate resolution, or when a strategic decision at the leadership level is required that cannot be made below that level. Executive escalation should be prepared and used deliberately. Triggering it too frequently or without adequate preparation dilutes the signal. Involving leadership signals the strategic significance of the issue.

Time pressure in the renewal process typically manifests as shortened offer validity windows, linking renewal offers to time-limited incentives, or emphasizing upcoming price changes. These communication patterns are part of the normal SAP negotiation framework. The counter-strategy is sufficiently early renewal preparation that allows you to review offers, evaluate alternatives, and negotiate without time pressure. Starting renewal preparation 18 months before contract expiration puts the governance moment on your side.

Room to maneuver within a deep RISE integration starts with precise knowledge of your own dependencies: which data, interfaces, and custom developments are SAP-specific? Which contract clauses limit your options at renewal? On that basis, targeted measures can be taken: documenting technical dependencies, reviewing exit options (without a transition needing to be planned), preparing early for renewal, and building a strong internal negotiating position through complete usage and cost transparency.

That depends on the contract clauses, particularly the change-of-control and assignment provisions. Typically, transferring a SAP contract to a different legal entity requires SAP's written consent. This consent requirement should be addressed as early as possible in the M&A process, because SAP's internal decision processes take time. Reviewing SAP contract clauses for change-of-control provisions in advance is part of a complete M&A due diligence.

Affiliate licensing refers to the right of group companies to use SAP products under an existing master contract. The definition of "affiliate" is governed by the contract and is typically tied to the contracting party holding a majority interest. Affiliate licensing is relevant during M&A transactions (when new entities join the corporate group), during carve-outs (when entities leave), and during organic expansion into new group companies.

Escalation documentation that is useful in negotiations includes: the date and duration of the escalation situation, documented SLA deviations (response times, resolution times), the impact on business operations, all formal escalation steps with contacts and responses, and the outcome. This documentation should be maintained on an ongoing basis and treated as part of the contract history. During renewal preparation, it is a concrete input for assessing contract performance and for formulating requests for SLA adjustments.

External support is appropriate during complex renewals, audit situations, M&A transactions with SAP contract implications, and the initial build-out of a SAP governance function. These phases call for specialized knowledge that is not available internally at the required depth. Internal know-how is sufficient for ongoing operations when there is complete documentation of the contract structure, a functioning governance calendar, and the four roles are adequately staffed and coordinated. Internal competence should be built to the point where it can independently manage the ongoing governance moments.

In practice, the hybrid model is often the pragmatic entry point: internal roles stay in their departments, a coordination owner is designated, and external support is brought in for cross-functional tasks such as usage analysis and governance moment preparation. The decisions remain internal.

Governance tasks are then distributed informally or absorbed into day-to-day operations. This works for a period of time, as long as no extraordinary events arise. As portfolios grow, renewals approach, or first escalations occur, it becomes clear that informal structures are not sufficient.

Quarterly is the right rhythm for most organizations. For contracts with active renewal processes or ongoing escalations, a monthly governance round cadence makes sense.

By ensuring that every alignment produces a concrete output: a decision, a decision brief, or a documented finding. Alignments without output are an indicator that the process is not sufficiently structured.

SAP's renewal processes have internal lead times. The AE has incentives to place the offer within a specific window in their own fiscal year. For customers, this means that starting renewal preparation internally before the external offer arrives is structurally the right approach.

The CSM is responsible for adoption and usage depth, not commercial contract governance. For pricing, renewal terms, and contract modifications, the right contact is the AE, supplemented by commercial teams where needed. Routing commercial questions through the CSM typically creates longer resolution cycles.

Commitments, including informal ones, should be captured in writing: what was agreed, by when, and by whom. This matters especially for statements about usage data, SLA interpretations, and commercial commitments made outside of formal proposals. Written notes are the foundation for ongoing contract governance, not optional documentation.

No. The CSM is focused on adoption, not commercial contract governance. For questions about terms, renewal options, or billing details, the AE is the right contact. For technical questions, go to the TAM.

Every add-on proposal changes the contract structure and creates downstream costs over the term. Before deciding, you should assess which components will actually be used, what maintenance costs will be generated, and whether the bundle can be negotiated as separate items.

At a minimum quarterly, for a structured review covering contract status, usage development, and open items. In addition, on an event-driven basis at specific governance moments such as renewal preparation, escalations, or strategic portfolio decisions.

Technical escalations, meaning issues with system performance, SLAs, or infrastructure, belong with the TAM. Commercial escalations, meaning questions about terms, billing errors, or contract interpretation, belong with the AE, who routes them internally as needed.

A certain degree of technical dependency is structurally unavoidable for a core system like SAP. Contractual and organizational lock-in, however, are largely manageable. The goal is not to eliminate all dependencies but to govern them deliberately.

18 to 24 months before contract expiry is the right starting point for structured renewal preparation. Organizations that begin only six months out have already foreclosed most of their options. Your governance calendar should make this timeframe automatically visible.

Auto-renewal provisions are typically found in the term and termination section of the contract. The key questions are how long the notice period is and whether the renewal takes effect automatically on the same terms or whether SAP has the ability to introduce adjustments.

These are two different objectives. The countermeasures described here are not aimed at a system migration. They are aimed at keeping your negotiating position informed throughout the ongoing SAP relationship. Knowing your exit options is part of that informed position, without any intent to switch being required.

The four countermeasures do not require comprehensive SAP expertise in-house. They require a clear role assignment, a structured documentation practice, and an active governance calendar. For specific phases such as renewal negotiations or complex contract clause assessments, external support remains valuable, but as supplemental input, not as a permanent substitute for internal governance.