Analytics in audit: risk assessment, testing and anomaly detection

Auditing is where data analytics has changed accounting practice most visibly. For most of the twentieth century, auditors could examine only a small sample of transactions, because each one had to be pulled and checked by hand. Today an auditor can obtain a complete copy of a client's general ledger and subledgers and test every transaction against a rule in minutes. This lesson explains how analytics fits into an audit under the standards, then works through four techniques: substantive analytical procedures built on a driver model, full-population tests of payments, Benford's law, and journal entry testing. It closes with the practical and professional issues of using client data and handling large numbers of exceptions. The same techniques serve internal auditors and fraud examiners, and many apply to tax compliance reviews.

Audit data analytics

The AICPA's Guide to Audit Data Analytics, published in 2017, describes audit data analytics as the science and art of discovering and analyzing patterns, identifying anomalies and extracting other useful information from data underlying or related to the subject matter of an audit, through analysis, modeling and visualization, for the purpose of planning or performing the audit. The definition is broad on purpose: analytics can support almost every phase of an audit.

US auditing standards increasingly address analytics directly. For audits of public companies, the PCAOB adopted amendments to AS 1105, Audit Evidence, and AS 2301, The Auditor's Responses to the Risks of Material Misstatement, in June 2024, approved by the SEC in August 2024 and effective for audits of financial statements for fiscal years beginning on or after December 15, 2025. The amendments address technology-assisted analysis: they specify the auditor's responsibilities when evaluating the reliability of information in electronic form, including information the company receives from external sources, and when investigating items identified by such analysis, and they clarify that a procedure may serve more than one purpose. AS 2305 governs substantive analytical procedures and AS 2401 requires journal entry testing. For other entities, the AICPA's SAS 142, Audit Evidence, effective for periods ending on or after December 15, 2022, explicitly considers audit data analytics and information in electronic form, and SAS 145, effective for periods ending on or after December 15, 2023, updated risk assessment, including the auditor's understanding of IT.

Reliable data first

Every audit analytic rests on the data. Before using client data, the auditor must obtain evidence that it is complete and accurate, as lesson 2 described: reconciling the extract to the general ledger and trial balance, understanding how it was produced, and testing the IT general controls over the system that produced it, or otherwise testing the data directly. Auditors prefer to obtain data directly from the system, or to observe the extraction, rather than accept a file prepared by client staff. A beautiful analysis of incomplete data gives false assurance, which is worse than no analysis at all.

Substantive analytical procedures

A substantive analytical procedure compares a recorded amount with the auditor's expectation of what it should be. To provide substantive evidence, the procedure must be designed carefully. The auditor develops an expectation precise enough to detect a misstatement that could be material, usually from independent or tested data and plausible relationships; sets a threshold for the difference that can be accepted without further investigation, before seeing the result; compares the expectation with the recorded amount; and investigates differences above the threshold by obtaining corroborating evidence, not merely management's explanation.

Halden Rowe, Cedarbrook's auditor, uses the driver model from lesson 10 to test December 2025 freight expense. This time the model is fitted on January 2024 to November 2025 only, so that the month under test does not influence its own expectation. The audit senior sets the threshold at 12 thousand, based on performance materiality for the account, before running the comparison.

# A substantive analytical procedure for December 2025 freight
import numpy as np
shipments = np.array([3120, 2980, 3410, 3890, 4420, 4710, 4650, 4580, 4300,
                      3950, 3380, 3050, 3200, 3090, 3520, 4010, 4560, 4840,
                      4790, 4700, 4410, 4060, 3460, 3140])
fuel = np.array([100, 101, 103, 104, 106, 108, 107, 105, 104, 102, 101, 100,
                 99, 100, 102, 105, 107, 109, 110, 108, 106, 104, 103, 102])
freight = np.array([181, 175, 199, 228, 262, 282, 277, 270, 252, 230, 197,
                    178, 185, 179, 205, 236, 270, 291, 290, 283, 264, 241,
                    203, 213])                       # $ thousands, recorded
X = np.column_stack([np.ones(24), shipments, fuel])
coef, *_ = np.linalg.lstsq(X[:23], freight[:23], rcond=None)  # fit Jan24-Nov25
expected = X[23] @ coef
threshold = 12.0                 # set by the auditor before seeing the result
diff = freight[23] - expected
print(f"expected December freight {expected:.1f}, recorded {freight[23]}")
print(f"difference {diff:+.1f} against a threshold of {threshold}")
print("investigate the difference" if abs(diff) > threshold
      else "no further work: within threshold")

expected December freight 184.3, recorded 213
difference +28.7 against a threshold of 12.0
investigate the difference

Fitted without December's own data, the model expects December freight of about 184 thousand, so the recorded 213 thousand exceeds the expectation by about 29 thousand, well above the threshold. Note that the difference is larger than the residual of 23 thousand found in lesson 10, because the outlier is no longer pulling the fitted line toward itself. The auditor must now investigate: obtain the December freight invoices and accruals, compare them with carrier statements and shipping records, and determine whether the difference reflects a misstatement. Management's explanation alone is not enough; it must be corroborated.

