如何製作退貨與退款報告：完整指南

某家商店回報了 12% 的退貨率。但其中有三分之一實際上根本沒有收到任何退回的實體商品。

這並非資料錯誤。當退款被記錄為退貨時，就會發生這種情況，而這正是大多數平台計算的方式。

這種區分聽起來可能有些吹毛求疵，直到營運部門的同仁根據您提供的數字來規劃倉儲空間時，您才會意識到其重要性。

本指南將介紹退貨與退款報告中應包含的內容，以及為什麼這兩個詞代表不同的事件。接著，我們將探討悄悄破壞每月數據對比的日期問題，並說明如何透過匯出的資料來製作這份報告。

退貨與退款報告必須包含的內容

同一個檢視畫面中應該包含五個要素，而退貨率只是其中之一。

退款金額、退款訂單數量、期間、計算所使用的分母，以及全額退款與部分退款的佔比。

如果您的平台有記錄退款原因代碼，也請一併加入。退貨率能告訴您問題的嚴重程度，而原因則能指出具體問題所在。

一開始請先排除運費和稅金。這兩者通常是分開追蹤的，混在一起會導致日後無法進行數據對帳。

退貨與退款並非同一回事

平台說明文件對此有著異常清晰的定義，非常值得仔細閱讀其確切措辭。

WooCommerce 的 analytics documentation 直接將兩者分開。它指出「退款（refund）是指將資金退還給顧客的交易。」

該定義的後半部分才是關鍵。退貨（returns）指標記錄的是退款金額，「無論是全額退款還是部分退款，也無論商品是否實際退回。」

因此，即使沒有任何商品寄回，因商品損壞而給予的補償性退款也會被計入退貨中。價格調整也是如此。

光是這一句話，就解釋了為什麼不能直接將電子商務分析中的退貨數據交給倉庫團隊，當作實體退貨預測的依據。

運費和稅金也被排除在外。退還的運費和稅金不包含在退款金額中，而是以負值顯示在運費和稅金的數據中。

日期問題

這個問題會影響您的趨勢線，而不僅僅是單個儲存格，這使得情況變得更糟。

WooCommerce 會將退款記錄為「退貨發生當天的負數（而非下單日期）。」

think about what that does to a monthly comparison. 針對 2 月訂單在 3 月進行的退款會被歸入 3 月，而 2 月的營收則永遠不會被重新調整。

這導致這兩個月的數據都出現了相反方向的輕微偏差。2 月的業績看起來比實際情況更好，而 3 月則承擔了並非由該月創造的成本。

有兩種合理的解決方案，您必須明確選擇其中一種並記錄下來。

依退款日期進行報告，並將該報告標記為現金流檢視。這能與您的銀行和平台數據對齊，但永遠無法與同期群分析相匹配。

或者將每筆退款重新歸入其原始下單日期。這能呈現每個銷售期間的真實狀況，但也意味著上個月的數據在發布後仍會發生變化。

這兩種方法都沒有錯。錯的是在發布報告時沒有說明您使用的是哪一種方法。

選擇分母

計算退貨率需要一個除數（分母），以下是三種常用的分母，它們會產生三種不同的數值。

分母	該比率代表的意義	最適用於
該期間的訂單數	發生退款的訂單比例	客服工作量評估
出貨件數	退回商品的比例	倉儲與重新上架規劃
淨銷售額	營收逆轉（退回）的比例	財務與利潤分析

請根據閱讀對象來選擇。財務審查需要金額版本的數據，而營運審查則需要件數。

此外，請務必留意周邊的銷售數據，因為這些數據也有明確的定義。WooCommerce 的總銷售額（gross sales）定義為價格乘以數量（不含退款、優惠券、稅金和運費），而淨銷售額（net sales）則是總銷售額減去退貨和優惠券。

其中的平均訂單金額（AOV）是淨銷售額除以訂單數。因此，您在其他地方引用的 AOV 中，其實已經包含了退款的影響。

我們的指南 turning raw e-commerce orders into a sales trend report 介紹了同一份匯出資料中關於營收方面的處理。

如何手動製作報告

方案 1：兩個總和與一次除法

篩選出該期間退款記錄的匯出資料，然後使用 SUMIFS 計算退款總金額。

使用 COUNTIFS 計算受影響的訂單數量。如果單筆訂單可能包含多次退款，請先去除重複的訂單識別碼。

最後進行一次除法計算。保持這兩個總和清晰可見，能方便他人複核您的工作。

這種方法的局限性很快就會顯現。您只能得到單一期間的單一比率，無法得知是哪些商品或原因導致了退貨。

方案 2：每筆退款佔用一列

建立一個每筆退款佔用一列的表格。欄位包括：下單日期、退款日期、間隔天數、退款金額、全額或部分退款，以及原因。

用較晚的日期減去較早的日期來計算天數差距。Microsoft 針對 DATEDIF function 的指南中警告，該函數「在某些特定情況下可能會計算出不正確的結果」。

現在，您可以對報告進行多維度分析：按商品、按類別、按通路、按原因或按退款時間差。

