Playbook AI đối soát hóa đơn và PO: chỉ đẩy ca lệch cho người duyệt

Thiết kế luồng nhận hóa đơn, OCR, đối chiếu với đơn mua hàng, phân loại ngoại lệ và chuyển đúng ca cần duyệt. Kèm schema JSON, quy tắc so khớp và lưu ý bảo vệ dữ liệu nhạy cảm.

Một hóa đơn PDF vừa vào email chung. Nhân viên vận hành phải mở file, tìm mã PO, dò từng dòng hàng, kiểm tra tiền thuế rồi ghi kết quả vào Sheet hoặc ERP. Mỗi bước không quá khó, nhưng khi số lượng chứng từ tăng lên, sai sót rất dễ xuất hiện.

Cách dùng AI hiệu quả không phải là để AI tự “quyết định thanh toán”. Hãy dùng AI làm lớp đọc chứng từ và phát hiện ngoại lệ: các ca khớp rõ ràng được ghi nhận tự động, còn người duyệt chỉ nhận hóa đơn thiếu PO, lệch đơn giá, sai tổng tiền hoặc có dữ liệu OCR chưa đủ chắc chắn.

Mục tiêu: từ file đính kèm đến hàng chờ duyệt

Một workflow đối soát cần tạo ra đầu ra rõ ràng:

Trạng thái đối soát Lý do lệch Dữ liệu đã trích xuất Liên kết tới chứng từ gốc

Nhờ đó, bảng tính hay hệ thống nội bộ không trở thành nơi mọi người phải đoán AI đã xử lý gì.

Bạn có thể triển khai luồng này bằng n8n, Make, Zapier, Power Automate hoặc Apps Script:

Trigger: Nhận email có tệp đính kèm, file mới trong kho lưu trữ hoặc bản ghi hóa đơn từ hệ thống kế toán. Kiểm tra đầu vào: Xác nhận có file, có mã giao dịch nội bộ và tệp có thể xử lý. OCR: Gửi hóa đơn vào Google Cloud Document AI Enterprise Document OCR. Chuẩn hóa dữ liệu: Chuyển kết quả OCR thành các trường phục vụ đối soát. Tìm PO: Tra đơn mua hàng theo số PO trong ERP, CRM, cơ sở dữ liệu hoặc Google Sheets. So khớp theo quy tắc: Đối chiếu PO, nhà cung cấp, tiền tệ, dòng hàng, số lượng, đơn giá và tổng tiền. Phân loại: Gắn trạng thái matched, review hoặc blocked. Action: Ghi log cho ca khớp; tạo task và thông báo cho người duyệt với ca bất thường. Phê duyệt: Chỉ sau khi người có thẩm quyền duyệt, workflow tiếp theo mới cập nhật trạng thái thanh toán hoặc gửi xác nhận.

Điểm quan trọng: AI không nằm ở cuối luồng chỉ để “viết nhận xét”. AI cần cung cấp dữ liệu có cấu trúc cho các node điều kiện, database và bước phê duyệt phía sau.

Chọn lớp đọc tài liệu trước khi suy luận

Google Document AI có Enterprise Document OCR, một processor OCR ở trạng thái GA. Processor này nhận diện văn bản in và viết tay trong hơn 200 ngôn ngữ, bao gồm tiếng Việt. Nó cũng thực hiện đánh giá chất lượng tài liệu dựa trên khả năng đọc nội dung.

Với hóa đơn tiếng Việt, đây là lớp nền tảng để đọc chữ trước, sau đó mới đưa phần văn bản và các trường cần thiết vào bước chuẩn hóa hoặc đối soát. Google mô tả phiên bản OCR v2.1 có cải thiện về nhận diện chữ in, phát hiện checkbox và thứ tự đọc.

Document AI cũng có Custom Extractor để trích xuất trường bằng mô hình sinh hoặc mô hình tùy biến. Tuy nhiên, với khả năng trích xuất bằng AI sinh, tiếng Anh là ngôn ngữ được hỗ trợ chính thức. Vì vậy, không nên mặc định kết quả trích xuất sinh trên hóa đơn tiếng Việt đã đủ tin cậy cho nghiệp vụ thanh toán.

