Ein Shopify-Bestellentwurf ist kein Angebot: der Zustandsautomat hinter beiden

Ein Shopify-Bestellentwurf ist der Datensatz einer Bestellung, die auf ihre Bezahlung wartet. Er hat drei Status – offen, Rechnung gesendet, abgeschlossen – und jeder davon setzt voraus, dass der Preis bereits vereinbart ist. Ein Angebot ist der Datensatz darüber, wie der Preis vereinbart wird: eine Anfrage, ein Vorschlag, Überarbeitungen, Gegenangebote, Freigaben und eine Annahme.

Für das Erste hat Shopify ein Objekt, für das Zweite keines. Ein B2B-Aufbau, der Verhandlung braucht, muss die Angebotsstatus also woanders abbilden und den Bestellentwurf am Ende anlegen.

Das ist die ganze Antwort; der Rest dieser Seite ist der Beleg. Sie geht Feld für Feld durch, was Shopifys Bestellentwurf tatsächlich abbildet, dann durch die Status, die eine Verhandlung braucht und die kein Feld eines Bestellentwurfs halten kann, und schließlich dahin, wo der Bestellentwurf hingehört, sobald man beides auseinanderhält. Geschrieben ist sie für den Agenturentwickler, dessen erster Reflex bei einem B2B-Angebotsprojekt lautet: „Warum nehmen wir nicht einfach Bestellentwürfe?“ Ein guter Reflex, denn Bestellentwürfe sind das richtige Ende – und ein teurer, wenn sie auch die Mitte sein sollen.

Alles über Shopify wurde am 21. September 2026 gegen Shopifys eigene Dokumentation bei API-Version 2026-07 geprüft; die Quellen stehen am Ende. Wo die Seite beschreibt, wie QuotWay die Status abbildet, ist das eine Umsetzung des Musters, und das Muster gilt auch für eine Eigenentwicklung.

Was ein Bestellentwurf abbildet

Shopifys Enum DraftOrderStatus hat drei Werte, und ihre Definitionen sind die kürzeste Beschreibung dessen, wofür ein Bestellentwurf da ist. OPEN: „Der Bestellentwurf ist offen. Er wurde nicht bezahlt, und es wurde keine Rechnung gesendet.“ INVOICE_SENT: „Eine Rechnung für den Bestellentwurf wurde an den Kunden gesendet.“ COMPLETED: „Der Bestellentwurf wurde bezahlt.“ Einen vierten Wert gibt es nicht. Nichts in diesem Enum beschreibt einen Preis, der angefragt, angeboten, überarbeitet oder abgelehnt wird, weil das Objekt erst beginnt, nachdem das geschehen ist.

Die Felder rund um den Status sagen dasselbe. invoiceSentAt ist der Zeitpunkt, zu dem die Rechnung zuletzt per E-Mail gesendet wurde – ein einzelner Zeitstempel, der bei jedem Versand überschrieben wird. completedAt ist der Moment, in dem aus dem Entwurf die Bestellung wurde. ready sagt, ob der Entwurf überhaupt abgeschlossen werden kann. order zeigt auf die Bestellung, sobald sie existiert. paymentTerms, deposit, amountDueNowSet und amountDueLaterSet beschreiben, wie die vereinbarte Summe eingezogen wird. anyVariantPricesOverridden sagt, ob eine Position einen anderen Preis als den Katalogpreis trägt – es hält fest, dass ein Preis geändert wurde, nicht von welchem Wert aus, durch wen, oder ob der Käufer zugestimmt hat.

Ein Bestellentwurf ist außerdem sein ganzes Leben lang veränderbar. draftOrderUpdate nimmt ein vollständiges DraftOrderInput und ersetzt, was da ist – die Positionen werden komplett ausgetauscht, nicht einzeln angepasst –, und die Dokumentation schränkt das Aktualisieren eines Entwurfs, dessen Rechnung schon raus ist, nicht ein. Sie warnt nur vor der Folge: Ein Update nach begonnenem Checkout trennt diesen Checkout vom Entwurf, und die Bestellung kann dann entstehen, während der Entwurf offen bleibt. Die Zeitleiste des Entwurfs (events) hält jede dieser Änderungen als BasicEvent fest, dessen Feld message „menschenlesbarer Text, der das Ereignis beschreibt“ ist. Das ist ein Protokoll, dass eine Änderung stattfand; es ist keine nummerierte Version, die man wieder öffnen kann, und es gibt kein Feld, das die Positionen so zurückgibt, wie sie vor der Änderung standen.

