Kiểm toán – Kiểm soát Accounting Judgment as a Structured Decision Object: Khi quyết định kế toán cần trở thành dữ liệu có cấu trúc

[Trợ lý AI]

Trong hệ thống kế toán truyền thống, doanh nghiệp lưu rất nhiều thứ.

Chứng từ.

Bút toán.

Sổ kế toán.

Báo cáo tài chính.

Approval log.

Nhưng có một loại thông tin rất quan trọng lại thường được lưu rất kém:

Vì sao doanh nghiệp lựa chọn một accounting treatment cụ thể?

Một khoản chi phí được vốn hóa hay ghi nhận ngay?

Một tài sản sử dụng useful life bao nhiêu năm?

Một khoản mục được xem là material hay immaterial?

Một transaction mới sẽ được hạch toán vào tài khoản nào?

Một policy mới áp dụng từ thời điểm nào?

Thông thường câu trả lời nằm rải rác trong:

email,

biên bản họp,

file Excel,

trao đổi giữa kế toán trưởng và kiểm toán,

hoặc đơn giản là:

“Trước giờ công ty vẫn làm như vậy.”

Trong môi trường Finance ngày càng số hóa và AI bắt đầu tham gia vào core workflow, cách quản lý đó sẽ không còn đủ.

Doanh nghiệp cần biến Accounting Judgment thành một đối tượng dữ liệu có cấu trúc:

Decision Object​

Có thể hình dung:

Business Context

→ Accounting Question

→ Options Considered

→ Decision

→ Rationale

→ Evidence

→ Approval

→ Effective Period

→ Application

→ Outcome / Review.

Khi đó một accounting judgment không còn là tri thức nằm trong đầu một vài người.

Nó trở thành:

organizational memory.

1. Từ “hạch toán đúng” sang “giải thích được vì sao hạch toán như vậy”​

Một accounting system thông thường rất giỏi trả lời:

Bút toán nào đã được ghi?

Ví dụ:

Nợ TK X

Có TK Y.

Nhưng nếu hỏi:

Tại sao doanh nghiệp chọn treatment này?

hệ thống thường không trả lời được.

Đây là một khoảng trống quan trọng.

Accounting record cho biết:

what happened.

Accounting Judgment cần giải thích:

why this treatment was selected.

Hai thứ này không giống nhau.

2. TT99 làm câu chuyện này đáng chú ý hơn​

Thông tư 99/2025/TT-BTC có hiệu lực từ ngày 01/01/2026 và áp dụng cho năm tài chính bắt đầu từ hoặc sau ngày này.

Điểm đáng chú ý là trong một số phần, doanh nghiệp có thêm không gian để điều chỉnh hệ thống kế toán cho phù hợp với đặc điểm hoạt động và yêu cầu quản lý.

Điều này không có nghĩa doanh nghiệp được tùy ý.

Ngược lại.

Khi doanh nghiệp có nhiều không gian judgment hơn, câu hỏi quản trị trở nên quan trọng hơn:

Ai đã quyết định?

Dựa trên cơ sở nào?

Áp dụng từ thời điểm nào?

Có áp dụng nhất quán không?

3. Flexibility luôn đi cùng accountability​

Một system rule cố định tương đối dễ kiểm soát.

Ví dụ:

Transaction Type A → Account 642.

Nhưng nếu doanh nghiệp quyết định:

trong một số trường hợp Transaction Type A phải được phân loại khác vì bản chất kinh tế khác,

thì lúc này xuất hiện:

judgment.

Judgment có thể hoàn toàn hợp lý.

Nhưng judgment không được quản trị sẽ tạo ra:

• inconsistent accounting;
• khó kiểm toán;
• knowledge dependency vào một vài cá nhân;
• khó giải thích historical treatment;
• khó tự động hóa;
• AI không có context để reasoning.

Vì vậy vấn đề không phải:

doanh nghiệp có được judgment hay không?

Mà là:

judgment có được quản trị như một controlled decision hay không?

4. Accounting Judgment nên trở thành một Business Object​

Thay vì lưu judgment trong một memo rời rạc, có thể coi nó là một object:

Accounting_Decision.

Ví dụ:

DEC-ACC-2026-014.

Decision Question:

Chi phí phát triển sản phẩm X nên ghi nhận như thế nào?

Business Context:

• Project X;
• development stage;
• expected economic benefit;
• supporting contracts;
• management forecast.