> Với workflow tiếng Việt, hãy để OCR làm nhiệm vụ “nhìn thấy”, còn quy tắc nghiệp vụ làm nhiệm vụ “quyết định”.

Nếu cần dùng AI để diễn giải kết quả OCR, hãy yêu cầu đầu ra JSON và luôn giữ bản OCR gốc để người duyệt kiểm chứng.

Lưu ý về giới hạn trang

Theo tài liệu Document AI, Enterprise Document OCR hỗ trợ:

Tối đa 15 trang cho yêu cầu xử lý trực tuyến. Tối đa 500 trang cho xử lý batch bất đồng bộ. Tối đa 30 trang cho yêu cầu trực tuyến ở chế độ imageless.

Nếu PDF dài, hãy định tuyến sang nhánh batch thay vì cố xử lý trực tuyến.

Xây workflow theo từng node, không giao tất cả cho một agent

Dưới đây là blueprint độc lập với nền tảng automation.

Node 1: Nhận và định danh chứng từ

Lưu file gốc trong kho có kiểm soát truy cập. Tạo documentid, lưu thời điểm nhận, nguồn nhận và đường dẫn tệp.

Nếu trigger đến từ email, không nên dùng tên file làm khóa đối soát: tên file có thể trùng hoặc bị thay đổi.

Nếu thiếu file, file hỏng hoặc không thể xử lý, chuyển thẳng sang hàng chờ thủ công. Tránh retry vô hạn với lỗi đầu vào.

Node 2: OCR và kiểm tra dữ liệu đầu ra

Gửi file tới Enterprise Document OCR. Lưu phản hồi OCR thô riêng với dữ liệu đã chuẩn hóa để phục vụ truy vết khi cần kiểm tra lại.

Nếu kết quả OCR không có phần văn bản cần thiết hoặc thiếu dữ liệu quan trọng, đặt trạng thái review. Có thể retry có giới hạn khi gặp lỗi mạng hoặc lỗi tạm thời từ dịch vụ; nhưng retry không thể sửa ảnh mờ, file thiếu trang hay bản scan bị cắt.

Node 3: Chuẩn hóa thành JSON đối soát

Ở bước này, bạn có thể dùng AI với phạm vi dữ liệu được kiểm soát. Chỉ gửi văn bản OCR và dữ liệu PO cần so sánh; không đưa toàn bộ lịch sử nhà cung cấp nếu không cần thiết.

Prompt mẫu:

text Bạn là bộ chuẩn hóa dữ liệu phục vụ đối soát hóa đơn và đơn mua hàng.

Dữ liệu OCR từ hóa đơn: <invoiceocrtext>

Dữ liệu PO từ hệ thống: <podata>

Hãy trích xuất và chuẩn hóa các trường: invoicenumber invoicedate ponumber suppliername currency subtotal taxamount totalamount lineitems: sku, description, quantity, unitprice, linetotal

Quy tắc: Chỉ dùng thông tin có trong dữ liệu đầu vào. Không đoán giá trị bị thiếu. Với số tiền, giữ nguyên giá trị đọc được và trả thêm giá trị chuẩn hóa nếu xác định được. Với mỗi trường, nêu nguồn là "invoice", "po", hoặc "unknown". Nếu không chắc chắn, đưa giá trị null và ghi lý do vào extractionnotes. Chỉ trả về JSON hợp lệ, không kèm giải thích ngoài JSON.

Schema mong muốn: { "invoice": {}, "po": {}, "extractionnotes": [], "needshumanreview": true }

Ở node kế tiếp, hãy parse JSON và kiểm tra schema. Nếu JSON lỗi hoặc thiếu khóa quan trọng, lưu phản hồi thô, gắn review và tạo task cho người xử lý thay vì để workflow dừng mà không có dấu vết.

Để quy tắc quyết định, AI chỉ hỗ trợ đọc và chuẩn hóa

Không nên yêu cầu AI tự kết luận “hóa đơn hợp lệ”. Các phép so sánh xác định được cần thực hiện bằng code, biểu thức no-code hoặc SQL.