Für B2B ergänzt Shopify die Teile, die eine Geschäftsbestellung braucht – und weiterhin nichts, was eine Verhandlung braucht. Ein Bestellentwurf kann im Admin beginnen oder im Shop: Steht ein Unternehmensstandort auf „Alle Bestellungen als Entwürfe zur Prüfung einreichen“ (die Checkout-Übersicht von Shopify nennt dieselbe Einstellung weiterhin „Nur Bestellentwürfe im Checkout zulassen“), sehen seine Käufer im Checkout statt eines Zahlschritts die Schaltfläche Zur Genehmigung einreichen, und der Entwurf landet mit gesperrten Preisen auf der Seite Entwürfe des Händlers. Der Händler kann Produkte und Mengen ändern, eine Bestellnummer ergänzen, Zahlungsziele und eine Anzahlung setzen, die Preise sperren oder entsperren, die Rechnung senden oder die Bestellung direkt anlegen. Die Preissperre lohnt ein genaues Lesen: Sie „verhindert, dass Preise erhöht werden, verhindert aber auch, dass sie automatisch gesenkt werden“ – sie friert den Preis ein, den der Entwurf bereits hat, und das ist nicht dasselbe wie das Festhalten eines Preises, auf den sich zwei Parteien geeinigt haben. Bezahlt der Käufer über den Rechnungslink, wird der Entwurf zur Bestellung mit Status bezahlt; mit Zahlungszielen beginnt die Bestellung als ausstehend und wandert über teilweise bezahlt zu bezahlt, während Shopify nach dem Zahlplan einzieht. Und ein Entwurf, den ein Jahr lang niemand bearbeitet, wird gelöscht – jede Bearbeitung setzt die Uhr zurück, was ein weiterer Grund ist, warum der Entwurf nicht der Ort sein sollte, an dem eine langsame Verhandlung lebt.

Shopifys eigener Changelog beschreibt die Reihenfolge exakt. Der Eintrag vom Juli 2024, der Zahlungsziele auf Rechnungen zu Bestellentwürfen brachte, sagt, die Rechnung gebe Kunden „die Gelegenheit, ihren verhandelten Warenkorb und die Preise zu prüfen, bevor sie die Bestellung aufgeben“. Verhandelt, Vergangenheit, bevor der Bestellentwurf aufgegeben wird. Die Verhandlung fand woanders statt.

Was ein Bestellentwurf nicht abbilden kann

Die Tabelle listet, was eine B2B-Verhandlung festhalten muss und was der Bestellentwurf dafür jeweils bietet. Die mittlere Spalte ist die ehrliche: Wo der Bestellentwurf ein Feld hat, wird es genannt; wo er keines hat, steht das da.

