Cuối tháng nào, phòng kế toán cũng phải ngồi đối chiếu hàng trăm hóa đơn, sao kê ngân hàng và chứng từ nội bộ. Trong quá trình làm việc với nhiều đội tài chính, chúng tôi nhận ra một điều khá rõ: nút thắt hiếm khi nằm ở việc thiếu phần mềm. Nó nằm ở chỗ dữ liệu đến từ quá nhiều nguồn, và mỗi nguồn lại trình bày theo một kiểu riêng. Bài này chúng tôi muốn đi qua ứng dụng AI cho phòng kế toán dưới góc nhìn kỹ thuật, để bạn hình dung rõ nó giải quyết được việc gì và cần chuẩn bị những gì trước khi bắt tay vào.
Bài toán đối soát: nơi kế toán mất nhiều giờ nhất
Hóa đơn, sao kê và chứng từ đến dưới nhiều định dạng
Một phòng kế toán thường nhận dữ liệu từ rất nhiều đầu vào. Hóa đơn PDF đến từ nhà cung cấp. Sao kê ngân hàng xuất ra file Excel hoặc CSV. Phiếu thu chi nhiều khi chỉ là bản scan giấy. Chứng từ điện tử lại đến từ hệ thống nội bộ. Ngay cả hai hóa đơn cùng loại từ hai nhà cung cấp khác nhau cũng có thể lệch nhau về vị trí mã số thuế, kiểu chữ và cách kẻ bảng.
Khi khối lượng tăng, đặc biệt ở doanh nghiệp vừa và lớn, đối chiếu bằng tay rất dễ sai sót. Chúng tôi từng chứng kiến một kế toán viên mất gần nửa buổi chỉ để xử lý một lô hóa đơn nhỏ, chỉ vì định dạng không đồng nhất. Đó là điểm nghẽn thật sự, và cũng là chỗ tự động hóa mang lại hiệu quả rõ ràng nhất.
Vì sao OCR thuần chưa đủ
Nhiều đơn vị đã thử OCR để chuyển chứng từ scan thành văn bản. Nhận dạng ký tự thường khá ổn. Vấn đề là kết quả vẫn chỉ là một khối chữ thô. Hệ thống không biết đâu là mã số thuế, đâu là số tiền cần khớp, đâu là tên đối tác. Vì vậy phía sau OCR phải có thêm một lớp hiểu ngữ cảnh, học ý nghĩa của từng trường dữ liệu ngay cả khi vị trí của chúng thay đổi theo từng nhà cung cấp.
Ba cách tiếp cận thường gặp khác nhau khá rõ ở khả năng đi tới bước đối soát tự động. OCR thuần cho ra chữ nhưng không hiểu chữ đó là gì. OCR kèm quy tắc cứng chỉ chạy tốt với mẫu cố định, đổi mẫu là vỡ. OCR kết hợp mô hình AI linh hoạt hơn nhiều, và chỉ khi có lớp này, việc đối soát theo ngưỡng tin cậy mới thực sự khả thi.
Pipeline kỹ thuật để bóc tách và khớp dữ liệu
OCR đầu vào kết hợp mô hình trích xuất trường
Một pipeline thường bắt đầu bằng tiền xử lý ảnh: chỉnh góc nghiêng, tăng độ tương phản, loại nhiễu nền. Sau đó OCR chuyển ảnh thành văn bản thô. Phần quan trọng nhất nằm ở bước kế tiếp, khi một mô hình nhận diện thực thể có tên gắn nhãn cho từng đoạn chữ. Số hóa đơn, ngày phát hành, tổng tiền và mã số thuế người bán được gắn đúng trường của nó.
Đầu ra là một cấu trúc dữ liệu sạch, thường ở dạng JSON. Nếu bước này bóc sai một trường, mọi bước phía sau sẽ sai theo. Vì vậy đội ngũ bên mình luôn kiểm thử kỹ đoạn này trước khi nối sang các bước khác. Thường chỉ cần vài chục chứng từ mẫu đa dạng là đã lộ ra những trường hay bị nhầm.
Quy tắc khớp tự động và hàng đợi ngoại lệ
Sau khi trích xuất xong, hệ thống so khớp dữ liệu với các nguồn đối chiếu. Số hóa đơn được so với đơn đặt hàng. Tổng tiền được kiểm tra với hợp đồng. Ngày giao dịch được đối chiếu với điều khoản thanh toán đã thỏa thuận. Bản ghi nào qua hết các quy tắc sẽ được duyệt tự động và đồng bộ sang hệ thống kế toán.
Bản ghi nào lệch sẽ đi vào hàng đợi ngoại lệ để người duyệt xem xét. Mô hình này thường được gọi là human-in-the-loop. Máy xử lý nhanh những trường hợp rõ ràng, còn con người giữ quyền quyết định ở những điểm không chắc chắn. Với giai đoạn đầu triển khai, đây là cách cân bằng hợp lý nhất mà chúng tôi từng áp dụng.
Ghi log đầy đủ để phục vụ kiểm toán
Điều hay bị bỏ qua khi thiết kế là ghi log chi tiết cho mọi hành động. Với kế toán, khả năng truy vết là bắt buộc. Cần biết ai đã duyệt gì, vào lúc nào, dựa trên kết quả trích xuất nào, và mức tin cậy của mô hình khi đó là bao nhiêu. Thiếu những thông tin này, việc kiểm toán sẽ rất vất vả dù hệ thống chạy tốt đến đâu.
Log còn là nguồn dữ liệu để đội kỹ thuật phân tích lỗi và cải thiện mô hình theo thời gian. Khả năng quan sát toàn hệ thống, hay observability, là yếu tố chúng tôi luôn đặt lên hàng đầu khi làm việc với dữ liệu tài chính.
Tích hợp vào phần mềm kế toán đang dùng
Đẩy kết quả qua API về hệ thống hiện hữu
Nhiều doanh nghiệp lo rằng phải thay toàn bộ phần mềm mới làm được việc này. Thực tế, giải pháp tốt thường được thiết kế để tích hợp, không thay thế. Sau khi khớp thành công, dữ liệu được đẩy qua API vào phần mềm kế toán đang dùng, dù đó là MISA, Fast Accounting hay một hệ thống ERP lớn hơn.
Đội kỹ thuật cần hiểu kỹ cấu trúc API của hệ thống đích, đặc biệt là cách xử lý giao dịch thất bại và cơ chế idempotency để tránh ghi trùng. Đây thường là phần phát sinh nhiều vấn đề nhất trong giai đoạn go-live, nên dành thời gian kiểm thử từ sớm sẽ tiết kiệm rất nhiều công sửa về sau.
Học từ các triển khai thực tế
Thay vì tự xây từ con số không, nhiều đội bắt đầu bằng việc nghiên cứu tài liệu và các ví dụ đã được kiểm chứng. Bạn có thể tham khảo thêm ứng dụng AI cho phòng kế toán để nắm bức tranh tổng thể trước khi đi vào thiết kế chi tiết.
Từ kinh nghiệm của chính mình, chúng tôi rút ra vài bài học. Nên chọn loại chứng từ đồng nhất nhất để làm điểm bắt đầu. Nên dựng môi trường staging để thử toàn bộ pipeline trước khi nối với hệ thống thật. Nên đào tạo kế toán viên cách đọc kết quả và xử lý hàng đợi ngoại lệ ngay từ đầu. Và nên triển khai theo từng giai đoạn, tránh chuyển đổi toàn bộ cùng lúc.
Trước khi rót ngân sách, bạn cũng nên đọc thêm về cách thẩm định năng lực kỹ thuật của một công ty ứng dụng AI, để tránh chọn sai đối tác ngay từ đầu. Chọn đúng đối tác quan trọng không kém việc chọn đúng công nghệ.
Ngoài ra, nếu bạn đang cân nhắc hạ tầng dữ liệu nền tảng, bài hạ tầng dữ liệu trước khi ứng dụng AI cũng là phần đáng đọc, vì nguyên tắc chuẩn hóa dữ liệu áp dụng khá giống nhau giữa các phòng ban.
Cơ chế rollback khi kết quả trích xuất sai
Không hệ thống nào chính xác tuyệt đối, nhất là khi mô hình chưa được tinh chỉnh theo đặc thù chứng từ của doanh nghiệp. Vì vậy cơ chế rollback là phần không thể thiếu. Khi một bản ghi đã được duyệt tự động nhưng sau đó bị phát hiện sai, hệ thống cần đánh dấu bản ghi đó để xem lại mà không xóa log gốc.
Đồng thời, hệ thống phải hỗ trợ hủy hoặc điều chỉnh bút toán đã đẩy sang phần mềm kế toán thông qua API tương ứng. Lý do rollback cũng cần được ghi lại cùng dữ liệu trích xuất gốc, và nên có cảnh báo để đội kỹ thuật xem lại ngưỡng tự động duyệt. Nhờ vậy, rollback không chỉ là lưới an toàn mà còn là nguồn dữ liệu để cải thiện hệ thống theo thời gian.
Kết luận: tự động hóa kế toán cần độ chính xác có thể kiểm chứng
Đặt ngưỡng tin cậy và giữ con người ở vòng duyệt cuối
Tự động hóa không có nghĩa là loại bỏ con người, nhất là trong kế toán, nơi một sai sót có thể kéo theo hệ quả pháp lý và tài chính thật sự. Nguyên tắc chúng tôi luôn áp dụng là chỉ tự động duyệt khi độ tin cậy vượt ngưỡng đã đặt. Mọi trường hợp còn lại phải có người kiểm tra trước khi ghi nhận.
Ngưỡng này nên được hiệu chỉnh theo thực tế vận hành. Ban đầu nên đặt cao, rồi hạ dần khi đã có đủ dữ liệu xác nhận độ chính xác. Một hệ thống tốt không phải là hệ thống không bao giờ sai, mà là hệ thống biết mình có thể sai ở đâu và xử lý điều đó một cách minh bạch.
Bắt đầu từ một loại chứng từ rồi nhân rộng
Đừng cố tự động hóa tất cả cùng lúc. Chúng tôi thường khuyên khách hàng chọn một loại chứng từ làm điểm xuất phát. Hóa đơn điện tử theo chuẩn quốc gia thường là lựa chọn hợp lý vì tính đồng nhất cao. Khi độ chính xác đã ổn định và đội ngũ đã quen quy trình, mới nên mở rộng sang sao kê ngân hàng, phiếu chi hay các chứng từ phức tạp hơn.
Cách làm từng bước này giúp kiểm soát rủi ro và cho phép cả kế toán lẫn kỹ thuật cùng điều chỉnh quy trình. Nếu bạn đang nghiên cứu chủ đề này, hãy dành thời gian thiết kế kỹ pipeline trích xuất và cơ chế kiểm soát chất lượng trước khi chọn công cụ hay nhà cung cấp. Nền tảng vững ngay từ đầu sẽ quyết định khả năng nhân rộng của cả dự án về sau.
