Zalo Icon
Zalo Icon

Câu chuyện thành công

Resources > Case Study > 6> Dian Xiao Er’s multi-source sales reconciliation, automated with an AI agent

Dian Xiao Er tự động hóa đối soát doanh thu đa nguồn bằng AI Agent

Dian Xiao Er (DxR) — tập đoàn F&B đa cửa hàng tại Singapore — đang cùng AFusion triển khai giải pháp AI Agent tự động hóa đối soát doanh thu bán hàng hằng ngày trên bốn nguồn dữ liệu độc lập: báo cáo POS, báo cáo store, báo cáo kênh thanh toán của merchant và báo cáo ứng dụng PMS. Thiết kế hai đội đã thống nhất trong phạm vi công việc: đối soát waterfall hai tầng với dung sai bằng 0 (lệch 0,01 là mismatch), một file tracker Excel cho mỗi cửa hàng mỗi ngày bán hàng, con người duyệt trước khi nhập, và nhập vào SAP Business One qua tự động hóa màn hình. Hệ thống được xây để xử lý tới 100 lượt đối soát cửa hàng mỗi ngày trên tập đối tác, với thời gian xử lý kỳ vọng nằm trọn trong khung giờ ban đêm và kết quả sẵn sàng cho việc review lúc 8 giờ sáng mỗi ngày.

Vì sao đối soát doanh thu đa cửa hàng là bài toán khó

Mỗi ngày bán hàng, một cửa hàng DxR tạo ra câu chuyện doanh thu được kể bởi bốn hệ thống khác nhau:
  • Báo cáo POS ghi nhận những gì quầy thu ngân đã bắn.
  • Báo cáo store (từ cổng PMS) là những gì cửa hàng báo lên.
  • Báo cáo kênh merchant đến từ các đơn vị thanh toán — tiền thẻ và NETS mà ngân hàng thực sự đã chuyển.
  • Báo cáo ứng dụng PMS phủ các đơn đặt qua app gọi món.
Bốn hệ thống là bốn cơ hội lệch nhau. Doanh thu khớp ở quầy vẫn có thể lệch ở tiền về: một khoản settlement của kênh thanh toán về thiếu, một khoản discount được mã hóa khác ở downstream, một phương thức thanh toán có ở báo cáo này nhưng không ở báo cáo kia. Đối soát thủ công nghĩa là tải bốn loại báo cáo cho từng cửa hàng, căn chỉnh từng dòng, và truy từng đồng chênh lệch — ngày nào cũng vậy, cửa hàng nào cũng vậy.
AFusion x DxR case study - manual process carried the classic failures
Quy trình thủ công trước đây của DxR mang các vấn đề kinh điển:
  • Khối lượng Tối đa 100 cửa hàng hoạt động mỗi ngày, mỗi nơi một bộ đối soát đầy đủ.
  • Dữ liệu bất đối xứng Không phải nguồn nào cũng mang đủ phương thức thanh toán; phí thẻ chỉ tồn tại phía merchant; ví điện tử FomoPay (Alipay, PayNow, ShopeePay, WeChat) được đối soát mà không có dòng debit/credit.
  • Lệch âm thầm. Việc làm tròn nhanh 0,01 có thể vô tình xảy ra với một nhân sự mệt mỏi nào đó trong nhóm luôn phải làm những nhiệm vụ lặp lại mang tính bào mòn, nhưng từ đó lại dẫn đến "control failure".
  • Áp lực nhập sổ. Số đã đối soát vẫn phải đưa vào SAP Business One chính xác, từng journal một, nếu không sẽ dẫn đến một bản sổ cái bị rối tung.

DxR và AFusion đã thống nhất hệ thống phải làm gì

Phạm vi công việc nêu rõ thiết kế mục tiêu: thu bốn báo cáo hằng ngày, trích xuất phần dữ liệu mà công đoạn đối soát cần, chạy khớp hai tầng — xác nhận doanh thu trước, xác nhận tiền về sau — xuất file tracker từng cửa hàng để review, và chỉ nhập vào SAP Business One những bản ghi đã được duyệt; tất cả chạy trên chung một robot và trong cùng vùng an ninh với hệ thống nhập liệu hóa đơn AP (Phase 1), dữ liệu không rời khỏi DxR và không cần API SAP.