Eine Verhandlung muss festhalten	Bestellentwurf	Was tatsächlich gebraucht wird
Den Preis, den der Käufer angefragt hat	Kein Feld. Die Position hat einen Preis; sie weiß nicht, ob Käufer oder Verkäufer ihn gesetzt haben	Angefragter Preis je Position, getrennt von angebotenem und finalem Preis
Das Angebot des Verkäufers, wie es gesendet wurde	Die aktuellen Positionen. draftOrderUpdate ersetzt sie vollständig	Eine nummerierte Version, die in dem Moment gesperrt wird, in dem sie rausgeht
Die Versionshistorie	Eine Zeitleiste aus menschenlesbarem Ereignistext	Jede Version, wieder öffenbar, mit einem Vergleich zwischen zwei beliebigen
Ein Gegenangebot des Käufers	Nichts. Die Handlungen des Käufers an einem Entwurf sind „Rechnung bezahlen“ oder „nichts tun“	Eine vom Käufer verfasste Version mit dem angefragten Preis je Position
Eine Freigabe des Händlers, bevor das Angebot rausgeht	Nichts. Mitarbeiterberechtigungen regeln, welche Bestellungen jemand sieht, nicht ob ein Angebot rausgehen darf	Eine Richtlinie, die ein Angebot anhält, und die Entscheidung mit ihrem Urheber
Eine Freigabekette auf Käuferseite	Nichts. „Zur Genehmigung einreichen“ bittet den Händler, die Bestellung des Käufers zu genehmigen	Ein Status, in dem die Freigebenden des Käufers handeln können, mit jedem Schritt protokolliert
Einige Positionen annehmen, die übrigen offen lassen	Nichts. Ein Entwurf wird ganz bezahlt oder gar nicht	Annahme je Position, wobei die nicht gewählten Positionen für eine spätere Runde offen bleiben
Ablauf eines Angebots	Die Löschung nach einem Jahr Inaktivität – eine Aufräumfrist, keine kaufmännische	Ein vom Verkäufer gesetztes Gültigkeitsdatum, nach dem Annahme und Gegenangebot zurückgezogen sind
Unveränderlichkeit nach dem Senden	Keine. Ein Entwurf mit gesendeter Rechnung bleibt bearbeitbar, was einen laufenden Checkout abkoppelt	Eine gesendete Version, die nicht an Ort und Stelle bearbeitet werden kann; eine Änderung ist eine neue Version
Wer welchen Zug machen darf	Die Berechtigungen des Admin-Nutzers	Jeder Übergang ist einem benannten Akteur erlaubt – Käufer, Händler oder System – und allen anderen verweigert
Woher der Preis kam	anyVariantPricesOverridden sagt, dass eine Position überschrieben wurde, nicht von wo aus	Der Katalogpreis, von dem die Verhandlung ausging, aufgelöst für den Standort des Käufers, mit der Katalog-ID als Herkunft
Endzustände	COMPLETED (bezahlt) oder gelöscht	Abgelehnt, abgelaufen, storniert, erstattet und geschlossen als getrennte Enden, weil jedes anders berichtet und nachgefasst wird

Nichts davon ist Kritik am Bestellentwurf. Er ist ein präzises Objekt für eine präzise Aufgabe. Der Fehler liegt allein darin, ihn die Aufgabe vor seiner eigenen erledigen zu lassen.

Die Angebotsstatus, für die Shopify kein Objekt hat

Ein Zustandsautomat für Angebote muss nicht groß sein, aber er muss explizit sein, denn jeder Status beantwortet eine Frage, die später jemand stellen wird: Was konnte der Käufer an diesem Punkt tun, was konnte der Händler tun, und wer hat was getan? Die Status unten sind die, die QuotWay verwendet; eine Eigenentwicklung würde sie anders nennen und dieselbe Menge brauchen.

Angefragt. Der Käufer hat gefragt. Positionen, Mengen, die Preise, auf die er hofft, eine Notiz, eine Bestellnummer, eigene Felder, Anhänge. Der Händler hat noch nichts getan. Dieser Status existiert, damit die Anfrage ein Datensatz ist, bevor irgendjemand sie bepreist hat – der Architektur-Beitrag erklärt, warum die Anfrage selbst Daten sind, die Shopify nie hält.

In Prüfung. Ein Händler hat sie geöffnet. Hier bepreist er die Positionen vom Katalogpreis des Käufers aus – aufgelöst für dessen Unternehmensstandort, nicht aus einer Liste kopiert –, ergänzt oder entfernt Positionen, fügt Versand hinzu und schreibt das Angebot.

Wartet auf Händlerfreigabe. Eine Richtlinie hat das Angebot angehalten, weil etwas daran sie auslöst: die Summe, die Produkte darauf, das Unternehmen, das Kundentag. Das Angebot geht nicht an den Käufer, bis die freigebende Person handelt, und ihre Entscheidung wird mit Namen festgehalten. Shopify-Mitarbeiterberechtigungen können „ein Angebot über diesem Wert braucht vor dem Versand eine Führungskraft“ nicht ausdrücken; dieser Status ist der Ort, an dem diese Regel lebt.

