A technical reference series for Finance and IT Professionals

This post is the anchor for a growing series on AI-driven autonomous finance in SAP—covering the data layer, agent architecture, governance model, and what separates production-ready AI from a proof of concept. New articles will be linked from this page as they are published.

That is not a failure of the existing system. The automation already in place handles what it was designed for, reliably and at scale. The question is whether it is possible to extend that automation further, into work that requires judgment and handles exceptions; work that has, until now, needed a human in the loop.

That is not a people problem. It is an architecture problem. And it is the problem that SAP has been solving progressively: first by building the most reliable and governed ERP core in enterprise finance, then by extending it with embedded machine intelligence, and now by adding a third layer on top of both: agents that do not just automate tasks but reason about them, act on them, and remain fully accountable for every step.

Decades of building the foundation

SAP did not arrive at Autonomous Finance overnight. The path runs through three generations of capability added to the same trusted core, each one building on the layer before it. Understanding that progression is what makes it clear why Joule Agents can be trusted in places where generic AI cannot.

The proven core: Rule-based automation and SAP S/4HANA

Deterministic, reliable, and deeply embedded in SAP's ABAP core. If the condition is met, the action fires. This is the layer that runs the financial operations of the world's largest companies: millions of postings processed correctly, every time, with a full audit trail. SAP S/4HANA (On-Premise), SAP S/4HANA Cloud Private Edition, and SAP S/4HANA Cloud Public Edition all sit on this foundation. It is not a legacy to be replaced; it is the governance infrastructure that makes everything above it trustworthy. As finance complexity grew, the same teams that mastered it asked a new question: could the system also help with the work that does not fit a deterministic rule?

Adding intelligence: Predictive analytics and machine learning

SAP extended that foundation by embedding ML models directly into finance processes, trained on the same governed data already living in SAP S/4HANA. Payment risk scoring, trade item classification, posting anomaly detection, cash flow forecasting: pattern recognition at scale, without explicit rules. This was a genuine expansion of what the platform could do. What the teams running these models eventually asked for was more: not just a score or a flag, but a system that could act on the insight, explain its reasoning in terms an auditor could follow, and handle multi-step workflows end to end.

AI agents: Reasoning, acting, and staying accountable

The third layer is not a replacement for the first two; it depends on them. An AI agent running in SAP S/4HANA Finance has access to the governed ABAP data layer, the predictive analytics that the platform continuously generates, and the full authorization and compliance framework of SAP S/4HANA. That is precisely what allows a Joule Agent to do things a rule engine or predictive model cannot: read an email alongside live transaction data, determine the right sequence of actions, execute them directly in SAP S/4HANA, and adjust course if conditions change mid-process. The question SAP had to answer was not whether this was possible in theory, but how to make it work inside the governance, compliance, and auditability requirements of enterprise finance while preserving everything the first two layers already guarantee.

Why agents, and not RPA?

Robotic Process Automation works well for structured, repetitive tasks with predictable inputs. It executes the same sequence reliably — but it does not handle exceptions, ambiguity, or unstructured content. When the process deviates, RPA stops or fails silently.
The distinction is not that agents replace RPA. It is that they operate at a different layer. The three-layer architecture above already captures this: rule-based automation handles the deterministic, embedded machine learning handles the pattern-driven, and agents handle the judgment-heavy exceptions — precisely the work that RPA cannot reach. Each layer does what it does best; none of them tries to do what the others already do well.

Why generative AI falls short in finance

The finance function is not forgiving of approximation. A misposted journal entry is not a user experience issue; it is a compliance event. A forecast that reflects the wrong cost center is not a minor inaccuracy; it is a decision made on false premises. When people say AI is "hallucinating," they are describing a behavior that is professionally irrelevant in most consumer contexts but existentially unacceptable in financial operations.

Generic large language models are trained on internet-scale text. They produce plausible outputs. They do not know your chart of accounts, your intercompany structure, your approval hierarchies, or which currency pairs your treasury team is hedging this quarter. They are intelligent about the world in general and without context about your business in particular.

