Khách có thể thanh toán đúng tổng số tiền nhưng lệch lịch từng kỳ; một khoản trả sớm lại bị gắn vào kỳ đang mở của hợp đồng khác. Tự động hóa đối soát ngân hàng cho mô hình kinh doanh trả góp cần giữ được cả khoản đã nhận, lịch phải thu và cách phân bổ. Chỉ ghi đơn đã thanh toán là không đủ để biết kỳ nào còn thiếu.
Phạm vi ở đây là quản lý khoản phải thu theo lịch mà doanh nghiệp đã xác lập hợp lệ với khách. Phần mềm nhận dữ liệu và đối chiếu không tự quyết định điều kiện cấp tín dụng, tính lãi hoặc thay đổi nghĩa vụ. Những điều kiện đó phải được xác định trước rồi mới chuyển thành quy tắc của ứng dụng.
Bắt đầu từ hợp đồng và lịch thu đã được duyệt
Mỗi hợp đồng cần có mã ổn định, khách liên quan, giá trị nghĩa vụ và lịch các kỳ. Từng kỳ lưu số phải thu, hạn, số đã phân bổ và phần còn lại. Nếu có khoản khác ngoài giá trị hàng hóa, hồ sơ cần tách rõ theo điều kiện áp dụng của doanh nghiệp; không gộp thành một số tổng mà người vận hành không giải thích được.
Lịch thu phải có phiên bản. Khi thay đổi hạn hoặc số kỳ theo quyết định được phép, giữ lịch trước và thời điểm hiệu lực. Khách có thể thanh toán theo thông báo cũ, nên ứng dụng cần biết khoản đó liên quan lịch nào. Sửa trực tiếp ngày hạn trên một dòng sẽ làm mất căn cứ khi phát sinh tranh luận.
Người trả tiền cũng có thể khác khách đứng tên. Định danh khoản phải thu nên dựa trên hợp đồng và kỳ, thay vì tên tài khoản chuyển. Nếu một khách có nhiều hợp đồng, mã khách hàng đơn thuần chưa đủ. Cần quy tắc nhận diện để một khoản đến không tự rơi vào hợp đồng đầu tiên mà hệ thống tìm thấy.
Đừng trộn lịch thu nội bộ với sản phẩm trả góp của ngân hàng
Trả theo lịch do doanh nghiệp quản lý và trả góp qua sản phẩm ngân hàng có luồng dữ liệu, hợp đồng và bên chịu trách nhiệm khác nhau. Hướng dẫn thẻ tín dụng ACB là ví dụ về quy trình riêng của ngân hàng. Doanh nghiệp cần xác định đang triển khai mô hình nào trước khi đặt yêu cầu cho phần mềm đối soát.
Nếu đơn vị tài chính hoặc đối tác chuyển trả cho người bán theo lô, nguồn đối chiếu có thể là bảng kê và khoản quyết toán, thay vì từng lần khách trả trực tiếp vào tài khoản doanh nghiệp. Nếu khách trả trực tiếp theo kỳ, ứng dụng cần theo dõi từng khoản thu và số còn lại. Hai luồng không nên dùng chung một quy tắc ghép chỉ vì đều được gọi là trả góp.
Tương tự, gửi nhắc kỳ thanh toán khác với tự động trích nợ. Khả năng tạo yêu cầu hoặc nhận thông báo không chứng minh dịch vụ có quyền tự thu từ tài khoản khách. Nếu dự án cần trích nợ, phải xác nhận sản phẩm, điều kiện và cách cấp quyền riêng với đơn vị cung cấp, thay vì suy ra từ một trang API thanh toán.
Tạo yêu cầu cho kỳ và phân bổ khoản nhận
Thông báo kỳ thu nên nêu hợp đồng, kỳ, số cần trả và tham chiếu rõ. Trước mỗi lần gửi, kiểm tra số còn phải thu vì khách có thể vừa thanh toán qua kênh khác. Thông báo không cập nhật sẽ tạo trải nghiệm khó chịu: khách đã trả nhưng vẫn bị nhắc, hoặc chuyển thêm lần nữa vì nghĩ khoản trước chưa được nhận.
Collection Link Pay2S mô tả tạo yêu cầu thanh toán cho đơn. Doanh nghiệp có thể đánh giá việc liên kết yêu cầu với kỳ thu trong ứng dụng của mình. Lịch trả, phân bổ nhiều kỳ và quy tắc nhắc nợ cần được thiết kế riêng; không mặc định đây là chức năng quản lý hợp đồng trả góp dựng sẵn.
Khi dữ liệu hợp lệ về, lưu khoản thu trước rồi phân bổ theo tham chiếu và quy tắc đã duyệt. Trạng thái kỳ được tính từ số cần thu và tổng phân bổ hợp lệ. Một khoản trả thiếu vẫn là khoản đã nhận; kỳ còn phần phải thu. Một thông báo gửi lại cho giao dịch đó không làm tổng đã trả tăng thêm.
Bài luồng webhook đối soát đơn hàng giúp đội kỹ thuật xác định đầu vào. Điểm nghiệp vụ cần kiểm tra là khoản thu đi về đúng hợp đồng và kỳ, chứ không chỉ request đã tới máy chủ. Một hệ thống nhận đủ thông báo vẫn có thể phân bổ sai nếu dữ liệu nghĩa vụ không rõ.
Trả sớm, trả thiếu và trả gộp cần quy tắc riêng
Với trả sớm, cần xác định khách muốn thanh toán kỳ sắp tới hay nhiều kỳ. Không tự phân bổ vào khoản lâu nhất chỉ vì đó là dòng xuất hiện đầu. Cách ưu tiên cần theo hồ sơ và chính sách đã được duyệt. Nếu bằng chứng chưa đủ, giữ phần tiền chờ xác minh thay vì buộc hệ thống chọn một kỳ để đóng.
Với trả thiếu, theo dõi số còn lại ở đúng kỳ. Điều kiện chuyển sang kỳ tiếp theo hoặc tiếp tục cung cấp dịch vụ phải được xác định theo hợp đồng, không dựa vào một nhãn chung đã có tiền. Nếu doanh nghiệp cho phép điều chỉnh phần chênh, quyết định đó cần lưu riêng, giữ khoản ngân hàng theo số thực nhận.
Với trả gộp, một giao dịch có thể được phân bổ thành nhiều phần, tổng không vượt khoản nhận. Mỗi phần trỏ về kỳ và hợp đồng liên quan. Khi điều chỉnh sau đó, giữ lịch sử để người khác có thể dựng lại số còn phải thu tại từng thời điểm. Bảng tổng không nên che mất cách một khoản tiền được chia.
Khách trả dư cũng cần một nơi theo dõi. Phần vượt có thể được xử lý theo quyết định hợp lệ như phân bổ cho nghĩa vụ khác hoặc hoàn. Không tự đổi lịch thu hoặc coi toàn bộ phần vượt là phí phát sinh. Hệ thống chỉ nên thực hiện những nhánh đã có quy tắc và thẩm quyền rõ.
Tình huống giả định: một khoản trả cho hai kỳ
Giả định hợp đồng có sáu kỳ, mỗi kỳ 1.000.000 đồng theo bộ điều kiện đã được xác định. Khách chuyển 2.000.000 đồng và xác nhận muốn trả kỳ hai cùng kỳ ba. Ứng dụng lưu một giao dịch, sau đó phân bổ hai phần 1.000.000 đồng vào hai kỳ. Tổng hợp đồng đã nhận tăng 2.000.000 đồng, không phải số lần bản tin được tiếp nhận.
Nếu khách chỉ chuyển 1.500.000 đồng, quy tắc có thể cho phép phân bổ đủ kỳ hai và một phần kỳ ba khi hồ sơ phù hợp. Phần còn lại của kỳ ba vẫn hiển thị. Nhưng nếu chưa có căn cứ về kỳ mà khách muốn trả, nhân viên phải xác minh; phép cộng đúng không thay thế việc xác định đúng nghĩa vụ.
Giả sử sau đó một lần gửi lại đến máy chủ. Giao dịch đã tồn tại nên không tạo hai phần phân bổ mới. Nếu nguồn gửi tới một khoản thật khác, ứng dụng lưu khoản mới và tiếp tục kiểm tra. Thử hai tình huống này giúp phát hiện chương trình có đang nhầm số lần thông báo với số lần khách thanh toán hay không.
Nhắc đúng khoản còn nợ, xử lý thay đổi có dấu vết
Danh sách nhắc nên lấy từ nghĩa vụ còn mở và thời hạn đã duyệt. Trước khi gửi, kiểm tra các khoản đang chờ phân bổ để tránh nhắc nhầm người đã trả. Có thể tách nhóm chưa nhận tiền, nhận một phần và có khoản chờ xác minh; mỗi nhóm cần nội dung và người xử lý khác nhau.
Khi khách đề nghị đổi lịch, nhân viên ghi yêu cầu và chuyển đúng người có quyền. Sau khi được duyệt, ứng dụng cập nhật phiên bản cùng thông báo liên quan. Các yêu cầu thu cũ còn hiệu lực phải được rà lại, vì khách có thể tiếp tục dùng chúng. Không để bộ nhắc vẫn chạy theo lịch trước trong khi màn hình hợp đồng đã hiển thị lịch mới.
Quyền thay đổi hạn, giảm nghĩa vụ và hoàn tiền nên được tách khỏi quyền tra cứu khoản thu. Người hỗ trợ khách có thể xem thông tin cần thiết nhưng không tự sửa mọi điều kiện. Nhật ký giúp đội tài chính giải thích vì sao số còn phải thu đổi, nhất là khi người phụ trách hợp đồng thay đổi giữa quá trình.
Kiểm tra cuối kỳ bằng nghĩa vụ, phân bổ và tiền nguồn
Báo cáo nên nối tổng tiền nhận, tổng được phân bổ, tiền chưa phân bổ và nghĩa vụ còn lại theo hợp đồng. Phần quá hạn cần theo định nghĩa ngày và trạng thái đã thống nhất. Nếu chỉ nhìn số kỳ đã đóng, doanh nghiệp có thể bỏ sót những khoản đóng một phần hoặc nghĩa vụ đã điều chỉnh sau khi nhận tiền.
Cần giữ khả năng xem tại một mốc quá khứ. Báo cáo cuối tháng trước không nên tự thay toàn bộ số liệu vì tháng này hợp đồng được đổi lịch hoặc một khoản được chuyển phân bổ. Lưu phiên bản và thời điểm quyết định để giải thích số tại ngày chốt, rồi thể hiện thay đổi kỳ sau theo quy trình của doanh nghiệp. Đây cũng là cách tránh tranh luận khi hai bộ phận xuất báo cáo vào thời điểm khác nhau.
Với giao dịch lặp hoặc phân bổ sai, thực hiện kiểm tra và điều chỉnh có dấu vết. Tham khảo kiểm soát chống xử lý trùng cho lớp thanh toán. Đồng thời kiểm tra việc nhắc khách và trạng thái cung cấp hàng hoặc dịch vụ, vì một lỗi phân bổ có thể ảnh hưởng nhiều tác vụ ngoài báo cáo tiền.
Nếu triển khai hóa đơn, cần kế toán xác định quy trình phù hợp với mô hình đang dùng. Bài đối chiếu khoản thu, đơn và hóa đơn giúp chuẩn bị dữ liệu liên kết; nhận tiền theo kỳ không tự xác định thời điểm và nội dung chứng từ cho mọi trường hợp.
Trước khi làm việc với đội triển khai Pay2S trên hoadontudong.com.vn, hãy chọn các tình huống trả sớm, thiếu, gộp và đổi lịch mà doanh nghiệp thực sự phải xử lý. Viết kết quả mong đợi cho từng tình huống rồi dùng để nghiệm thu. Một luồng đáng tin phải giữ được lịch sử nghĩa vụ và giải thích từng khoản phân bổ, ngay cả khi khách không trả đúng một kỳ trong một lần chuyển.