Angebot gesendet. Das Angebot ist draußen. Es ist eine nummerierte Version, und diese Version ist jetzt gesperrt: Das Dokument, das der Käufer erhalten hat, ist ein kaufmännischer Beleg, und das Prüfprotokoll muss sagen können, was darin stand. Eine Änderung ist eine neue Version, nie eine Bearbeitung. Der Käufer kann von hier aus annehmen, teilweise annehmen, kontern, ablehnen oder es an die eigenen Freigebenden weiterleiten.

Wartet auf Käuferfreigabe. Die Organisation des Käufers hat ihre eigene Zeichnung – eine Führungskraft, jemand aus der Finanzabteilung. Shopifys „zur Genehmigung einreichen“ ist nicht das: Es bittet den Händler, die Bestellung des Käufers zu genehmigen, nicht die Führungskraft des Käufers, das Angebot des Verkäufers freizugeben. Ist die Kette durch, kehrt das Angebot mit den Entscheidungen der Kette in der Akte zu „Angebot gesendet“ zurück.

Gegenangebot. Der Käufer hat mit anderen Zahlen geantwortet. Das Gegenangebot ist selbst eine Version, verfasst vom Käufer, mit dem angefragten Preis je Position, und wenn der Händler es öffnet, geht das Angebot zurück in die Prüfung. Das nächste Angebot ist Version n+1. Ein Bestellentwurf kann diesen Status überhaupt nicht darstellen: Die einzigen Handlungen des Käufers an einem Entwurf sind bezahlen oder warten.

Teilweise angenommen und vollständig angenommen. Der Käufer hat alle Positionen genommen oder eine echte Teilmenge. Nicht genommene Positionen sind weiterhin offen – sie können in einer späteren Runde angenommen oder neu angeboten werden –, und die Preise der angenommenen Positionen sind jetzt versiegelt; nichts nach diesem Punkt bearbeitet einen Preis. Ab dem Tarif Professional entscheidet der Käufer je Position (wie Teilannahme funktioniert); in jedem Tarif gibt es die Annahme des ganzen Angebots.

Teilweise umgewandelt, vollständig umgewandelt, Rechnung gesendet, Bestellung abgeschlossen. Jetzt existiert der Bestellentwurf. Ein Bestellentwurf bringt das Angebot nach „teilweise umgewandelt“, weil eine angenommene Teilmenge zu einem Bestellentwurf werden kann, während der Rest nachverhandelt wird; „vollständig umgewandelt“, wenn jede angenommene Position einen Bestellentwurf hat; „Rechnung gesendet“, wenn die Rechnung jedes Entwurfs raus ist; „Bestellung abgeschlossen“, wenn Shopifys Webhook orders/create meldet, dass die Bestellung existiert. Diese Status spiegeln Shopifys drei plus die Bestellung, und sie werden von Shopifys Ereignissen getrieben, nicht von den Annahmen der Angebotsebene.

Abgelehnt, abgelaufen, Bestellung storniert, Bestellung erstattet, geschlossen. Die Enden. Sie sind getrennt, weil sie unterschiedlich berichtet werden – ein abgelehntes Angebot ist ein Preissignal, ein abgelaufenes ein Signal zum Nachfassen, eine erstattete Bestellung Sache der Buchhaltung – und weil „geschlossen“ das ausdrückliche Archivieren jedes der anderen durch eine Person ist.

„Zur Genehmigung einreichen“ ist die Prüfung des Händlers, nicht die Verhandlung des Käufers

Die eine Stelle, an der Shopifys natives B2B einen Status zwischen „der Käufer will das“ und „bezahlt“ setzt, ist die Standorteinstellung „Alle Bestellungen als Entwürfe zur Prüfung einreichen“. Sie verdient eine klare Beschreibung, weil sie oft für einen Angebots-Workflow gehalten wird.

