SAP AI in RISE Contracts: Consumption Tracking

RISE with SAP contracts bundled AI capabilities sold as "included" are anything but transparent. SAP bills AI consumption through AI Service Units—a consumption metric tied to BTP AI Core interactions, SAP Joule usage, and other proprietary AI workloads. The problem: SAP controls the meter, SAP interprets the consumption rules, and you see only what SAP decides to show you.

Most enterprises sign RISE deals with AI Service Unit budgets (often 100 million, 500 million, or 1 billion units annually) and discover consumption patterns only after the fact—when overages appear on invoices or services degrade. This is not a compliance gap. This is by design. SAP's opaque consumption tracking creates two outcomes: either you underspend your budget (and waste committed spend), or you exceed it and face penalties or supplementary billing.

The solution is not to trust SAP's dashboards. The solution is to build your own consumption intelligence using SAP's APIs, logs, and billing data—and to negotiate contract terms that give you real-time visibility before penalties apply.

What SAP Tracks and What You Don't See in Real Time

SAP's AI consumption tracking operates across three layers:

• SAP BTP AI Core: The underlying cloud service that logs all AI API calls, vector database operations, and inference requests. Consumption is tracked in real time by SAP's backend systems.
• SAP Joule interactions: Every prompt-to-response cycle involving SAP's copilot (Joule) consumes Service Units. This includes queries in S/4HANA, SuccessFactors, Ariba, and other modules.
• Custom applications running on BTP: Any third-party or custom AI application deployed on the Business Technology Platform that calls AI services counts against your quota.

SAP tracks all of this. You do not.

The disconnect occurs because SAP stores detailed consumption logs in its BTP administration console, but does not expose real-time granular data to enterprise users. Instead, SAP provides aggregate snapshots:

• Monthly summaries in SAP for Me (delayed by 2–3 weeks)
• Weekly dashboards in AI Launchpad (showing trends but not transaction detail)
• Quarterly usage reports in your RISE contract invoice (after consumption is locked)

This asymmetry is intentional. SAP controls the consumption definition, the meter, the data, and the invoice. You control nothing except your budget approval and your ability to negotiate contract terms before signing.

The practical consequence: You cannot accurately forecast AI overage risk during the contract year. You cannot identify which applications or teams are consuming the most units. You cannot perform what-if analysis ("If we deploy Joule to Finance by Q2, how much will our consumption increase?"). You only see the problem after it manifests.

BTP AI Service Unit—How the Consumption Meter Works

AI Service Units are SAP's abstraction layer for all AI consumption in RISE. Unlike traditional software licenses (which cap users or modules), Service Units are a consumption pool: you get a fixed annual budget, and every AI interaction reduces that pool.

The unit cost varies by AI workload type:

