Tự động hóa nghiệm thu: Đối chiếu ba bên, AI-OCR và ERP

Bộ phận mua hàng tìm đơn đặt hàng, kho xác nhận số lượng thực nhận, còn kế toán công nợ so phiếu giao hàng với hóa đơn. Mục tiêu của tự động hóa nghiệm thu không chỉ là đọc giấy nhanh hơn. Hệ thống phải liên kết đơn đặt hàng (PO), bằng chứng nhận hàng và hóa đơn nhà cung cấp ở cấp dòng; cho giao dịch phù hợp chính sách đi tiếp; chuyển chênh lệch hoặc thiếu bằng chứng cho người chịu trách nhiệm; rồi ghi kết quả đã phê duyệt vào ERP mà không tạo trùng. Bài viết trình bày mô hình vận hành, AI-OCR, ngoại lệ, kiểm soát và bằng chứng triển khai mà bên mua cần yêu cầu.

Tự động hóa nghiệm thu là hệ thống bằng chứng và quyết định

“Nghiệm thu” có thể chỉ nhiều quyết định khác nhau. Kho ghi nhận hàng đã đến. Chất lượng có thể giữ hàng chờ kiểm. Bộ phận yêu cầu xác nhận dịch vụ hoặc Milestone đã hoàn thành. Kế toán công nợ quyết định liệu bằng chứng có đủ để ghi nhận nghĩa vụ và thanh toán hay chưa. Nhà máy còn phải quản lý mã hàng, Lot, đơn vị tính, trạng thái kiểm tra, vị trí, giao từng phần và trả hàng.

Scanner và OCR không tự nối các quyết định đó. Nếu chưa định nghĩa khóa đối chiếu, chủ sở hữu chính sách và tuyến xử lý ngoại lệ, việc kiểm thủ công chỉ chuyển từ giấy lên màn hình. Hãy thiết kế một vòng khép kín:

1. Nhận PO, sự kiện nhận hàng, phiếu giao hàng, hóa đơn và Credit Note.
2. Phân loại chứng từ và xác định nhà cung cấp.
3. Trích xuất, chuẩn hóa số PO, dòng, mã hàng, số lượng, UOM, giá, thuế và tiền tệ.
4. Đối chiếu dòng PO–nhận hàng–hóa đơn và áp dụng Tolerance được duyệt.
5. Chuyển sai lệch vào hàng đợi ngoại lệ theo Reason Code.
6. Người có thẩm quyền kiểm bằng chứng rồi duyệt, từ chối, giữ hoặc sửa.
7. Ghi ERP theo nguyên tắc Idempotent và giữ Decision Trail.
8. Đối soát sau ghi sổ, theo dõi đảo, trả hàng và Credit Note.

AI có thể đọc chứng từ, xếp hạng Candidate và báo độ không chắc chắn. AI không thay người chịu trách nhiệm phê duyệt. NIST AI RMF Core tổ chức quản trị rủi ro AI theo Govern, Map, Measure và Manage. Đây là hướng dẫn tự nguyện, không thay luật địa phương, nhưng nhắc rằng AI-OCR cần Ownership, đo lường, quản lý thay đổi và ứng phó liên tục thay vì chỉ một điểm nghiệm thu lúc Go-live. NIST AI RMF Core

Đối chiếu ba bên là gì và vì sao phải làm ở cấp dòng

Đối chiếu ba bên thường so đơn đặt hàng, phiếu nhận hàng và hóa đơn nhà cung cấp. Tài liệu Microsoft Dynamics 365 mô tả Invoice Matching là so Invoice, PO và Product Receipt, đồng thời cho thấy Policy và Tolerance có thể cấu hình. Đây là tài liệu sản phẩm, không chứng minh mọi ERP đều vận hành giống nhau, nhưng giúp xác định câu hỏi thiết kế. Accounts payable invoice matching overview

Chỉ so tổng tiền là chưa đủ

Tổng Invoice có thể bằng tổng PO trong khi cấu thành dòng sai: thiếu hàng A và tính dư hàng B có thể triệt tiêu nhau. Một PO cũng có nhiều lần giao và nhiều Invoice. Nếu không giữ số lượng mở và lượng đã lập hóa đơn theo từng dòng, hệ thống khó phân biệt giao tách hợp lệ với hóa đơn trùng hoặc số dư chưa lập hóa đơn.

