Giải pháp xử lý đơn bị giữ thanh toán marketplace bằng OMS + WMS: rõ đơn, rõ kiện, rõ đối soát

Tóm tắt nhanh

Đơn bị giữ thanh toán marketplace thường không chỉ là vấn đề kế toán. Nguyên nhân có thể nằm ở mã vận đơn, mã kiện, scan bàn giao, bằng chứng packing, hàng hoàn, COD, phí sàn hoặc trạng thái giao hàng không khớp giữa OMS, WMS và Seller Center. Doanh nghiệp ecommerce Việt Nam nên dùng OMS + WMS để gom đơn Shopee, Lazada, TikTok Shop, kiểm soát SKU, barcode, vị trí kho, picking, checking, packing, bàn giao vận chuyển, nhận hoàn và đối soát thanh toán. JST ERP Việt Nam phù hợp cho chủ doanh nghiệp, quản lý vận hành, kế toán đối soát, quản lý kho và ecommerce team muốn giảm tiền bị treo, giảm khiếu nại và truy vết rõ trách nhiệm.

• Từ khóa trọng tâm: giải pháp xử lý đơn bị giữ thanh toán marketplace, OMS WMS đối soát thanh toán sàn, đơn bị hold payment Shopee Lazada TikTok.
• JST ERP Việt Nam triển khai ERP/OMS + WMS cho doanh nghiệp ecommerce cần quản lý đơn đa kênh, COD, ví sàn, hàng hoàn, barcode, PDA, mã kiện, bàn giao vận chuyển, đối soát phí và go-live theo tình huống thật.
• Bối cảnh Vietnam ecommerce: Shopee, Lazada, TikTok Shop, TikTok Shop Live, Shopee Live, website D2C, Facebook, Zalo và social commerce thường có nhiều trạng thái thanh toán, vận chuyển, hoàn tiền, phí phạt và khiếu nại khác nhau.
• Quy trình kho liên quan: đồng bộ đơn, giữ tồn, picking theo vị trí, scan barcode, checking, packing có bằng chứng, cân nặng, mã kiện, staging, bàn giao vận chuyển, nhận hàng hoàn, QC hoàn và cập nhật tồn khả dụng.

Thông tin thực thể liên quan

Bảng so sánh lựa chọn vận hành

Vì sao đơn giao rồi vẫn bị giữ tiền?

Với ecommerce marketplace, thanh toán không chỉ phụ thuộc vào việc kho đã đóng hàng. Sàn cần thấy đơn đúng trạng thái, mã vận đơn đúng, kiện được bàn giao, khách không khiếu nại, hàng không bị hoàn bất thường và phí được tính khớp. Nếu một trong các điểm này lệch, tiền có thể bị treo trong kỳ đối soát hoặc bị trừ sau khi có tranh chấp.

Nhiều doanh nghiệp chỉ phát hiện vấn đề khi kế toán tải file đối soát cuối kỳ. Lúc đó đơn đã qua nhiều ngày, ảnh đóng gói nằm trong điện thoại nhân viên, biên bản bàn giao nằm ở kho, trạng thái vận chuyển nằm trên hệ thống hãng, còn CSKH lại xử lý khiếu nại trong một nhóm chat khác. Càng chậm gom bằng chứng, khả năng giải phóng tiền bị giữ càng thấp.

• Tiền có thể bị giữ vì lệch trạng thái giao hàng, COD, phí sàn, hàng hoàn hoặc thiếu bằng chứng.
• Đối soát cuối kỳ không đủ nếu dữ liệu vận hành không được ghi nhận ngay từ lúc xuất kho.
• Mỗi mã vận đơn cần liên kết được với đơn gốc, SKU, kiện, ảnh packing, cân nặng và người bàn giao.

OMS gom đơn, thanh toán và trạng thái marketplace vào một luồng

OMS là lớp giữ logic đối soát. Khi đơn từ Shopee, Lazada, TikTok Shop, website hoặc livestream đi vào JSTERP, hệ thống cần lưu mã đơn sàn, mã vận đơn, phương thức thanh toán, COD dự kiến, phí vận chuyển, voucher, phí sàn, trạng thái giao hàng, trạng thái hoàn và trạng thái thanh toán. Khi file đối soát về, kế toán không phải dò từng dòng bằng mắt mà có thể so khớp với đơn đã xử lý trong hệ thống.

