Cách lập báo cáo trả hàng và hoàn tiền: Hướng dẫn chi tiết

Một cửa hàng báo cáo tỷ lệ trả hàng là 12%. Nhưng thực tế, một phần ba trong số đó không hề có hàng hóa nào được gửi trả lại.

Đó không phải là lỗi dữ liệu. Đó là điều xảy ra khi một khoản hoàn tiền được ghi nhận là một lượt trả hàng, và đây chính xác là cách hầu hết các nền tảng tính toán.

Sự khác biệt này nghe có vẻ quá chi li cho đến khi một nhân viên vận hành sử dụng con số của bạn để lập kế hoạch cho công suất kho bãi.

Hướng dẫn này sẽ đề cập đến những nội dung cần có trong một báo cáo trả hàng và hoàn tiền, và tại sao hai từ này lại mô tả các sự kiện khác nhau. Sau đó, hướng dẫn sẽ đề cập đến vấn đề về ngày tháng vốn âm thầm làm sai lệch các so sánh theo tháng, và cách xây dựng báo cáo từ một tệp xuất dữ liệu.

Những nội dung cần có trong báo cáo trả hàng và hoàn tiền

Có năm yếu tố cần xuất hiện trên cùng một giao diện hiển thị, và tỷ lệ trả hàng chỉ là một trong số đó.

Giá trị được hoàn lại, số lượng đơn hàng được hoàn tiền, khoảng thời gian, mẫu số dùng để chia, và tỷ lệ phân chia giữa hoàn tiền toàn phần và hoàn tiền một phần.

Hãy thêm các mã lý do nếu nền tảng của bạn ghi nhận chúng. Tỷ lệ cho bạn biết quy mô của vấn đề, còn lý do sẽ cho bạn biết bạn đang gặp phải vấn đề cụ thể nào.

Ban đầu, hãy bỏ qua phí vận chuyển và thuế. Cả hai thường được theo dõi riêng biệt, và việc gộp chung chúng lại sẽ khiến con số này không thể đối soát được về sau.

Trả hàng và hoàn tiền không phải là một

Tài liệu hướng dẫn của các nền tảng thường làm rất rõ điều này, và việc đọc chính xác từng câu chữ là điều rất đáng giá.

Tài liệu phân tích của WooCommerce analytics documentation phân biệt trực tiếp hai khái niệm này. Tài liệu nêu rõ rằng "hoàn tiền mô tả giao dịch gửi lại tiền cho khách hàng."

Nửa còn lại của định nghĩa đó mới là phần quan trọng. Chỉ số trả hàng ghi nhận giá trị được hoàn lại "bất kể việc hoàn tiền là toàn phần hay một phần và bất kể hàng hóa có thực sự được trả lại về mặt vật lý hay không."

Vì vậy, một khoản tín dụng thiện chí cho một mặt hàng bị hư hỏng vẫn được tính vào lượt trả hàng ngay cả khi không có sản phẩm nào được gửi ngược trở lại. Việc điều chỉnh giá cũng tương tự như vậy.

Chỉ một câu nói đó đã giải thích tại sao số liệu trả hàng lấy từ phân tích thương mại không thể được giao cho đội ngũ kho bãi để làm dự báo về lượng hàng trả lại thực tế.

Phí vận chuyển và thuế cũng được tách riêng. Phí vận chuyển được hoàn và thuế được hoàn không được bao gồm trong con số hoàn tiền. Thay vào đó, chúng xuất hiện dưới dạng giá trị âm trong số liệu vận chuyển và thuế.

Vấn đề về ngày tháng

Vấn đề này làm thay đổi đường xu hướng của bạn thay vì chỉ ảnh hưởng đến một ô dữ liệu đơn lẻ, điều này khiến nó trở nên tồi tệ hơn.

WooCommerce ghi nhận các khoản hoàn tiền "dưới dạng một số âm vào ngày xảy ra hoạt động trả hàng (không phải ngày đặt đơn hàng)."

Hãy nghĩ xem điều đó ảnh hưởng thế nào đến việc so sánh theo tháng. Một khoản hoàn tiền vào tháng 3 cho một đơn hàng từ tháng 2 sẽ được tính vào tháng 3, và doanh thu của tháng 2 không bao giờ được điều chỉnh lại.

Cả hai tháng giờ đây đều bị sai lệch một chút theo các hướng ngược nhau. Tháng 2 trông có vẻ tốt hơn thực tế, còn tháng 3 lại phải gánh một khoản chi phí mà nó không hề tạo ra.

