When AI agents start matching invoices, proposing journals or clearing reconciliations, external auditors will want audit evidence for AI agents in the same way they want it for any other control that touches the ledger. The real question is whether that evidence exists when the auditor asks, or whether the team spends interim and year-end fieldwork reconstructing it from system logs and memory. This article sets out what auditors are likely to request, how they test it, where deployments typically fall short, and how to run a monthly evidence routine that keeps you ready throughout the year.
1. Why external auditors look harder at AI agents
An auditor's job does not change because software made a decision. They still need to conclude whether the financial statements are free from material misstatement, which means understanding the controls the business relies on and whether those controls operated through the period. A rules-based automated control is familiar ground. An agent that reads a supplier invoice, reasons about a price variance and decides where to route it is harder to pin down, because its behaviour depends on a model, instructions, reference data and thresholds that can all change.
That uncertainty is what draws scrutiny. Auditing standards expect auditors to understand the IT environment and the general controls around applications relevant to the audit, and an agent posting to SAP or Oracle is plainly relevant. Expect questions about who designed it, what it may do, how you know it behaved the same way in March as in October, and what happens when it is wrong. Teams that keep audit evidence for AI agents in a maintained file, rather than in people's heads, tend to get through fieldwork faster.
2. What audit evidence for AI agents will auditors ask for?
The request list usually falls into five groups. First, a description of each agent: its role, the process it sits in, the systems it reads from and writes to, and the assertions it supports. Second, its decision rights and the thresholds above which a person must decide. Third, logs of what it actually did, transaction by transaction. Fourth, change records for the model, instructions, rules and reference data. Fifth, evidence that people reviewed exceptions properly.
Of these, decision rights cause the most trouble. Many pilots give a service account broad ERP access and rely on the agent's instructions to keep it in bounds. Auditors will not accept a prompt as a control. They want system-enforced limits, and they will test how those limits fit your segregation of duties for AI agents, for example whether one identity can both create a vendor and release a payment to it. If the answer depends on the agent choosing not to, expect a finding.
The approval evidence matters just as much. A queue of exceptions closed in seconds by the same reviewer looks like rubber-stamping, whatever the policy says. Well-designed human-in-the-loop approvals record the reviewer's identity, the information they saw and the reason for their decision. That record is part of the evidence an auditor will sample, so treat it as a control output rather than an operational nicety.
3. IT general controls for AI: access, change and operations
Most of the reliance an auditor places on an agent comes through IT general controls for AI, the same three families that apply to any financial system. Access covers who can configure the agent, change its thresholds or run it with elevated rights, and how that access is approved and reviewed. Change covers how updates are requested, tested, approved and released. Operations covers how failures, retries and outages are monitored, and how you prove no transactions were dropped or processed twice.
Change management evidence is where agentic systems differ most from traditional applications. A provider may update the underlying model, or a developer may adjust instructions to handle one awkward supplier. Either can change outcomes. Treat both as production changes: version them, test them against a fixed set of historical cases with known answers, record the results and obtain sign-off from the process owner. Keep the test set itself under control, because an auditor reperforming your test needs exactly the inputs you used.
4. How auditors test AI controls in practice
Walkthrough first. The auditor picks a transaction, perhaps an invoice the agent auto-approved, and traces it from the source document through the agent's checks to the ERP posting. They want the inputs used, each check performed and its result, and the posting reference. Then they repeat the exercise for an item that was escalated to a person. If any step lives only in a chat window or a developer console, the walkthrough stalls and the audit team starts asking for screenshots.
Operating effectiveness comes next. For automated controls testing, auditors often test the configuration once and rely on general IT controls to show nothing changed, which makes your change log the critical document. Where the agent exercises judgement, expect sampling and reperformance. Take a group with entities in Dubai and Riyadh where an agent clears intercompany differences within a tolerance. The auditor may reperform a sample in both entities and ask why an item cleared in one was escalated in the other. The answer has to come from the configuration in force at the time, not from recollection.
5. Building an AI audit trail that stands on its own
An AI audit trail should let someone who was not in the room reconstruct any decision months later. For each transaction, capture the source documents or data references, the agent and model version, the configuration and thresholds in force, the checks run and their results, the decision, any escalation and who resolved it, and the ERP posting reference. Every step needs a timestamp and an identity. Store the record where the agent cannot edit it, retained in line with your record-keeping obligations.
Design matters more than tooling here. Logs written to an application monitoring tool are hard for finance to query and easy to purge. A better pattern writes decision records to a governed data layer alongside ledger data, so the controller can filter by entity, period or vendor and export a sample in minutes. Explanations should be plain language a reviewer can follow, tied to the evidence they rely on, rather than raw model output.
This is the standard AITHENTIC holds its own finance AI agents to: each has a defined role, decision rights, escalation logic and a full audit trail, and people approve exceptions. Whichever platform you choose, ask the vendor to reconstruct a decision made six months ago before you sign. A live demonstration of today's processing tells you very little about what you will be able to show an auditor next year.
6. Continuous audit readiness: keeping evidence current all year
Audit-ready AI is a monthly routine rather than a year-end project. Teams that handle audits well run a short evidence cycle inside the close: confirm the agent inventory is current, review access to agent configuration, reconcile the change log to what is running in production, reperform a handful of agent decisions and check that exception reviews were completed within policy. Each step produces a dated, signed artefact that goes straight into an evidence folder mapped to the control matrix.
Give each agent control a place in the risk and control matrix like any other control, with a named human owner, a frequency, a description of the evidence produced and a link to the logs. Once that mapping exists, the audit evidence for AI agents becomes an export rather than a scramble when the interim request list arrives. Walk the audit team through the design before the period starts; explaining it once in advance is far cheaper than defending it afterwards.
Be honest about where heavy evidence is not worth the effort. An agent that drafts variance commentary for management does not need the same regime as one that releases payments, because a person reads and owns every word before it leaves finance. Scope the full controls to agents that post, approve or change financial data, and keep lighter documentation for advisory agents. Auditors respect a reasoned scoping decision far more than a uniform pile of paper.
Key challenges
- Agents running under broad service accounts, with limits enforced only by instructions rather than system roles.
- Model, instruction and threshold changes made outside formal change management.
- Decision logs held in developer tools that finance cannot query, export or retain.
- Exception reviews that look like rubber-stamping because reviewer context and reasoning are not recorded.
- No named human owner for agent controls in the risk and control matrix.
The framework
A workable operating model treats each agent as a control with its own evidence file in four layers. Design sets out the role, scope, assertions supported, decision rights and thresholds. Integrity covers access, change and operations controls over the agent and its configuration. Execution is the per-transaction decision record held on a governed data store that finance can query. Oversight is the monthly cycle of exception review checks, sampling and reperformance, signed by a named owner. Design is agreed with the auditor before the period begins, integrity and execution produce evidence continuously, and oversight turns that evidence into a dated monthly conclusion. If any layer is missing, the auditor will rebuild it with you during fieldwork, at considerable cost in time.
How to implement it
- Build an inventory of every agent that reads, posts, approves or changes financial data, with a named owner and the assertions it supports.
- Replace instruction-based restrictions with system-enforced roles and thresholds in the ERP and the agent platform.
- Put model versions, instructions, rules and tolerances under change control, with a fixed regression test set and process-owner sign-off.
- Write a per-transaction decision record to a governed store that finance can query, retained in line with record-keeping policy.
- Add a monthly evidence cycle to the close covering access review, change reconciliation, decision reperformance and exception review completion.
- Walk the external audit team through the agent design and evidence pack before the period under audit begins.
Frequently asked questions
What evidence do auditors need for AI agents in finance?
Auditors typically need five things: a description of each agent and its process, system-enforced decision rights and thresholds, per-transaction logs, change records for models, instructions and configuration, and proof that people reviewed exceptions. Together these form the audit evidence for AI agents that lets an auditor walk through a transaction, test operating effectiveness and decide whether to rely on the control.
Can external auditors rely on AI-driven controls?
Yes, if the controls are designed and evidenced well. Auditors can rely on an agent when general IT controls over access and change are effective, its limits are enforced by the system rather than by instructions, and its decisions can be reconstructed and reperformed. Where any of these is weak, they usually extend substantive testing instead, which takes longer.
How do you keep an audit trail for AI decisions?
Record a decision entry for every transaction the agent handles: inputs, model and configuration version, checks run, outcome, any escalation and reviewer, and the ERP posting reference. Store it in a governed location the agent cannot alter, with timestamps and identities on each step, so finance can export samples for auditors without developer help.
Do AI model updates count as changes for audit purposes?
Yes. A new model version, an edited instruction or a revised tolerance can change how transactions are treated, so auditors expect these to follow change management like any other production change. That means a documented request, testing against known historical cases, approval by the process owner and a record of when the change went live.
