Testing direction: completeness versus occurrence
Why an occurrence test runs from the ledger back to documents, a completeness test runs from documents forward, and how to pick the right population.
By Achekam · · 5 min read · For Accountants & audit firms in South Africa, Nigeria, Kenya
Two seniors test sales on the same client. One picks invoices from the sales ledger and finds a delivery note for each. The other picks delivery notes from the dispatch book and finds each one in the ledger. Both write "no exceptions". They have tested different things, and only the second has any evidence that sales are complete.
Direction is one of the most mechanical ideas in auditing and one of the easiest to get wrong late on a Friday. Which end of the trail you start from decides which assertion the test can support, and no amount of careful work afterwards fixes a sample drawn from the wrong place.
Occurrence runs backwards, from the ledger
ACCA explains that a test of occurrence should start with the entry in the ledger and check back to the supporting documentation, to make sure the transaction actually happened. As ACCA describes it under ISA 315 (Revised 2019), occurrence means that recorded transactions and events have occurred and pertain to the entity.
The logic is simple. An invented or misattributed entry can only be caught by starting from what was recorded. If a fictitious sale has been posted, it exists in the ledger and nowhere else. It will never turn up in a sample drawn from delivery notes, because no goods left the warehouse.
Completeness runs forwards, to the ledger
ACCA explains that a test of completeness should start from the underlying documents and trace them to the entries in the relevant ledger, to make sure none has been missed. Its article on financial statement assertions sets out both directions side by side and is a good page to give a trainee who keeps mixing them up.
The reasoning mirrors occurrence. An omitted transaction is, by definition, missing from the ledger, so sampling the ledger cannot find it. You have to start from a record created independently of the accounting entry, such as a delivery note, a goods received note, a timesheet or a contract, and see whether it reached the books.
Choosing the starting population
Getting direction right depends on choosing a population that is independent of what you are testing and complete in itself.
For occurrence, the population is the ledger account or the listing of recorded transactions, reconciled to the trial balance so you know you are sampling from everything that was recorded.
For completeness, the population is a source the accounting entries are supposed to come from, and you need some comfort over its own completeness. A numbered dispatch book kept by the warehouse, a goods received log, a contract register held by the legal team, or the bank statements are all better than a report produced by the same accounting system.
Three questions settle most cases:
- Was this population produced independently of the entries I am testing?
- How do I know the population is itself complete: numbering, a reconciliation, a second source?
- Does it cover the whole period, including the last days before year end?
Two worked examples in words
Sales at a distributor. For occurrence, the senior selects recorded invoices from the sales ledger across the year and, for each, inspects the customer order, the signed delivery note and the later receipt. For completeness, she selects delivery notes from the warehouse's numbered dispatch book, checks the sequence for gaps and traces each selected note to an invoice in the sales ledger. A delivery note with no invoice is a completeness exception: goods went out and were never billed. Near the year end the same tracing becomes a cut-off test, covered in revenue cut-off testing.
Non-current assets. For existence, the balance-sheet cousin of occurrence, the team selects items from the fixed asset register and finds them on site. For completeness the direction flips: note assets seen on site and trace them to the register. ACCA adds a second completeness route that catches a common error. Reviewing the repairs and maintenance expense account can reveal items that should have been capitalised but were left out of non-current assets. A new roof or a replacement engine expensed as a repair leaves the register understated.
Drawing the sample from the right population in Achekam
In practice, direction is decided by which file is loaded before a sample is drawn. In Achekam's Audit Intelligence, staff load a population, Achekam risk-scores it and proposes a sample, and a reviewer who did not prepare the plan approves it before anything is drawn. Every draw can be reproduced from its stored seed. The methods are random, systematic, monetary unit, specific items and all items, and no sample size is proposed without approved materiality and a confidence level.
That approval is the natural checkpoint for direction. A reviewer approving a completeness plan should see a population of source documents, the dispatch log rather than the sales ledger, and should send the plan back if the wrong file was loaded. Bear in mind that monetary unit selection favours larger recorded values. That suits occurrence and overstatement, but it does little for completeness, where the missing items have no recorded value to weight.
On the work item itself, write the direction into the step. Each work item lists the procedures to perform and the documents required, and a step is marked done only with a written response and its documents, or set aside with a reason. A step that reads "Select from dispatch notes and trace to the sales ledger (completeness)" puts the direction on the record.
Direction mistakes reviewers often find
- Completeness tested from the ledger. The commonest error: the heading says completeness, but the sample came from recorded entries.
- Payables tested only from the creditors listing. Confirming listed balances says little about the supplier who was left off. That gap is why the search after year end exists; see searching for unrecorded liabilities.
- A "source" produced by the same system. A dispatch report generated from the invoicing module is not independent of invoicing.
- Sequence gaps ignored. Missing numbers in a dispatch book are the completeness question itself, not a clerical detail.
- One sample claimed for both assertions. A single selection rarely supports both directions. If a paper claims both, check where the items came from.
When reviewing a test, ask one question before any other: where did the sample come from? The answer tells you which assertion the work can support, whatever the paper's heading says.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
