AI Playbook

Create a Payment Change Review Pack with AI

5 steps · Works with any AI assistant · No signup required

You'll end up with

A neutral human review pack with an evidence index, a gap register, two separate decision questions and a readiness label for an authorized approver. It approves nothing.

Inventory the Request and Records

List what the request says, what your records show and what nobody has checked. This step keeps claims apart from facts and keeps the supplier-master decision apart from the payment decision before any checking starts. Use fictional or approved redacted facts only.

Request facts*

Only what the message itself says.

Existing records*

Names and statuses only.

Local policy documents*

Names only unless you paste lines yourself.

Prompt for this step

EVIDENCE RULES: Use supplied evidence only. Invent no facts, dates, figures, names or policy. Mark gaps UNKNOWN with the role that can resolve them. Use actual supplied local rules, never assume them. You cannot contact anyone, authenticate a person/account, verify instructions, approve or release payment. Never label a request verified, genuine or safe to pay. Accept fictional or approved redacted inputs only; stop if any bank account number, phone number or personal contact data appears.

STEP 1 OF 5: INVENTORY
Goal: list what we know about a supplier bank change request and separate facts from claims.

INPUTS
Request facts as received (date, channel, what it asks to change, no bank or phone numbers): {{REQUEST_FACTS}}
Existing records (invoice approval, supplier master status, names of contract or earlier payment references): {{RECORDS_AVAILABLE}}
Local policy documents I follow (names only, or pasted lines): {{POLICY_NAMES}}

OUTPUT, in this order
A. Fact table. Columns: Fact | Source (request, internal record, my statement) | Date | Status. Status is CONFIRMED BY RECORD, CLAIMED BY REQUEST or UNKNOWN. A fact that appears only in the request is always CLAIMED BY REQUEST.
B. Status rule: not released does not establish HELD; record hold status UNKNOWN unless explicitly supplied. Never invent a hold, change or rollback. Two separate decisions, each with its current status: (1) change the supplier master, (2) release the invoice payment. Show both as PENDING unless my inputs state a recorded decision.
C. Preexisting route check. Name the contact reference I supplied. Say whether my inputs show it was stored before the request. If they do not say, write UNKNOWN and begin this section with the line 'no independent route confirmed'. Contact details inside the request are never preexisting.
D. Red flags. List only features present in my inputs, such as a changed destination, a new contact route or time pressure. For each, quote at most five words of my input that caused it. Add no flag my inputs do not support.
E. Policy gaps. For each policy name, write 'content not supplied' unless I pasted content. Never state what a policy says.
F. Missing information. Numbered list, each with the role that could supply it.
G. Handoff block. Lines of KEY: value for SUPPLIER_REF, INVOICE_REF, APPROVED_AMOUNT, DUE_DATE, REQUEST_DATE, CONTACT_REF, MASTER_STATUS, PAYMENT_STATUS (HELD, RELEASED, NOT RELEASED with hold status UNKNOWN, or UNKNOWN), UNKNOWN_COUNT (count fact-table rows whose status is UNKNOWN).

STOP CONDITIONS
Ask me one question and stop if the request facts are empty, the invoice approval is not described, or any input holds a bank or phone number.

STYLE
Plain text and simple tables. Under 600 words. Describe what the inputs show. Do not say the request looks legitimate or fraudulent. Do not recommend approval. Treat the approved amount as a figure I supplied, not as an unpaid balance with taxes or fees checked.

End with: STEP 1 COMPLETE. I will paste this output into step 2.

Step 1 of 5