Prompt templates for triaging a pile of invoices without missing the one that matters

Background

Invoice fraud and simple billing errors both hide the same way: inside a pile of otherwise-normal invoices, as the one line that's slightly off from what you'd expect - a changed bank account, a supplier billing twice for the same delivery under a different reference, a price that's crept up 30% since last quarter with nobody noticing because each individual invoice looked fine on its own.

A person skimming forty invoices at the end of the month is bad at catching this, not because they're careless, but because skimming for "does this look roughly right" is exactly the wrong cognitive mode for catching a small, deliberate deviation - it's tuned to catch big obvious errors, not a five percent uplift that looks like normal variance. This is a genuinely good fit for an AI tool: comparing many similar things against a pattern and flagging outliers is what it's built for.

The risk runs the other way from most of these templates. Here the danger isn't the model inventing content in an otherwise-harmless document - it's a false negative: the model says "nothing unusual here" about a batch that does contain something wrong, and that confident all-clear gets treated as a real check when it wasn't one. The prompts below are built to make the model show its working and flag its own uncertainty, specifically so a false "all clear" is harder to produce by accident.

Setup

The shape every template below follows:

• Role - an accounts payable reviewer looking for deviations, not a bookkeeper reconciling totals.
• Context - what "normal" looks like for this supplier or category, so there's a baseline to compare against.
• Inputs - the actual invoice data and, where you have it, the history to compare it to.
• Task - specific things to check, not a vague "does this look ok".
• Constraints - force explicit uncertainty rather than a false all-clear, and never let the model be the final decision-maker on payment.

The single-supplier check

For "does this invoice match what I'd expect from this supplier":

You're checking one invoice against this supplier's normal pattern for
anything that deviates.

Inputs:
- Supplier name and this invoice's details (amount, date, line items,
  bank details if you have them to compare): [PASTE]
- Their last 3-6 invoices for comparison, same detail level: [PASTE OR
  SUMMARISE]
- Anything you already know changed recently (a new contract, a price
  renegotiation): [DESCRIBE OR "NOTHING KNOWN"]

Task: compare this invoice against the historical pattern on price per
unit, total amount, invoice frequency, and bank/payment details. List
anything that's different, by how much, and whether that difference is
explained by what I told you changed.

Constraints: for anything unexplained, say so explicitly rather than
assuming it's fine - "unexplained: bank details differ from the last
three invoices" is a useful flag even if it turns out to be an innocent
change. Never conclude "nothing unusual" without listing what you actually
compared, so I can see you checked the things that matter, not just the
total.

The batch scan for duplicates and near-duplicates

For catching the same cost billed twice under slightly different details - a genuine duplicate, or a supplier double-billing:

You're scanning a batch of invoices for duplicate or near-duplicate
charges - the same underlying cost billed more than once.

Inputs: [PASTE THE BATCH - SUPPLIER, DATE, AMOUNT, REFERENCE, DESCRIPTION
FOR EACH LINE]

Task: group anything that could be the same underlying charge - same
supplier and amount with a different reference, same amount and date from
different-but-similarly-named suppliers, or a description that overlaps
closely with another invoice in the batch. Rank the groups by how likely
they are to be a genuine duplicate versus a coincidence, and say why.

Constraints: don't just match on exact amount - a duplicate billed a week
apart, or split into two invoices to look different, is the pattern worth
catching, not the easy exact match. Explicitly list anything you considered
and ruled out, not just what you flagged.

The bank-detail-change red flag

For the single highest-value check in accounts payable - a changed bank account is the classic fraud vector, and it deserves its own dedicated pass rather than being one line among many:

You're specifically checking whether payment details have changed from
this supplier's established pattern - this is the check that matters most
for fraud, treat it as such.

Inputs:
- This invoice's payment/bank details: [PASTE]
- The bank details used on their last several invoices or in your supplier
  master record: [PASTE]
- Any known reason for a change (supplier told you directly, in writing,
  through a channel you didn't just get from this invoice): [DESCRIBE OR
  "NO KNOWN REASON"]

Task: state plainly whether the bank details match, and if not, exactly
what changed. If there's no known, independently-verified reason for a
change, say explicitly that this should be verified by phone on a number
you already have on file - not a number provided on the invoice itself -
before anything is paid.

Constraints: this check never results in "probably fine, pay it" from the
model - a changed bank account with no independently verified reason is
always a hold-and-verify, full stop.