| Trường | Cách xử lý | Khi nào đưa người duyệt | |---|---|---| | Số PO | So khớp chính xác với hệ thống | Không có PO hoặc PO không tồn tại | | Nhà cung cấp | So tên đã chuẩn hóa hoặc mã nhà cung cấp | Khác biệt chưa giải thích được | | Tiền tệ | So khớp chính xác | Khác tiền tệ | | Dòng hàng | So SKU, số lượng, đơn giá, thành tiền | Thiếu dòng, thừa dòng, lệch giá | | Tổng tiền | So với tổng PO và quy tắc thuế nội bộ | Lệch vượt <ngưỡngchophép> | | OCR | Kiểm tra trường null, mâu thuẫn hoặc thiếu dữ liệu | Không đủ dữ liệu để kết luận |

Một cấu trúc kết quả cho node Rules có thể là:

json { "documentid": "<documentid>", "status": "review", "mismatchscore": "<điểm>", "reasons": [ { "field": "totalamount", "invoicevalue": "<giátrịhóađơn>", "povalue": "<giátrịpo>", "reason": "amountmismatch" } ], "requiresapproval": true }

mismatchscore chỉ nên phục vụ xếp hàng ưu tiên, không phải một “điểm tin cậy” để tự động thanh toán. Ví dụ, PO không tồn tại có thể cần chặn ngay cả khi các trường khác đều khớp.

Walkthrough: đẩy đúng ca lệch cho đúng người

Giả sử node email nhận được một hóa đơn. OCR lấy được số PO, nhà cung cấp, dòng hàng và tổng tiền. Node tra cứu tìm thấy PO tương ứng, nhưng node Rules phát hiện totalamount khác giá trị trên PO.

Thay vì gửi email chung chung kiểu “có lỗi”, workflow tạo một bản ghi trong Sheet hoặc database với:

Trạng thái: review Lý do: amountmismatch Liên kết file gốc Dữ liệu hóa đơn và PO đặt cạnh nhau Người phụ trách duyệt

Node chat hoặc email sẽ thông báo cho đúng người phụ trách, kèm đường dẫn tới tác vụ duyệt. Hành động như thanh toán, gửi xác nhận cho nhà cung cấp hoặc sửa dữ liệu ERP nên được đặt sau bước phê duyệt.

Tài liệu tham chiếu không cung cấp sẵn node cấu hình cho n8n, Make hay Power Automate. Khi triển khai, bạn có thể bắt đầu bằng webhook hoặc HTTP node để gọi dịch vụ OCR, sau đó ánh xạ phản hồi vào schema nội bộ.

Bảo vệ dữ liệu, log và vận hành lâu dài

Hóa đơn có thể chứa tên người liên hệ, địa chỉ hoặc dữ liệu tài chính. Presidio là SDK hỗ trợ nhận diện và khử định danh dữ liệu nhạy cảm trong văn bản và hình ảnh. Công cụ này hỗ trợ recognizer có sẵn hoặc tùy biến bằng NER, biểu thức chính quy, logic theo quy tắc và checksum.

Bạn có thể đặt Presidio trước node AI suy luận để che bớt dữ liệu không cần thiết trong log hoặc prompt. Tuy nhiên, README của Presidio lưu ý rằng phát hiện tự động không đảm bảo tìm được toàn bộ dữ liệu nhạy cảm. Vì vậy, vẫn cần kết hợp kiểm soát truy cập, chính sách lưu trữ và quy trình kiểm toán phù hợp với tổ chức.

Checklist trước khi đưa vào vận hành

[ ] Lưu API key trong secret manager hoặc credential store, không dán vào prompt hay Sheet. [ ] Log có documentid, thời điểm, phiên bản processor, kết quả rules và người duyệt. [ ] Không đưa toàn văn OCR vào kênh chat công khai. [ ] Retry có giới hạn cho lỗi tạm thời; lỗi dữ liệu chuyển sang người xử lý. [ ] Các action rủi ro như thanh toán, xóa file hoặc gửi email xác nhận cần có bước phê duyệt. [ ] Theo dõi quota và chi phí thực tế; trang danh sách processor không nêu thông tin giá. [ ] Test bằng hóa đơn scan mờ, nhiều dòng, thiếu PO và có chỉnh sửa thủ công.

Một workflow tốt không cố thay thế kế toán hay procurement. Nó làm phần việc máy móc: đọc, chuẩn hóa, đối chiếu, lưu bằng chứng và chỉ gọi con người khi có ngoại lệ. Đó là cách biến AI thành năng lực vận hành có thể kiểm soát.