ERP-, CRM- und PIM-Anbindung für Shopify-B2B-Angebote: die Integrationsmuster

Eine Angebotsebene für Shopify B2B sollte nicht direkt an die Warenwirtschaft, das CRM oder das PIM angebunden werden. Sie wird an Shopify angebunden, und Shopify an den Rest: Das Angebot erreicht das ERP als die Bestellung, zu der es wird, es erreicht das CRM als die Ereignisse, die es auslöst, und das PIM erreicht es gar nicht, weil es Produktdaten wie jeder andere Teil des Shops aus Shopify liest. Das ist keine Abkürzung. Es ist die einzige Anordnung, in der jedes Feld genau einen Schreiber hat – und es ist die Anordnung, für die die Shopify-ERP-Schnittstelle, die der Shop ohnehin betreibt, gebaut wurde.

Diese Seite beschreibt das Muster für die Agentur, die die Anbindung scoped: welches System welches Feld besitzt, welche Schlüssel vor jedem Abgleich festzulegen sind, die drei Türen, durch die ein Angebot heute den Shop verlassen kann, und was jede davon trägt, der Preislistenfluss vom ERP nach Shopify, von dem die Angebotsebene abhängt, die angebotsspezifischen Fehlerfälle und zehn Fragen für das Lastenheft. Es geht um Muster, nicht um Konnektoren: Die Seite nennt kein Produkt „integriert“ und sagt, wo eine Fähigkeit noch nicht existiert, genau das. Die Beispiele sind die Systeme, nach denen der deutschsprachige Markt in der Suche fragt – JTL-Wawi, Business Central, SAP Business One, Odoo, HubSpot, Akeneo –, ohne für eines davon eine fertige Schnittstelle zu behaupten.

Alles über Shopify wurde am 22. September 2026 gegen Shopifys eigene Seiten in API-Version 2026-07 geprüft; die Quellen stehen am Ende. Wo die Seite beschreibt, was QuotWay schreibt und bereitstellt, ist das eine Implementierung des Musters und als solche gekennzeichnet.

Wer besitzt was

Eine Integration ist eine Liste von Feldern und für jedes Feld das eine System, das es schreiben darf. Alles Weitere am Projekt – Taktung, Transport, Fehlerbehandlung – folgt aus dieser Liste, und die meisten Integrationsvorfälle lassen sich auf ein Feld mit zwei Schreibern zurückführen. Für einen Shopify-B2B-Shop mit Angebotsebene ist die Liste kurz genug für eine Tabelle.

