RMA返品データを
Excelで追跡する方法

RMAデータの死角：返品フォームとスプレッドシートの間でなぜ処理が滞るのか

返品管理ソフトウェアは、RMAプロセスのうち顧客向けの部分を解決しました。Loop Returns、Happy Returns、Narvarなどのポータルでは、買い物客はサポートにメールを送ることなく、返品の開始、ラベルの印刷、返金の追跡が可能です。しかし、その自動化はデータ層で止まっています。つまり、RMAフォームの情報が、倉庫チーム、返品処理担当者、またはERPシステムが処理できるスプレッドシートの行になるべき時点です。

このギャップが重要である理由は、数字が示しています。UPS傘下のHappy Returnsと共同で作成したNRFの「2025年リテール返品状況レポート」によると、小売業者の60%が返品処理と新規注文のフルフィルメントのどちらかを選択せざるを得なかったことがわかりました。全返品の9%は不正として分類されており、構造化された追跡がなければ、正当な返品と不正な返品を区別することは推測に頼らざるを得ません。2033年までに3.18兆ドル市場を代表するReverse Logistics Associationは、最近の年次会議でデータ主導の処分を中心テーマに掲げています。

返品ポータルと倉庫現場の間にあるものは、驚くほどローテクです。誰かがRMAフォーム（顧客ポータルからのPDF、B2B卸売業者からのスキャンされた返品伝票、箱の中に手書きで同封された承認書など）を開き、そのフィールドを手動で追跡用スプレッドシートに入力します。r/Netsuiteのある投稿は、この状況を正確に説明しています。「RMAプロセスは2人分のフルタイムの仕事になっています。すべての返品は、顧客からのメール、誰かが手動で承認し、その後手動でラベルを生成することから始まります。」r/supplychainのある卸売業者は、もっと率直に述べています。彼らの返品プロセスは「彼らを蝕んでいた」—手動のRMAワークフロー、仕入先クレジット調整の悪夢、そして倉庫のボトルネック。

返品自動化に欠けているのは、返品ポータルではありません。抽出層、つまりフォームを構造化データに変換するステップです。

RMAフォームに実際に含まれる情報 — 手入力では拡張できない理由

標準的なRMAフォームには、ほとんどの人が認識している以上の情報が含まれています。単に「顧客が商品を返品したい」というだけではありません。完全なRMAフォームには、注文番号、製品SKUとUPC、返品数量、返品理由コード（不良品、サイズ違い、説明と異なる、配送中の破損、気が変わった）、到着時の商品状態（未開封、開封済み、破損、付属品欠品）、希望する対応（返金、交換、ストアクレジット、修理）、そして割り当てられたRMA番号自体が含まれます。IMARC Groupのデータによると2024年にリバースロジスティクス収益の35.1%を占めたB2B返品の場合、フォームには契約固有の条件、クレジットノート参照情報、一括返品数量も含まれます。

そのフォームで最も業務上有用なフィールドは理由コードです。特定のSKUで「不良品」が急増すれば、それは品質管理のシグナルです。アパレルラインで「サイズ違い」が返品の大半を占めれば、それはサイズガイドの問題です。LateShipmentによるRMAデータの分析では、理由コードレベルの追跡により、全体の返品率では隠れてしまう問題が明らかになることが判明しました。全体的な返品率が4%の製品投入は一見問題なさそうに見えても、そのSKUだけで「説明と異なる」が2%から18%に跳ね上がっていることがわかります。

しかし、理由コードデータを規模に応じて取得するには、フォームから抽出する必要があります。すべての返品理由コードがPDF、スキャンされた伝票、手書きのメモから手入力されている場合、データは遅れて、一貫性がなく、しばしばまったく届きません。ReturnProの内部調査では、顧客はドロップダウンメニューに最初に表示される理由を不釣り合いなほど選択することが判明しており、これは顧客向けフォームからの手動データがすでに汚染されていることを意味します。正確な理由コードデータを取得するには、抽出に加えて構造化された分類ロジックが必要です。これは手入力では強制できません。

