Free starter pack

Try it yourself. Now.

Paste the starter pack into ChatGPT, Claude or Gemini and ask for a finding. Compare it with what you got yesterday. It carries three writers: findings, risks and controls. The knowledge foundations, the testing procedures and workpapers, the memos, the self review and your team rules come with an account, and they load on their own from the app you already use.

Same prompt, same model

What changes when the harness is in the room.

Auditor prompt Draft the finding: during Q3 testing we found 14 supplier payments totaling $482,000 that were released without the second approval required by the payments policy. The approvers say the queue was down that week and payments were pushed manually.

Bare modelno methodology

Finding: Supplier Payments Released Without Required Second Approval

Rating: High

Condition
During Q3 testing, 14 supplier payments totaling $482,000 were identified as having been released without the second-approver sign-off required by the Payments Policy.

Cause
The approval queue was unavailable during the affected week. Approvers stated that, in response, payments were pushed through manually to avoid processing delays.

Recommendation
1. Establish and document a formal manual approval procedure.
2. Require incidents of queue downtime to be logged and escalated.
3. Perform a retrospective review of the 14 identified payments.
4. Reinforce policy awareness with approvers regarding the non-negotiable nature of the dual-approval requirement.

Management Response: [to be completed]
Target Remediation Date: [to be completed]

Let me know if you'd like this adjusted for a specific audit template, tagged with a control ID, or if you want the retrospective review scoped out as a follow-up action item.

With AuditFellowissue-writer

Observation Title: Supplier payments released without required second approval

Criteria
Supplier payment processing requires every payment to receive a second, independent approval before release, so that no single individual or approval path can release a payment unchecked. The requirement was stated in the request; no policy clause or standard was provided for it.

Condition
As part of the internal audit review, we observed that 14 supplier payments were released during the third quarter without the second approval the payments policy requires. The total number of payments tested and the population from which these 14 were identified were not provided.

Business Impact
14 supplier payments totaling $482,000 were released during the third quarter without the segregation of duties the second approval control provides. This exposes the organization to erroneous, duplicate or unauthorized payments within that population that a second approver could otherwise have identified before release.

Risk Level: N/A

Root Cause
The approval queue used for the second approval step was unavailable during the affected week, and payments were pushed through manually without an equivalent compensating approval control in place.

Recommendation
1. Obtain evidence of retrospective secondary review for each of the 14 payments identified.
2. Establish a documented manual compensating control, a designated backup approver and a manual sign-off log, to apply whenever the approval queue is unavailable.
3. Implement monitoring and alerting for approval queue outages so that any manual workaround is identified and approved in advance.

Owner: N/A Target date: N/A Priority: N/A Effort: N/A

Assumptions
Risk Level, Owner, Target date, Priority and Effort were not provided in the request and are recorded as N/A.

Auditor prompt Here is the audit memo for the payments platform migration. Suggest the top 3 cybersecurity controls we should test in this audit. audit-memo-payments-migration.pdf

Bare modelmemo uploaded to the model as-is

Based on the memo, here are the top 3 cybersecurity controls to test:

1. Multi-Factor Authentication (MFA)
   Ensure MFA is enabled for all users accessing the payments platform to prevent unauthorized access.

2. Patch Management
   Verify that all systems are kept up to date with the latest security patches to mitigate known vulnerabilities.

3. Network Segmentation and Firewalls
   Confirm that the payments environment is properly segmented from the rest of the network and protected by firewalls.

These controls are fundamental to any secure payments environment and should be prioritized in your audit. Let me know if you'd like me to expand on any of them!

With AuditFellowcybersecurity knowledgescoped to the memo

