Catch duplicate invoices and bank-detail changes before payment
Before each payment run, the system checks every invoice for duplicates and every vendor record for changed bank details. Suspicious items are held and sent to a named person for a call-back to a number already on file. A control for AP teams who want payment fraud and double payments stopped earlier.
Function: Finance · Industry: Any industry
Catch duplicate invoices and bank-detail changes before payment
6 steps
At a glance
- Trigger
- An invoice is approved for payment, or a vendor's bank details are edited.
- Typical inputs
- Approved invoice list for the payment run
- Vendor master with change history
- Past payments by vendor
- Verified contact details for each vendor
- Systems it usually connects to
- NetSuite
- QuickBooks
- Gmail
- Slack
- How the work splits
4 rules, 1 model, 1 person steps
How it runs, step by step
6 steps, each tagged by what does the work. Rules are fixed logic, a model reads or drafts, and a person decides.
- Rules Fixed logic in code
- Model AI reads or drafts, with a confidence score
- Person A named person decides
- 1
Check for exact duplicates
RulesVendor, invoice number, amount and date are compared against all prior invoices, including those already paid.
- 2
Check for near duplicates
ModelA model flags invoices that look the same with a changed number, a re-sent scan or a split amount.
- 3
Watch vendor record changes
RulesAny edit to bank account, remit-to address or contact email is logged with who changed it and when.
- 4
Hold the payment
RulesItems that fail a check are removed from the payment run automatically and cannot be added back without an override.
- 5
Verify by call-back
PersonA named person contacts the vendor on a phone number already on file, never one from the email that asked for the change.
- 6
Release or reject
RulesThe verification result is stored on the vendor record, and the held payment is released or canceled.
Where people approve
The decisions that stay with your team, whatever the confidence score says.
- Two people are needed to change vendor bank details, one to enter and one to verify.
- Only the finance controller can override a duplicate hold.
- Payments to a changed account wait for a completed call-back.
KPIs to track
What to measure, before and after. Targets come from your own baseline.
- 01Duplicate payments found after the fact (should trend to zero)
- 02Held payments and how long each waited
- 03Bank-detail changes verified before first payment
- 04False-positive rate of near-duplicate flags
Questions about this workflow
Does the model decide whether a bank change is fraud?
No. A model only helps spot near-duplicate invoices. Bank changes are handled by rules and a person: every change triggers the hold, and a human verifies it through a channel already on file.
Will this slow down the payment run?
Only for held items. Everything else is checked in seconds as the run is assembled. Teams tend to tune the near-duplicate threshold in the first month so the hold list stays short enough to read.
Which steps use rules, a model and a person?
Rules: check for exact duplicates; watch vendor record changes; hold the payment; release or reject. Model: check for near duplicates. Person: verify by call-back. Rules are fixed logic in code. A model reads or drafts and reports its confidence. A named person decides.
What do we need to start?
Typically: approved invoice list for the payment run; vendor master with change history; past payments by vendor; verified contact details for each vendor. You also need read access to NetSuite, QuickBooks, Gmail and Slack, or the equivalents you use. A workflow audit measures your volumes and past cases first, then gives a fixed price for the build, so you can decide with real numbers.