AI抽出がテンプレートなしでRMAフォームを読み取る仕組み

従来のOCRは、文字の画像をテキストストリームに変換することでドキュメントを処理します。どのテキストがRMA番号で、どれが返品理由なのかを認識せず、ただ単に単語の羅列を出力するだけです。テンプレートベースのツールは、各フィールドの座標を定義できる点で一歩進んでいますが、フォームのレイアウトが変わるとすぐに機能しなくなります。あるRMAは返品ポータルが生成したPDF、次のRMAは手書きの伝票の写真、3つ目はベンダーのERPシステムからスキャンされたB2B承認フォームかもしれません。フォーマットが変わるごとに新しいテンプレートが必要になり、フォームのバリエーションごとにテンプレートを管理することが、2人分の工数が必要だったRMA処理を恒久的な人員配置要件に変えてしまいます。

AIベースのカスタム列抽出は、これとは異なる動作をします。システムに各フィールドをページ上のどこで見つけるかを指示する代わりに、出力スプレッドシートに必要な列名を入力することで、何を探しているかを指示します。「RMA番号」「返品理由コード」「SKU」「数量」「要求された対応」。AIは各フォームを読み取り、座標ではなく意味に基づいてそれらの列名に一致する値を特定し、対応する列に自動入力します。鮮明なPDF、歪んだ手書き返品伝票のスマホ写真、10年前のファイルキャビネットから出てきたスキャン済み紙フォームのいずれであっても、同じ列名セットが機能します。

これがデータ抽出とテキスト転記の違いです。「RMA # — 44291 — 理由: 破損」と書かれた手書きのRMAは、ポータル生成のラベル付きPDFと同じように読み取られます。AIは「44291」をRMA番号として識別します。これは、番号とラベルの意味的な関係を理解しているからであり、テンプレート上の所定の位置に一致するからではありません。複数の倉庫、複数の販売チャネル、それぞれ異なるRMAフォーム形式で返品を処理するチームにとって、このテンプレート不要のアプローチは、機能するシステムと、最も整った60%のフォームしか処理できないシステムとの違いを生みます。

この仕組みは、フォームに明示的に書かれているフィールドに限定されません。推論列を定義できます。例えば、「処分カテゴリ」列を「選択肢: 再在庫、修理、廃棄、ベンダー返品」と定義します。AIは商品の状態と理由コードを読み取り、フォームに「処分」フィールドが存在しなくても、ビジネスルールに基づいて推定される処分方法を割り当てます。抽出と分類を1回の処理で実行できます。

ステップバイステップ：RMAデータパイプラインをフォームからスプレッドシートへ構築

抽出レイヤーは、RMA受付（顧客やパートナーが返品を送信する方法）と運用スタック（WMS、ERP、追跡スプレッドシート）の間に位置します。以下は、RMAフォーム専用の設定方法です。

上記のデモは「RMAフォーム」を文書タイプとして実行されます。独自の列名を入力し、サンプルのRMAフォームをアップロードして抽出動作をご確認ください。週に数百件の返品がある本番環境でも、同じワークフローが追加設定なしでスケールします。フォームごとの設定やテンプレート管理は不要です。

返品データの追跡：処分判断とトレンド分析

RMAデータがスプレッドシートに取り込まれると、それは利益率の回復に直結するリバースロジスティクス判断の基盤となります。「処分（ディスポジション）」とは返品された商品の行き先を決める判断であり、返品がコストになるか価値を回復するかを左右します。標準的な処分経路は、再在庫（販売可能在庫に戻す）、再生（修理後に再販）、換金（セカンダリチャネルで割引販売）、仕入先返品（RTV：サプライヤーに返送してクレジット）、廃棄（回収価値なし）です。

各経路は財務結果が異なります。定価で再在庫された商品は、処理コストを差し引いてほぼ全額を回収します。再生品は通常、元の価値の40～60％を回収します。換金パレットは10～20％程度です。返品を再在庫に回すか換金に回すかの違いは純利益そのものですが、適切な判断には、検査時点で正確な商品状態と理由コードデータが必要です。