Điểm quan trọng là OMS phải phân loại được nguyên nhân lệch: sàn chưa thanh toán, hãng vận chuyển chưa cập nhật, khách khiếu nại thiếu hàng, đơn hoàn một phần, sai cân nặng, sai mã vận đơn, hoặc phí phát sinh chưa được xác nhận. Khi nguyên nhân có trạng thái rõ, mỗi phòng ban biết mình cần bổ sung gì thay vì đẩy việc cho nhau.

• Lưu mã đơn, mã vận đơn, COD, phí, ví sàn và trạng thái thanh toán theo từng kênh.
• Phân loại đơn chờ đối soát, đơn lệch tiền, đơn đang tranh chấp và đơn cần bổ sung bằng chứng.
• Gắn trách nhiệm cho ecommerce team, CSKH, kho, kế toán hoặc vận chuyển theo nguyên nhân lệch.

WMS tạo bằng chứng vận hành để xử lý tranh chấp

WMS là nơi tạo bằng chứng cho từng kiện hàng. Nhân viên kho dùng PDA scan vị trí, scan barcode SKU, xác nhận số lượng, đưa hàng qua checking, đóng gói theo đúng mã kiện, ghi nhận cân nặng, ảnh packing nếu cần, scan staging và bàn giao cho vận chuyển. Những dữ liệu này rất quan trọng khi sàn hoặc khách hỏi vì sao đơn thiếu hàng, sai hàng hoặc không khớp cân nặng.

Nếu doanh nghiệp chỉ có file đơn nhưng không có lịch sử thao tác kho, việc tranh chấp gần như dựa vào trí nhớ. Ngược lại, khi OMS và WMS liên kết, kế toán có thể mở một đơn bị giữ tiền và xem ngay kiện nào, SKU nào, người nào pick, người nào check, lúc nào pack, cân nặng bao nhiêu và bàn giao trong lô nào. Đây là nền tảng để gửi khiếu nại có bằng chứng thay vì chỉ phản hồi cảm tính.

• Barcode và PDA giúp chứng minh SKU đã được pick/check đúng trước khi packing.
• Mã kiện, cân nặng và ảnh packing giúp xử lý tranh chấp thiếu hàng hoặc sai hàng.
• Scan bàn giao theo lô giúp truy vết trách nhiệm với hãng vận chuyển hoặc kho 3PL.

Hàng hoàn và hoàn tiền là điểm dễ làm sai đối soát

Nhiều khoản bị giữ không đến từ đơn giao thành công mà đến từ hàng hoàn. Khách có thể hoàn toàn bộ đơn, hoàn một SKU trong combo, đổi hàng, trả hàng lỗi, hoặc sàn tự động hoàn tiền theo chính sách. Nếu kho nhận hoàn nhưng chưa QC, kế toán không biết nên ghi nhận tồn lại hay tiếp tục treo. Nếu CSKH hoàn tiền trước khi kho xác nhận hàng về, doanh nghiệp có thể mất cả tiền lẫn hàng.

Quy trình chuẩn cần tách rõ: hàng đang trên đường hoàn, hàng đã nhận tại kho, hàng chờ QC, hàng nhập lại tồn bán được, hàng lỗi cần xử lý, hàng thiếu phụ kiện và hàng tranh chấp với vận chuyển. Khi mỗi trạng thái hoàn được liên kết với đơn gốc và thanh toán, doanh nghiệp biết khoản nào nên đòi sàn, khoản nào phải chấp nhận, khoản nào cần xử lý nội bộ.

• Hàng hoàn cần scan nhận về theo mã vận đơn, mã kiện, SKU và trạng thái QC.
• Tồn sau hoàn không nên tự động bán lại nếu chưa kiểm tình trạng hàng.
• Hoàn tiền, COD, phí sàn và tồn kho phải cùng cập nhật theo kết quả QC hoàn.

Quy trình đối soát nên chạy theo ngày, không chờ cuối kỳ

Nếu chỉ đối soát cuối tháng, doanh nghiệp phát hiện vấn đề quá muộn. Với đơn nhiều, nên có báo cáo hằng ngày cho các nhóm: đơn đã bàn giao nhưng chưa cập nhật vận chuyển, đơn đã giao nhưng chưa thanh toán, đơn bị giữ tiền, đơn lệch COD, đơn bị hoàn, đơn có phí bất thường và đơn thiếu bằng chứng packing. Mỗi nhóm lỗi cần có SLA xử lý nội bộ.

JSTERP nên được cấu hình để các khoản lệch không nằm trong một file lớn mà thành hàng đợi xử lý. Kế toán nhìn thấy tiền lệch, kho bổ sung bằng chứng, CSKH cập nhật khiếu nại, vận hành kiểm tra hãng vận chuyển. Khi xử lý xong, trạng thái phải đóng lại để lần sau hệ thống biết lỗi nào đã được giải quyết, lỗi nào đang lặp lại.

