Kiến trúc nền tảng tài chính cho doanh nghiệp Việt Nam

Phần lớn doanh nghiệp quy mô vừa và lớn tại Việt Nam đã có ERP. Điều họ chưa có là một lớp vận hành nằm phía trước ERP. Hệ quả rất quen thuộc: hóa đơn điện tử đến qua nhiều kênh — email của kế toán, cổng của VNPT hoặc Viettel, phần mềm meInvoice của MISA, đôi khi là bản in do lái xe giao hàng cầm theo. Kế toán tải về, đối chiếu với đơn hàng trên Excel, nhập tay vào ERP, rồi in ra để trình ký. Ba nguồn sự thật cùng tồn tại: hệ thống thuế, bảng tính, và ERP.

Kiến trúc BancoOS xuất phát từ giả định ngược lại: chứng từ phải được số hóa, xác thực và đối soát trước khi chạm vào sổ cái. Khi bút toán đã vào ERP, mọi sai sót đều trở nên đắt đỏ vì phải điều chỉnh, giải trình và lưu vết. Việc đưa điểm kiểm soát lên phía trước là khác biệt kiến trúc quan trọng nhất, và cũng là lý do các đội tài chính rút ngắn được thời gian đóng sổ.

AI trong kiến trúc này không phải một sản phẩm riêng lẻ mà là một lớp có phạm vi rõ ràng. Nó phụ trách những việc mà quy tắc cứng làm không tốt: đọc hóa đơn có bố cục khác nhau, hiểu mô tả hàng hóa viết tắt kiểu Việt Nam ("thép hộp 40x80 mạ kẽm" so với mã vật tư trong ERP), quy đổi đơn vị giữa "cây", "kg" và "tấn", và đoán đúng trung tâm chi phí dựa trên lịch sử.

Những việc AI không phụ trách cũng quan trọng không kém: xác định một hóa đơn có hợp lệ về mặt thuế hay không (việc này thuộc lớp tra cứu GDT), quyết định chi tiền (thuộc con người), và ghi sổ (thuộc ERP). Ranh giới rõ ràng này giúp doanh nghiệp giải trình được với kiểm toán về vai trò của AI. Xem thêm các tác nhân AI tài chính và tự động hóa tài chính.

Mỗi lớp có thể vận hành độc lập và có API riêng. Doanh nghiệp có thể bắt đầu chỉ với lớp 1 đến lớp 3 — tức là số hóa và xác thực hóa đơn — rồi mở rộng dần sang đối soát và thanh toán khi quy trình nội bộ đã sẵn sàng.

Thị trường ERP Việt Nam phân mảnh theo quy mô: doanh nghiệp trong nước phần lớn dùng MISA hoặc Fast, doanh nghiệp FDI quy mô vừa dùng Microsoft Dynamics 365 Business Central, còn các tập đoàn sản xuất lớn dùng SAP hoặc Oracle. Không hiếm trường hợp một tập đoàn dùng đồng thời hai đến ba hệ thống sau các thương vụ mua bán sáp nhập.

Nguyên tắc chung: BancoOS không ghi trực tiếp vào sổ cái. Hệ thống tạo chứng từ ở trạng thái đã đối soát và đã duyệt, ERP nhận và hạch toán theo cấu hình tài khoản của doanh nghiệp. Nhờ vậy, chính sách kế toán, hệ thống tài khoản theo Thông tư 200 và quy trình kiểm soát nội bộ trên ERP không bị thay đổi.

Đây là lớp mang tính đặc thù Việt Nam rõ nhất và cũng là lớp không thể sao chép từ một nền tảng nước ngoài. Hóa đơn điện tử tại Việt Nam có cấu trúc XML theo chuẩn của cơ quan thuế, kèm chữ ký số của người bán và trong nhiều trường hợp là mã của cơ quan thuế. Bản PDF chỉ là bản thể hiện, không phải chứng từ gốc.

Lớp này kiểm tra bốn nhóm rủi ro mà đội kế toán Việt Nam gặp thường xuyên:

• Người bán ngừng hoạt động hoặc bị cưỡng chế hóa đơn tại thời điểm lập chứng từ — rủi ro trực tiếp đến quyền khấu trừ thuế giá trị gia tăng.
• Hóa đơn trùng: cùng một số hóa đơn được gửi hai lần qua hai kênh khác nhau, rất phổ biến khi nhà cung cấp vừa gửi email vừa đẩy qua cổng hóa đơn.
• Sai lệch giữa bản thể hiện PDF và dữ liệu XML gốc.
• Thời điểm lập hóa đơn không khớp với thời điểm nghiệm thu hoặc giao hàng — điểm mà cơ quan thuế thường xem xét khi thanh tra.

Toàn bộ phản hồi tra cứu được lưu kèm chứng từ. Xem hướng dẫn chi tiết tại cẩm nang hóa đơn điện tử GDT và kiến trúc tích hợp GDT.