抽出されたRMAデータをスプレッドシートに持つことで、多くの返品運用が見逃している分析を実行できます。

• SKU別理由コード発生率。「不良」返品が多いのはどの製品か？特定のロット、特定の倉庫での取り扱い、あるいは設計上の問題か？全返品で理由コードデータを正規化しなければ、推測に過ぎない。
• 処分区分の分布。返品のうち、再在庫、再生、廃棄の割合は？廃棄率が上昇しているなら、上流（サプライヤー品質、梱包、返品理由の構成）で何かが変わっている。
• 処分経路別処理時間。RMA発行から倉庫受領、最終処分まで、各段階にどれだけ時間がかかるか？返品業務ベンチマークでは、受領から処分まで2～7日が目標。1日超えるごとに残存価値が目減りする。
• 複数倉庫間比較。同じ人員数で倉庫Aが倉庫Bの2倍の返品処理速度なら、スプレッドシートはプロセス改善の焦点、あるいは拠点間のフォーム入力品質の差を示す。

スプレッドシートはWMSの代わりにはならない。それは、現在のデータ（フォーム）と、WMSが返品を正しく振り分けるために必要なデータのギャップを埋めるものだ。

抽出したRMAデータと倉庫システムの統合

ほとんどの返品業務には既にソフトウェアスタックがある。問題はそれを置き換えるかどうかではなく、いかにクリーンなデータを供給するかだ。抽出レイヤーはExcel（XLSX）とCSVに出力する。これは主要なWMSとERPがインポート用に受け付ける形式だ。統合方法は使用中のシステムによる。

NetSuite: 返品チームが既にNetSuiteでRMAレコードを生成している場合、ボトルネックはデータ入力工程、つまりフォームのフィールドをNetSuiteのRMAモジュールに手入力することだ。抽出したスプレッドシートはNetSuiteのCSVインポートツールに直接インポートでき、抽出した列（RMA番号、SKU、理由コード、処分区分）をNetSuiteのRMAフィールドにマッピングできる。2名のフルタイム従業員問題を報告したr/Netsuiteスレッドでも、NetSuiteは「レコードを適切に保持する」が、問題は常にレコードへのデータ投入だったと指摘されている。

ShipStation / Cin7 / Fishbowl: これらのWMSプラットフォームは在庫追跡と注文フルフィルメントをネイティブに処理するが、返品の振り分け（返品されたアイテムの処分区分の決定）はRMAフォームからのデータに依存する。抽出したスプレッドシートをCSVとして返品モジュールにインポートすれば、WMSは抽出時に生成した処分区分列に基づいて、アイテムを再在庫、隔離、再生、RTVゾーンに振り分けられる。

Googleスプレッドシート / 手動管理: スプレッドシートで運用している場合、抽出出力は既に作業形式になっている。XLSXにエクスポートし、Googleスプレッドシートで開けば、手動入力工程を直接フィードに置き換えられる。同じスプレッドシートで、入力作業は不要。これは、正式なWMSを持たない中小規模の3PLや倉庫業務で最も一般的な設定だ。

3つのアプローチすべてに共通するパターンは同じだ。抽出レイヤーが「フォームを読む」ことと「データに基づいて行動する」ことを切り離す。データがNetSuite、ShipStation、共有のGoogleスプレッドシートのいずれに届くかは下流の判断であり、抽出の設定方法は変わらない。1つの抽出設定ですべての出力先で機能する。

よくある質問

手書きのRMA伝票でも使えますか？

はい — ただし、すべての手書き文字認識に共通する注意点があります。適切な照明の下で人間が読める手書き文字であれば、AI抽出は通常読み取れます。にじんだインク、極端に圧縮された筆記体、他の欄にかぶって書かれた文字は精度が低下します。同じ列ベースの抽出が、設定変更なしでタイプ印刷と手書きの両方のフォームで機能します — システムにどのフォームが手書きか印刷かを伝える必要はありません。手書き文字抽出のパフォーマンスの詳細については、手書き文字抽出精度向上ガイドをご覧ください。

