21.4 Data Analytics, Exceptions, and Follow-Up

Analytics Begin With Reliable Data

The 2026 AUD blueprint explicitly covers the use of data and information: data requests, preparing and transforming data, evaluating the reliability of data, and audit data analytics (ADA). It also asks candidates to use outputs such as reports and visualizations to identify relationships, trends, or notable items, and then select the appropriate audit response.

Audit data analytics are automated tools and techniques used to discover, organize, structure, analyze, or present data to generate useful audit information. They can scan an entire journal-entry population, match sales to shipping records, identify duplicate payments, age receivables, recompute payroll, or flag unusual users posting manual entries after hours. The output is never the endpoint; it is a disciplined way to focus audit attention. The reliability of any conclusion depends entirely on the reliability of the underlying data, which the auditor must establish first under AU-C 500.

Data Request and Transformation

A strong data request is specific: it names fields, date ranges, transaction types, source systems, extraction criteria, and file format. For a journal-entry analysis the auditor may request entry number, date, posting time, preparer, approver, account, amount, description, source module, reversal flag, and period. For revenue cutoff the auditor may need invoice date, shipment date, delivery terms, customer-acceptance date, credit-memo date, and cash-receipt date.

Transformation includes cleaning dates, standardizing vendor names, mapping fields, removing inappropriate duplicates, and joining tables. The auditor documents enough that another experienced auditor can understand what data was used and how the output was produced.

Exception Analysis Is Audit Work, Not a Conclusion

An exception is an item that violates the rule or expectation embedded in the analytic. It might be a true misstatement, a control deviation, a fraud indicator, a system-mapping artifact, or a false positive. AUD questions repeatedly test whether the candidate jumps too fast from exception to conclusion.

Worked example: an analytics routine flags duplicate vendor payments sharing the same vendor, invoice number, and amount. The auditor should inspect supporting invoices, payment approvals, credit memos, and subsequent refunds.

• If the duplicates are real, consider whether expenses or payables are overstated and whether the control over invoice entry failed (a possible control deficiency).
• If they are false positives caused by legitimate installment billing, document that conclusion and refine the query.

Notice the spread of possible meanings from one identical pattern. The CPA-level skill is determining what the output means for the audit, not mechanically recording every flagged row as an error.

Follow-Up Workflow

1. Tie the analytic to a specific assertion and planned procedure.
2. Validate the completeness and accuracy of the source data.
3. Review the transformation logic, joins, filters, and thresholds.
4. Run or inspect the output and identify notable items.
5. Investigate exceptions using source documents and system or external evidence.
6. Ask follow-up questions that address the cause, not just the description.
7. Classify each exception: misstatement, control deviation, fraud risk, or false positive.
8. Accumulate results and decide whether the risk assessment, sample design, or substantive procedures must change.

A full-population scan does not eliminate professional judgment or AU-C 530 sampling discipline when the analytic still relies on attribute thresholds the auditor must interpret. Even a complete scan can be undermined by an incomplete rule, unreliable data, or exceptions that demand human interpretation. The auditor must also guard against automation bias, the tendency to over-trust a clean-looking dashboard.

CPA Exam Signals

Expect simulation exhibits with spreadsheet extracts, pivot tables, visualizations, or exception lists. The best answer almost always addresses both data reliability and follow-up evidence. If the source data came from a client-run query, the auditor typically validates the query criteria, reconciles totals to the general ledger, and traces a selection of records back to the system of record before drawing any inference.

Distractor answers to reject: assuming a client file is complete because it came from accounting, deleting items from documentation, or concluding fraud from a pattern alone. Analytics generate leads; professional skepticism and corroborating evidence turn leads into conclusions.