Full-population tests

Analytics lets the auditor test every item in a population against a rule. Common examples include matching every purchase invoice to a purchase order and receiving record, testing every sales invoice around year end for cut-off, recalculating every depreciation charge, and checking every payment for proper approval. The program below runs two tests across Cedarbrook's June 2025 payments: payments that may have been split to stay under the 5,000 approval limit, and payments made shortly after a vendor's bank details were changed, a common sign of payment diversion fraud.

# Full-population tests on payments: split invoices and bank detail changes
import pandas as pd
pay = pd.DataFrame({
    "pay_id":  range(1, 11),
    "vendor":  ["V0417", "V0982", "V1312", "V1312", "V1312", "V0640",
                "V0640", "V2208", "V1133", "V2208"],
    "date":    pd.to_datetime(["2025-06-02", "2025-06-02", "2025-06-03",
                "2025-06-03", "2025-06-03", "2025-06-05", "2025-06-12",
                "2025-06-16", "2025-06-16", "2025-06-30"]),
    "amount":  [1250.00, 8200.00, 4900.00, 4750.00, 4980.00, 2300.00,
                2310.00, 3400.00, 6120.00, 9800.00],
    "approved_by": ["jli", "dreyes", "tpatel", "tpatel", "tpatel", "jli",
                    "jli", "tpatel", "dreyes", "tpatel"],
})
limit = 5000                    # payments of 5,000 or more need the controller
same_day = pay.groupby(["vendor", "date"]).agg(
    n=("pay_id", "size"), total=("amount", "sum"), largest=("amount", "max"))
split = same_day[(same_day["n"] > 1) & (same_day["largest"] < limit)
                 & (same_day["total"] >= limit)]
print("possible split payments:")
print(split.to_string())
changes = pd.DataFrame({"vendor": ["V2208", "V0640"],
    "changed_on": pd.to_datetime(["2025-06-13", "2025-01-20"]),
    "changed_by": ["tpatel", "mokafor"]})
m = pay.merge(changes, on="vendor")
recent = m[(m["date"] >= m["changed_on"])
           & (m["date"] - m["changed_on"] <= pd.Timedelta(days=30))]
print("payments within 30 days after a bank detail change:")
print(recent[["pay_id", "vendor", "date", "amount", "changed_by",
              "approved_by"]].to_string(index=False))

possible split payments:
                   n    total  largest
vendor date                           
V1312  2025-06-03  3  14630.0   4980.0
payments within 30 days after a bank detail change:
 pay_id vendor       date  amount changed_by approved_by
      8  V2208 2025-06-16  3400.0     tpatel      tpatel
     10  V2208 2025-06-30  9800.0     tpatel      tpatel

The first test finds three payments to vendor V1312 on the same day, each just under the 5,000 limit, totaling 14,630, all approved by the same person. That pattern is consistent with splitting a payment to avoid the controller's approval. The second test finds two payments to V2208 shortly after its bank details were changed, and the change, the approval of both payments and the processing were all done by the same user. Payment 10, for 9,800, also exceeds the approval limit without the controller's approval, which is a control failure in its own right. None of this proves wrongdoing: there may be legitimate explanations, and an analyst should be careful not to treat a user name as a suspect. But together these are exactly the patterns that call for prompt follow-up with supporting documents, and, given the overlap with the manual entry patterns in lesson 6, a discussion with those charged with governance about whether a broader investigation is needed.

Testing the whole population changes the nature of the evidence but does not remove the need for judgment. There is no sampling risk, because nothing was left untested against the rule, but the test is only as good as the rule and the data. A three-way match on every invoice confirms that documents agree with each other; it does not confirm that the goods were needed or that prices were fair. And full-population tests often produce many exceptions, which brings us to their treatment below.

Benford's law

In many naturally occurring sets of numbers, the leading digit is far more often 1 than 9. Benford's law predicts that the proportion of numbers with first digit d is log10(1 + 1/d), about 30.1 percent for 1, 17.6 percent for 2, and falling to 4.6 percent for 9. The pattern appears in data that span several orders of magnitude and arise from combining or multiplying quantities, which describes many accounting populations such as invoice amounts and payments. ACCT-240 introduced the idea; here we add a measure of conformity.

Mark Nigrini, who popularized Benford's law in auditing, proposed the mean absolute deviation (MAD) between observed and expected proportions as a measure of conformity, with suggested thresholds for the first-digit test of up to 0.006 for close conformity, 0.006 to 0.012 for acceptable conformity, 0.012 to 0.015 for marginally acceptable conformity, and above 0.015 for nonconformity. The program applies the test to simulated vendor invoices, first as genuine data, then with 600 invoices added just under a 5,000 approval limit.