OpenPeppol BIS Billing 3.0 định nghĩa Business Term và Validation Rule cho hóa đơn có cấu trúc; Invoice Line cũng có thể mang Order-Line Reference. Dữ liệu có cấu trúc có thể bỏ bước OCR, nhưng không bảo đảm nhà cung cấp gửi Reference, Reference khớp Master hoặc không phát sinh ngoại lệ. Peppol BIS Billing 3.0 / Order-line reference

Không ép Non-PO và dịch vụ đi qua tuyến nhận hàng

Tiền thuê, điện nước, phí chuyên gia, Subscription, đi công tác và bảo trì khoán có thể không có Material Receipt. Dịch vụ có thể dùng Milestone, biên bản hoàn thành, Deliverable, kỳ dịch vụ hoặc phê duyệt của Requester. Chúng cần tuyến Non-PO hoặc Two-Way hợp lệ, không phải “ngoại lệ” không có Owner.

Hãy định nghĩa Requester, ngân sách, Account, hợp đồng, kỳ dịch vụ, Deliverable và Delegated Authority. Theo dõi xem Non-PO có trở thành cách né quy trình mua hàng hay không. Một tuyến riêng có kiểm soát mạnh hơn việc giả định mọi khoản thanh toán đều có cùng ba chứng từ.

Số hóa phiếu giao hàng và OCR đơn đặt hàng có kiểm soát

AI-OCR có thể trích Candidate Field từ PO, phiếu giao hàng và Invoice với Layout khác nhau. Kết quả phụ thuộc chất lượng ảnh, ngôn ngữ, Font, bảng, dấu mộc, chữ viết tay, nối trang và mẫu từng nhà cung cấp. Vì vậy một điểm “Accuracy” tổng không đủ để nghiệm thu Production.

Tách Confidence và mức ảnh hưởng theo Field

Sai một ký tự trong số Invoice có thể làm lọt Duplicate Check. Sai PO Line có thể gắn hóa đơn vào Receipt khác. Sai thuế ảnh hưởng hạch toán. Trong khi đó dấu câu trong ghi chú có thể không ảnh hưởng quyết định. Với từng Field, cần xác định:

• Mandatory hay Optional;
• mức ảnh hưởng nếu sai;
• điều kiện Machine Confirm;
• có thể kiểm bằng Master hoặc Arithmetic không;
• Confidence hay Inconsistency nào phải chuyển người;
• giữ giá trị gốc, giá trị sửa, người sửa và lý do ra sao.

Dù OCR Confidence cao, hồ sơ vẫn phải dừng nếu PO đã đóng, số lượng vượt Accepted Receipt, tính toán sai hoặc Supplier/Invoice đã tồn tại. Field Confidence thấp có thể được củng cố bằng Barcode, XML hoặc Portal. Xem thêm hướng dẫn đánh giá độ chính xác AI-OCR theo từng Field và tình huống.

Giảm tài liệu phải OCR cũng là tự động hóa

Khi nhà cung cấp gửi XML, EDI, API hoặc nhập Portal được, nên dùng giá trị có cấu trúc và giữ PDF làm bằng chứng theo chính sách. Revenue Department Thái Lan cung cấp thông tin chính thức về e-Tax Invoice & e-Receipt, còn ETDA công bố FAQ. Phạm vi áp dụng, định dạng, chữ ký, truyền, lưu giữ và xử lý thuế phải được đối chiếu hướng dẫn mới nhất và chuyên gia. Bài viết không phải tư vấn thuế. Revenue Department e-Tax / ETDA FAQ

Luồng tự động hóa xử lý hóa đơn đầu cuối

1. Tiếp nhận và kiểm soát bản gốc

Ghi Channel: Email, Portal, Scan, EDI, e-Tax hoặc kênh được duyệt khác. Dùng Intake ID và File Hash để Invoice đến cả giấy lẫn Email không tạo hai Case. Retention, Delete, Backup và Access phải theo chính sách pháp lý, thuế và Information Governance của doanh nghiệp.