Options:

Option A → Expense

Option B → Capitalize.

Decision:

Option B.

Rationale:

dựa trên bản chất transaction và accounting policy áp dụng.

Evidence:

• contract;
• project approval;
• management forecast;
• technical documentation.

Approved By:

CFO.

Effective From:

01/07/2026.

Review Date:

31/12/2026.

Lúc này decision không còn là:

một đoạn email.

Nó trở thành:

managed data.

5. Một Decision Object tối thiểu cần những gì?​

Một schema thực dụng có thể bắt đầu bằng:

Decision_ID

→ Decision_Type

→ Business_Context

→ Accounting_Question

→ Applicable_Rule / Policy

→ Options_Considered

→ Selected_Decision

→ Rationale

→ Evidence

→ Prepared_By

→ Approved_By

→ Effective_From

→ Effective_To

→ Review_Date

→ Status.

Không cần làm quá phức tạp ngay từ đầu.

Điều quan trọng là mỗi decision trả lời được ba câu:

Quyết định gì?

Tại sao?

Ai chịu trách nhiệm?

6. Decision khác với Policy​

Policy nói:

doanh nghiệp nói chung sẽ làm như thế nào.

Decision nói:

trong context cụ thể này, doanh nghiệp đã lựa chọn gì.

Ví dụ:

Accounting Policy:

Useful life của nhóm tài sản A thường từ 5–10 năm.

Decision:

Machine M03 useful life = 7 years.

Policy là:

Expected Framework.

Decision là:

Applied Judgment.

Hai object nên liên kết với nhau.

7. Decision cũng khác với Case​

Một Case thường bắt đầu khi:

có Issue cần giải quyết.

Ví dụ:

VAT mismatch.

BOM variance.

AR overdue.

Nhưng Accounting Decision có thể xuất hiện mà không có Issue.

Ví dụ doanh nghiệp triển khai một loại transaction mới.

Không có lỗi.

Không có exception.

Nhưng management vẫn phải quyết định:

accounting treatment nào phù hợp?

Do đó:

Issue → Case

là một flow.

Trong khi:

Question → Decision

là một flow khác.

Hai flow sau đó cùng tạo:

Context Capital.

8. Decision cần Evidence​

Một judgment không nên chỉ có:

Decision = A.

Nó phải có:

evidence chain.

Ví dụ:

Decision

→ Accounting Standard / Regulation

→ Contract

→ Transaction Data

→ Management Assumption

→ Approval.

Khi kiểm toán hoặc management review lại sau hai năm, system có thể reconstruct:

doanh nghiệp đã biết gì tại thời điểm đó?

Đây là điểm rất quan trọng.

Không nên đánh giá một historical judgment chỉ bằng thông tin có được sau này.

9. Decision cần Effective Period​

Accounting Judgment không nhất thiết đúng mãi mãi.

Business context có thể thay đổi.

Regulation thay đổi.

Estimate thay đổi.

Ví dụ:

Useful life ban đầu:

7 years.

Sau ba năm, machine usage pattern thay đổi đáng kể.

Decision có thể cần:

Review.

Do đó Decision Object nên có:

Effective_From

và khi cần:

Effective_To.

Đây là cùng một nguyên tắc mình đã dùng cho:

Expected State versioning.

10. Một Decision phải có version history​

Không nên sửa đè decision cũ.

Ví dụ:

DEC-014 v1

→ useful life 7 years.

Sau review:

DEC-014 v2

→ remaining useful life revised.

Historical transaction cần biết:

tại thời điểm đó decision version nào đang có hiệu lực?

Đây là nền tảng cho:

auditability.

11. Accounting Judgment là một loại Protected Business Object​

Một số decision có thể ảnh hưởng lớn tới:

• P&L;
• asset value;
• tax exposure;
• KPI;
• covenant;
• management compensation.

Do đó AI có thể:

• phân tích;
• tìm precedent;
• đề xuất treatment;
• summarize evidence.

Nhưng AI không nên tự:

Change Accounting Policy

hoặc:

Approve Material Judgment.

Có thể dùng flow:

AI Recommendation

→ Professional Review

→ Approval

→ Decision Version.

Đây chính là:

Probabilistic Reasoning, Deterministic Authority.

12. AI đặc biệt hữu ích trước khi Decision được đưa ra​

AI có thể đọc:

• regulation;
• accounting policy;
• contracts;
• transaction data;
• previous decisions.