Có hai cách khắc phục hợp lý, và bạn phải chọn một cách và ghi rõ bằng văn bản.

Báo cáo theo ngày hoàn tiền và gắn nhãn báo cáo là chế độ xem dòng tiền. Cách này khớp với ngân hàng và nền tảng của bạn, nhưng sẽ không bao giờ khớp với phân tích nhóm thuần tập.

Hoặc phân bổ lại từng khoản hoàn tiền về ngày đặt đơn hàng ban đầu. Cách này mang lại một bức tranh chân thực theo từng giai đoạn bán hàng, đồng thời đồng nghĩa với việc con số của tháng trước sẽ thay đổi sau khi bạn đã công bố.

Không có cách nào là sai cả. Việc công bố báo cáo mà không nêu rõ bạn đã sử dụng cách nào mới là sai.

Lựa chọn mẫu số

Tỷ lệ trả hàng cần một số chia, và có ba số chia phổ biến tạo ra ba con số khác nhau.

Mẫu số	Ý nghĩa của tỷ lệ	Phù hợp nhất cho
Đơn hàng trong kỳ	Tỷ lệ đơn hàng được hoàn lại tiền	Khối lượng công việc của bộ phận chăm sóc khách hàng
Số lượng sản phẩm đã giao	Tỷ lệ sản phẩm bị trả lại	Kho bãi và nhập lại kho
Giá trị doanh thu thuần	Tỷ lệ doanh thu bị hoàn trả	Tài chính và biên lợi nhuận

Hãy lựa chọn tùy theo đối tượng người xem. Một báo cáo tài chính sẽ cần phiên bản giá trị, còn một báo cáo vận hành sẽ cần số lượng sản phẩm.

Sau đó, hãy cẩn thận với các số liệu bán hàng xung quanh, vì chúng cũng đã được định nghĩa sẵn. WooCommerce tính tổng doanh thu bằng giá nhân với số lượng, không bao gồm hoàn tiền, phiếu giảm giá, thuế và phí vận chuyển; và doanh thu thuần bằng tổng doanh thu trừ đi lượt trả hàng và phiếu giảm giá.

Giá trị đơn hàng trung bình ở đây là doanh thu thuần chia cho số lượng đơn hàng. Vì vậy, các khoản hoàn tiền đã nằm sẵn trong chỉ số AOV mà bạn có thể đang trích dẫn ở nơi khác.

Hướng dẫn của chúng tôi về cách chuyển đổi đơn hàng thương mại điện tử thô thành báo cáo xu hướng bán hàng sẽ đề cập đến khía cạnh doanh thu của cùng một tệp xuất dữ liệu này.

Cách thực hiện thủ công

Tùy chọn 1: Hai tổng số và một phép chia

Lọc tệp xuất dữ liệu để lấy các bản ghi hoàn tiền trong kỳ, sau đó tính tổng giá trị được hoàn lại bằng hàm SUMIFS.

Đếm số đơn hàng bị ảnh hưởng bằng hàm COUNTIFS, và hãy lọc trùng lặp các mã định danh đơn hàng trước nếu một đơn hàng đơn lẻ có thể có nhiều lần hoàn tiền.

Thực hiện phép chia một lần duy nhất ở bước cuối cùng. Việc hiển thị cả hai tổng số là cách giúp người khác có thể kiểm tra lại công việc của bạn.

Giới hạn sẽ xuất hiện rất nhanh. Bạn chỉ có được một tỷ lệ cho một khoảng thời gian, mà không có cái nhìn tổng quan về việc sản phẩm hoặc lý do nào đã dẫn đến tỷ lệ đó.

Tùy chọn 2: Mỗi hàng cho một khoản hoàn tiền

Xây dựng một bảng với mỗi hàng tương ứng với một khoản hoàn tiền. Các cột bao gồm ngày đặt hàng, ngày hoàn tiền, số ngày chênh lệch, giá trị hoàn tiền, hoàn tiền toàn phần hay một phần, và lý do.

Tính toán khoảng cách ngày bằng cách lấy ngày muộn hơn trừ đi ngày sớm hơn. Hướng dẫn của Microsoft về hàm DATEDIF cảnh báo rằng hàm này "có thể tính toán kết quả không chính xác trong một số trường hợp nhất định."

Giờ đây, báo cáo có thể được phân tích lát cắt. Theo sản phẩm, theo danh mục, theo kênh, theo lý do, hoặc theo độ trễ hoàn tiền.

