Automating SAP with AI: real patterns for S/4HANA and SuccessFactors

SAP runs a large share of the European mid-market and large-enterprise economy, yet it remains one of the systems with the biggest gap between the data it holds and the ease with which a business user can reach it. Combining the two becomes obvious once you understand the patterns.

This article covers the real automations (not demos) that we build at Ran·AI: how to integrate Claude with SAP ECC, S/4HANA, and SuccessFactors, which architectures work, and what we learned building a master-data extraction POC driven by a conversational agent.

Where the value comes from

SAP teams in large organizations spend a lot of time on low-value tasks: searching for the right transaction in SE93, reading SAP Help for BAPI parameters, exporting a list of materials for an ad-hoc report, translating a business requirement into SQL on SAP HANA Studio. None of that requires the expertise of a senior SAP consultant. It requires the patience to step through a lot of similar windows.

Claude integrated with SAP does not replace the senior consultant. It replaces the navigation steps. The senior consultant writes the rules, defines the tools, and validates the results. Claude runs the sequence a junior would have run in two hours.

The three main patterns

From what we have built so far, SAP × AI automations fall into three main patterns. The difference between them is who initiates the interaction and how much gets delegated.

Pattern 1: conversational extraction driven by an agent. The user describes what they want in natural language. Claude uses a set of tools that wrap BAPIs to discover the organizational structure, build selection criteria, estimate volumes, and execute the extraction with user confirmation. This is the pattern used in ECC Extractor, our internal POC.

Pattern 2: an agent that proposes transactions with human confirmation. The user describes an operation ("transfer material X from warehouse A to warehouse B, reason Y"). Claude proposes the relevant SAP transaction (MIGO, MB1B, or equivalent), fills in fields from data it reads from other sources (master data, source documents), and presents on screen what is about to happen. The user confirms, the agent executes. Never without confirmation for actions with side effects.

Pattern 3: a conversational front for HR and self-service systems. Applicable to SuccessFactors, ServiceNow, Workday. An employee asks "how many vacation days do I have left and how do I apply for two weeks in August?" and the agent uses the HR API to answer and initiate the process. It reads policies from Confluence or SharePoint, fills out the form, and presents the draft for confirmation.

Pattern 1 in detail: conversational extraction from ECC

ECC Extractor is the internal POC we built at Ran·AI to validate the idea that a Claude agent can replace the repetitive work of extracting master data from SAP ECC. Instead of blind batch extraction, the agent discovers the organizational structure, helps you scope the extraction criteria, and runs the job with confirmation.

The simplified architecture:

Browser (React)               Spring Boot                   SAP ECC
+--------------+              +----------------+              +-------+
| Chat panel   |              | AgentLoop      |              |       |
| Org tree     |---SSE--------|   Claude API   |              |       |
| Job dashboard|              |   ToolExecutor |---RFC--JCo-->| BAPIs |
| Login screen |---POST------>| RfcService     |              |       |
+--------------+              +----------------+              +-------+
                                     |
                                     v
                              H2 / PostgreSQL
                              (extracted data)

The key components:

• 8 tools defined for Claude, each wrapping one or more BAPIs: test_connection, discover_org_structure, list_data, get_detail, count_records, start_extraction, get_extraction_status, preview_extracted_data.
• System prompt with BAPI reference: Claude receives in the system prompt documentation for the relevant BAPIs, their field structure, and examples of selection criteria.
• Per-user session: the user brings their own SAP credentials at runtime. Never hard-coded. The JCo destination is created dynamically per session.
• Mock mode for development: a parallel implementation of the RFC service that responds from local JSON files. Allows development without an SAP system at hand.
• SSE streaming for chat: Claude responses arrive in real time in the interface, including intermediate tool-use steps.

A typical user opens the app, enters SAP credentials, asks "how many ROH-type materials do we have in plant 1000?". Claude calls count_records, replies with an order of magnitude, proposes the selection criteria for extraction, asks for confirmation. On OK, it triggers start_extraction, which runs in the background with a job ID the user can check.

Real lessons from building this POC

A few specific things we learned and that you will run into if you build something similar:

Verify BAPI signatures before coding. Community documentation and some AI-generated summaries contain wrong names or non-existent parameters. A real example we hit: the correct BAPI for listing GL accounts is BAPI_GL_ACC_GETLIST, not BAPI_GL_ACCOUNT_GETLIST as some sources list it. The parameters MAXROWS, GLACCTRANGE, GLACCTGROUPRANGE do not exist for this BAPI either. Verify on sapdatasheet.org or in SE37 on the target system.

Mock mode can create false confidence. If your mock uses the wrong BAPI name and responds with the corresponding file, your code will look like it works perfectly until it hits the real system. Lesson: name mock files with the real BAPI name, not what your code assumes.

