Audit concepts

Connect each finding to the audit objective.

Materiality, assertions and evidence give a finding its meaning. OpenAuditor supplies checks and their supporting facts; your audit plan determines the question, the population and the conclusion those checks can support.

Use this guide when designing a finance review or incorporating verification results into audit workpapers. The terminology below draws on PCAOB standards for financial statement audits. Apply the standards relevant to your engagement.

Materiality: assess significance in context

In a financial statement audit, materiality concerns the significance of a misstatement or omission to users of the financial statements. The amount matters, as do the nature and circumstances of the issue. Individually small misstatements can matter together; a related-party conflict can warrant attention because of its nature. Materiality guides the auditor's planning and evaluation of the work.

The auditor establishes materiality for the financial statements as a whole and considers whether particular accounts or disclosures need lower levels. Tolerable misstatement helps plan work at the account or disclosure level and is lower than the applicable materiality level. These are engagement judgments that may need revision as evidence changes. See PCAOB AS 2105: Consideration of Materiality.

A purchase-order threshold has a different purpose: it tells a control when a PO is required. In the supplier-invoice example, a $24,800 invoice without a PO fails a rule whose threshold is $1,000. That identifies a control exception. It does not establish that the financial statements contain a $24,800 misstatement, or that the exception is material.

The current hosted API has no materiality setting. It does not calculate engagement materiality, aggregate misstatements against it, or suppress failed checks because an amount is small. Record materiality and the reasoning behind your conclusion in your own workpapers, alongside the finding.

Assertions: define what the procedure must establish

Financial statement assertions concern management's representations about existence or occurrence, completeness, valuation or allocation, rights and obligations, and presentation and disclosure. An OpenAuditor assertion is a narrower, executable condition, such as whether invoice lines reconcile to the total. The reviewer maps that condition to the engagement's relevant assertion and decides what additional work is needed. PCAOB AS 1105: Audit Evidence describes both financial statement assertions and the relevance and reliability of evidence.

OpenAuditor check	Useful audit question	Work still needed
Invoice arithmetic	Do the supplied quantities, prices, tax and discount reconcile to the recorded amount?	Establish whether the goods or services were received and the prices and accounting treatment are appropriate.
Purchase-order reference	Does this invoice satisfy the configured requirement to reference a PO?	Inspect the PO, its authorization and relevant receipt evidence. A populated reference alone does not establish these facts.
Duplicate comparison	Does another supplied invoice match the rule's duplicate criteria?	Confirm the comparison population, investigate matches and determine whether an overstatement or duplicate payment occurred.

A passed check supports its stated condition within the supplied evidence and applicable decision rules. It does not establish every financial statement assertion about the transaction. A model-qualified finding can still be wrong; qualification and the requested certainty target are not independent proof of the business fact.

Audit evidence: preserve the source and the scope

Sufficiency concerns how much evidence is obtained; appropriateness concerns its relevance and reliability. More records do not repair an unreliable source. Evidence can support a conclusion or contradict it, and both matter to the review. These distinctions are described in AS 1105.

OpenAuditor checks the records and references you submit. Its response identifies this boundary as scope.evidence: "supplied". An evidence pointer leads to a request field; it does not authenticate an original invoice or independently confirm a vendor balance. Preserve the source documents, extraction or transformation steps, and relevant reconciliations with the result.

Before relying on a population, establish its period, source, exclusions and completeness. For example, an accounts-payable export can show recorded invoices but cannot by itself establish that every liability was recorded. The results reference explains how to read evidence pointers and unresolved assertions.

Control testing: distinguish a rule from its operation

A test of controls addresses whether a control operates as designed, including whether the person performing it has the necessary authority and competence. The evidence, timing and extent of the testing determine the conclusion it supports. See PCAOB AS 2301: Responses to the Risks of Material Misstatement.

OpenAuditor can check supported conditions such as approval authority, separation of duties or a required PO reference against supplied records. Use those findings within a documented control-testing procedure. A single valid approval record does not establish that a control operated throughout the year; a missing reference needs investigation before you conclude why the control failed.

Substantive procedures: test the recorded amount or disclosure

Substantive procedures address potential misstatements and include tests of details and substantive analytical procedures. The objective distinguishes them from tests of controls. Recalculating invoice lines can support a test of details; inspecting an approval record can support a control test. A procedure used for both purposes needs to meet both objectives.

OpenAuditor provides supported record-level checks, including arithmetic, dates, limits and population comparisons. Choose them for a defined objective and document how their results relate to the account under review. The service does not independently obtain confirmations, observe inventory, or assemble a complete financial statement audit.

Exceptions: retain the finding and resolve its meaning

A failed assertion is an exception to the condition tested. It may reveal a control deviation, an input error or a potential misstatement. The reviewer determines which, investigates the cause and assesses its significance. An unresolved assertion instead identifies work the service could not decide, such as a missing record or an unqualified judgment question.

For the missing-PO invoice, inspect the source and purchasing records, confirm which policy applies, and record the disposition. Correct an input error and rerun the verification when appropriate. Retain the original result with the correction and review decision. The API verdict false is a result for the submitted item; it is not an audit opinion or a fraud determination.

Sampling and population coverage: state what was tested

Audit sampling applies a procedure to part of a population to evaluate a characteristic of that population. Its design, selection method and evaluation determine whether results can support a wider conclusion. Testing only selected high-value items does not by itself provide a representative sample. See PCAOB AS 2315: Audit Sampling.

A batch audit in OpenAuditor processes the items submitted. It does not design an audit sample or project monetary misstatements to an untested population. Even testing every uploaded row leaves questions about the export's completeness and whether the checks address the audit objective.

Population checks can use related items in the same batch and the comparison records supplied in context. Splitting records across requests can hide relevant relationships. In a single verification, an omitted comparison population can leave its check unresolved; an explicit empty list declares no additional comparison records. In a batch, submitted items of the relevant type still participate even when that context list is absent or empty. Keep that scope with the result. See batch audits for submission and retrieval.

Audit trail: make the conclusion reviewable

Useful audit documentation connects the procedures performed, evidence obtained and conclusions reached, and identifies who performed and reviewed the work. That is the purpose of the documentation requirements in PCAOB AS 1215: Audit Documentation.

Keep the verification response, input_sha256, configuration, source records and policy version together. Add the objective, selection rationale, exceptions, follow-up evidence, preparer and reviewer details, and final disposition in your system. Batch review marks record whether a reviewer accepts an item's returned verdict, including an uncertain verdict, with an optional note. A new mark replaces the previous mark for that item; the API exposes aggregate counts, not individual notes or a review history. Preserve that history in your workpapers.

Single-verification calls do not create a retained audit record. Batch results expire seven days after completion unless deleted sooner. Export the records your engagement needs and apply your own retention requirements; see data retention.

Put the concepts into a review

Start with the financial-audit workflow, choose a supported assertion, and follow the quickstart to inspect one result. Establish the purpose and scope before expanding the review to a population.