Ist die Einstellung aktiv, kommt jede Bestellung dieses Standorts als Entwurf an: Der Käufer baut einen Warenkorb zu Katalogpreisen, sieht einen Hinweis, dass die Zahlung bei Bestätigung der Bestellung fällig wird, und klickt Zur Genehmigung einreichen. Der Entwurf erscheint mit gesperrten Preisen. Der Händler prüft ihn, darf Produkte und Mengen ändern, darf Zahlungsziele setzen, und legt entweder die Bestellung an oder sendet die Rechnung. Einschalten lässt sich das je Standort, je Unternehmen, in Masse oder über eine Shopify-Flow-Aktion beim Anlegen eines Standorts.

Was das abbildet, ist ein Halt: die Gelegenheit des Händlers, eine Bestellung zu prüfen, bevor sie bestätigt wird. Der Käufer schlägt zum Preis nichts vor; der Preis ist der des Katalogs. Die Änderungen des Händlers werden am Entwurf gemacht, nicht zur Zustimmung zurückgereicht. Es gibt keine Version, kein Gegenangebot, keinen Annahmeschritt – die nächste Handlung des Käufers ist bezahlen. Für einen Händler, dessen Geschäfte „Bestellung prüfen, dann Rechnung stellen“ lauten, ist das das richtige Werkzeug, und eine Angebotsebene wäre Ballast; wann Sie keine Angebots-App verwenden sollten führt diesen Fall unter anderen auf. In dem Moment, in dem ein Geschäft einen zweiten Preis enthält, reicht der Halt nicht mehr.

Wie die Übergänge durchgesetzt werden

Eine Liste von Status ist kein Zustandsautomat, solange die Übergänge dazwischen nicht aufgezählt sind und alles andere verweigert wird. Das ist das technische Detail, das eine Angebotsebene von einer Statusspalte unterscheidet, und hier lohnt es sich, QuotWays Umsetzung als Muster zu beschreiben.

Jeder erlaubte Zug ist eine Zeile in einer Tabelle: der Status, den er verlässt, der Status, den er betritt, welche Akteure ihn ausführen dürfen – Käufer, Händler oder System – und das Ereignis, das er schreibt. „Angebot gesendet → Gegenangebot“ ist dem Käufer erlaubt und schreibt ein Ereignis Gegenangebot. „Gegenangebot → in Prüfung“ ist dem Händler erlaubt und schreibt ein Ereignis geprüft. „Vollständig angenommen → teilweise umgewandelt“ ist Händler oder System erlaubt, weil eine Umwandlung aus einer Warteschlange ohne angemeldete Person laufen kann, und schreibt ein Ereignis Umwandlungsgruppe angelegt. Ein Übergang, der nicht in der Tabelle steht, wirft einen Fehler, und weil Statuswechsel und Ereignis in einer einzigen Datenbanktransaktion geschrieben werden, rollt der Fehler beides zurück: Das Angebot kann nicht in einem Status zurückbleiben, den seine Historie nicht erklärt.

Zwei Regeln in der Tabelle sind Platzhalter, und genau die vergisst eine Eigenentwicklung am häufigsten. Jeder Nicht-Endzustand kann nach abgelaufen wechseln, wenn das Gültigkeitsdatum verstreicht – eine Regel, auf jeden Status angewendet, ausgeführt von einem täglichen Lauf, sodass ein Angebot dem Ablauf nicht entkommt, nur weil es in einem ungewöhnlichen Status steckt. Und jeder Endzustand kann nach geschlossen wechseln, dem Archiv des Bedieners. Fünf Status sind Endzustände: abgelehnt, abgelaufen, Bestellung storniert, Bestellung erstattet, geschlossen. Bestellung abgeschlossen gehört bewusst nicht dazu, weil Shopifys Webhook orders/updated noch eine Stornierung oder eine Erstattung melden kann und das Angebot der Bestellung dorthin folgen können muss.

