GLM 5.2 đạt độ chính xác ngang ngửa kế toán viên trong báo cáo thuế

Chúng tôi đã đánh giá hiệu suất của GLM 5.2, một mô hình AI mã nguồn mở, trong tác vụ chuẩn bị tờ khai thuế giá trị gia tăng (VAT) hàng quý cho một doanh nghiệp nhỏ tại Vương quốc Anh. Chuẩn bị tờ khai VAT là một nhiệm vụ tuân thủ điển hình đối với các doanh nghiệp vừa và nhỏ (SME) tại Anh. Các doanh nghiệp đăng ký VAT tại Anh bắt buộc phải lập tờ khai VAT mỗi quý. Đối với các SME, tờ khai VAT thường được thực hiện bởi một công ty kế toán bên ngoài. Phí dịch vụ thông thường cho công việc này rơi vào khoảng 750–2.100 GBP/quý (1.000–2.800 USD/quý). Theo quy định pháp luật, tờ khai VAT phải được nộp trong vòng 5 tuần kể từ khi kết thúc quý. Việc nộp chậm sẽ dẫn đến các khoản phạt đáng kể.

Trong quá trình thử nghiệm, GLM 5.2 có thể chuẩn bị một tờ khai VAT hàng quý gần như hoàn hảo cho một SME tại Anh, xử lý 59 giao dịch trong 68 phút với chi phí token thô là 2,73 USD. GLM 5.2 phải nhập từng giao dịch vào phần mềm kế toán thông qua công cụ dòng lệnh (CLI). Chúng tôi đã chấm điểm trạng thái cuối cùng của phần mềm kế toán dựa trên độ chính xác của 6 tiêu chí cho mỗi giao dịch. Mô hình đã tạo ra một tờ khai VAT về cơ bản là chính xác, với số dư cuối kỳ (Mục 5) chỉ chênh lệch 7 xu (~10 cent Mỹ) so với dữ liệu thực tế.

Trong bài viết này, chúng tôi sẽ giải thích cách thức thực hiện bài kiểm tra (benchmark) và ghi chú lại những lỗi mà mô hình đã mắc phải.

Cách thức thực hiện bài kiểm tra

Chúng tôi đã sử dụng Claude Fable 5 để trích xuất dữ liệu kiểm tra dưới dạng dữ liệu giao dịch và các hóa đơn tương ứng từ phần mềm kế toán của chúng tôi: quý đầu tiên trong sổ sách năm 2026 của Vineyard Finance (tháng 1, tháng 2, tháng 3 năm 2026). Những sổ sách này được con người chuẩn bị nội bộ theo quy trình kế toán thông thường: một người lập sổ và một người khác kiểm tra lại. Công việc do con người thực hiện bao quát hơn so với yêu cầu đặt ra cho mô hình trong bài kiểm tra này: con người còn phải tìm các hóa đơn liên quan (tìm kiếm trong hộp thư hoặc yêu cầu từ nhà cung cấp) và suy luận dựa trên các tình huống không thể tự suy ra từ dữ liệu ngân hàng và hóa đơn/biên lai. Trong bài kiểm tra, các tình huống này được trình bày với mô hình dưới dạng “ghi chú của người dùng” (user notes).

GLM 5.2 chạy trên một instance của Google Cloud Platform (GCP) được cách ly khỏi môi trường thử nghiệm còn lại (để ngăn mô hình truy cập vào dữ liệu thực tế): tuy nhiên, nó có quyền truy cập internet, phần mềm kế toán dựa trên đám mây và một công cụ CLI đã được xác thực trước. Mô hình chạy trên một bộ khung tùy chỉnh, tối giản, chỉ cho phép sử dụng hai công cụ: công cụ bash và công cụ kết thúc phiên + báo cáo cuối cùng. Chúng tôi đã sử dụng tầng serverless của Fireworks AI làm nhà cung cấp mô hình GLM 5.2 (định dạng lượng tử hóa chính xác của mô hình không được nhà cung cấp tiết lộ, nhưng được cho là FP16 hoặc FP8).

Quá trình kiểm tra (audit) khả năng suy luận và sử dụng công cụ của mô hình không phát hiện bất kỳ hành vi gian lận rõ ràng nào. Việc sử dụng kết nối internet ngoài dự kiến duy nhất của mô hình là thu thập thông tin về cách ghi nhận thuế VAT đảo ngược (reverse-charge VAT), và thông tin tìm kiếm rất cụ thể đối với phần mềm kế toán được sử dụng. Các kết nối gửi đi khác đều đã được dự đoán trước và thực hiện vì lý do vận hành dưới dạng các lệnh gọi API tới nhà cung cấp phần mềm kế toán SaaS. Chúng tôi lưu ý rằng khả năng suy luận của mô hình bị ảnh hưởng bởi việc nó biết mình đang bị kiểm tra. Ví dụ, tại một thời điểm, mô hình nhận xét:

