AI đang tiến rất nhanh vào Finance, Accounting, Tax và Operations.

Nhưng khi doanh nghiệp bắt đầu đưa AI từ:

Chat

sang:

Workflow

rồi tới:

Transaction

một câu hỏi quan trọng xuất hiện:

Phần nào nên để AI reasoning, và phần nào phải giữ deterministic?

Đây không phải câu hỏi kỹ thuật thuần túy.

Nó là câu hỏi về:

• kiểm soát;
• tính đúng đắn;
• auditability;
• trách nhiệm;
• rủi ro tài chính.

Một nguyên tắc rất hữu ích có thể tóm gọn:

AI nên reasoning trên context; calculation và control cốt lõi nên deterministic.

Nói cách khác:

Deterministic Calculation

→ tạo factual result.

Probabilistic Reasoning

→ giải thích, suy luận và đề xuất.

Đây là cách để AI mạnh nhưng vẫn giữ được:

financial integrity.

1. Vì sao không nên để LLM tính mọi thứ?

Large Language Model rất giỏi:

• hiểu ngữ cảnh;
• tổng hợp;
• phân loại;
• giải thích;
• gợi ý nguyên nhân;
• đề xuất hành động.

Nhưng nó không phải là lựa chọn tốt nhất cho những việc có thể được biểu diễn bằng:

• formula;
• rule;
• reconciliation;
• code;
• policy.

Ví dụ:

VAT payable.

Gross margin.

BOM variance.

DSO.

Inventory days.

Tax penalty.

Approval threshold.

Những thứ này nếu có công thức rõ ràng thì nên tính bằng:

deterministic engine.

Không nên hỏi AI:

“Theo em VAT tháng này khoảng bao nhiêu?”

nếu hệ thống đã có thể tính chính xác.

2. Deterministic nghĩa là gì?

Deterministic có nghĩa:

cùng một input → cùng một output.

Ví dụ:

Gross Margin = Revenue - COGS.

Nếu input giống nhau:

output phải giống nhau.

Một rule:

If Amount > 500M → CFO Approval.

Với cùng condition:

kết quả phải giống nhau.

Đây là đặc tính rất quan trọng cho Finance.

3. Probabilistic Reasoning nghĩa là gì?

AI reasoning thường không hoàn toàn deterministic.

Cùng một context, model có thể:

• diễn giải khác;
• xếp root cause khác;
• đưa recommendation khác.

Điều này không có nghĩa AI không hữu ích.

Ngược lại, AI đặc biệt hữu ích ở những nơi:

không có một công thức duy nhất.

Ví dụ:

Vì sao gross margin giảm?

Vì sao batch này có yield thấp?

Customer này có khả năng trả chậm vì nguyên nhân nào?

Đây là:

probabilistic reasoning.

4. Một kiến trúc an toàn cần tách hai lớp

Có thể hình dung:

Business Data

↓

Deterministic Layer

• calculations;
• rules;
• reconciliation;
• validation.

↓

Detection Result

↓

AI Reasoning Layer

• explanation;
• root-cause hypothesis;
• prioritization;
• recommendation.

↓

Policy / Human Approval

↓

Action

↓

Outcome.

Điểm quan trọng là:

AI không được thay thế deterministic layer ở nơi có thể kiểm tra bằng code/rule.

5. Ví dụ Accounting

Giả sử:

GL Revenue:

100 tỷ.

E-Invoice:

92 tỷ.

VAT Return:

93 tỷ.

System có thể deterministic tính:

Deviation = 7–8 tỷ.

Đây là factual result.

AI không cần tính.

AI nên làm bước sau:

Possible reasons:
– timing difference;
– credit note;
– unbilled revenue;
– posting error.

Đây là:

reasoning.

6. Ví dụ Product Costing

Standard Material:

100 kg.

Actual:

107 kg.

Variance:

+7%.

System tính:

Material Usage Variance.

AI phân tích:

Root-cause possibilities:
– material quality;
– machine setting;
– operator;
– BOM error.

Calculation:

deterministic.

Root Cause:

probabilistic.

Hai việc này không nên trộn.

7. Ví dụ Tax

Tax obligation có:

• tax base;
• tax rate;
• effective date;
• formula.

Nếu rule rõ:

system nên tính:

Tax Payable.

AI có thể:

• tìm regulation;
• phân loại transaction;
• giải thích applicability.

Nhưng final computation nên:

rule-based.

Đặc biệt với tax:

một rounding error khác hoàn toàn với một hallucination.

8. Ví dụ Approval Control

Nếu policy nói:

Payment > 200M

→ CFO Approval.

