What SAP Joule is, and which parts can touch money
SAP Joule is SAP's AI copilot across its cloud applications, and in 2026 it is three things at once. Joule Base is included with every SAP cloud subscription at no extra cost and consumes no AI Units. Joule Agents are SAP-delivered agents that plan and act across multiple steps, coordinated by Joule Assistants, and SAP said at Sapphire in May 2026 that it now ships more than 50 assistants and more than 200 agents. Joule Studio is where you build your own: the classic edition's agent builder became generally available in December 2025, and the new Joule Studio announced on 13 May 2026 targets general availability in Q3 2026.
Several of these SAP AI agents sit directly on money. SAP's public agent catalog lists a Receivables and Payables Clearing Agent that proposes postings, a Cash Positioning Agent that proposes bank transfers, a Sourcing Negotiation Agent in Ariba that sets counteroffer target prices, and Concur agents for expenses and booking. The Spend Management assistants for Requisition, Buying and Invoicing were scheduled for general availability between June and September 2026.
SAP describes real controls around these agents: each agent has its own identity, traffic runs through an agent gateway so an agent can only do what the end user is permitted to do, and SAP states that high-risk processes always require explicit human approval. What SAP's marketing does not describe is a spending limit. So we went to the developer tooling, where a limit would have to be declared.
We measured SAP's public Joule Studio packages: 480 property names, zero money fields
On 26 September 2026 we pulled every Joule package SAP publishes to the public npm registry, with no SAP account and no authentication: @sap/joule-studio-cli and @sap/joule-studio-cli-core 2.0.2 (published 12 August 2026), SAP's Joule project generator @sap/generator-joule 1.6.7, and the Joule Studio developer CLI for early adopters, 0.1.20-alpha.25 (19 August 2026). We added the two SAP Cloud SDK for AI packages that front SAP AI Core and its orchestration service, both 2.16.0, released at 01:21 UTC on the morning of the probe.
The Joule Studio tooling ships nine JSON schemas. Together they define everything a Joule assistant, capability, dialog function, MCP server connection, evaluation package and deployable solution is allowed to contain: 107 distinct property names. Across the 391 type declaration files in the three Joule packages there are 433 distinct declared names, or 480 unique names once the two sets are combined. We ran a money regex over all of them: amount, currency, budget, spend, price, cost, payment, invoice, monetary, dollar, purchase, usd, billing, charge, fee, wallet, card.
It returned zero hits in the schemas and zero hits in the type declarations. The only limit-shaped names in the whole Joule schema set are max_file_size and max_files_allowed, which govern uploads.
The only number on a Joule agent is how many times it may reason
SAP's generator scaffolds a Joule agent from a template with eight settings: agent, expert_in, iterations, base_model, advanced_model, default_output_format, task, and an optional orchestration_config for content filtering.
iterations is the only numeric control on the agent. The generator validates it as a whole number greater than 0 and no more than 100, and the default it writes is 100, which is the maximum. The default base model is gpt-4o-mini and the default advanced model gpt-4o.
The filtering block is real and worth using. It routes input through a content safety filter with thresholds for Hate, Violence and SelfHarm. Those are the categories an agent can be graded on. An amount is not one of them.
One detail in SAP's own template makes the point better than we could. Its commented example describes a calculator step that takes UnitPrice * (1 - Discount) to price products in an order. The agent is expected to reason about prices. Nothing in its definition bounds them.
SAP's own procurement template creates a purchase order with no price and no confirmation
The Joule generator ships two starter projects. One is a weather lookup. The other is procurement, and it includes a function called create_purchase_order.
That function takes four parameters: purchase_requisition_id, material_id, shipping_address and quantity. There is no price, no amount, no currency and no approver. Its action list has two steps, a status-update message and a set-variables step that assigns the new order an ID.
To be fair and precise: this is a demo. SAP's own comment in the file says a productive scenario would call a backend service at that point to persist the order, and a real S/4HANA purchase order would then run through whatever release strategy your procurement team configured. The template is not SAP's production procurement agent.
What it does show is the shape SAP teaches developers first. Joule's function language includes a user-confirmation action, which puts a title, a subtitle and Confirm and Cancel buttons in front of the user, and the procurement example does not use it. Even where it is used, the schema for that action permits exactly those fields and nothing else. There is no property for an amount, a threshold or a named approver, so a confirmation step fires on every call or on none, never on "anything above 5,000 dollars".
SAP AI Core quotas count replicas and templates, not dollars
Joule agents built in Joule Studio run on SAP Business Technology Platform, with models served through SAP AI Core and its generative AI hub. So we measured that layer too.
The SAP AI Core API package declares 296 distinct property names. The money regex returned two. One is a false positive: statusDetails matches only because "statusDetails" contains the letters u, s, d. The other is genuine, a cost field on a model version, documented as a "list of costs associated with the model". It is catalog metadata you can read, not a ceiling you can set.
AI Core does have quotas, and every one of them is a count: maxCount, maxReplicaPerDeployment, servingTemplateMaxCount and workflowTemplateMaxCount. The orchestration service adds max_tokens and max_retries. These bound how much compute an agent can occupy. None of them is denominated in money.
The control: SAP models money in detail one layer down
An absence only means something if the method could have found a presence. So we ran the identical regex over SAP's own published data model for the S/4HANA purchase order API, the package SAP released for its Cloud SDK (@sap/cloud-sdk-vdm-purchase-order-service 2.1.0, from 2022 and since deprecated in favor of generated clients, but still SAP's own model of that API).
It lit up. Of 258 distinct properties, 31 are genuine money fields once you set aside purchase order ID fields: netPriceAmount, documentCurrency, downPaymentAmount, conditionAmount, purgDocNetAmount, paymentTerms, costCenter, budgetPeriod, and most tellingly overallLimitAmount and expectedOverallLimitAmount.
That is the whole finding in one comparison. SAP's purchase order carries an overall limit amount. The Joule layer that can create that purchase order carries no amount at all. SAP knows exactly how to model a spending limit. It has placed every one of them in the ERP, and none in the agent.
What SAP meters instead: AI Units, at 8.06 dollars each
SAP does govern one kind of spending tightly, its own. Premium AI, which covers Joule Agents, is paid in AI Units, bought annually into a shared pool under SKU 8019164. SAP's pricing page states that SAP-delivered agents are priced at 0.02 AI Units per agent action, where an action is one step such as calling a service or triggering a workflow, and that unused units expire after 12 months.
SAP Discovery Center publishes the conversion rate: 1 AI Unit = 8.06 US dollars. So a standard agent action lists at about 16 cents. In SAP's catalog in September 2026, 52 of 63 agents are marked billable, and some of the most finance-sensitive ones, including the Receivables and Payables Clearing Agent and the Cash Positioning Agent, currently list at 0.00 AI Units per action. The Shopping Agent lists at 0.20. Our SAP Joule pricing breakdown works through the arithmetic.
Notice what the meter measures. SAP for Me shows AI Unit consumption in near real time and lets an administrator deactivate an agent to stop usage, and usage beyond the pool is billed as excess use. That is a view of what the agent costs SAP to run. The cash an agent moves, a 40,000 dollar bank transfer proposal or a supplier payment, is not denominated in AI Units and never appears on that meter. An agent can be free to run and still move real money.
Why SAP's design is reasonable, and where it still leaves you exposed
The fair reading first. SAP's bet is that the ERP is the control. When a Joule agent creates a purchase requisition or a purchase order inside S/4HANA or Ariba, that document enters the same release strategy, approval workflow and budget check as one a person keys in. If your agents only ever write documents into SAP, and your SAP approval rules are sound, the amount is governed, just not by Joule. That is a coherent architecture and for many SAP shops it is enough.
The exposure is everything that does not pass through an SAP document. Joule Studio agents connect to external systems through API destinations and MCP servers, and the MCP schema SAP ships has a name, a path and a timeout, with no limit of any kind. An agent that renews a SaaS subscription on a vendor portal, tops up an API balance, books travel outside Concur, or pays through a card or a payment API never produces an SAP purchase order. Your release strategy never sees it.
There is a second, quieter gap. SAP approval rules were written for people, who create a few documents a day. An agent with 100 reasoning iterations can create many small ones, each under the threshold that would have triggered a release. Per-document limits do not add up to a monthly ceiling per agent.
So the practical question is not whether SAP has controls. It is how much of what your Joule agents will spend actually lands as an SAP document. Where the answer is "all of it", configure release strategies and stop there. Where it is "most of it", the remainder needs a per-agent budget in dollars, a merchant allowlist and an approval threshold that fires on the amount.
A rollout checklist for Joule agents that can spend
- Classify every agent by where its money lands. Agents that only create SAP documents inherit your release strategy. Agents with an API destination, an MCP connection to a vendor, a card or a payment API do not.
- Lower
iterationsfrom the default. The generator writes 100, the maximum. Set it to what the task needs, because it is the one numeric brake the agent definition gives you. - Turn on the content filtering block. It is free to configure in
orchestration_configand it is the only graded threshold Joule exposes today. - Put a
user-confirmationstep in front of every function that commits. It cannot key on an amount, so apply it to the functions that create orders, approve invoices or release payments, not to lookups. - Check that SAP release strategies cover agent-created documents. Confirm the agent's technical user is not exempt and that thresholds are sized for many small documents, not a few large ones.
- Add a dollar ceiling for everything outside SAP. Give each agent its own funded wallet or virtual card with a monthly limit, lock it to approved merchants, and route anything above your threshold to a named approver.
- Reconcile monthly per agent. Pull the agent's SAP documents and its card or wallet statement side by side so cost per outcome is a number you can defend at close.
AgentsPay is built for step six. Each Joule agent gets its own wallet and scoped virtual card, a budget in dollars that is cumulative rather than per conversation, spend controls by merchant and category, approval thresholds that fire on the amount, and an audit trail you can reconcile against SAP. SAP keeps governing the documents. The wallet governs what the agent can pay outside them.
We have measured the same pattern across nine other enterprise platforms. UiPath ships a policy check named budget that counts tool calls, Workday registers agents in a system of record with no monetary field, Oracle AI Agent Studio and ServiceNow AI Control Tower govern identity and access in depth, and Microsoft Agent 365 has no money property anywhere in its Graph schema.