Một khoản tiền nhận được có thể liên quan nhiều hóa đơn; nội dung chuyển khoản đôi khi chỉ có tên khách hàng. AI có thể tìm chứng từ ứng viên và giải thích dấu hiệu ghép. Nó không nên tự coi hóa đơn đã tất toán chỉ vì tổng tiền gần bằng nhau. Sổ đề xuất cần giữ phần đã xác nhận và phần chưa rõ riêng biệt.
Phân bổ khoản thanh toán khác ghi nhận đã nhận tiền
Bằng chứng có tiền vào và bằng chứng tiền đó dùng cho hóa đơn nào là hai việc khác nhau. Tài liệu Microsoft về cash application có luồng tạo khoản thanh toán mà chưa tất toán hóa đơn. Ranh giới này giúp thiết kế một vùng đề xuất trước khi kế toán thao tác trong hệ thống chính.
Bài viết tập trung vào sổ ghép chứng cứ, không đưa hướng dẫn hạch toán, xử lý thuế hay lựa chọn phương pháp kế toán. Quyết định ghi sổ cần theo người có trách nhiệm và quy trình hiện hành.
Mẫu bảng đề xuất ghép
| Trường | Cần giữ |
|---|---|
| payment_id | Mã giao dịch, ngày, tiền tệ, số tiền và nguồn sao kê |
| payer_raw, reference_raw | Tên người chuyển và nội dung nguyên gốc |
| invoice_candidate | Hóa đơn ứng viên, khách hàng và chứng cứ liên quan |
| proposed_amount, reason | Số đề xuất và lý do ghép |
| confirmed_amount, unallocated_amount | Phần được duyệt và phần còn chờ |
| reviewer, decision_at | Người xác nhận và thời điểm |
Không sửa tên người chuyển thành tên khách hàng trước khi có quan hệ được xác nhận. Đơn vị thanh toán hộ, tên viết tắt hoặc nội dung thiếu dấu đều cần chứng cứ bổ sung. Điểm tương đồng tên chỉ giúp xếp hàng chờ, không xác nhận danh tính.
Ví dụ mô phỏng với phần tiền còn chờ
Khoản P1 nhận 12 triệu đồng. Thư xác nhận đã được kiểm tra nêu 7 triệu cho I1 và 4 triệu cho I2; còn 1 triệu chưa có giải thích. Sổ đề xuất giữ hai phần có nguồn và 1 triệu chưa phân bổ. Không tự gán phần còn lại cho hóa đơn gần ngày nhất.
Nếu hai hóa đơn cùng có số dư 12 triệu và nội dung chỉ ghi “thanh toán”, hệ thống phải giữ nhiều ứng viên. Một câu hỏi cụ thể gửi qua quy trình được phép sẽ hữu ích hơn việc AI chọn hóa đơn có vẻ phù hợp. Mọi mã và số trong ví dụ là mô phỏng, không phải kết quả của Onter.
Những dấu hiệu không đủ để tự ghép
Tổng tiền bằng nhau, tên gần giống và ngày gần nhau không đủ nếu có nhiều khả năng. Khoản thanh toán một phần, phí ngân hàng, bù trừ hoặc khác tiền tệ cần kế toán xem xét theo hồ sơ. AI không được tự suy ra phí để làm số khớp.
Với mỗi dòng, nên mở được nguồn giao dịch và tài liệu giải thích phân bổ. Nếu một thư được thay thế, giữ quan hệ phiên bản; không dùng đồng thời hai hướng dẫn mâu thuẫn mà không cảnh báo.
Kiểm tra số bảo toàn và quyền cập nhật
Tập kiểm thử nên có một khoản cho nhiều hóa đơn, nhiều khoản cho một hóa đơn, người thanh toán hộ, cùng giao dịch nhập lại và hướng dẫn bị sửa. Kiểm tra tổng đề xuất không tự vượt số tiền nhận; phần chưa phân bổ phải hiển thị rõ.
Trạng thái người duyệt cần độc lập với trạng thái AI đã đọc. Chỉ tạo tác vụ trong hệ thống kế toán qua đường được cấp quyền và có nhật ký; tránh để câu trả lời ngôn ngữ tự nhiên trở thành lệnh tất toán.
Chuẩn bị đối chiếu công nợ có nguồn
Sổ này có thể hỗ trợ quy trình đối chiếu công nợ. Nếu chứng cứ nằm rải rác trong file và email, phần đọc tài liệu cần giữ được liên kết nguồn.
Khi trao đổi triển khai, chuẩn bị vài khoản đã được kế toán phân bổ đúng và vài khoản còn chờ, sau khi che dữ liệu nhạy cảm. Điều cần làm rõ là tiêu chuẩn chứng cứ và người xác nhận, không phải lời hứa AI tự giải quyết mọi khoản tiền không rõ nội dung.
Nguồn tham khảo
Tài liệu chính thức: Luồng cash application có thể tạo khoản thanh toán mà chưa tất toán hóa đơn, nên phân biệt hai trạng thái. Truy cập ngày 13/10/2026. Các mẫu sổ, tình huống và đề xuất kiểm soát trong bài do người biên tập xây dựng; không phải tính năng Onter đã nghiệm thu.