Không nên hỏi AI:

“Theo em payment này có cần CFO duyệt không?”

Đó là:

deterministic policy.

AI có thể giải thích:

đây là vendor mới + amount lớn + bank account vừa đổi.

Nhưng approval threshold vẫn do policy quyết định.

9. Prompt không phải Internal Control

Một lỗi nguy hiểm là viết trong prompt:

“Không được approve payment trên 200 triệu.”

Đây không phải control mạnh.

Vì prompt:

• có thể bị thay;
• bị bỏ qua;
• conflict;
• bị jailbreak.

Control nên nằm trong:

policy engine / workflow / ERP permission.

Prompt chỉ nên hướng AI:

reasoning.

10. Expected State nên deterministic khi có thể

Trong Common Diagnostic Engine, Expected State là nền tảng.

Ví dụ:

Invoice posted

thì expected:

• PO exists;
• Receipt exists;
• Approval complete.

Đây là deterministic expectation.

System check:

Actual vs Expected.

AI không cần phán đoán phần này.

11. Detection Result phải factual

Detection Result nên trả lời:

điều gì lệch?

Ví dụ:

PO missing.

VAT mismatch = 8%.

Yield below standard = 6 points.

Không nên trả lời:

“có vẻ bất thường”.

Factual detection giúp:

• audit;
• explainability;
• repeatability.

12. AI nên bắt đầu từ Detection Result

Sau khi factual layer tạo Detection Result:

AI mới đọc:

• context;
• historical cases;
• business object;
• evidence.

Sau đó AI có thể:

• classify issue;
• suggest root cause;
• recommend action.

Đây là ranh giới rất rõ.

13. Deterministic Engine làm nền cho explainability

Nếu AI nói:

“Tax Risk = High”

mà không biết vì sao:

rất khó dùng.

Nếu system nói:

• GL/VAT mismatch = 8%;
• supplier master invalid;
• evidence missing;

sau đó AI giải thích:

các yếu tố này tạo risk profile cao,

thì dễ audit hơn nhiều.

14. Deterministic Calculation giúp giảm hallucination

Một cách tốt để giảm hallucination:

đừng bắt AI làm phần không cần AI.

Ví dụ:

Không cần AI tính:

Revenue - COGS.

Không cần AI tính:

Current Ratio.

Không cần AI tính:

Material Variance.

Code làm tốt hơn.

AI nên dành năng lực cho:

interpretation.

15. AI nên reasoning trên Business Context

AI càng có context tốt:

reasoning càng tốt.

Context có thể gồm:

• Business Object;
• Expected State;
• Actual State;
• Deviation;
• Historical Cases;
• Policies.

Ví dụ:

Batch B2409

→ SKU A

→ Supplier S08

→ Machine M03

→ Yield 91%.

AI reasoning lúc này có cơ sở hơn nhiều.

16. Rule Engine và AI Engine không cạnh tranh nhau

Một số doanh nghiệp nghĩ:

có AI rồi cần gì rule?

Đây là hiểu sai.

Rule Engine làm tốt:

• logic rõ;
• threshold;
• validation;
• calculation.

AI làm tốt:

• ambiguity;
• explanation;
• root cause;
• recommendation.

Hai lớp bổ sung nhau.

17. Reconciliation cũng nên deterministic

Ví dụ:

Subledger ↔ GL

E-Invoice ↔ VAT

Payroll ↔ PIT.

Reconciliation là:

expected relationship check.

Nếu difference vượt tolerance:

Detection.

AI chỉ cần giải thích difference.

18. Materiality Filter cũng nên deterministic

Không phải deviation nào cũng tạo Issue.

Ví dụ:

Mismatch:

0,02%.

Có thể bỏ qua.

Materiality Filter nên dùng:

• absolute amount;
• percentage;
• risk class;
• frequency.

Sau đó mới quyết định:

Create Issue?

Đây cũng là deterministic logic.

19. Anomaly Detection là vùng giao thoa

Anomaly Detection có thể dùng:

• statistics;
• machine learning;
• AI.

Nhưng output vẫn nên là:

deviation score / anomaly probability.

Sau đó:

Materiality + policy

quyết định:

issue hay không.

Không nên để model tự:

“cảm thấy case này quan trọng.”

20. Root Cause Hypothesis nên probabilistic

Root cause thường không thể biết chắc ngay.

Ví dụ Yield thấp.

AI có thể xếp:

1. Material quality — 60%.
2. Machine setting — 25%.
3. Operator — 15%.

Đây là dạng probabilistic output phù hợp.

Sau đó human/process validate.

21. Recommendation cũng có thể probabilistic

