Audit trail for finance agents: what to log

By KYN AI Advisory Team — AI implementation specialists, Singapore

A finance agent's audit trail should let a reviewer answer five questions about any entry: who did it, what changed, why, on what evidence and who approved it. That takes twelve fields per action, written to an append-only store the agent cannot edit. Log the inputs and the rule version, not just the result. Keep the records for at least as long as your tax authority requires: five years for GST and income tax records in Singapore.

Why does a finance agent need its own audit trail?

An agent acts faster and more often than a person, and it leaves no memory of its own. Without a log, a wrong journal entry looks the same as a right one. With a log, you can reconstruct what happened, find the rule that was wrong and fix every entry it touched.

There are three readers of the trail:

• The finance lead who needs to know why a number changed.
• The external accountant or auditor who needs to trace a figure to a document.
• The engineer who needs to find out why the agent did something unexpected.

The trail serves all three if each record is complete on its own. A record that says "journal posted" fails all three. A record that says who, what, why, evidence and approval serves them.

What are the twelve fields to log?

Write one record per action. An action is any read that matters, any proposal, any write and any decision.

| # | Field | Example | |---|---|---| | 1 | Timestamp, with time zone | 2026-10-29T08:02:11+08:00 | | 2 | Actor ID | agent:bill-reader, or a named user | | 3 | Actor type | agent, person, scheduled job | | 4 | Action | bill.extracted, journal.drafted, payment.held | | 5 | Object type and ID | bill 4471, journal 982 | | 6 | Before state | field values prior to the change | | 7 | After state | field values after the change | | 8 | Rule or prompt version | dup-check v7, extract-prompt v12 | | 9 | Evidence | source document ID and hash, rate row ID, email ID | | 10 | Model and parameters | model name, temperature, tool calls made | | 11 | Approver and decision | person ID, approved, rejected or edited, with reason | | 12 | Correlation ID | links every step of one workflow run |

Fields 6 and 7 let you undo a change. Fields 8 to 10 let you reproduce it. Field 11 proves that a person was in the loop where policy says one must be. Field 12 lets you pull the whole story for one bill, one payment run or one month-end.

Which actions must wait for a person, and how is that logged?

Our rule is that money, filings, outbound messages and deletions wait for a named person. The log should show that the rule held. For each gated action, record two events:

1. proposed by the agent, with the evidence.
2. approved or rejected by a person, with the person's ID, the time and an optional reason.

The system should refuse to execute the action unless event two exists and its actor differs from the proposer. Do not rely on a policy document. Make it a check in the code path. For the broader pattern, see setting approval gates for high-risk agent actions.

Also log the denials. When the agent tries something its account is not allowed to do, the permission error is a record. A pattern of denied attempts is an early signal that a prompt or a rule has drifted, which is covered in compliance drift in autonomous runbook execution.

How do you make the log trustworthy?

A log that the logged system can edit is not an audit trail. Four properties matter.

• Append-only. The agent's account can insert records and cannot update or delete them. Corrections are new records that point to the old one.
• Separate store or account. Write the trail to a table or bucket the agent's own credentials cannot modify. Object storage with versioning and a retention lock, or a database table with insert-only grants, both work.
• Named accounts everywhere. Each agent has its own restricted account, and each person signs in with their own identity. A shared login makes field 2 meaningless. If you use one cloud identity service for both, the identity in the log matches the identity in the cloud audit log.
• Tamper evidence. Hash each record with the hash of the one before. A break in the chain shows an edit. This is cheap and catches the quiet cases.

Do not log secrets. Store a reference to the document, not the bank account number. If a record must contain personal data, the log inherits the same access controls as the source system.

How long do you keep it?

Keep finance records at least as long as the law requires. In Singapore, IRAS/basics-of-gst/invoicing-price-display-and-record-keeping/keeping-records) sets a minimum of five years for GST records, and the same period applies to income tax records. If you change software, the old records must stay retrievable. For the agent trail, the practical rule is to keep it as long as the accounting entries it explains.

Plan for volume. Assume a workflow writes 15 records per bill. A team that handles 500 bills a month then writes 90,000 records a year. That is small by database standards. The cost problem is not storage. It is making the log searchable by bill, by actor and by date.

What should a reviewer be able to do with it?

Test the trail with five tasks. If any takes more than a few minutes, fix the log, not the reviewer.

1. Pick any journal entry. Find the source document, the extraction, the rule version and the approver.
2. Pick any payment. Show who proposed it, who approved it and what checks ran.
3. Pick a rule change. List every entry produced under the old version.
4. Pick an agent. List everything it did last week.
5. Pick a person. List everything they approved last month.

The fifth task matters more than it looks. It shows whether approvals are real or whether one person approves forty items in two minutes. Log how long the approval screen was open.

How does this connect to duplicate and vendor checks?

Each check result is itself a record: rule fired, outcome, evidence. A hold on a bill is an event, and so is its release. When a reviewer later asks why a payment was delayed, the trail has the answer. See duplicate payment and vendor change checks.

Where KYN fits

Every KYN system logs each action with the actor. Agents have their own restricted accounts, people sign in with named accounts through the cloud provider's identity service, and the database uses row-level security. Outbound messages, money, filings and deletions wait for a named person. The logs sit in a cloud account in your name, so you keep them if you revoke KYN's role. See security and finance systems.

The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days.

Frequently asked questions

Is the model's reasoning text part of the audit trail?

Log the inputs, the output, the rule or prompt version and the tool calls. Reasoning text can be stored as supporting detail, but it is not evidence. The evidence is the source document and the rule.

Who should have access to the log?

The finance lead, the external accountant on request and the engineers who run the system. Nobody, including engineers, should be able to edit it. Access to read is itself logged.

Do we need a separate tool for this?

Not at first. A database table with insert-only grants plus a nightly export to versioned storage covers most SMEs. Add a dedicated tool when volume or an auditor requires it.

Checked 30 October 2026.

Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.

Start Building →