Explainability. Grounded reasoning
When the AI rejects an invoice, classifies an expense, or flags an anomaly, it points to the exact passage in the customer’s policy or document which supports the decision. We call this grounded reasoning. It is the strongest mitigation we have against hallucination and the foundation of transaction-level transparency.
Context
Section titled “Context”The difference between a usable AI in B2B finance and an unusable one is whether its outputs are audited at the transaction level. An accountant who reads “this invoice seems high, I rejected it” does not defend the rejection to a vendor or to the CFO. An accountant who reads “this invoice exceeds Travel Policy §4.2 (cap 5M VND for client tier 2) by 3M VND” does. The first is theatre. The second is governance.
What a grounded output contains
Section titled “What a grounded output contains”- Citation. The source passage. Policy section, contract clause, transaction history.
- Source link. A direct link to the document inside tenant data.
- Reasoning chain. A one-to-three sentence trace from the source to the conclusion.
Where grounding applies
Section titled “Where grounding applies”Grounded reasoning is required for any AI action with downstream consequence:
- Approval or rejection of an invoice or expense. Cite the policy section.
- Expense category assignment. Cite the rule which maps the line item to the category.
- Anomaly warning. Cite the baseline data the AI compared against.
- Suggested journal entry. Cite the chart of accounts.
- Chatbot answer to a policy question. Cite the document retrieved by RAG.
How we deliver it. RAG with citation enforcement
Section titled “How we deliver it. RAG with citation enforcement”The pipeline which produces a grounded output has five fixed steps:
- Retrieval. The query is embedded and matched against the tenant’s vector index. The top-K relevant chunks are returned with metadata.
- Context injection. The top-K chunks are injected into the LLM prompt with stable identifiers.
- Constrained generation. The system prompt requires the LLM to cite chunks by identifier in its output.
- Verification. The output is parsed. Every citation is validated. The chunk must exist and its content must match what was retrieved.
- Render. The UI displays the citation as a link to the source document in tenant storage.
A response which fails verification is not served. Either the model retries with a stricter prompt or the request escalates to HITL.
Worked example
Section titled “Worked example”Situation. An accountant submits a client entertainment invoice for 8M VND.
Grounded output.
“I cannot auto-approve this invoice. Under Travel Policy §4.2: ‘Client entertainment expenses for tier-2 clients shall not exceed 5M VND per occasion.’ This invoice lists a tier-2 client (‘B’) and a value of 8M VND. Please obtain CFO approval before proceeding.”
Source: Travel Policy 2026 §4.2
Ungrounded output (which we do not ship).
“This invoice looks high. I’m rejecting it.”
The first output is defended to the vendor, to the CFO, and to an external auditor. The second is not.
Edge cases
Section titled “Edge cases”- Conflicting sources. If two policy sections apply and disagree, the AI flags the ambiguity and escalates to a human. It does not pick a side.
- Outdated source. Policies change but RAG corpora lag. Every retrieved chunk carries a version timestamp. If the retrieval surfaces a stale version, the output discloses the version it cited and the user refreshes the corpus.
- No source available. If the AI is offering a general suggestion (“you should consult Accounting”), the output is labelled as such. “This is a general suggestion, not derived from your policy.” Treated as advisory only.