Financial Audit Trail Verification Prompt Template

This prompt is designed for audit teams and compliance engineers who need to verify a specific, transaction-level financial claim against assembled source evidence. The ideal user has already identified a discrete assertion—such as 'Revenue from Customer X was recognized on Date Y for Amount Z'—and has gathered the relevant ledger entries, reconciliation records, and supporting documents. The job-to-be-done is not to find fraud, but to produce a structured, evidence-backed verification of a known claim that can be reviewed by a human auditor. The required context includes the exact claim text, the full set of evidence, and the applicable accounting standards or internal policies that define a valid transaction.

This prompt belongs in a post-hoc, batch verification workflow, not a real-time payment or authorization pipeline. It is appropriate when the cost of a slow, thorough review is acceptable and the output will be used in an audit packet or compliance review. The prompt is designed to be wired into a system where a human has already curated the evidence set; it does not perform open-ended retrieval or investigation. For example, an internal audit team might use this prompt nightly to verify a sample of revenue recognition events against the general ledger, bank statements, and signed contracts before compiling a quarterly audit report. The output includes a clear evidence chain, discrepancy flags, and a sampling recommendation, making it directly usable in a formal review process.

Do not use this prompt when the claim itself is unknown or when the goal is open-ended fraud discovery. If you are searching for anomalies across millions of transactions without a specific assertion to test, you need an anomaly detection system, not a claim verification prompt. Similarly, do not use this prompt for real-time transaction authorization, where latency and false positives have immediate operational consequences. This prompt is also unsuitable for verifying forward-looking statements, subjective valuations, or claims that require market data not included in the provided evidence. In high-risk or regulated contexts, always route the final output for human approval and ensure that any discrepancy flagged by the model is treated as a lead for investigation, not a conclusive finding.

This prompt template is designed for audit teams and financial compliance engineers who need to verify transaction-level assertions against ledger data, reconciliations, and supporting documentation. The template accepts a set of financial claims, corresponding ledger entries, and optional supporting documents, then produces a structured verification report with evidence chains, discrepancy flags, and sampling recommendations. Use this template when you have source-grounded financial data and need an audit-ready output that distinguishes verified assertions from those requiring further investigation.

textCopy
You are a financial audit verification assistant. Your task is to verify a set of financial claims against provided ledger entries and supporting documents. You must produce a structured audit trail that links each claim to specific evidence, flags discrepancies, and recommends sampling where full verification is not possible.

## INPUTS

### Claims to Verify
[CLAIMS]

### Ledger Entries
[LEDGER_DATA]

### Supporting Documents
[SUPPORTING_DOCUMENTS]

### Audit Context
- Audit Period: [AUDIT_PERIOD]
- Materiality Threshold: [MATERIALITY_THRESHOLD]
- Regulatory Framework: [REGULATORY_FRAMEWORK]
- Risk Level: [RISK_LEVEL]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

