MCP-Server für SAP Business One

Warum gerade SAP Business One ein MCP-Kandidat ist

SAP Business One ist im deutschen Mittelstand fest verankert: produzierende Betriebe, Großhandel, Projektgeschäft — überall dort, wo das große S/4HANA überdimensioniert wäre, aber Excel längst nicht mehr reicht. Das ERP hält Aufträge, Lagerbestände, Lieferanten und Finanzbuchungen zusammen. Der Haken: Das volle Datenpotenzial bleibt oft hinter den Formularmasken des Clients liegen. Wer eine Zahl braucht, klickt sich durch — oder wartet auf den einen Kollegen, der die Reports kennt.

Ein MCP-Server für SAP Business One verbindet KI-Agenten wie Claude, GPT, Gemini oder Copilot über das offene Model Context Protocol mit Ihrer Business-One-Instanz. Statt für jede KI-Anbindung eigene Skripte zu pflegen, sprechen Agent und ERP über eine standardisierte Tool-Schicht miteinander. Die Anbindung läuft primär über den Service Layer — die moderne REST-/OData-Schnittstelle von Business One, die SAP seit Version 10.0 als zentralen Integrationsweg führt.

Service Layer und DI-API — der technische Unterbau

Der Service Layer stellt Business-One-Daten als REST-API über OData (Version 4 ist seit FP 2405 der Standard, Version 3 gilt als veraltet) im JSON-Format bereit. Nahezu alle Geschäftsobjekte unterstützen die üblichen CRUD-Operationen, und die OData-Abfrageoptionen $select, $filter, $orderby und $expand erlauben gezielte, sparsame Abfragen — der Agent zieht nur, was er für die Aufgabe wirklich braucht.

Die ältere DI-API ist eine .NET-Bibliothek für tiefen serverseitigen Zugriff, klassisch für Add-ons auf dem Client-Rechner. Service Layer und DI-API teilen sich den Großteil ihrer Metadaten, sodass ein MCP-Server beide Wege kombinieren kann: Service Layer für den schlanken REST-Zugriff, DI-API dort, wo Massenverarbeitung oder spezielle Geschäftslogik nötig ist. Praktischer Bonus: Auch benutzerdefinierte Felder (UDF) und Objekte (UDO) lassen sich über OData ansprechen — Ihre individuellen Anpassungen bleiben anbindbar.

Use Cases: Was ein Business-One-MCP-Server leistet

1. Auftragsanlage per Sprache „Leg einen Kundenauftrag für Lieferant Meier über 40 Stück Artikel A-2201 mit Liefertermin nächste Woche an." Der Agent prüft Business Partner und Item, baut einen Order-Entwurf — Sie geben frei, dann wird gebucht.
2. Bestands- und Verfügbarkeitsabfragen „Wie viel von Artikel X liegt noch im Lager Hamburg?" — „Welche Items sind unter Meldebestand?" Der Agent zieht die Zahlen über OData direkt aus den Item-Objekten, ohne Klickweg durch den Client.
3. Stammdatenpflege Business Partners Neue Kunden oder Lieferanten landen sauber als Business Partner — der Agent prüft auf Dubletten, ergänzt USt-ID, Zahlungsbedingungen und Adresse und meldet, wenn Pflichtfelder fehlen.
4. Einkaufs-Workflows Aus einer Bedarfsmeldung wird eine Bestellung (Purchase Order): Der Agent schlägt anhand letzter Einkaufspreise und Lieferantenstammdaten einen Entwurf vor — die Freigabe bleibt beim Einkauf.
5. Reporting ohne Report-Builder „Wie hoch war der Auftragseingang im Mai pro Vertriebsgebiet?" Der Agent nutzt OData-Aggregationen und liefert die Auswertung im Chat — kein Crystal-Report-Ticket nötig.
6. Buchungs-Vorbereitung (Journal Entries) Wiederkehrende oder regelbasierte Sachbuchungen bereitet der Agent als Journal-Entry-Entwurf vor. Gebucht wird erst nach Prüfung — der Finanzbereich behält die Hoheit über das Hauptbuch.

So läuft die Integration ab

Architektur-Bild für Business One:

KI-Agent ↔ MCP-Server (Ihr EU-Host) ↔ Service Layer (REST/OData v4, JSON) ↔ SAP Business One

Konkrete Schritte, die wir in einem solchen Projekt gehen:

• Service-Layer-Zugang: Wir richten einen dedizierten Technik-Login mit eng gesetzten Berechtigungen ein — der Agent sieht nur die Objekte und Mandanten, die seine Use-Cases brauchen.
• Tool-Mapping: MCP-Tools wie create_order_draft, get_item_stock, find_business_partner oder list_open_purchase_orders — jedes mit JSON-Schema, validierten Eingaben und klaren Fehlermeldungen.
• Entwurf statt Direktbuchung: Schreibende Aktionen erzeugen standardmäßig Entwürfe. Das Veröffentlichen und Buchen erfordert eine menschliche Freigabe — pro Tool konfigurierbar.
• DI-API für Sonderfälle: Wo der Service Layer an Grenzen stößt (Massenimporte, spezielle Add-on-Logik), binden wir die DI-API ergänzend ein.
• Logging: Jede ERP-Aktion wird mit Zeitstempel, Auslöser und Vorher/Nachher-Diff protokolliert — Nachvollziehbarkeit bis zur einzelnen Buchung.

