AI in Internal Audit: Continuous Monitoring and Full-Population Testing

By Jane Ha · Updated Oct 11, 2026

AI in internal audit is the use of machine learning, analytics and language models to test controls and transactions continuously and across the whole population, instead of reviewing a small sample once a year, while auditors keep responsibility for scoping, judgment and conclusions. The shift is simple to state. Traditional audit asks, "Of the 60 invoices we pulled, how many broke the rule?" AI-assisted audit asks, "Of all 400,000 invoices, which ones broke the rule, and which look odd even though they passed?"

This guide is for chief audit executives, audit managers, CFOs and controllers who want to know what continuous monitoring and full-population testing actually involve, where AI helps, and where it doesn't. It sits in the AI for Finance collection. For the wider picture, start with AI in finance and accounting. For the control environment audit tests against, read AI and internal controls.

Key Facts

• The IIA's Global Internal Audit Standards are organized into five domains and 15 principles (The IIA), and they became effective on January 9, 2025 (The IIA press release, January 2025).
• The IIA issued the third edition of its Global Technology Audit Guide on continuous auditing and monitoring on September 25, 2025, replacing the 2015 edition (The IIA).
• In the 2025 North American Pulse of Internal Audit, 41% of teams reported using generative AI in internal audit, but only 6% used it often or extensively in fieldwork and 13% in planning (AuditBoard summary of The IIA Foundation report).
• In that same survey, data analysis was the skill chief audit executives most wanted to improve, chosen by 78% of respondents (AuditBoard summary).
• Audit sampling is formally defined as applying audit procedures to less than 100% of items in a population, and sampling risk is the risk that a conclusion from a sample differs from the conclusion the full population would give (FRC, ISA (UK and Ireland) 530).
• The IIA's Artificial Intelligence Auditing Framework, updated September 13, 2024, covers AI governance, management and the internal audit function itself, including generative AI (The IIA).

What Continuous Monitoring and Full-Population Testing Mean

The two ideas are related but not identical.

Full-population testing means running a test against every record in a data set (all journal entries, all payments, all expense claims) rather than a selected sample. A sample gives you an estimate with a confidence level. A full-population test gives you a list of every exception. Sampling is a tool for when you can't look at everything. Once data is in a warehouse and a test is a query, you often can.

Continuous monitoring means the tests run on a schedule (daily, weekly) rather than once per audit cycle. Strictly, the IIA's guidance separates two roles. Continuous auditing is what internal audit does to give ongoing assurance. Continuous monitoring is what management does to watch its own controls. In practice they share tooling, and good programs coordinate them so the two lines don't build the same test twice.

Where does AI fit? Rules-based analytics can already test full populations: "flag any payment above the approval limit." AI adds three things rules struggle with:

1. Pattern detection without a written rule. Anomaly models score each transaction against what's normal for that vendor, user or account, so they surface the odd item nobody thought to write a rule for.
2. Reading unstructured text. Language models can read contracts, emails, expense descriptions and policy documents and compare them to what the ledger says.
3. Prioritization. With a full population, you might get 3,000 exceptions. A model can rank them so auditors start with the ones most likely to be real.

Sampling vs Full-Population Testing

The table shows why the change isn't just "more testing." The auditor's work moves from pulling items to deciding which exceptions matter and why. Sampling risk, as the FRC's ISA 530 text defines it, is the chance that a sample-based conclusion differs from what testing everything would have shown. Full-population tests remove that specific risk. They add others, covered below.

Where AI Helps, by Audit Area

The examples below are illustrative, not drawn from a specific organization.

Accounts payable and procurement. A rules test checks for duplicate invoice numbers. A model also catches near-duplicates: the same amount and vendor with a transposed digit, or a split purchase just under an approval limit. A language model can compare invoice descriptions to the purchase order. See AI in accounts payable for how the process itself is automated, which changes what audit has to test.

Journal entries and the close. Auditors have long tested manual journal entries for risk markers: posted at odd hours, round amounts, unusual account pairings, entries by users who rarely post. A model scores every entry against those patterns and the preparer's history. The month-end close is where most manual adjustments cluster, so it's a natural place to focus.

Expenses and card spend. Instead of sampling 40 claims, test every claim for policy breaks, duplicate receipts, weekend spending and merchant mismatches. AI expense management covers the detection methods in more detail.

Access and segregation of duties. Compare user-role assignments across ERP and banking systems and flag people who can both create a vendor and approve a payment. This is a data-matching problem, and it runs well on a daily schedule.

Revenue and receivables. Test every invoice against contract terms and shipment records, and flag credit notes issued shortly after quarter end. A document-review model can read contract clauses and compare them to the billing set-up.

Fraud indicators. Models can rank vendors, employees or transactions by fraud risk for investigation. Treat the output as a lead, not a finding. The companion guide, AI fraud detection in finance, covers the methods and their error rates.