Die Umwandlungsstatus sind die andere Stelle, an der das Muster zählt. Das Angebot entscheidet nicht, dass es „umgewandelt“ ist, wenn es draftOrderCreate aufruft; es speichert die ID des Bestellentwurfs und wartet. Es wechselt zu „Bestellung abgeschlossen“, wenn orders/create eintrifft – auch in dem Fall, dass der Käufer über die Rechnungs-URL bezahlt, bevor der Händler die Rechnung ausdrücklich gesendet hat, was der Automat als direkten Übergang aus „vollständig umgewandelt“ zulässt. Ein Aufbau, der seinen eigenen Status beim Erfolg des API-Aufrufs weiterschaltet statt bei Shopifys Webhook, wird eines Tages „Bestellung abgeschlossen“ für einen abgebrochenen Checkout anzeigen.

Dieselbe Tabelle ist es, die das Prüfprotokoll ein Jahr später Fragen beantworten lässt. Weil jeder Übergang seinen Akteur benennt und sein Ereignis schreibt, sind „wer hat diesen Preis freigegeben“, „hat der Käufer Version 2 je gesehen“ und „warum ist dieses Angebot abgelaufen“ Nachschlagevorgänge, keine Ermittlungen.

Wo der Bestellentwurf hingehört

Auf seine Aufgabe beschränkt, ist der Bestellentwurf der beste Teil des Entwurfs, denn Shopify übernimmt das Einziehen. Das Muster lautet: einmal anlegen, bei der Annahme, mit allem darauf, was die Verhandlung geklärt hat.

Der verhandelte Stückpreis kommt auf jede Variantenposition als priceOverride in der Präsentationswährung, sodass die Bestellung der angenommenen Version auf den Cent entspricht; freie Positionen tragen ihren eigenen Preis. Die purchasingEntity – Unternehmen, Standort, Kontakt – macht daraus einen B2B-Entwurf, sodass Steuerbefreiung und Checkout-Einstellungen des Standorts greifen. Die Vorlage für Zahlungsziele, auf die sich das Geschäft geeinigt hat, wird am Entwurf gesetzt, und wo das Geschäft eine Anzahlung enthielt – auf Shopify-Plus-Shops, ab QuotWays Tarif Professional, 1–99 Prozent –, reist sie ebenfalls am Entwurf mit, sodass der Checkout die Anzahlung einzieht und Shopify den Rest terminiert. Bestellnummer und Notiz des Käufers gehen in die Felder des Entwurfs. Vor dem Anlegen zeigt draftOrderCalculate die Summen in der Vorschau, sodass Änderungen bei Steuer, Versand und Bestand seit dem Angebot erkannt und angezeigt werden, statt auf der Rechnung aufzufallen; der Architektur-Beitrag behandelt die Preisübergabe im Detail, und die Funktionsseite zur Umwandlung zeigt sie aus Händlersicht.

Eine Teilannahme wird zu einem Bestellentwurf nur für die angenommenen Positionen; die noch offenen bleiben für die nächste Runde am Angebot, und eine spätere Annahme wird zu einem zweiten Bestellentwurf. Deshalb hat das Angebot einen Status teilweise umgewandelt, und deshalb ist eine Umwandlung je angenommener Menge idempotent – der Neuversuch eines fehlgeschlagenen Anlegens darf nicht zwei Entwürfe für dieselben Positionen erzeugen.

Von hier an läuft Shopifys Automat allein. draftOrderInvoiceSend bringt den Entwurf nach „Rechnung gesendet“ und mailt den Checkout-Link; der Käufer zahlt, oder zahlt später gemäß den Zahlungszielen aus seinem Kundenkonto; der Entwurf wird abgeschlossen; die Bestellung existiert mit einem Zahlungsstatus ausstehend, teilweise bezahlt oder bezahlt. Die Angebotsebene hört zu und spiegelt. Sie bearbeitet den Entwurf nach dem Senden nicht – die Verhandlung ist vorbei, und eine Bearbeitung würde einen laufenden Checkout abkoppeln –, und sie behandelt den Entwurf nie als den Ort, an dem ein Preis wieder aufgemacht wird. Muss sich der Preis nach der Annahme ändern, ist das ein neues Angebot am Angebotsobjekt, eine neue Annahme und ein neuer Bestellentwurf; die Mechanik auf Händlerseite steht in Shopify-Bestellentwürfe für B2B, und die Eigenheiten des Bestellentwurfs selbst – standardmäßig kein reservierter Bestand, die Grenze von 500 Positionen, die Löschung nach einem Jahr – im Beitrag zu den Grenzen.

