Phê duyệt hóa đơn có SLA: tránh treo việc và thanh toán trễ

Hóa đơn thường không bị trễ vì thiếu nút “Approve”. Chúng bị treo vì không xác định deadline bắt đầu từ đâu, ai là approver hiện tại, người đó nghỉ thì chuyển cho ai, case nào gần vi phạm SLA và khi quá hạn hệ thống phải làm gì. Một workflow chỉ gửi email rồi chờ không phải là quản lý SLA.

Thiết kế tốt cần một work item có trạng thái, deadline, business calendar, owner, evidence, policy version và escalation path. AI có thể trích xuất dữ liệu, phát hiện thiếu chứng từ và đề xuất tuyến duyệt, nhưng quyền phê duyệt hoặc release payment vẫn phải theo separation of duties và risk tier.

Chọn sự kiện bắt đầu: hóa đơn được nhận, được xác thực hay đủ chứng từ. Nếu chờ vendor bổ sung, đồng hồ có pause không? Dùng giờ thực hay business hours? Ngày lễ và timezone nào áp dụng? Một hóa đơn giá trị cao có SLA khác hóa đơn lặp lại đã match PO không?

Mỗi item nên có received_at, eligible_at, due_at, at_risk_at, current_stage, approver, delegation, pause_reason và policy_version. Deadline được tính một lần từ policy đã version; không âm thầm thay đổi khi sửa flow.

Microsoft Work Queues cho phép TTL, ngưỡng SLA at-risk và SLA violation; item gần hạn có thể được ưu tiên và item vi phạm được đưa vào can thiệp. Xem tài liệu work queue SLA. Dù dùng nền tảng nào, tư duy stateful queue vẫn cần thiết.

Routing có thể dựa trên legal entity, cost center, PO status, amount band, vendor risk, currency và loại chi phí. Resolve approver tại thời điểm tạo stage; kiểm tra người duyệt còn active và không vi phạm separation of duties. Nếu requester cũng là approver hoặc bank detail vừa thay đổi, bắt buộc tuyến bổ sung.

Reminder phải idempotent: cùng item, stage và reminder threshold không gửi lặp vô hạn. At-risk có thể nhắc approver và owner; breach có thể reassign, thêm approver dự phòng hoặc chuyển AP manager tùy policy. Không tự động “approve vì hết hạn”.

Microsoft Approvals Kit mô tả trạng thái Pending, Pending Timeout, Send back và Reassign; cấu hình preset approval còn hỗ trợ delegation khi timeout hoặc out-of-office và cách tính actual days hoặc business days. Xem xử lý approval request và cấu hình delegation.

AI có thể trích xuất header và line item, kiểm tra thiếu PO, tóm tắt chênh lệch, phát hiện mô tả bất thường và đề xuất cost center hoặc approver. Mọi đề xuất phải kèm evidence từ invoice, PO, receipt và master data. Rule xác định vẫn kiểm tra duplicate, tổng, thuế, vendor status và bank change.

Confidence thấp, dữ liệu xung đột hoặc action risk cao đi vào review. Agent có thể hỏi bổ sung, tạo task và theo dõi SLA, nhưng không tự sửa master vendor hoặc release payment bằng cùng credential. Approval decision và payment execution phải là hai quyền khác nhau.

Theo NIST AI RMF, tổ chức cần governance, context mapping, measurement và management cho rủi ro AI. Với invoice approval, lưu model/tool version, input reference, đề xuất, người quyết định, override và outcome downstream để đánh giá lỗi và xử lý incident. Xem NIST AI RMF Playbook.

SLA nên bắt đầu khi nhận email hay khi đủ chứng từ?

Tùy cam kết nghiệp vụ. Có thể theo dõi cả intake SLA và approval SLA, nhưng định nghĩa và pause reason phải rõ.

Quá hạn có nên tự động chuyển người duyệt?

Chỉ khi policy cho phép và separation of duties vẫn đúng. Luôn lưu actor cũ, lý do và lịch sử reassign.

AI có thể ưu tiên hóa đơn gần hạn không?

Có, nhưng deadline nên được tính bằng rule xác định; AI hỗ trợ xếp ưu tiên theo rủi ro và giải thích ngoại lệ.

Nhắc việc bao nhiêu lần là đủ?

Theo threshold và kênh đã định nghĩa. Thiết kế idempotent, tránh spam và escalation phải có owner hành động.