Claude on SAP through MCP

How it is built

Three parts. Claude runs where your data policy allows: on Amazon Bedrock in the Frankfurt region or Google Vertex AI in the EU under your own cloud account, or on Claude Enterprise, which is Anthropic-hosted software under Anthropic's terms. The MCP server runs inside your network, next to SAP, and uses two interfaces: OData for the services on the Gateway and RFC for remote-enabled function modules and BAPIs. Between them sits the control layer: sign-in through the Microsoft or Google accounts people already have, masking of personal identifiers before a request leaves your network, and an audit record of every call.

Claude never talks to SAP directly. It asks the MCP server for a tool, the server checks whether that tool is allowed for that user, runs it under a scoped SAP technical account, writes the audit line and returns the result. In the pilot setup the SAP account is a technical user with the roles the use case needs. The person's own SAP identity is not passed through yet. That matters for authorisation and for licensing, and every proposal says so.

Why an MCP server, and what the alternatives are

• SAP's own assistant is Joule. At Sapphire on 12 May 2026 SAP said ECC customers who commit to moving the majority of their landscape to SAP Cloud ERP get selected AI scenarios, from the third quarter of 2026; a day later SAP's chief strategy officer told CIO.com the condition was committing half of the maintenance spend to the cloud first. Those are public statements and press reporting. Which scenarios, under which product and SKU, with which prerequisites, is in SAP's documentation and your contract.
• Other routes exist: custom extensions on SAP BTP and Joule Studio, Microsoft Copilot Studio with Azure OpenAI over SAP connectors, or an integration platform in front of ECC. The MCP route uses an open protocol, a model you choose and host, and a server whose code you can read.
• The server covers OData and RFC/BAPI. Reads use OData services and remote-enabled function modules; remote-enabled does not mean released, so for production each one is checked for its release status with your Basis team. RFC_READ_TABLE is used for ad-hoc table reads in a sandbox and has known limits (512-byte rows, no cluster tables, no application-level authorisation), so a production process gets a released API or a Z service instead, and that can mean Gateway activation, roles and transports on your side.
• The RFC bridge is built on open-rfc, an independent implementation of the RFC protocol, so a sandbox install does not need the SAP NetWeaver RFC SDK. SAP does not support that implementation, and it handles SAP credentials, so it gets its own security review before a pilot. Where your Basis team requires SAP's stack, the bridge runs on SAP's RFC SDK with PyRFC instead; SAP supports the SDK, not PyRFC or this server.

What Claude can do over SAP in a pilot

• Answer questions over the tables and views the technical account is authorised to read: open items per customer, stock per plant, production order status, purchase orders waiting for goods receipt. Claude explains SAP field names to the user. The limit is the technical account's roles, so a user could see data their own SAP roles would hide; a pilot therefore limits the account to data every pilot user may see, and processes with segregation-of-duties rules wait for named-user propagation.
• Call allowlisted BAPIs: lists and details of materials, customers, vendors, sales and purchase documents, open items for dunning. Each BAPI is named in a list your IT team controls.
• Query OData services on S/4HANA: material master, production orders, purchase orders through the standard API_ services. On ECC the same goes through RFC or your existing Z services.
• Prepare a transaction as a draft: a purchase requisition from a request in plain language, with material, quantity and plant filled in. The public server is read-only; a confirmed write is implemented per BAPI inside a pilot, after your IT team has approved that BAPI, with the person's confirmation recorded in the audit log. That confirmation is not an SAP workflow approval or an electronic signature; writes that need one stay out of the pilot.
• Match public tenders to what you produce: a connector to the EU tenders database TED reads new notices and Claude compares them with your material master.

The security model, written down

• Read-only in the published server. Writes exist only for BAPIs on an allowlist, only inside a pilot, and only with an explicit confirmation step by a named person.
• A scoped SAP technical account per deployment, with the roles the use case needs and nothing more. Named-user propagation from the company directory is on the roadmap and is not in the pilot setup today.
• An audit record for every call: time in UTC, the SAP account, the tool, arguments, status, duration and a note, written as JSON lines and forwarded to your log store or SIEM during the pilot. The local file is not tamper-proof and in the published server it records the technical account, not the person; the control is your log store, and the person's identity comes from the sign-in layer in a pilot.
• Personal identifiers masked before the model sees them: identification numbers, IBANs and contact details are replaced in the server. Free text, material and vendor descriptions, attachments and custom Z fields are not covered by the default masks; each pilot process gets its own data review.
• Where prompts are processed, whether they are retained, whether cross-region inference is on and which subprocessors are involved depends on the provider, region, model and endpoint you choose; we write the configuration down per component before go-live and you keep the document.
• A documented exit: how the server is stopped, the SAP account revoked and the process returned to manual operation.

SAP licensing and supportability: settled in writing before production

Three questions decide whether an SAP architect lets this into production, and a technical account answers none of them on its own. First, licensing: SAP's Digital Access model covers specified document types created in SAP through third-party applications, so it applies to writes; reads do not create such documents, but named-user and indirect-access terms in your contract can still apply to an application that reads on behalf of many people. Second, supportability: each OData service, BAPI and function module the pilot uses is checked for its release status, and the RFC implementation is chosen with your Basis team. Third, security: SNC on the RFC path and TLS on the HTTPS path, the account's roles, the network path, where the credential is stored and the log retention.