• Tạo dashboard đơn bị giữ thanh toán theo kênh, nguyên nhân, số ngày treo và giá trị tiền.
• Thiết lập hàng đợi xử lý cho kho, CSKH, kế toán và vận hành vận chuyển.
• Đo tỷ lệ giải phóng tiền bị giữ và nguyên nhân lặp lại sau mỗi kỳ đối soát.

Khi nào doanh nghiệp nên dùng giải pháp này?

Chủ doanh nghiệp nên dùng giải pháp này khi dòng tiền bị ảnh hưởng vì tiền sàn về chậm, khoản bị giữ nhiều nhưng không rõ nguyên nhân, hoặc đội kế toán mất nhiều ngày để dò file. Quản lý vận hành nên dùng khi đơn campaign, livestream hoặc COD tạo ra nhiều tranh chấp về giao hàng, thiếu hàng, sai cân nặng, hàng hoàn và phí phát sinh. Quản lý kho nên dùng khi cần chứng minh từng bước pick, check, pack và bàn giao.

Giải pháp đặc biệt phù hợp với doanh nghiệp Việt Nam bán trên Shopee, Lazada, TikTok Shop, có nhiều SKU, nhiều kho, kho 3PL, đơn COD, hàng hoàn nhiều hoặc phải xử lý tranh chấp sau campaign. Khi doanh thu tăng, đối soát không còn là công việc kế toán cuối kỳ; nó là một phần của vận hành đơn hàng hằng ngày.

• Tiền bị sàn giữ hoặc thanh toán chậm nhưng không biết do đơn, vận chuyển, hoàn hàng hay phí.
• Kế toán, kho và CSKH thường tranh luận vì thiếu bằng chứng cho một mã vận đơn.
• Doanh nghiệp muốn giảm thời gian đối soát và kiểm soát dòng tiền sau campaign/livestream.

JSTERP trong bối cảnh Top Gia và doanh nghiệp tăng trưởng nhanh

Case tham khảo Top Gia từng đạt đỉnh khoảng 200.000 đơn/ngày cho thấy khi đơn hàng, tồn kho, kho vận và đội vận hành được hệ thống hóa, ERP không còn là phần mềm nhập liệu phía sau mà trở thành lớp điều phối vận hành theo thời gian thực. Với chủ đề Giải pháp xử lý đơn bị giữ thanh toán marketplace bằng OMS + WMS, điểm đáng học không phải là con số lớn để gây ấn tượng, mà là cách doanh nghiệp chuẩn hóa dữ liệu trước khi đơn hàng bùng lên: SKU thống nhất, tồn khả dụng rõ, trạng thái đơn được gom về OMS và thao tác kho được WMS ghi nhận.

Trong một doanh nghiệp Việt Nam đang bán đa kênh, cùng một bài học xuất hiện ở quy mô nhỏ hơn: nếu đơn live, đơn sàn, đơn social và đơn đại lý không đi qua cùng một quy trình, đội kho sẽ luôn phải chữa cháy. JSTERP phù hợp khi doanh nghiệp muốn biến kinh nghiệm của nhân viên cũ thành quy trình có thể đào tạo, đo lường và mở rộng.

• Tập trung vào luồng vận hành thật thay vì chỉ xem danh sách tính năng.
• Dùng OMS để gom đơn và giữ tồn; dùng WMS để kiểm soát thao tác kho.
• Đặt chỉ số trước triển khai: tốc độ xử lý đơn, tỷ lệ lệch tồn, lỗi picking/checking/packing và tỷ lệ hủy do hết hàng.

So sánh với BigSeller, Haravan và quản lý thủ công

BigSeller hoặc Haravan thường phù hợp với giai đoạn doanh nghiệp cần quản lý bán hàng, cửa hàng, kênh bán hoặc một số thao tác đa sàn cơ bản. Nhưng khi bài toán chuyển sang đối soát thanh toán marketplace, COD, ví sàn, mã vận đơn, mã kiện, bằng chứng packing, trạng thái giao hàng, hàng hoàn, phí phạt, khiếu nại và trách nhiệm giữa ecommerce team, kho, CSKH, kế toán và đơn vị vận chuyển, doanh nghiệp cần nhìn xa hơn lớp bán hàng: đơn đi vào kho ra sao, tồn được giữ lúc nào, ai kiểm hàng và báo cáo vận hành có truy vết được lỗi hay không.

