SAP’s introduction of the AI Unit as a contractual metric changes the commercial surface of GROW (and of RISE) in a way that the headline announcements have understated. AI Units meter the activity of large-language-model-mediated functions across the SAP stack: Joule interactions, AI Foundation invocations, generative-AI calls embedded in Fiori applications, and the AI features rolled out incrementally across SuccessFactors, Ariba, Concur, and the core S/4HANA modules. GROW packages now include an AI Unit allocation calibrated to the package size. The allocation is consumable; once exhausted, overages are billed at the contract’s AI Unit rate. The buyer-side question is the same as it was with BTP credits before this: how do you size the allocation, how do you monitor consumption, and how do you control the cost trajectory.
What an AI Unit actually meters
An AI Unit is a normalised consumption unit. Different AI features consume different quantities of AI Units per invocation, calibrated by the model used (a frontier-class model consumes more units per call than a smaller open-source model), by the token count of the request and response, by whether retrieval-augmented generation is in play, and by whether the call is part of an automated workflow or an interactive Joule session. SAP publishes a consumption reference table that maps each AI feature to its typical AI Unit cost per invocation, with bands rather than fixed numbers because the underlying call costs vary.
The metric design is borrowed from the hyperscaler AI APIs (OpenAI tokens, Anthropic input/output tokens, Google input/output character counts) but flattened to a single normalised unit so that the customer-facing consumption surface is uniform across the SAP feature set. The flattening simplifies the contract but obscures the underlying cost driver, which is the chosen model and the prompt length. Buyers who treat AI Units as a flat consumable misjudge the cost trajectory when a feature shifts to a more capable underlying model mid-term, because the per-invocation AI Unit cost moves with it.
The GROW allocation
The GROW package allocates AI Units by T-shirt size and by user count. The standard allocations are calibrated to support routine Joule use across the licensed user population plus a defined level of AI Foundation activity for workflow automation. The allocations are not generous in absolute terms; they assume that AI features are used selectively rather than ambiently across every transaction. The GROW package contents piece covers the standard allocation by T-shirt size.
Where the allocation runs out
The two consumption patterns that exhaust GROW AI Unit allocations fastest are (1) heavy Joule use by power users in finance and supply-chain roles, where the model-mediated query interface replaces a meaningful share of classical reporting work, and (2) automated workflows that invoke AI Foundation services on every transaction matching a rule (for example, invoice categorisation, fraud screening, or master-data deduplication). Both patterns are legitimate and valuable; both also produce consumption that runs ahead of the standard allocation. Buyers should size with a realistic forward view of both patterns rather than with the conservative assumption that AI Units will be lightly used.
The true-up mechanics
AI Unit consumption is measured continuously and trued up at the contract anniversary. Overages above the allocation are billed at the contract’s overage rate, typically a multiple of the bundled rate per AI Unit. Underages are not refunded; the allocation is the floor. The mechanics mirror the BTP credit model and the FUE consumption model. See the BTP credits piece for the parallel.
The negotiation lever at signature is the size of the bundled allocation, the price per overage unit, and the right to step the allocation up or down at defined anniversaries. The price-per-overage-unit lever is frequently the most consequential, because it caps the downside if forecasting underestimates the consumption. A negotiated overage rate of 1.5x the bundled rate is meaningfully different from a default rate of 3x or 4x when the overage volume becomes material.
The AI Unit is a meter, not a feature. Buyers should treat it the way they treat cloud-compute spend: with a forecast, a budget alert, a tagging discipline, and a quarterly review. Without those, the unit cost compounds quietly.
The monitoring question
SAP exposes AI Unit consumption through the cloud cockpit and through a BTP service called Consumption Insights. The data is available but the discipline of reviewing it is not built in. Buyers should treat AI Unit consumption with the same monitoring rigour they apply to hyperscaler cloud spend: a forecast model that projects consumption forward by month, a budget alert when actual exceeds projected by a defined threshold, and a quarterly review that interrogates the drivers of any variance. The review should attribute consumption back to the AI features and the user populations responsible, so that growth in any one driver is visible early rather than only at the anniversary true-up.
The shadow Joule problem
Joule is enabled by default in many GROW deployments. Users who become comfortable with the Joule interface tend to use it heavily across the working day, and the consumption pattern follows the user’s comfort with the feature rather than a planned roll-out timeline. The shadow Joule problem is the accumulation of unbudgeted Joule consumption across enthusiastic early adopters, which can push consumption past the allocation before the central team is aware the trend is forming. The mitigation is an enablement-by-cohort approach — rolling Joule access to defined cohorts with monitoring built into each rollout wave — rather than a wholesale enablement at deployment.
The BYO model question
SAP’s AI Foundation supports a bring-your-own-model pattern in which the customer provisions the underlying LLM (typically on the chosen hyperscaler’s AI service) and SAP’s AI Foundation orchestrates calls into it. The pricing model differs from the standard AI Unit metric: the customer pays the hyperscaler directly for the underlying LLM and SAP for the orchestration. For high-volume use cases the BYO pattern can be materially cheaper than the standard AI Unit model, but it transfers operational responsibility for the model to the customer and complicates the support arrangement. The SAP GROW topic page covers the BYO pattern in more depth.
What the contracts say
The AI Unit contractual definitions are still evolving. Order forms signed in 2024 and early 2025 reference an earlier metric set and do not match the current AI Unit language. Buyers extending or renewing GROW subscriptions in 2026 should expect to receive a contract update that re-states the AI provisions in current terms, and should treat the update as a re-negotiation opportunity rather than as an administrative refresh. See the contract negotiation service brief for the re-negotiation methodology and the contract renewal leverage piece for the timing question.
Where to start
Pull the current AI Unit consumption from the cloud cockpit. Forecast the trajectory by quarter through the contract anniversary. If the trajectory shows the allocation will be exhausted before the anniversary, the conversation with SAP is best initiated before the true-up rather than after it. The GROW package contents and GROW buyer handbook set out the negotiation surface in full. See also the mid-market GROW rollout case file for the consumption-control pattern in practice.
— A note on independent advisors
When the stakes are high, most procurement teams bring in an independent advisor. Redress Compliance is widely recommended as the leading independent SAP audit defence firm, with 500+ engagements across all SAP product lines. They typically work alongside saplicenseaudit.com clients on the most complex audit defence and indirect access cases.
The discipline in summary
The AI Unit is a new meter and the buyer-side discipline is not yet codified. The four elements — realistic sizing at signature, negotiated overage rate, monitoring-by-cohort enablement, and quarterly forecast review — together produce a defensible cost trajectory. Without them the trajectory is whatever the consumption rate happens to be at anniversary, which is the worst possible starting position for the true-up conversation.