SAP's position is different for four reasons that were built over decades, not added on top of a language model:

• Process and domain knowledge. Over five decades of finance process expertise encoded in SAP applications, the SAP Knowledge Graph with 7.3 million semantically linked data fields, and purpose-built financial models that produce 3.5 times higher prediction quality than generic LLMs across 120+ mission-critical finance processes.
• Data with business context. A customer record linked to a contract, a material tied to a purchase order, a payment term connected to a credit risk rating. Every data point arrives with the business context that makes AI conclusions trustworthy in finance.
• Governance by design. ISO/IEC 42001-certified AI management, with 100% of AI workloads running under certified controls. Governance is not added after the fact; it is part of the architecture from the first line of code.
• Authorization enforced at the data layer. Joule Agents operate within the same role and authorization framework that governs every user action in SAP S/4HANA. An agent cannot post to an account a user cannot post to. That constraint is enforced at the CDS and OData layer; it is not a policy wrapper applied on top; it is the same technical boundary that every human transaction must pass through.

The architecture: How assistants actually work end to end

The image below shows how Assistants work end-to-end across finance processes. An Assistant sits at the top of the hierarchy as an Orchestrator, coordinating a set of specialized Agents, each of which operates through one or more Joule Personas, backed by Joule Scenarios, OData services, and CDS Views all the way down to the governed data in SAP S/4HANA. Here is what each layer in that hierarchy actually does.

Simplification note: The following describes the architecture in accessible terms. The actual implementation is more complex and continues to evolve.

Starting from the bottom of the stack:

• CDS Views and OData Services form the governed data interface. Security, data privacy, SOX compliance, and SAP Product Standards are enforced here. Every agent action that reads or writes data must pass through this layer, which means the access control framework that governs a Fiori transaction governs an agent action in exactly the same way.
• Joule Skills are purpose-built functions, each designed to perform exactly one operation within SAP S/4HANA — retrieving a specific data set, evaluating a condition, or triggering a defined action. A Joule Scenario groups the Skills needed for a complete process into a structured interface, defining how they connect and in what sequence.
• Joule Personas bring together the Scenarios — and through them, the Skills — relevant to a specific user role into a single end-to-end process view. A finance professional working through Joule does not switch systems; the Persona assembles everything that role needs in one place.
• Agents are built on one or more Joule Personas. They are the specialized digital coworkers: they take action on governed SAP data, autonomously, within the boundaries their configuration defines. Examples include the Journal Entry Agent, the Cash Positioning Agent, the Billing Anomaly Agent, and the International Trade Classification Agent.
• Assistants are teams of Agents coordinated by an Orchestrator Agent. The Orchestrator does not execute tasks itself; it delegates to the right Agent, synthesizes outputs, manages sequencing, and drives complex multi-step workflows across the entire domain. Examples include the Financial Closing Assistant and the Tax and Compliance Assistant.
• Autonomous Finance is multiple Assistants operating together across the full finance function simultaneously, without requiring a human to coordinate between them.

How an agent gets built: The lifecycle behind the architecture

Understanding the architecture is one thing. Understanding the discipline required to build agents that are reliable, auditable, and continuously maintainable is another. SAP has invested significantly in defining and operating the full lifecycle of its agents, from ideation through ongoing support, as a structured engineering process.