Feld	Schreiber (führendes System)	Wo es in Shopify landet	Wer es liest	Übliche Taktung
Produktinhalte: Titel, Beschreibungen, Medien, Attribute	PIM (oder Shopify selbst, wenn es kein PIM gibt)	Product, ProductVariant, Metafelder	Storefront, Angebotsebene, ERP über die SKU	Batch, bei Änderung
Existenz der Variante und SKU	PIM oder Artikelstamm des ERP	ProductVariant.sku	Alles	Batch, bei Änderung
Basispreis	ERP	ProductVariant.price	Storefront, Kataloge, Angebotsebene	Batch, täglich oder bei Änderung
Kundenspezifische Preise und Mengenregeln	ERP	Katalog-Preislisten (PriceList), Mengenregeln	Storefront für den angemeldeten Standort, Angebotsebene als Ausgangspreis	Batch, bei Änderung
Bestand	ERP oder Lagerverwaltung	InventoryLevel je Standort	Storefront, Checkout, Vorprüfung der Umwandlung	Nahezu Echtzeit
Unternehmen, Standorte, Adressen, Steuernummer, Befreiungen, Zahlungsziele, Checkout-Einstellungen	Kundenstamm des ERP	Company, CompanyLocation (mit externalId), BuyerExperienceConfiguration	Storefront, Checkout, Angebotsebene über purchasingEntity	Batch, bei Änderung
Kontakte und ihre Rollen	CRM oder ERP, eines von beiden	CompanyContact, Customer	Anmeldung, Angebotsebene	Bei Änderung
Der verhandelte Preis und die Konditionen eines Geschäfts	Die Angebotsebene – die versiegelte, angenommene Version	Der Bestellentwurf, den sie bei der Umwandlung anlegt	Shopify-Checkout, dann das ERP als Bestellung	Einmal, bei Annahme
Die Bestellung und ihr Zustand	Shopify	Order	ERP über die Schnittstelle; CRM als Ergebnis des Geschäfts	Ereignis, orders/*-Webhooks
Versand- und Zahlungsstatus	ERP oder Lagerverwaltung, zurück nach Shopify	Fulfillment, Transaktionen	Kundenkonto, Benachrichtigungen	Ereignis
Pipeline: Deal, Phase, Verantwortliche, Forecast	CRM	Nichts – es bleibt im CRM	Vertriebsleitung	Ereignis, aus Angebotsereignissen

Zwei Dinge in dieser Tabelle leisten die Arbeit. Die Angebotsebene besitzt genau eine Zeile – den Datensatz dessen, was die beiden Seiten vereinbart haben – und liest alles andere. Und Shopify ist für jede andere Zeile der Treffpunkt: Das PIM schreibt Produkte hinein, das ERP schreibt Preise, Bestand und Unternehmen hinein, und das ERP liest Bestellungen heraus. Nichts schreibt in die Angebotsebene, und die Angebotsebene schreibt in nichts außer Shopify. Ein Angebot ist nichts, was das ERP empfängt; eine Bestellung ist es.

Das beantwortet auch eine Frage, die die Suchdaten zu diesem Thema immer wieder zeigen: Shopify ist kein ERP und keine Warenwirtschaft. Es ist das führende System für Produkte, wie sie verkauft werden, für Kundinnen, wie sie kaufen, und für Bestellungen, wie sie aufgegeben werden – und es hält bewusst nichts zu Einkauf, Buchhaltung, Kalkulation oder Fertigung. Das ERP bleibt der Stamm für Preise, Bestand und die kaufmännische Identität des Kunden, und die Tabelle oben lässt es diese Dinge nach Shopify schreiben, nie umgekehrt.

Schlüssel vor allem anderen

Ein Abgleich, der nicht sagen kann „dieses Shopify-Unternehmen ist jener ERP-Kunde“, endet mit einer Zuordnungstabelle, die niemand pflegt. Shopify gibt jedem B2B-Objekt genau dafür ein Feld, also werden die Schlüssel zuerst festgelegt.

• Unternehmen und Standorte. CompanyInput.externalId ist „eine eindeutige, extern vergebene ID für das Unternehmen“, und CompanyLocationInput.externalId dasselbe für den Standort. Die ERP-Kundennummer gehört an das Unternehmen, die Liefer- oder Rechnungsadressnummer des ERP an jeden Standort. Die companies-Abfrage filtert auf external_id, sodass die Schnittstelle den benötigten Datensatz ohne eigene Tabelle findet. Für alles, was das ERP über eine ID hinaus braucht – eine Preisgruppe, ein Vertreterkürzel, ein Kreditlimit – sind Metafelder da: COMPANY und COMPANY_LOCATION sind Metafeld-Besitzertypen, und dieselbe Abfrage filtert auf metafields.{namespace}.{key}.
• Produkte. Nur dann über die SKU abgleichen, wenn das ERP garantiert, dass die SKU über jede exportierte Variante hinweg eindeutig ist; wenn nicht, die ERP-Artikelnummer in einem Varianten-Metafeld mitführen und darauf abgleichen. Eine Angebotsposition verweist auf eine Shopify-Variante, also muss der Schlüssel, den das ERP für den Artikel verwendet, zu einer Variante aufgelöst sein, bevor die Angebotsebene ins Spiel kommt.
• Bestellungen aus Angeboten. Diesen Schlüssel muss die Angebotsebene liefern, weil nichts in Shopify eine Bestellung als aus einem Angebot entstanden markiert. QuotWay schreibt zwei Tags auf jeden Bestellentwurf, den es anlegt – quotway und quotway-<Referenz>, zum Beispiel quotway-QW-1042 –, und Shopify übernimmt Tags des Bestellentwurfs auf die Bestellung, „wenn Sie aus einem Bestellentwurf eine Bestellung erstellen“. Tags an Bestellungen sind auf 40 Zeichen und auf Buchstaben, Ziffern und Bindestriche begrenzt; eine Standardreferenz hält das ein, ein eigenes Referenzpräfix sollte es ebenfalls. Der Entwurf trägt außerdem ein für die Käuferin sichtbares Bestellattribut, quotway_conversion_group_id, das QuotWay selbst aus der orders/create-Nutzlast zurückliest, um die Bestellung dem Angebot zuzuordnen – also ist es der Schlüssel, der im ERP für denselben Zweck taugt.

Der eine Schlüssel, den man nicht verwenden sollte, ist sourceName. Eine Bestellung, die aus dem Entwurfsbereich des Admins abgeschlossen wurde, meldet shopify_draft_order; derselbe Entwurf, von der Käuferin über die Rechnung abgeschlossen, meldet web; von einer App abgeschlossen, meldet er die ID der App. Das ist Shopifys eigene Beschreibung des Feldverhaltens, und sie bedeutet, dass ein Filter auf sourceName je nachdem, wer geklickt hat, manche Angebotsbestellungen findet und die übrigen verfehlt.

Die drei Türen

Ein Angebot kann den Shop heute durch drei Türen verlassen. Jede trägt eine andere Form von Daten, und die falsche Tür für eine Anforderung zu wählen ist der Weg, auf dem ein Projekt am Ende etwas baut, was der Shop nicht tragen kann.

Tür 1: Das ERP erhält die Bestellung

Das ERP braucht das Angebot in genau einem Moment – wenn es zu etwas wird, das ausgeliefert und fakturiert werden muss –, und in diesem Moment ist es eine Shopify-Bestellung. Also nimmt das ERP es über das entgegen, was Bestellungen ohnehin bewegt: einen zertifizierten Konnektor, den Shopify-Connector der JTL-Wawi, eine iPaaS-Plattform oder ein Abonnement der Webhooks orders/create, orders/updated, orders/edited, orders/paid, orders/cancelled und orders/fulfilled. An diesem Weg ändert die Angebotsebene nichts; was sie hinzufügt, ist die Kennzeichnung auf der Bestellung, damit das ERP eine Angebotsbestellung von einer Storefront-Bestellung unterscheiden und sie dem Geschäft zuordnen kann.

Was eine aus QuotWay entstandene Bestellung trägt, so wie die Umwandlung sie in API 2026-07 anlegt:

Auf der Bestellung	Wert	Sichtbar für	Verwendung im ERP
Tag	quotway	Admin, Schnittstelle	Angebotsbestellungen in einen eigenen Ablauf leiten
Tag	quotway-<Referenz>, z. B. quotway-QW-1042	Admin, Schnittstelle	Die Angebotsnummer, als Schlüssel
Notiz (nur Händler)	QuotWay quote QW-1042 v3, danach eine etwaige interne Notiz	Admin, Schnittstelle	Die Nummer der angenommenen Version, für die Nachvollziehbarkeit
Bestellattribut	quotway_conversion_group_id	Käuferin und Admin	Der Idempotenzschlüssel einer Umwandlung; darauf entduplizieren
Bestellattribute	Special requests, dann jedes beantwortete Formularfeld als Bezeichnung: Wert	Käuferin und Admin	Hinweise der Käuferin und jedes Feld, das das Formular erhebt, etwa eine von ihr eingetragene Referenz
Positionseigenschaft	Customer note an Positionen, die die Käuferin kommentiert hat	Käuferin und Admin	Hinweise je Position
purchasingEntity	Unternehmen, Standort, Kontakt – bei unternehmensbezogenen Angeboten	Schnittstelle	Der ERP-Kunde, über die externalId des Standorts
paymentTerms	Die Zahlungsziele des Standorts, wie auf den Entwurf angewandt	Schnittstelle	Fälligkeit und Forderungen
presentmentCurrencyCode, currencyCode, totalPriceSet	Die Angebotswährung, die Shopwährung, Summen in beiden	Schnittstelle	In der richtigen Währung buchen (siehe Fehlerfälle)
poNumber	Nur, wenn der Händler sie im Entwurf ergänzt oder die Käuferin sie im Checkout eingegeben hat; die Umwandlung schreibt sie nicht	Schnittstelle	Zuordnung der Bestellnummer des Kunden

Zwei Anmerkungen zu dieser Tabelle. Die Angebotsebene setzt poNumber nicht. Das Anfrageformular von QuotWay hat ein eingebautes Feld für die Bestellnummer der Käuferin; der Wert bleibt am Angebot und wird im Admin angezeigt, aber die Umwandlung übergibt ihn heute nicht an den Entwurf – weder in DraftOrderInput.poNumber noch als Attribut; nur ein eigenes Formularfeld erreicht die Bestellung, als Attribut unter seiner Bezeichnung. Ein Händler, der die Bestellnummer auf der Shopify-Bestellung braucht, ergänzt sie im Entwurf, bevor er die Rechnung sendet, und eine ERP-Zuordnung sollte sie nicht vom Angebot erwarten. Und die Attribute sind der Mechanismus, auf den sich QuotWay für seine eigene Buchführung verlässt – sein Handler liest quotway_conversion_group_id aus der orders/create-Nutzlast, um das Angebot als umgewandelt zu markieren –, sodass eine ERP-Zuordnung auf demselben Attribut auf demselben Verhalten aufbaut, von dem die App im Produktivbetrieb abhängt.

Welche Schnittstelle die Bestellung trägt, entscheidet der Shop, nicht die Angebotsebene. Shopifys Global ERP Program führt heute fünf zertifizierte Apps – Dynamics 365 Business Central, Brightpearl by Sage, NetSuite ERP Connector, Acumatica Cloud ERP und den Infor eCommerce Connector – und hat den Umfang des Programms beim Start als „Bestand, Produkte, Bestellungen und Kundeninformationen“ beschrieben. Im deutschsprachigen Markt kommt dazu, was die Suchdaten zeigen: die JTL-Wawi mit ihrem Shopify-Connector, SAP Business One, Odoo. Ob ein bestimmter Konnektor auch Unternehmen, Standorte und Katalog-Preislisten schreibt, ist eine Frage je Konnektor, und die Antwort entscheidet, ob die ERP-nach-Shopify-Zeilen der Besitztabelle über den Konnektor oder über die Admin-API laufen. Shopifys eigener Hinweis in der Spring-’26-Edition, dass QuickBooks B2B-Bestellungen, Bestellnummern und Unternehmensdaten synchronisiert, ist die Art Satz, nach der man in der Dokumentation eines Konnektors suchen sollte, bevor man ihn voraussetzt.

Tür 2: Das CRM erhält Ereignisse

Das Objekt eines CRM ist der Deal, und ein Deal verändert sich durch Ereignisse: angelegt, Vorschlag raus, in Verhandlung, gewonnen, verloren. Das ist die Form des Lebenszyklus eines Angebots, und genau das trägt Shopify Flow. QuotWay stellt Flow ab dem Professional-Tarif zehn Trigger bereit – eingereicht, Vorschlag gesendet, Gegenangebot, angenommen, abgelehnt, abgelaufen, umgewandelt, Freigabe angefordert, erteilt und verweigert –, jeder mit Feldern auf Angebotsebene: ID, Nummer, ein Deep-Link zum Angebot im Admin, Status, Summe und Währung, wer wann gehandelt hat, die Shopify-Kunden-ID (leer bei Gastanfragen) und die E-Mail der Käuferin, die immer vorhanden ist. Einzelne Trigger ergänzen die Rundennummer, ob die Annahme vollständig oder teilweise war und die angenommene Summe, die ID des Bestellentwurfs bei der Umwandlung und ob eine Freigabe die des Händlers oder die der Käuferin war.

Vom Trigger aus erreicht der Workflow das CRM auf einem von zwei Wegen. Die eingebauten Flow-Konnektoren (Slack, E-Mail, Google Sheets und die Apps, die Aktionen registriert haben) decken die Benachrichtigungsfälle direkt ab. Für ein CRM ohne Flow-Aktion – HubSpot ist das CRM, das in den deutschen Suchdaten auftaucht – sendet HTTP-Anfrage senden die Felder des Triggers an jeden Endpunkt, die API des CRM oder den Webhook einer iPaaS-Plattform, mit GET, POST, PUT, PATCH und DELETE, einem Zeitfenster von 30 Sekunden für die Antwort und einer Wiederholungsregel je Statusklasse, die bis zu 24 Stunden weiterprobieren kann. Flow selbst ist auf Basic, Grow, Advanced und Plus kostenlos; die HTTP-Aktion braucht Grow, Advanced oder Plus.

Die Zuordnung, als Tabelle, die die CRM-Administration prüfen kann:

Angebotsereignis	Wirkung im CRM
Angebot eingereicht	Deal anlegen oder aktualisieren; Kontakt über die E-Mail zuordnen, oder über die Kunden-ID, wenn vorhanden
Vorschlag gesendet	Phase: Vorschlag; Betrag: die Vorschlagssumme
Gegenangebot	Phase: Verhandlung; Rundennummer vermerken
Freigabe angefordert / erteilt / verweigert	Aktivität am Deal; nach Freigabeart verzweigen, um die eigene Kette des Händlers von der der Käuferin zu trennen
Angebot angenommen	Phase: gewonnen, Betrag: die angenommene Summe; eine Teilannahme ist ein Gewinn für die angenommenen Positionen, der Rest bleibt offen
Angebot abgelehnt, Angebot abgelaufen	Phase: verloren, mit Grund
Angebot umgewandelt	ID des Bestellentwurfs anhängen; die Bestellnummer folgt über Tür 1, sobald die Käuferin bezahlt

Was Tür 2 nicht tragen kann, sind Positionen. Die Trigger enthalten keine Positionen, Mengen oder Positionspreise, und ein Workflow, der sie wollte, hätte noch nichts, woher er sie holen könnte. Ein CRM, das die angebotenen Positionen zeigen muss, braucht die API weiter unten, keinen Umweg über Flow.

Tür 3: Finanzen erhalten eine Datei

Manche Anforderungen sind Reporting, keine Integration: Die Buchhaltung will die Angebote des Monats mit Status und Summen gegen die Bestellungen, zu denen sie wurden; ein BI-Werkzeug will den Pipeline-Wert über die Zeit. Der Analytics-Export von QuotWay (ab Professional) lädt die Angebote hinter den Kennzahlen als CSV für den gewählten Zeitraum und die gesetzten Filter herunter. Er ist stapelweise, er ist auf Angebotsebene, und er ist die richtige Tür, wenn niemand die Daten vor Monatsende braucht. Er ist die falsche Tür, sobald auf der anderen Seite ein System wartet statt eines Menschen.

Was auf die API wartet

Drei Anforderungen passen heute durch keine Tür, und die ehrliche Antwort im Scoping ist, das zu sagen, statt sie zu nähern: die Positionen eines Angebots vor der Umwandlung ins ERP zu schieben, ein Angebot von der ERP- oder CRM-Seite aus anzulegen, und ein beidseitiger Status zwischen Angebot und Deal. Jede davon braucht eine API, über die ein System Angebote lesen und schreiben kann, und QuotWay hat noch keine öffentliche API und keine ausgehenden Webhooks. Bis dahin ist die Zuordnung aus Tür 1 der Ort, an dem das ERP dem Angebot begegnet, und es lohnt sich, sie so zu entwerfen, dass sie sich mit der API nicht ändern muss: Angebotsnummer, Versionsnummer und Umwandlungsgruppen-ID bleiben dieselben Schlüssel.

Preislisten: Das ERP schreibt, Shopify löst auf, das Angebot liest

Die Zeile der Besitztabelle, die am häufigsten schiefgeht, sind kundenspezifische Preise, weil drei Systeme eine Meinung dazu haben. Das Muster, das hält, ist eine Richtung: Das ERP schreibt Preise in Shopify-Kataloge, Shopify löst auf, welchen Preis ein bestimmter Standort sieht, und die Angebotsebene nimmt diesen aufgelösten Preis als Ausgangspunkt der Verhandlung.

Auf der Shopify-Seite ist ein Katalog eine Veröffentlichung (welche Produkte) plus eine Preisliste (was sie kosten). Eine Preisliste nimmt Festpreise je Variante über die Admin-API entgegen – priceListFixedPricesAdd „erstellt oder aktualisiert Festpreise in einer PriceList“, mit Geschwistern zum Aktualisieren je Produkt, Löschen und Verwalten der Liste – oder über den CSV-Import des Admins, der nur Festpreise trägt und den Festpreis einer Variante entfernt, wenn die Zeile mit leerem Preis importiert wird. Festpreise überschreiben den prozentualen Aufschlag des Katalogs, sodass ein ERP, das Kundenpreisgruppen als Festbeträge exportiert und die Prozentregeln in Shopify belässt, eine saubere Trennung hat. Erreicht ein Standort dieselbe Variante über mehr als einen Katalog, wendet Shopify zuerst den spezifischsten Katalog und dann den niedrigsten Preis an, wobei Mengenregeln und Mengenpreise dem gewinnenden Katalog folgen; außerhalb von Plus liegt die Grenze bei drei aktiven Katalogen über alle B2B-Märkte hinweg. Die aktuellen Zeilen stehen in der Shopify-B2B-Referenz.

Zwei Regeln machen diese Zeile sicher. Die Angebotsebene darf nie einen eigenen Preis für ein Produkt halten – ihr Ausgangspreis sollte aus dem abgeleitet sein, was Shopify der angemeldeten Käuferin zeigt, damit eine Preisänderung im ERP das nächste Angebot über den Katalog erreicht, ohne zweiten Abgleich. Und ein verhandelter Preis darf nie automatisch in eine Preisliste zurückgeschrieben werden: Ein Dealpreis ist das Ergebnis eines Geschäfts, und ein Job, der ihn zum Listenpreis des Kunden befördert, hat jedes Zugeständnis einer Vertriebsmitarbeiterin in einen dauerhaften Rabatt verwandelt, ohne dass es jemand entschieden hätte.

Unternehmen und Standorte: der Kundenstamm, in einer Richtung

Die zweite Zeile, die zwei Schreiber anzieht, ist das Unternehmen. Shopify lässt Händler Unternehmen im Admin oder über die Admin-API anlegen, und ein Registrierungsablauf im Storefront kann dasselbe Objekt befüllen; das ERP hat einen Kundenstamm mit Nummernkreis, Kreditlimit und Zahlungszielen. Eines davon wählen. Ist das ERP der Stamm, legt es die Company und jede CompanyLocation mit gesetzter externalId an, dazu taxRegistrationId, taxExempt und taxExemptions des Standorts sowie eine buyerExperienceConfiguration mit der Vorlage für die Zahlungsziele, ob Bestellungen des Standorts zur Prüfung als Entwurf eingehen und ob die Käuferin eine einmalige Lieferadresse eingeben darf – und es aktualisiert sie bei Änderung. Ist Shopify der Stamm – typisch, wenn Konten aus einer Registrierung stammen –, abonniert das ERP companies/create, company_locations/create und ihre update-Themen, legt seinen Kunden aus dem Webhook an und schreibt die ERP-Nummer als externalId zurück, damit das nächste Ereignis zugeordnet werden kann. So oder so: Ein System legt an, das andere reagiert.

Kontakte folgen derselben Regel mit einem anderen Kandidaten: Oft hält ein CRM die Personen, während das ERP die Konten hält. Welches System die Person besitzt, schreibt den CompanyContact; die Themen company_contacts/* und company_contact_roles/* sagen der anderen Seite, was passiert ist. Eine Angebotsebene mit unternehmensbezogenen Angeboten liest dann zum Zeitpunkt der Anfrage den Standort der Käuferin und trägt ihn als purchasingEntity in den Entwurf – so erreichen Zahlungsziele, Steuereinstellungen und Identität des Standorts die Bestellung und über Tür 1 das ERP.

Fehlerfälle, die das Angebot hinzufügt

Die gewöhnlichen Shopify-ERP-Fehlerfälle – doppelt zugestellte Webhooks, Ankunft in falscher Reihenfolge, ein Konnektor, der ein Feld falsch abbildet – gelten hier wie überall. Diese kommen durch das Angebot hinzu.

Fehlerfall	Was passiert	Entwurf
Filtern auf sourceName	Der Wert hängt davon ab, wer den Entwurf abgeschlossen hat: shopify_draft_order aus dem Admin, web über die Rechnung, eine App-ID von einer App	Angebotsbestellungen über das Tag quotway oder das Referenz-Tag erkennen
Ein Angebot, mehrere Bestellungen	Teilannahme und aufgeteilte Umwandlung erzeugen je Umwandlungsgruppe einen Entwurf, sodass aus einem Angebot zwei oder mehr Bestellungen werden können, während nicht angenommene Positionen offen bleiben	Auf quotway_conversion_group_id entduplizieren, nicht auf die Angebotsnummer; N Bestellungen je Referenz erwarten
Falsche Währung gebucht	Der Entwurf entsteht in der Angebotswährung (presentmentCurrencyCode); currencyCode ist die Shopwährung; totalPriceSet trägt beide	Festlegen, welche Währung das ERP bucht, und diese Seite des Geldbetrags lesen; siehe Mehrwährungs-B2B auf Shopify
Bestellung nach der Umwandlung bearbeitet	Der Händler bearbeitet die Bestellung; orders/edited feuert; die versiegelte Version des Angebots ändert sich nicht	Nach der Umwandlung ist die Bestellung die Wahrheit für Versand und Rechnung; das Angebot ist der Nachweis der Vereinbarung, keine zweite Kopie zum Abgleichen
Referenz-Tag abgelehnt oder gekürzt	Bestell-Tags sind auf 40 Zeichen und auf Buchstaben, Ziffern und Bindestriche begrenzt	Ein eigenes Referenzpräfix innerhalb dieser Regeln halten
Webhook kommt doppelt, spät oder nie	Zustellung mindestens einmal, acht Wiederholungen über vier Stunden; keine Reihenfolgegarantie	Idempotente Handler, geschlüsselt auf die Bestell-ID; ein Abgleichjob, der Shopify fragt – derselbe Entwurf, den die Umwandlung selbst braucht
Standorte mit Entwurfsprüfung	Unter „alle Bestellungen zur Prüfung als Entwürfe einreichen“ kommt auch jede Storefront-Bestellung des Standorts als Entwurf an, neben den Entwürfen der Angebotsebene	Über das Tag unterscheiden; nicht jeden Entwurf als Angebot behandeln
Gastangebote	Eine Anfrage einer Käuferin ohne Shopify-Kunde trägt im Flow-Trigger eine leere Kunden-ID	Den CRM-Kontakt über die E-Mail der Käuferin zuordnen, die der Trigger immer trägt
Unternehmen auf beiden Seiten angelegt	Registrierung in Shopify und ein im ERP angelegter Kunde für dieselbe Käuferin	Ein Stamm; die andere Seite prüft externalId, bevor sie anlegt
Preis-Reimport löscht einen Preis	Eine Katalog-CSV-Zeile, importiert mit leerem Festpreis und leerem Vergleichspreis, entfernt den Festpreis dieser Variante	Vor dem Import exportieren; nie eine Teildatei im Kreis schicken
Bestellnummer des Kunden auf der Bestellung erwartet	Die Umwandlung schreibt poNumber nicht; das eingebaute Feld bleibt am Angebot, nur ein eigenes Formularfeld landet als Attribut	Die Nummer vor der Rechnung im Entwurf ergänzen oder als eigenes Feld erheben und das Attribut abbilden

Zehn Fragen vor dem Lastenheft

1. Welches System schreibt jede Zeile der Besitztabelle, und hat der Kunde das schriftlich bestätigt?
2. Wie lautet der ERP-Schlüssel für Kunde, Lieferadresse und Artikel, und welches Shopify-Feld trägt ihn jeweils (externalId, ein Metafeld, die SKU)?
3. Schreibt die Schnittstelle, die der Shop betreibt oder betreiben wird, Unternehmen, Standorte und Katalog-Preislisten – oder nur Produkte, Bestand, Kunden und Bestellungen?
4. Wie verlassen kundenspezifische Preise das ERP – als Festbeträge je Variante, als Prozentgruppen oder beides –, und passt die Grenze von drei aktiven Katalogen außerhalb von Plus dazu?
5. Welche Währung bucht das ERP, und bietet die Angebotsebene in der Marktwährung des Standorts an?
6. Ist das ERP auf mehrere Bestellungen je Angebotsreferenz vorbereitet, und entdupliziert es auf die Umwandlungsgruppe?
7. Welche Angebotsereignisse braucht das CRM, und erlaubt der Shopify-Tarif „HTTP-Anfrage senden“, falls das CRM keine Flow-Aktion hat?
8. Braucht jemand Angebotspositionen vor der Umwandlung in einem anderen System? Wenn ja, ist das die Anforderung, die auf eine API wartet, und das Lastenheft sollte das sagen.
9. Wer besitzt das Anlegen von Unternehmen, und wie erfährt die andere Seite davon?
10. Was muss der Testplan für den Start für die Anbindung ergänzen – je Tür ein Angebot, auf einem Entwicklungsshop, vor dem Go-live?

Wie QuotWay in das Muster passt

Als eine Implementierung gekennzeichnet, damit sich das Muster oben an etwas Konkretem prüfen lässt. QuotWay besitzt die versiegelte, angenommene Version und sonst nichts: Es liest Varianten, katalogaufgelöste Preise und – im Enterprise-Tarif – den Unternehmensstandort der Käuferin aus Shopify und schreibt je Umwandlung einen Bestellentwurf, getaggt und attributiert wie in der Tabelle zu Tür 1, mit purchasingEntity und den Zahlungszielen des Standorts bei unternehmensbezogenen Angeboten und der Angebotswährung als Präsentationswährung. Seine Umwandlung ist idempotent und wird abgeglichen, was die Regel „N Bestellungen je Angebot“ überhaupt erst tragfähig macht. Es stellt die zehn Flow-Trigger ab Professional und drei Aktionen auf Enterprise bereit, dazu einen CSV-Export der Angebote ab Professional. Es hat keinen eigenen ERP- oder CRM-Konnektor und noch keine öffentliche API und keine ausgehenden Webhooks. Die Tarife stehen auf der Preisseite, die Flow-Oberfläche auf der Seite zu Shopify Flow und die Referenz der Trigger-Felder in der Dokumentation.

Die Shopify-Fakten in diesem Beitrag werden in der Shopify-B2B-Referenz aktuell gehalten.

Häufige Fragen

Ist Shopify ein ERP oder eine Warenwirtschaft?

Nein. Shopify ist das führende System für Produkte, wie sie verkauft werden, Kundinnen, wie sie kaufen, und Bestellungen, wie sie aufgegeben werden. Es hält keine Daten zu Einkauf, Buchhaltung, Kalkulation oder Fertigung – dafür ist das ERP da. In einem B2B-Shop bleibt das ERP der Stamm für Preise, Bestand und die kaufmännische Identität des Kunden und schreibt diese nach Shopify; Shopify bleibt der Stamm für die Bestellung und übergibt sie ans ERP.

Welche ERP-Systeme haben eine zertifizierte Shopify-Schnittstelle?

Shopifys Global ERP Program führt am 22. September 2026 fünf zertifizierte Apps: Dynamics 365 Business Central, Brightpearl by Sage, NetSuite ERP Connector, Acumatica Cloud ERP und den Infor eCommerce Connector. Andere Systeme – im deutschsprachigen Raum etwa JTL-Wawi, SAP Business One oder Odoo – verbinden sich über Partner-Apps, eine iPaaS-Plattform oder die Admin-API. Ob eine davon auch B2B-Unternehmen und Katalog-Preislisten schreibt, ist je Konnektor in der Dokumentation zu prüfen.

Wie kommt ein Angebot in Business Central, die JTL-Wawi oder SAP?

Als die Bestellung, zu der es wird. Die Angebotsebene wandelt das angenommene Angebot in einen Shopify-Bestellentwurf mit der Angebotsreferenz als Tag um; sobald die Käuferin bezahlt oder der Händler den Entwurf abschließt, fließt die Bestellung über die Schnittstelle, die der Shop ohnehin nutzt, ins ERP, das sie am Tag erkennt und über die Referenz dem Geschäft zuordnet. Nichts schiebt ein offenes Angebot ins ERP, und nichts sollte das.

Kann Shopify Flow Angebotsdaten an HubSpot oder Salesforce senden?

Ja, auf Angebotsebene. Flow-Trigger feuern bei eingereicht, Vorschlag gesendet, Gegenangebot, angenommen, abgelehnt, abgelaufen, umgewandelt und den drei Freigabeereignissen, mit Nummer, Status, Summe, Währung, E-Mail der Käuferin und Admin-Link. Ein CRM mit Flow-Aktion erhält sie direkt; jedes andere CRM erhält sie über „HTTP-Anfrage senden“ auf den Tarifen Grow, Advanced und Plus. Positionen sind nicht in den Triggern enthalten.

Wie synchronisiere ich ERP-Preislisten nach Shopify B2B?

Indem Sie sie in Katalog-Preislisten schreiben, entweder über die Festpreis-Mutationen der Admin-API oder über den Katalog-CSV-Import des Admins, und die Richtung einseitig halten. Festpreise überschreiben den prozentualen Aufschlag des Katalogs, ein leerer Preis beim Import entfernt den Festpreis, und außerhalb von Plus sind drei aktive Kataloge über alle B2B-Märkte hinweg die Grenze. Die Angebotsebene nimmt dann den Preis, den Shopify für den Standort auflöst, als Ausgangspreis.

Brauche ich für all das Shopify Plus?

Für das Muster nicht. Flow gibt es auf jedem Tarif, die Aktion „HTTP-Anfrage senden“ braucht Grow, Advanced oder Plus, und die Kataloggrenze außerhalb von Plus liegt bei drei aktiven Katalogen über die B2B-Märkte hinweg. Plus ergänzt die direkte Katalogzuweisung an Unternehmen und Standorte, unbegrenzt viele aktive Kataloge und Anzahlungen.

Wo passt ein PIM hinein?

Vor Shopify und nirgends in der Nähe des Angebots. Das PIM – in den deutschen Suchdaten vor allem Akeneo – schreibt Produktinhalte, Attribute und Medien in Shopify-Produkte; die Angebotsebene verweist auf Shopify-Varianten und hält keine eigenen Produktdaten. Sind sich PIM und ERP uneins, ob eine Variante existiert, muss das geklärt sein, bevor es Shopify erreicht, weil die Angebotsposition eine Variante braucht, auf die sie zeigt.

Quellen

Shopify-Seiten, alle am 22. September 2026 in API-Version 2026-07 gelesen, sofern nicht anders datiert:

• Objekte DraftOrder und Order
• Tags verwenden
• CompanyInput, CompanyLocationInput, BuyerExperienceConfigurationInput, die companies-Abfrage und MetafieldOwnerType
• priceListFixedPricesAdd und B2B-Preise mit Katalogen anpassen
• Bulk-Importe
• WebhookSubscriptionTopic und Webhooks (gelesen am 20. September 2026)
• Shopify Flow und die Aktion HTTP-Anfrage senden
• Shopify startet das Global ERP Program und die Sammlung des Global ERP Program
• B2B-Bestellungen mit Bestellentwürfen erstellen und Checkout-Einstellungen im B2B verwalten
• source_name vs sales channel, Shopify Staff, Shopify Community, 28. September 2022
• Shopify Editions Spring ’26 zu den QuickBooks- und Mailchimp-Integrationen (gelesen am 20. September 2026)

Was QuotWay auf einen Bestellentwurf schreibt, aus der Bestellung zurückliest und Flow bereitstellt, ist aus seinem Quellcode und seinen Tests beschrieben; die Darstellung für Händler steht in der oben verlinkten Dokumentation. Wie der deutschsprachige Markt dieses Thema benennt, stammt aus der Autocomplete-Erhebung der Keyword-Recherche der Site vom 22. September 2026.