“tác vụ này đang kiểm tra xem tôi có làm đúng VAT hay không… đâu là câu trả lời ‘được mong đợi’”

Những gì mô hình đã thấy

Dưới đây là cách một giao dịch điển hình trong bài kiểm tra hiển thị với mô hình:

Dòng dữ liệu ngân hàng:

{"id": "941285000000092067", "date": "2026-03-08", "amount": -18, "currency": "GBP", "account": "Wise GBP", "description": "Card transaction of 18.00 GBP issued by Claude.ai Subscription ANTHROPIC.COM CARD-3534994599", "card_ref": "CARD-3534994599"}

PDF biên lai: tất cả biên lai và hóa đơn trong bài kiểm tra đều là các tệp PDF chứa văn bản; không có biên lai hay tệp PDF nào yêu cầu xử lý hình ảnh. Do đó, việc thiếu hỗ trợ thị giác (vision support) trong mô hình GLM 5.2 không phải là yếu tố hạn chế đối với bài kiểm tra này.

Ghi chú tùy chọn của người dùng. Chỉ có 2 trong số 59 giao dịch có ghi chú của người dùng. Nội dung các ghi chú này chính xác như sau: 1) “founder shares” (cổ phần người sáng lập) và 2) “personal car hire” (thuê xe cá nhân). Hai ghi chú này là cần thiết để mô hình có thể suy luận về bối cảnh thực tế mà dữ liệu ngân hàng và biên lai không thể cung cấp.

Cách chúng tôi chấm điểm

Mỗi giao dịch được chấm điểm dựa trên trạng thái cuối cùng của sổ sách trong phần mềm kế toán sau khi chạy bài kiểm tra, dựa trên 6 tiêu chí sau:

Bảng dưới đây tóm tắt kết quả chạy bài kiểm tra trong toàn bộ quý:

Mỗi tháng chạy như một phiên tác nhân (agent session) liên tục; một “lượt” (turn) là một lệnh gọi API, và toàn bộ cuộc hội thoại được gửi lại sau mỗi lượt — đó là lý do tại sao số lượng token đầu vào (prompt tokens) lên tới hàng triệu, trong khi 92–95% trong số đó được phục vụ từ bộ nhớ đệm của nhà cung cấp với giá bằng một phần năm. Token đầu ra bao gồm cả quá trình suy luận nội bộ của mô hình. ¹ Ngữ cảnh đỉnh (Peak context) là lệnh gọi đơn lẻ lớn nhất, tính theo tỷ lệ phần trăm trong cửa sổ ngữ cảnh 1.048.576 token của mô hình — tháng bận rộn nhất đã sử dụng khoảng một phần tám dung lượng này.

Mô hình đã làm sai điều gì?

Tờ khai VAT do mô hình chuẩn bị về cơ bản là chính xác: con số quan trọng nhất trong tờ khai, đó là số tiền VAT mà công ty được cơ quan thuế hoàn lại, chỉ chênh lệch 7 xu so với tờ khai do con người chuẩn bị.

Tuy nhiên, việc hiểu rõ những gì mô hình làm sai và tại sao điều đó lại quan trọng trong thực tế là rất hữu ích. Hầu hết các lỗi của mô hình thực tế không gây ra bất kỳ tác động tài chính nào, nhưng một kế toán viên lành nghề chắc chắn sẽ không bao giờ mắc phải.

Trong số 354 lượt kiểm tra (59 giao dịch × 6 tiêu chí), mô hình đã thất bại 20 lần, rải rác trên 18 giao dịch. Chỉ có 1 lỗi nghiêm trọng, chúng tôi sẽ đề cập đến nó đầu tiên; 19 lỗi còn lại thuộc về một trong hai loại mà chúng tôi sẽ trình bày dưới đây.