AI có thể đề xuất:

kiểm tra supplier lot trước.

Nhưng recommendation:

không đồng nghĩa execution.

Đây là khác biệt quan trọng.

22. Recommendation → Action phải qua Policy

Flow nên là:

AI Recommendation

→ Policy Gate

→ Human Approval nếu cần

→ Execution.

Không nên:

AI Recommendation → Direct ERP Write.

Đây là core principle.

23. Deterministic Execution

Execution trong Finance cần:

• permission;
• approval;
• validation;
• audit trail.

Ví dụ:

AI đề xuất:

Create Credit Note.

System kiểm tra:

• amount;
• reason code;
• authority.

Sau đó mới:

execute.

24. AI nên giải thích, không nên quyết định authority

Authority là:

business governance.

Không nên giao cho model.

Ví dụ:

CFO approval required?

→ policy.

AI không cần quyết định.

25. Một architecture chuẩn cho Finance AI

Có thể dùng:

Source Systems

↓

Trusted Data

↓

Expected State

↓

Deterministic Detection

↓

Detection Result

↓

Materiality

↓

Issue

↓

AI Reasoning

↓

Recommended Action

↓

Policy / Approval

↓

Transaction

↓

Outcome.

Đây là kiến trúc rất cân bằng.

26. Common Diagnostic Engine phù hợp với mô hình này

Common Diagnostic Engine có thể chia:

Layer 1 — Business Objects

Layer 2 — Expected State

Layer 3 — Deterministic Detectors

• Rule;
• Reconciliation;
• Calculation.

Layer 4 — Issue Engine

Layer 5 — AI Reasoning

Layer 6 — Case / Action

Layer 7 — Outcome.

AI là một layer.

Không phải toàn bộ engine.

27. Finance Value Leakage Pack

Ví dụ:

AR overdue

Deterministic:

Days Past Due.

AI:

Root Cause / Collection Strategy.

Outcome:

Cash Recovered.

28. Tax Health Check Pack

Deterministic:

• obligation due?
• filing complete?
• GL ↔ VAT reconcile?

AI:

• explain mismatch;
• suggest evidence;
• prioritize risk.

Final tax treatment:

human + rules.

29. Smart Factory Lite

Deterministic:

• BOM variance;
• yield;
• scrap;
• downtime.

AI:

root cause.

Action:

Production/QA approval.

Outcome:

Cost reduced.

30. Case History giúp AI reasoning tốt hơn

Case History chứa:

Context

→ Root Cause

→ Action

→ Outcome.

AI có thể dùng:

Case-Augmented Reasoning.

Nhưng nó không thay deterministic calculation.

Đây là hai vòng riêng.

31. Hai vòng học

Rule Learning

Regulation / Policy / Standard

→ Expected State.

Context Learning

Case History

→ better reasoning/recommendation.

Không nên trộn hai thứ.

Rule change cần:

approval/versioning.

Case history chỉ giúp:

decision support.

32. Vì sao tách hai vòng rất quan trọng?

Nếu AI thấy:

Standard Yield 98% không thực tế.

AI có thể đề xuất:

Review Standard.

Nhưng không tự đổi:

98% → 95%.

Protected Object Policy phải kiểm soát.

Đây là governance đúng.

33. Deterministic Engine cần versioning

Rule không cố định mãi.

Ví dụ:

Tax Rule 2026 khác 2027.

Approval limit thay đổi.

BOM revision thay đổi.

Do đó mỗi rule cần:

• Version;
• Effective Date;
• Owner.

Nếu audit historical transaction:

dùng rule đúng thời điểm.

34. AI Reasoning cũng cần traceability

AI output nên lưu:

• Model;
• Prompt/Task;
• Context;
• Recommendation;
• Timestamp.

Không cần lưu chain-of-thought.

Nhưng cần đủ:

decision evidence.

35. AI confidence không thay thế control

AI có thể nói:

Confidence = 95%.

Nhưng confidence cao không có nghĩa:

được quyền execute.

Authority vẫn do:

• risk;
• object sensitivity;
• policy.

Đây là nguyên tắc rất quan trọng.

36. Autonomy nên phụ thuộc risk, không phụ thuộc confidence

Ví dụ:

Low-risk case:

AI có thể auto-close.

High-risk payment:

dù AI confidence 99%:

vẫn cần approval.

Risk-based autonomy quan trọng hơn:

model-based autonomy.

37. Một ví dụ end-to-end: BOM Variance

Standard:

100 kg.

Actual:

107 kg.

Deterministic:

Variance:

+7%.

Materiality:

>5%.

Issue created.

AI reasoning:

Likely causes:

