Settlement và Reconciliation khác nhau thế nào trong EWA?

Settlement và Reconciliation là hai lớp liên quan nhưng khác mục đích. Trong kiến trúc EWA, Settlement tập trung vào việc hoàn tất và ghi nhận kết quả tài chính của giao dịch hoặc kỳ quyết toán; Reconciliation tập trung vào việc so sánh các nguồn độc lập để xác nhận rằng công, giao dịch ngân hàng và payroll đang cùng ghi nhận một kết quả.

Trước hết: cùng liên quan đến tiền nhưng trả lời hai câu hỏi khác nhau

Hai khái niệm thường bị dùng thay thế cho nhau vì đều xuất hiện sau khi giao dịch được tạo.

Tuy nhiên, có thể tách rất rõ:

• Settlement: “Nghĩa vụ tiền này cuối cùng được hoàn tất và ghi nhận thế nào?”
• Reconciliation: “Các hệ thống độc lập có đang cùng ghi nhận một kết quả hay không?”

Nếu gộp hai việc thành một, hệ thống dễ rơi vào tình trạng “đã ghi nhận xong nên mặc nhiên coi là đúng”, trong khi đối soát độc lập chưa hề được thực hiện.

Settlement nên được hiểu thế nào trong bài này?

Thuật ngữ “settlement” có thể được dùng khác nhau giữa ngân hàng, cổng thanh toán và payroll.

Trong phạm vi bài này, Settlement được hiểu là bước xác lập kết quả tài chính cuối cùng của một giao dịch hoặc một kỳ nghiệp vụ.

Ví dụ với một giao dịch EWA:

• yêu cầu đã được tạo;
• ngân hàng đã xác nhận kết quả;
• hệ thống xác định khoản tiền đã thực sự được chi;
• sổ giao dịch ghi nhận số đã nhận;
• phần tiền còn lại được cập nhật.

Ở cấp kỳ lương, settlement còn liên quan đến việc:

• tổng hợp các khoản EWA đã được xác nhận;
• đưa đúng tổng vào payroll;
• xác định phần còn lại cần chi trong kỳ;
• đóng các nghĩa vụ đã xử lý xong.

Settlement vì vậy thiên về hoàn tất một nghĩa vụ tiền.

Reconciliation nên được hiểu thế nào?

Reconciliation là quá trình đối chiếu hai hoặc nhiều nguồn dữ liệu độc lập để xem chúng có khớp hay không.

Ví dụ:

• sổ giao dịch EWA ghi đã chi 500.000 đồng;
• sao kê ngân hàng cũng phải có giao dịch tương ứng;
• payroll cuối kỳ phải phản ánh đúng khoản đã nhận đó;
• phiếu lương phải không trừ hai lần.

Nếu các nguồn cùng khớp, giao dịch hoặc kỳ được xem là đã đối soát.

Nếu không khớp, chênh lệch phải được đưa vào hàng đợi ngoại lệ.

Reconciliation không “tạo” giao dịch và cũng không nên tự sửa số để làm báo cáo khớp.

Bảng phân biệt Settlement và Reconciliation

Tiêu chí	Settlement	Reconciliation
Câu hỏi chính	Nghĩa vụ tiền đã hoàn tất thế nào?	Các sổ có khớp nhau không?
Thời điểm	Trong/ sau vòng đời giao dịch hoặc cuối kỳ	Sau khi có dữ liệu từ nhiều nguồn
Dữ liệu chính	Trạng thái giao dịch, số tiền, kỳ	EWA ledger, ngân hàng, payroll
Kết quả	Số đã chi/đã quyết toán/phần còn lại	Khớp hoặc ngoại lệ
Có tạo giao dịch?	Có thể liên quan đến việc hoàn tất giao dịch	Không
Có phát hiện chênh lệch?	Có thể, nhưng không phải mục đích chính	Có, đây là mục đích chính
Có đóng kỳ?	Có thể tham gia đóng nghĩa vụ	Xác nhận dữ liệu trước khi đóng
Khi chưa rõ	Giữ trạng thái phù hợp	Đưa vào ngoại lệ/tra soát

Hai lớp phải nối nhau nhưng không thay thế nhau.

Một giao dịch đi qua Settlement thế nào?

Một luồng điển hình có thể là:

1. yêu cầu đã đủ điều kiện;
2. Payment Orchestration tạo giao dịch;
3. ngân hàng xử lý;
4. trạng thái cuối được xác định;
5. giao dịch thành công được ghi vào sổ “đã nhận”;
6. phần giá trị liên quan được khóa khỏi tái sử dụng;
7. nghĩa vụ giao dịch được xem là hoàn tất.

Nếu trạng thái ngân hàng chưa chắc chắn, bước settlement không nên tự kết luận.

Đây là nơi nguyên tắc fail-closed được áp dụng: chưa rõ thì chưa đóng như thành công hoặc thất bại.

Một giao dịch đi qua Reconciliation thế nào?

Sau khi có dữ liệu độc lập, hệ thống đối chiếu:

1. mã giao dịch nội bộ;
2. mã/tham chiếu ngân hàng;
3. số tiền;
4. người nhận;
5. thời gian;
6. trạng thái;
7. kỳ lương;
8. khoản đã ghi vào payroll.

Nếu tất cả khớp, giao dịch có thể được đánh dấu đối soát thành công.

Nếu một trường không khớp, hệ thống tạo ngoại lệ.

Điểm quan trọng là reconciliation dùng nguồn độc lập để kiểm chứng kết quả đã được hệ thống ghi nhận.

Vì sao phản hồi API chưa đủ để gọi là đối soát?

Một API ngân hàng có thể trả “success” tại thời điểm xử lý.

