返品・返金レポートの作成方法：完全ガイド
ある店舗が12% ofの返品率を報告したとします。しかし、そのうちの3分の1は、物理的には何も戻ってきていません。
これはデータの誤りではありません。返金が「返品」として記録されたときに起こる現象であり、まさにほとんどのプラットフォームがそのようにカウントしているからです。
この違いは、運用の担当者があなたの数字をもとに倉庫のキャパシティを計画するまでは、細かすぎる話に聞こえるかもしれません。
本ガイドでは、返品・返金レポートに含めるべき内容と、なぜこの2つの言葉が異なる事象を指すのかについて解説します。さらに、月次比較を密かに狂わせる「日付の問題」と、エクスポートデータからレポートを作成する方法についても説明します。
返品・返金レポートに含めるべき内容
同じビューに含めるべき要素は5つあり、率はそのうちの1つに過ぎません。
返金額、返金された注文数、対象期間、除算に使用した分母、そして全額返金と一部返金の割合です。
プラットフォームで理由コードを取得している場合は、それも追加してください。率は問題の大きさを教えてくれ、理由はどの問題が発生しているかを教えてくれます。
最初は配送料と税金を除外しておきましょう。どちらも通常は個別に追跡されるため、これらを混ぜてしまうと、後で数値を照合することが不可能になります。
返品と返金は同じではない
プラットフォームのドキュメントでは、この点について非常に明確に説明されており、正確な文言を読んでみる価値があります。
WooCommerceの分析ドキュメントでは、この2つを直接区別しています。そこには、「返金（refund）とは、顧客にお金を返す取引のことである」と記載されています。
その定義のもう半分が重要な部分です。返品（returns）の指標は、「返金が全額か一部か、また商品が物理的に返品されたかどうかにかかわらず」、返金された金額を記録します。
したがって、破損した商品に対するお詫びのクレジット（返金）は、何も返送されていなくても「返品」にカウントされます。価格調整も同様です。
この一文こそが、コマース分析から取得した返品の数値を、物理的な返品予測として倉庫チームにそのまま渡してはならない理由です。
配送料と税金も除外されます。返金された配送料や税金は、返金額の数値には含まれません。代わりに、配送料と税金の数値にマイナスの値として表示されます。
日付の問題
この問題は、単一のセルではなくトレンドライン自体を変化させてしまうため、より厄介です。
WooCommerceは、返金を「（注文が確定した日付ではなく）返品が発生した日付のマイナスの数値として」記録します。
これが月次比較にどのような影響を与えるか考えてみてください。2月の注文に対する3月の返金は3月に計上され、2月の売上は修正されません。
その結果、両方の月の数値が逆の方向に少しずつ狂ってしまいます。2月は実際よりも良く見え、3月は自らが生み出していないコストを抱えることになります。
これには論理的に説明可能な2つの解決策があり、どちらを採用するかを明文化しておく必要があります。
返金日基準で報告し、レポートに「キャッシュビュー（現金ベース）」とラベルを貼る方法です。これは銀行口座やプラットフォームの数値と一致しますが、コホート分析とは決して一致しません。
または、各返金を元の注文日に再割り当てする方法です。これにより、販売期間ごとの正確な状況が把握できますが、レポート公開後に先月の数値が変動することになります。
どちらの方法も間違いではありません。間違っているのは、どちらの方法を使用したかを明記せずに公開することです。
分母の選択
返品率を算出するには除数（分母）が必要ですが、一般的に使用される3つの分母があり、それぞれ異なる数値が算出されます。
| 分母 | 率が意味すること | 最適な用途 |
|---|---|---|
| 期間内の注文数 | 返金が発生した注文の割合 | カスタマーサービスの負荷測定 |
| 出荷個数 | 戻ってきた商品の割合 | 倉庫および棚卸し管理 |
| 純売上高 | 取り消された売上の割合 | 財務およびマージン管理 |
報告する相手に合わせて選んでください。財務レビューでは金額ベースの数値が求められ、運用レビューでは個数ベースの数値が求められます。
また、その周辺の売上数値にも注意してください。これらも定義されているからです。WooCommerceでは、総売上高（gross sales）は返金、クーポン、税金、配送料を除く「価格 × 数量」として定義され、純売上高（net sales）は総売上高から返品とクーポンを差し引いたものとして定義されています。
そこでの平均注文額（AOV）は、純売上高を注文数で割ったものです。つまり、他で引用している可能性のあるAOVには、すでに返金分が含まれていることになります。
生のEコマース注文データを売上トレンドレポートに変換する方法に関するガイドは、こちらのリンクからご覧いただけます。同じエクスポートデータの売上側面について説明しています。
手動で行う方法
オプション 1：2つの合計と1つの除算
エクスポートデータをその期間の返金レコードでフィルタリングし、SUMIFSを使用して返金額を合計します。
対象となる注文数をCOUNTIFSでカウントします。1つの注文に複数の返金が含まれる可能性がある場合は、事前に注文識別子の重複を排除しておきます。
最後に1回だけ除算を行います。両方の合計値を表示させておくことで、他の人があなたの作業をチェックできるようになります。
この方法ではすぐに限界が来ます。1つの期間に対して1つの率しか得られず、どの製品や理由がそれを引き起こしたのかを把握することはできません。
オプション 2：返金1件につき1行
返金1件につき1行のテーブルを作成します。列には、注文日、返金日、経過日数、返金額、全額または一部、理由を設定します。
遅い日付から早い日付を引いて、日数の差を計算します。MicrosoftのDATEDIF関数に関するガイダンスでは、「特定のシナリオにおいて誤った結果が計算される可能性がある」と警告されています。
これで、レポートを製品別、カテゴリ別、チャネル別、理由別、または返金ラグ（タイムラグ）別などでスライス（分析）できるようになります。
ラグ（タイムラグ）の列は過小評価されがちですが、非常に重要です。購入から40日後に返金が集中している場合は耐久性に問題がある可能性があり、4日後に集中している場合はサイズや商品説明に問題がある可能性があります。
限界となるのは、データ量と結合（ジョイン）です。返金を注文明細や製品データと照合する作業は、数式だけで快適に処理できる限界を超えてしまいます。
オプション 3：定義タブの作成
どの基準日を使用するか、分母、そして配送料と税金が含まれているかどうかを記録します。
次に、除外対象を記録します。出荷されなかったキャンセル注文、テスト取引、チャージバックなど、それぞれどのように処理するかを明記する必要があります。
チャージバックは忘れられがちです。お金は出ていくものの返品は記録されないため、2つのシステム間で数値が永久に一致しなくなります。
この方法の限界は、ルールを書き留めただけでは自動的に適用されないことです。来月には、また誰かが同じフィルターを再作成することになります。
共通する限界： 3つのオプションすべてにおいて、エクスポートデータに両方の日付が含まれていることが前提となります。返金日しか含まれていない場合、そのファイルからコホートビューを復元することはできません。
手動プロセスの効率が落ちる原因
最初のレポート作成には午前中いっぱいで済みます。しかし、4回目になると、3つの要素がずれてしまうため、より多くの時間がかかるようになります。
一部返金が重なります。1つの注文に対して3回の一部返金があると3行になり、行数をカウントして求めた注文数は誤ったものになります。
製品カタログが変更されます。SKUの名前が変更されると、1つの製品の履歴が2つに分割され、最も返品率の高い製品がリストのトップから消えてしまいます。
さらに、定義がいつの間にか変更されます。今月はより完全なデータにするために、誰かが返金された配送料を含めてしまい、トレンドの整合性が崩れてしまいます。
会議の席で初めて明らかになる4つ目のコストもあります。「なぜ財務の数字と違うのか」と聞かれたとき、その答えは、あなたが持参しなかったタブに記載されている日付の定義ルールの中にあります。
ツールに関するまとめは、AI tools for e-commerce analyticsで紹介しています。
Powerdrill Bloomで作成する方法
ステップ 1：注文と返金のエクスポートデータをアップロードする
注文ファイルと返金ファイルを一緒にアップロードします。Powerdrill Bloomはインポート時に対象列のプロファイルを作成するため、返品率を計算する前に、欠落している返金日、重複する注文識別子、不整合なSKU値などが明らかになります。
ステップ 2：自然言語でレポートを記述する
ルールを構築するのではなく、言葉で指定します。報告対象の日付、分母、配送料や税金を含めるかどうか、そして除外するものを指定します。
次に、エラーを検出するための質問を投げかけます。複数の返金が含まれる注文がいくつあるか、元の注文の報告期間外に発生した返金はどれか、そして製品別および理由コード別の返品率を尋ねます。
ステップ 3：チャート、レポート、またはスライドをエクスポートする
分母を指定した返品率、返金ラグ（日数）の分布、または数値の横に日付の定義が記載されたスライドなどを出力します。
よくある間違い
返品を物理的な返品として扱うこと。 プラットフォームの指標は、商品が戻ってきたかどうかにかかわらず、返金された金額をカウントします。どちらを意味しているのかを明確にしてください。
分母を明記せずに率を報告すること。 注文数、個数、金額では、それぞれ異なる結果が得られます。レポートで使用している分母を明記してください。
返金日と注文日を混同すること。 いずれかの基準を選択してラベルを貼り、この2つを混在させて比較しないでください。
返金された配送料や税金を説明なしに含めること。 どちらも通常は個別に追跡されます。これらを含めてしまうと、財務との照合が不可能になります。
注文数ではなく行数をカウントすること。 一部返金により、1つの注文に対して複数の行が作成されます。カウントする前に重複を排除してください。
チャージバックを無視すること。 返金記録がないままお金が出ていきます。これらをどこに表示させるかを決定し、明記してください。
公開されている業界平均の率と比較すること。 他の小売業者は異なる分母や日付ルールを使用しています。まずは自社のトレンドと比較してください。
結論
返金取引と返品額を区別し、日付の定義を決め、分母を1つ選択し、算出の基準となった数値の横に率を報告します。
率は成果物そのものではありません。製品別、理由別、返金ラグ別の内訳こそが、商品ページ、サイズチャート、またはサプライヤーのどこを修正すべきかを教えてくれるのです。
毎月その内訳を再構築するのに丸一日かかっているなら、注文のエクスポートデータを使ってPowerdrill Bloomをお試しください。また、CSV AI assistantやAI report generatorのページもご覧ください。
よくある質問
返品と返金の違いは何ですか？
返金（refund）とは、お金を返す取引のことです。指標としての返品（returns）は、商品が物理的に返品されたかどうかにかかわらず、商品やサービスの返金額を記録します。
返品率はどのように計算しますか？
返金された数値を指定した基準値で割り、100を掛けます。基準値には注文数、出荷個数、または純売上高を使用でき、それぞれ異なる数値が得られます。
返金日と注文日のどちらで報告すべきですか？
どちらでも構いませんが、ラベルを明記する必要があります。返金日はプラットフォームや銀行口座と一致し、注文日は各販売期間のより正確な状況を示します。
返金された配送料や税金はカウントされますか？
通常、返金額の数値には含まれません。WooCommerceでは、返金された配送料や税金は、代わりに配送料と税金の数値に報告されます。
私の数値が財務の数値と異なるのはなぜですか？
最も多い原因は日付の定義ルールであり、次に配送料、税金、チャージバックが含まれているかどうかです。数値を比較する前に、定義を比較してください。