Đối soát waterfall hai tầng vận hành

Tầng 1 — xác nhận doanh thu: POS với Store

Tầng đầu giải quyết một câu hỏi: quầy và cửa hàng có khớp nhau về những gì đã bán không? Báo cáo POS và báo cáo store được so từng dòng, từng phương thức thanh toán. Cùng với luật tuyệt đối: không dung sai — lệch 0,01 ghi nhận là Mismatchedcả hai ô đều highlight, kèm ghi chú cụ thể. Những dòng khớp thì tự đóng, còn dòng nào lệch thì thông báo và chờ con người.

Tầng 2 — xác nhận tiền: Store với Merchant và PMS

Tầng hai đi theo dòng tiền. Số thu theo báo cáo store được so với báo cáo kênh merchant và báo cáo ứng dụng PMS. Khi ba nguồn cùng phủ một dòng, từng cặp một đều được so: hai nguồn khớp và một nguồn lệch vẫn tính là Difference, ba nguồn ba số cũng vậy. Một số dòng sẽ có logic riêng theo nguồn:
  • Dòng tiền mặt được tính chứ không chép: tổng thu tiền mặt trừ service charge trừ GST đầu ra cộng card DBS, tính độc lập phía store và phía POS.
  • Phí thẻ (AMEX, DBS) chỉ tồn tại trên báo cáo kênh merchant — hệ thống biết để không tìm ở nơi khác.
  • Ví FomoPay (Alipay, PayNow, ShopeePay, WeChat) được cộng gộp và đối soát không debit/credit, đúng cách DxR hạch toán.
  • Dòng theo mapping phân bổ vào tài khoản GL/BP qua file mapping do khách hàng duy trì cùng AF; dòng không có mapping được ghi rõ "no mapping" chứ không đoán.

File tracker: một nguồn sự thật cho mỗi cửa hàng mỗi ngày

Sau mỗi lượt khớp, agent sinh một tracker đối soát cho từng cửa hàng và ngày bán — mã tên cửa hàng, ngày bán, tài khoản GL/BP, bốn giá trị nguồn đặt cạnh nhau, debit/credit/base, trạng thái (Mismatched → Approved/Rejected → Posted), số journal voucher và journal entry sau khi nhập, kèm link thẳng tới file báo cáo nguồn trên Dropbox. Với quy tắc dữ liệu thiếu được quy định rõ: nếu hoàn toàn không có dữ liệu thì để trống; còn những ô trống trong file nguồn thì tính bằng 0.

Con người vẫn là người duyệt cuối — thiết kế đảm bảo sự kiểm soát an toàn

Trong mỗi ngày khớp, tracker được đưa vào thư mục Pending của từng cửa hàng. 8h sáng, PIC nhận email thông báo kèm bản tóm tắt và link; khung review chạy tới 12h. PIC kiểm tra nhanh các ô được đánh dấu, sửa những gì dữ liệu nguồn giải thích được, rồi chuyển file đã duyệt sang Reviewed — reject/approve. Sau khi con người xử lý lại một file được đánh dấu, agent sẽ ghi đè kết quả cũ bằng kết quả mới nhất để đảm bảo tại mọi thời điểm chỉ tồn tại đúng một sự thật duy nhất cho mỗi cửa hàng/ngày.

AFusion x DxR case study - Human review stays in the loop, by design

Nhập SAP Business One: chỉ những gì con người đã duyệt

Mỗi 8 giờ, agent quét thư mục Reviewed và nhập các file đã duyệt vào SAP Business One qua tự động hóa màn hình, ghi ngược số journal voucher và journal entry vào tracker trước khi chuyển file sang Posted. Các lớp bảo vệ quanh bước nhập nói rõ: debit khác credit thì file quay về Pending thay vì nhập; SAP gián đoạn thì công việc xếp hàng, thử lại mỗi 30 phút trong 4 giờ rồi mới báo cáo; với dòng số tiền bằng 0 bỏ qua việc tạo journal; và file bị reject thì không bao giờ được nhập.

Khâu thu thập và trích xuất: chuẩn bị cho thực tế hằng ngày