2. Phân loại và xác định nhà cung cấp

Phân biệt Invoice, Delivery Note, Quotation và Credit Note. Xác định Supplier bằng nhiều tín hiệu: Tax ID, địa chỉ, Approved Email Domain và Master. Thay đổi tài khoản ngân hàng xuất hiện trên Invoice không được tự động cập nhật Vendor Master; phải đi qua quy trình xác minh độc lập.

3. Trích xuất, chuẩn hóa và kiểm tra

Chuẩn hóa Date Format, ký tự, Separator, tiền tệ, UOM, Tax Notation và Supplier Item. Kiểm Subtotal/Tax/Total, Mandatory Field, Duplicate, Supplier Status và Open PO. Tách OCR Extraction khỏi Business Validation để giải thích chính xác nguyên nhân dừng.

4. Đối chiếu dòng và Tolerance

Với từng Candidate PO Line, so Ordered Quantity, Accepted Receipt, Previously Invoiced và Current Invoice. Áp dụng Tolerance về số lượng, giá, số tiền, thuế, Freight và FX do doanh nghiệp duyệt. Tolerance là Business Policy, không phải đề xuất của AI. Nó có thể khác theo Company, Site, Supplier, Category và hạn mức; cần quy tắc ưu tiên khi nhiều Policy chồng nhau.

5. Hàng đợi ngoại lệ và Human Approval

Gắn Reason Code và chuyển Procurement, Receiving, Quality, Requester hoặc AP. Không chỉ hiện “Mismatch”; cần hiển thị Source, giá trị OCR, ERP, chênh lệch, lịch sử và Next Action trong cùng View. Người duyệt xem bằng chứng rồi ghi lý do duyệt, từ chối, giữ hoặc sửa.

6. Ghi ERP theo nguyên tắc Idempotent

API hoặc Bot có thể Timeout sau khi ERP Commit. Retry mù sẽ tạo trùng. Dùng External Processing ID và Duplicate Key gồm Company, Supplier, Invoice Number và Fiscal Context. Tách Pending, Processing, Posted, Failed, Reversed. Retry bằng Identity cũ và Query ERP trước khi tạo Transaction khác.

7. Đối soát sau ghi sổ

Trả ERP Document Number về Case. Đối chiếu hằng ngày số hồ sơ, số tiền, thuế và tiền tệ. Theo dõi Case đã nhận nhưng chưa Posted, ERP có giao dịch nhưng Workflow thiếu kết quả, và giao dịch đã Reversed nhưng Task còn mở. Automation chưa hoàn tất nếu hai bên chưa khớp.

Microsoft cũng mô tả Pattern Automated Vendor Invoice Matching và Workflow Submission cho Dynamics 365. Đây là ví dụ cấu hình, không phải cam kết Touchless Rate hay Control Effectiveness. Phải kiểm Configuration, Permission, Log, Error Handling và Change Process của ERP thực tế. Automated vendor invoice matching

Ngoại lệ quyết định tự động hóa nghiệm thu có vận hành được hay không

Demo Normal Path thường dễ. Thời gian vận hành tích tụ ở nơi bằng chứng thiếu, có nhiều cách hiểu và Ownership đi qua nhiều phòng ban.

Exception Queue nên có Case ID, Reason, Materiality, Amount/Currency, Age, Owner, Deadline, Related Document, Variance, Decision, Hold Reason và Resume Condition. Đây là Work Queue có SLA và Escalation, không phải thêm một Inbox.

Không được nhầm Model Confidence với Business Tolerance. Confidence biểu thị độ không chắc khi đọc; Tolerance là chính sách được duyệt. Case chỉ đi tiếp khi bằng chứng đủ, cả hai điều kiện đạt và Control khác như Duplicate, Supplier Status, Access không yêu cầu dừng.

Tích hợp OCR RPA: ưu tiên giao diện ổn định, quản trị Screen Automation

Nếu ERP có API hoặc Import Service được Support, việc quản lý State, Error và Idempotency thường rõ hơn. RPA có ích với Legacy System hoặc cầu nối tạm thời, nhưng Field màn hình, Dialog và Response Time có thể đổi.

