AI đọc sai hóa đơn: kiểm soát thế nào trước khi đưa vào kế toán?

AI đọc hóa đơn nên được xem là bước trích xuất đề xuất, không phải bằng chứng đủ để hạch toán. Pipeline an toàn phải giữ file gốc, trả confidence theo từng trường, chuẩn hóa dữ liệu, kiểm tra rule nghiệp vụ, đối soát nhà cung cấp–PO–số tiền và chỉ cho phép posting khi đạt policy. Trường không chắc chắn hoặc có tác động tài chính cao phải vào review queue.

Không dùng một confidence tổng cho toàn tài liệu. Hóa đơn có thể đọc đúng tên nhà cung cấp nhưng sai dấu thập phân, thuế, currency hoặc tổng tiền. Một lỗi nhỏ về ký tự có thể tạo thanh toán trùng hoặc hạch toán sai. Vì vậy, kiểm soát phải dựa trên field, ngữ cảnh và mức rủi ro của hành động tiếp theo.

Ảnh nghiêng, mờ, nhiều trang, dấu đóng, chữ viết tay và bảng line item phức tạp làm giảm chất lượng trích xuất. Hai trường có hình thức giống nhau—invoice date và due date, subtotal và total—có thể bị gán nhầm. Định dạng số 1.234,56 và 1,234.56, ký hiệu tiền tệ, số âm hoặc chiết khấu cũng cần chuẩn hóa theo locale.

Azure Document Intelligence cung cấp model prebuilt-invoice để trích xuất invoice ID, date, vendor, customer, total, tax và line items thông qua API/SDK. Tài liệu mô tả schema và các trường được hỗ trợ, nhưng ứng dụng vẫn phải kiểm tra kết quả trước khi dùng. Xem invoice model.

Đừng biến giá trị null, field thiếu hoặc confidence thấp thành số 0. Đó là dữ liệu chưa biết và phải được xử lý khác với số 0 thật.

Bước intake xác thực nguồn, quét file, tính hash và lưu immutable original. Extraction tạo normalized JSON nhưng không sửa file gốc. Mỗi field lưu value, normalized value, confidence, page/bounding reference và model version. Validation kiểm tra kiểu dữ liệu, required field, currency, công thức subtotal + tax − discount = total và ngày hợp lệ.

Reconciliation so khớp vendor master, purchase order, goods receipt và invoice đã có. Dùng nhiều khóa cho duplicate detection: vendor ID, normalized invoice number, amount, date và file hash. Nếu không có PO, policy có thể yêu cầu review cao hơn thay vì tự động từ chối.

Cuối pipeline là posting gate. Chỉ các invoice đạt threshold theo từng field, qua rule và không có xung đột mới được tạo draft hoặc post theo mức quyền. Microsoft cung cấp ví dụ gọi model qua SDK/REST trong hướng dẫn Document Intelligence; orchestration, kiểm soát và quyền posting vẫn thuộc ứng dụng doanh nghiệp.

Tạo tier theo giá trị, vendor, loại chi phí, PO match và field confidence. Tier thấp có thể tự tạo accounting draft nhưng không tự thanh toán. Tier trung bình yêu cầu người kiểm tra các field bị đánh dấu. Tier cao—vendor mới, thay đổi tài khoản ngân hàng, số tiền lớn, không có PO hoặc duplicate nghi ngờ—phải fail closed và cần người có quyền duyệt.

Giao diện review cần hiển thị file gốc cạnh field trích xuất, highlight vị trí, lý do flag và dữ liệu đối soát. Người duyệt sửa value phải chọn reason; correction trở thành labeled feedback nhưng không tự động dùng để train nếu chưa có governance. Theo dõi model/version drift theo vendor và layout.

NIST AI RMF đề xuất quản trị rủi ro qua Govern, Map, Measure và Manage. Với invoice AI, điều này tương ứng owner rõ, inventory model/use case, đánh giá error theo tác động và incident/recovery process. Xem NIST AI RMF.

Confidence bao nhiêu thì được tự động?

Không có một số chung. Thiết lập threshold theo field, loại invoice và tác động; đánh giá bằng tập dữ liệu thực của doanh nghiệp.

Có cần review tất cả line item không?

Không nếu policy cho phép summary-level processing và các phép đối soát đủ mạnh. Nhưng line item ảnh hưởng tồn kho hoặc thuế cần kiểm soát phù hợp.

AI có phát hiện hóa đơn giả không?

Extraction model không phải hệ thống xác minh gian lận. Cần vendor verification, PO/receipt match, banking-change control và các tín hiệu khác.

Correction của kế toán có nên tự train model?

Không trực tiếp. Hãy review, version dataset, loại PII không cần thiết và đánh giá model mới trước deployment.