Bốn nguồn đến theo bốn cách khác nhau, nên tầng thu thập không giả định điều gì. Đăng nhập cổng lỗi thì thử lại ba lần trước khi báo động; báo cáo chưa xuất bản thì nhịp 8 giờ sau sẽ lấy; thiếu file merchant thì ghi log và báo DxR tải lên, các dòng liên quan đánh dấu unmatched chứ không tự phỏng đoán. Trích xuất lỗi thì thử lại ba lần; cửa hàng không định dạng được sau ba lần thì đánh dấu lại cho con người kiểm tra, không gán cứng vào cửa hàng sai.

Hệ thống được xây để đạt điều gì

Các yêu cầu đã thống nhất xác định rõ phạm vi hiệu suất: các đợt đối soát hoàn thành trong khung thời gian ban đêm (từ 19h-8h) vào các ngày đối soát, xử lý tối đa 100 lượt đối soát cửa hàng mỗi ngày cho mỗi đợt chạy, thu thập báo cáo từ cả bốn nguồn trong chu kỳ 8 giờ hàng ngày, và đối soát khớp chính xác 100% với tỷ lệ dương tính giả bằng không. Các đợt ghi sổ chạy theo đúng chu kỳ 8 giờ (vốn đang xử lý các hóa đơn phải trả (AP) của DxR), nhờ đó cỗ máy robot dùng chung có thể đan xen khối lượng công việc mới này vào quy trình đã được kiểm chứng — quy trình ở Phase 1 mà AI agent chạy song song

Bài toán vận hành đáng chú ý: với 100 cửa hàng, mỗi ngày, mỗi giờ vòng lặp đối soát tự động tiết kiệm được đồng nghĩa với từng ấy thời gian được trả lại cho kế toán để tập trung điều tra các chênh lệch thay vì phải loay hoay tổng hợp bảng tính.

Đối soát doanh thu của bạn vẫn là việc của bảng tính?

Nếu việc chốt sổ mỗi ngày đồng nghĩa với việc một nhân viên phải tải xuống bốn loại báo cáo và một nhân viên khác phải kiểm tra lại tổng số tiền, thì giới hạn ở đây không nằm ở sự siêng năng — mà nằm ở cấu trúc được thiết kế trong quy trình này. AFusion phối hợp cùng các đội ngũ tài chính để vạch ra cấu trúc tối ưu — gồm những nguồn nào tồn tại, dữ liệu nào phải khớp nhau, ai phê duyệt phần nào — đồng thời chỉ ra cách một AI agent (với khả năng đối soát tuyệt đối không dung sai và quy trình ghi sổ kiểm soát bằng phê duyệt) có thể biến công việc vất vả hàng ngày thành một buổi sáng rà soát nhẹ nhàng.

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

Đối soát doanh thu đa nguồn là gì?

So cùng một ngày doanh thu giữa các hệ thống ghi nhận nó — POS, báo cáo store/PMS, báo cáo settlement của kênh thanh toán và app đặt món — để số bán và tiền về khớp nhau trước khi nhập vào ERP.

 

Vì sao đối soát doanh thu lại dung sai bằng 0?

Vì ngưỡng dung sai là chính sách về tiền, không phải về dữ liệu. Dự án này nêu rõ luật: lệch 0,01 là mismatch, highlight kèm số chênh. Hệ thống trình mọi khoảng hở; con người quyết định nó có ý nghĩa gì. Cách đó giữ những dịch chuyển nhỏ không bị làm tròn mất trước khi ai kịp thấy.

 

Phí thanh toán và ví điện tử xử lý thế nào?

Phí xử lý thẻ (AMEX, DBS) lấy riêng từ báo cáo kênh merchant vì không nguồn nào khác chứa nó. Khoản thu ví điện tử (Alipay, PayNow, ShopeePay, WeChat) được đối soát theo nhóm cộng gộp, không dòng debit/credit, khớp với cách hạch toán của khách hàng.

 

Trước khi vào SAP có ai duyệt không?

Có — đó là control lõi. Kết quả khớp nằm ở thư mục Pending; PIC xem, sửa, duyệt bằng cách chuyển file sang Reviewed; chỉ khi đó agent mới nhập vào SAP Business One và ghi số journal ngược lại tracker. Cân thử không cân (debit ≠ credit) thì file về Pending thay vì nhập.

Comments are closed.