AI in audit: auditing with AI under the ISAs

What auditing with AI means

Auditing with AI means using machine learning, language models and data analytics to perform or support audit procedures: analysing whole ledgers, reading contracts, drafting working papers and flagging unusual items. It matters because the auditor still signs the opinion. AI changes how evidence is gathered and documented, not who is responsible for judging whether it is sufficient and appropriate.

The International Standards on Auditing (ISAs) do not ban or endorse any tool. They set outcomes: understand the entity and its risks (ISA 315 (Revised 2019)), design responses (ISA 330), obtain relevant and reliable evidence (ISA 500), evaluate misstatements (ISA 450) and document the work so that an experienced auditor with no previous connection to the engagement can understand it (ISA 230). Every AI-assisted procedure has to be judged against those same requirements.

This guide covers external and internal audit: where AI fits in the audit cycle, when testing 100% of a population replaces sampling, whether AI output counts as audit evidence, how to document it, and how to audit a client that uses AI to prepare its own entries. For the fraud-focused selection criteria of journal testing, see our guide on journal entry testing and fraud red flags; for sample sizes, see audit materiality and sampling.

Where AI fits in the audit cycle

AI is most useful where the audit is data-heavy or text-heavy, and least useful where the auditor needs evidence from outside the entity or physical observation. A practical map of the audit cycle looks like this.

• Acceptance and planning: summarising prior-year files, board minutes and public filings to identify changes in the business; the engagement partner still decides whether to accept.
• Risk assessment under ISA 315 (Revised 2019): profiling the full general ledger by account, user, source and month to find where volumes or values moved, which ISA 315 calls using automated tools and techniques.
• Analytical procedures under ISA 520: building expectations from non-financial data, such as payroll cost from headcount and pay rates, and explaining differences.
• Tests of details: matching every invoice to a dispatch note and a receipt, recomputing every depreciation charge, or reading every lease contract for key terms.
• Contract and document review: extracting renewal dates, penalties and guarantees from hundreds of agreements for the auditor to verify.
• Completion: comparing the draft financial statements with the trial balance and the disclosure checklist, and drafting the summary of misstatements for review.

Full-population testing versus audit sampling

ISA 530 applies when the auditor selects less than 100% of a population and draws a conclusion about the whole. When a tool tests every item, the procedure is not sampling at all: ISA 500 recognises selecting all items as one of the ways of choosing items for testing, alongside selecting specific items and audit sampling. There is no sampling risk to evaluate, because nothing is being projected.

Full-population testing is not full assurance. A routine that matches every invoice to a dispatch note proves that the documents agree with each other; it does not prove that the dispatch notes are genuine, that the customer exists or that the revenue belongs in this period. It is only as good as the data it runs on and the rule it applies, and it usually produces hundreds of exceptions that the auditor must resolve rather than ignore.

Audit sampling AI tools blur a line that matters. If a model ranks transactions by risk and the auditor tests the top 40, that is a targeted selection of specific items: the results say nothing about the untested items and cannot be projected. If the auditor wants a conclusion about the whole population, the selection must follow a sampling design under ISA 530, such as monetary unit sampling, whatever software draws the items.

• Use full-population analytics for rules that can be checked mechanically: matching, recomputation, duplicates, cut-off dates, gaps in numbering.
• Keep sampling or targeted testing for evidence the data cannot supply: external confirmations, physical inspection, reading a signed contract.
• Combine them: analytics to split the population, then targeted tests on the exceptions and a sample from the remainder if a residual risk is left.

Is AI output audit evidence?

ISA 500 requires the auditor to consider the relevance and reliability of information used as audit evidence and, for information produced by the entity, to evaluate whether it is sufficiently complete and accurate. AI adds two links to that chain: the data the tool was given and the tool itself.

Separate two kinds of AI use. In the first, AI helps write a deterministic routine, such as a matching script or a spreadsheet formula, which is then tested and run. The evidence is the output of that routine, and the auditor tests the routine once, like any other audit software. In the second, a language model makes a judgement directly, such as reading a contract and stating that it contains no termination penalty. That statement is not evidence about the contract; the contract is. The model's reading is a pointer that tells the auditor where to look, and the auditor verifies it against the source.

At firm level, ISQM 1 requires quality objectives for obtaining, implementing, maintaining and using appropriate technological resources, and AI tools used on engagements are such resources. In practice that means an approved list of AI tools, a view on how each one handles client data, and guidance on which procedures they may support.