異なる言語のRMAフォームからデータを抽出できますか？

AIは書かれている言語のまま文書の内容を読み取ります — RMAフォームが英語、スペイン語、ドイツ語、または混在していても、抽出は各フォームを個別に処理します。列名は出力したい言語で指定してください。アップロード前に言語を事前翻訳したり正規化する必要はありません。

RMAフォームごとにフィールドが異なる場合はどうなりますか？

それが想定されるシナリオです。カスタム列抽出では、すべてのフォームにすべてのフィールドが含まれている必要はありません。定義したフィールドがフォームにない場合 — たとえば手書き伝票に「理由コード」がない場合 — 出力ではそのセルは空白になります。システムはデータを推測したり、ギャップを埋めるためにデータを作成したりしません。これは特に、異なるベンダーのB2B返品フォームが異なるフィールドセットを持つRMAワークフローで重要です。

Loop ReturnsやHappy Returnsのような専用返品管理プラットフォームとの違いは何ですか？

専用返品プラットフォームは、ブランド化されたポータル、ラベル生成、返金処理といった顧客向けワークフローを処理し、買い物客にセルフサービスの返品体験を提供する必要がある場合に適したツールです。抽出レイヤーは別の機能を果たします。RMAフォームがどこから来たかに関係なくデータを抽出します。すべての返品が構造化データを取得する単一のポータルを通じて行われる場合、抽出は不要です — ポータルがすでに構造化データを提供します。返品がポータル、メール、B2Bベンダーフォーム、紙の伝票など複数のチャネルから届く場合、抽出がポータルではカバーできないギャップを埋めます。

理由コードと処分先フィールドの精度はどのくらいですか？

きれいに印刷されたRMAフォームの場合、注文番号やSKUなどの構造化フィールドの精度は最大99%に達します。理由コード（「不良品」「サイズ違い」などの短いテキストラベル）は、語彙が限られているため、高い信頼性があります。最も大きな変動要因は入力品質です。鮮明な印刷RMAフォームの写真は、くしゃくしゃの返品伝票のぼやけた写真よりも正確に抽出できます。誤った処分先に返品を振り分けるなど、エラーが高くつくフィールドについては、インポート前にスプレッドシートを簡単に人間が確認することが実用的な対策です。フィールドタイプ別の精度の詳細については、抽出精度の階層的分析をご覧ください。

最初にAIにRMAフォームの形式を学習させる必要がありますか？

いいえ。テンプレート不要の抽出とは、事前の学習やサンプルアノテーションなしで、AIがあらゆるRMAフォーム形式を処理できることを意味します。列名を一度定義すれば、ポータルのPDF、スキャンしたベンダーフォーム、手書きの伝票、倉庫で撮影した写真など、あらゆる形式から同じ列名で抽出できます。ゼロトレーニング要件こそが、それぞれ異なるレイアウトを持つ数十の異なるソースからのフォームを処理する返品業務において、このアプローチを実用的なものにしています。

返品自動化が見落としたデータギャップを埋める

逆物流業界は、返品の目に見える部分（カスタマーポータル、返品受付ネットワーク、即時返金、不正検知）に投資を注いできました。自動化されなかったのは、最も地味で労働集約的なステップ、つまりフォームを読んでデータを入力することです。これは、スタック内のすべてのソフトウェアツールと、それらのツールが機能するために実際に必要な情報の間に位置するステップです。

年間8499億ドル相当の返品がこのステップを通過します。トレンドを把握できる返品業務と、推測に頼る業務の違いは、より優れたポータル、より迅速な返金、またはより派手なWMSではありません。それは、RMAフォームのデータが間に合うようにスプレッドシートに反映されるかどうかです。

実際のRMAフォームでお試しください。バッチをアップロードして、手入力していたデータが、1フォームあたり5分ではなく5秒で列に表示されるのをご確認ください。