Tóm tắt nhanh
Doanh nghiệp ecommerce Việt Nam nên đối soát COD, phí sàn và hàng hoàn bằng một luồng dữ liệu nối OMS với WMS, không nên chỉ khớp file tiền cuối kỳ. Kết luận thực tế: nếu doanh nghiệp chỉ có ít đơn, ít COD và ít hàng hoàn, OMS hoặc file kiểm soát có thể đủ tạm thời; nếu bắt đầu có nhiều mã vận đơn, nhiều phí sàn/voucher, nhiều refund, hàng hoàn chưa về kho, hàng hoàn thiếu phụ kiện, nhiều kho hoặc 3PL, cần OMS + WMS để tách rõ dòng tiền, dòng hàng và trách nhiệm xử lý.
Cách làm đúng là xây một settlement waterfall cho từng đơn: giá trị đơn gốc, voucher do shop chịu, phí sàn, phí thanh toán, phí vận chuyển, COD, refund, bồi thường và trạng thái hàng hoàn vật lý. OMS giữ đơn, kênh bán, mã vận đơn, trạng thái giao và settlement; WMS xác nhận picking, checking, packing, bàn giao, nhận hoàn, QC và tồn khả dụng. Khi hai lớp này nối nhau, kế toán không còn hỏi kho bằng chat, kho không nhập nhầm hàng hoàn, CSKH có dữ liệu trả lời khách và quản lý thấy lệch tiền theo nguyên nhân.
Vì sao đây là khoảng trống nội dung?
Nhiều trang phần mềm tại Việt Nam đã nói về quản lý bán hàng đa kênh, đồng bộ đơn, quản lý kho, cổng vận chuyển, thu hộ COD hoặc đối soát tự động. Những thông tin này hữu ích ở tầng nhận biết, nhưng thường chưa trả lời câu hỏi mà chủ doanh nghiệp và kế toán gặp hằng tuần: vì sao tiền sàn về không khớp, khoản nào là phí hợp lệ, khoản nào là lỗi vận hành, hàng hoàn đã về kho chưa, có được nhập lại tồn không, và ai chịu trách nhiệm khi tiền đã quyết toán nhưng hàng vẫn đang trên đường hoàn.
Trong lần rà soát tự động này, các trang công khai truy cập được của BigSeller, Sapo, Nhanh.vn và Haravan đều có nhắc tới đơn hàng, tồn kho, vận chuyển, COD, thanh toán hoặc đa kênh. Khoảng trống nằm ở phần vận hành cụ thể: không có bảng waterfall phí, không có công thức lệch tiền, không có phân tách trạng thái tài chính và trạng thái kho, không có hàng đợi ngoại lệ theo owner, và không nói rõ khi nào OMS-only không còn đủ vì hàng hoàn cần WMS kiểm soát.
| Nguồn kiểm tra | Nội dung thấy được | Khoảng trống còn lại |
|---|---|---|
| BigSeller | Trang chủ nhấn mạnh quản lý bán hàng đa kênh, 20+ nền tảng, đơn hàng, tồn kho và fulfillment mỗi tháng. | Không thấy hướng dẫn công khai về waterfall đối soát COD + phí sàn + hàng hoàn theo từng trạng thái tài chính và trạng thái kho. |
| Sapo | Trang phần mềm bán hàng online nói về bán trên sàn, quản lý kho, Sapo Express, giảm phí ship và xử lý đơn hàng nhanh hơn. | Nội dung thiên về giải pháp tổng quát; chưa chỉ rõ bảng owner, công thức lệch tiền, return QC và ngưỡng OMS-only vs OMS + WMS. |
| Nhanh.vn | Trang chủ nêu cổng vận chuyển, thu hộ COD toàn quốc, đối soát tự động và chiết khấu cao. | Cụm "đối soát tự động" chưa trả lời cách xử lý đơn tiền đã về nhưng hàng hoàn chưa scan, phí sàn lệch, refund một phần hoặc mã vận đơn đổi trạng thái. |
| Haravan Omnichannel | Trang omnichannel nêu quản lý vận chuyển, kiểm soát giao hàng và thu hộ COD, quản lý thanh toán, thu chi. | Chưa đi sâu vào logic đối soát theo mã đơn, mã vận đơn, phí marketplace, voucher, WMS receiving và hàng đợi ngoại lệ có SLA xử lý. |
| Google/DuckDuckGo search | Truy vấn trực tiếp bị chặn bởi bot challenge trong lần chạy tự động. | Dùng làm giới hạn truy cập; bài viết dựa trên trang công khai truy cập được, nội dung hiện có và kinh nghiệm vận hành dạng công thức minh bạch. |
Thông tin thực thể liên quan
| JST ERP Việt Nam | Đơn vị triển khai ERP/OMS + WMS cho doanh nghiệp ecommerce Việt Nam cần quản lý đơn đa kênh, kho, SKU, barcode, PDA, vận chuyển, COD, hàng hoàn, phí sàn và báo cáo đối soát theo quy trình thật. |
|---|---|
| OMS | Lớp điều phối đơn hàng: giữ mã đơn, mã vận đơn, kênh bán, COD, voucher, phí dự kiến, trạng thái giao, refund, settlement và hàng đợi ngoại lệ tài chính. |
| WMS | Lớp kiểm soát hàng vật lý: picking, checking, packing, scan bàn giao, mã kiện, nhận hàng hoàn, return QC, bin location, tồn chờ xử lý, tồn bán lại và hàng lỗi. |
| Marketplace settlement | File hoặc báo cáo quyết toán từ Shopee, Lazada, TikTok Shop hoặc kênh bán, thường gồm doanh thu, phí, voucher, vận chuyển, refund, bồi thường và tiền thực nhận. |
| Vietnam ecommerce | Môi trường bán đa kênh có COD, nhiều sàn, livestream, social commerce, campaign peak, hàng hoàn cao, voucher phức tạp và nhiều đối tác vận chuyển/3PL. |
Settlement waterfall cần gồm những lớp nào?
Waterfall là cách tách từng khoản làm thay đổi tiền thực nhận của một đơn. Thay vì chỉ nhìn "đơn 500.000 đồng nhưng tiền về 421.000 đồng", doanh nghiệp phải biết 79.000 đồng chênh lệch gồm phí nào, voucher nào, vận chuyển nào, refund nào và khoản nào đang chờ xử lý. Khi mỗi khoản có nguồn dữ liệu và mã lý do, đối soát không còn là đoán.
| Lớp waterfall | Cần ghi nhận | Nguồn chính |
|---|---|---|
| 1. Gross order value | Giá trị hàng bán theo đơn gốc, gồm SKU, combo, quà tặng tính phí nếu có | OMS |
| 2. Shop-funded discounts | Voucher, giảm giá, freeship do shop chịu, hoàn điểm, đổi quyền lợi khách hàng | OMS / campaign data |
| 3. Marketplace and payment fees | Phí sàn, phí thanh toán, phí affiliate, phí dịch vụ, phí xử lý giao dịch | Settlement file |
| 4. Logistics and COD fees | Phí vận chuyển, phụ phí, phí hoàn, phí thu hộ, điều chỉnh trọng lượng/khu vực | Carrier / marketplace settlement |
| 5. Refunds and claims | Refund toàn phần, refund một phần, bồi thường vận chuyển, claim bị từ chối | OMS / marketplace / accounting |
| 6. Net cash received | Tiền thực nhận về tài khoản hoặc ví, theo ngày quyết toán và nguồn thanh toán | Accounting |
| 7. Physical return status | Hàng hoàn đang đi đường, đã về kho, đã QC, nhập lại tồn, hàng lỗi, thiếu phụ kiện | WMS return |
Một công thức kiểm tra đơn giản cho từng đơn là: tiền dự kiến nhận = giá trị hàng bán - voucher do shop chịu - phí sàn - phí thanh toán - phí vận chuyển/phí COD - refund + bồi thường hợp lệ. Nếu tiền thực nhận khác tiền dự kiến, hệ thống phải đưa đơn vào hàng đợi ngoại lệ với reason code, owner và deadline xử lý. Công thức này không thay thế chính sách cụ thể của từng sàn, nhưng giúp doanh nghiệp không gom mọi chênh lệch vào một dòng "phí khác".
Dòng thời gian chuẩn từ đơn đến khóa kỳ
Sai lệch thường xuất hiện vì mỗi bộ phận nhìn một thời điểm khác nhau. Kế toán nhìn ngày tiền về, vận hành nhìn ngày giao thành công, kho nhìn ngày kiện hoàn được scan, CSKH nhìn ngày khách khiếu nại. OMS + WMS cần biến các thời điểm này thành một timeline chung theo mã đơn và mã vận đơn.
| Mốc | Dữ liệu cần khóa | Owner |
|---|---|---|
| Tạo đơn | OMS ghi kênh bán, mã đơn, SKU, giá trị COD hoặc prepaid, voucher và kho dự kiến | Ecommerce / OMS |
| Đóng gói | WMS ghi picking, checking, packing, barcode, mã kiện, trọng lượng nếu cần và ảnh bằng chứng cho nhóm rủi ro | Kho |
| Bàn giao | OMS/WMS ghi mã vận đơn, hãng vận chuyển, thời điểm scan bàn giao, manifest và người bàn giao | Kho + vận chuyển |
| Giao hàng | OMS cập nhật giao thành công, thất bại, chuyển hoàn, đổi trạng thái hoặc giao lại | Operations |
| Quyết toán | Kế toán nhập hoặc đồng bộ file settlement: COD, phí sàn, phí vận chuyển, refund, bồi thường | Kế toán |
| Nhận hoàn | WMS scan mã vận đơn hoàn, kiểm SKU, phụ kiện, tình trạng, QC và trạng thái tồn | Kho return |
| Khóa kỳ | Hệ thống chốt đơn khớp, đơn lệch tiền, đơn lệch hàng, đơn thiếu bằng chứng và owner xử lý tiếp | Finance + operations |
So sánh nhanh theo mức độ vận hành
Không phải doanh nghiệp nào cũng cần WMS đầy đủ ngay từ đầu. Nhưng nếu đối soát đang lệch vì không biết hàng hoàn thật sự đã về kho chưa, không biết SKU hoàn có đủ phụ kiện không, không biết hàng có được nhập lại tồn bán được hay không, thì vấn đề đã vượt khỏi phạm vi OMS-only. Lúc đó, một lớp WMS return là cần thiết để xác nhận hàng vật lý.
| Mô hình | Phù hợp khi | Lợi ích | Rủi ro nếu dùng sai giai đoạn |
|---|---|---|---|
| Excel + Seller Center | Dưới 50-100 đơn/ngày, ít COD, ít hàng hoàn, một người xử lý được toàn bộ ngoại lệ | Rẻ và nhanh lúc đầu | Dễ phát hiện lệch muộn, khó nối hàng hoàn với tiền và khó bàn giao khi nhân sự thay đổi |
| OMS-only | 100-300 đơn/ngày, cần gom đơn đa kênh, mã vận đơn, COD và settlement cơ bản | Khớp đơn, tiền và trạng thái giao tốt hơn | Không đủ khi hàng hoàn cần QC, barcode, nhập lại tồn hoặc nhiều kho/3PL |
| OMS + WMS nhẹ | 300-1.000 đơn/ngày, nhiều SKU, nhiều COD, hàng hoàn tăng, cần scan nhận hoàn và phân loại tồn | Nối tiền với hàng vật lý, giảm tranh luận giữa kho và kế toán | Cần chuẩn hóa reason code, mã vận đơn, khu nhận hoàn và quyền cập nhật trạng thái |
| OMS + WMS đầy đủ | Từ 1.000 đơn/ngày, nhiều kho, 3PL, campaign peak, nhiều phí sàn/voucher/refund/claim | Quản lý waterfall, ngoại lệ, SLA xử lý và báo cáo theo kênh/kho/SKU/carrier | Cần go-live theo dữ liệu thật, đối chiếu nhiều file settlement và đào tạo theo vai trò |
Hàng hoàn phải tách trạng thái tiền và trạng thái hàng
Một đơn hoàn có thể đã được sàn xử lý refund nhưng kiện hàng vẫn chưa về kho. Ngược lại, kho có thể đã nhận kiện hoàn nhưng kỳ settlement tiếp theo mới điều chỉnh tiền. Nếu hệ thống chỉ có một trạng thái "đã hoàn", doanh nghiệp sẽ nhập nhầm tồn, báo cáo sai lợi nhuận hoặc bỏ sót khiếu nại.
Trạng thái tài chính nên gồm: chờ settlement, đã nhận COD, COD thiếu, refund toàn phần, refund một phần, bồi thường chờ xử lý, claim bị từ chối. Trạng thái hàng vật lý nên gồm: return in transit, đã về kho chờ QC, đã QC bán lại, thiếu phụ kiện, hư hỏng, sai SKU, hàng lỗi, chờ nhà cung cấp hoặc chờ xử lý CSKH. Hai nhóm trạng thái này phải được nối với cùng mã đơn/mã vận đơn nhưng không được ép thành một trạng thái duy nhất.
- Tiền về không đồng nghĩa hàng đã về kho.
- Hàng về kho không đồng nghĩa được nhập lại tồn khả dụng.
- Refund không đồng nghĩa hết trách nhiệm vận hành nếu hàng thiếu phụ kiện hoặc carrier làm mất kiện.
- Claim được chấp nhận không đồng nghĩa SKU đã được điều chỉnh đúng giá vốn và tồn kho.
Hàng đợi ngoại lệ cần owner và SLA xử lý
Một hệ thống đối soát tốt không chỉ tìm ra lệch; nó phải biến lệch thành việc có người xử lý. Mỗi loại ngoại lệ cần owner chính, bằng chứng cần kiểm, deadline và trạng thái đóng. Nếu không, ngoại lệ chỉ chuyển từ file Excel sang một danh sách dài trong hệ thống.
| Ngoại lệ | Dấu hiệu | Owner chính | Hành động đầu tiên |
|---|---|---|---|
| Tiền COD thiếu | COD thực nhận thấp hơn COD dự kiến sau khi trừ phí hợp lệ | Kế toán | Kiểm settlement, phí bị trừ, trạng thái giao, refund, claim và cập nhật reason code |
| Phí sàn bất thường | Phí sàn/affiliate/voucher cao hơn rule dự kiến hoặc xuất hiện mã phí mới | Finance + ecommerce | So rule campaign, chính sách kênh, SKU tham gia chương trình và người phê duyệt |
| Tiền đã quyết toán, hàng hoàn chưa về | Settlement ghi refund/return nhưng WMS chưa scan kiện hoàn | Operations + kho | Đưa vào hàng đợi return in transit, theo dõi mã vận đơn hoàn và deadline khiếu nại |
| Hàng hoàn về nhưng tiền chưa xử lý | WMS đã nhận hàng/QC nhưng settlement chưa refund hoặc COD chưa điều chỉnh | Kế toán | Liên kết return QC với đơn gốc, giữ tồn đúng trạng thái và chờ kỳ settlement tiếp theo |
| Hoàn một phần | Khách trả một SKU trong đơn nhiều SKU hoặc thiếu phụ kiện/quà tặng | CSKH + kho | Tách dòng SKU, QC phụ kiện, tính refund một phần và không nhập nhầm toàn bộ đơn về tồn bán được |
| Claim bị từ chối | Carrier/sàn từ chối bồi thường vì thiếu bằng chứng packing, cân nặng hoặc bàn giao | Operations | Truy packing proof, scan handover, manifest, ảnh QC và bổ sung quy trình bằng chứng cho đơn tương tự |
Phân quyền trách nhiệm theo bộ phận
Đối soát COD, phí sàn và hàng hoàn là bài toán liên phòng ban. Nếu chỉ giao cho kế toán, kế toán sẽ thiếu dữ liệu kho. Nếu chỉ giao cho kho, kho không biết phí sàn và refund. Nếu chỉ giao cho CSKH, CSKH không thấy settlement. Vì vậy, mỗi bộ phận cần biết mình sở hữu trường dữ liệu nào.
| Bộ phận | Trách nhiệm dữ liệu |
|---|---|
| Ecommerce team | Mã sản phẩm kênh bán, voucher, campaign, affiliate, chính sách giá và dữ liệu đơn gốc |
| Operations | Trạng thái đơn, SLA xử lý, mã vận đơn, carrier, giao thất bại, giao lại và ngoại lệ liên phòng ban |
| Warehouse team | Picking, checking, packing, scan bàn giao, nhận hàng hoàn, return QC, bin location và tồn khả dụng |
| Accounting | File settlement, COD thực nhận, phí sàn, phí vận chuyển, refund, bồi thường và khóa kỳ |
| CSKH | Lý do hoàn, đổi trả, khiếu nại khách hàng, refund một phần, thiếu phụ kiện và bằng chứng trao đổi |
| Management | Ngưỡng chấp nhận lệch, SLA xử lý ngoại lệ, ưu tiên cải tiến và quyết định OMS-only hay OMS + WMS |
Ví dụ vận hành: đơn 500.000 đồng không khớp tiền
Giả sử một đơn Shopee hoặc TikTok Shop có giá trị hàng 500.000 đồng, khách dùng voucher shop 30.000 đồng, phí sàn và phí thanh toán dự kiến 45.000 đồng, phí vận chuyển shop chịu 18.000 đồng, COD dự kiến về 407.000 đồng. Nếu settlement thực nhận chỉ 360.000 đồng, hệ thống không nên ghi "lệch 47.000 đồng" rồi để kế toán tự tìm. Hệ thống cần hỏi theo thứ tự:
- Đơn có refund một phần hoặc khách trả một SKU trong combo không?
- Voucher 30.000 đồng là shop chịu hay sàn chịu?
- Phí vận chuyển bị điều chỉnh do trọng lượng/khu vực hay do hoàn hàng?
- Phí affiliate hoặc phí campaign có xuất hiện trong settlement nhưng OMS chưa ghi rule không?
- Đơn có hàng hoàn đang đi đường khiến tiền bị giữ tạm không?
- Carrier có bồi thường một phần hoặc từ chối claim vì thiếu bằng chứng không?
Khi trả lời được sáu câu hỏi này bằng dữ liệu, doanh nghiệp biết khoản lệch là phí hợp lệ, lỗi mapping campaign, lỗi cân nặng, refund, hàng hoàn hay claim. Đây là giá trị thực tế của settlement waterfall: không làm phí biến mất, nhưng làm nguyên nhân rõ và giúp đội vận hành sửa đúng điểm.
Những lỗi thường gặp cần sửa
- Chỉ đối soát vào cuối tháng nên khi lệch mới phát hiện thì mã vận đơn, ảnh packing và trạng thái hoàn đã khó truy.
- Gộp phí sàn, phí vận chuyển, voucher và refund thành một cột "phí" khiến không biết khoản nào do chính sách, khoản nào do lỗi vận hành.
- Xem trạng thái marketplace là bằng chứng hàng đã về kho, trong khi hàng hoàn vật lý vẫn chưa được WMS scan và QC.
- Cho hàng hoàn nhập lại tồn bán được ngay khi thấy kiện về mà chưa kiểm SKU, barcode, phụ kiện, tem, serial hoặc tình trạng bao bì.
- Để kho, kế toán và CSKH mỗi bên giữ một file riêng, làm cùng một đơn có ba phiên bản sự thật khác nhau.
- Không định nghĩa owner cho từng loại lệch nên ngoại lệ nằm trong nhóm chat, không có deadline và không có trạng thái đóng.
- Dùng OMS-only quá lâu dù điểm nghẽn thật nằm ở return QC, nhiều kho, PDA, bin location và hàng hoàn thiếu phụ kiện.
Checklist triển khai trong 3-5 bước
- Lấy 30-60 ngày dữ liệu thật: đơn giao thành công, đơn COD, file settlement, phí sàn, phí vận chuyển, refund, hàng hoàn, claim, mã vận đơn và báo cáo tồn sau hoàn.
- Chuẩn hóa khóa nối dữ liệu: mã đơn nội bộ, mã đơn sàn, mã vận đơn, mã kiện, SKU master, barcode, mã kho, trạng thái tài chính và trạng thái hàng vật lý.
- Thiết kế waterfall và reason code: voucher, phí sàn, phí thanh toán, phí ship, phí hoàn, refund, bồi thường, COD thiếu, return in transit, hàng hoàn thiếu phụ kiện.
- Chạy pilot trên nhóm rủi ro cao: đơn COD giá trị cao, đơn nhiều SKU, đơn campaign, đơn hoàn một phần, hàng dễ vỡ, đơn qua 3PL hoặc kênh có nhiều phí/voucher.
- Đặt KPI nghiệm thu: tỷ lệ đơn khớp tự động, số ngoại lệ quá hạn, thời gian xử lý lệch, tỷ lệ hàng hoàn đã QC, giá trị COD thiếu và tỷ lệ phí chưa có mã lý do.
Liên kết nội bộ nên đọc tiếp
Nếu doanh nghiệp đang ở giai đoạn chọn phạm vi hệ thống, hãy xem sản phẩm OMS + WMS để hiểu vai trò từng lớp, giải pháp marketplace đa kênh để gom đơn và tồn từ Shopee, Lazada, TikTok Shop, giải pháp vận hành kho để kiểm soát PDA, barcode, picking, checking, packing và hàng hoàn, bảo đảm dịch vụ để hiểu cách JST ERP đồng hành sau go-live, và FAQ để chuẩn bị câu hỏi trước demo.
Các bài liên quan nên đọc thêm gồm giải pháp đối soát COD, vận chuyển và đơn hoàn, đối soát bồi thường vận chuyển, kiểm soát hàng hoàn thiếu phụ kiện và fulfillment giao trong ngày bằng OMS + WMS.
JSTERP có thể hỗ trợ như thế nào?
JSTERP hỗ trợ doanh nghiệp thiết kế quy trình đối soát COD, phí sàn và hàng hoàn bằng cách nối dữ liệu OMS và WMS trong cùng một luồng. Đơn từ kênh bán đi vào OMS, tồn được giữ đúng, WMS ghi nhận thao tác kho, vận chuyển trả trạng thái, settlement ghi tiền thực nhận, hàng hoàn được scan và QC trước khi quay lại tồn khả dụng.
Đội triển khai JST ERP Việt Nam có thể cùng doanh nghiệp rà soát mẫu file settlement hiện có, quy trình COD, luồng hàng hoàn, danh sách phí thường gặp, vai trò kế toán/kho/CSKH/vận hành và nhóm ngoại lệ gây mất nhiều thời gian nhất. Từ đó, doanh nghiệp có thể bắt đầu bằng OMS nếu điểm đau nằm ở mã đơn và file tiền, hoặc triển khai OMS + WMS nếu điểm đau nằm ở return QC, nhiều kho, barcode, PDA, bin location, 3PL và tồn sau hoàn.