Fünf Anzeichen, dass ein Bestellentwurf als Angebot benutzt wird

Das ist, was eine Agentur bei einem Rettungsprojekt vorfindet, aufgelistet, damit man es früh erkennt.

1. Die Seite Entwürfe ist die Pipeline. Dutzende offene Entwürfe, manche monatealt, mit Notizen wie „v3 – warten auf Käufer“. Die Löschung nach einem Jahr wird die ältesten irgendwann entfernen, und es gibt keinen Bericht darüber, in welcher Phase jeder steht, weil das Objekt keine Phase hat.
2. Preise werden an Ort und Stelle geändert. Ein Entwurf, viermal bearbeitet für vier Runden Feilschen, ohne Aufzeichnung der Runden eins bis drei außer den Einträgen „bearbeitet“ in der Zeitleiste. Bestreitet der Käufer die Endsumme, kann niemand zeigen, was vorher angeboten wurde.
3. Rechnungen werden als Angebote gesendet. Die Rechnung ist der Vorschlag, und „der Käufer hat nicht bezahlt“ ist das einzige Signal, dass er nicht angenommen hat. Zahlungsziele machen das schlimmer, weil eine unbezahlte Rechnung mit 30 Tagen Ziel einen Monat lang nicht von einer abgelehnten zu unterscheiden ist.
4. Das Gegenangebot des Käufers kommt per E-Mail. Weil der Entwurf keinen vom Käufer verfassten Status hat, läuft die Verhandlung in einem Postfach, und der Entwurf wird hinterher von Hand nachgezogen – in dem Moment, in dem beides auseinanderläuft, ist die Bestellung falsch.
5. Die Freigabe ist eine Slack-Nachricht. Ein Vertriebler fragt eine Führungskraft, ob ein Rabatt in Ordnung ist, bekommt einen Daumen hoch und bearbeitet den Entwurf. Nichts verbindet die Freigabe mit dem Preis, den sie freigegeben hat.

Jedes davon ist ein Status, den der Bestellentwurf nicht halten kann und der deshalb irgendwo informell gehalten wird. Die Lösung ist kein größerer Bestellentwurf; es ist ein Angebotsobjekt davor.

Häufige Fragen

Was ist der Unterschied zwischen einem Bestellentwurf und einem Angebot auf Shopify?

Ein Bestellentwurf ist Shopifys Datensatz einer Bestellung, die auf Zahlung wartet: Er hat drei Status – offen, Rechnung gesendet, abgeschlossen –, und seine Positionen tragen je einen Preis. Ein Angebot ist der Datensatz darüber, wie dieser Preis zustande kam: die Anfrage des Käufers, die nummerierten Angebote des Verkäufers, Gegenangebote, Freigaben und die Annahme. Shopify hat kein Angebotsobjekt, also hält eine Angebotsebene diese Status und legt den Bestellentwurf an, sobald der Preis vereinbart ist.

Warum nicht einfach Bestellentwürfe als Angebote verwenden?

Weil der Bestellentwurf für nichts vor der Einigung ein Feld hat. Er kann keinen angefragten Preis, kein Gegenangebot, keine gesperrte Version, keine Freigabeentscheidung und keine Annahme je Position halten, seine Positionen werden bei jeder Bearbeitung komplett ersetzt, und seine Zeitleiste ist Text statt wieder öffenbarer Versionen. Ein Geschäft mit einer Runde – Käufer reicht ein, Händler prüft, Käufer zahlt – passt hinein; ein Geschäft mit einem zweiten Preis nicht.

Welche Status hat ein Shopify-Bestellentwurf?

