Tác giả: Lạc Phạm, Solution Architect, S4 Consulting · Cập nhật: 22/10/2026
Oracle NetSuite ghi nhận bút toán theo từng dòng sổ cái, nhưng không lưu sẵn cặp tài khoản đối ứng theo cách thường dùng trong sổ kế toán Việt Nam. Để lập Nhật ký chung, Sổ Cái có cột tài khoản đối ứng và hỗ trợ báo cáo lưu chuyển tiền tệ trực tiếp theo Thông tư 99, hệ thống cần một bước xử lý để ghép các dòng Nợ và Có thành từng cặp. Đây là một phần trong gói bản địa hóa TT99 mà S4 Consulting phát triển cho NetSuite.
Xem nhanh cách gói bản địa hóa kế toán của S4 Consulting lập 26 mẫu sổ và báo cáo theo Thông tư 99 ngay trên Oracle NetSuite trong video demo dưới đây.
Vì sao kế toán Việt Nam cần tài khoản đối ứng?
Nhiều mẫu sổ kế toán Việt Nam trình bày quan hệ giữa tài khoản Nợ và tài khoản Có. Nhật ký chung cần thể hiện các cặp đối ứng; Sổ Cái và sổ chi tiết có thể cần cột “TK đối ứng”; còn báo cáo lưu chuyển tiền tệ theo phương pháp trực tiếp phải phân loại dòng tiền dựa trên tài khoản đối ứng với tài khoản tiền.
Với chứng từ đơn giản, việc ghép cặp có thể dễ nhận biết. Chẳng hạn một giao dịch bán hàng có Nợ phải thu, Có doanh thu và Có thuế GTGT đầu ra. Nhưng khi một bút toán tổng hợp có nhiều dòng Nợ và nhiều dòng Có, không phải lúc nào cũng có một cách ghép duy nhất. Nếu ghép sai, sổ chi tiết có thể trình bày không đúng bản chất nghiệp vụ và dòng tiền có thể bị phân loại nhầm.
Thuật toán tách đối ứng ghép các dòng như thế nào?
Thuật toán cần có thứ tự ưu tiên thay vì ghép tùy ý. Trong gói của S4 Consulting, các lượt xử lý ưu tiên ghép những dòng có cùng số tiền, sau đó áp dụng các cặp tài khoản được khai là ưu tiên, xét độ ưu tiên theo tiền tố tài khoản và cuối cùng mới phân bổ phần còn lại theo tỷ lệ. Cách làm này giúp xử lý cả chứng từ đơn giản lẫn bút toán tổng hợp nhiều dòng.
Bộ quy tắc có hai nhóm. Quy tắc PREFER xác định các cặp nên được ghép với nhau, ví dụ tài khoản tiền với phải thu khách hàng. Quy tắc DISALLOW xác định những cặp không được ghép. Nếu dữ liệu thực tế buộc thuật toán tạo ra một cặp trái quy tắc DISALLOW, kết quả cần được đánh dấu để kế toán kiểm tra, thay vì để hệ thống âm thầm đưa vào sổ như một kết quả chắc chắn đúng.
Các quy tắc cần được rà soát theo nghiệp vụ của doanh nghiệp. Không nên coi một bộ quy tắc mặc định là phù hợp với mọi ngành hoặc mọi cách tổ chức hệ thống tài khoản.
Việc tách đối ứng chạy khi nào?
Kế toán thường cần xem sổ ngay sau khi lưu chứng từ, vì vậy việc tách nên chạy gần thời gian thực trong các trường hợp có thể xử lý ngay. Gói của S4 sử dụng hai cơ chế bổ sung cho nhau.
User Event chạy sau khi lưu và xử lý ngay các chứng từ có số dòng sổ cái không vượt ngưỡng cấu hình, mặc định 50 dòng. Nếu bước tách gặp lỗi, hệ thống ghi trạng thái lỗi để xử lý sau, không chặn người dùng lưu chứng từ.
Map/Reduce chạy định kỳ mỗi giờ để rà soát bổ sung các trường hợp chưa được xử lý tại thời điểm lưu, gồm chứng từ vượt ngưỡng, dữ liệu được tạo hoặc sửa qua CSV hay cập nhật hàng loạt, và bút toán đảo do NetSuite tự tạo. Mỗi giao dịch lưu dấu thời gian của lần tách và phiên bản thuật toán, giúp lượt quét tiếp theo xác định giao dịch nào thực sự cần xử lý lại.
Những tình huống nào cần tách lại đối ứng?
Dữ liệu đối ứng không nên được xem là kết quả cố định sau lần chạy đầu tiên. Trong kỳ chưa khóa, giao dịch có thể được sửa, xóa hoặc hủy; khi đó, dữ liệu đã tách cần được đồng bộ theo trạng thái mới của giao dịch.
Các tình huống cần kiểm soát gồm:
- Chứng từ được sửa: chạy tách lại theo số liệu mới.
- Chứng từ bị xóa: xóa dữ liệu cặp đối ứng và trạng thái tách liên quan trước khi hoàn tất việc xóa, tránh để bản ghi phụ cản trở thao tác.
- Phiếu chi bị void: kiểm tra cả giao dịch gốc và bút toán hủy do NetSuite tạo để bảo đảm kết quả đối ứng triệt tiêu đúng.
- Bút toán đảo tự động: đưa vào lượt rà soát bổ sung nếu không đi qua User Event.
- Giao dịch không còn ghi sổ: hủy kết quả tách cũ để dữ liệu không tiếp tục xuất hiện trong báo cáo.
Các tình huống này cần được kiểm thử trên môi trường phát triển với cấu hình và luồng nghiệp vụ thực tế của doanh nghiệp. Không nên suy ra toàn bộ hành vi của hệ thống chỉ từ một tình huống thử nghiệm.
Làm sao biết dữ liệu đối ứng đã đầy đủ?
Kế toán cần màn hình đối chiếu và các phép kiểm tra tự động, không chỉ dựa vào việc tác vụ nền đã chạy. Màn hình đối chiếu trong gói liệt kê giao dịch chưa tách, giao dịch đã thay đổi sau lần tách, trường hợp tách lỗi, chênh lệch với sổ cái và các cặp bị buộc ghép trái quy tắc DISALLOW. Người dùng có thể chọn từng giao dịch hoặc xử lý theo danh sách để chạy lại.
Trang tổng quan còn so sánh tổng phát sinh trên Nhật ký chung với tổng phát sinh Nợ trên sổ cái trong cùng kỳ. Nếu hai số không khớp, cần kiểm tra giao dịch chưa tách hoặc kết quả xử lý chưa đầy đủ. Khi mở sổ hoặc báo cáo, hệ thống cũng nên cảnh báo nếu phạm vi dữ liệu đang xem còn giao dịch chưa tách.
Doanh nghiệp nên vận hành chức năng này ra sao?
Doanh nghiệp nên thống nhất quy tắc PREFER và DISALLOW với kế toán trưởng, sau đó rà soát màn hình đối chiếu định kỳ và trước khi khóa sổ tháng. Với dữ liệu nhập hàng loạt qua CSV, cần xác nhận lượt rà soát bổ sung đã hoàn tất hoặc chủ động chạy tách từ màn hình đối chiếu trước khi lập sổ. Quy trình kiểm tra này giúp phát hiện sai lệch sớm hơn thay vì đợi đến lúc đối chiếu báo cáo cuối kỳ.
Xem gói bản địa hóa kế toán NetSuite chạy trên dữ liệu thực tế
S4 Consulting là nhà tư vấn Oracle NetSuite tại Việt Nam. Xem video demo đầy đủ hoặc tìm hiểu chi tiết sổ, báo cáo và mẫu thuế theo Thông tư 99 trên NetSuite.
Tìm hiểu gói bản địa hóaXem video trên YouTubeBài viết liên quan
- NetSuite cần bổ sung những gì để đáp ứng Thông tư 99?
- Tài khoản đối ứng trên NetSuite theo VAS: vì sao cần và cách tách tự động
- Ngành thép dùng NetSuite tối ưu chi phí thế nào?
Câu hỏi thường gặp
NetSuite có sẵn tài khoản đối ứng cho Nhật ký chung không?
NetSuite ghi nhận dữ liệu theo dòng sổ cái, vì vậy cần bước xử lý bổ sung để xác định cặp Nợ/Có khi lập các mẫu sổ Việt Nam có yêu cầu tài khoản đối ứng.
Sửa chứng từ đã ghi sổ thì cặp đối ứng có cập nhật không?
Gói xử lý lại khi giao dịch được lưu qua giao diện trong phạm vi hỗ trợ. Những thay đổi qua CSV hoặc luồng không kích hoạt User Event được đưa vào lượt rà soát bổ sung định kỳ.
Lỗi tách đối ứng có chặn việc lưu chứng từ không?
Theo thiết kế được mô tả, lỗi được ghi nhận thành trạng thái để kế toán xử lý và không chặn việc lưu chứng từ.
Làm sao kiểm tra Nhật ký chung đã đủ dữ liệu?
Có thể so sánh tổng phát sinh Nhật ký chung với tổng phát sinh Nợ trên sổ cái cùng kỳ, đồng thời rà danh sách giao dịch chưa tách và giao dịch có lỗi.