Spring @Async self-invocation is silent. Calling a method annotated @Async from inside the same bean bypasses Spring's proxy and runs synchronously, with no warning. For an extraction job that takes minutes, that means the HTTP thread blocks until the end. The fix is simple: put the async method in a separate bean. The bug is not: documented in Spring for more than a decade, but easy to miss.

SseEmitter is not thread-safe. The Spring documentation does not state this clearly, but it is a known open issue (#17815). If multiple threads send on the same emitter at once, data can interleave. Synchronize the sends.

Tool use with Claude has strict message ordering rules. Every tool_use block must have a matching tool_result in the next user message. All tool_result entries for parallel tool calls must go in one user message. History trimming must preserve tool_use/ tool_result pairs. The is_error: true flag on failed results helps the model understand what happened and decide what to do next.

SAP list BAPIs do not return total record counts. The best you can do isMAXROWS=1 and an estimate. For an agent that wants to ask "how many?" before extracting, you have to be explicit that the answer is an order of magnitude, not an exact figure.

Pattern 2: an agent that proposes transactions with confirmation

The next step beyond extraction is the agent that proposes actions which modify the system: create a new material, post a stock movement, post a financial document. Risk goes up here. A few principles we follow:

Never an action without human confirmation. The agent builds the payload, presents it as a diff or preview, waits for explicit confirmation. For BAPIs that support TEST_RUN = 'X', run the simulation first and present the result.

Minimal SAP roles for the agent. The agent's service account has only the permissions needed for the approved transactions. Never SAP_ALL on an account that takes input from an LLM.

Audit log on every call. Who asked, what they asked, what Claude proposed, what the user confirmed, what was actually executed, what SAP returned. Useful for compliance, debugging, and evaluating quality.

Idempotency where possible. If the user accidentally confirms twice, the system must detect it and not execute twice. An idempotent ID generated client-side works well.

Pattern 3: conversational HR and self-service

Here Microsoft 365 Copilot and vendor-locked solutions are serious competition. The advantage of a custom agent is that it can read policies from Confluence, query HR in the background, and complete a SuccessFactors form in a single conversational flow, which off-the-shelf solutions do not handle well at the customization level.

The technical pattern is similar to pattern 2: the agent has tools for the relevant APIs (Graph, SuccessFactors OData, ServiceNow Table API), a retrieval layer over company policies, and a confirmation flow before any side-effect action.

The most important lesson for HR: the end user is not technical. Replies must be short, citations must be clear, proposed forms must be in the user's language. The system prompt does a lot of the work.

What still does not work well

Some things to be honest about for readers evaluating what to build in 2026:

Fully autonomous agents on transactions with financial impact. We are not there. The risk of systematic errors is too high. The "confirm at every step" pattern remains necessary for any operation that creates accounting documents or modifies stock.

Analysis across the entire SAP data landscape simultaneously. An agent that answers cross-module (FI + MM + SD in a single question) tends to lose itself in large data volumes. The current solution: specialized agents per module, with a coordinator that orchestrates.

Classic SAP GUI and older Web Dynpro. There are browser-automation tools that can click through SAP GUI, but reliability is low. Prefer BAPI and OData wherever they exist. For transactions without an API, raise a wrapping request to the ABAP team.

Where this is going in the next 12 months

A few directions we track and that we are building at Ran·AI:

Extraction-to-migration pipeline. Once the agent extracts master data, the next logical step is to generate LTMC or LSMW files for migration into S/4HANA. That is on the ECC Extractor roadmap once the POC is stable.

Delta extraction. Instead of re-extracting everything, the agent detects what has changed and updates only the delta. Useful mechanism for continuous integrations.

Multi-agent across complete business processes. One agent that orchestrates specialized agents (FI agent, MM agent, HR agent) and coordinates a full business process (for example month-end close) with confirmations at the key steps.

MCP servers for full SAP applications. The cleanest wrapping approach. An MCP server exposes transactions, BAPIs, and queries over an SAP application, and any compatible client (Claude Desktop, Claude Code, another agent) uses it uniformly. At Ran·AI we have built MCP servers that give Claude full control of custom applications, and the pattern carries over to SAP without major rework.

For automated SAP change specs, where agents draft and review the functional specification for a change request, see our article on the pattern (in Romanian).

How to get started in practice

1. Pick a concrete repetitive operation that consumes time today (for example, extracting a weekly report of active materials per plant).
2. Identify the BAPIs or OData services that answer the question. Validate the signatures on sapdatasheet.org or in SE37.
3. Build a one-week prototype in mock mode. Verify the agent produces the correct output on known scenarios.
4. Connect to the dev system. Validate that tool use against real BAPIs produces the same results as the mock variant.
5. Add confirmations, audit log, error handling. Then a pilot group.

If you want a concrete discussion about integrating Claude with your SAP environment, write to us at contact@ranresults.com. Many of us worked in SAP for years before the LLM era, which is what differentiates us from teams that come only from the AI side and do not understand the particularities of the systems they aim to integrate.