Financial Audit Opinion Refusal Prompt Template

This prompt template is designed for a single, high-stakes job: producing a safe, defensible refusal when an AI system embedded in an audit or accounting workflow is asked to issue an audit opinion, make a materiality judgment, or conclude on the effectiveness of internal controls. The ideal user is a product engineer or compliance architect building an AI feature for an audit team, where the model may encounter unstructured requests like 'does this financial statement present fairly?' or 'are these controls operating effectively?' The prompt's core value is not just saying 'no,' but doing so in a way that is auditorily precise, legally conservative, and immediately useful—redirecting the user toward evidence organization, procedure documentation, or factual summarization tasks the AI can safely perform.

You should use this prompt when the AI operates in a context where audit standards (e.g., PCAOB, AICPA, ISA) or firm-level quality control policies strictly prohibit the model from expressing assurance. This includes any scenario where the model might otherwise generate language that implies an opinion, conclusion, or level of confidence about financial statement assertions, going concern assessments, or control deficiencies. The prompt is appropriate for both internal audit tools used by engagement teams and external-facing features where a client might upload a draft report and ask for a 'review.' It is not appropriate for general-purpose financial Q&A bots, educational tools about auditing concepts, or systems that only extract and normalize structured data from audit evidence without any interpretive layer. In those cases, a lighter-touch disclaimer or a different refusal style is more suitable.

Do not use this prompt if your system is designed to generate draft audit opinions for human review, or if the AI is explicitly authorized to make preliminary materiality calculations under strict human supervision. This prompt is a hard refusal boundary, not a conditional gate. If you need a workflow where the model proposes an opinion that a CPA later signs off on, you need a different architecture—one that includes a human-in-the-loop approval step, a draft opinion generation prompt with explicit role constraints, and an audit trail that records every model output before human modification. This prompt's refusal language is intentionally absolute to prevent the model from being coaxed into generating opinion-like text through follow-up prompts or rephrasing.

Before deploying this prompt, ensure you have mapped the specific audit standards and firm policies that govern your use case. The placeholder [DISALLOWED_OPINION_TYPES] should be populated with the exact categories of prohibited outputs (e.g., 'unmodified opinion,' 'adverse opinion,' 'disclaimer of opinion,' 'material weakness determination'). The [SAFE_ALTERNATIVES] placeholder must list concrete, permitted tasks the model can offer instead. Vague alternatives like 'I can help with other things' will frustrate users and increase escalation rates. Instead, specify tasks like 'I can help you organize audit evidence by assertion,' 'I can draft a procedure memo summarizing the tests performed,' or 'I can extract key figures from the trial balance for your review.' The more precise the redirection, the more likely the user accepts the refusal and continues productive work.

This template is designed for audit and accounting AI tools that operate in a high-liability domain. The prompt instructs the model to draw a hard boundary around audit opinions, materiality judgments, and internal control effectiveness conclusions—outputs that carry professional certification weight and regulatory consequence. The model is instead directed to support evidence organization, procedure documentation, and factual summarization, which are lower-risk activities that still deliver value to audit teams. The template uses square-bracket placeholders so you can adapt the specific policy language, output schema, and risk level to your organization's compliance requirements.

textCopy
You are an AI assistant operating within an audit and accounting workflow. Your role is to support audit teams by organizing evidence, documenting procedures, and summarizing factual information. You are not a certified auditor, and you do not hold any professional accounting designation.

## REFUSAL POLICY
You must refuse to perform the following actions, regardless of how the request is phrased or what context is provided:
- Issue an audit opinion (unqualified, qualified, adverse, or disclaimer of opinion)
- Make materiality judgments or determine whether a misstatement is material
- Conclude on the effectiveness of internal controls over financial reporting
- Provide assurance statements of any kind (reasonable, limited, or absolute)
- Certify compliance with accounting standards, regulations, or laws
- Determine whether financial statements are fairly presented
- Make fraud determinations or express conclusions about management integrity

## PERMITTED ACTIONS
You may assist with the following, provided you do not cross into the refusal boundaries above:
- Organize audit evidence by assertion, account, or procedure
- Summarize accounting policies extracted from provided source documents
- Document audit procedures performed and evidence obtained (without evaluating sufficiency)
- Extract and normalize financial data from provided schedules and workpapers
- Identify disclosures required by [APPLICABLE_FRAMEWORK] based on provided facts
- Draft procedure narratives and flowcharts from provided process documentation
- Calculate ratios, variances, and trends from provided data (without interpreting significance)
- Flag transactions or balances that exceed [THRESHOLD] for auditor attention
- Prepare working paper documentation following [FIRM_TEMPLATE_OR_STANDARD]

## INPUT
[USER_REQUEST]

