Dynamics 365 Business Central & Shopware verbinden 2026

Microsoft Dynamics 365 Business Central ist mit über 40.000 Kunden in mehr als 250 Ländern (ERP.today) das am schnellsten wachsende Produkt der Dynamics-Familie und ein Standard-ERP für den wachsenden Mittelstand. Wer einen Shopware-6-Shop betreibt und BC als führendes System nutzt, steht früher oder später vor einer Integrationsfrage: Wie gelangen Kunden, Artikel, Preise und Bestände stabil, nachvollziehbar und möglichst in Echtzeit zwischen beiden Welten? Dieser Leitfaden zeigt, wie eine Business-Central-Shopware-Anbindung technisch sauber aufgebaut wird - mit OData v4, Webhooks, Azure Service Bus und einer klaren Middleware-Strategie - und welche B2B-Szenarien sich so ohne teure Zusatzmodule umsetzen lassen.

Dynamics 365 BC im deutschen Mittelstand

Der deutsche ERP-Markt ist 2024 mit einem Anteil von 22,3% der größte in Europa (Market Data Forecast) - und Dynamics 365 Business Central spielt darin eine zentrale Rolle. Deutschland ist mit 780 Unternehmen, die BC einsetzen, der zweitgrößte Markt weltweit nach Großbritannien und hält einen Anteil von 12,89% an allen bekannten BC-Installationen (6sense). Die Zielgruppe ist dabei klar im Mittelstand verankert: 2.493 Unternehmen mit 100-249 Mitarbeitern nutzen BC, dazu kommen 1.678 mit 20-49 und 1.168 mit 250-499 Mitarbeitern (6sense/Landbase).

Parallel beschleunigt sich der Cloud-Trend: 90% der deutschen Unternehmen nutzen 2025 Cloud-Apps (Bitkom Cloud-Report 2025), ein Anstieg gegenüber 81% im Vorjahr. Gleichzeitig sinkt das ERP-Cloud-Interesse leicht von 44% auf 37% (Bitkom Research) - ein Hinweis darauf, dass der Mittelstand kostenbewusster agiert. Die Initiative "Digital Now" hat in Deutschland bis 2024 rund 3,2 Mrd. EUR für ERP-Adoption und mehr als 35.000 Implementierungen gefördert (Market Data Forecast). Wer BC einsetzt, hat also ein modernes, cloud-natives ERP mit starker regulatorischer und technologischer Basis - ideal als Rückgrat einer Shopware-Anbindung.

Integrations-Architektur: Direct vs. Middleware

Die erste Architekturentscheidung ist grundlegend: Wird BC direkt mit Shopware verbunden oder über eine Middleware-Schicht? Beide Ansätze haben ihre Berechtigung. Eine direkte Anbindung spricht die Shopware Admin API aus BC heraus an (oder umgekehrt) - schnell zu bauen, aber eng gekoppelt. Eine Middleware entkoppelt beide Systeme über einen Broker, puffert Spitzenlasten und erlaubt zentrales Mapping, Logging und Retry. Besonders bei B2B-Projekten mit Rahmenverträgen, Staffelpreisen und mehreren Shops führt erfahrungsgemäß kein Weg an einer Middleware vorbei. Unsere Erfahrung aus ERP-Integrationen bei Shopware zeigt: Wer heute klein startet, profitiert morgen von einer tragfähigen Architektur.

OData v4 API: Endpoints und Rate-Limits

Business Central bietet seit mehreren Versionen eine OData-v4-REST-API als Standard-Schnittstelle - die ältere SOAP-Variante gilt für Neuentwicklungen als abgekündigt (Microsoft Learn). Über OData sprechen Sie Companies, Customers, Items, SalesOrders, Vendors, und viele weitere Entitäten an, sowohl aus Standard- als auch aus Custom-Pages heraus. Entscheidend für stabile Integrationen sind die offiziellen Rate-Limits: BC OData v4 erlaubt 6.000 Requests pro 5 Minuten pro User, das entspricht rund 20 Requests pro Sekunde (Microsoft Learn). Zusätzlich gilt: maximal 5 gleichzeitige Requests, bis zu 100 queued Connections pro User - darüber hinaus antwortet BC mit HTTP 429 und einem Retry-After-Header (Microsoft Learn).

Für eine saubere Anbindung bedeutet das: Die Middleware muss Throttling, Retry mit exponentiellem Backoff und 429-Handling beherrschen. Wer das ignoriert, baut Integrationen, die unter Last kippen. Mehr dazu lesen Sie auch in unserem Beitrag zu Middleware im E-Commerce.

