An audit senior opens the payables population for the year: several thousand vendor bills. The plan calls for a few dozen items, selected with care and documented properly. The sample comes back clean, and the file says so. In the same population, two bills from the same vendor carry the same reference a week apart, and neither was selected. The sample was correct. It was also silent about the two items that mattered.
Sampling exists because, for most of audit history, testing everything was impossible within any sensible budget. That constraint has largely gone for anything held in a ledger. The question is no longer whether you can test every transaction, but what changes in your method, your evidence and your judgement when you do. This guide answers that, with a worked procedure you can run on your own data.
What is full-population testing?
Full-population testing is applying an audit procedure to every item in a defined population, such as all vendor bills posted in a year, rather than to a selected subset. ISA 530 governs audit sampling, where the auditor applies procedures to less than the whole population and draws a conclusion about the rest. When every item is tested, there is no extrapolation and therefore no sampling risk for that test. What remains is the risk that the population is incomplete, that the test is wrong, or that someone misreads an exception.
Definition is half the work. “All purchases” is not a population; “all posted vendor bills and credit notes in the purchase journals between two dates, for all companies in the database” is. If the definition is loose, the test is complete only for the part you happened to extract. Full-population testing is one of the engines of continuous auditing with AI, and the series hub on AI in accounting shows where it fits among the other uses.
How is it different from audit sampling under ISA 530?
| Aspect | Audit sampling (ISA 530) | Full-population testing with AI |
|---|---|---|
| Question answered | Is the error rate or misstatement in the population acceptable? | Which specific items fail the test? |
| Risk that remains | Sampling risk plus non-sampling risk | Non-sampling risk only: wrong test, incomplete data, misjudged exception |
| Completeness check | Population defined, then sampled | Extracted population reconciled to the ledger before testing |
| Exceptions | Few, each investigated, then projected | Many, ranked by risk, each resolved or explained |
| Documentation (ISA 230) | Selection method, items tested, results, projection | Test logic, population totals, every exception and its resolution |
| Effort profile | Spread across document inspection | Concentrated in test design and exception review |
| Best suited to | Physical, external or costly-per-item evidence | Attributes visible in ledger and system data |
The first row is the one people miss. Sampling estimates; full-population testing identifies. That changes what you do with the result. A projected error is evaluated against materiality as a whole. An identified exception is a specific record with a specific owner, and it needs a specific resolution.
Does testing 100% of transactions mean 100% assurance?
No, and claiming it would be a documentation problem waiting to happen. A test detects only what it was designed to detect. A duplicate test on reference numbers will not find a duplicate entered with a different reference. A cut-off test on dates will not find a sale that should never have been recorded. ISA 500 asks whether information used as audit evidence is relevant and reliable, and that applies to the extract and the test logic as much as to any document. The IAASB’s August 2026 exposure drafts revising ISA 500, ISA 330 and ISA 520 address the increased use of technology; comments are due by 15 December 2026 and the drafts are not yet final, so watch the wording rather than anticipate it.
A decision rule we use: describe a full-population test by the attribute it proves and the population it covers, never as “all transactions tested”. “Every posted vendor bill in the year was tested for duplicate vendor and reference” is a claim you can defend. “AP was tested 100%” is not.
How does AI help test a full population?
Preparing the data
Before any test, profile the population: count of records, totals by period, blank fields, users who posted, posting dates outside the period. Then reconcile totals to the trial balance. AI is useful here for spotting inconsistent text, such as one vendor written five ways, but the reconciliation itself is arithmetic and should stay deterministic.
Testing and ranking
Rules test attributes: duplicates, approvals, dates, round amounts. Models then rank all items by risk so that reviewers start at the top rather than in posting order. Ranking is what makes a full population workable: a reviewer cannot read every line, but can read the riskiest ones first and document why the rest were not escalated.
Documenting
Language models can draft the exception narrative and the working paper. The safeguard is that every statement cites the records it was drawn from; anything else is rejected. That principle, evidence or silence, is covered in our article on AI provenance and the audit trail.
A worked example: testing every vendor bill in a quarter
The procedure below uses no amounts. It can be run on any ERP; where Odoo features are mentioned, confirm them in your own database and edition.
- Define the population: all posted vendor bills and credit notes in the purchase journals for the quarter, for every company in scope.
- Reconcile: the count and total of the extract must agree with the movement on the payables control account for the same period. If they do not, stop and find the gap.
- Test exact duplicates: same vendor, same reference, same amount. Odoo’s 20 release notes add duplicate detection on invoices and bills with two levels, red for highly likely and yellow for potential duplicates; compare your results with those warnings to learn whether the system control is working.
- Test near-duplicates: same vendor and amount within a short date window but a different reference, and vendors whose names differ only slightly.
- Test approvals: bills linked to purchase orders that exceeded the approval threshold without a manager’s validation. In recent Odoo versions this rests on the Purchase Order Approval setting; confirm how it is configured in your 20 database, and see three-way match purchase controls for the matching side.
- Test segregation: the same user created the vendor, raised the order and validated the bill, a pattern explored in AI and segregation of duties.
- Test cut-off: bill date and posting period disagree around the quarter end.
- Rank all exceptions by risk and review from the top, recording the conclusion for each.
How should exceptions be evaluated?
Every exception ends in one of four categories, and the category decides what happens next.
- Explained: a legitimate item, such as a recurring monthly bill. Record the evidence that explains it and consider refining the test.
- Control deviation: the control did not operate, but no misstatement resulted. Report it as a control finding with an owner.
- Misstatement: the books are wrong. Quantify it, evaluate it against materiality as described in our note on ISA 320 thresholds, and correct it by reversal, never by deletion.
- Fraud indicator: an item that calls for the inquiries ISA 240 requires. It is not proof; AI-based fraud detection explains why a flag is a question, not a conclusion.
Testing every transaction removes sampling risk. It does not remove the duty to be right about what you tested.
When is sampling still the right tool?
When the evidence is not in the system. Physical inventory, external confirmations, inspection of a signed contract or a site visit cost the same per item whether or not you have AI, so sampling remains the rational choice. The two approaches also combine well: use the full population to identify high-risk strata, test those strata fully, and sample the low-risk remainder where documentary evidence is needed. The ACFE’s 2024 Report to the Nations found that proactive data monitoring and analysis was among the anti-fraud controls associated with roughly half the losses and duration, which argues for running analytics across the population, not for abandoning judgement about where to look closer.
Where to start on Monday
Choose one population you already sample, most often payables. Define it precisely, reconcile it to the trial balance, and run the five tests from the worked example on the last closed quarter. Then compare: what did the full-population tests find that the last sample did not, and how many exceptions turned out to be explained items? That comparison is your calibration, and your first working paper.
This is the method behind MFT’s seg-audit platform, which reads the books from the ERP read-only and scores every transaction by risk instead of sampling a few percent. Every finding has a source in the books, is classified against the ISAs, and keeps an evidence trail that external auditors can use. If you want the analysis run for you, our internal audit service and the Auditor agent, which drafts findings for a named person to approve, are where to start.