Đó là một tín hiệu quan trọng, nhưng hệ thống tài chính vẫn nên có lớp đối soát độc lập sau đó.

Lý do:

• phản hồi thời gian thực có thể lỗi hoặc bị mất;
• hệ thống nội bộ có thể ghi sai trạng thái;
• một giao dịch có thể bị ghi hai lần;
• sao kê có thể xuất hiện giao dịch hệ thống không ghi nhận;
• payroll có thể dùng sai kỳ.

Reconciliation giúp kiểm chứng sau cùng.

Settlement cuối kỳ khác settlement từng giao dịch thế nào?

Có thể có hai cấp.

Cấp giao dịch

Xác định một lệnh cụ thể đã chi hay chưa, số tiền bao nhiêu và ghi vào sổ giao dịch.

Cấp kỳ lương

Tổng hợp toàn bộ giao dịch thuộc kỳ và xác định:

• tổng đã nhận;
• khoản hoàn/điều chỉnh;
• phần phải phản ánh trên payroll;
• phần lương còn lại.

Hai cấp đều cần dữ liệu truy vết.

Vì sao không nên “đối soát bằng cách sửa số cho khớp”?

Một lỗi nguy hiểm là khi hai sổ không khớp, người vận hành sửa tay một bên để tổng cuối bằng nhau.

Cách này làm mất bằng chứng nguyên nhân.

Quy trình đúng nên là:

1. giữ nguyên dữ liệu nguồn;
2. tạo ngoại lệ;
3. tìm nguyên nhân;
4. xác định sổ nào sai;
5. thực hiện điều chỉnh bằng nghiệp vụ có dấu vết;
6. phê duyệt;
7. đối soát lại.

Mọi điều chỉnh cần audit trail.

Những ngoại lệ thường gặp giữa Settlement và Reconciliation

Hệ thống ghi thành công nhưng sao kê không có

Cần tra soát giao dịch và bằng chứng ngân hàng.

Sao kê có tiền ra nhưng hệ thống ghi pending

Có thể phản hồi API bị mất. Không được gửi lại lệnh mới.

Giao dịch thành công nhưng payroll không phản ánh

Rủi ro phần đã nhận bị chi lại cuối kỳ.

Payroll trừ nhưng giao dịch thất bại

Rủi ro người lao động bị giảm tiền dù chưa nhận.

Giao dịch thuộc sai kỳ

Cần kiểm tra quy tắc cut-off và kỳ liên quan.

Có giao dịch trùng

Phải giữ cả hai bản ghi, xác định nguyên nhân và xử lý theo quy trình.

Ai nên sở hữu hai lớp này?

Không nhất thiết cùng một đội.

Có thể phân chia:

• Payment Operations: theo dõi settlement từng giao dịch;
• Kế toán/đối soát: reconciliation với ngân hàng;
• Payroll: settlement và đối soát cuối kỳ lương;
• Engineering: bảo đảm trạng thái, idempotency và log;
• Product Operations: điều phối ngoại lệ.

Điều quan trọng là trách nhiệm phải rõ khi có chênh lệch.

Dữ liệu nào cần để nối hai lớp?

Tối thiểu nên có:

• mã giao dịch;
• mã người lao động;
• tài khoản nhận;
• số tiền;
• thời gian;
• khách hàng;
• kỳ lương;
• trạng thái giao dịch;
• mã tham chiếu ngân hàng;
• khoản đã đưa vào payroll.

Không nên đối soát chủ yếu bằng họ tên hoặc nội dung chuyển khoản tự do.

Khi nào một kỳ có thể được coi là “đóng”?

Một kỳ không nên chỉ đóng vì payroll đã chạy.

Trước khi đóng, doanh nghiệp nên biết:

• công đã đủ trạng thái cuối;
• các giao dịch thành công đã được tổng hợp;
• giao dịch pending đã có hướng xử lý;
• ngân hàng và sổ nội bộ đã đối soát;
• payroll đã phản ánh đúng;
• ngoại lệ còn lại đã có owner;
• báo cáo cầu nối đã được lưu.

Không nhất thiết mọi ngoại lệ phải biến mất ngay, nhưng ngoại lệ còn mở phải được nhận diện và kiểm soát.

KPI nên theo dõi riêng cho Settlement và Reconciliation

Settlement

• thời gian xác định trạng thái cuối;
• số giao dịch pending;
• tỷ lệ giao dịch cần can thiệp;
• số giao dịch bị retry;
• số giao dịch trùng.

Reconciliation

• tỷ lệ khớp tự động;
• số ngoại lệ;
• tuổi ngoại lệ;
• số chênh lệch ngân hàng;
• số chênh lệch payroll;
• thời gian đóng đối soát.

Nếu gộp chung một KPI, doanh nghiệp khó biết vấn đề nằm ở xử lý giao dịch hay ở đối chiếu sổ.

Kết luận

Settlement và Reconciliation là hai mắt xích khác nhau của cùng chuỗi kiểm soát. Settlement hoàn tất và ghi nhận nghĩa vụ tiền; Reconciliation dùng các nguồn độc lập để chứng minh kết quả đó nhất quán. Khi hai lớp được tách rõ, doanh nghiệp dễ xử lý pending, chênh lệch, cut-off và payroll hơn, đồng thời giữ được khả năng truy vết từ giao dịch đến phiếu lương.

Tác giả: Đỗ Huy Lê — Tổng Giám Đốc, Công ty TNHH Cung Ứng Nhân Lực Nhân Kiệt.

Tư vấn Lương Ngày cho doanh nghiệp: Hotline 0937.022.655 · Email info@nhankiet.vn · Tìm hiểu Lương Ngày cho doanh nghiệp