• Data completeness: reconcile the extract to the trial balance before running anything.
• Data accuracy: agree a few records back to source documents, and understand the system that produced them.
• Tool reliability: test scripts on known cases; for language models, check every flagged item and a selection of unflagged ones.
• Reproducibility: record the model name and version, the prompt and the input files, because the same request may not return the same answer twice.

Worked example: revenue matched in full, and an AI summary rejected

An auditor of a distributor sets overall materiality at EUR 150,000, performance materiality at EUR 112,500 and the clearly trivial threshold at EUR 7,500. The sales ledger extract holds 18,400 invoices totalling EUR 12,600,000, while revenue in the trial balance is EUR 12,640,000. The EUR 40,000 difference is two manual year-end journals for accrued revenue, which the auditor tests separately. Only then is the extract accepted as complete.

A matching routine compares every invoice with dispatch notes and cash receipts: 18,212 invoices match fully and 188 are exceptions, so 18,212 plus 188 equals 18,400. An AI assistant then summarises the exceptions and concludes that the 36 January credit notes need no further work because each one is below the clearly trivial threshold. The reviewer rejects that conclusion: under ISA 450, a matter is clearly trivial only if it is clearly inconsequential individually and in aggregate, and misstatements are accumulated. The exceptions are then worked through by type.

The identified misstatements total EUR 55,000, below performance materiality but above clearly trivial, so they go on the summary of misstatements and are proposed to management, assuming the invoices are unpaid: Dr Revenue 55,000 / Cr Trade receivables 55,000, and for the goods still held, Dr Inventory 15,000 / Cr Cost of sales 15,000. Each entry balances. The software did the matching and the summarising; the reviewer's judgement changed the conclusion.

• 140 invoices, EUR 1,120,000, dispatched but unpaid at year end: expected, and covered by the receivables work on confirmations and after-date cash.
• 36 credit notes raised in January against December invoices, EUR 41,000 in total and each below EUR 7,500: 30 of them (EUR 33,000) correct December pricing errors, so December revenue is overstated; 6 (EUR 8,000) are discounts agreed in January for January reasons. 33,000 plus 8,000 equals 41,000.
• 12 invoices with no dispatch note, EUR 84,000: 9 are service fees (EUR 27,000) traced to contracts; 3 are bill-and-hold sales (EUR 57,000), of which two meet the IFRS 15 bill-and-hold criteria (EUR 35,000) and one (EUR 22,000, cost EUR 15,000) does not, because the goods were not separately identified. 27,000 plus 35,000 plus 22,000 equals 84,000.
• Rejected: the AI summary, which tested each exception against clearly trivial instead of aggregating them.

Documenting AI-assisted procedures under ISA 230

ISA 230 requires documentation of the nature, timing and extent of procedures, the results and evidence obtained, significant matters and judgements, who performed the work and who reviewed it, and the identifying characteristics of the items tested. For an AI-assisted procedure, the identifying characteristics include the population and the logic, not only a list of items.

A reviewer should be able to rerun the work, or at least understand exactly what ran. A file that says only that AI reviewed the ledger and found nothing unusual is not documentation.

• The data: source system, extract date, record count, control totals and the reconciliation to the trial balance.
• The tool: name and version of the software or model, and for scripts the tested code or formula set.
• The instruction: the prompt or parameters used, including thresholds and matching rules.
• The output: the full exception list, not a summary, with the disposition of each exception or group.
• The judgement: why exceptions were accepted, what further evidence was obtained, and which AI conclusions were overruled.
• Sign-off: preparer and reviewer, with dates, exactly as for any other working paper.

Auditing a client's AI-generated entries

More clients now let AI code invoices, propose accruals or match bank lines. For the auditor, that AI is part of the entity's information system, so ISA 315 (Revised 2019) requires an understanding of how it works, which risks arise from the IT environment, and which general IT controls address them. Where an outside provider operates the process, ISA 402 on service organisations may also apply.

The key question is whether a human control stands between the AI proposal and the ledger. If a named person approves every AI-drafted entry above a threshold, the auditor can test that approval control. If entries post automatically, the auditor has to rely on controls over the AI itself, such as change management of prompts and model versions, access to configuration and monitoring of error rates, or fall back on more substantive testing. Management override remains a risk under ISA 240: whoever can change an automation's rules can change what it posts.