The lifecycle of a Joule Agent begins long before it is released. It starts with ideation informed by customer input and market signals, moves through a design phase that must comply with the Northstar Architecture (SAP's internal standard for how agents are conceived and structured), and passes through several mandatory onboarding stages before a single line of agent code is validated for development.

Consistency across deployment options is a design requirement, not an afterthought. The ideation, customer input, and design process for Joule Agents is aligned at the source to ensure consistent behavior across SAP S/4HANA Cloud Public Edition and SAP S/4HANA Cloud Private Edition.

Ongoing support is treated with the same rigor as development. When an agent does not behave as expected in production, clear procedures and collaboration models between Technical Support and Engineering ensure that the path from issue to resolution is as short as possible.

The agent roadmap is built with continuous input from customers and from SAP's own operations, where SAP runs its agents internally and collects firsthand feedback before external release. Early adopter programs feed that input into the next set of agents being designed across Finance, GRC, and GTS.

Before a Joule Agent can be published, it must also clear SAP's Responsible AI review. This evaluation goes beyond the technical gate: it assesses the agent for bias, fairness, explainability, and alignment with SAP's AI ethics principles. An independent ethics committee reviews the agent's design and intended behavior. Where the Onboarding Gate confirms the agent was built correctly, the Responsible AI review confirms it was built responsibly. Both are required before an agent reaches customers.

Accountability is not a feature; it is the foundation

Of all the questions that enterprise customers raise about AI agents, accountability is the one with the lowest tolerance for ambiguity. An agent that posts to the wrong account, posts without authorization, or posts in a way that cannot be traced is not a product liability. It is a compliance failure.

SAP's approach to accountability is layered and explicit:

Authorization Checks: Same Rules as a Human

Joule Agents are embedded into SAP's role and authorization framework. When a Joule Agent performs an action, the system runs the exact same authorization checks it would run if a user triggered that same action in Fiori or the SAP GUI: same rules, same boundaries, no exceptions. If the user does not have the authorization to post to a particular account, the agent does not have it either. If the agent cannot complete an action because of insufficient authorization, it reports that explicitly rather than skipping it silently. This is not a safeguard added on top of the agent; it is enforced at the CDS and OData layer that every agent action must pass through.

AEval: Continuous Behavioral Auditability

One structural challenge with AI agents that has no equivalent in deterministic ABAP code is this: agent behavior is not guaranteed to be stable over time. A change in an underlying model, a new policy loaded into agent context, or a shift in the language model's outputs can cause an agent to behave differently than it did yesterday, without any explicit code change. SAP addresses this with AEval, an evaluation framework embedded into every Finance Agent that continuously documents what was done, when, why (because of which policy), and whether the user agreed. AEval does not just confirm that an action was taken; it documents the reasoning behind it. If an agent begins to behave differently, AEval surfaces that deviation. SAP and its customers are notified. The response is traceable. This is how SAP works with auditors: not just certifying individual agents, but certifying the platform and the environment they are built in.

Human in the Loop: Still Mandatory

None of the current Joule Agents in Finance execute a posting without a human review step. The agent prepares, analyzes, and proposes. The human confirms. That is not a temporary limitation on the path to full autonomy; it is a deliberate design decision that reflects the accountability chain: the agent operates inside the enterprise's governance framework, and the human who confirms an action retains responsibility for it. As trust and certification mature, that boundary may shift. But it shifts on the customer's terms and within the platform's governance structure, not because the technology simply enables it.

The longer-term design goal is Human Outside The Loop: a model where finance professionals set the parameters, define the boundaries, and review aggregated agent behaviour across a period rather than approving individual transactions. The controller no longer signs off on every posting; they oversee what the agent did and whether it stayed within bounds. As trust and certification mature, that shift happens on the organisation's terms—not through a technology setting, but through demonstrated performance.

Two questions every CIO and CTO will ask

Can we build this ourselves?

The answer depends on where the agent is built.

Customers and partners who want to build their own agents can do so through Joule Studio and the broader SAP Business AI platform. Agents built there enter the same framework as SAP-delivered Joule Agents, inheriting the authorization model, the layered automation, and the re-certification cycle that follows every SAP release. The next section explains how.

External agents built outside the SAP platform and accessing data through API calls are a different matter. Authorization logic that works today may drift after a platform update. Every process step runs through the AI layer, including steps that SAP's own automation already handles reliably, which drives up token consumption and introduces variability where finance requires consistency. Audit traceability has to be built from scratch. All the work required to make it safe, compliant, and maintainable in a finance context becomes the customer's own engineering problem to solve.

Can we extend the platform with our own agents?

Yes, by design. Joule Studio is the tool through which custom agents are designed, created, documented, tested, and deployed. When a custom agent is built via Joule Studio, it enters the SAP framework and can use the same platform capabilities as SAP-delivered agents: the same authorization check framework, the same OData governance layer, the same multi-agent orchestration infrastructure, and the same visibility in SAP AI Agent Hub. SAP AI Agent Hub is the central place to discover, inventory, verify, and govern all agents in the landscape, whether SAP-delivered or customer-built. The accountability model follows the deployment path: if the agent was designed, created, documented, tested, and deployed through Joule Studio, it operates within the SAP framework and inherits the platform's governance. If it is custom-built outside the platform and connected separately, the accountability sits with the party who built and deployed it.

The finance function this enables

The six business areas of SAP Autonomous Finance each have a dedicated Assistant and a growing portfolio of specialized Agents. The table below shows the current state of the portfolio, not as a product list, but as a map of where in the finance function continuous intelligent operation is becoming possible today.

This portfolio continues to grow. Additional Agents and Assistants are on the roadmap, informed by customer feedback and early adopter input. Value metric estimates are based on SAP Value Engineering analysis.

Autonomous finance that learns

The architecture described in this series addresses execution: how Joule Agents act on SAP data reliably, accountably, and at scale. The next dimension is adaptation — how the system becomes more capable over time, and how it incorporates human judgement to progressively expand the boundary of what it can handle autonomously.

Predictive course correction

Beyond executing within known processes, Joule Agents with access to the SAP Knowledge Graph and SAP's embedded predictive models can sense early signals across the financial data landscape—a receivables pattern suggesting a liquidity gap two weeks out, a cost deviation in one cost centre that historically precedes a broader budget overrun. Rather than waiting for the variance to materialise, the agent surfaces the risk, models the likely trajectory, and where configured, triggers a corrective action before the event occurs. This is the shift from reactive automation to proactive financial stewardship: the CFO organisation intervenes at the right moment, with the right information, not after the fact.

Rules that the system learns

Not every financial scenario can be codified in advance. Edge cases and exceptions—the judgement calls that have always required a human—are where agents add the most immediate value. But they can also build long-term value in a different way: by observing patterns across those exceptions, proposing generalisations, and surfacing candidate rules that a finance professional can validate and operationalise. Once validated, those rules move into the deterministic layer—executed by rule-based automation, with no AI inference cost. Over time, the exception surface shrinks, the automation layer deepens, and the agent's attention concentrates on the genuinely novel cases. This is how Autonomous Finance becomes self-reinforcing: not just running the process, but progressively hardening it.

Human corrections as a learning signal

Every time a finance professional overrides a Joule Agent's proposal—adjusting a journal entry, changing a forecast, resolving a posting edge case differently—that correction is a signal, not just an outcome. SAP's Cash Application agent is an early example of this feedback loop in practice: human corrections to matching proposals are captured and used to improve future matching quality, progressively reducing the volume of exceptions that require human review. The long-term effect is that the boundary of autonomous execution expands naturally, as the system becomes better aligned with how each organisation actually makes financial judgements.

What this adds up to

Decades of building a trusted ERP foundation, extending it with machine intelligence, and embedding governance at every layer: that is what Joule Agents run on. The ABAP core, the CDS data model, the authorization framework of SAP S/4HANA, whether deployed on-premise or in the cloud, are not the thing agents work around. They are the thing that makes agents trustworthy in the first place.

That is what SAP is building with Autonomous Finance: not a product category, but a capability that was only possible once the data layer, the process knowledge, the authority framework, and the governance infrastructure were all in place and connected. Most of that work was already done. The agents are the interface to it.

The agent does not remove the human; it removes the investigation. The controller reviews the agent's analysis, reasoning, and proposed resolution; the judgment call takes minutes instead of hours. Not only fewer tasks, but qualitatively different tasks.

The controller running the monthly reconciliation they could do in their sleep will still exist next year. But the question they will be asking is a different one: not "when will I get to the strategic work," but "what does the agent need from me to take this one off my list."