Audit administration. Language models can summarize prior-year workpapers, draft test steps from a control description, and turn interview notes into a first-draft finding. The IIA Foundation's Pulse data shows this is the early pattern: use is spread thin across planning, fieldwork and reporting, and few teams use it heavily in any one stage.

What Continuous Monitoring Looks Like in Practice

A working setup has a few moving parts, and none of them are exotic.

• A data layer. Extracts from the ERP, payment systems, HR and access logs land in a controlled store on a schedule. Auditors have read-only access.
• A test library. Each test has an ID, a control it relates to, a logic description, an owner, and a threshold. Some tests are rules. Some are models.
• An exception queue. Results go to one place with a status (new, under review, confirmed, dismissed) and a reason code for each decision.
• A routing rule. Low-risk exceptions go to the control owner in the first line to explain. High-risk ones go to audit.
• A dashboard for the audit committee. Trends in exceptions by process and entity, time to resolve, and repeat issues.

The routing rule is where programs succeed or fail. If management owns the monitoring and audit tests that monitoring, you get coordination without duplication. If audit runs everything itself, it risks becoming part of the control environment it's supposed to assess independently.

How to Implement It, Step by Step

1. Pick the first process by risk and data readiness. Choose one with a clean, centralized data source and a clear control. Payments, journal entries and expenses are common starters. Finance data readiness for AI lists what to check.
2. Start with rules, add models where rules fall short. Rebuild your current sample-based tests as full-population queries first. That alone often changes what you see. Add anomaly scoring where there's a clear gap.
3. Define what counts as an exception before you run it. Write the control objective, the test logic and the threshold. Without that, you can't explain a result to the process owner.
4. Baseline against the old method. Run the full-population test on a period you already sampled. Compare what each approach found.
5. Measure false positives and tune. If 90% of flags are dismissed, reviewers will stop looking. Adjust thresholds with the people reviewing the queue.
6. Agree roles with management. Decide which tests management owns as monitoring, which audit owns as assurance, and how exceptions are routed. Document it.
7. Set model governance. Record each model's purpose, inputs, owner, test results and change history. The IIA's AI Auditing Framework is a useful checklist for how to assess AI-enabled processes, and the same discipline applies to your own models.
8. Validate conclusions manually. Every reported finding should trace to source records an auditor has looked at, not to a model score alone.
9. Report differently. Move from "we tested 40 items and found 2 exceptions" to "we tested all 212,000 items, found 340 exceptions, and 19 were confirmed errors."
10. Review the program each quarter. Check coverage, false-positive rates, data feed breaks and whether the tests still match the controls.

Limits and Pitfalls

Full-population testing sounds like certainty. It isn't.

• A complete data set isn't the same as complete assurance. You tested every record in the extract. If the extract missed a system, an entity or a manual process, the population wasn't whole. Reconcile record counts and totals to the ledger before you trust the test.
• Controls that aren't in the data. Management review, approvals by email and physical checks leave little structured trace. Analytics can't test what isn't recorded.
• False positives. Thousands of exceptions can bury the real ones. A ranked queue helps, but only if the ranking is tuned and reviewed.
• Black-box output. If a model flags an entry and nobody can say why, you can't support a finding with it. Prefer methods where the reason is visible, or add an explanation layer and verify against source documents.
• Language model errors. Writing that sounds right can still be wrong. An IIA-published practitioner account of a year of AI use in audit warns about polished output that hides errors and recommends reviewing it as you would a junior colleague's draft (Internal Auditor, December 2025). Treat model-drafted findings and summaries as drafts.
• Independence. If audit builds and runs the monitoring that management should own, it takes on a management role. Keep the line clear.
• Data privacy and security. Payroll, vendor and customer data feeding a model or an external tool needs the same access controls and approvals as any other sensitive system.
• Drift. Business changes (a new ERP module, a new vendor onboarding flow) shift what normal looks like. A model trained before the change will mislabel afterward.
• Skills gaps. Pulse respondents named data analysis as the skill they most wanted to improve. A tool without people who can interpret and challenge it produces reports nobody acts on.
• Overreach in claims. "We tested everything" is only true for the population and the test you actually ran. Say what was covered.

What to Measure

• Coverage: share of in-scope transactions tested, and share of key controls with an automated test.
• Exception quality: exceptions raised, confirmed, dismissed, and the false-positive rate by test.
• Speed: time from the event to the flag, and from the flag to resolution.
• Repeat issues: the same control failing in the same unit, which signals a root cause rather than a one-off.
• Effort shift: auditor hours moved from sample selection and retesting to investigation.
• Data health: feed failures, missing records and reconciliation breaks.

Where to Go Next

If you do one thing this quarter, pick one process, rebuild its sample test as a full-population query, and compare what it finds with last year's sample. Then read AI and internal controls for the control design side, AI fraud detection in finance for investigation methods, and AI in finance for the governance picture across the function.