Kiểm tra hồ sơ, chứng từ

1. Bài toán

Ai gặp việc này: kế toán, hành chính nhân sự, nhân viên mua hàng ở các doanh nghiệp nhỏ và vừa (SME). Bạn không cần biết lập trình để bắt đầu; chỉ những cấp sau mới cần nhờ người biết code hoặc nhờ AI hỗ trợ.

Hằng ngày nó trông thế nào: có một chồng hồ sơ trên bàn hoặc trong máy, và bạn phải kiểm từng bộ xem có đúng quy định, đủ giấy tờ, khớp số liệu hay chưa. Có người ngồi đối chiếu hóa đơn với phiếu nhập kho và đơn mua. Có người đọc từng điều khoản của một hợp đồng. Có người xem một bộ hồ sơ nhân sự đã đủ giấy tờ chưa. Làm lâu thì mệt, mệt thì sót.

Nhóm bài giúp gì: giúp bạn dựng một cách kiểm có danh sách quy tắc rõ ràng, đi hết từng quy tắc cho từng hồ sơ, và cho ra kết quả mà người duyệt có thể kiểm lại được.

Nói theo ngôn ngữ của cả nhóm:

Đầu vào: một bộ hồ sơ. Ví dụ: hóa đơn + phiếu nhập kho + đơn mua; một hợp đồng; một bộ hồ sơ nhân sự. Đầu ra: danh sách lỗi có căn cứ. Mỗi lỗi ghi: quy tắc nào, kết quả (đạt / lỗi / không rõ), nằm ở đâu trong chứng từ, căn cứ quy tắc là gì. Người quyết định: người duyệt. Hệ thống chỉ đề xuất.

Nhóm bài này khác nhóm bài (Tra cứu tài liệu nội bộ). RAG là cách cho AI tìm trong một kho tài liệu lớn rồi trả lời câu hỏi, kèm chỗ trích dẫn. Bảng dưới so hai nhóm:

Vì bộ quy tắc biết trước, ta không cần tìm kiếm ở phần lớn bài toán. Đây là điểm làm bài toán này rẻ hơn RAG.

2. Vì sao SME Việt Nam gặp bài toán này

• Kế toán kiểm hóa đơn đầu vào (hóa đơn của nhà cung cấp gửi cho mình) trước khi thanh toán và kê khai. Hành chính nhân sự kiểm hồ sơ, hợp đồng lao động. Mua hàng đối chiếu đơn mua, phiếu giao, hóa đơn. Đây là việc lặp lại, tốn công, dễ sót khi mệt. Quan sát
• Cách dùng AI "vô tội vạ" thường gặp: chụp hóa đơn dán vào chat, hỏi "hóa đơn này có đúng không?". Không có checklist, không có đáp án, không biết AI đã kiểm những gì. Đề xuất
• Lợi thế riêng của Việt Nam: hóa đơn điện tử có file XML gốc (XML là một định dạng file chứa dữ liệu hóa đơn đã được sắp xếp sẵn theo từng ô, máy đọc được trực tiếp). Đọc XML bằng code thì không cần OCR (công nghệ "đọc chữ" từ ảnh hoặc bản scan), không cần mô hình AI, không có lỗi nhận dạng chữ. Phần đắt và dễ sai nhất của bài toán (biến chứng từ thành dữ liệu) gần như miễn phí với hóa đơn điện tử. Xem cap-01.

3. Bằng chứng tóm tắt

Đây là phần các nghiên cứu và ca triển khai đứng sau thiết kế của nhóm bài. Bạn không cần nhớ từng con số; chỉ cần nắm ý chính ở phần "Rút ra" cuối mục. Chi tiết và mức tin cậy ở mục 8 của từng file cấp.