1. Privileged access over production data stores during the migration
Why here: migrations grant broad temporary access, and temporary is the word that gets forgotten. Risk: unauthorised access to payment data persisting after cutover, driven by migration accounts never being revoked. Ask for: the list of accounts granted for the migration, who approved each, and evidence of revocation after cutover that the owner could not edit.
2. Change management over migration deployments
Why here: the memo shows code and configuration moving to production weekly during the window. Risk: unauthorised or untested changes reaching the payment flow, driven by emergency changes bypassing review under deadline pressure. Ask for: the deployment log reconciled against approved changes, and the disposition of every emergency change.
3. Controls over the replicated payment data
Why here: a migration always creates a second copy. Risk: exposure of payment data through the legacy copy, driven by the old platform outliving its controls once attention moves to the new one. Ask for: encryption and access evidence for both copies, and the decommission plan with a date.

Auditor prompt Design an analytic test for duplicate supplier payments across our two entities for FY25, and run it against the extract I loaded.

Bare modeldesigns, doesn't run

Here's a suggested approach for a duplicate payments analytic:

Step 1: Gather the supplier payment data from both entities for FY25.

Step 2: Look for payments with the same supplier and the same or very similar amounts.

Step 3: Review invoice numbers for matches or near-matches (e.g. INV-001 vs INV001).

Step 4: Flag any suspicious pairs for manual review by the audit team.

I'm not able to run this against your data directly, but you could implement it in Excel using a pivot table or in Python with pandas. Would you like me to write the pandas code?

With AuditFellowanalytics-test-designerfull populationre-runnable

Tools used: company-mcp-query-bi company-mcp-finance company-mcp-workpapers ,  discovered in the session, queries run inside your environment.
Objective: address the risk of duplicate supplier payments by testing the full FY25 payment population across both entities.
Population: all supplier payments, both entities, FY25. Completeness check first: 1,248,310 records, control total reconciled against the ledger. Pass.
Test logic: normalise supplier id, invoice number and amount; match across entities and within entity on the normalised key; flag pairs paid within 30 days of each other.
Exception rule: same normalised invoice and amount, different payment id. No judgment words: a different auditor rerunning this gets the same list.
Result: 37 exception pairs. Disposition: 29 legitimate (credit and rebill), 8 confirmed duplicates totaling $214,600, concentrated in one shared supplier paid by both entities.
Next step suggested: draft the finding with the issue writer. The duplicate concentration in cross-entity suppliers is the condition; the missing cross-entity match in the payment run is the gap.
Workpaper generatedWP-DA-07 Duplicate supplier payments FY25.docx

Auditor prompt Write a finding: campaign spend under $5,000 in the marketing team has no secondary approval. The CFO set that threshold in the 2025 delegation of authority policy, section 3.4, and the audit committee was informed of it in the March 2025 meeting minutes.

Bare modelwrites it up anyway

Finding: Campaign Spend Below $5,000 Threshold Lacks Secondary Approval

Condition
Marketing team campaign spend under $5,000 is processed with single-approver sign-off only.

Criteria
The 2025 Delegation of Authority Policy, Section 3.4, establishes $5,000 as the threshold below which single-approver authority applies.

Effect / Risk
Split transactions could evade the secondary-approval tier entirely. Single-approver spend has no independent check for duplicate payments or vendor legitimacy.

Recommendation
1. Confirm this control design reflects deliberate risk acceptance.
2. Implement a detective control: periodic review of aggregate sub-threshold spend.
3. Consider a system-enforced cap on same-vendor transactions within a rolling period.

Want me to adjust the severity, add a specific owner and due date, or save this into a findings log file?

With AuditFellowissue-writerno finding

The facts as given do not support a finding. The absence of a secondary approval below $5,000 is not a control gap: the CFO set that threshold in section 3.4 of the 2025 delegation of authority policy, and the audit committee was informed of it in the March 2025 minutes. The control is operating as designed, and the people accountable know the risk they carry.

There is no Criteria against Condition mismatch to write up, so no finding is produced.

What would change this conclusion
1. Evidence that spend is being split to stay under $5,000.
2. Evidence that the threshold is outdated against the risk the category now carries.
3. Spend above the threshold released without the second approval.

Tell me which of these applies and the finding gets written from that gap instead.