Paste the starter pack into ChatGPT, Gemini or Claude and ask for a finding. Compare it with what you got yesterday. It carries the finding, risk and control writers. The knowledge foundations, the reasoning loop, the self-review and the learning loop come with a key.
Copies to your clipboard. Paste it into ChatGPT, Gemini or Claude. Free, no account, no key.
Same prompt, same model
What changes when the harness is in the room.
Auditor promptDraft 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: Lack of Segregation of Duties in Supplier Payments
During Q3 testing, it was identified that 14 supplier payments totaling $482,000 were processed without the required second approval as stipulated by the payments policy. The approvers failed to follow the established procedure, citing that the approval queue was unavailable during that week.
Risk Rating: High
This represents a significant control weakness that could potentially lead to fraud, error, or misappropriation of funds. The $482,000 in payments may have been inappropriate and should be investigated further.
Recommendation: Management should reinforce the importance of dual approval with all approvers and consider disciplinary measures where appropriate. Additional training should be provided.
In summary, this finding highlights the critical importance of maintaining strong internal controls over the payments process at all times.
With AuditFellowissue-writerwith the harness
Observation Title: Supplier payments released without required second approval
Criteria: The payments policy requires that every supplier payment above the approval threshold carries two approvals before release. The workflow tool is the designated mechanism for capturing both.
Condition: During the audit period, payments were released with a single approval. When the approval queue became unavailable, the team pushed payments manually, and the manual path has no step where a second approver examines the payment before it leaves.
Business Impact:14 payments totaling $482,000 were released with one approval during Q3. The exposure is concentrated in one week, which matches the outage, and nothing prevents recurrence at any future outage.
Root Cause: The contingency path for queue outages was designed without the approval step. This is a design gap in the fallback process, not an execution failure by the approvers.
Recommendation: Define the outage procedure so that manual release requires the same two approvals, captured in a form that survives the outage. Owner: payments process owner. Target: before the next quarter close.
Assumptions: The approval threshold applies to all 14 payments; severity assumed medium pending the team scale.
Auditor promptHere 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 promptDesign 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-bicompany-mcp-financecompany-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.