Nghiệm thu tích hợp OCR RPA nên gồm:

• Bot ID riêng với Least Privilege;
• không dùng chung Credential của cá nhân;
• Log liên kết Case ID và ERP Document Number;
• Monitoring và Safe Stop khi UI thay đổi;
• Query trạng thái trước Retry sau Timeout;
• không dựa vào việc né CAPTCHA hoặc MFA;
• Failed Queue, Authorized Retry và Manual Fallback;
• Regression Test trước Production Change; và
• tiêu chí ngừng Bot khi có Supported Interface.

Nếu Standard ERP không đáp ứng, hướng dẫn quyết định phát triển tùy chỉnh hệ thống quản lý sản xuất giúp làm rõ Interface Boundary và Ownership dài hạn.

Audit Trail, phân tách nhiệm vụ và Data Control

Phân tách nhiệm vụ

Không tập trung quyền tạo PO, nhận hàng, nhập Invoice và duyệt thanh toán vào cùng một vai trò. Nếu Site nhỏ không thể tách hoàn toàn, cần Compensating Control như Review cấp trên, Change Report, ngưỡng tiền và đối soát sau. Đưa cả AI/RPA Service ID vào Role Matrix.

Bằng chứng truy vết

Mỗi Case cần tham chiếu Source File, Received Time, Model/Version, Extracted Value/Confidence, Master Lookup, Matching Rule/Version, Variance, Before/After Correction, Reviewer, Decision Reason và ERP Request/Response. Lưu Log trong kho có kiểm soát quyền, không phải Spreadsheet ai cũng sửa được.

Change Management

Khi Model, Prompt, OCR Template, Supplier Mapping, Tolerance, Tax Rule hoặc ERP Interface đổi, chạy Regression Test bằng Evaluation Set ổn định. Hợp đồng cần quy định Change Notice, Reassessment, Rollback, Incident Response và Manual Continuity.

GS1 EPCIS 2.0 là chuẩn Visibility Event có thể mô tả What, When, Where và Why trong Supply Chain. Nó hỗ trợ bằng chứng nhận hàng, nhưng một Event không tự chứng minh Quality Acceptance, Ownership, Contract Performance hay Liability. Những quyết định đó vẫn tách biệt. GS1 EPCIS 2.0

PoC 30/60/90 ngày

PoC phải tạo bằng chứng cho quyết định vận hành, không chỉ Demo OCR bắt mắt.

Ngày 0–30: định nghĩa và Baseline

• Giới hạn Company, Site, Supplier, Document, Language và ERP.
• Quan sát Flow hiện tại từ Intake đến Posting; đo Wait/Rework.
• Lập Data Dictionary PO, Receipt, Invoice và Exception.
• Freeze Evaluation Set gồm Normal và Critical Exception.
• Thống nhất Critical Field, Tolerance, Authority và Retention.
• Đánh giá API, RPA, EDI và Structured Invoice.
• Định nghĩa Gate: Continue, Revise, Stop, Expand.

Ngày 31–60: Shadow và học từ ngoại lệ

Chạy nhóm Supplier hoặc Document hạn chế. Nhân viên vẫn thực hiện quy trình chuẩn, hệ thống mới đề xuất Extraction và Matching. Ghi Wrong Extraction, Wrong Link, Missed Exception và Unsafe Straight-through. Chủ động đưa Partial Delivery, UOM, Freight, Tax và Credit Note vào Test.

Ngày 61–90: Controlled Live và Handover

Chỉ bật Scope đã đạt. Vận hành Exception Queue, Approval, Idempotent Posting, Daily Reconciliation và Manual Fallback. Xác nhận đội nội bộ làm First-line Support và Regression Test được. Ngày 90 là Decision Gate để tiếp tục, sửa, dừng hoặc mở rộng, không phải ngày kết thúc mặc định.

KPI phải vượt ra ngoài OCR Accuracy

Cố định Numerator, Denominator và Exclusion; phân theo Supplier, Document, Language, Site và Exception. Trung bình có thể che Critical Error ít gặp.

