AI for Audit and Assurance Capstone Exercise — AI for Audit and Assurance

What you'll learn

Design a complete AI-assisted testing approach for a financial statement area and defend it in standards terms
Produce the four documents a reviewer and an inspector would ask for, rather than only the exception report
Apply the population, precision, scepticism, and documentation disciplines from across the course to a single realistic engagement

Across this course you have separated the three roles AI plays in an audit, tied procedures to assertions, tested the precision of an expectation against performance materiality, weighed full-population coverage against depth, built journal entry criteria from entity-specific fraud risks, met the ISA 500 and ISA 230 evidence and documentation standards, audited a client's own model, drawn the line between monitoring and auditing, designed against automation bias, and worked through the ISQM 1 and independence framework around all of it.

This capstone puts them together. The scenario is deliberately one where the AI-assisted approach is genuinely the right choice and where doing it carelessly would produce a file that looks strong and is not.

Capstone Exercise

Designing and Defending a Full-Population Revenue Testing Approach

Context

You are the audit manager on the statutory audit of a distribution business with revenue of £84 million and approximately 310,000 revenue transactions in the period. Performance materiality is £1.9 million. Two facts shape the engagement. First, the client migrated from a legacy billing system to a new ERP eleven weeks before year end; both systems were live during a two-week parallel run, and finance confirms some transactions exist in both. Second, a fraud risk has been identified around period-end revenue recognition, because the senior management bonus is based on revenue growth and the prior year outturn narrowly missed the threshold. The client has also enabled a new revenue-forecasting feature in the ERP that finance uses to estimate a rebate accrual of £1.2 million presented net against revenue; nobody in finance can explain how the estimate is produced beyond saying that the system calculates it. Your firm's analytics platform is approved for full-population testing and for directing attention, but firm methodology states it may not be the sole basis for substantive assurance without documented seeded-error testing on the engagement.

Your Task

Produce four deliverables. First, a population and completeness memorandum: set out how you would establish a complete revenue population across two systems and a parallel-run period, what reconciliations you would perform and to what, how you would identify and treat duplicated transactions from the parallel run, and what you would do if the reconciliation did not agree. Second, a testing design: specify which assertions you will address by full-population routine and which by judgment-based selection, state for each routine what attributes it tests and — explicitly — which relevant attributes it cannot test, derive your investigation threshold from performance materiality showing the calculation, and set out the seeded-error testing you will perform to satisfy firm methodology. Third, an ISA 240 journal entry selection: build the selection criteria for this engagement, mapping each criterion to the identified period-end revenue recognition fraud risk rather than to a generic list, and state how you will corroborate the cause of any group of exceptions you exclude from individual investigation. Fourth, a rebate accrual approach: set out how you would audit the £1.2 million system-generated estimate under ISA 540, including what you would ask the client to establish about the model, what you would do given that finance cannot explain it, and at what point you would conclude that sufficient appropriate evidence is not available.

Your notes (optional)

Deliverable

Four written deliverables: (1) a population and completeness memorandum covering both systems, the parallel run, duplicate identification, the reconciliations to be performed, and the response to an unexplained difference; (2) a testing design specifying assertions covered by routine versus judgment-based selection, the attributes each routine cannot test, the threshold derivation from performance materiality with the calculation shown, and the seeded-error testing plan; (3) an ISA 240 journal entry selection mapping each criterion to the identified period-end revenue fraud risk, with the corroboration standard for any excluded exception group; (4) a rebate accrual approach under ISA 540 covering method, assumptions and data, the treatment of finance's inability to explain the model, back-testing against realised outcomes, and the point at which you would conclude that sufficient appropriate evidence is unavailable.

Quick check

The client in this capstone ran two billing systems in parallel for two weeks before year end. What does the capstone say that does to the population problem, set against the migration gap in lesson one?

Select one answer.

Key takeaways

The population question comes first and is the one most often skipped. A parallel run between two billing systems produces duplication rather than omission, and a full-population test over a population you have not reconciled provides less assurance than a sample over one you have.
A defensible testing design states what its routines cannot test as clearly as what they can, and names the procedure covering the assertions left uncovered. Coverage and appropriateness are independent properties.
Thresholds derive from performance materiality with the arithmetic shown, never from a platform default. Seeded-error testing is what converts trust in a routine from an assumption into evidence, which is why firm methodology requires it before substantive reliance.
ISA 240 criteria must map to the fraud risk actually identified for this entity. A period-end revenue risk driven by a bonus threshold calls for criteria aimed at manual revenue entries in the closing window and early-period reversals, not a generic checklist run unchanged from last year.
When a client cannot explain how a system-generated estimate is produced, that inability is the first finding and it concerns both the estimate and the control environment. Concluding that sufficient appropriate evidence is unavailable is a legitimate professional outcome, and a more defensible one than accepting a plausible figure you cannot corroborate.