Cột độ trễ là cột thường bị đánh giá thấp. Một nhóm các khoản hoàn tiền tập trung vào thời điểm 40 ngày sau khi mua hàng cho thấy vấn đề về độ bền, trong khi một nhóm tập trung vào thời điểm bốn ngày lại cho thấy vấn đề về kích cỡ hoặc mô tả sản phẩm.

Giới hạn ở đây là khối lượng dữ liệu và việc liên kết dữ liệu. Việc đối chiếu các khoản hoàn tiền với các dòng đơn hàng và dữ liệu sản phẩm đã vượt quá giới hạn mà các công thức thông thường có thể xử lý một cách dễ dàng.

Tùy chọn 3: Một tab định nghĩa

Ghi lại ngày bạn dùng để báo cáo, mẫu số, và liệu phí vận chuyển và thuế có được bao gồm hay không.

Sau đó, ghi lại các trường hợp ngoại trừ. Các đơn hàng bị hủy chưa từng được giao, các giao dịch thử nghiệm và các khoản bồi hoàn đều cần có phương án xử lý rõ ràng.

Bồi hoàn là điều mà mọi người thường hay quên. Tiền bị trừ đi, không có lượt trả hàng nào được ghi nhận, và hai hệ thống sẽ mãi mãi không khớp số liệu với nhau.

Hạn chế là việc viết ra một quy tắc không đồng nghĩa với việc nó sẽ tự động được áp dụng. Ai đó sẽ lại phải thiết lập lại các bộ lọc tương tự vào tháng sau.

Giới hạn chung. Cả ba tùy chọn đều giả định rằng tệp xuất dữ liệu chứa cả hai loại ngày. Nếu nó chỉ có ngày hoàn tiền, chế độ xem nhóm thuần tập sẽ không thể khôi phục được từ tệp đó.

Những điểm nghẽn của phương pháp thủ công

Báo cáo đầu tiên mất một buổi sáng. Báo cáo thứ tư mất nhiều thời gian hơn, bởi vì có ba yếu tố đã bị sai lệch.

Các khoản hoàn tiền một phần nhân lên. Một đơn hàng với ba lần hoàn tiền một phần sẽ biến thành ba hàng dữ liệu, và việc đếm số lượng đơn hàng bằng cách đếm số hàng giờ đây sẽ bị sai.

Danh mục sản phẩm thay đổi. Một SKU bị đổi tên sẽ chia lịch sử của một sản phẩm thành hai, và sản phẩm có tỷ lệ trả hàng tệ nhất sẽ biến mất khỏi vị trí dẫn đầu trong danh sách của bạn.

Sau đó, các định nghĩa âm thầm thay đổi. Ai đó đã gộp cả phí vận chuyển được hoàn vào tháng này vì cảm thấy nó đầy đủ hơn, và thế là đường xu hướng bị phá vỡ.

Có một cái giá thứ tư chỉ xuất hiện trong các cuộc họp. Khi ai đó hỏi tại sao bộ phận tài chính lại có một con số khác, câu trả lời nằm ở quy ước ngày tháng được lưu trong một tab dữ liệu mà bạn đã không mang theo.

Về khía cạnh công cụ, chúng tôi có một bài tổng hợp riêng tại AI tools for e-commerce analytics.

Cách xây dựng báo cáo với Powerdrill Bloom

Bước 1: Tải lên các tệp xuất dữ liệu đơn hàng và hoàn tiền

Tải lên đồng thời tệp đơn hàng và tệp hoàn tiền. Powerdrill Bloom sẽ phân tích cấu trúc các cột ngay khi tải lên, nhờ đó các thông tin như ngày hoàn tiền bị thiếu, mã định danh đơn hàng bị trùng lặp và các giá trị SKU không nhất quán sẽ được phát hiện trước khi bất kỳ tỷ lệ nào được tính toán.

Bước 2: Mô tả báo cáo bằng ngôn ngữ tự nhiên

Hãy nêu ra các quy tắc thay vì tự mình xây dựng chúng. Hãy chỉ định ngày bạn dùng để báo cáo, mẫu số, liệu phí vận chuyển và thuế có được bao gồm hay không, và những gì cần loại trừ.

Sau đó, hãy đặt những câu hỏi giúp phát hiện lỗi. Hỏi xem có bao nhiêu đơn hàng có nhiều hơn một lần hoàn tiền. Hỏi xem những khoản hoàn tiền nào nằm ngoài kỳ báo cáo của đơn hàng gốc tương ứng. Sau đó, yêu cầu cung cấp tỷ lệ theo sản phẩm và theo mã lý do.

Bước 3: Xuất biểu đồ, báo cáo hoặc slide trình bày

