This pilot prompt helps a finance operator prepare a callback sheet when a supplier email asks to change payment details. It prepares only. The AI cannot contact anyone, authenticate a supplier, approve a change or release payment. The sheet has seven headings and five open questions. It keeps the payment hold until authorized humans decide the supplier master change and the payment release as two separate decisions. Use fictional or approved redacted inputs only.
Prepare a Supplier Bank Change Callback
Prepares a callback sheet from supplied facts. It does not contact anyone, verify anything or approve payment.
Use fictional or approved redacted inputs only. Never paste bank numbers, phone numbers, personal contacts or client material into an AI tool.
You help a finance operator prepare, not decide. First ask me for the facts below, then use only what I supply; invent nothing; mark missing facts UNKNOWN. You cannot authenticate anyone, verify a bank instruction, approve or release payment, or contact anyone. Never say a request is verified or safe to pay. Output can be unreliable. I will use only fictional or approved redacted inputs; refuse bank account numbers, phone numbers or personal contacts.
Ask for: supplier reference; invoice reference and approved amount; due date; request date and channel; what the request asks to change; the stored contact reference (label only); checks done; master and payment status; the local policy I follow.
Status: preserve supplied CHANGED/RELEASED history; flag and escalate immediately. Never invent rollback, held or unchanged. Missing status: UNKNOWN; ask a human to check and hold as applicable. Continue only a supplied hold pending authorized decisions.
Then write one plain text sheet, under 400 words, with seven headings:
1 Hold status
2 Route: use only the stored contact reference, never details from the request. A route stored before the request is not enough: note who stored it, its provenance and current trust, or UNKNOWN.
3 Questions address the person reached about the request, not our internal records or policy. Write exactly five OPEN questions, each starting What, How or Which, none answerable yes or no, for example: What change, if any, did your team ask us to make? Use roles, not names. Never ask for a new destination, account number or personal data.
4 Note fields: time, role reached, reported statement, not reported.
5 Limits: a callback cannot prove identity or account ownership; a stored route may be stale.
6 Stop conditions: no answer, no stored route, unresolved route trust, supplier denial, unclear policy. Each escalates; any hold stays.
7 Approver questions: two separate human decisions, master change and payment release; is the route currently trusted under local policy?
Human check: a person confirms the route predates the request; the approver checks the sheet against local policy. Treat the draft as unverified.
What this prompt does
The prompt prepares a callback sheet when a supplier email asks for new payment details. It prepares only. The AI cannot contact anyone, authenticate a route, approve a master change or release payment.
Fictional example
Supplier S-14 has approved invoice INV-28 for USD480, due November 6. A November 1 email supplies a new phone number and asks for a changed destination. Contact reference VC-07 was stored before that email, but its provenance and currentness are unknown. No call has been made. The supplier master is unchanged, payment is held, and local policy is unknown. USD480 is the approved invoice amount, not a threshold or net balance.
Expected output
One plain text sheet under 400 words with seven headings: hold status, route, five open questions, note fields, limits, stop conditions and approver questions. It says the hold continues, marks policy and route trust as UNKNOWN, and never says verified or safe to pay. If your facts say the master was already changed or payment already released, it keeps that history and escalates immediately instead.
Human check
The caller confirms VC-07 predates the request, then checks who stored it, its provenance and current trust. A callback cannot prove identity or account ownership. The approver checks the sheet against local policy and makes two separate decisions: the master change and the payment release.
Sources
- Internal financial controls for charities (CC8), sections 4.2 and 6.4. Scope: England and Wales charities only; a general control reference, not your local policy.
- NCSC phishing guidance, second communication channel. Scope: UK cyber guidance; general organizational practice.
- AI guide for small businesses (NCSC New Zealand), overview page only. Scope: New Zealand small-business overview; it supports risk awareness. Our redaction rules and human checks are suggestions, not claims from that source.
Related guides
- Verify a Supplier Bank Change Before Payment
- Supplier Bank Change Verification Record
- Create a Payment Change Review Pack with AI
Use fictional or approved redacted inputs only.