1. Ca triển khai thật có cấu trúc giống bài toán này. BMO FinDAS kiểm tài liệu tài chính nộp kèm hồ sơ vay: 78 tài liệu chính sách, 23 loại tài liệu, hơn 100 skill (mỗi skill là một khả năng đóng gói sẵn cho AI), 15 công cụ. Nhóm công cụ "kiểm tra luật định và cấu trúc" là hàm theo quy tắc (một đoạn code nhỏ làm đúng một việc), cho kết quả hợp lệ/không hợp lệ xác định; tác giả viết việc giao các quyết định này cho công cụ thay vì cho LLM (mô hình ngôn ngữ lớn, ví dụ ChatGPT, Claude, Gemini) làm giảm khả năng LLM bịa kết luận tuân thủ Nguồn: ESCROW 2608.01772, phụ lục B, C.
2. Quy tắc được trích một lần, kiểm nhiều lần. Nguyên mẫu ở Erste Bank: 90 đoạn chính sách → 36 quy tắc JSON (JSON là cách viết dữ liệu có khung rõ ràng để máy đọc; ổn định qua 5 lần chạy); kiểm 11 hồ sơ vay × 36 quy tắc = 396 lượt; bắt được 11/13 ngoại lệ đã biết, thêm vài lỗi người bỏ sót; có báo nhầm, xu hướng báo thừa Nguồn: 2610.20155.
3. Trích xuất bằng mô hình vẫn sai đáng kể. (Trích xuất là việc lấy từng thông tin như số hóa đơn, ngày, tổng tiền ra khỏi chứng từ.) GPT-4o sai 26,6% số trường trên hóa đơn DocILE; độ tự tin do mô hình tự báo (logprob, tự chấm) gần như không phân biệt được trường đúng/sai (AUC 0,69-0,74) Nguồn: 2606.24420. Trên ExtractBench, một mô hình giảm từ 87,9% ở tài liệu ngắn xuống 27,9% ở tài liệu dài Nguồn: 2607.29677, nhóm tác giả là nhà cung cấp công cụ.
4. Rà hợp đồng bằng LLM còn bỏ sót nhiều. ContractScrub (44 hợp đồng, luật sư gắn nhãn): mô hình tốt nhất bắt 75% lỗi; loại lỗi cần hiểu ngữ cảnh chỉ khoảng 35-43% Nguồn: 2608.20204.
5. Kết quả LLM không lặp lại. 14 triển khai thương mại, gửi cùng yêu cầu nhiều lần ở chế độ "xác định": cả 14 đều có lúc trả khác nhau, 12 có lúc đổi cả nhãn kết luận Nguồn: 2610.21300. Quy tắc bằng code thì lặp lại tuyệt đối.
6. Hợp đồng do bên kia soạn có thể chứa câu nhắm vào AI rà soát (kiểu tấn công này gọi là prompt injection: cài sẵn một câu "ra lệnh" vào tài liệu để AI làm theo). 11 bộ lọc prompt injection bày bán sẵn đều không dùng được trên hợp đồng (báo nhầm tới 92%); LLM có prompt riêng làm tốt hơn nhiều Nguồn: 2611.08834.
7. Không có nguồn nào đo trên chứng từ SME Việt Nam. Khảo sát nhận dạng tài liệu tiếng Việt chỉ ra dấu thanh và thiếu dữ liệu là trở ngại chính Nguồn: 2506.05061.

Đề xuất Rút ra: quy tắc nào viết được bằng code thì viết bằng code. LLM chỉ dùng cho (a) đọc chứng từ không có dữ liệu gốc, (b) quy tắc cần hiểu nghĩa. Mọi kết luận của LLM phải kèm trích dẫn nguyên văn và bị code kiểm lại. Người duyệt xem mọi "lỗi" và "không rõ".

4. Thang cấp độ của nhóm

Mỗi cấp là một bước nâng thêm một khả năng. Bảng dưới liệt kê tám cấp, kèm tên file bài và một dòng nói cấp đó làm gì.