Lỗi nghiêm trọng nằm ở cách mô hình xử lý cổ phần của người sáng lập. Tại Vương quốc Anh, một công ty trách nhiệm hữu hạn phát hành “vốn cổ phần”. Các cổ đông (bao gồm cả người sáng lập) thanh toán vốn vào tài khoản của công ty, và khoản này cần được ghi sổ vào mục như “Vốn cổ phần chưa thanh toán” (Called up share capital not paid), trong phần mềm chúng tôi sử dụng gọi là “Unpaid Shares”. Đây là cách hạch toán chính xác cho khoản thanh toán này. Lựa chọn của mô hình là “Tài khoản vốn” (Capital Account), điều này có những hệ lụy pháp lý có thể ảnh hưởng đến công ty, có khả năng bị chất vấn trong quá trình kiểm toán hoặc gây rắc rối khi nộp báo cáo tài chính cuối năm. Bản chất của vấn đề là vốn cổ phần (“Unpaid Shares”) không chỉ đơn thuần là tiền của người sáng lập (“Capital Account”). Đó là nguồn vốn vĩnh viễn, bảo vệ chủ nợ và đi kèm với các ràng buộc pháp lý. Ví dụ, nó không thể đơn giản được trả lại cho người sáng lập và phải được công bố phù hợp với cơ quan thuế trong các báo cáo cuối năm. Một yếu tố làm trầm trọng thêm vấn đề là số tiền liên quan: 10.000 GBP (~13.300 USD). Không hẳn là một khoản tiền nhỏ. Mặc dù không ảnh hưởng đến tờ khai VAT, đây là sai sót lớn nhất mà mô hình mắc phải trong bài kiểm tra này.

Đối với 14 trong số 17 giao dịch còn lại, loại lỗi là nhầm lẫn giữa danh mục VAT “zero-rated” (thuế suất 0%) và danh mục “tax-exempt” (miễn thuế). Có những lý do thuế tế nhị khiến hai danh mục này, dù đều không liên quan đến việc nộp VAT, lại khác biệt nhau. Tác động thực tế là nhỏ, nhưng một kế toán viên lành nghề thường sẽ không nhầm lẫn giữa hai loại này. Điều thú vị là mô hình có tính ngẫu nhiên ở đây – nó mắc lỗi vào tháng 1 và tháng 2 (với tỷ lệ sai 100%), nhưng lại không mắc lỗi vào tháng 3, xử lý chính xác từng giao dịch miễn thuế VAT.

3 giao dịch cuối cùng chia sẻ một lỗi suy luận hơi khó hiểu, và có thể lập luận rằng trong một trường hợp (một lần nữa, vào tháng 3), mô hình thực sự đã đúng. Tại Vineyard Finance, chúng tôi sử dụng Wise, vốn có thói quen hơi kỳ lạ là giữ tiền rải rác trên các số dư bằng nhiều loại tiền tệ khác nhau, ngay cả khi người dùng chỉ cố ý sử dụng một loại tiền tệ. Khi chi tiêu bằng thẻ, Wise lấy tiền từ các số dư khác nhau theo một thứ tự xác định. Trong trường hợp của chúng tôi, chúng tôi có một khoản “hoàn tiền” hoặc “phí hoàn lại” từ Wise, bằng cách nào đó rơi vào số dư USD (chúng tôi thường không sử dụng số dư USD). Vì vậy, một khoản thanh toán cho dịch vụ bằng USD dẫn đến một “giao dịch tách biệt” (split transaction), tức là hai giao dịch trên hai số dư, cụ thể là 0,51 USD và 43,45 GBP. Thông thường, VAT sẽ được hạch toán trong giao dịch “chính” (43,45 GBP). Trong một trường hợp, mô hình không may đã “tính trùng” – nó hạch toán toàn bộ VAT trên “phần chính” (ví dụ: 43,45 GBP) và giảm tỷ lệ VAT tương ứng trên “phần dư” (ví dụ: 0,51 USD). Điều này là không chính xác, mặc dù không đáng kể. Trong một giao dịch vào tháng 3, mô hình đã nhận ra rằng nó sẽ tính trùng, nên nó đã tính toán tổng VAT chính xác và chia đều cho mỗi phần. Cách làm này không chính thống, nhưng có thể cho rằng không sai (tuy nhiên, người chấm điểm vẫn bảo thủ và tính giao dịch tháng 3 là một lỗi).

Những gì mô hình luôn làm đúng

Quan trọng không kém, cần lưu ý những gì mô hình luôn làm đúng:

Điều này dẫn chúng ta đến đâu? Chúng ta nên học được gì từ đây?

Kế toán đang nhanh chóng trở thành một vấn đề đã được giải quyết. Trọng tâm hiện tại cần tập trung vào việc xây dựng các nền tảng phù hợp để đưa những khả năng này vào tay các startup và SME tại Vương quốc Anh. Chúng tôi đang làm việc trên một giải pháp như vậy — bạn có thể thử nghiệm bản beta mở của sản phẩm chúng tôi tại toot-books.com. Nếu bạn quan tâm đến kế toán tự động, vui lòng liên hệ tại [email protected].