InferioLàm sao tổng hợp hoá đơn từ hàng chục nhà cung cấp về một bảng dữ liệu duy nhất?
8 tháng 7, 2026 · 6 phút đọc
Bạn tổng hợp dữ liệu hoá đơn bằng cách trích xuất mọi hoá đơn — PDF, bản scan, hay ảnh chụp, từ bất kỳ nhà cung cấp nào — về một schema chung: nhà cung cấp, số hoá đơn, ngày, line item, thuế theo từng thuế suất, tổng tiền. AI OCR đảm nhận bước chuẩn hoá vốn trước đây đồng nghĩa với việc gõ lại từng hoá đơn vào Excel, nên bảng tổng hợp tự hình thành khi tài liệu đến thay vì dồn vào đợt chạy nước rút cuối tháng. Khi dữ liệu đã nằm trong một cấu trúc, báo cáo chi tiêu, đối chiếu công nợ và phát hiện hoá đơn trùng không còn là những dự án thủ công nữa.
Vì sao dữ liệu hoá đơn khó tổng hợp đến vậy?
Dữ liệu hoá đơn bị phân mảnh trên hai trục cùng lúc. Trục thứ nhất là layout: mỗi nhà cung cấp tự thiết kế mẫu hoá đơn của mình, nên tổng tiền nằm góc trên bên phải ở hoá đơn này, góc dưới bên trái ở hoá đơn kia, còn phần tách thuế có thể là một bảng, một dòng chú thích, hoặc không có luôn. Một công ty mua hàng từ 30 nhà cung cấp thực chất đang phải đọc 30 định dạng tài liệu khác nhau mà cái nào cũng tự nhận là "hoá đơn".
Trục thứ hai là kênh tiếp nhận. Hoá đơn đến dưới dạng file PDF đính kèm email, dạng giấy phải scan, và ngày càng nhiều là ảnh chụp gửi qua ứng dụng chat — nhà cung cấp gửi ảnh hoá đơn qua Zalo hay LINE là chuyện thường ngày với nhiều doanh nghiệp SME ở Việt Nam và Nhật Bản. Không nguồn nào trong số này tạo ra dữ liệu có cấu trúc; chúng chỉ tạo ra pixel.
Cách xử lý quen thuộc là dùng sức người: cuối tháng, một người bên kế toán mở từng file và gõ lại nhà cung cấp, ngày, số tiền, thuế vào một bảng Excel, mỗi hoá đơn một dòng. Cách này chạy được ở mức 20 hoá đơn mỗi tháng và sụp đổ ở mức 200 — dữ liệu vẫn phân mảnh cho tới khi có người ngồi gom lại, nghĩa là báo cáo luôn chậm vài tuần và việc đối chiếu với chứng từ thanh toán là một cuộc dò từng dòng.
Chuẩn hoá hoá đơn mọi định dạng về một schema chung thế nào?
Bước chuẩn hoá chính là chỗ AI OCR chứng minh giá trị. Một mô hình vision-language — mô hình đọc đồng thời layout và chữ trên tài liệu, giống cách con người đọc — trích xuất các trường theo ý nghĩa thay vì theo vị trí, nên không cần template riêng cho từng nhà cung cấp. Dù nguồn là PDF gốc, bản scan TIFF nhiều trang, hay ảnh JPG chụp nghiêng, kết quả đầu ra đều rơi vào cùng một bộ trường: tên nhà cung cấp, số hoá đơn, ngày phát hành, line item, thuế tách theo từng thuế suất (8% và 10% với hoá đơn Nhật), và tổng tiền.
Schema đầu ra chung đó chính là cốt lõi của việc tổng hợp: 30 layout nhà cung cấp đi vào, một bảng dữ liệu đi ra. Một nhà cung cấp mới với layout hệ thống chưa từng thấy cũng không cần một dự án setup — mô hình đọc được ngay từ tài liệu đầu tiên, vì nó đang trả lời câu hỏi "giá trị nào là tổng tiền?" chứ không phải "toạ độ X có gì?".
Chuẩn hoá chỉ có ý nghĩa khi tin được vào con số, nên mỗi trường trích xuất đều kèm một confidence score — ước lượng của chính mô hình về xác suất giá trị đó đúng. Trường nào dưới ngưỡng (mặc định của Inferio là 0.75) sẽ được chuyển cho người duyệt trong giao diện sửa lỗi, thay vì âm thầm chảy vào bảng tổng hợp. Trong thực tế, điều đó nghĩa là con người chỉ kiểm vài tấm ảnh mờ và layout bất thường, chứ không phải soát lại mọi hoá đơn.
Từ dữ liệu đã chuẩn hoá làm được những báo cáo gì?
Một bảng hoá đơn đã tổng hợp biến những câu hỏi từng tốn cả buổi chiều lọc Excel thành các truy vấn đơn giản. Chi tiêu theo nhà cung cấp mỗi tháng, chi tiêu theo loại chi phí, xu hướng chi phí qua từng quý — tất cả chỉ cách một thao tác nhóm dữ liệu khi mọi hoá đơn đã dùng chung một bộ trường.
Việc đối chiếu cũng được nâng cấp tương tự. Khi số hoá đơn, nhà cung cấp và số tiền là các trường có cấu trúc, việc khớp hoá đơn với chứng từ thanh toán hay sổ công nợ trở thành một phép join thay vì so từng dòng. Cũng chính ba trường đó làm lộ ra hoá đơn trùng: hai hoá đơn cùng nhà cung cấp, cùng số, cùng số tiền gần như chắc chắn là một hoá đơn bị nộp hai lần — loại lỗi gần như vô hình khi dữ liệu nằm rải trong 200 file PDF riêng lẻ.
Với công ty hoạt động tại Nhật, còn một phép kiểm tra quan trọng nữa: theo Qualified Invoice System, thuế đầu vào chỉ được khấu trừ nếu T-number của bên phát hành (mã đăng ký đơn vị phát hành hoá đơn) hợp lệ. Vì T-number là một trường được trích xuất, từng mã có thể được xác thực tự động qua API công khai của Tổng cục Thuế Nhật Bản (NTA) — mỗi hoá đơn trong bảng tổng hợp đã được kiểm điều kiện khấu trừ từ trước, thay vì phải rà soát hàng loạt lúc quyết toán.
Đưa dữ liệu tổng hợp về đâu — Excel, phần mềm kế toán hay ERP?
Với các đội làm báo cáo trên bảng tính, export là điểm khởi đầu: bảng tổng hợp tải xuống thành một file, thay thế cuốn sổ Excel cuối tháng dựng bằng tay bằng một file sinh ra từ dữ liệu đã kiểm chứng. Đây là đích đến ít tự động nhất, nhưng thường là đích đầu tiên — nó chứng minh dữ liệu đúng trước khi bất kỳ hệ thống hạ nguồn nào phụ thuộc vào nó.
Với phần mềm kế toán, sync trực tiếp tốt hơn một file. Inferio kết nối với freee và MoneyForward qua OAuth, nên hoá đơn đã duyệt được ghi thẳng thành bút toán mà không cần bước import CSV ở giữa — việc tổng hợp diễn ra ở thượng nguồn, hệ thống kế toán nhận về các bút toán sạch.
Với hệ thống nội bộ — ERP, data warehouse, hay bộ công cụ BI — REST API cung cấp kết quả có cấu trúc, và signed webhook đẩy từng tài liệu đã xử lý về endpoint của bạn ngay khi qua bước duyệt, kèm chữ ký để server của bạn xác thực và loại bỏ payload giả mạo. Và vì luật Nhật yêu cầu lưu trữ chứng từ giao dịch điện tử theo Electronic Bookkeeping Law, bản gốc lẫn dữ liệu trích xuất được lưu trong kho lưu trữ tuân thủ suốt 7 năm — tổng hợp dữ liệu không làm nó tách rời khỏi những tài liệu chứng minh cho nó.
Giải đáp nhanh
- Bao nhiêu nhà cung cấp hay hoá đơn mỗi tháng thì nên tự động hoá thay vì gõ tay?
- Ngưỡng này thấp hơn nhiều đội vẫn nghĩ: độ vất vả tăng theo số nhà cung cấp nhiều hơn là số hoá đơn, vì mỗi nhà cung cấp là một layout riêng mà con người phải làm quen lại mỗi tháng. Theo kinh nghiệm chung, vượt khoảng 10 nhà cung cấp hoặc 50 hoá đơn mỗi tháng, quy trình gõ-lại-vào-Excel bắt đầu ngốn đáng kể giờ công kế toán và sinh lỗi nhập liệu — nguồn dạng ảnh chụp và bản scan còn kéo ngưỡng này xuống thấp hơn, vì đó là loại chậm gõ tay nhất.
- Hoá đơn tiếng Nhật, tiếng Anh, tiếng Việt lẫn lộn có tổng hợp chung được không?
- Được. Một mô hình vision-language đọc được tài liệu tiếng Anh, tiếng Nhật và tiếng Việt — kể cả hoá đơn trộn ngôn ngữ, như hoá đơn tiếng Nhật có line item tiếng Anh — mà không cần engine riêng cho từng ngôn ngữ. Vì mọi tài liệu đều được map về cùng một schema đầu ra bất kể ngôn ngữ, một tờ 請求書 từ Tokyo và một hoá đơn từ Hà Nội nằm chung một bảng với cùng một bộ cột.
- Có phát hiện được hoá đơn trùng lặp không?
- Dữ liệu có cấu trúc làm được điều mà file PDF không bao giờ làm được. Khi số hoá đơn, nhà cung cấp và số tiền đã là các trường trong một bảng, hai dòng khớp cả ba giá trị gần như chắc chắn là một hoá đơn bị nộp hai lần — do gửi lại, scan lại, hay hai người cùng forward một email. Bắt được nó là một truy vấn trên dữ liệu đã chuẩn hoá, không phải bài kiểm tra trí nhớ của người nhập liệu.
- Có thay được file Excel tổng hợp thủ công không?
- Nó thay phần thủ công, không nhất thiết thay bảng tính. Cuốn sổ cuối tháng ai đó dựng bằng cách gõ lại hoá đơn trở thành một file export từ dữ liệu đã được kiểm chứng — vẫn định dạng quen thuộc, chỉ bớt đi hàng giờ gõ tay và lỗi nhập liệu. Khi đội vượt quá quy mô của bảng tính, cùng một bộ dữ liệu chuẩn hoá đó chuyển sang phần mềm kế toán hoặc data warehouse qua sync hay API, mà không phải thay đổi cách thu nhận hoá đơn.