Xuất ra tỷ lệ đi kèm với mẫu số của nó, biểu đồ phân phối độ trễ hoàn tiền theo ngày, hoặc các slide trình bày có hiển thị quy ước ngày tháng ngay bên cạnh con số.

Các sai lầm phổ biến

Coi lượt trả hàng là trả hàng thực tế. Các chỉ số của nền tảng tính toán giá trị được hoàn lại bất kể hàng hóa có được trả lại hay không. Hãy nêu rõ bạn đang muốn nói đến trường hợp nào.

Báo cáo tỷ lệ mà không có mẫu số. Đơn hàng, số lượng sản phẩm và giá trị mang lại ba câu trả lời khác nhau. Hãy ghi rõ mẫu số của bạn trên báo cáo.

Lẫn lộn giữa ngày hoàn tiền và ngày đặt hàng. Hãy chọn một quy ước duy nhất, gắn nhãn cho nó và không bao giờ so sánh chéo giữa hai quy ước này.

Âm thầm gộp cả phí vận chuyển và thuế được hoàn vào. Cả hai thường được theo dõi riêng biệt. Việc gộp chung chúng lại sẽ khiến việc đối soát với bộ phận tài chính trở nên bất khả thi.

Đếm số hàng thay vì đếm số đơn hàng. Hoàn tiền một phần tạo ra nhiều hàng dữ liệu cho mỗi đơn hàng. Hãy lọc trùng lặp trước khi đếm.

Bỏ qua các khoản bồi hoàn. Tiền bị trừ đi mà không có bản ghi hoàn tiền nào. Hãy quyết định xem chúng sẽ xuất hiện ở đâu và ghi lại điều đó.

So sánh với tỷ lệ trung bình được công bố của ngành. Các nhà bán lẻ khác sử dụng các mẫu số và quy tắc ngày tháng khác nhau. Hãy so sánh với xu hướng của chính bạn trước tiên.

Kết luận

Hãy tách biệt giao dịch hoàn tiền khỏi giá trị trả hàng, chọn một quy ước ngày tháng, chọn một mẫu số và báo cáo tỷ lệ đó ngay bên cạnh số liệu nền tảng tạo ra nó.

Tỷ lệ không phải là kết quả bàn giao cuối cùng. Việc phân tích chi tiết theo sản phẩm, theo lý do và theo độ trễ hoàn tiền mới là thứ cho bạn biết liệu cần phải chỉnh sửa thông tin sản phẩm, bảng kích cỡ hay cần làm việc lại với nhà cung cấp.

Nếu việc xây dựng lại bảng phân tích chi tiết đó mỗi tháng làm tiêu tốn của bạn cả ngày trời, hãy dùng thử Powerdrill Bloom cho tệp xuất dữ liệu đơn hàng của bạn. Xem thêm các trang CSV AI assistant và AI report generator.

Câu hỏi thường gặp

Sự khác biệt giữa trả hàng và hoàn tiền là gì?

Hoàn tiền là giao dịch gửi lại tiền cho khách hàng. Trong khi đó, trả hàng, với tư cách là một chỉ số, ghi nhận giá trị được hoàn lại của hàng hóa và dịch vụ bất kể có sản phẩm nào thực sự được trả lại về mặt vật lý hay không.

Làm thế nào để tính tỷ lệ trả hàng?

Chia số lượng hoạt động hoàn tiền cho một số liệu nền tảng được chỉ định, sau đó nhân với 100. Số liệu nền tảng đó có thể là số lượng đơn hàng, số lượng sản phẩm đã giao hoặc giá trị doanh thu thuần, và mỗi lựa chọn sẽ cho ra một con số khác nhau.

Tôi nên báo cáo theo ngày hoàn tiền hay ngày đặt hàng?

Cách nào cũng được, miễn là bạn có gắn nhãn rõ ràng. Ngày hoàn tiền sẽ khớp với nền tảng và ngân hàng của bạn, trong khi ngày đặt hàng mang lại bức tranh chân thực hơn về từng giai đoạn bán hàng.

Phí vận chuyển và thuế được hoàn có được tính gộp vào không?

Thường là không nằm trong con số hoàn tiền. Thay vào đó, WooCommerce báo cáo phí vận chuyển và thuế được hoàn trong các số liệu về vận chuyển và thuế tương ứng.

Tại sao con số của tôi lại khác với số liệu của bộ phận tài chính?

Nguyên nhân phổ biến nhất là do quy ước ngày tháng, tiếp theo là việc có bao gồm phí vận chuyển, thuế và các khoản bồi hoàn hay không. Hãy so sánh các định nghĩa trước khi so sánh các con số.