Sau đó AI có thể hỗ trợ:

Những accounting treatments nào có thể áp dụng?

Case nào trước đây tương tự?

Evidence nào còn thiếu?

Decision hiện tại có conflict với policy cũ không?

Nhưng AI nên tạo:

Decision Support.

Không nên trở thành:

Decision Authority.

13. Historical Decisions là nguồn context cực kỳ giá trị cho AI​

Giả sử doanh nghiệp phát sinh một transaction mới.

AI có thể search:

Similar Accounting Decisions.

Ví dụ:

Current transaction:

Customer rebate arrangement.

System tìm được:

• DEC-2025-031;
• DEC-2026-004;
• DEC-2026-019.

AI có thể nói:

Trong ba decision tương tự trước đây, doanh nghiệp đã xử lý theo treatment X khi điều kiện A+B tồn tại, nhưng chuyển sang treatment Y khi contract có condition C.

Đây không còn là generic accounting advice.

Nó là:

enterprise-specific reasoning.

14. Đây là “Decision-Augmented Reasoning”​

Trước đây chúng ta nói tới:

Case-Augmented Reasoning.

AI tìm historical cases để reasoning.

Với Accounting Judgment, có thể mở rộng:

Decision-Augmented Reasoning.

Flow:

Current Business Context

→ Retrieve Similar Decisions

→ Compare Rationale + Evidence

→ AI Analysis

→ Proposed Decision

→ Human Approval.

Đây là một use case AI rất phù hợp cho Finance.

15. Decision History trở thành Context Capital​

Nếu doanh nghiệp lưu hàng trăm decision có cấu trúc:

Context

→ Question

→ Options

→ Decision

→ Rationale

→ Outcome.

Sau nhiều năm, doanh nghiệp có một kho tri thức rất đặc biệt:

doanh nghiệp đã đưa ra những judgment nào và vì sao.

Đây là thứ AI model bên ngoài không có.

Model có thể biết accounting standards.

Nhưng model không biết:

CFO của doanh nghiệp này đã áp dụng policy như thế nào trong những context cụ thể trước đây.

Đó chính là:

Context Capital.

16. Decision History giúp giảm key-person dependency​

Một vấn đề quen thuộc trong Finance:

“Cái này phải hỏi chị A vì chị làm từ năm 2019.”

Nếu chị A nghỉ việc:

reasoning mất.

ERP chỉ còn bút toán cuối cùng.

Decision Object giúp lưu:

• question;
• rationale;
• evidence;
• approval.

Tri thức không còn nằm hoàn toàn trong:

đầu con người.

17. Decision Object cũng giúp kiểm tra Consistency​

Một AI hoặc rule engine có thể phát hiện:

Current Decision:

Treatment A.

Similar historical context:

Treatment B.

System tạo:

Decision Consistency Exception.

Không có nghĩa decision mới sai.

Nhưng nó nên hỏi:

Tại sao treatment thay đổi?

Nếu có lý do:

document.

Nếu không:

review.

Đây là một control rất mạnh.

18. Accounting Health Check có thể kiểm tra Decision Governance​

Health Check không nên chỉ kiểm tra:

hạch toán có đúng không?

Nó có thể kiểm tra thêm:

Material Judgment Exists?

→ Rationale Documented?

→ Evidence Complete?

→ Approver Valid?

→ Effective Period Defined?

→ Applied Consistently?

→ Periodic Review Completed?.

Đây là một tầng trưởng thành cao hơn nhiều so với checklist accounting truyền thống.

19. Decision có thể trở thành Expected State​

Một khi Decision được approved:

nó có thể tạo:

Expected State mới.

Ví dụ:

Decision:

Machine M03 useful life = 7 years.

Expected State:

Depreciation calculation follows 7-year life.

Hoặc:

Decision:

Transaction Type X → Account Mapping Y.

Expected State:

mọi transaction cùng context phải áp dụng mapping Y.

Như vậy:

Decision

→ Expected State

→ Detection.

Đây là một vòng rất đẹp.

20. Và Exception có thể kích hoạt Decision Review​

Chiều ngược lại cũng đúng.

Nếu Detection Engine liên tục thấy:

Expected State ≠ Actual Reality,

system có thể tạo:

Decision Review Case.

Ví dụ:

Standard cost assumption không còn phù hợp.

Useful life không còn phản ánh usage.

Materiality threshold tạo quá nhiều false positives.

