Forensic Ledger Discrepancy Audit Prompt Generator

What this generator does

A general "review my ledger" request produces general commentary. A forensic audit produces a findings table. The difference is the class list: professional exception-testing works from named discrepancy classes, each with a detection rule, and reports every hit with the evidence that supports it and the step that resolves it.

This generator builds that prompt for you. You supply a ledger, journal, or disbursement export; select the classes to test; set the two numbers that define your engagement — the approval threshold your organization uses for payments, and the materiality level below which findings are noted rather than escalated — and the generator produces a complete audit prompt with the detection rules, the figures firewall, and the findings-table format already embedded.

No dedicated prompt page exists for this job today: the ranking content is audit checklists, audit software, and prompt-engineering advice written for firms building their own tooling. This page is the tool itself, free, in your browser.

The six discrepancy classes

1. Duplicate payments. The same vendor paid the same amount twice — matching invoice numbers are the easy case; the valuable catch is the same amount, same vendor, different invoice references within a short window, which usually means an invoice was entered twice under a variant number. Duplicate disbursements are a classic recovery-audit target precisely because they survive ordinary review: each payment looks legitimate in isolation.

2. Split invoices. One purchase divided into two or more invoices, each below the approval threshold, so no single document ever triggers review. The detection signature is structural: same vendor, same day or adjacent days, amounts that sum to just over the threshold. Individually compliant, jointly a control bypass — whether deliberate or accidental, it belongs in the findings table.

3. Round-dollar amounts just below approval limits. Legitimate invoices rarely land on exact round numbers; manual entries do. A payment of $4,950 against a $5,000 approval limit deserves a question, and a pattern of them deserves several. The prompt tests for round amounts inside a band below your threshold and ranks them by proximity.

4. Missing or voided sequences. Invoice numbers, check numbers, and journal IDs are issued in sequence. Gaps in the sequence — a number never appearing, or appearing as voided without a matching explanation — are where deleted or suppressed documents hide. The prompt lists every gap in the supplied population instead of sampling over it.

5. Amount transpositions. Digits swapped during manual entry ($5,640 keyed as $5,460). The arithmetic signature is reliable: a transposition difference is always divisible by 9. The prompt checks recorded amounts against source amounts where both are supplied, and flags unexplained differences divisible by 9 as probable transpositions rather than generic errors.

6. Date anomalies. Entries posted on weekends or outside business hours, backdated entries, entries dated outside the period under review, and clusters of entries posted in the final hours of a period. Dates are metadata reviewers skim; the prompt treats them as evidence.

Who this is for

External and internal audit staff running exception tests over client or company ledgers; forensic accountants building a first-pass findings list before interviews; controllers and finance managers self-auditing disbursements before a formal audit; and bookkeepers asked to "take a look" at books kept by someone else — the situation where a structured class list matters most, because it keeps the review systematic instead of impressionistic.

How it works

1. Export the population. Pull the full ledger, journal, or disbursement listing for the period as CSV or a clean table. Completeness matters more than tidiness: the prompt includes a population check (count of records supplied vs. the count you state) so a truncated export is flagged, not silently audited as if complete.
2. Anonymize. Replace vendor and employee names with codes if the data is not yours to share. Amounts, dates, and document numbers are the evidence — names are not.
3. Set the engagement numbers. Approval threshold and materiality, from your organization's policy. These drive classes 2 and 3 and the severity ratings.
4. Generate and run. Paste the generated prompt and your data into your AI tool. For a full-population export that will not fit in one conversation, Gemini 4 Argon is the recommended model; Claude Sonnet 5.5 for standard populations.
5. Work the findings table. Every row carries a next step: documents to pull, people to ask, adjustments to propose. Findings marked INSUFFICIENT EVIDENCE are work orders, not conclusions.

THE PROMPT TEMPLATE

You are a forensic accounting analyst performing an exception audit over a supplied ledger population. You produce draft findings for review by a licensed CPA or the engagement lead. You are not issuing an audit opinion.

ENGAGEMENT CONTEXT:
- Framework: [US GAAP / IFRS]
- Entity: [entity type, names anonymized to codes]
- Period under review: [start date – end date]
- Approval threshold for payments: [amount, e.g. $5,000]
- Materiality threshold: [amount]
- Population: [record type — e.g. disbursements journal / general ledger extract / AP payment listing], [number of records you state are included], source: [export description]

LEDGER DATA:
[paste the full population here — document number, date posted, vendor/payee code, description, amount, entered-by if available]