# First-digit Benford test on vendor invoices, with a conformity measure
import numpy as np
rng = np.random.default_rng(2025)
genuine = np.round(rng.lognormal(7.0, 1.3, 9_400), 2)
just_under = np.round(rng.uniform(4_500, 4_999.99, 600), 2)  # below a 5,000 limit
for label, amounts in [("genuine invoices only", genuine),
                       ("with 600 invoices just under 5,000",
                        np.concatenate([genuine, just_under]))]:
    first = np.array([int(f"{a:e}"[0]) for a in amounts])
    observed = np.array([(first == d).mean() for d in range(1, 10)])
    expected = np.log10(1 + 1 / np.arange(1, 10))
    mad = np.abs(observed - expected).mean()
    verdict = ("close conformity" if mad <= 0.006 else "acceptable" if mad <= 0.012
               else "marginal" if mad <= 0.015 else "nonconformity")
    print(f"{label}: MAD {mad:.4f} ({verdict})")
    print("  digit    " + "".join(f"{d:>6}" for d in range(1, 10)))
    print("  expected " + "".join(f"{e:>6.3f}" for e in expected))
    print("  observed " + "".join(f"{o:>6.3f}" for o in observed))

genuine invoices only: MAD 0.0021 (close conformity)
  digit         1     2     3     4     5     6     7     8     9
  expected  0.301 0.176 0.125 0.097 0.079 0.067 0.058 0.051 0.046
  observed  0.302 0.177 0.123 0.104 0.077 0.065 0.058 0.052 0.043
with 600 invoices just under 5,000: MAD 0.0136 (marginal)
  digit         1     2     3     4     5     6     7     8     9
  expected  0.301 0.176 0.125 0.097 0.079 0.067 0.058 0.051 0.046
  observed  0.284 0.166 0.115 0.158 0.072 0.061 0.054 0.049 0.040

The genuine invoices conform closely, with a MAD of 0.0021. Adding the 600 invoices just under 5,000 raises the share of amounts starting with 4 from about 10 to 16 percent and pushes the MAD to 0.0136, marginal conformity. The digit-level detail is more informative than the overall verdict: the spike at 4 points directly to amounts just below the 5,000 limit, which can then be examined with the split-payment test above.

Benford analysis is a screening tool, not proof. Many legitimate populations do not follow Benford's law: amounts with a built-in minimum or maximum, prices set at psychological points such as 99, populations of similar-sized items such as monthly rent, and assigned numbers such as invoice numbers. It works best on large populations of transaction amounts that span several orders of magnitude, and its results direct attention to particular digits or digit combinations for follow-up.

Journal entry testing

AS 2401 for public company audits, and AU-C 240 for others, require the auditor to design procedures to test the appropriateness of journal entries recorded in the general ledger and other adjustments made in preparing the financial statements, because management is in a unique position to commit fraud by overriding controls. The auditor makes inquiries about inappropriate or unusual activity, selects entries made at the end of the reporting period, and considers the need to test entries throughout the period. Analytics makes this practical: the auditor obtains the complete journal entry population, reconciles it to the trial balance, and uses exception queries like those in lesson 6 to select entries with fraud risk characteristics.

The characteristics auditors look for are those in lesson 6: entries to unrelated, unusual or seldom-used accounts; entries by individuals who do not normally make entries; entries recorded at period end or after the close with little or no explanation; entries made before or during preparation of the financial statements without account numbers; round numbers or consistent ending digits; and entries affecting accounts with complex estimates. The auditor tests selected entries by examining support and confirming that they were properly authorized and recorded.

Handling exceptions

Full-population tests and exception queries often produce more exceptions than an auditor can examine one by one. Simply sampling from the exceptions is generally not appropriate, because each exception is an item that failed a test designed to find misstatements. Guidance in this area recommends a structured approach. First, refine the test if exceptions reveal that the rule was too broad, documenting the reason. Second, group exceptions with similar characteristics, investigate the cause of each group, and decide whether the group represents misstatements, control deficiencies or false positives. Third, evaluate any misstatements found, project them where appropriate, and consider their effect on the risk assessment and the rest of the audit.

Practical and professional issues

Several issues recur in practice. Data access and security: client data often contain personal and confidential information, so auditors must transfer and store it securely, keep only what they need and dispose of it according to policy. Independence: building or maintaining a client's analytics systems could create a self-review threat, so audit firms must be careful about providing analytics services to audit clients. Tool reliability: the auditor must be satisfied that the software and scripts used work correctly, which firms address through testing and controls over audit tools. Documentation: the audit file must record the data, the procedures, the parameters, the results and how exceptions were resolved, so another auditor could understand and reproduce the work. And skepticism: analytics finds patterns; auditors must still ask whether the data could be manipulated and whether the explanation fits all the evidence.

Analytics also supports tax work, such as testing sales tax coding on every invoice, matching expense claims to policy, and reconciling payroll to tax filings, and internal audit, where continuous monitoring of payments, vendor changes and journal entries can detect problems as they arise rather than months later.