見積とShopifyの注文が食い違うとき：変換後にずれるもの

Shopifyで見積が変換されると、同じ取引を4つのレコードが表すことになります。承諾された見積、下書き注文、注文、そして基幹システム（ERP）やCRMが持つものです。この4つが食い違うパターンは、文書化されている少数のものに限られます。変換後に編集された下書き、注文ができた後も開いたままの下書き、削除された、あるいは1年後に自動削除された下書き、編集・キャンセル・返金された注文、バイヤーが依頼した変更、コネクタに上書きされたタグの一覧です。どのずれも特定の2つの項目を比べれば検出でき、各項目の持ち主は1つだけです。突合（reconciliation）とは、その持ち主を決め、項目の組を定期的に確認することです。

このページは、下書きが存在した後にずれるものの一覧です。各ケースの検出方法と修復方法、そして変換以降どの項目を誰が持つかを扱います。下書きをちょうど1件だけ作る方法は承諾された見積1件を、Shopifyの下書き注文ちょうど1件にする方法で、変換の時点で壊れるものは17の失敗パターンで、最初から誤っていた価格の診断は見積が誤った価格で変換される理由で扱っています。ここでいう「突合」は見積と注文のデータのことで、入金（ペイアウト）や銀行口座の照合のことではありません。

以下のShopifyに関する記述はすべて、2026年10月9日にShopify自身のページでAPIバージョン2026-10を対象に確認しました。出典は末尾にあります。

4つの比較

何がずれ、どう捕まえるか

起きる時期ごとにまとめています。「正本」は、変換以降に優先されるレコードです。

注文ができる前

#	ずれるもの	Shopify側の原因	検出	修復	正本
1	下書きの明細や合計が、承諾された内容と食い違う	変換後にスタッフが下書きを編集する。tags を更新すると一覧全体が上書きされる	draft_orders/update のペイロードの合計を、変換時に保存した合計と比べる。DraftOrder.tags を、自分が書いたタグと比べる	取引条件の変更は新しい提案かカウンターオファーと新しい下書きで行い、古い下書きは削除する。物流上の変更は記録する	支払いまでは承諾されたバージョン
2	注文があるのに、下書きが開いたまま	チェックアウトの途中で更新が行われ、チェックアウトとの紐づけが外れた。注文は作成され、「注文が作成された後も下書きは開いたままになります」	注文に自分の変換属性があるのに、DraftOrder.order がnull、またはステータスが COMPLETED でない	属性で注文を紐づける。古い下書きは人が削除する	注文
3	見積が、もう存在しない下書きを指している	スタッフが削除した	draft_orders/delete。最後の備えとして、draftOrder(id) が何も返さないこと	下書きを失われたものとして記録し、属性を持つ注文がないことを確かめてから、作り直すか閉じる	Shopify
4	同じことが1年後に起きる	2025年4月1日以降に作成された下書きは、編集がないまま1年経つと削除される	draftOrder(id) が何も返さない。この自動削除で削除のWebhookが送られるかどうかは、Shopifyが文書化していない	1年が来るずっと前に、取引を失注とするか再見積するかを決める	Shopify
5	請求書を送ったが、支払われていない	注文ができるのは、下書きが支払われるか完了したときだけ	draftOrders(query: "tag:… status:invoice_sent") と経過日数	催促する、延長する、または下書きを削除して見積を閉じる。後者は必ず両方同時に	下書きのステータス
6	見積は期限切れなのに、下書きはまだ支払える	下書きには自動削除以外の期限がない	見積が期限切れで、DraftOrder.status が OPEN または INVOICE_SENT	見積の期限切れと同時に下書きを削除する。または、請求書を送った後は見積を期限切れにしない	どちらかを選ぶ。ただし1つだけ
7	見積レイヤーや基幹システムが知らない、支払い済みの注文	Webhookの配信は保証されていない	draftOrder.order が設定されているのに注文IDが保存されていない。または orders(query: "tag:… updated_at:>…") を保存済みのIDと比べる	同じWebhookハンドラーで再生する（突合ジョブ）	注文

注文ができた後