Đặt Target từ Baseline, Risk Appetite và Sample Size của doanh nghiệp; không biến Benchmark chung của Vendor thành Guarantee.

Nội dung cần có trong RFP

Nêu Company, Site, Volume/Variation, Language, Page, Channel, Supplier, PO/Non-PO, Goods/Service, Partial Delivery, Currency, Tax Context, ERP và Approval Structure; đồng thời nêu giới hạn Sample và Anonymization.

Yêu cầu Extraction Field, Line Matching, Tolerance Hierarchy, Exception Reason, Queue/SLA, Segregation, Approval, Duplicate Prevention, Idempotent Posting, Reversal, Credit Note, Log, Retention, Search và Audit Export. Chỉ ghi “hỗ trợ AI-OCR” không đủ để so sánh.

Non-functional phải bao gồm Availability, Performance, Security, Encryption, Data Location, Subprocessor, Backup, Monitoring, Incident, Recovery, Change Notice, Model Update, Support và Exit Data Return/Deletion.

Tách TCO thành Setup, phí Document/Page/Field, AI Usage, Integration, RPA/ERP Licence, Environment, Monitoring, Support, Supplier Onboarding, Layout Change, Retraining, Audit, Storage và Internal Operation. Xem hướng dẫn so sánh chi phí AI-OCR để so đơn vị tính. Bài viết không đặt giá dự án giả định vì Scope và Volume quyết định chi phí.

Acceptance Test phải nhấn mạnh ngoại lệ và Retry

Dùng phân bố dữ liệu thật cùng Critical Case ít gặp: Scan nghiêng, độ phân giải thấp, dấu mộc, bảng nhiều trang, Nhật/Thái/Anh, sửa tay, mã gần giống và khác UOM. Phải kiểm rằng:

• Invoice từ hai Channel chỉ tạo một Case;
• PO đúng nhưng PO Line sai thì dừng;
• Partial Delivery, Split Invoice, Quantity/Price Variance có Reason riêng;
• Non-PO và Service đi vào Alternative Route được duyệt;
• Freight, Tax, Currency và FX không bị đoán để cho qua;
• Low Confidence, Arithmetic Error và Master Mismatch đến người;
• Role Control hoạt động khi một người từng tạo PO hoặc Receipt;
• Timeout sau ERP Commit không tạo Duplicate;
• ERP Outage giữ thứ tự Queue và Recovery có kiểm soát;
• Return/Credit Note nối được chứng từ gốc;
• Model/Rule/UI Change qua Regression; và
• Export Evidence từ Intake đến Posting được.

Nghiệm thu cần Zero-tolerance Gate cho Critical Failure đã định nghĩa, cùng Exception Resolution, Segregation, Retry, Reconciliation và Fallback. Chỉ dùng trung bình là không đủ.

Checklist trước khi triển khai

• [ ] Đã tách quyết định nhận hàng vật lý, chấp nhận chất lượng và đối chiếu hóa đơn.
• [ ] Có Key nối PO, Receipt và Invoice ở cấp dòng.
• [ ] Có tuyến hợp lệ cho Non-PO, Service, Partial Delivery và Split Invoice.
• [ ] Đã chỉ định Owner cho Tax, Freight, Currency, FX và Credit Note.
• [ ] Quản trị AI Confidence riêng với Business Tolerance.
• [ ] Low Confidence và Inconsistency được chuyển người; AI không thay người phê duyệt.
• [ ] Segregation of Duties và Compensating Control được ghi trong Role Matrix.
• [ ] ERP Posting có Idempotency Key và Reconciliation sau ghi sổ.
• [ ] Có và đã thử RPA Recovery cùng Manual Fallback.
• [ ] KPI gồm Unsafe Straight-through, Exception Time, Rework và ERP Variance.
• [ ] PoC 90 ngày có Gate Continue, Revise, Stop và Expand.
• [ ] TCO gồm Internal Operation và thay đổi trong tương lai.

FAQ

Nên bắt đầu tự động hóa nghiệm thu từ đâu?