Drei, aus dem Enum DraftOrderStatus in API 2026-07: OPEN (nicht bezahlt, keine Rechnung gesendet), INVOICE_SENT (eine Rechnung wurde an den Kunden gemailt) und COMPLETED (bezahlt). Nach dem Abschluss hat die daraus entstandene Bestellung ihren eigenen Zahlungsstatus – ausstehend, teilweise bezahlt, bezahlt, erstattet und so weiter.

Ist „Zur Genehmigung einreichen“ ein Angebots-Workflow?

Nein. Es ist eine Einstellung am Unternehmensstandort, die jede Bestellung dieses Standorts in einen Entwurf verwandelt, den der Händler vor der Bestätigung prüft. Der Käufer reicht einen Warenkorb zu Katalogpreisen ein; der Händler darf ihn ändern und stellt dann die Rechnung oder legt die Bestellung an. Es gibt keinen Preisvorschlag des Käufers, keine Version und keinen Annahmeschritt. Es bildet einen Halt an der Bestellung ab, was für Händler, die Bestellungen nur vor der Rechnung prüfen müssen, genau richtig ist.

Kann ein Bestellentwurf nach dem Senden der Rechnung bearbeitet werden?

Ja. draftOrderUpdate kennt keine Einschränkung für Entwürfe mit gesendeter Rechnung, und jede Bearbeitung setzt die Löschfrist von einem Jahr zurück. Shopify warnt allerdings, dass ein Update nach begonnenem Checkout diesen Checkout abkoppelt – die Bestellung kann dann entstehen, während der Entwurf offen bleibt. Genau diese Veränderbarkeit macht den Bestellentwurf zum falschen Beleg für ein Angebot: Ein gesendetes Angebot darf nicht an Ort und Stelle bearbeitbar sein.

Wann sollte der Bestellentwurf angelegt werden?

Bei der Annahme, einmal, mit den verhandelten Preisen als priceOverride auf den Positionen, der Purchasing Entity, den Zahlungszielen, einer etwaigen Anzahlung und der Bestellnummer bereits darauf. Ihn früher anzulegen – beim Angebot – stellt ein veränderbares, löschbares Objekt mitten in die Verhandlung; ihn später anzulegen lässt den Käufer ohne etwas zurück, gegen das er zahlen kann. Eine Teilannahme legt einen Entwurf für die angenommenen Positionen an und lässt den Rest am Angebot offen.

Laufen Angebote ab, und laufen Bestellentwürfe ab?

Unterschiedlich. Der Ablauf eines Angebots ist ein kaufmännisches Datum, das der Verkäufer setzt – danach sind Annahme und Gegenangebot zurückgezogen, und der Käufer braucht ein neues Angebot. Die einzige Uhr eines Bestellentwurfs ist Aufräumarbeit: Entwürfe, die am oder nach dem 1. April 2025 angelegt wurden, werden nach einem Jahr ohne Bearbeitung gelöscht. Keines von beiden sollte die Aufgabe des anderen übernehmen.

Quellen

Shopify-Seiten, alle gelesen am 21. September 2026 bei API-Version 2026-07:

• DraftOrder-Objekt, Enum DraftOrderStatus und BasicEvent
• draftOrderUpdate und draftOrderComplete
• Bestellentwürfe für B2B-Apps
• B2B-Bestellungen mit Bestellentwürfen anlegen und Checkout-Einstellungen im B2B verwalten
• Zahlungsziele im B2B einrichten, PaymentTerms-Objekt und OrderDisplayFinancialStatus
• Rechnungen für Bestellentwürfe senden und Bestellentwürfe und Rechnungen
• Flow-Aktion: Checkout eines Unternehmensstandorts auf Entwurf umstellen
• Changelog, 8. Juli 2024: Rechnungen zu Bestellentwürfen mit Zahlungszielen senden

QuotWays Zustandsautomat, Übergangsregeln und Umwandlungsverhalten sind aus seinem Quellcode beschrieben; die Darstellung für Händler steht in Angebot erstellen und senden, wie die Durchsetzung von Freigaben funktioniert und Angebot in einen Bestellentwurf umwandeln. Die Tarifunterschiede stehen auf der Preisseite.