Financial Audit Evidence Prioritization Prompt

This prompt is designed for audit automation and assurance AI teams that need to transform a flat set of retrieved audit evidence into a sufficiency-weighted schedule before generating an audit conclusion. The core job-to-be-done is ranking evidence by assertion coverage, source reliability, and detection risk reduction. Use it when your system has already retrieved candidate evidence passages and associated metadata—such as source type, date, and preparer—and now must evaluate whether that evidence is strong enough to support or challenge specific financial statement assertions like existence, completeness, or valuation.

The ideal user is an engineering lead or AI architect building an audit workflow where the model must explicitly reason about management bias in internally generated evidence. The prompt forces the model to explain why each piece of evidence reduces or fails to reduce detection risk for each assertion, producing a structured schedule that an auditor or downstream conclusion generator can consume. Required context includes the audit area, the assertions under test, the retrieved evidence passages, and metadata fields such as source origin (internal vs. external), preparer role, and date. Without this context, the model cannot perform the required bias and sufficiency analysis.

Do not use this prompt for general document search, ad-hoc Q&A over financial documents, or when evidence has not been pre-retrieved and filtered. It is not a retrieval prompt—it assumes you already have a candidate set. Do not use it when the audit area or assertions are undefined, as the model will produce generic rankings that fail to address specific detection risk. This prompt is also inappropriate for real-time transaction screening or control testing where evidence volume is too high for LLM-based ranking; those workflows require deterministic rules or smaller classification prompts. Finally, avoid this prompt when the output will be used as a final audit opinion without human review. The ranked schedule is an input to auditor judgment, not a replacement for it.

Before deploying, ensure your retrieval pipeline produces evidence with consistent metadata fields. The prompt's effectiveness depends on the model being able to distinguish internally generated evidence from externally sourced evidence. If your retrieval system cannot reliably tag source origin, add a pre-processing step to classify evidence provenance before invoking this prompt. For high-risk audit areas such as revenue recognition or going concern, always route the ranked schedule to a human reviewer and log the full prompt-response pair for audit trail purposes.

This prompt template is designed to be pasted directly into your model's system or user message. It instructs the model to act as an audit evidence specialist, prioritizing a provided set of evidence items against specific financial statement assertions. The core logic forces the model to weigh three critical dimensions: how directly the evidence tests the assertion (coverage), the independence and objectivity of its source (reliability), and its power to reduce the risk of not detecting a material misstatement (detection risk reduction). The output is a structured, ranked schedule, not a conversational summary.

textCopy
You are a senior audit evidence specialist. Your task is to rank the provided audit evidence items for a specific financial statement assertion. You must produce a sufficiency-weighted evidence schedule.

## ASSERTION UNDER AUDIT
[ASSERTION]

## EVIDENCE ITEMS
[EVIDENCE_LIST]

## RANKING CRITERIA
For each evidence item, assign a score from 1 (low) to 5 (high) for each of the following criteria, and provide a brief justification:
1. **Assertion Coverage:** How directly and completely does this evidence test the stated assertion?
2. **Source Reliability:** How independent and objective is the source? (Externally generated and directly received evidence scores highest; internally generated evidence requires a flag for management bias risk).
3. **Detection Risk Reduction:** How effectively does this evidence reduce the risk that a material misstatement will go undetected?

## OUTPUT FORMAT
Return a single JSON object with the key "evidence_schedule" containing an array of objects. Each object must have the following fields:
- "evidence_id": string (from the input)
- "evidence_summary": string (a brief, 10-word summary)
- "assertion_coverage_score": integer (1-5)
- "assertion_coverage_justification": string
- "source_reliability_score": integer (1-5)
- "source_reliability_justification": string
- "management_bias_flag": boolean (true if the source is internally generated and lacks corroboration)
- "detection_risk_reduction_score": integer (1-5)
- "detection_risk_reduction_justification": string
- "overall_priority_rank": integer (1 is highest priority)

## CONSTRAINTS
- The "overall_priority_rank" must be determined by a weighted sufficiency calculation: (assertion_coverage_score * 0.4) + (source_reliability_score * 0.3) + (detection_risk_reduction_score * 0.3). Higher total scores get a higher priority (lower rank number).
- If any evidence item is internally generated, the "management_bias_flag" must be set to true and the "source_reliability_score" cannot exceed 3.
- Do not invent evidence. Only rank the items provided in [EVIDENCE_LIST].
- If the [EVIDENCE_LIST] is empty, return an empty "evidence_schedule" array.