• Inference queries: A single Joule prompt-and-response = 1-10 Service Units (SAP's definition is vague, varies by model and complexity)
• Embedding/vector operations: Creating or querying embeddings = 1-5 Service Units per request
• Fine-tuning and training: Custom model training = 100s or 1000s of Service Units per job
• Batch processing: Large document analysis or bulk inference = variable units based on tokens/documents processed

SAP's definition of "1 Service Unit" is opaque by design. It encompasses compute, memory, API calls, and data transfer, but SAP does not publish a clear formula. This means:

• You cannot predict Service Unit cost before deploying an application
• You cannot compare two different AI features' consumption impact
• You cannot optimize your code or queries to reduce unit consumption without trial and error

In practice, Service Units accumulate quickly. A single team running Joule searches for 20 hours per week can consume 5–10 million units annually. A deployed AI application handling 10,000 transactions per day can consume 50–100 million units per year. With a 500 million unit annual budget (a typical mid-market RISE AI allocation), you're not as protected as the number suggests.

The consumption curve is non-linear. As adoption grows (more users, more modules, more integrations), consumption accelerates. By Q3 or Q4 of a contract year, many enterprises realize they're on pace to exceed budget—and by then, renegotiation is expensive and urgent.

SAP Joule Usage Metrics—What Counts as a Billable Interaction

SAP Joule is the copilot that enterprises interact with most directly. Understanding what counts as billable consumption is critical.

Every Joule interaction counts:

• Single prompt-and-response in S/4HANA (e.g., "Summarize this sales order") = 1 billable interaction
• Multi-turn conversation (Joule remembers context) = 1 unit per turn
• Joule query that triggers a backend API call (e.g., "Get last month's revenue by customer") = 1–2 units (the query itself + backend fetch)
• Joule generating code snippets or SQL = 1 unit (for the generation; execution may incur additional costs)

SAP's rule: if a user sees a Joule response, a Service Unit was consumed. No exceptions, no free tier, no threshold.

This creates a hidden consumption vector: accidental usage. A user opens Joule to explore a feature, tries three different prompts, then abandons the query. That's 3 Service Units spent on exploration. If 500 users do this across your organization once per week, you're burning 1.5 million Service Units per year on experimentation alone.

SAP does not publish per-request costs. However, based on enterprises' post-audit reports and SAP's public pricing, the rough breakdown is:

• Basic Joule queries: 0.1–1.0 units per interaction
• Complex multi-step queries: 2–5 units
• Joule + ML model invocation: 5–20 units
• Joule fine-tuning job: 1000–10000 units per job

These numbers are illustrative. SAP's actual formulas are proprietary and change based on model updates, load, and other factors. The bottom line: you cannot predict Joule consumption without external measurement.

Joule Availability and Hidden Costs

Joule is sold as "included" in most RISE contracts. What is not disclosed: Joule availability and responsiveness vary based on AI Service Unit consumption. If your quota is exhausted or oversubscribed, Joule may be throttled or disabled entirely—without warning, and without compensation credits. This is a form of service degradation that SAP does not advertise upfront.

Why SAP's Monitoring Tools Are Insufficient for Enterprise Planning

SAP provides three primary monitoring tools for AI consumption:

1. SAP for Me (Dashboards and Reports)

SAP for Me is the primary self-service portal for RISE subscription management. It includes AI consumption metrics, but with critical limitations:

• Lag: Consumption data is updated weekly or monthly, not in real time
• Aggregation: Data is rolled up by service (Joule, BTP AI Core, etc.) with minimal drill-down capability
• No granularity: You cannot see consumption by application, user, or transaction type
• No alerting: SAP for Me does not alert you when consumption is trending above budget or approaching quota
• Read-only: You cannot control or throttle specific workloads from SAP for Me

For example, SAP for Me might show: "AI Service Units consumed this month: 45 million." It will not show: "Joule in S/4HANA Finance module: 20M units; Custom forecasting app: 15M units; BTP AI Core batch jobs: 10M units." This lack of visibility prevents targeted cost control.

2. BTP AI Launchpad (Developer Console)

The BTP AI Launchpad provides more granular insights than SAP for Me, but is designed for developers, not enterprise planners:

• Shows API-level consumption for BTP AI Core services (embeddings, inference, fine-tuning)
• Includes timing and performance metrics for AI model calls
• Allows you to set service-level quotas for individual applications
• Provides event logs (what queries were run, by whom, when)

The drawbacks: AI Launchpad covers only BTP-deployed applications, not Joule (which runs on SAP's cloud infrastructure). This means you can monitor custom AI apps but not the copilot that end users are interacting with daily—which is often the largest consumption driver.

3. RISE Invoice and Usage Attachments

After each month, SAP appends usage details to your invoice. These are the most accurate numbers available but come too late for corrective action. By the time you see the invoice, the consumption has occurred, and overage charges are locked in.

All three tools have a fatal flaw: They are reactive, not predictive. You see what was consumed, not what will be consumed. This makes budget forecasting a guessing game and prevents enterprises from optimizing spend before year-end.

How to Build Your Own AI Consumption Tracking Framework

The only reliable way to control AI overage risk is to build your own consumption tracking system outside of SAP's dashboards. Here's a practical framework:

Step 1: Extract Detailed Consumption Logs from BTP

SAP exposes AI consumption data via BTP's Usage and Analytics APIs. Set up a scheduled job (daily or hourly) to pull:

• Per-service consumption (BTP AI Core, Joule, embeddings, etc.)
• Per-application or per-module breakdown
• Timestamps and transaction counts

Store this data in your own data warehouse or BI tool (Tableau, Power BI, Analytics Cloud, etc.). SAP's APIs are not real-time but are typically available within 1–2 hours of consumption.

Step 2: Model Consumption Growth and Forecast Year-End

Use historical consumption data to project forward:

• Calculate month-over-month consumption growth rate
• Apply growth rate to remaining contract months to estimate year-end total
• Compare forecast to annual budget and identify overage risk
• Recalculate weekly as new data arrives

Example: If consumption was 40M units in Month 1, 50M in Month 2, and 60M in Month 3 (33% growth), a 500M annual budget will be exhausted by Month 9. This gives you 5–6 months to optimize, negotiate, or plan for supplementary billing.

Step 3: Identify High-Consumption Workloads

Use application-level and module-level data to pinpoint which systems or teams consume the most units:

• Is Joule in Finance consuming more than Joule in HR?
• Is your custom forecasting app consuming more than expected?
• Which user segments (by department or role) trigger the most Joule queries?

Once you identify the drivers, you can optimize selectively (e.g., reduce Joule enablement in low-value modules, optimize the forecasting app's API calls, implement usage governance).

Step 4: Implement Consumption Alerts and Governance

Set thresholds in your BI tool:

• Alert if monthly consumption exceeds a target (e.g., 40M units/month for a 500M annual budget)
• Alert if consumption growth rate is accelerating above trend
• Alert if a single application or module exceeds a per-unit cost baseline

Use these alerts to trigger governance conversations: Which teams should reduce Joule usage? Which applications can be optimized? Should we negotiate a higher budget, or should we deprioritize certain AI features?

Step 5: Negotiate Consumption-Based Adjustments with SAP

Armed with your own data, you can negotiate contract adjustments mid-year:

• Provide SAP with your consumption analysis and forecast
• Request a budget increase if you're on pace to exceed the original allocation
• Request a credit or reduction if you're significantly underspending
• Request a change to the consumption definition (e.g., exempt certain low-value interactions from billing)

SAP is less likely to negotiate if you have no evidence. SAP is more likely to negotiate if you present clear, detailed consumption data and a credible forecast. This is why building your own tracking framework is so valuable.

The response includes per-service, per-application consumption broken down daily. Iterate over your full contract year to build a complete consumption profile.

Warning Signs You're Approaching Overage Territory

Watch for these indicators that you're trending toward budget exhaustion:

1. Month-over-Month Consumption Growth Above 10%

If consumption grows more than 10% per month, you're accelerating toward overage. A 15% monthly growth rate will exhaust a 500M unit budget in 7 months. This is not uncommon when Joule adoption ramps up across multiple business units simultaneously.

2. Joule Adoption Exceeds Initial Projections

Enterprises often underestimate Joule adoption. If actual Joule usage is 50% higher than your pre-contract forecast (e.g., 50 teams using Joule daily instead of 25), consumption will exceed budget. This is a clear warning sign to either throttle adoption or negotiate a higher budget.

3. New AI Applications Deploy Faster Than Expected

Every new custom AI application or Joule integration adds consumption. If your roadmap is aggressive (e.g., 5 new AI-enabled modules launching in Q2), you're stacking consumption risk. Build buffer into your budget.

4. SAP for Me Shows Consumption Spike Without Explanation

A sudden jump in AI Service Unit consumption often indicates a runaway process, an unoptimized query, or a bug. Investigate immediately. Examples:

• A batch job that should consume 1M units per month suddenly consumes 10M
• A team's Joule usage doubles without announced policy changes
• A new integration starts consuming more units than estimated

Without your own tracking, you'll miss these spikes until the next invoice. With your own framework, you catch them within hours.

5. Your Budget-to-Date Ratio Hits 80% by Month 10

If you've consumed 80% of your annual budget by Month 10, you have only 2 months to consume 20% of your remaining budget. This is a high-risk signal. Communicate with your SAP account team immediately and begin negotiating supplementary budget or consumption controls.

6. Joule is Disabled or Throttled Without Notice

SAP can silently disable Joule or degrade responsiveness if you exceed quota. If users report that Joule is slow or unresponsive, check your consumption metrics. You may already be at or above your limit.

What Happens When You Exceed Your AI Quota in RISE

Unlike traditional software licenses (which prevent overuse through hard enforcements), RISE AI quotas are soft-enforced by billing. Here's what happens:

Scenario A: You Exceed Budget by 10–25%

• Year 1: SAP bills overage charges on a per-unit basis. Cost: 10–25% additional fee on your AI spend (often 20–30% per unit premium for overage).
• Year 2 (contract renewal): SAP uses Year 1 overage data to propose a higher base allocation. You're forced to commit to a larger (and more expensive) annual budget.

Scenario B: You Exceed Budget by 50%+

• Service throttling: Joule response times increase. AI queries fail or timeout. Custom applications experience latency.
• Feature lockout: SAP may disable advanced Joule features (e.g., fine-tuning, batch processing) to reduce consumption.
• Overage billing: SAP charges a 30–50% premium on overage units, making supplementary AI spend extremely expensive.
• Contract renegotiation: SAP uses the overage as leverage to increase your base allocation and lock in a multi-year commitment at a higher price.

Scenario C: You Significantly Underutilize Your Budget

• Unused Service Units do not roll over. They are forfeited at contract year-end.
• SAP uses your underspend as evidence that you over-bought. On renewal, SAP proposes a lower allocation (and potentially higher per-unit costs).
• You lose leverage in future negotiations because SAP has data showing you didn't need the allocation you committed to.

The critical insight: SAP has an incentive to ensure you either overspend (to collect overage fees) or underspend (to reduce your power in renewal negotiations). There is no "just right" outcome from SAP's perspective. The only way to protect yourself is to maintain precise, defensible consumption forecasts and renegotiate proactively before year-end.

FAQ: Common Questions on AI Consumption Tracking

Related Articles in the RISE AI Series

• SAP AI in RISE Contracts: The Complete Enterprise Guide — Comprehensive overview of AI in RISE: capabilities, architecture, and buyer strategy.
• What Enterprises Need to Know About SAP AI in RISE — Key gaps between SAP's marketing and operational reality.
• SAP AI in RISE Contracts: Pricing and Budget Planning — Deep dive into AI Service Unit economics and multi-year cost modeling.
• SAP AI in RISE Contracts: Negotiation Approach — Tactical guidance for negotiating favorable AI Service Unit terms with SAP.