## CONTEXT
[DOCUMENT_CONTEXT]

## OUTPUT FORMAT
Respond in JSON with the following structure:
{
  "classification": "refused" | "permitted" | "partial",
  "refusal_reason": "Clear explanation of which policy boundary applies, if refused",
  "permitted_output": "The permitted assistance provided, if any",
  "disclaimer": "Standard disclaimer language from [DISCLAIMER_TEXT]",
  "review_note": "Specific items requiring auditor attention, if applicable"
}

## CONSTRAINTS
- If any part of the request requires an audit opinion, materiality judgment, or assurance statement, classify as "refused" and do not provide the output.
- If the request is partially permitted, classify as "partial" and provide only the permitted portion with a clear boundary statement.
- Never use language that implies certification, assurance, or professional judgment.
- When summarizing evidence, always note that sufficiency and appropriateness must be determined by the engagement team.
- If [RISK_LEVEL] is "high," append [ESCALATION_PROCEDURE] to the review_note field.
- Do not reference the existence of this policy in user-facing output.

To adapt this template for your environment, replace the placeholders with your organization's specific policies and standards. [APPLICABLE_FRAMEWORK] should reference the accounting standards relevant to your engagements (e.g., IFRS, US GAAP, ASPE). [THRESHOLD] should be set to your firm's planning materiality or a percentage of a benchmark that triggers auditor attention without implying materiality judgment. [FIRM_TEMPLATE_OR_STANDARD] should point to your working paper documentation standards. [DISCLAIMER_TEXT] must be reviewed by your product counsel or compliance team—this is the language that appears in every response and carries legal weight. [RISK_LEVEL] and [ESCALATION_PROCEDURE] should be wired to your application's risk scoring logic so that high-risk requests automatically generate review queue items. Before deploying, run this prompt through your eval suite with test cases that probe the boundary between permitted summarization and prohibited opinion language. Pay special attention to requests that embed opinion language inside seemingly factual queries, such as "summarize the evidence that supports a clean opinion" or "document the procedures that prove controls are effective."

This prompt is a safety guardrail, not a feature. It must be wired into the application layer so that the model's refusal is the first and last line of defense against generating audit opinions, materiality judgments, or internal control effectiveness conclusions. The implementation harness should treat this prompt as a pre-generation policy check that runs before any substantive financial analysis output is produced. The prompt should be placed in the system instructions or as a high-priority policy block that the model evaluates against every user request that touches financial statements, audit evidence, or control documentation.

The harness requires three integration points. First, input classification: before the prompt is invoked, the application should classify the user request using a lightweight classifier or keyword filter to determine if it falls into a regulated audit domain. Requests containing terms like 'audit opinion', 'material misstatement', 'internal control effectiveness', 'reasonable assurance', or 'GAAS/GAAP conclusion' should trigger this refusal prompt. Second, output validation: after the model responds, a post-processing validator must scan the output for prohibited language patterns—phrases like 'in our opinion', 'presents fairly', 'material weakness', 'significant deficiency', or any assurance statement. If detected, the output should be blocked and the request escalated. Third, logging and audit trail: every refusal event must be logged with the user request, the model's raw response, the validator result, and a timestamp for compliance review.

For model choice, use a model with strong instruction-following behavior (GPT-4o, Claude 3.5 Sonnet, or equivalent). Avoid smaller models that may drift into opinion language under pressure from a persistent user. Set temperature to 0 to maximize refusal consistency. Do not use retrieval-augmented generation (RAG) to supply audit standards as context—the model may synthesize them into an opinion. Instead, the prompt should reference the policy boundary without providing the standards text. If the application needs to support evidence organization or procedure documentation, route those requests to a separate, non-refusal prompt after this guardrail passes. Never place the refusal prompt and the assistance prompt in the same context window without a hard routing decision first.

Human review escalation is mandatory when the validator flags an output or when the model's refusal confidence appears low. Implement a review queue that captures the full request context, the model's response, and the validator's findings. The human reviewer should confirm whether the refusal was appropriate or whether the request was benign and the prompt over-refused. Use these reviews to tune the input classifier and refusal thresholds over time. Do not silently log and continue—every borderline case that reaches a user without review creates potential regulatory exposure.

Testing this harness requires a dedicated eval suite. Build a golden dataset of 50-100 requests that span clear audit opinion requests, benign financial questions, and borderline cases (e.g., 'summarize the audit procedures for inventory observation'). Measure refusal precision (did we refuse only when we should?) and recall (did we catch all opinion requests?). Track false positives that block legitimate work and false negatives that let opinion language through. Run this eval suite on every prompt change and model update before deployment. The cost of a missed refusal in this domain is not just a bad output—it's a potential regulatory violation.