Bắt đầu tại một Site với tập chứng từ giới hạn. Quan sát Flow đầy đủ, tìm Key cấp dòng, Baseline ngoại lệ và chỉ rõ người phê duyệt. Freeze Evaluation Set trước khi so công cụ.

Chỉ số hóa phiếu giao hàng có đủ để đối chiếu ba bên không?

Không. Phiếu giao hàng có thể không phản ánh lượng thực nhận, trạng thái kiểm tra, trả hàng hoặc Service Completion. Phải nối Authoritative Receipt với PO và Invoice Line.

OCR đơn đặt hàng cần chính xác bao nhiêu phần trăm?

Không có một tỷ lệ cho mọi doanh nghiệp. Đánh giá Critical Field riêng, đo Wrong Line Link và Unsafe Straight-through. Chuyển Low Confidence và Inconsistency cho người cũng là tiêu chí nghiệm thu.

Tự động hóa xử lý hóa đơn có bỏ người phê duyệt không?

Không. Low-risk Case phù hợp Policy có thể tự đi bước tiếp, nhưng Delegated Authority và Accountability vẫn thuộc tổ chức. Ngoại lệ và thay đổi tác động cao cần người phù hợp xem bằng chứng.

Tích hợp OCR RPA có rẻ hơn API không?

Initial Development có thể nhìn nhỏ hơn, nhưng phải so TCO gồm UI Change, Monitoring, Failure, Retry, Licence và Internal Operation. Supported API thường quản lý State và Idempotency rõ hơn.

e-Tax của Thái Lan có loại bỏ mọi quy trình giấy không?

Điều đó phụ thuộc phạm vi áp dụng, thỏa thuận đối tác, định dạng, chữ ký, truyền, lưu và chính sách nội bộ. Hãy kiểm Revenue Department/ETDA mới nhất và xin tư vấn chuyên môn. Định dạng điện tử và đối chiếu nghiệp vụ là hai bài toán khác nhau.

PoC chỉ Demo OCR có đủ không?

Không đủ cho Production Decision. Phải thử Line Matching, Exception, Permission, Duplicate Prevention, Reconciliation và Continuity trong Scope giới hạn.

Kết luận: tự động hóa vòng khép kín, không chỉ nhập liệu

Tự động hóa nghiệm thu hoàn tất khi PO, Receipt và Invoice Line được kết nối; Tolerance do doanh nghiệp duyệt được áp dụng; Non-PO, Service, Partial Delivery, Quantity, Price, Tax, Freight, Currency, FX và Credit Note được chuyển đến người chịu trách nhiệm; và kết quả đã duyệt được ghi ERP không trùng. AI-OCR đề xuất dữ liệu và bộc lộ độ không chắc, không trở thành người phê duyệt. Segregation of Duties, Audit Evidence, Reconciliation và Change Control cho phép cải thiện tốc độ cùng kiểm soát.

TOMAS TECH có thể hỗ trợ ngay khi Scope chứng từ và phương thức Integration chưa hoàn chỉnh—từ Current-state Mapping, quy tắc Three-Way Matching và Evaluation Set AI-OCR đến Exception Queue và PoC 30/60/90 ngày. Để trao đổi thiết kế phù hợp cho nhà máy tại Thái Lan hoặc ASEAN, vui lòng liên hệ chúng tôi.

Tài liệu tham khảo

• Thailand Revenue Department: e-Tax Invoice & e-Receipt
• ETDA: e-Tax Invoice & e-Receipt FAQ
• Microsoft Learn: Accounts payable invoice matching overview
• Microsoft Learn: Automated vendor invoice matching
• OpenPeppol: Peppol BIS Billing 3.0
• OpenPeppol: Invoice-line order-line reference
• NIST: AI RMF Core
• GS1: EPCIS 2.0

*Bài viết là thông tin chung để lập kế hoạch hệ thống và quy trình, không phải tư vấn pháp lý, thuế, kế toán; không bảo đảm hiệu năng sản phẩm hoặc hiệu quả đầu tư. Hãy xác nhận phạm vi áp dụng, lưu giữ, phê duyệt và hạch toán theo hướng dẫn chính thức mới nhất cùng chuyên gia nội bộ hoặc bên ngoài phù hợp.*