Traditional internal audit tests samples because testing everything was impractical. With transaction data available and analytical tooling in place, that constraint has largely gone for many controls.

AI does not find anything a human could not find in principle. What changes is the volume it can examine, and that changes what assurance means. This sits within a broader internal audit approach.

Full-population testing

The tests check every payment against approval limits and segregation rules. They check every journal entry for unusual patterns such as round numbers or posting outside business hours, every vendor against employee bank details and addresses, and every expense claim against policy. They run across the entire period and repeat regularly instead of once a year.

Anomaly detection versus rules

Rules find what you thought to look for. Anomaly detection surfaces patterns nobody specified, such as a supplier whose invoice values cluster just below an approval threshold or a user whose posting behavior changed after a role change. Both are needed: rules for known control requirements and anomaly detection for what the control framework did not anticipate.

Continuous monitoring

The greater shift is timing. When analytics run on a regular schedule, an issue surfaces while it is still small and while the people involved remember the context. Internal audit moves from finding out what went wrong last year to flagging what is going wrong now.

A hypothetical example

Consider a Riyadh group whose internal audit tests a sample of payments each year and reports no issues. Analysis of all payments could show patterns a sample would miss. Examples are payments to bank accounts that match employee records, a duplicate-payment pattern to one supplier, or purchase orders split just below the approval threshold.

Governance and human judgment

Analytics generate exceptions, not conclusions. Every flagged item needs human assessment, because most anomalies have a legitimate explanation and treating a flag as a finding damages credibility quickly. Documenting how exceptions are triaged, and by whom, is part of AI governance and of the control framework the audit function operates within.

Reporting findings usefully

Full-population testing produces far more exceptions than sampling, and showing them all overwhelms an audit committee. We triage by financial value and control significance, report the pattern instead of every instance, and separate control failures from data quality issues. That keeps analytics credible with the board. Recurring patterns also feed risk assessment, because they usually show where control design itself needs attention.

Building the test library in phases

A set of analytical tests is not built in one step. We start with a small number of high-value tests on payments and journal entries and run them long enough to tune the false-positive rate. Then we add more. A large library that produces mostly false alerts is worse than a few reliable tests, because the team stops reviewing results it knows are mostly noise.

Coordinating with the external auditor

The external auditor may be able to rely on your analytical work if it is documented and performed to standards they accept, which can narrow the scope of their testing. We discuss this with your auditor early to learn what they will accept. Building analytics without that conversation often means running the same tests twice.