#	ずれるもの	Shopify側の原因	検出	修復	正本
8	注文の明細や合計が、承諾されたバージョンと食い違う	マーチャントや別のアプリが注文を編集する。Shopifyによれば、アプリが作成した下書きから生まれた注文は「Shopify管理画面で、また他のアプリによって編集できます」	orders/edited、Order.edited、originalTotalPriceSet と currentTotalPriceSet の比較	理由を注文に記録する。見積は書き換えない。基幹システムは注文に従う	フルフィルメントと請求は注文、合意した内容は見積
9	基幹システムや倉庫が把握していない、保留中のバイヤーの変更	2026-10から、バイヤーは未フルフィルメントの明細の削除を依頼できる	requested_order_edit/* Webhook、Order.requestedOrderEdits	保留中はフルフィルメントを止める。承認か却下かを決める。承認された依頼は注文の編集として届く	注文
10	見積は進行中の取引に見えるが、注文はキャンセル済み	キャンセルは「元に戻せません」	orders/cancelled、cancelledAt	注文ごとに記録する。見積は記録として残し、再見積は新しい見積にする	注文
11	返金や返品の後の金額	明細ごと、送料ごとの返金、そして返品	refunds/create、returns/*、currentSubtotalPriceSet	基幹システムのクレジットノートは、見積からではなく返金から作る	注文の返金
12	フルフィルメントの状態が複数の場所に複製される	倉庫や基幹システムがShopifyにフルフィルメントを書き込む	fulfillments/*、displayFulfillmentStatus	フルフィルメントを見積レイヤーに複製しない	Shopifyを通じて、倉庫または基幹システム

取引の形とキー

#	ずれるもの	原因	検出	修復	正本
13	「この見積の注文は1件だが、2件あるはず」	一部承諾や分割変換では、グループごとに下書きが1件できる。後回しにした明細は未決定のままで、辞退されたわけではない	変換済みのグループを保存済みの注文IDと比べる。各注文の小計を、承諾された明細と比べる	グループごとに突合する。未決定の明細は欠落ではない	どの明細が未決定かは見積レイヤー、何が購入されたかは注文
14	見積の合計が基幹システムの金額と合わない	下書きと注文は表示通貨で、shopMoney は換算後の金額	見積とは presentmentMoney だけを比べる	どちらの側で計上するかを意図して決める	表示通貨の金額
15	注文が見積から来たものだと分からなくなる	一覧全体の書き込みでタグが上書きされた。属性やメモが編集された	orders(query: "tag:…") を保存済みのIDと比べる。Eventsの order.tags と order.customAttributes のトリガー	見積の記録から復元する。連携はタグを一覧の書き換えで扱わず、必ず tagsAdd で追加する	キーを一度だけ書いた見積レイヤー
16	変換後にバイヤーの識別情報が変わった	連絡先の削除、所在地の削除や変更、顧客の統合	company_contacts/delete、company_locations/delete、customers/merge を保存済みのIDと比べる	支払い前なら、正しい所在地で下書きを作り直す。支払い後は、注文ではなく顧客マスタを直す	基幹システムの顧客マスタかShopify。どちらか一方
17	見積レイヤーが持つ項目をコネクタが書き換える	1つの項目に書き手が2人いる	項目単位のEventsトリガー。見積レイヤーが書いた内容との差分	コネクタを自分の項目だけに制限する	項目ごとに書き手は1人
18	連携が見積レイヤーのイベントを取りこぼした	少なくとも1回（at-least-once）で順不同の配信。エンドポイントの停止	イベントの連番の欠け。送信側が配信をあきらめたもの	まずイベントフィードから、次にAPIから再生する	見積レイヤーのイベントログ
19	突合ジョブが古い注文について「問題なし」と報告する	read_all_orders がないアプリから見えるのは、直近60日の注文だけ	ジョブの対象範囲を注文の経過日数と比べる	read_all_orders を申請するか、その期間内で突合する	-

変換後、どの項目を誰が持つか

基幹システム・CRM・PIMの連携パターンには、連携の全期間を通じた所有権の表があります。こちらの表は、下書きが存在した時点から始まります。

項目	変換後の持ち主	それ以外のシステム	理由
合意した明細、数量、単価、条件、バージョン	見積レイヤー。封印された承諾済みバージョンで、編集しない	監査のために読む	合意の記録だから。送信済みの提案はロックされている
未決定のままの明細	見積レイヤー	CRMはパイプラインとして読む	変換されておらず、失われてもいない
支払いまでの下書きの内容	見積レイヤーが一度だけ書いた。スタッフの編集は記録すべき例外	基幹システムは下書きを無視する	下書きは支払える状態にあり、変えれば取引が変わる
注文の明細、数量、合計	Shopifyの注文	基幹システムと倉庫が読む。見積レイヤーは複製しない	編集、返金、返品は注文の上で起きる
支払いと返金	Shopify	基幹システムは返金から計上し、見積レイヤーは最終状態だけを記録する	お金は注文の上で動く
フルフィルメント	Shopifyに書き込む倉庫または基幹システム	見積レイヤーは何もしない	書き手は1人
請求書、元帳、クレジットノート	基幹システムまたは会計システム	-	Shopifyは元帳ではない
紐づけのキー（見積のタグ、変換属性、メモの行）	見積レイヤーが一度だけ書く	ほかのシステムは tagsAdd で追記する	tags の更新は一覧を上書きする
会社、所在地、連絡先	基幹システムの顧客マスタかShopify。どちらか一方	見積レイヤーは読む	書き手は1人
変換後の見積のステータス	Shopifyの注文イベントから導出する見積レイヤー	連携は読む	導出するもので、逆方向にはしない

ここから導かれる規則は、注文の変更を見積に書き戻さないことです。見積は合意した内容で、注文はフルフィルメントと支払いが行われているものです。両者が違うときは、その理由を注文に記録します。

Eventsか、Webhookか

ShopifyのEventsはAPI 2026-10で一般提供となり、従来のWebhook（classic webhooks）の後継と位置づけられています。従来のWebhookも引き続き動作します。Eventsには注文、返金、返品、フルフィルメントオーダー、会社、顧客のトピックがあり、個々の項目に対するトリガーを持ちます。order.tags、order.customAttributes、order.lineItems.quantity などがあり、表の8、15、17行目に向いています。ただし下書き注文のトピックはないため、1〜6行目には引き続き従来の draft_orders/* Webhookが必要です。ShopifyはEventsの配信保証を文書化していないので、どちらを使う場合も、下の突合ジョブは残してください。

そのまま使える突合ジョブ

保存済みのIDを対象に、注文にアクセスできる期間内で、定期的に実行します。

1. 自分が作成し、まだ支払いを確認していない下書き。 draftOrders(query: "tag:<your-tag> updated_at:>…")。それぞれの status と order を見ます。注文があるのにIDが保存されていなければ7行目、下書きがなければ3行目か4行目、古い INVOICE_SENT の下書きは5行目か6行目です。
2. 自分のキーを持つ注文。 orders(query: "tag:<your-tag> updated_at:>…")。originalTotalPriceSet と currentTotalPriceSet を比べ（8行目）、cancelledAt と支払いステータス（10、11行目）、requestedOrderEdits（9行目）、そしてタグと変換属性がまだ残っていること（15行目）を確認します。
3. 外部システム。 注文ごとに、基幹システムの金額を presentmentMoney と（14行目）、注文の件数を変換済みのグループの数と（13行目）比べます。
4. 対象範囲。 read_all_orders がなければ、見えるのは直近60日の注文だけです（19行目）。

作成側、つまり結果が不明な変換を見つける突合ジョブは、冪等な変換の記事にあります。

QuotWayの動作

一実装として、現在の動作を説明します。

• 何で照合するか。 QuotWayが作成するすべての下書きには、quotway と quotway-<quote reference> のタグ、見積参照とバージョンを記したマーチャント専用のメモ、そして注文をその変換グループへ紐づける変換属性が1つ付きます。QuotWayは作成した後の下書きを編集、完了、削除することはなく、注文を編集することもありません。
• 何を記録するか。 変換済みの下書きの合計が変わると、変更前と変更後の金額とともに見積の履歴に記録します。見積が注文完了になった後は、その注文がキャンセルされたとき、または全額返金されたときに、見積に記録します。一部返金、返品、注文の編集、フルフィルメントはShopifyの注文の側に残るので、それらは注文で確認してください（下書き注文への変換）。
• 分割変換と一部変換。 承諾された各グループが、それぞれ独自の下書きと注文になります。バイヤーが後回しにした明細は見積の上で未決定のまま残り、後から変換できます（一部承諾と分割変換）。
• 取りこぼした注文のWebhook。 突合ジョブが、請求書を送ってから7日経っても注文のない見積を確認し、Shopifyに注文があれば同じハンドラーで再生します。
• 連携向け。 Enterpriseプランでは（14日間の無料トライアル中も含みます）、APIの見積オブジェクトに見積のShopify下書き注文IDと注文IDが含まれ、30日分のイベントフィードが取りこぼしたWebhookを回復する手段になります（イベントフィード）。プランは料金ページに、変換については見積を注文に変換するにあります。

よくある質問

顧客が支払ったのに、Shopifyの下書き注文が開いたままなのはなぜですか？

チェックアウトの途中で下書きが更新され、チェックアウトとの紐づけが外れたためです。注文は作成されますが、「注文が作成された後も下書きは開いたままになります」。DraftOrder.order を確認し、自分のキーで注文を紐づけ、古い下書きを削除してください。

下書き注文が支払われたときのWebhookはありますか？

下書き注文の「支払い済み」というトピックはありません。支払いによって注文が作成されるので、orders/create を購読し、自分の属性やタグで下書きと照合します。下書きの status は COMPLETED になり、order 項目が設定されます。下書きへの変更は draft_orders/update で分かります。2026-10の時点で、ShopifyのEventsに下書き注文のトピックはありません。

注文が編集されたら、見積も変えるべきですか？

いいえ。見積は合意した内容の記録で、注文はフルフィルメントと支払いの対象です。編集の理由は注文に記録し、基幹システムは注文に従わせます。

基幹システムのために注文の編集を検出するには？

orders/edited Webhook、注文の edited 項目、そして originalTotalPriceSet と currentTotalPriceSet の差です。Eventsでは、order.lineItems.quantity のトリガーが数量について同じ役割を果たします。

バイヤーが依頼する注文の編集とは何ですか？

API 2026-10から、バイヤーは注文から未フルフィルメントの明細の削除を依頼できます。依頼は requested_order_edit/* Webhookとして届き、Order.requestedOrderEdits で確認できます。保留中はフルフィルメントを止めてください。承認された依頼は、通常の注文の編集になります。

未払いの下書き注文に期限はありますか？

2025年4月1日以降に作成された下書きは、編集がないまま1年経つと削除されます。それ以外に下書きを失効させるものはないので、それより早く見積が期限切れになっても、下書きを削除しない限り、下書きは支払える状態のまま残ります。

突合ではShopify EventsがWebhookに取って代わりますか？

Eventsは従来のWebhookの後継で、従来のWebhookも引き続き動作します。ただし下書き注文のトピックがないため、下書きには引き続き draft_orders/* が必要です。ShopifyはEventsの配信保証を文書化していないので、どちらにしても突合ジョブは残してください。

基幹システムの合計が見積と合わないのはなぜですか？

見積、下書き、注文はバイヤーの表示通貨で、shopMoney は換算後の金額です。返金や注文の編集は、注文の現在の合計を変えます。見積は、注文の表示通貨の金額とその元の合計と比べてください。

出典

Shopifyのページ。2026年10月9日にAPIバージョン2026-10で確認しました。

• draftOrderUpdate：更新は進行中のチェックアウトとの紐づけを外し、下書きは開いたままになる
• DraftOrderとDraftOrderInput：ステータス、order、タグ
• 下書き注文：2025年4月1日以降に作成された下書きは編集がないまま1年経つと削除される。支払いによって注文が作成される
• Order：元の合計と現在の合計、edited、cancelledAt、requestedOrderEdits
• 既存の注文の編集：アプリが作成した注文は管理画面と他のアプリから編集できる。注文の60日の期間
• orderCancel：キャンセルは元に戻せない
• tagsAdd：上書きせずにタグを追加する
• WebhookのトピックとHTTPSでのWebhook配信：トピック。配信は保証されない
• Eventsの一般提供開始とEventsとWebhook：トピック、項目単位のトリガー、従来のWebhookの継続
• リリースノート 2026-10：バイヤーが依頼する注文の編集

QuotWayの動作は、2026年10月9日に確認した公開ドキュメントとアプリのソースに基づいて説明しています。