Full-population testing, run with data analytics, checks every transaction in a cycle against a rule rather than checking a sample and inferring about the rest. What changes is that rare but material exceptions — the single duplicate payment in ten thousand, the one voucher posted out of sequence — stop depending on whether they happened to fall into the sample. What does not change is the judgement step: a flagged exception is a candidate, and deciding whether it is an error, a misclassification, or nothing at all still requires a person who understands the transaction.

What sampling was always built to answer

Sampling exists because testing every transaction by hand is not feasible within a reasonable budget. It answers a specific and useful question: based on the error rate observed in a representative sample, what is the likely error rate in the population, within a stated confidence level? That is a sound basis for an opinion on a population's overall characteristics, and it is what sampling has always been for.

It is a weaker tool for a different question: is there a specific transaction in this population that is wrong, regardless of what the rest of the population looks like. A statistically sound sample of two hundred transactions out of forty thousand will, by design, very often miss the three transactions that matter. That is not a flaw in the sampling method. It is a mismatch between the question sampling answers and the question an exception-driven risk actually poses.

What testing every row actually surfaces

Full-population testing applies a rule — a duplicate check, a sequence check, a tolerance on a variance, a cross-reference between two records that should agree — to every row, not a sample of rows. The value is concentrated in exactly the cases sampling is weak on: low-frequency, high-consequence exceptions that would otherwise need to be unlucky enough to land in the sample to be found at all.

Duplicate payments to the same vendor for the same invoice number, which are individually rare but structurally invisible to a sample unless both occurrences happen to be drawn.
A voucher sequence gap in week 37 of 52, when the sample happened to cover weeks 1 to 12 and 40 to 52.
A journal entry posted directly to a revenue account outside the normal sales cycle, on a date with no other unusual activity around it.
A handful of transactions where a rate or rule changed mid-year and a small number of postings were made on the old basis after the cutover.

Common practice, not a requirement

None of these examples depends on the population being large. The reason sampling misses them is not population size, it is that each is a needle, and a sample is a handful of straw drawn at random from the stack. Testing the whole stack finds every needle that matches the rule it was tested against.

The limit that does not move

A rule can only find what it is written to find. Full-population testing is exhaustive within the scope of the rules applied, not exhaustive in some broader sense. A duplicate-payment check finds duplicate payments. It says nothing about a payment that was properly matched to an invoice but for a service that was never actually rendered. That is a different category of risk, and no amount of running the existing checks against more rows closes it.

This is the point worth being explicit about with a client or a reviewer: full-population coverage is coverage of a defined set of checks against every transaction, not a guarantee that every risk in the cycle has been addressed. The audit still needs a view on what the rules do not cover.

What an exception is, and what it is not

A rule flags a transaction that meets a defined condition. It does not and cannot determine why the transaction meets that condition. The same duplicate-payment flag covers an outright duplicate, a legitimate split payment against one invoice recorded under two voucher numbers, and a genuine re-payment after a reversed earlier entry. All three trip the same rule. Only one of them is an error.

What the two steps actually do
Step	What it does	Who or what performs it
Running the check	Applies a fixed rule to every row and produces a list of matches	Deterministic code, run the same way every time
Resolving the exception	Decides what each matched row actually is, and what it means for the opinion	A named auditor, with access to the underlying documents

What the two steps actually do

An exception list with no disposition recorded against each line is not audit evidence. It is a to-do list. The file needs to show who looked at each exception, what they found, and why it was or was not an error — otherwise the running of the check has added volume to the file without adding assurance.

Sizing the work this actually creates

01Decide which rules earn their placeA check that is likely to return hundreds of immaterial matches for every one real exception is not free: every match still has to be looked at or formally scoped out. Favour checks where a match is a reasonably strong signal, not every check that is technically possible to write.
02Run the checks against the full population, not a convenience extractA check run against a sample-sized extract is sampling with extra steps. The benefit described above depends on every row being tested.
03Triage exceptions by value and by pattern before by countTen exceptions concentrated in one vendor or one week tell a different story than ten exceptions scattered across the year with no relationship to each other.
04Record a disposition for every exception, including the ones cleared with no adjustmentA cleared exception with a one-line reason is defensible. A cleared exception with no reason recorded looks, on review, exactly like one nobody actually looked at.

Where this sits against sampling, not instead of it

Full-population testing and sampling are not competing choices for the same risk. Sampling remains the right tool for forming a view on characteristics that are genuinely about the population as a whole — an overall error rate, a general level of control compliance — where no single transaction being wrong changes the conclusion. Full-population testing is the right tool where a single transaction being wrong does change the conclusion, and where a rule can be written to find it reliably.

How we think about this

The honest way to describe what changed is narrower than it sounds: a computer can apply a fixed rule to every row without getting tired or skipping rows, which a person cannot do reliably at scale. That is a real and useful capability. It is not intelligence, and it does not extend to deciding what a match means. Lekhya runs checks across full populations because that part of the work is mechanical and should never depend on which rows happened to be drawn — and leaves every disposition to the auditor who signs the file.

This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.

Free tools, no signup

Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.

Data analytics in audit: what full-population testing changes