### Customers abrufen (Standard-API v2.0)
GET https://api.businesscentral.dynamics.com/v2.0/{tenant}/{env}/api/v2.0/companies({companyId})/customers?$top=100
Authorization: Bearer {token}
Accept: application/json

### Einzelnen Artikel aktualisieren
PATCH https://api.businesscentral.dynamics.com/v2.0/{tenant}/{env}/api/v2.0/companies({companyId})/items({itemId})
Authorization: Bearer {token}
If-Match: {etag}
Content-Type: application/json

{
  "unitPrice": 129.00,
  "inventory": 42
}

### SalesOrder anlegen (aus Shopware)
POST https://api.businesscentral.dynamics.com/v2.0/{tenant}/{env}/api/v2.0/companies({companyId})/salesOrders
Authorization: Bearer {token}
Content-Type: application/json

{
  "customerNumber": "K-10042",
  "externalDocumentNumber": "SW-ORDER-98312",
  "orderDate": "2026-05-02"
}

Webhook-Subscriptions für Echtzeit-Events

Polling ist teuer und langsam. Aktuelle Messungen zeigen: Webhook-basierter Abgleich erreicht Sub-200ms-Propagation gegenüber 5-15 Minuten bei klassischem Polling (Codesol). BC unterstützt dafür offiziell Webhook-Subscriptions, die über den subscriptions-Endpoint der API v2.0 angelegt werden. Eine Subscription hat eine maximale Laufzeit von 3 Tagen und muss vor Ablauf erneuert werden - andernfalls endet der Event-Stream still (Microsoft Learn). Produktionsreife Integrationen implementieren daher einen Renewal-Job, der Subscriptions rechtzeitig verlängert und Ausfälle protokolliert.

Ein verbreiteter Best Practice ist die Kombination aus Webhook-Triggern für Echtzeit-Events und einer periodischen API-Reconciliation - letztere fängt verlorene Events ab (Codesol). Damit erreichen Sie die Geschwindigkeit eines Push-Modells und die Verlässlichkeit eines Pulls.

POST /api/v2.0/subscriptions

{
  "notificationUrl": "https://middleware.example.com/bc/webhooks",
  "resource": "api/v2.0/companies({companyId})/items",
  "clientState": "xictron-prod-items-v1",
  "expirationDateTime": "2026-05-05T12:00:00Z"
}

// Renewal-Pseudocode (Middleware)
foreach (sub in activeSubscriptions) {
  if (sub.expiresIn < 24h) {
    PATCH /api/v2.0/subscriptions(sub.id)
    { "expirationDateTime": now + 3d }
  }
}

$batch für Bulk-Sync: Tausende Datensätze effizient

Beim initialen Go-Live oder bei Preislisten-Rollouts müssen oft tausende Artikel oder Preise in BC landen. Jeder Request einzeln durch den OData-Endpoint zu schieben, sprengt die Rate-Limits in Minuten. Die Lösung ist der $batch-Endpoint: Er bündelt mehrere Create-, Update- und Delete-Operationen in einem einzigen HTTP-Request (Microsoft Learn). Das ist sowohl für die Rate-Limit-Bilanz als auch für die Transaktions-Semantik ein Gewinn, da alle Operationen in einem Changeset atomar behandelt werden können.

Bewährt hat sich in der Praxis eine Batch-Größe zwischen 50 und 200 Operationen pro Request - abhängig von Payload-Größe, Netzwerk-Latenz und der Komplexität der Ziel-Entität. Mehr zur B2B-seitigen Architektur und wie solche Bulk-Operationen in größere Prozesse einzubetten sind, beleuchten wir in weiteren Beiträgen.

POST /api/v2.0/$batch HTTP/1.1
Content-Type: multipart/mixed; boundary=batch_xictron_001
Authorization: Bearer {token}

--batch_xictron_001
Content-Type: multipart/mixed; boundary=changeset_items_001

--changeset_items_001
Content-Type: application/http
Content-Transfer-Encoding: binary

PATCH companies({id})/items({itemIdA}) HTTP/1.1
Content-Type: application/json

{"unitPrice":119.00,"inventory":120}

--changeset_items_001
Content-Type: application/http
Content-Transfer-Encoding: binary

PATCH companies({id})/items({itemIdB}) HTTP/1.1
Content-Type: application/json

