SAP Business One MCP server

Why SAP Business One in particular is an MCP candidate

SAP Business One is firmly established among mid-sized companies in Germany: manufacturers, wholesale, project business — wherever the big S/4HANA would be oversized but Excel is long since no longer enough. The ERP holds orders, inventory, suppliers and financial postings together. The catch: the full data potential often stays behind the client's forms. Anyone who needs a figure clicks through — or waits for the one colleague who knows the reports.

An MCP server for SAP Business One connects AI agents such as Claude, GPT, Gemini or Copilot to your Business One instance via the open Model Context Protocol. Instead of maintaining your own scripts for every AI connection, agent and ERP talk to each other through a standardised tool layer. The connection runs primarily via the Service Layer, the REST/OData interface of Business One.

SAP API Policy: what applies to AI agents on Business One

With Business One too, the SAP API Policy (v.4.2026a) comes before the first line of code. Clause 2.2.2 prohibits API use by (semi-)autonomous or generative AI systems that plan, select or execute the consequences of API calls, unless access runs through architectures or routes recognised by SAP. Letter (b) additionally prohibits scraping and systematic or large-volume data extraction and replication (SAP API Policy).

Business One is not named in the policy or FAQ. However, in question 1 the accompanying FAQ describes the policy as part of the documentation for all SAP cloud solutions and the on-premise portfolio, including all line-of-business solutions (SAP API Policy FAQ v1.3). We therefore treat an AI agent on the Service Layer as if it fell under the policy, and obtain a written assessment from your SAP partner before the project starts.

Which routes SAP recognises for AI agents, when a custom MCP server may be permissible and what applies to rule-based processes is covered in detail in the section on the SAP API Policy in the SAP guide. This assessment is not legal advice.

Service Layer and DI API — the technical foundation

The Service Layer exposes Business One data as a REST API via OData in JSON format. Nearly all business objects support the usual CRUD operations, and the OData query options $select, $filter, $orderby and $expand allow targeted, economical queries — the agent pulls only what it really needs for the task.

The older DI API is a .NET library for deep server-side access, traditionally used for add-ons on the client machine. The Service Layer and DI API share most of their metadata, so an MCP server can combine both routes: Service Layer for lean REST access, DI API where special business logic is needed. We deliberately do not plan for bulk data extraction by the agent, because clause 2.2.2 (b) of the SAP API Policy prohibits it outside recognised routes. A practical bonus: user-defined fields (UDFs) and objects (UDOs) can also be addressed via OData — your individual customisations remain connectable.

Use cases: what a Business One MCP server delivers

1. Order entry by voice "Create a sales order for customer Meier for 40 units of item A-2201 with delivery next week." The agent checks the business partner and item and builds an order draft — you approve, then it is posted.
2. Stock and availability queries "How much of item X is still in the Hamburg warehouse?" — "Which items are below reorder level?" The agent pulls the figures via OData directly from the item objects, without a click path through the client.
3. Business partner master data maintenance New customers or suppliers are created cleanly as business partners — the agent checks for duplicates, adds VAT ID, payment terms and address, and reports when mandatory fields are missing.
4. Purchasing workflows A requirement notice becomes a purchase order: based on recent purchase prices and supplier master data, the agent proposes a draft — approval stays with purchasing.
5. Reporting without a report builder "What was the order intake in May by sales territory?" The agent uses OData aggregations and delivers the analysis in the chat — no Crystal Reports ticket needed.
6. Posting preparation (journal entries) The agent prepares recurring or rule-based ledger postings as a journal entry draft. Posting only happens after review — finance retains control of the general ledger.

How the integration works

Architecture for Business One:

AI agent ↔ MCP server (your EU host) ↔ Service Layer (REST/OData, JSON) ↔ SAP Business One

Concrete steps we take in a project like this:

• Service Layer access: We set up a dedicated technical login with tightly scoped permissions — the agent sees only the objects and companies its use cases need.
• Tool mapping: MCP tools such as create_order_draft, get_item_stock, find_business_partner or list_open_purchase_orders — each with a JSON schema, validated inputs and clear error messages.
• Draft instead of direct posting: Write actions create drafts by default. Publishing and posting require human approval — configurable per tool.
• DI API for special cases: Where the Service Layer reaches its limits (special add-on logic), we add the DI API, without enabling bulk extraction by the agent.
• Logging: Every ERP action is logged with timestamp, trigger and before/after diff — traceability down to the individual posting.

GDPR, hosting and security for ERP access

Unlike pure cloud accounting systems, SAP Business One mostly runs on-premise or in a cloud environment of your choice. That is an advantage for data protection: the ERP database stays in your infrastructure, and only the fields a tool returns for the question at hand go to the AI model. To keep the AI chain compliant with data protection, we pay attention to the following points for every Business One MCP server — tailored to the sensitive content of an ERP (revenue, margins, supplier terms):

• MCP server in EU hosting (Hetzner or the Azure region Germany West Central in Frankfurt) or directly in your network next to the Business One server — no US edge in the data path.
• AI model with EU data residency: Claude via AWS Bedrock (Frankfurt region) or Google Vertex AI in the EU, OpenAI Enterprise with EU data residency or Azure OpenAI in an EU region — including a DPA.
• Local model as an option: If no request should go to a model provider, an open-weight model can be run in your network.
• Minimal permissions on the Service Layer: The technical login gets only read and, where needed, write rights on the objects actually used, not full admin.
• Write lock as default: Postings, order approvals and purchase orders need a human click — the agent prepares, a human takes responsibility.

A realistic project sketch

As an anonymised, realistic sketch (not a specific reference): a wholesaler with Business One manages around 6,000 items and processes dozens of customer orders every day. Before the connection, every availability query goes through two inside-sales employees. With an MCP server, sales could ask for stock levels, delivery times and order status directly in the chat and create order drafts there — a human stays in the loop for final approval. The bottleneck "inside sales knows the reports" would thereby be eased.

Frequently asked questions

Is there an official MCP server from SAP for Business One?

No, to our knowledge there is no officially SAP-maintained one. Community and third-party MCP servers are available that expose parts of the Service Layer as tools — such as a read-only connector from CData or Azure/Copilot Studio setups. For write-capable, productive use cases we usually build our own EU-hosted server tailored to your environment.

Which interface does the connection use?

Primarily the Service Layer with REST, OData and JSON. For special add-on logic we add the DI API. Both largely share the same metadata, which keeps the integration consistent. We avoid systematic or large-volume data extraction because the SAP API Policy prohibits it in clause 2.2.2 (b) outside recognised routes.

Can the AI agent post documents directly in the ERP?

Technically yes, because the Service Layer allows CRUD on objects such as orders or journal entries. We recommend the draft route, though: the agent creates a draft, an employee reviews and posts. That way control stays in-house, and the general ledger is never written to without review.

Does it stay compliant with data protection when an AI model accesses ERP data?

Yes, if the chain is right. Business One mostly runs on-premise or in a cloud of your choice, so the database stays in your environment. Only the fields a tool returns for the question at hand go to the AI model. The prerequisites are an MCP server in the EU or in your network, an AI model with EU data residency and a DPA, and minimal permissions. The SAP API Policy must be assessed separately.

How long does a first productive use case take?

That depends on the permission situation, the objects you want and the clarification of the SAP API Policy. We set the timeline after the AI Check. A typical first use case is guided order entry or a stock query.

Which AI models can be used?

All MCP-compatible models: Anthropic Claude, OpenAI GPT, Google Gemini, Microsoft Copilot. Switching models later is possible without a new integration, because the tool layer stays stable.