To adapt this template, replace the [ASSERTION] and [EVIDENCE_LIST] placeholders with real data. The [EVIDENCE_LIST] should be a valid JSON array of objects, each with a unique evidence_id and a description field. The weighted formula in the constraints is a starting point; you should calibrate the weights (0.4, 0.3, 0.3) based on your firm's audit methodology or the specific risks of the engagement. For high-risk areas, you might increase the weight of detection_risk_reduction. The critical non-negotiable rule is the cap on source_reliability_score for internally generated evidence, which operationalizes the professional skepticism required by auditing standards. Before deploying, run this prompt against a golden dataset of 10-15 evidence sets where the correct priority ranking is known and agreed upon by a senior auditor to validate the weighting function.

This prompt is designed to operate as a stateless scoring step inside a larger audit evidence pipeline. It should receive a pre-retrieved set of evidence items (from a document store, RAG retrieval, or structured audit database) and return a ranked, scored schedule. The application layer is responsible for assembling the input context, enforcing the output schema, and deciding what happens with low-confidence or conflicting rankings. Do not use this prompt as the sole decision-maker for audit conclusions; it is an evidence prioritization assistant that requires downstream human review for any materiality judgments.

Input assembly requires the application to collect: [AUDIT_ASSERTION] (the specific financial statement assertion being tested, such as completeness or valuation), [EVIDENCE_LIST] (an array of evidence objects, each with source_type, source_reliability, detection_risk_reduction, assertion_coverage, and management_bias_flag fields), and [MATERIALITY_THRESHOLD] (a numeric threshold for filtering low-impact evidence). The application must validate that each evidence object contains all required fields before sending the prompt. Missing or malformed fields should trigger a pre-processing rejection, not a model retry. Output validation must enforce a strict JSON schema: an array of evidence items with rank, evidence_id, sufficiency_score (0-1), priority_tier (enum: HIGH, MEDIUM, LOW), bias_warning (boolean), and rationale (string). Use a JSON schema validator post-generation. If validation fails, retry once with the error message appended to the prompt as a [PREVIOUS_ERROR] constraint. After two failures, escalate to a human review queue with the raw model output and validation errors logged.

Model choice should favor models with strong structured output and reasoning capabilities. For production audit workloads, prefer GPT-4o or Claude 3.5 Sonnet with response_format set to json_object (OpenAI) or use tool-calling with a strict output schema (Anthropic). Avoid smaller models for this task because the ranking logic requires multi-attribute trade-off reasoning that degrades sharply below frontier model capabilities. Logging must capture: the full prompt input, the raw model output, the validated output, the sufficiency scores per evidence item, any bias warnings triggered, and the final reviewer decision if escalated. This audit trail is essential for demonstrating evidence prioritization rationale to external auditors. Human review gates should be triggered automatically when: (a) any evidence item receives a bias_warning: true with a sufficiency_score above 0.5, (b) the top-ranked evidence item has a sufficiency_score below 0.3, or (c) the model output fails schema validation twice. These gates prevent over-reliance on internally generated evidence with management bias and ensure insufficient evidence is flagged before audit conclusions are drawn.

Retrieval integration depends on the evidence source. If evidence is pulled from a document store via RAG, the retrieval step should pre-filter by assertion type and entity before passing results to this ranking prompt. Do not send raw document chunks directly; the application layer must extract structured evidence metadata (source_type, source_reliability, etc.) before invoking the prompt. For structured audit databases, query directly for evidence records matching the assertion and entity, then map fields to the expected input schema. Tool use is not required for the core ranking step, but consider adding a lookup_prior_year_evidence tool if temporal comparison is needed for detection risk assessment. Wire this as a pre-processing tool call before the ranking prompt, not during it, to keep the ranking step stateless and testable.

Testing and eval must include: (1) a golden dataset of 20+ evidence sets with auditor-annotated rankings to measure ranking accuracy (use NDCG or Kendall's tau), (2) adversarial test cases with all internally generated evidence to verify bias warnings trigger, (3) edge cases with empty evidence lists (expect a refusal or empty array, not hallucinated rankings), and (4) schema compliance tests that run 100+ generations and verify zero schema violations. Run these evals on every prompt version change and log results alongside the prompt version in your audit trail. What to avoid: never bypass the bias warning gate for speed, never use this prompt to generate audit opinions directly, and never skip output validation in production—unvalidated rankings will corrupt downstream audit workflows and create compliance exposure.