The readiness check produces the interface list, the account roles and the questions for your SAP account team in a two-page document. Before a pilot writes anything we ask for a contractual clarification from SAP on licensing, naming the users, interfaces and document types; an account manager's e-mail is not that. We do not describe this route as free of licensing questions.

What we can show today, and what we cannot

• We can show Claude reading an SAP ECC 6.0 IDES sandbox and an S/4HANA 2025 sandbox through this server, live, in a 30-minute call.
• We can hand over the code, the audit log format and the data-flow map before any conversation. A pinned release with a dependency list and a threat model is part of the pilot, not of the public repository today.
• We cannot yet point to a production ECC customer. The first ECC pilot is in preparation for the fourth quarter of 2026; an anonymised case with numbers follows when it is done. If a production reference is your condition, say so and we will tell you when we have one.

How a six-week pilot runs

Week one is assessment: which two processes, which tables and BAPIs, which roles, which hosting, and the licensing questions for your SAP account team. Weeks two and three put the MCP server into your network and connect it to Claude with sign-in and audit. Weeks four and five run the two processes with the people who own them, measured against the manual baseline. Week six is the audit review and a go or no-go for the next processes. The pilot has a fixed price, stated in the first conversation together with what it covers and what it does not.

The server is open source

The SAP MCP server we deploy is published on GitHub under the MIT licence, with the OData and RFC tools, the BAPI allowlist, the audit log and the Claude Desktop and Claude Code configuration. The MIT licence covers that code, not its dependencies, not the model client and not any SAP interface or licence right. We sell the production deployment: the security layer, hosting in your environment, the process work with your people and support.

Who this is for, and who it is not for

For companies running SAP ECC 6.0, S/4HANA on premises or S/4HANA private cloud, with roughly 200 to 10,000 employees, in Europe or anywhere we can work remotely with your IT team. It is not for a company that wants an agent writing into SAP without a person in the loop, and it is not a certified SAP add-on; it is a layer beside SAP that uses SAP's remote interfaces under your SAP licence.

Questions we get asked

Does the server need the SAP NetWeaver RFC SDK?

Not for the install: RFC calls go through a Node bridge on open-rfc, an independent implementation of the RFC protocol, so a Python environment plus Node 22 is enough. SAP does not support that implementation. If your SAP contract or Basis team requires SAP's own stack, the bridge runs on the SAP NetWeaver RFC SDK with PyRFC under your licence; the tools stay the same.

Which SAP versions does it work with?

SAP ECC 6.0 and S/4HANA, on premises and private cloud. It has been run against ECC 6.0 IDES and S/4HANA 2025 sandbox systems; whether your system exposes the needed Gateway services and function modules is what the readiness check looks at. For S/4HANA Cloud Public Edition we combine Joule with custom skills on SAP BTP and use the MCP server for cross-system work.

Can Claude change data in SAP?

In the published server, no: it is read-only. In a pilot, a write is enabled per BAPI from an allowlist, after your IT team has approved it, and runs only after a named person confirms the proposal the server prepared. Everything else stays read-only.

Where does the model run and what happens to our data?

On Amazon Bedrock in the Frankfurt region or Google Vertex AI in the EU under your own cloud account, or on Claude Enterprise as Anthropic-hosted software under Anthropic's terms. Retention, logging, cross-region inference and training terms depend on the provider, region, model and endpoint; we document the exact configuration per component and you keep it. Personal identifiers are masked in the server before the model sees them.

How is this different from SAP Joule?

Joule is SAP's assistant inside SAP products; for ECC customers SAP ties it to a cloud commitment and selected scenarios. The MCP server is a layer beside SAP that works with Claude, reaches ECC through RFC and OData, and keeps the audit trail in your hands. The two can coexist.

Does a technical SAP user settle the licensing question?

No. Digital Access covers specified document types an application creates in SAP, and named-user or indirect-access terms in your contract can cover an application that reads on behalf of people, whatever account it uses. The readiness check lists every interface the pilot touches so SAP can give a contractual answer before production.

Does it work with ChatGPT or Microsoft Copilot?

MCP is an open protocol and the server is not tied to Claude. We implement and support it with Claude; another MCP client would need its own check of authentication, transport and the confirmation step before it is trusted with SAP.

Can we run it ourselves?

Yes. The code is on GitHub under the MIT licence, which covers that code and not its dependencies or any SAP interface right. We sell the production deployment around it: the security layer, hosting in your environment, the process work with your people and support.

How long does the pilot take and what does it cost?

Six weeks for two processes, at a fixed price that we state in the first conversation together with what it covers. The first conversation is 30 minutes and is free.

Is your ECC ready for Claude?

A 30-minute technical readiness check: which interfaces your ECC exposes, which roles a pilot needs, where the model would run, the licensing questions for your SAP account team, and a two-page summary you can forward. Sandbox demo on request.

Request the ECC readiness check

Or write to us directly: info@iteractive.ai · +421 905 452 325