MISA là hệ thống phổ biến nhất ở nhóm doanh nghiệp trong nước, và cũng là hệ thống mà đội kế toán gắn bó nhất. Vì vậy nguyên tắc thiết kế là: kế toán viên không phải rời MISA. Bộ kết nối đồng bộ danh mục nhà cung cấp và đơn mua hàng theo lịch, nhận dữ liệu phiếu nhập kho theo sự kiện, và đẩy ngược chứng từ mua hàng đã hoàn tất đối soát.

Một chi tiết thực tế thường bị bỏ qua: dữ liệu nhà cung cấp trên MISA của nhiều doanh nghiệp bị trùng lặp sau nhiều năm sử dụng — cùng một nhà cung cấp tồn tại dưới ba mã khác nhau vì khác cách viết tên. Trong giai đoạn kết nối, hệ thống chuẩn hóa theo mã số thuế thay vì theo tên, và trả về danh sách trùng lặp để kế toán quyết định gộp.

Với doanh nghiệp FDI, ràng buộc thường không nằm ở kỹ thuật mà ở quản trị: hệ thống ERP do công ty mẹ ở Nhật Bản, Hàn Quốc hoặc châu Âu quản lý, chi nhánh Việt Nam không có quyền thay đổi cấu hình. Kiến trúc BancoOS xử lý ràng buộc này bằng cách chỉ yêu cầu quyền đọc dữ liệu nền và quyền ghi ở phạm vi chứng từ mua hàng, không đụng đến cấu hình sổ cái.

Với Business Central, kết nối dùng API chuẩn của Microsoft và tôn trọng mô hình phân quyền theo company. Với SAP, một lớp trung gian chuẩn hóa chứng từ trước khi tạo MIRO, cho phép giữ nguyên quy trình release strategy hiện có. Với Oracle NetSuite, kết nối SuiteTalk cho phép tạo Vendor Bill kèm đầy đủ phân bổ theo subsidiary — điểm quan trọng với tập đoàn có nhiều pháp nhân tại Việt Nam.

Mọi chức năng hiển thị trên giao diện đều có API tương ứng. Điều này quan trọng với các tập đoàn Việt Nam đang xây dựng kho dữ liệu tập trung hoặc trung tâm dịch vụ chia sẻ: dữ liệu hóa đơn, trạng thái phê duyệt và lịch thanh toán có thể được đẩy sang hệ thống báo cáo nội bộ mà không cần xuất Excel.

• API đọc: danh sách chứng từ, trạng thái đối soát, hàng đợi ngoại lệ, lịch thanh toán dự kiến.
• API ghi: tạo chứng từ, cập nhật nhà cung cấp, ghi nhận quyết định phê duyệt từ hệ thống bên ngoài.
• Webhook: hóa đơn được xác thực, phát sinh ngoại lệ, khoản chi được duyệt, thanh toán hoàn tất.
• Nhật ký gọi API đầy đủ, phục vụ đối chiếu khi có tranh chấp dữ liệu giữa các hệ thống.

Bảo mật được thiết kế theo bốn lớp độc lập: cách ly dữ liệu theo tenant và theo pháp nhân; kiểm soát truy cập theo vai trò với nguyên tắc tối thiểu quyền — người mua hàng không nhìn thấy dữ liệu lương, kế toán chi nhánh không nhìn thấy dữ liệu pháp nhân khác; mã hóa dữ liệu khi lưu trữ và khi truyền; và giám sát hành vi bất thường như tải hàng loạt chứng từ hay thay đổi số tài khoản ngân hàng của nhà cung cấp.

Rủi ro thực tế nghiêm trọng nhất tại Việt Nam không phải tấn công hạ tầng mà là gian lận thay đổi tài khoản thụ hưởng qua email giả mạo. Vì vậy mọi thay đổi thông tin ngân hàng của nhà cung cấp đều được xử lý như một sự kiện rủi ro: yêu cầu phê duyệt kép, thông báo tới người phụ trách và tạm giữ khoản chi trong một khoảng thời gian cấu hình được. Xem thêm tổng quan bảo mật.

Ma trận phê duyệt của doanh nghiệp Việt Nam hiếm khi đơn giản. Nó phụ thuộc vào hạn mức, loại chi phí, pháp nhân, nhà máy, và đôi khi phụ thuộc vào việc khoản chi đó có nằm trong ngân sách đã duyệt hay không. Kiến trúc tách phần định tuyến khỏi phần logic nghiệp vụ: quy tắc định tuyến là cấu hình, không phải mã nguồn, nên phòng tài chính có thể tự điều chỉnh khi cơ cấu tổ chức thay đổi.

Chuỗi kiểm toán được thiết kế theo nguyên tắc chỉ thêm, không sửa. Mỗi thay đổi tạo ra một bản ghi mới liên kết bằng hàm băm với bản ghi trước đó, nên việc sửa lịch sử sẽ làm gãy chuỗi và bị phát hiện. Với mỗi hóa đơn, hệ thống lưu: tệp gốc, hàm băm, phản hồi tra cứu thuế tại thời điểm xử lý, toàn bộ giá trị trường trước và sau khi chỉnh sửa, danh tính người thực hiện và dấu thời gian.

