Before an AI Agent Posts a Journal: Identity, Accuracy and Audit Trail Controls for CFOs

An AI assistant finds a possible missing accrual during the month-end close. It reads an invoice, compares a purchase order and proposes a journal.

The draft looks reasonable. The debit and credit even balance.

Should the system be allowed to post it?

That is not primarily a question about how clever the model is. It is a question about identity, authority, accuracy and evidence. A CFO can automate much of the investigation without delegating the final accounting decision to a language model.

The distinction matters because agent capabilities come from the tools and permissions we deliberately give them. An agent does not acquire ERP posting rights simply because it can explain an accounting treatment. OWASP (the Open Worldwide Application Security Project, a nonprofit organization known for practical application-security guidance) identifies excessive functionality, excessive permissions and excessive autonomy as distinct sources of risk in LLM-powered systems. See OWASP's Excessive Agency guidance.

The practical case: an accrual proposed at close

Consider a hypothetical October close for a services business. A supplier invoice for ₹480,000 arrives after the cut-off. A purchase order exists, but the delivery or service-acceptance evidence has not yet been confirmed. An AI-enabled close assistant spots the invoice and proposes:

• Debit: relevant operating expense, ₹480,000
• Credit: accrued expenses, ₹480,000
• Explanation: expense appears to relate to October, subject to service-period verification

The balanced journal is not proof that the journal is correct. The service might have been delivered in November, posted elsewhere, disputed, or only partly received. Those are evidence and accounting questions.

A useful system should be able to identify the uncertainty and stop, not manufacture a definitive answer.

These controls are requirements for the illustrative design, not claims that an existing implementation automatically delivers them.

Separate investigation, decision and execution

The four stages have different jobs:

1. AI investigation: retrieve permitted invoices, purchase orders, acceptance records and prior accruals. Draft an explanation with explicit uncertainties.
2. Deterministic validation: check duplicate candidates, currency, arithmetic, account mapping, period and policy thresholds. These calculations should run in tested code, not rely on model prose.
3. Human review: verify evidence, decide on accounting treatment and approve or reject within the established authority framework.
4. Controlled posting: a separate executor validates an approved, unexpired and single-use posting request before calling the ERP. It must not trust the model's instruction alone.

Do not confuse these stages with a requirement to deploy four separate AI agents. A conventional workflow service can perform validation and execution more predictably and with fewer privileges.

Control 1: whose identity is acting?

An AI workflow may involve at least four identities: the employee who started the task, the automation workload, the person who approved the decision and the technical service that executed the action.

If everything appears in the ERP as a single generic integration account, the team may be unable to distinguish who requested, evaluated, approved and executed a consequential transaction.

My preferred control design is to:

• Allocate a distinct and traceable workload identity to the application or agent that accesses finance evidence.
• Grant only the data and tool scopes required for that work. Investigation should be read-only by default.
• Preserve the initiating user and approver in the business event record even when downstream execution uses a service principal.
• Issue time-bound permissions where supported, rotate credentials and regularly review unused privileges.
• Avoid exposing ERP administrator credentials or broad write tools to the language model.
• Make any approval service validate the real authorized approver, not a name or email string supplied by the agent.

An identity is not the same thing as authority. A service account tells you which system called the API. It does not necessarily establish that a human had the right to approve a journal.

Minimum permissions by role

This separation is a practical response to the Open Worldwide Application Security Project's (OWASP) excessive-agency risk. The exact matrix will differ by ERP, company policy and transaction type.

Control 2: accuracy is not a confidence score

A fluent explanation is not a tested accounting conclusion.

For the ₹480,000 example, the control system should independently establish whether the invoice relates to the correct period, whether the amount and currency are valid, whether the proposed accounts are permitted and whether a duplicate accrual exists.

Accuracy needs several separate tests:

• Numerical accuracy: reproduce calculations in deterministic code, including rounding and currency conversion.
• Source accuracy: link each material claim to a specific retained record and version, not only to a document title.
• Policy accuracy: check against the organization's approved, versioned policy rather than an unverified summary.
• Decision accuracy: test whether the recommendation distinguishes known facts from assumptions requiring finance judgment.
• Operational accuracy: measure false positives, missed exceptions and the rate at which reviewers overturn agent recommendations.

A model-provided confidence of 95% is not evidence of a 95% accounting accuracy rate. Such a figure is meaningful only if its interpretation is defined and calibrated against a representative test set.

Build a small acceptance dataset before production: clean cases, duplicate invoices, missing delivery evidence, wrong-period documents, foreign currency errors and deliberate contradictions between sources. Record both missed exceptions and unnecessary escalations.

NIST's AI Risk Management Framework and Generative AI Profile offer broader approaches to governance, measurement and ongoing risk management. They are not accounting standards and do not replace the entity's finance control framework.