{"unitPrice":89.50,"inventory":58}

--changeset_items_001--
--batch_xictron_001--

Azure Service Bus für asynchrone Queues

Für anspruchsvollere Integrationen ist eine Queue zwischen BC und Shopware ein stabiler Baustein. Azure Service Bus dient als asynchroner Broker: Shopware-Events wie neue Bestellungen oder Kundenanlagen werden in Queues geschrieben, die Middleware konsumiert, mappt und schreibt in BC. Umgekehrt fließen Artikel-, Preis- und Bestandsänderungen aus BC über Webhooks in Queues und von dort in Shopware. Dead-Letter-Queues fangen fehlerhafte Nachrichten ab, ohne den Main-Stream zu blockieren; exponentielles Backoff verhindert das Hämmern auf fehlerhafte Endpunkte.

Alternativen wie selbst betriebene Broker, generische Queues auf Basis von RabbitMQ oder Kafka, oder schlanke SaaS-Middleware-Ebenen sind technisch ebenso tragfähig - entscheidend ist, dass Sync-Flows nicht synchron an die HTTP-Verfügbarkeit der Endsysteme gekettet sind. Neutrale Muster wie generische iPaaS-Plattformen (Alumio, APIcenter, Codeless BPA) adressieren dasselbe Prinzip; wir empfehlen jedoch keine spezifischen Drittanbieter, sondern bauen je nach Anforderung die passende Lösung.

Datenmodell-Mapping: BC ↔ Shopware

Das technische Fundament jeder Anbindung ist ein explizites, dokumentiertes Mapping zwischen BC-Entitäten und Shopware-Entitäten. Änderungen an diesem Mapping sind die häufigste Ursache für Bugs, wenn sie nur im Kopf eines Entwicklers leben. Wir legen das Mapping daher versioniert als JSON oder YAML ab und prüfen es im CI - parallel zum Mapping für Bestellstati, Zahlungsarten und Währungen.

B2B-Szenarien: Rahmenverträge und Staffelpreise

Der eigentliche Wert einer BC-Anbindung zeigt sich im B2B-Umfeld. Rahmenverträge, kundenspezifische Sortimente, Staffelpreise, Budget-Kontrollen und Approval-Workflows werden fast immer in BC gepflegt - Shopware ist der Vertriebskanal. Shopware 6 CE bietet dafür ein mächtiges Rule-Builder-System, das ohne kostenpflichtige Erweiterungen auskommt: Kundengruppen, Company-Accounts und individuelle Preisregeln lassen sich über Custom-Plugins und die Admin-API spiegeln. Hintergründe liefern unsere Beiträge zu B2B-Preisstrategien, kundenspezifischen Sortimenten und B2B-Self-Service-Portalen.

• Rahmenverträge in BC als Blanket Sales Orders pflegen - API-Spiegelung in Shopware als Kunden-spezifisches Sortiment mit Restmenge
• Staffelpreise SKU-spezifisch aus BC-Preislisten ableiten und als Rule-Builder-Regeln in Shopware CE abbilden (Mengen- und Kundengruppen-Trigger)
• Kundenspezifische Preise aus Vertragsdaten über Rule Builder in Shopware CE - ohne Lizenz-gebundene Paketlösungen
• Kreditlimits und Zahlungsziele aus BC in Shopware-Checkout-Regeln übersetzen (Sperren bei Überschreitung)
• Approval-Workflows für Großbestellungen nativ in Shopware als Eigenentwicklung, Spiegelung in BC als Sales-Quote-Status
• Company Accounts und Offer Management als CE-kompatible Muster - Shopware-nativ implementiert, BC als Datenquelle
• Bidirektionaler Echtzeit-Sync für Bestände - kritisch bei knappen Lagerbeständen und Mehrkanal-Vertrieb
• Mehrere Shops an einer BC-Company - Produkt-Visibility pro Shop über Channel-Mapping steuern

Fehler-Handling und Reconciliation

Integrationen scheitern selten spektakulär, sondern leise: ein Webhook fehlt, ein Preis veraltet, ein Artikel ist im Shop anders als in BC. 70% aller ERP-Projekte verfehlen ihre Ziele durch defekte Daten-Handoffs (Shopify Enterprise) - das passiert vor allem, wenn Fehler-Handling und Reconciliation nachgelagert implementiert werden. Wer ERP-Prozesse dagegen sauber aufsetzt, verbessert sie in 95% der Fälle (NetSuite).