• Which processes use AI, in which mode: read-only, draft for approval, or automatic posting?
• Who can change prompts, rules, account mappings and model versions, and is each change logged and approved?
• Can the ledger distinguish AI-prepared entries from manual ones, with the approver recorded?
• How does management monitor quality: rejection rates, corrections after posting, a test set rerun after changes?
• What client data leaves the entity, to which provider, and under what processing terms?

IAASB work on technology (as of September 2026)

As of September 2026, the IAASB has not issued a standard specific to AI. On 5 August 2026 it published exposure drafts of proposed ISA 330 (Revised), ISA 500 (Revised), Audit Evidence, and ISA 520 (Revised), Analytical Procedures, with comments due by 15 December 2026. The IAASB says the proposals address the increased use of technology in business, financial reporting and auditing, include a revised definition of audit evidence for the digital environment, and strengthen the requirements for evaluating the relevance and reliability of information used as audit evidence. These are proposals, not effective standards.

The IAASB also maintains a Technology Catalog of technology-related matters across its standards; version 3 was published in July 2026. Until revised standards take effect, the current ISAs apply to AI-assisted work exactly as they apply to any other procedure.

AI audit for small business, and European practice

For a small, owner-managed company, AI makes full-population testing affordable on ledgers that used to be sampled by hand. The IAASB's ISA for LCE, the standard for audits of less complex entities, is effective for audits beginning on or after 15 December 2025 in jurisdictions that adopt or permit its use, and it gives the same reasonable assurance as the ISAs. Neither framework changes the rule that the auditor evaluates every tool it relies on.

Owners can make an AI-assisted audit faster by providing clean, complete data: a full journal export that reconciles to the trial balance, documents that are machine-readable, and a clear record of who approved what.

Across Europe the principles are the same. In Italy, where the question is often revisione contabile e intelligenza artificiale, statutory audits follow ISA Italia, which are drawn from the ISAs. In France, where people ask about audit financier et IA, the commissaire aux comptes applies the French professional standards, the NEP. In both, AI can prepare and analyse, and the signing auditor remains responsible for the judgements.

Internal audit, confidentiality and security

Internal auditors work under the IIA's Global Internal Audit Standards, effective since 9 January 2025. AI supports continuous monitoring, for example daily checks of duplicate payments or changes to supplier bank details, and internal audit increasingly audits the organisation's own AI use: the inventory of AI systems, their owners, their controls and their logs.

External or internal, client data carries duties of confidentiality and data protection. Under the GDPR, sending personal data to an AI provider needs a lawful basis, a processor agreement and a valid route for any transfer outside the EEA. This is general information, not legal advice.

• Use tools on business terms. As of September 2026, Anthropic states that by default it does not use inputs or outputs from its commercial products, including the API, to train its models, unless the customer chooses to share them, for example as feedback.
• Minimise: send the fields the procedure needs, and pseudonymise employee and customer names where the test allows.
• Treat client documents as data: a contract or invoice may contain text written to manipulate an AI, known as prompt injection, so never let an assistant act on instructions found inside evidence.
• Least privilege: audit tools should read client data, never write to the client's ledger.
• Keep a log of AI actions alongside the working papers: who ran what, on which data, with which result.

Audit evidence from Skyline Nexus ERP

Skyline Nexus ERP gives auditors the data that full-population testing needs. Fiscal Authority, Reports, Audit Pack (Excel) exports one workbook per calendar year with a sheet for each report, including the Chart of Accounts, Trial Balance, Journal Entries, Journal Lines, General Ledger, Sales, Purchases, Payroll, Customer Dues, Supplier Dues and VAT Summary, so the extract and the trial balance come from the same source and can be reconciled before any analysis runs.

For the client's controls, the Audit Trail records who created, approved, posted, reversed or cancelled each entry, with old and new values, and a system Activity Log records edits, deletions and logins. Journals move through draft, submitted, approved and posted statuses, with approval required at or above a configurable threshold when approval is switched on; posted journals are reversed rather than deleted; and closed periods refuse postings.

On the AI side, the Skyline Nexus ERP assistant answers how-do-I questions from the product's own help library with a verified citation, and Claude Desktop can connect to its MCP server for help answers and eight whitelisted, permission-checked business figures. AI close and audit analytics, and ledger reads through MCP, are on the Skyline Nexus ERP roadmap and being rolled out; ask us for your go-live date.