Trong thực tế, giá trị lớn nhất của lớp này xuất hiện vào kỳ kiểm toán và thanh tra thuế: thay vì mất nhiều ngày tìm lại chứng từ trong hộp thư và thư mục chia sẻ, đội tài chính xuất một hồ sơ hoàn chỉnh cho từng nghiệp vụ được chọn mẫu.

Lớp quyết định trả lời một câu hỏi duy nhất cho mỗi chứng từ: tự động đi tiếp, hay chuyển cho con người. Câu trả lời dựa trên tổ hợp của điểm tin cậy trích xuất, kết quả xác thực thuế, mức sai lệch đối soát, hồ sơ rủi ro của nhà cung cấp và giá trị giao dịch.

Ngoại lệ không phải lỗi hệ thống mà là phần việc thực sự cần con người. Thiết kế tốt là thiết kế đưa đúng ngoại lệ tới đúng người, kèm đủ ngữ cảnh để xử lý trong vài phút. Mỗi ngoại lệ mang theo: ảnh vùng dữ liệu trên hóa đơn gốc, chứng từ liên quan, lịch sử giao dịch với nhà cung cấp đó, và gợi ý xử lý dựa trên các trường hợp tương tự trước đây.

Ba loại ngoại lệ chiếm phần lớn khối lượng tại doanh nghiệp sản xuất Việt Nam: chênh lệch số lượng do hao hụt vận chuyển, chênh lệch giá do phụ phí nhiên liệu chưa có trong đơn hàng, và hóa đơn về trước khi phiếu nhập kho được ghi nhận trên hệ thống. Xem thêm hướng dẫn đối soát ba chiều.

Nhiều doanh nghiệp — đặc biệt trong lĩnh vực có yếu tố hạ tầng hoặc có vốn nhà nước — đặt yêu cầu dữ liệu tài chính phải lưu trữ trong lãnh thổ Việt Nam, tham chiếu Nghị định 53/2022/NĐ-CP hướng dẫn Luật An ninh mạng. Kiến trúc tách phần lưu trữ chứng từ khỏi phần tính toán, nên có thể cấu hình lưu trữ bản gốc và bản ghi kiểm toán tại hạ tầng trong nước trong khi vẫn dùng chung lớp dịch vụ. Phương án cụ thể được thống nhất trong giai đoạn khảo sát vì nó ảnh hưởng tới chi phí và thời gian triển khai.

Các lớp thu nhận, trích xuất và xác thực chạy bất đồng bộ theo hàng đợi. Khi khối lượng tăng đột biến — điển hình là tuần cuối tháng và cao điểm trước Tết Nguyên đán, khi nhà cung cấp dồn hóa đơn để chốt công nợ — hệ thống mở rộng theo chiều ngang thay vì xếp hàng chờ.

Trong thực tế, điểm nghẽn hiếm khi nằm ở hạ tầng. Nó nằm ở số lượng người có thẩm quyền xử lý ngoại lệ. Vì vậy chỉ số cần theo dõi khi mở rộng không phải thời gian phản hồi hệ thống, mà là tỷ lệ chứng từ đi thẳng không cần can thiệp và thời gian chờ trung bình trong hàng đợi ngoại lệ.

Mô hình phổ biến tại Việt Nam: một công ty mẹ, hai đến ba nhà máy ở các khu công nghiệp khác nhau, một công ty thương mại phân phối, đôi khi thêm một pháp nhân logistics. Mỗi đơn vị có mã số thuế riêng, nghĩa vụ kê khai riêng, và thường có cả hệ thống kế toán riêng.

Kiến trúc xử lý điều này bằng cách coi pháp nhân là chiều dữ liệu cơ bản, xuất hiện ở mọi bản ghi từ chứng từ đến quyền truy cập. Giao dịch nội bộ giữa các pháp nhân được gắn thẻ để loại trừ khi hợp nhất. Người dùng có thể được cấp quyền trên nhiều pháp nhân — phù hợp với mô hình trung tâm dịch vụ chia sẻ đang được nhiều tập đoàn Việt Nam áp dụng để tập trung công tác kế toán về một địa điểm.

Hướng đi không phải là loại bỏ con người mà là thu hẹp dần phạm vi con người phải can thiệp. Lộ trình thực tế cho một doanh nghiệp Việt Nam thường trải qua bốn mức: số hóa chứng từ, tự động đối soát, tự động định tuyến quyết định, và cuối cùng là dự báo chủ động — hệ thống cảnh báo trước rằng dòng tiền tuần thứ chín sẽ căng nếu giữ nguyên lịch thanh toán hiện tại, kèm phương án điều chỉnh.

Mức thứ tư mới là nơi giá trị tài chính thực sự xuất hiện, nhưng không thể đạt được nếu ba mức đầu chưa ổn định, bởi dự báo chỉ đáng tin khi dữ liệu nền sạch. Đây là lý do lộ trình triển khai được thiết kế theo thứ tự đó.