はじめに：月末に電卓を叩くたびに、数字が合わない
楽天市場とAmazonの両方に出店している事業者から、よく聞く悩みがあります。「月次の売上を集計すると、楽天の管理画面で見た数字と、後日確定する数字が違う」「Amazonのレポートを日をおいて2回出力したら、同じ期間なのに合計が変わっていた」というものです。
こうしたとき、多くの担当者は自分の集計方法を疑います。CSVの範囲指定を間違えたのではないか、フィルタのかけ方がおかしいのではないか、と一つずつ確認し直す。しかし何度見直しても原因が見つからず、時間だけが過ぎていく、というケースが少なくありません。
結論から言うと、この食い違いは集計ミスとは限りません。楽天とAmazonでは、「注文が入った時点の数字」と「入金として確定した数字」を、そもそも別のデータとして扱う設計になっている場合があります。この記事では、その構造がなぜ生まれるのか、そして経営者としてどこまで数字の一致を追いかけるべきかを整理します。
「注文の数字」と「入金の数字」は、そもそも別の集計です
まず押さえておきたいのは、EC事業者が普段見ている売上の数字には、性質の異なる2種類があるということです。
一つは「注文が確定した時点の数字」です。お客様が購入ボタンを押し、決済が通った瞬間に記録される数字で、日々の売上感覚に最も近いものです。もう一つは「モールから実際に入金される金額が確定した時点の数字」です。ここには手数料の精算やキャンセル・返品の反映、モール側の内部処理のタイミングが絡んできます。
この2つは、性質が違う以上、同じ期間で切り取っても一致しないことがあります。これはどちらかが「間違っている」わけではなく、「何を数えているか」が違うために起きる差です。日々の受注状況を見たいのか、実際に口座に入ってくる金額を見たいのかによって、参照すべき数字自体が変わってきます。
Amazonの場合：注文データと財務データは別のシステムです
この構造がはっきり分かるのが、Amazonが外部システム連携用に公開しているSP-API（Selling Partner API）の仕様です。Amazonの公式ドキュメントでは、注文情報を取得する「Orders API」と、入金確定額などの財務イベントを取得する「Finances API」が、明確に別のエンドポイントとして用意されています。
そして公式のオペレーションリファレンスには、直近48時間以内の注文が、財務イベント側のデータにまだ含まれないことがあると明記されています（出典: Amazon SP-API公式ドキュメント listTransactions, https://developer-docs.amazon.com/sp-api/reference/listtransactions）。つまりAmazonでは、「注文の受付」と「お金の確定」を別の処理系として設計していることが読み取れます。
これは裏を返せば、月末や月初にAmazonのレポートを2回出力すると、直近の注文が財務データにまだ乗っていない、あるいは乗るタイミングが担当者の想定とずれる、という状況が起こり得るということです。担当者の集計作業に問題がなくても、参照先のデータそのものが「まだ確定していない」状態を含んでいれば、数字は動きます。
楽天の場合も、確定までにタイムラグがあるとされています
楽天市場についても、受注時点の数字と、手数料が精算されて最終的な入金額が確定するタイミングとの間に、実務上のタイムラグがあるとされています。この点は公式の一次情報で具体的な期間まで確認できているわけではないため、この記事では「何日後」「何ヶ月後」といった断定はしません。ただし、注文確定と入金確定が別の工程として動いている点は、Amazonと同じ構造だと理解しておくと、数字が合わない理由を探すときの見当がつけやすくなります。
大切なのは、「楽天とAmazon、どちらの数字が正しいか」という二択で考えないことです。どちらも、それぞれの時点における正しい数字を返しています。ただし、切り取っている時点が違うだけです。
では、経営判断としてどちらの数字を使えばよいのか
ここまでの構造を踏まえると、実務上の対応は次のように分けられます。
日々の受注状況や、キャンペーンの反応を見たいのであれば、注文時点の数字（受注ベース）で十分です。多少の後日修正があっても、大きなトレンドを掴むという目的には支障がありません。一方で、月次決算や資金繰りの見通しに使うのであれば、確定入金額（入金ベース）を基準にする必要があります。ここで受注ベースの数字を使ってしまうと、実際に手元に入ってくる金額との差が積み上がり、資金繰りの読みが甘くなるおそれがあります。
つまり「どちらが正しいか」ではなく「この数字を何に使うのか」を先に決める、という順番が重要です。目的を決めずに両方の数字を同じ表に並べてしまうと、差分そのものが「異常値」に見えてしまい、無駄な調査に時間を使うことになります。
前提条件：突き合わせを始める前に整理しておくべきこと
複数モールの数字を本気で突き合わせようとすると、まず「どのタイミングの数字を、どのタイミングの数字と比べているのか」を明確にする必要があります。楽天の受注データとAmazonの入金確定データを並べて「合わない」と言っても、それは前提が違う2つの数字を比べているだけです。
具体的には、次の3点を先に整理してから統合作業に入ることをおすすめします。
- 各モールの「締め日」（その月の売上として計上される区切りの日）がいつか
- 各モールで「注文確定」と「入金確定」がそれぞれいつ発生するか
- 自社が最終的に見たいのは「受注ベース」か「入金ベース」か、どちらか一方に統一するか、両方を別の指標として持つか
この整理をせずにAPI連携やデータ集約の仕組みを組んでしまうと、見た目は自動化されていても、中身は精度の低い比較を自動で繰り返すだけの仕組みになってしまいます。複数モールのデータを一つの基盤に集約する具体的な手順については、楽天・Amazon・自社ECの売上データをBigQueryに集約して一元管理する方法で扱っていますので、前提の整理が済んだ段階で参考にしてください。
やらなくてよい場合
ここまで構造の話をしてきましたが、すべての事業者がこの食い違いを厳密に追いかける必要があるわけではありません。
月次の大まかな傾向、たとえば「先月より楽天の売上が伸びているか」「Amazonの構成比が増えているか」を把握できれば十分で、日次レベルでの完全一致を求めていないのであれば、この問題を突き詰めて調査する優先度は高くありません。多少のタイムラグがあっても、多くは翌月までに収束していきます。
追いかける価値があるのは、月次決算の締め作業で毎回手作業の照合に時間を取られている場合や、資金繰りの見通しに使う数字がモールごとにバラバラで、経営判断の材料として使いにくいと感じている場合です。逆に言えば、そうした実害が出ていないうちは、無理に仕組みを作る必要はありません。
まとめ
楽天とAmazonの売上の数字が合わないという現象は、集計ミスではなく、モール側が「注文時点の数字」と「入金確定額」を別のデータとして設計していることに起因する場合があります。Amazonについては、Orders APIとFinances APIが別エンドポイントであり、直近の注文が財務データにすぐ反映されないことがあると公式ドキュメントに明記されています。楽天についても、確定までに実務上のタイムラグがあるとされています。
大事なのは「どちらが正しいか」を探すことではなく、「この数字を何の判断に使うのか」を先に決め、それに応じた数字を参照することです。前提を整理しないまま複数モールのデータを機械的に突き合わせても、精度の低い比較が自動化されるだけです。
もし自社の数字の食い違いが、このような構造的な理由なのか、それとも別の原因（集計範囲の設定ミスなど）なのかを切り分けたい場合は、BigQueryによるデータ統合の相談やお問い合わせから、現状の集計方法を含めて相談していただくことも可能です。