The first six audit prompts, in the previous post, were mostly about getting ready: reconciling, documenting, answering questions. These six are about testing. They're the procedures an auditor runs, written so that a controller can run them first, on the same data, and find the exceptions before the auditor does.
That order matters more than it sounds. An exception you find in March is a correction. The same exception found by the auditor in June is a finding, and findings have a way of becoming management letter points.
If you're new to the library, it's a set of 150 prompts for NetSuite finance work that I released in January. Each one is a structured system prompt that you paste into Claude or ChatGPT along with your NetSuite data, and it turns the model into a specific kind of analyst with a defined method, a required output, and rules about what it's not allowed to make up.
Control Documentation Generator
The model becomes an internal control specialist and produces the documentation set that a SOX program runs on: a process overview, a risk assessment, control descriptions with type, nature, frequency, and owner, a risk and control matrix, a segregation of duties matrix, IT general control dependencies, and a testing approach. It's built around the COSO framework and it's a framework prompt rather than a data prompt. Its value is in producing a complete, consistent set of documents in an afternoon instead of a quarter.
Cutoff Testing Analyzer
Cutoff is where period-end errors live. The model becomes an external auditor testing the period boundary: revenue, expenses, cash, inventory, accruals, and intercompany, each with its own query. Revenue cutoff looks at invoices and shipments around the period end and asks whether each was recognized in the right period. Expense cutoff does the same for bills and receipts. Late journal entries and subsequent-period reversals get their own queries, because a reversal in the first week of the new period is often an accrual that should never have been booked.
The error table is the useful part. Revenue recorded early is an overstatement and gets a proposed adjustment. Revenue recorded late is an understatement that's evaluated in the next period. Expense recorded late is an understatement of liabilities and gets a proposed adjustment. Each error carries its impact, and the deliverable quantifies the total.
Journal Entry Testing Tool
This is the prompt I'd point an auditor at first, because journal entries are where the interesting things hide. The model becomes an external auditor doing substantive testing. It profiles the whole population, entry counts, value distribution, who prepared them, when. Then it stratifies by risk using the indicators auditors use: period-end dates, after-hours creation, round amounts, inadequate descriptions, unusual account combinations such as revenue credited without cash or a receivable, and memo keywords like top-side, consolidation, and reclassification.
Five queries ship with it: population analysis, high-risk identification above a materiality you set, unusual account combinations, top-side and consolidation entries, and a preparer distribution. The output order is fixed, population summary, high-risk entries, sample selection, testing results and exceptions, supporting evidence, and recommendations. Every exception carries the evidence that produced it, and the prompt won't let the model declare an entry valid without the test that showed it.
Management Assertion Validator
Financial statements make five implicit claims about every balance: it exists, it's complete, the company has rights to it, it's valued correctly, and it's presented properly. This prompt tests them. Existence testing uses receivables confirmations; completeness looks at subsequent receipts; valuation checks inventory against net realizable value; rights and obligations verifies payables; accuracy tests revenue recognition. Existence and completeness are rated high risk by default, because fictitious assets and unrecorded liabilities are the two things auditors fear most. The deliverable maps each assertion to the evidence gathered and the exceptions found.
Reconciliation Documentation Writer
Where the reconciliation auditor in part one verifies a balance, this one writes it up. The model becomes a senior staff accountant and produces the reconciliation package: the type of reconciliation identified (bank, subledger to GL, intercompany, third-party confirmation, or balance-forward), each reconciling item classified as timing, error, or unexplained with its expected clearing date, a roll-forward, an aged items review, and sign-off lines. It's written to the standards auditors inspect against, which means the reviewer finds what they need where they expect it.
Transaction Sample Selector
The last prompt is about method. The model becomes an audit sampling specialist and designs the sample: statistical or non-statistical, random or systematic, monetary-unit sampling for overstatement risk, attribute sampling for controls. It determines sample size from confidence level, expected error, and tolerable error, stratifies so that high-value items are tested in full, documents the selection so it can be reproduced, and provides a results template. The point of documenting the method is that a sample nobody can reproduce is a sample nobody can rely on.
Who They're For
Controllers who'd rather find their own exceptions. Internal auditors building a repeatable program. And external auditors' clients, who can hand over a tested population instead of a raw one. All six are in the NetSuite AI Prompt Library, under Audit and Assurance.
Update, September 2026
I ran the Journal Entry Testing Tool prompt from this group against one of my NetSuite test accounts, with the queries executed through Chartstone and the analysis done by Claude, and formatted the report to one of my branding guidelines. Here's what it found.
The account has 88 posted journal entries, so the test covered all of them rather than a sample. Forty-eight of them share the memo "Beg Balance Entries", one per month per subsidiary for two years, each with 62 or 63 lines across about 50 accounts. Together they carry 96% of all journal debits in the account and credit $19.8 million to revenue, which is most of the revenue the account has ever recognized. All 48 were created on a single day, September 10, 2026, backdated by up to 709 days.
The report's point about that series is the one I'd want an auditor to make. A beginning balance is posted once. These recur monthly and carry a full income statement every time, so the description doesn't match the content. None of the keyword or account-combination screens caught it, because each entry touches bank, receivables, and payables along with the P&L. The population summary caught it, by reading the memos and counting. That's the difference between a checklist and a test.
The other forty entries produced the exceptions the indicators are built for. Three undescribed entries created between 20:57 and 21:14 on September 14 move $262,000 in round amounts between balance sheet accounts, and every indicator the prompt carries fires on them. Eight entries with the memo "Negative Cash Flow" move round amounts between cash and equity, all created within six minutes at 03:28 on a Saturday. Seventy-nine of the 88 entries have no preparer and none has an approval status, so segregation of duties can't be tested at all, which the report records as a failed test rather than skipping it. And two accruals are dated in October, after the run.
The report closes with a note I appreciated: the regularity of the beginning-balance series is consistent with a scripted history load into a demonstration account, in which case the finding is a documentation failure rather than a misstatement. The test can't tell the difference, and it says so, and hands the question to a person.
You can read the full report here: Journal Entry Testing. The names and numbers are test data.