DSGVO, Hosting und Sicherheit beim ERP-Zugriff

Anders als bei reinen Cloud-Buchhaltungen läuft SAP Business One meist On-Premise oder in einer von Ihnen gewählten Cloud-Umgebung. Das ist für den Datenschutz ein Vorteil: Die ERP-Daten verlassen Ihre Infrastruktur nicht. Damit das auch für die KI-Kette gilt, achten wir bei jedem Business-One-MCP-Server auf folgende Punkte — abgestimmt auf die sensiblen Inhalte eines ERP (Umsätze, Margen, Lieferantenkonditionen):

• MCP-Server im EU-Hosting (Hetzner oder Azure Germany) bzw. direkt in Ihrem Netz neben dem Business-One-Server — kein US-Edge im Datenpfad.
• KI-Modell mit EU-Datenresidenz: Claude über AWS Bedrock (Region Frankfurt) oder Google Vertex AI in der EU, OpenAI Enterprise mit EU-Data-Residency oder Azure OpenAI in Deutschland — inklusive AVV.
• Minimal-Berechtigung am Service Layer: Der Technik-Login bekommt nur Lese- und ggf. Schreibrechte auf die wirklich genutzten Objekte, kein Voll-Admin.
• Schreibsperre als Default: Buchungen, Auftragsfreigaben und Bestellungen brauchen einen menschlichen Klick — der Agent bereitet vor, ein Mensch verantwortet.

Eine solche Anbindung ist in vielen Fällen als Digitalisierungs- und Beratungsprojekt grundsätzlich förderfähig — das klären wir bei Bedarf im Erstgespräch.

Eine realistische Projektskizze

Als anonymisierte, realistische Skizze (keine konkrete Referenz): Ein Großhändler mit Business One führt rund 6.000 Artikel und bearbeitet täglich Dutzende Kundenaufträge. Vor der Anbindung läuft jede Verfügbarkeitsabfrage über zwei Mitarbeiter im Innendienst. Mit einem MCP-Server ließe sich umsetzen, dass der Vertrieb Bestände, Lieferzeiten und Auftragsstände direkt im Chat erfragt und Auftragsentwürfe in Sekunden erzeugt — final freigegeben bleibt der Mensch im Spiel. Der Engpass „Innendienst kennt die Reports" wäre damit entschärft.

Häufige Fragen

Gibt es einen offiziellen MCP-Server von SAP für Business One?

Nein, einen offiziell von SAP gepflegten gibt es Stand 2026 nicht. Verfügbar sind community- und drittanbieter-MCP-Server, die Teile des Service Layer als Tools bereitstellen — etwa ein read-only Connector von CData oder Azure-/Copilot-Studio-Aufbauten. Für schreibende, produktive Use-Cases bauen wir in der Regel einen eigenen, EU-gehosteten Server passgenau auf Ihre Umgebung.

Über welche Schnittstelle läuft die Anbindung?

Primär über den Service Layer mit REST, OData v4 und JSON. Wo es nötig ist — etwa bei Massenverarbeitung oder spezieller Add-on-Logik — ergänzen wir die DI-API. Beide teilen sich weitgehend dieselben Metadaten, das hält die Integration konsistent.

Kann der KI-Agent Belege direkt im ERP buchen?

Technisch ist das möglich, weil der Service Layer CRUD auf Objekten wie Orders oder Journal Entries erlaubt. Wir empfehlen aber den Entwurfs-Weg: Der Agent legt einen Draft an, ein Mitarbeiter prüft und bucht. So bleibt die Kontrolle im Haus, und das Hauptbuch wird nie ungeprüft beschrieben.

Bleibt das DSGVO-konform, obwohl ein KI-Modell auf ERP-Daten zugreift?

Ja, wenn die Kette stimmt. Da Business One meist in Ihrer eigenen Umgebung läuft, bleiben die ERP-Daten dort. Der MCP-Server wird in der EU gehostet, das KI-Modell läuft mit EU-Datenresidenz und AVV, und der Agent sieht nur die minimal nötigen Felder.

Wie lange dauert ein erster produktiver Use-Case?

Je nach Berechtigungslage und gewünschten Objekten meist drei bis fünf Wochen für den ersten Use-Case — typischerweise eine geführte Auftragsanlage oder eine Bestandsabfrage. Weitere Tools kommen danach in kurzen Schritten dazu.

Welche KI-Modelle lassen sich verwenden?

Alle MCP-kompatiblen Modelle: Anthropic Claude, OpenAI GPT, Google Gemini, Microsoft Copilot. Ein Modellwechsel ist später ohne neue Integration möglich, weil die Tool-Schicht stabil bleibt.