Audit anomaly review

• Every journal line in the period is extracted with standard, versioned scripts, and reconciled to the trial balance and the balance roll-forward before any test runs. A failed reconciliation stops the analysis and goes back to the team.
• The firm's standard journal tests still run as plain rules, exactly as the methodology defines them. The machine learning adds to them; it never replaces them.
• Every entry is scored for how unusual it is for this client, compared with its own history and patterns: who posted it, when, to which account pairs, with what amount and description.
• Similar unusual entries are grouped into clusters, so the team reviews 40 explained groups instead of 3,000 separate hits, and each flag shows the specific features that made it stand out.
• An assistant gathers the supporting data for the entries the team chooses and drafts the working paper narrative. The team investigates, edits and concludes, and the reviewer and engagement partner sign off.
• The audit file gets a standard record of the tool: what it does, which version ran, on which data, with which settings, and what the team did with the results.

• FRCISA (UK) 240: the auditor's responsibilities relating to fraud
  →

  The team must respond to the risk of management override, including by testing journal entries. The tool helps the team see the whole population and choose what to test; the team still designs the procedures, sets the criteria with the methodology, and evaluates the results. ISA (UK) 240 (Revised March 2026) applies to audits of periods beginning on or after 15 December 2026.

• FRCISA (UK) 315 (Revised July 2020) and ISA (UK) 330: risk assessment and responses
  →

  The team must understand the client's IT environment, including how journals are posted and approved. Patterns the tool finds, such as an unusual posting user or an account pair never seen before, are inputs to the team's risk assessment, not the risk assessment itself.

• FRCISA (UK) 500 audit evidence and ISA (UK) 230 documentation
  →

  The ledger is information produced by the client, so the team must evaluate whether it is complete and accurate enough to rely on. Every extract is reconciled before use, and the file records what was run, on which data, with which version and settings, and what the team concluded, so an experienced auditor with no connection to the audit could follow it.

• FRCISQM (UK) 1, AI in audit guidance (26 June 2025), and Generative and Agentic AI Guidance (30 March 2026)
  →

  The firm certifies the tool centrally before engagement teams use it, under its system of quality management. The June 2025 guidance, whose illustrative example is an AI tool used over journals, sets out proportionate documentation centrally and on the audit file. The March 2026 guidance covers generative and agentic tools such as the drafting assistant. Neither creates new requirements, and the human auditor stays accountable.

• FRC and ICAEWFRC Ethical Standard (Revised 2024) and the ICAEW Code of Ethics
  →

  The analysis is audit work. Findings go to the client through the normal reporting channels, and the tool is never turned into a monitoring service the client relies on, or used to make management decisions, which would threaten independence. Each client's data stays confidential to its engagement: models learn from that client's own history, and one client's ledger is never used to produce another client's results.

• ICOUK GDPR and the Data Protection Act 2018
  →

  Ledgers contain personal data: employee names and user IDs, payroll and expense journals, and individuals paid as suppliers. That means a DPIA, minimising fields such as payroll narratives, processing in UK regions, a retention period aligned with the firm's audit file retention, and a contract that stops providers training their models on client data.

• Home OfficeFailure to prevent fraud (Economic Crime and Corporate Transparency Act 2023), in force since 1 September 2025
  →

  Large organisations can now be criminally liable when an employee or associate commits a listed fraud offence, such as false accounting, intended to benefit them, unless they had reasonable prevention procedures. Clients' boards are paying more attention to journal controls. The auditor's analysis is not part of the client's prevention procedures and should never be described as if it were.

On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →

• The central audit technology team certifies the tool before any engagement uses it, re-certifies on every material change, and keeps the central documentation the FRC's guidance describes.
• A named owner for each extract script, test, model and prompt, with change control like any other audit methodology change.
• Engagement teams trained before use, including what the tool can't see: top-side and consolidation adjustments made outside the ledger, entries in sub-ledgers, and fraud that looks normal.
• A clear route to forensic specialists when a cluster suggests something the team shouldn't investigate alone.
• An ethics check before any output is shared with a client, so findings go through normal reporting and never become a service the client relies on.
• The quality team reviews a sample of engagements each cycle, comparing what the tool flagged, what the team tested, and what they concluded.

1. 3–4 weeks

   Discovery

   Map today's journal testing and data extraction, list the client ERPs by volume, agree the certification route with methodology, and confirm what client engagement terms allow.

2. Gate · must be true to passBaseline measured, top ERP families chosen, DPIA and ethics review started, certification criteria agreed.

3. 10–12 weeks

   Pilot

   Re-run 10–15 completed audits from last cycle, then a few live audits in parallel with the standard approach. Compare what the tool flagged with what the teams tested and found.

4. Gate · must be true to passExtract checks match or beat today's, flags explainable to the teams, central documentation complete, methodology sign-off.

5. 4–6 weeks

   Production

   Certified for engagements on the pilot ERP families, with support, training and a rollback to the standard approach.

6. Gate · must be true to passCertification recorded, support model and training in place, audit file template updated.

7. Ongoing

   Scale

   Add ERP families one at a time, then reuse the platform for revenue, payroll and expense analytics.

8. Gate · must be true to passEach new ERP family and each new analytic passes the same certification gate.

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

1. 1

   Goes wrong

   The extract was incomplete, and nobody noticed until the file was reviewed.

   How the design avoids it

   Every extract has a manifest and is reconciled to the trial balance and rolled forward before any test runs. A failure stops the analysis.

2. 2

   Goes wrong

   The model is a black box, so the team can't say why an entry was flagged or why others weren't.

   How the design avoids it

   Reasons on every flag, the standard rules still run in full, and central documentation that explains how the model works and how it was tested.

3. 3

   Goes wrong

   Teams treat a low score as evidence an entry is fine.

   How the design avoids it

   Training and methodology say plainly that a low score proves nothing. Selection and conclusions are the team's, recorded on the file.

4. 4

   Goes wrong

   One client's data leaks into another client's results, or into a provider's model.

   How the design avoids it

   A separate store and key per engagement, models trained on that client's own history, and contracts that stop providers training on the data.

5. 5

   Goes wrong

   The tool is built first and certified afterwards, so the first busy season runs without it.

   How the design avoids it

   Certification criteria agreed with methodology at discovery, and documentation built alongside the tool.

1. 15 December 2026
   ISA (UK) 240 (Revised March 2026) and ISA (UK) 570 (Revised March 2026) apply to audits of periods beginning on or after this date, with enhanced fraud risk assessment and more transparency in auditor's reports, mainly for publicly traded entities.

   Map the tool's outputs to the revised requirements and update the methodology and audit file template before the first affected audits are planned.

2. 2027 annual reports
   Provision 29 of the UK Corporate Governance Code 2024 applies to periods beginning on or after 1 January 2026: boards of companies that report against the Code declare whether their material controls were effective. No auditor attestation is required.

   Expect audit committees to ask how journal controls look from the audit side. Keep the analysis as audit evidence, and agree with ethics what can be shared through normal reporting.

3. No date set
   The government said in January 2026 that it would not take forward the Audit Reform and Corporate Governance Bill, so the FRC will not be replaced by ARGA for now. It still plans to put the FRC on a statutory footing when parliamentary time allows.

   Design to the FRC's current standards and AI guidance, and keep the tool documentation complete enough to satisfy whichever body regulates audit next.

4. 2028
   The NCSC asks organisations to have a full post-quantum cryptography migration plan by 2028.

   Audit files and client ledgers are kept for years. Record which encryption the platform uses for stored extracts and transfers, and keep it easy to change.