(Project, Gem, GPT là tính năng của Claude, Gemini, ChatGPT cho bạn lưu sẵn chỉ dẫn và tài liệu mẫu để dùng lại nhiều lần.)

Mỗi cấp chạy được độc lập. Có thể dừng ở K2 nếu chỉ kiểm hóa đơn điện tử: phần lớn giá trị nằm ở K1-K2 với XML.

5. Phần nào dùng lại từ nhóm bài Tra cứu tài liệu

Nhóm bài Tra cứu tài liệu đã viết sẵn nhiều thứ dùng chung được, nên nhóm này không viết lại mà chỉ chỉ đường tới đó. Bảng dưới cho biết khối nào nằm ở file nào và dùng cho cấp nào của nhóm này. Một số thuật ngữ trong cột "Dùng cho": API là cách để một chương trình gọi một dịch vụ khác (ví dụ gọi AI); CER là tỷ lệ chữ bị đọc sai khi chuyển ảnh thành chữ; log là sổ ghi lại những gì hệ thống đã làm.

Nhóm này chỉ viết phần khác biệt. Không nhắc lại nội dung các bài trên.

6. Rủi ro pháp lý và dữ liệu chính

Phần này nhắc năm điều cần cẩn thận khi làm với chứng từ thật. Đây không phải tư vấn pháp lý; nhiều chỗ còn đang chờ kiểm chứng, xem mục 7.

1. Quy định hóa đơn đã thay đổi trong năm 2026. Theo nhiều nguồn thứ cấp (EY và các trang kế toán), Nghị định 254/2026/NĐ-CP ban hành 30/6/2026, hiệu lực 01/7/2026, thay thế Nghị định 123/2020/NĐ-CP (đã sửa bởi Nghị định 70/2025/NĐ-CP); Thông tư 91/2026/TT-BTC thay Thông tư 32/2025/TT-BTC Nguồn: EY, đọc qua công cụ tóm tắt, chưa đọc văn bản gốc. Bài nào còn dẫn NĐ 123 hay NĐ 70 làm căn cứ hiện hành phải sửa. Đây cũng là ví dụ thật cho K7: bộ quy tắc phải có ngày hiệu lực và căn cứ.
2. Định dạng XML: theo EY, NĐ 254 không còn quy định chi tiết định dạng, giao Bộ trưởng Bộ Tài chính hướng dẫn. Văn bản kỹ thuật trước đây là Quyết định 1450/QĐ-TCT (2021). Tên thẻ XML trong code mẫu chưa đối chiếu văn bản gốc; phải sửa theo file thật. (Thẻ XML là các "nhãn" đặt tên cho từng ô dữ liệu trong file hóa đơn, ví dụ nhãn cho số hóa đơn hay tổng tiền.)
3. Dữ liệu cá nhân: hồ sơ nhân sự, CV, ảnh CCCD là dữ liệu cá nhân; theo tóm tắt của EY về NĐ 356/2025, ảnh giấy tờ tùy thân và lịch sử giao dịch ngân hàng thuộc nhóm nhạy cảm. Gửi lên dịch vụ AI ở nước ngoài có thể là chuyển dữ liệu xuyên biên giới. Xem An toàn dữ liệu và pháp lý (mục 3.1, 4, 6).
4. Trách nhiệm: kết luận của hệ thống không phải căn cứ duy nhất để từ chối thanh toán, kê khai thuế, hay từ chối ứng viên. Quyết định về con người (tuyển dụng) cần thận trọng thêm; xem cap-05.
5. Tấn công qua tài liệu: hợp đồng, hóa đơn, CV do bên ngoài soạn. Có thể chứa câu hoặc chữ ẩn nhắm vào AI. Xem cap-03, cap-05.

8. Nguồn chính đã đọc

Cột "Mã" là mã dùng để gọi nguồn trong các bài (ví dụ Nguồn B5). Cột "Mức đọc" cho biết nhóm soạn đã đọc đến đâu.