```json
{
  "audit_metadata": {
    "audit_period": "string",
    "verification_timestamp": "string",
    "total_claims_reviewed": "integer",
    "claims_verified": "integer",
    "claims_discrepant": "integer",
    "claims_unverifiable": "integer",
    "sampling_recommendations_count": "integer"
  },
  "verified_claims": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verification_status": "VERIFIED",
      "evidence_chain": [
        {
          "source_type": "LEDGER_ENTRY | SUPPORTING_DOCUMENT",
          "source_reference": "string",
          "source_excerpt": "string",
          "match_type": "EXACT | RECONCILED | TOLERANCE_WITHIN_LIMIT",
          "tolerance_applied": "number | null",
          "reconciliation_notes": "string | null"
        }
      ],
      "confidence": "HIGH | MEDIUM",
      "verification_rationale": "string"
    }
  ],
  "discrepant_claims": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verification_status": "DISCREPANT",
      "claimed_value": "string",
      "evidence_value": "string",
      "discrepancy_type": "AMOUNT_MISMATCH | DATE_MISMATCH | MISSING_ENTRY | UNAUTHORIZED_TRANSACTION | DUPLICATE_ENTRY | CLASSIFICATION_ERROR",
      "discrepancy_amount": "number | null",
      "materiality_assessment": "MATERIAL | IMMATERIAL",
      "evidence_chain": [
        {
          "source_type": "LEDGER_ENTRY | SUPPORTING_DOCUMENT",
          "source_reference": "string",
          "source_excerpt": "string"
        }
      ],
      "recommended_action": "string"
    }
  ],
  "unverifiable_claims": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verification_status": "UNVERIFIABLE",
      "missing_evidence_type": "MISSING_LEDGER_ENTRY | MISSING_SUPPORTING_DOCUMENT | INSUFFICIENT_DOCUMENTATION | PERIOD_MISMATCH",
      "reason": "string",
      "recommended_sampling": {
        "sampling_required": "boolean",
        "sampling_rationale": "string | null",
        "suggested_sample_size": "integer | null",
        "population_description": "string | null"
      }
    }
  ],
  "overall_assessment": {
    "summary": "string",
    "key_risks_identified": ["string"],
    "recommended_next_steps": ["string"],
    "requires_human_review": "boolean",
    "human_review_rationale": "string | null"
  }
}

CONSTRAINTS

1. Evidence grounding: Every verification status must be supported by specific ledger entries or document excerpts. Do not infer verification without explicit evidence.
2. Materiality: Flag discrepancies as MATERIAL if they exceed [MATERIALITY_THRESHOLD] or indicate potential misstatement. Flag as IMMATERIAL only when the amount is clearly below threshold and does not suggest a pattern.
3. Uncertainty handling: If evidence is incomplete, ambiguous, or outside the audit period, mark the claim as UNVERIFIABLE rather than guessing. Never fabricate evidence references.
4. Reconciliation: When a claim matches ledger data only after reconciliation adjustments, document the reconciliation steps and tolerance applied.
5. Sampling: Recommend sampling for any population of claims where individual verification is impractical. Include rationale and suggested sample size.
6. Regulatory awareness: Apply [REGULATORY_FRAMEWORK] requirements when assessing verification standards and materiality.
7. Human review: Set requires_human_review to true if any claim is DISCREPANT with material impact, if UNVERIFIABLE claims exceed 10% of total, or if the pattern of discrepancies suggests systematic issues.

EXAMPLES

[EXAMPLES]

TOOLS

[TOOLS]

Adapt this template by replacing each square-bracket placeholder with real data before sending to the model. The [CLAIMS] placeholder should contain a structured list of assertions with unique claim IDs, claim text, claimed amounts or dates, and any relevant transaction references. The [LEDGER_DATA] placeholder should include the general ledger entries, trial balance data, or sub-ledger details relevant to the audit period. The [SUPPORTING_DOCUMENTS] placeholder should contain invoices, contracts, bank statements, or reconciliation reports that can serve as corroborating evidence. The [EXAMPLES] placeholder should include one or two worked examples showing correct verification, discrepancy flagging, and unverifiable claim handling to calibrate the model's behavior. The [TOOLS] placeholder should specify any function definitions if you are using tool-calling to retrieve ledger data or documents programmatically rather than providing them inline. Before deploying this prompt in a production audit workflow, validate the output against a golden dataset of known claims with expected verification outcomes, and ensure a human review step is configured for all discrepant and unverifiable claims.

The Financial Audit Trail Verification prompt is designed to operate as a critical node within a larger audit application, not as a standalone chat interface. To integrate it, you must build a harness that manages the prompt's inputs, executes the model call, validates the structured output, and routes results to the appropriate downstream systems. The primary input is a structured payload containing the transaction-level claim, the relevant ledger entries, reconciliation statements, and any supporting document excerpts. This payload should be assembled by an upstream retrieval or data integration layer before being passed to the prompt. The harness must enforce that all required placeholders—[TRANSACTION_CLAIM], [LEDGER_ENTRIES], [RECONCILIATION_DATA], and [SUPPORTING_DOCUMENTS]—are populated with non-null, validated data; an empty or malformed input should cause the harness to abort the call and log a data-preparation error, not pass a broken prompt to the model.

After the model returns a response, the harness must immediately validate the output against the expected [OUTPUT_SCHEMA], which is a JSON object containing an evidence_chain array, a discrepancy_flags array, and a sampling_recommendation object. Use a strict JSON Schema validator in your application code (e.g., ajv for JavaScript or pydantic for Python) to confirm the presence and types of all required fields. If validation fails, implement a retry loop with a maximum of two additional attempts, feeding the raw output and the specific validation error back into the model as a repair instruction. If the output is still invalid after three total attempts, the harness must log the failure, flag the transaction for immediate human review, and stop processing to prevent an unverified claim from entering the audit trail. For high-risk financial workflows, a human-in-the-loop review step is non-negotiable; the harness should automatically route any claim with a confidence_score below a configurable threshold (e.g., 0.85) or with discrepancy_flags containing a severity of high to a review queue.

Model choice and tool use are key architectural decisions. This prompt is optimized for models with strong reasoning and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, using their respective JSON mode or structured output features. Do not use a lightweight model for this task, as the cost of a missed financial discrepancy far outweighs the inference savings. The prompt is designed to work without external tools during the verification step, assuming all evidence is provided in the context. However, if your ledger data is too large to fit in a single context window, you must implement a retrieval-augmented generation (RAG) step before this prompt to fetch only the most relevant ledger entries and reconciliations. Log every prompt call, including the full input payload, the raw model response, the validation result, the retry count, and the final routing decision, to an immutable audit log. This log is your primary defense in demonstrating the rigor of your automated verification process to external auditors.