• material quality;
• machine setting.

Similar cases:

3/5 related Supplier S08.

Recommendation:

Check material lot.

Production validates.

Supplier issue confirmed.

Action:

Supplier claim.

Outcome:

Variance reduced.

Đây là AI đúng vai trò.

38. Một ví dụ end-to-end: Tax Risk

GL Revenue:

100 tỷ.

VAT:

92 tỷ.

Deterministic:

Difference:

8 tỷ.

Risk threshold exceeded.

Tax Issue created.

AI reasoning:

Possible causes:

• timing;
• credit note;
• exempt revenue.

Tax team validates.

Outcome:

Timing difference documented.

No adjustment needed.

AI không:

tự sửa tax return.

39. Một ví dụ end-to-end: AR Collection

Invoice:

320 triệu.

Due:

45 days ago.

Deterministic:

Overdue = 45.

Issue created.

AI reasoning:

Historical cases show dispute likely.

Recommendation:

Check commercial dispute first.

Sales resolves dispute.

Cash collected.

Outcome:

300 triệu.

40. KPI nên tách giữa Engine và AI

Deterministic Engine KPI:

• Accuracy;
• Reconciliation Coverage;
• Detection Precision.

AI Reasoning KPI:

• Recommendation Acceptance;
• Root Cause Accuracy;
• Human Override Rate.

Business KPI:

• Cash Recovered;
• Risk Reduced;
• Value Leakage Recovered.

Không nên gộp tất cả thành:

“AI accuracy”.

41. AI Cost cũng nên đo theo Case

Agent cost:

không chỉ token.

Nên đo:

Cost per Detection

Cost per Case

Cost per Successful Outcome.

Nếu deterministic layer xử lý phần đơn giản:

AI chỉ chạy cho case material.

Chi phí giảm đáng kể.

42. Model Routing

Có thể dùng:

Rule

→ straightforward case.

Small Model

→ normal reasoning.

Frontier Model

→ complex case.

Human

→ high-risk.

Đây là:

cost-aware reasoning architecture.

43. Vì sao kiến trúc này phù hợp SME?

SME không cần:

• AI platform lớn;
• autonomous agents ngay.

Có thể bắt đầu:

Google Sheets / SQL

→ formulas/rules

→ n8n

→ AI API

→ approval

→ ERP/manual write-back.

Kiến trúc vẫn đúng.

44. AI maturity nên tăng dần

Level 1

Deterministic detection.

Level 2

AI explanation.

Level 3

AI recommendation.

Level 4

AI prepares action.

Level 5

Controlled execution.

Không nên nhảy thẳng:

Level 1 → Autonomous Agent.

45. Nguyên tắc cốt lõi cho CFO

CFO có thể nhớ:

Nếu có thể tính chính xác bằng rule/code, đừng để AI đoán.

Nếu cần hiểu context và ambiguity, hãy dùng AI.

Nếu action ảnh hưởng transaction, phải có policy.

Ba câu này đủ để thiết kế phần lớn Finance AI.

46. Từ AI-first sang Control-first

Một architecture tốt không hỏi:

AI có làm được không?

Mà hỏi:

phần nào cần intelligence?

phần nào cần certainty?

Finance cần cả hai.

AI cung cấp:

flexibility.

Deterministic Engine cung cấp:

certainty.

47. Common Diagnostic Engine trở nên rõ hơn

Có thể chốt:

Business Object

→ Expected State

→ Deterministic Calculation / Detection

→ Deviation

→ Materiality

→ Issue

→ AI Reasoning

→ Recommended Action

→ Policy / Approval

→ Action

→ Outcome

→ Context Capital.

Đây là architecture rất bền.

Kết luận

AI sẽ ngày càng mạnh.

Nhưng Finance không nên vì thế mà biến mọi thứ thành probabilistic.

Một enterprise AI architecture tốt cần biết:

nơi nào cần certainty

và:

nơi nào cần intelligence.

Calculation, reconciliation, validation và authority nên càng deterministic càng tốt.

AI nên tập trung vào:

• interpretation;
• context;
• root cause;
• prioritization;
• recommendation.

Có thể tóm lại:

Deterministic Engine

trả lời:

What is true?

AI Reasoning trả lời:

Why might this be happening, and what should we do?

Policy trả lời:

What are we allowed to do?

Execution trả lời:

What actually happened?

Outcome trả lời:

Did it create value?

Đó là cách để AI đi vào Finance một cách thực tế:

mạnh hơn nhưng không mất kiểm soát.

Và cũng là một trong những nguyên tắc kiến trúc cốt lõi cho:

AI-enabled Finance Operating System