• Idempotenz-Keys pro Nachricht (Shopware-Order-UUID, BC-ETag) verhindern Doppelbuchungen bei Retries
• Dead-Letter-Queues mit Alerting - fehlerhafte Messages blockieren keine funktionierenden Flows
• Exponentielles Backoff bei HTTP 429 und 5xx - BC gibt Retry-After vor, das ist Pflicht
• Nightly Reconciliation via $batch - gleicht entgangene Webhook-Events ab und dient als Safety-Net
• Strukturierte Logs mit Correlation-IDs über Shopware, Middleware und BC hinweg - sonst ist Debugging im Nachgang kaum möglich
• Business-Alerts bei Mengenabweichungen (z. B. ">5% Bestandsdifferenz zwischen Shop und BC")

Typische Fallen bei BC-Shopware-Projekten

• Rate-Limits unterschätzen - 6.000 Requests/5min/User (Microsoft Learn) sind schneller aufgebraucht, als viele annehmen - besonders bei synchronen Preisabfragen pro Seitenaufruf
• Webhook-Expiration nicht automatisiert - Subscriptions enden still nach 3 Tagen, Monitoring darauf ist zwingend
• Fehlende Idempotenz - Retry-Logik verdoppelt ohne saubere Keys Bestellungen oder Rechnungen in BC
• Zeitzonen und Datumsformate - BC arbeitet intern mit UTC, Shopware-Admins denken in lokaler Zeit; Logik-Fehler bei Rabatten und Aktionsfenstern sind häufig
• Mehrwährungs-Szenarien - Preise, Steuern und Rundungsregeln müssen pro Land und Währung konsistent sein, sonst driften Shop und ERP auseinander
• Steuerlogik - BC rechnet auf Basis von Business-Posting-Groups, Shopware auf Basis von Tax-Rules; Mapping-Fehler kosten später Compliance
• Vermischung von Daten- und Business-Regeln - Regeln wie "Preis X gilt nur für Kunde Y ab 100 Stück" gehören in eine Rule-Engine, nicht in SQL-Trigger
• Unklare Ownership - wer darf einen Artikel im Shop anlegen: BC, PIM, Shopware? Ohne Festlegung entstehen Konflikte

Umsetzungs-Roadmap in 5 Phasen

1. Analyse & Scoping - Datenmodell in BC und Shopware inventarisieren, Sync-Richtungen festlegen, kritische Szenarien (B2B-Preise, Bestände, Rahmenverträge) identifizieren
2. Architektur-Entscheidung - Direct vs. Middleware, Auswahl der Queue-Technologie (z. B. Azure Service Bus), Authentifizierungs-Setup mit Entra ID
3. MVP-Integration - Stamm-Entitäten (Kunden, Artikel, Bestand) bidirektional, OData-Client mit Retry/Backoff, Webhook-Subscriptions inklusive Renewal-Job
4. Erweiterung B2B-Logik - Preislisten, Kundengruppen, Rahmenverträge, Approval-Workflows, kundenspezifische Sortimente über Rule-Builder und Custom-Plugins
5. Operate & Reconcile - Monitoring, Alerting, nightly $batch-Reconciliation, Performance-Optimierung, kontinuierliche Anpassung an neue BC- und Shopware-Releases

Für Kunden, die von einer älteren Microsoft-ERP-Generation kommen, lohnt parallel der Blick auf Dynamics NAV - viele NAV-Installationen sind auf dem Weg nach BC, und eine zukunftsfeste Shop-Anbindung sollte das von Anfang an berücksichtigen. Ergänzend bieten unsere Schnittstellen-Services einen Überblick über alle Systemlandschaften.

BC-Anbindung als strategische Investition

Eine Business-Central-Shopware-Anbindung ist kein Plugin-Kauf, sondern eine strategische Architektur-Entscheidung. Wer auf OData v4, Webhooks und eine entkoppelte Middleware setzt, erhält eine Integration, die mit dem Geschäft wächst - im B2B-Umfeld ebenso wie im Multichannel-Vertrieb. Der ROI stellt sich in Best-in-Class-Projekten typischerweise binnen weniger Monate ein (Rand Group), vorausgesetzt Datenmodell, Fehler-Handling und Reconciliation werden von Beginn an ernst genommen. Wir unterstützen Sie von der Architektur über die Umsetzung bis zum laufenden Betrieb - auf Basis von Shopware 6 CE, sauberer Programmierung und etablierten B2B-Mustern.