Sampling exists because testing everything used to be impossible. With a general ledger in a spreadsheet or database, it is often possible. A match of every bank deposit to an invoice, a scan of every journal entry for unusual characteristics, a recalculation of every depreciation line: these run in minutes. The question for the auditor is no longer whether it can be done but what the work has to look like to count as audit evidence.
What sampling is, and why analytics changes the picture
Audit sampling is the selection and evaluation of less than 100% of the items in a population so that the auditor can draw a conclusion about the whole. Because only part of the population is tested, there is sampling risk, and the auditor must expect the selected items to be representative. Our sampling guide covers the mechanics.
The AICPA's technical questions and answers on technology in financial statement audits (TQA section 8400, published October 23, 2025) address how analytics interacts with that framework:
- Audit data analytics may not necessarily eliminate the need for audit sampling, and may be used in conjunction with sampling procedures.
- Automated tools can reduce or eliminate sampling risk by analyzing entire populations. The Q&A's example is matching cash receipts from bank feeds to sales invoices and shipping records, flagging invoices, shipments or payments that lack a match, and investigating each unmatched item as a potential misstatement.
- When characteristics of the data differ from expectations, they may reveal risks that were not identified or are higher than assessed. The auditor then considers whether additional risks of material misstatement exist and tailors further procedures, which is an iterative risk assessment.
- Populations can be divided into subpopulations to target procedures at areas of higher risk.
- Automated tools do not replace the auditor's judgment, skepticism or the need to evaluate whether the electronic data is reliable.
The last point governs everything else. Testing 100% of an unreliable population tells you about the data, not the balance.
What the PCAOB amendments add as a benchmark
PCAOB standards apply to issuer audits, but the amendments to AS 1105 and AS 2301 that take effect for fiscal years beginning on or after December 15, 2025 describe the same issues in compact form. According to the SEC's approval order, they clarify what a test of details is, specify auditor responsibilities when identifying items that require further investigation in tests of details, state that a procedure used for more than one purpose (risk assessment, test of controls, substantive) must achieve each objective, and emphasize appropriate disaggregation or detail of information to the relevance of audit evidence. The reliability of external information the company provides in electronic form is addressed in new paragraph .10A of AS 1105.
For a private-company auditor, these are a statement of good practice: an analytic that produces a list of exceptions creates an obligation to dispose of the list.
Step 1: prove the population is complete
Before any test, establish that the data in your tool is the whole population and that amounts are accurate. The PCAOB's April 2024 Spotlight gives the reason in one example: to test fixed asset additions, the auditor needs a complete population of additions from the relevant system of record, and without testing completeness of the listing, errors or fictitious additions can go undetected.
For a QuickBooks-based client, completeness checks include:
- the exported general ledger totals agree to the trial balance for the same date range
- the number of transactions and the date range match what the system reports
- no accounts, classes or locations were filtered out
- voided or deleted transactions are accounted for through the audit trail, as covered in audit trail testing
- the data was exported directly, or you can document how it was handled before it reached you
Document these checks before you document the analytic. Our guide to auditing a client on QuickBooks Online covers the export controls.
Step 2: design the test to an assertion
An analytic without an assertion is a report. Write down the risk and assertion first, then the logic.
| Risk | Analytic over the full population |
|---|---|
| Revenue occurrence | Match every recorded invoice to cash receipt or delivery evidence; list unmatched |
| Revenue cutoff | Compare invoice date with shipment or service date across year-end; list differences |
| Management override of controls | Journal entries posted on weekends or holidays, by unexpected users, with round amounts, or to unusual account pairs |
| Duplicate payments | Same vendor, amount and date or invoice number; near-duplicates within a tolerance |
| Completeness of liabilities | Subsequent disbursements by date compared with accrual and payable balances |
| Fixed asset additions | Recompute depreciation by asset; list additions with no invoice reference |
Benford's Law works as a screening technique for fabricated-looking numbers, but it identifies populations to look at, not misstatements, and the distribution fits only certain data.
Step 3: dispose of every exception
This is where full-population testing succeeds or fails. When you test 100%, every exception is in your hands. The AICPA's own example says each unmatched item is investigated as a potential misstatement. Practical rules:
- Set the investigation criteria before you run the test. Define what a match is, the tolerance, and what counts as an exception.
- Log every exception with its disposition: error, timing difference, explained with evidence, or unresolved.
- Do not dispose of exceptions by volume. If a test produces 400 exceptions, risk assessment has found something; do not sample the exceptions to make them go away without a documented rationale.
- Project or extrapolate only where appropriate. If errors are found in a full-population test, they are known misstatements to be accumulated. They are not a sample to project.
- Carry the result back to the risk assessment. Unexpected findings can reveal risks higher than assessed, and the plan has to change.
Step 4: decide what the analytic is evidence of
A single analytic may serve more than one purpose. A journal entry scan can inform risk assessment and also serve as a substantive procedure on the population of entries, but if you use it for both, you must achieve each objective, as the PCAOB amendments put it for issuers. Write down which purposes the procedure served.
Remember what analytics does not do. It does not substitute for an understanding of the business, and it does not audit the items that never reached the ledger. Completeness of recording, such as unrecorded liabilities, still needs evidence from outside the ledger. Analytical procedures under AU-C 520 covers the other end of the spectrum, expectation-based analytics.
Step 5: workpaper documentation
Record the objective, the assertion, the data source and completeness checks, the logic (query or script saved with the file), the results, the disposition of every exception, and your conclusion. Another auditor should be able to re-run it. How to document audit procedures covers the standard.
Frequently asked questions
Is 100% testing required if the data allows it?
No. The standards do not require it. It is a choice that depends on the risk, the data and the cost compared with other approaches.
Does testing 100% eliminate audit risk?
No. It removes sampling risk for the test performed. Non-sampling risk, such as data that is incomplete or logic that is wrong, remains.
Do I need special software?
Not for many tests. A spreadsheet or query tool handles matching and filtering for small populations. Repeatability and documentation matter more than the tool.
Sources
- Thomson Reuters Tax & Accounting, "AICPA issues technical Q&As on technology use in financial statement audits" (reporting on AICPA TQA section 8400, published October 23, 2025): https://tax.thomsonreuters.com/news/aicpa-issues-technical-qas-on-technology-use-in-financial-statement-audits/
- SEC Release No. 34-100774, Order Granting Approval of Amendments Related to Aspects of Designing and Performing Audit Procedures that Involve Technology-Assisted Analysis of Information in Electronic Form (August 20, 2024): https://sec.gov/files/rules/pcaob/2024/34-100774.pdf
- PCAOB, Spotlight: Inspection Observations Related to Auditor Use of Data and Reports (April 2024): https://assets.pcaobus.org/pcaob-dev/docs/default-source/documents/data-and-reports-spotlight.pdf
CORAA prepares ready-to-review audit files for US CPA firms from QuickBooks books; you review and sign. See /us.
Part of CORAA University · Evidence and audit procedures: related guides, calculators and templates.
AU-C references are to AICPA Professional Standards, paraphrased here; read the standard itself before relying on a requirement. This page is guidance, not professional advice. Report an error