INSTRUCTIONS:
1. COMPLETENESS CHECK FIRST. Count the records in the data supplied. If the count differs from the stated population, report the difference as Finding #1 and state which records may be missing. Do not proceed as if the population were complete.
2. Test the population for each discrepancy class below. A class with no hits must be reported as "No exceptions found" — never skipped silently.
   a. DUPLICATE PAYMENTS: same payee code and same amount more than once; flag separately any same-payee/same-amount pairs within 14 days regardless of invoice reference, and exact invoice-number repeats at any distance.
   b. SPLIT INVOICES: same payee, documents dated the same day or within 3 days, each individually below the approval threshold, summing to above it.
   c. ROUND-DOLLAR THRESHOLD AMOUNTS: round amounts (ending in 00 or 50) within 10% below the approval threshold.
   d. MISSING / VOIDED SEQUENCES: gaps in document-number sequences within the population; voided documents with no replacement document in the data.
   e. AMOUNT TRANSPOSITIONS: where a source amount and a recorded amount are both supplied and differ, test whether the difference is divisible by 9; flag matches as probable transpositions.
   f. DATE ANOMALIES: entries posted on weekends, entries dated outside the period under review, entries whose posting date precedes their document date, and clusters of entries posted on the final day of the period.
3. For every exception, cite the exact records involved — document numbers, dates, amounts — copied from the data. Evidence means the records themselves, quoted accurately.
4. Rate severity: HIGH (control bypass or potential loss), MEDIUM (error pattern or unresolved gap), LOW (isolated anomaly above materiality). Exceptions below materiality are listed in a separate count only.
5. End with a reconciliation statement: total value of the population as supplied, total value of flagged exceptions, and the count of records tested per class.

NEGATIVE CONSTRAINTS:
- Never invent, estimate, or adjust a figure. If a value needed for a test is absent from the data, mark the affected test INSUFFICIENT EVIDENCE and state what is missing.
- Never resolve a discrepancy by assumption. Do not write "likely a data-entry error" unless the transposition test (2e) supports it, and even then label it probable, not proven.
- Do not accuse any person of fraud or misconduct. Report patterns and records; intent is a human determination.
- Do not cite approval policies, thresholds, or rules that were not supplied in the engagement context.
- If the data supplied contains no exceptions for a class, say so plainly. An empty finding is a valid result.

OUTPUT FORMAT:
Findings table with exactly these columns: # | Entry (document no. + date) | Class | Amount | Evidence (records quoted) | Severity | Next step.
Then: classes with no exceptions (list), the completeness-check result, and the reconciliation statement.

Best model: Claude Sonnet 5.5 for standard populations (constraint discipline across all six tests); Gemini 4 Argon when the full-population export is very large.

ONE WORKED EXAMPLE

Sample data (invented for this example): a 10-line disbursement extract, approval threshold $5,000, materiality $250, vendor names already coded.

Filled-in prompt: the template above, engagement context completed (US GAAP, period Mar 1–31, threshold $5,000, materiality $250, stated population 10 records), the table pasted as the ledger data.

Output excerpt:

Three planted patterns, five findings — including the sequence gap (INV-1048) that nobody planted a label on, caught by the completeness check rather than by sampling. That is the argument for testing the full population against named classes instead of asking for a general review.

GUARDRAILS

• Flag, don't fill. The prompt forbids inventing or estimating any figure. Where a test cannot be run on the data supplied, the output must say INSUFFICIENT EVIDENCE and name what is missing — an unresolved state, not a conclusion dressed up as one.
• Totals reconcile or get reported. The reconciliation statement must tie to the supplied population. If the model's own totals do not tie, that difference is a finding about the run, and the run should be repeated — never adjusted into agreement.
• Patterns are not people. Findings describe records and control weaknesses. They are not accusations, and they do not establish intent, fraud, or misconduct; those determinations belong to investigators and counsel.
• Draft workpaper, not an opinion. Output from this prompt is a starting findings list for a qualified reviewer. It does not satisfy audit evidence standards on its own and must not be represented to a client, regulator, or court as an audit conclusion.
• Anonymize before you paste. Vendor, employee, and client names become codes; bank details never go in at all. And on this page, privacy is structural: the generator runs 100% in your browser — the thresholds and data you enter never leave your device. What you paste into an AI tool afterwards is your firm's policy decision, so make it deliberately.

INTERNAL LINKS

• Accounting & Tax hub — AI Prompts for Accountants
• Schedule C Expense Categorization Prompt Generator
• Finance & Accounting AI workflow guide
• PromptStaging Prompt Generator (all professions)
• AI Cost Calculator

---