Control 3: what must the audit trail show?

A chatbot transcript on its own is not a sufficient finance audit trail. It may show an answer without showing the source version, actual tool result, authorization decision or ERP receipt.

For this journal example I would retain an event sequence such as:

These timestamps are illustrative, not measured system logs.

Treat audit integrity as a system property. Restrict who can edit or delete logs, define retention, secure access to source documents and reconcile execution events to the actual ERP. A log created by an agent and stored somewhere that the same agent can rewrite does not establish independent evidence integrity.

Consider the failure case: the agent recommends ₹480,000, an approver accepts, but the ERP rejects the posting. The record must not say "journal posted." It should show approved, execution failed, with the retry or escalation recorded. The eventual ERP response is the evidence of execution.

A practical 30-day implementation sequence

Week 1: define one low-risk workflow. Choose a single recurring close exception. Document source systems, data fields, decision points, transaction thresholds and the authoritative process owner. Start with recommendation-only operation.

Week 2: establish identity and approval boundaries. Set a separate read-only identity for investigation, restrict tool scopes, document allowed actions and implement a real human-approval mechanism. Test an attempted unauthorized write and verify it is blocked.

Week 3: build the evidence trail and accuracy tests. Save document versions, rule outcomes, proposals, reviewer decisions and execution responses. Run test cases with duplicate invoices, missing evidence, incorrect periods and contradictory sources.

Week 4: run in parallel with the current process. Compare proposed decisions with reviewers' decisions. Measure exception detection, reviewer overrides, missing evidence, end-to-end processing time and any differences between authorized and executed transactions. Expand authority only after the results justify it.

Do not begin by giving the assistant write access to production ERP. Begin by demonstrating that it can investigate, explain, document and escalate reliably.

A simple CFO review checklist

Before authorizing an AI-enabled finance workflow, ask:

1. Identity: Can we identify the initiating user, automation and approver separately?
2. Authority: What tools and systems can each component actually access?
3. Accuracy: Which figures are recomputed, and how have recommendations been tested?
4. Evidence: Can an independent reviewer recreate the conclusion from retained source records?
5. Approvals: Which decisions require human judgment or formal Delegation of Authority?
6. Execution: Can the workflow prove that the ERP actually accepted the approved action?
7. Failure: What happens when evidence is missing, outputs disagree or a tool call fails?
8. Monitoring: Who reviews overrides, access changes, drift, failures and cost?

If these questions cannot be answered, the problem is not that the organization needs a more powerful model. The operating controls are incomplete.

Questions CFOs often ask

Should an AI agent have its own identity?

A traceable application or workload identity is generally preferable to a shared administrator login. But keep the human initiating, reviewing and approving the transaction separately attributable. The technical design depends on the identity provider and ERP.

Can the agent post journals by itself?

Technically, an automation with write permissions can do so. That is precisely why permission boundaries matter. For consequential finance entries, a restricted execution service should enforce approved business rules and appropriate authorization. A model recommendation is not approval.

How can we test accuracy without reviewing every output forever?

Initially, review all recommendations in a bounded pilot. Build a labelled set of expected outcomes and measure false positives, missed exceptions and reviewer overrides. As performance becomes stable, consider risk-based sampling for low-risk recommendations while preserving review for significant judgments and actions.

Does an AI conversation history count as an audit trail?

Not on its own. An audit trail also needs source lineage, identity, tool results, approvals, state transitions and proof of execution or failure, all retained under defined access and integrity controls.

Do these controls stop an agent from being useful?

No. They allow the system to complete the labour-intensive investigation while keeping financial decisions and sensitive actions appropriately controlled. A read-only assistant that resolves a genuine evidence gap can already save meaningful analyst time, though savings must be measured rather than assumed.

Is this a real implementation or measured case study?

The ₹480,000 journal and event timeline are illustrative. They are provided to explain a practical control architecture. No client deployment, performance improvement, accuracy percentage or audit outcome is claimed here.

Related reading and primary sources

• OWASP: Excessive Agency in LLM Applications – unnecessary tool privileges and autonomy.
• NIST AI Risk Management Framework – voluntary governance, mapping, measurement and management of AI risks.
• NIST Generative AI Profile – cross-sector risk considerations for generative AI.
• NIST AI RMF Playbook – examples of practical risk-management actions.
• The Finance Control Framework: From Rule to Evidence – my six-part control-card method.
• AI Agents Need a Delegation of Authority – when capability expansion and spending need approval.
• Deterministic vs Agentic AI in Finance – choosing rules, model assistance or multi-step investigation.

By Akshan Kumar. These are my personal views and an illustrative control design, not a description of client work, legal advice, or a claim that a particular control is mandated by the external frameworks cited.