時間差這一欄往往被低估了。如果退款集中在購買後 40 天，通常指向耐用性問題；而如果集中在 4 天內，則可能指向尺寸或商品描述不符的問題。

這種方法的限制在於資料量和關聯操作。當需要將退款與訂單明細及商品資料進行比對時，公式的複雜度將超出易用範圍。

方案 3：定義分頁

記錄您報告所依據的日期、使用的分母，以及是否包含運費和稅金。

接著記錄排除項目。未出貨的取消訂單、測試交易和爭議款，都需要明確說明處理方式。

爭議款是人們最容易遺忘的一項。資金已被扣除，卻沒有記錄退貨，導致兩個系統的數據永遠對不上。

這種方法的局限在於，僅僅寫下規則並不等於自動執行。下個月還是得有人重新設定相同的篩選條件。

共同的局限。 這三種方法都假設匯出的資料同時包含這兩個日期。如果資料中只有退款日期，就無法從該檔案中還原同期群檢視。

手動流程效率低下的原因

製作第一份報告需要花費半天。但到了第四份時，花費的時間會更長，因為有三件事情發生了偏差。

部分退款成倍增加。一筆包含三次部分退款的訂單會變成三列資料，此時如果直接計算列數，得出的訂單數量就會出錯。

商品目錄發生變更。重新命名的 SKU 會將單一商品的歷史記錄拆分為兩部分，導致退貨率最高的商品從您的排行榜頂部消失。

接著，定義在不知不覺中發生了變化。有人因為覺得數據更完整，而在本月將退還的運費納入計算，導致趨勢線中斷。

還有第四種成本只會在會議中顯現。當有人詢問為什麼財務部門的數字不同時，答案其實是隱藏在您沒帶來的分頁中的日期定義慣例。

工具方面的彙整請參閱 AI tools for e-commerce analytics。

如何使用 Powerdrill Bloom 製作報告

步驟 1：上傳您的訂單與退款匯出檔案

同時上傳訂單檔案與退款檔案。Powerdrill Bloom 會在檔案匯入時分析欄位，因此在計算任何比率之前，就能找出缺失的退款日期、重複的訂單識別碼以及不一致的 SKU 數值。

步驟 2：使用自然語言描述報告

直接說明規則，而無需手動建構。指定您報告所依據的日期、分母、是否包含運費和稅金，以及要排除的項目。

接著提出能揪出錯誤的問題。例如：有多少訂單包含一次以上的退款？哪些退款超出了其原始訂單的報告期間？然後要求按商品和原因代碼計算退貨率。

步驟 3：匯出圖表、報告或簡報

匯出包含分母的退貨率、退款天數差距分佈圖，或是在數字旁標註日期慣例的簡報投影片。

常見錯誤

將退貨指標等同於實體退貨。 平台指標計算的是退款金額，無論商品是否實際退回。請明確說明您指的是哪一種。

報告退貨率時未註明分母。 訂單數、件數和金額會得出三種不同的答案。請在報告中明確標示您使用的是哪一種。

混用退款日期和下單日期。 請統一選擇一種慣例並做好標記，切勿將兩者進行交叉對比。

默默將退還的運費和稅金納入計算。 這兩者通常是分開追蹤的。將它們混入會導致無法與財務部門進行對帳。

計算列數而非訂單數。 部分退款會使單筆訂單產生多列資料。請在計算前先去除重複資料。

忽略爭議款。 資金已被扣除卻沒有退款記錄。請決定它們應該出現在哪裡並記錄下來。

與公開的行業平均率進行比較。 其他零售商可能使用不同的分母和日期規則。請先與您自己的歷史趨勢進行對比。

結論

將退款交易與退貨金額區分開來、選擇一種日期慣例、選定一個分母，並在報告退貨率時並列顯示其計算基準。

退貨率本身並非最終成果。按商品、原因和退款時間差進行的細分分析，才能告訴您應該修改商品頁面、調整尺寸表，還是更換供應商。

如果每個月重新進行這些細分分析要花上您一整天的時間，不妨試試 Powerdrill Bloom 來處理您的訂單匯出檔案。另請參閱 CSV AI assistant 和 AI report generator 頁面。

常見問題

退貨與退款有何不同？

退款是指退還資金的交易。而退貨作為一項指標，記錄的是商品和服務的退款金額，無論商品是否實際退回。

如何計算退貨率？

將退款活動除以指定的基準，然後乘以 100。該基準可以是訂單數、出貨件數或淨銷售額，每種基準都會得出不同的數值。

我應該依退款日期還是下單日期進行報告？

兩者皆可，只要您做好標記。退款日期能與您的平台和銀行數據對齊，而下單日期則能更真實地反映每個銷售期間的狀況。

退還的運費和稅金是否計算在內？

通常不包含在退款金額中。WooCommerce 會將退還的運費和稅金分別記錄在運費和稅金的數據中。

為什麼我的數據與財務部門的不一致？

最常見的原因是日期慣例不同，其次是是否包含了運費、稅金和爭議款。在對比數據之前，請先對比雙方的定義。