A successful run over every uploaded record establishes coverage of the upload. Before using the results, establish whether that upload represents the business population you intended to test.
Define the population in business terms
Write a scope statement that someone outside the extraction team can follow. Specify the entity, period, transaction type, relevant status and business units. Identify which date determines inclusion: invoice date, posting date and payment date answer different questions.
Also define the unit of analysis. An invoice header, invoice line and payment allocation are different records. Joining headers to lines can multiply rows without adding invoices. A count is useful only when its unit and filters match the population being reconciled.
For PCAOB engagements, company-produced information used as evidence needs evaluation for accuracy, completeness and adequate detail. AS 1105: Audit Evidence describes those requirements. A file's size or successful import does not establish those qualities.
Reconcile the extract before interpreting findings
Consider a fictional purchasing-control review at Cedar Works. The objective covers all posted supplier invoices for four business units during September. An initial source report contains 3,260 invoice headers across all statuses. The working CSV contains 3,180.
The difference is 80 records. Fifty are drafts, excluded consistently with the stated objective. The remaining 30 are posted invoices from a recently added business unit omitted by the export's saved filter. The intended population therefore contains 3,210 invoices. Documenting the authorized exclusion explains part of the gap; it does not explain away the missing business unit.
The analyst corrects the filter and produces a new extract. Both versions are retained, with the reconciliation and the reason for replacement. Testing the original file and adding a caveat later would leave the omitted invoices outside the review.
Use several controls over the same scope
| Check | What to compare | What a difference may reveal |
|---|---|---|
| Record count | Distinct business keys under matching source and extract filters. | Omitted records, duplicated joins or differing status rules. |
| Amount totals | Amounts by currency, entity and document type. | Lost values, sign changes, duplicated amounts or conversion problems. |
| Coverage | Expected business units, date ranges and transaction categories. | A missing branch, truncated period or excluded document class. |
| Key integrity | Missing identifiers, duplicate keys and unmatched relationships. | Records that cannot be traced or linked to their supporting context. |
| Boundary records | Transactions near period, status and filter boundaries. | Different date interpretations or inconsistent inclusion logic. |
Counts and totals complement each other. Two omitted invoices could be offset by two duplicated rows, leaving the count unchanged. An omitted debit and credit could leave a net amount unchanged. Retain the detail behind each reconciliation instead of accepting a matching grand total as the whole conclusion.
Also trace where the comparison totals came from. Two reports generated from the same filtered extract can agree while both exclude the missing branch. Their agreement confirms consistency between those reports; it does not independently establish the extract's completeness. Obtain a control total or source reconciliation whose preparation can reveal the omission.
Trace the transformations that can remove records
Follow the data from the source report into the final request. Inspect joins, deduplication, type conversion, date parsing and spreadsheet filters. A join to a vendor table can discard invoices with missing vendor records if it keeps only matching rows. Those invoices may be precisely the exceptions the review needs to identify.
Keep rejected and unsupported rows in a separate reconciliation, with their reason and review destination. Do not convert credits into positive invoices or remove failed imports merely to make a batch succeed. The supported schema determines what can be tested automatically; the review objective determines what still requires another procedure.
For Cedar Works, the missing branch is a filter defect. A second issue might be blank vendor identifiers. Fixing the branch filter would not justify discarding those records during preparation. Both issues need their own disposition.
Distinguish a complete extract from a complete liability population
An extract can faithfully contain every recorded invoice while omitting obligations never entered into the system. If the objective concerns unrecorded liabilities, start from evidence that can reveal those omissions rather than testing only the recorded ledger. PCAOB AS 2315 explains why the population must fit the audit objective.
That distinction belongs in the conclusion. “All posted September invoices from the four units were included” is a defined coverage statement. It does not establish that every September obligation was recorded. Describe any additional work on receipts, subsequent payments or other sources separately.
Preserve the comparison population as well as the tested items
Some checks need records beyond the items selected for testing. A duplicate review may need earlier invoices; a contract-cap check needs relevant billing history. Establish the coverage of that supporting context, not just the current-period items.
OpenAuditor uses related items in a batch and records supplied in context.records. The request mode matters. For a single invoice verification, omitting context.records.invoice leaves the duplicate comparison unavailable. In an audit, submitted invoice items establish an available invoice population even when that context key is absent. A one-invoice audit therefore has no other invoices to compare and can hold the duplicate assertion. An explicit empty context list adds no history; it does not remove peers already present as batch items.
These input conditions describe what the check can see, not whether the source population is complete. Neither mode asks the service to search the source system for missing history. Record the actual scope instead of treating an omitted key, an empty list and a complete population as interchangeable.
When splitting requests, preserve the context required by each check and reconcile every submitted item to its returned result. The batch review workflow explains that handoff. Request and account constraints are documented under limits.
Freeze the reviewed population before selecting a sample
Save the final extract, scope statement, reconciliations, preparation steps and unresolved exclusions together. Give the snapshot a stable reference and record when it was produced. If the population changes, assess the effect on selections and completed testing before replacing it.
OpenAuditor reports findings over supplied records; it does not certify source-system completeness. Once the population is established, use risk-based audit sampling to plan what to test and keep the population evidence with the audit trail. Before splitting that population into requests, inspect our batch-boundary experiment: testing every row can still lose a cross-record relationship.