Flow trở thành:

Decision

→ Expected State

→ Detection

→ Repeated Exception

→ Decision Review

→ New Decision Version.

Đây là:

continuous management learning.

21. Common Diagnostic Engine vì vậy có thêm một lớp rất quan trọng​

Kiến trúc trước đây:

Business Object

→ Expected State

→ Detection + Evidence

→ Issue

→ Case

→ Action

→ Outcome

→ Context Capital.

Accounting Judgment bổ sung một nhánh:

Business Context

→ Decision Object

→ Expected State / Policy

→ Detection.

Và sau này:

Outcome / New Evidence

→ Decision Review.

Decision không phá kiến trúc cũ.

Nó làm kiến trúc hoàn chỉnh hơn.

22. Không phải Decision nào cũng cần quản lý như nhau​

Một judgment không material có thể chỉ cần documentation đơn giản.

Một decision ảnh hưởng lớn tới financial statements có thể yêu cầu:

• CFO approval;
• audit consultation;
• evidence package;
• periodic review.

Do đó Decision Object nên có:

Decision_Risk_Class.

Ví dụ:

LOW

MEDIUM

HIGH

CRITICAL.

Từ đó system quyết định mức governance.

23. CFO nên quan tâm đến “Decision Inventory”​

Doanh nghiệp thường có:

Asset Register.

Vendor Master.

Contract Register.

Nhưng ít doanh nghiệp có:

Accounting Decision Register.

Trong khi đây có thể là một tài sản quản trị rất giá trị.

Một Decision Register có thể cho CFO biết:

Những accounting judgments material nào đang còn hiệu lực?

Decision nào sắp tới kỳ review?

Decision nào thiếu evidence?

Decision nào ảnh hưởng nhiều transaction nhất?

Decision nào đã bị override nhiều lần?

Đây là governance rất thực dụng.

24. Bắt đầu đơn giản​

Không cần triển khai một phần mềm lớn.

SME có thể bắt đầu bằng:

Google Sheet / Database

với các field:

Decision_ID

Question

Context

Decision

Rationale

Evidence_Link

Approver

Effective_Date

Review_Date

Status.

Sau đó mới kết nối:

• n8n;
• document repository;
• AI;
• accounting system.

Data Model quan trọng hơn platform.

25. Một nguyên tắc có thể khóa ngay​

Có thể tóm gọn:

Nếu một accounting judgment có thể ảnh hưởng material tới financial statement, tax, control hoặc future transactions, judgment đó không nên chỉ tồn tại trong email hoặc trí nhớ của cá nhân.

Nó nên trở thành:

Structured Decision Object.

Kết luận​

Trong Finance truyền thống, hệ thống chủ yếu lưu:

transactions.

Trong Finance hiện đại, doanh nghiệp cần lưu thêm:

decisions.

Bởi transaction cho biết:

doanh nghiệp đã làm gì.

Decision giải thích:

tại sao doanh nghiệp lại làm như vậy.

Khi Accounting Judgment được cấu trúc thành:

Context

→ Question

→ Options

→ Decision

→ Rationale

→ Evidence

→ Approval

→ Effective Period

→ Outcome,

doanh nghiệp đạt được đồng thời nhiều mục tiêu:

• auditability tốt hơn;
• consistency cao hơn;
• giảm phụ thuộc cá nhân;
• AI có business context tốt hơn;
• historical judgment trở thành organizational memory.

TT99 làm vấn đề này trở nên thực tế hơn khi chế độ kế toán mới có hiệu lực từ năm tài chính bắt đầu từ hoặc sau ngày 01/01/2026 và trong một số phần cho phép doanh nghiệp điều chỉnh hệ thống kế toán cho phù hợp hơn với hoạt động và nhu cầu quản lý, đi kèm yêu cầu tuân thủ, kiểm soát và trách nhiệm giải trình.

Nhưng ý tưởng này lớn hơn TT99.

Nó là một nguyên tắc cho Finance trong AI era:

Đừng chỉ số hóa transaction. Hãy số hóa cả judgment đứng phía sau transaction.

Bởi khi AI ngày càng mạnh, thứ tạo ra khác biệt không chỉ là model.

Mà là liệu doanh nghiệp có một lịch sử có cấu trúc về:

mình đã quyết định điều gì, trong context nào, dựa trên evidence nào và kết quả ra sao.

Đó chính là bước tiếp theo của:

Context Capital​