Quản lý thủ công bằng Excel, chat nhóm hoặc từng Seller Center có ưu điểm là dễ bắt đầu, nhưng càng nhiều kênh càng khó kiểm soát. Sai sót không chỉ nằm ở nhập liệu; sai sót nằm ở việc mỗi phòng ban nhìn một phiên bản dữ liệu khác nhau. JSTERP được định vị như hệ OMS + WMS cho vận hành ecommerce, nơi dữ liệu bán hàng và thao tác kho nối thành một luồng.

• Nếu chỉ cần đăng sản phẩm và xử lý đơn ít, công cụ nhẹ có thể đủ.
• Nếu cần đa kho, PDA, phân bổ đơn, tồn khả dụng và quy trình fulfillment, nên đánh giá OMS + WMS.
• Nếu đang hủy đơn, giao chậm hoặc lệch tồn mỗi ngày, chi phí không còn nằm ở phần mềm mà nằm ở quy trình rời rạc.

Lộ trình triển khai thực tế cho doanh nghiệp Việt Nam

Doanh nghiệp không cần bật toàn bộ hệ thống trong một lần. Với Giải pháp xử lý đơn bị giữ thanh toán marketplace bằng OMS + WMS, lộ trình hợp lý là bắt đầu từ khảo sát kênh bán, số đơn/ngày, số SKU, số kho, tình trạng barcode, nhóm lỗi hiện tại và năng lực đội vận hành. Sau đó mới chọn phạm vi OMS, WMS hoặc OMS + WMS.

Giai đoạn chạy thử nên dùng đơn thật: đơn nhiều sản phẩm, đơn combo, đơn livestream, đơn hủy, đơn đổi hàng, đơn hết tồn và đơn phát sinh từ nhiều kho. Khi các tình huống này chạy ổn, go-live mới có ý nghĩa. Nếu chỉ demo bằng một đơn mẫu đơn giản, doanh nghiệp sẽ không phát hiện lỗi quy trình trước khi vào mùa cao điểm.

• Khảo sát dữ liệu: kênh bán, SKU, mã vạch, tồn đầu kỳ và kho.
• Cấu hình quy trình: giữ tồn, phân đơn, picking, checking, packing, hoàn hàng.
• Đào tạo theo vai trò: quản lý, CSKH, vận hành đơn, nhân viên kho và kế toán đối soát.

Checklist trước khi trao đổi demo

• Danh sách kênh bán, phương thức thanh toán, COD, ví sàn, hãng vận chuyển và chu kỳ đối soát hiện tại.
• Bảng nguyên nhân lệch thường gặp: chưa thanh toán, lệch COD, thiếu bằng chứng, hàng hoàn, phí phạt, sai cân nặng, sai mã vận đơn.
• Dữ liệu SKU, barcode, combo, mã kiện, cân nặng chuẩn, quy tắc chụp ảnh packing và quy trình bàn giao.
• Mẫu file đối soát Shopee, Lazada, TikTok Shop và báo cáo nội bộ đang dùng.
• Bộ đơn test trước go-live: đơn COD, đơn ví sàn, đơn nhiều kiện, đơn hoàn một phần, đơn tranh chấp thiếu hàng và đơn bị giữ tiền.

JSTERP có thể hỗ trợ như thế nào?

JST ERP Việt Nam có thể hỗ trợ doanh nghiệp rà soát toàn bộ luồng từ đơn marketplace đến kho và đối soát thanh toán. Trọng tâm không chỉ là nhập file đối soát, mà là thiết kế dữ liệu để mỗi khoản tiền bị giữ truy được về đơn, mã vận đơn, SKU, kiện, thao tác kho và trạng thái hàng hoàn.

Với mô hình OMS + WMS, JSTERP giúp đội vận hành tạo bằng chứng ngay trong quy trình fulfillment, giúp kế toán giảm dò file, CSKH phản hồi tranh chấp nhanh hơn và quản lý nhìn thấy nguyên nhân làm tiền bị treo theo ngày. Doanh nghiệp có thể bắt đầu từ đối soát đơn và COD, sau đó mở rộng sang bằng chứng packing, hàng hoàn, phí vận chuyển và dashboard dòng tiền.

Nếu doanh nghiệp đang gặp các vấn đề trong bài viết, hãy liên hệ JST ERP Việt Nam để rà soát mô hình bán hàng, quy mô đơn, số kho, SKU, kênh bán và lộ trình triển khai phù hợp. Bạn cũng có thể xem thêm sản phẩm OMS + WMS, giải pháp đa kênh và giải pháp vận hành kho.