Vì sao phí sàn có thể lệch so với payout thực tế
Trả lời nhanh: Phí trong calculator có thể lệch payout vì calculator mô phỏng theo quy tắc và dữ liệu đầu vào, còn payout phản ánh đơn thực tế sau voucher, trạng thái đơn, điều chỉnh, hoàn/hủy, thời điểm ghi nhận và làm tròn. Muốn tìm nguyên nhân, phải lập cầu nối từng dòng, không chỉ so tổng cuối.
Calculator và payout có phạm vi khác nhau
Calculator thường trả lời trước khi bán:
- giá này có lời không;
- phí dự kiến bao nhiêu;
- CPA có thể chịu tới đâu;
- voucher có quá sâu không.
Payout trả lời sau khi bán:
- nền tảng đã ghi nhận khoản nào;
- khoản nào được hoàn;
- khoản nào bị điều chỉnh;
- tiền được chuyển ở kỳ nào.
Chênh lệch không tự động chứng minh một bên sai.
Bước 1: Xác nhận đang so cùng đối tượng
Kiểm tra:
- cùng order ID;
- cùng item;
- cùng số lượng;
- cùng trạng thái cuối;
- cùng kỳ payout;
- cùng tiền tệ;
- cùng mốc ngày;
- cùng phạm vi voucher và vận chuyển.
Payout thường gộp nhiều đơn, trong khi calculator đang tính một đơn mẫu.
Bước 2: Lập cầu nối từ doanh thu tới payout
Một bảng cầu nối có thể gồm:
- Giá sản phẩm.
- Voucher shop chịu.
- Khoản hoàn hoặc giảm sau bán.
- Phí cơ bản.
- Phí giao dịch.
- Phí dịch vụ.
- Hỗ trợ vận chuyển.
- Thuế/VAT của phí nếu tách dòng.
- Điều chỉnh.
- Payout.
Quảng cáo, KOC hoặc chi phí ngoài sàn có thể không nằm trong payout. Chúng vẫn phải trừ khi tính lợi nhuận nhưng không nên đưa vào cầu nối payout nếu nền tảng ghi ở báo cáo khác.
Những nguồn lệch thường gặp
Sai ngày hiệu lực
Calculator dùng quy tắc mới cho đơn cũ hoặc ngược lại.
Sai phạm vi
Sai ngành, loại shop hoặc chương trình.
Voucher
Nhập sai phần shop chịu hoặc trừ hai lần.
Hoàn/hủy
Đơn thay đổi trạng thái sau lần tính đầu.
Cách làm tròn
Nền tảng làm tròn từng dòng, còn calculator làm tròn tổng cuối.
Cap
Phí bị giới hạn nhưng calculator chưa áp hoặc áp sai thứ tự.
Điều chỉnh theo kỳ
Payout có bù trừ từ đơn khác hoặc kỳ trước.
Ví dụ cầu nối
Ví dụ giả định.
- giá sản phẩm: 300.000đ;
- voucher shop chịu: 15.000đ;
- phí cơ bản: 20.000đ;
- phí giao dịch: 6.000đ;
- phí dịch vụ: 9.000đ;
- điều chỉnh: 1.000đ.
Payout giả định:
300.000 − 15.000 − 20.000 − 6.000 − 9.000 − 1.000 = 249.000đ
Nếu calculator ra 250.000đ, dòng cần tìm là điều chỉnh 1.000đ, không phải sửa tỷ lệ cho khớp tổng.
Sau payout, lợi nhuận còn phải trừ giá vốn, quảng cáo và các chi phí ngoài nền tảng.
Không tạo “phí khác” để ép khớp
Một dòng bù chênh lệch có thể hữu ích tạm thời khi phân tích, nhưng không nên được lưu như quy tắc sản xuất nếu chưa biết nguyên nhân.
Ép tổng khớp sẽ:
- che lỗi phạm vi;
- che double count;
- làm quy tắc sai cho đơn khác;
- tạo cảm giác settlement_verified giả.
Tolerance cần được giải thích
Nếu mục tiêu là calculator tham khảo, chênh lệch nhỏ do rounding có thể chấp nhận được khi được công khai. Nếu mục tiêu là khớp từng đồng, tolerance phải bằng contract cụ thể và được test.
Không dùng một con số tolerance chung cho mọi fee type.
Policy_verified và settlement_verified
Policy_verified
- nguồn, tỷ lệ, ngày hiệu lực và phạm vi rõ;
- fail closed;
- test/validate/giao diện QA pass;
- đủ công khai phạm vi hẹp;
- không cam kết payout.
Settlement_verified
- có fixture payout;
- so từng fee;
- so tổng phí;
- so payout;
- biết rounding;
- tolerance có giải thích;
- chỉ đúng cho phạm vi đã kiểm chứng.
Không tự nâng từ policy_verified lên settlement_verified chỉ vì vài đơn “gần khớp”.
Nên lưu hồ sơ chênh lệch thế nào
Mỗi ca đáng điều tra nên lưu tối thiểu:
- mã đơn đã ẩn danh nếu cần;
- ngày và trạng thái;
- loại shop, ngành, chương trình;
- dữ liệu calculator;
- từng dòng bảng kê;
- chênh lệch;
- giả thuyết nguyên nhân;
- nguồn đã kiểm tra;
- kết luận;
- có cần sửa quy tắc hay chỉ sửa dữ liệu đầu vào.
Một vài đơn lệch vì điều chỉnh riêng không đủ để thay policy. Ngược lại, nhiều đơn cùng phạm vi lệch theo một mẫu là tín hiệu cần review. Hồ sơ này giúp phân biệt lỗi dữ liệu, lỗi engine và sự kiện riêng của đơn.
Hành động khi thấy lệch
- Dừng mở rộng nếu chênh lệch làm sản phẩm từ lãi thành lỗ.
- Dùng kiểm tra phí một đơn.
- So từng dòng.
- Kiểm tra ngày và phạm vi.
- Kiểm tra khoản nằm ngoài payout.
- Cập nhật giả định, không sửa dữ liệu phí nếu chưa có bằng chứng.
- Ghi lại mẫu để phục vụ reconciliation sau này.
Đọc thêm cách đọc breakdown phí và ngày hiệu lực phí sàn.
Câu hỏi thường gặp
Lệch so với payout có nghĩa calculator sai không?
Không nhất thiết. Có thể khác phạm vi, thời điểm, voucher, trạng thái đơn, điều chỉnh hoặc cách làm tròn. Cần so từng dòng.
Muốn kiểm tra lệch thì bắt đầu từ đâu?
Xác nhận cùng đơn và cùng kỳ, sau đó lập cầu nối từ doanh thu tới payout theo từng khoản khấu trừ.
Có nên dùng payout một đơn để suy công thức cho mọi đơn không?
Không. Một đơn có thể có ngành, chương trình, voucher hoặc điều chỉnh riêng.
Quảng cáo có luôn nằm trong payout không?
Không. Tùy nền tảng và cách thanh toán, quảng cáo có thể ở bảng kê khác. Cần tránh trừ hai lần.
Chênh lệch bao nhiêu là chấp nhận được?
Không có một tolerance chung. Mức chấp nhận phải gắn với cách làm tròn, mục tiêu sử dụng và bằng chứng settlement.
Khi nào được gọi là settlement_verified?
Khi từng dòng phí, tổng khấu trừ, payout và quy tắc làm tròn đã được đối chiếu bằng fixture phù hợp trong phạm vi cụ thể.