Finance & Admin

AI Fraud Checks: Spotting Duplicate and Altered Invoices

Is the invoice in front of you a second copy of one you already paid, or is it the real invoice with one detail quietly changed? Those are different problems, and they need different checks. Duplicates are a matching problem. Alterations are a change-detection problem. Running only one check leaves the other door open.

Published 2026-10-30 · Last updated 2026-10-30

Two frauds, two different checks

Start with the duplicate. Duplicate detection, as described in Ramp’s accounts-payable guidance, works by scanning three fields on every incoming invoice: the invoice number, the vendor name, and the amount. If all three match an invoice already in the system, the new one is flagged before payment. Advanced AI tools go one step further and can catch manipulated duplicates — copies where a date has been altered or an invoice number changed to make the duplicate look new.

An altered invoice fails that test by design. The number may be genuinely new and the amount plausible; what changed is something around the invoice — the bank account the money should go to, the payment terms, or the vendor itself. That is why a second kind of tool builds what one industry roundup calls a behavioural fingerprint: a record of a business’s normal invoice and payment patterns, against which altered bank details, phantom vendors, and modified payment terms can be flagged in real time.

One documented case shows why both checks matter at once. A single scanned PDF contained two invoices: one was a duplicate, and the second carried a swapped bank account. A typical optical-character-recognition-to-spreadsheet workflow would have paid both. The duplicate needed matching. The swapped account needed comparison against supplier history. Neither check substitutes for the other.

The duplicate checklist: matching what repeats

Run these checks on every invoice, before approval:

1. Match the three core fields. Compare invoice number, vendor name, and amount against invoices already recorded. An exact match on all three is a stop, not a coincidence to wave through.
2. Look for near-matches, not only exact ones. Check the same vendor and amount with a slightly different invoice number or date — the pattern used by manipulated duplicates.
3. Match against the order. Purchase-order matching — two-way and three-way — is the check that catches overbilling, quantity mismatches, and pricing errors, because the invoice is compared with what was actually ordered and received.
4. Hold the payment while a flag is open. A duplicate flag resolved after money leaves is a recovery job; resolved before, it is a two-minute check.

The alteration checklist: noticing what changed

Alterations are checked against history, not against the invoice itself:

1. Compare bank details with supplier history. The checking workflow in the case above compares bank accounts against supplier history, and invoices against their orders, before anything is approved. Any account that differs from the one previously paid gets verified through a channel you already trust — never through contact details printed on the invoice in question.
2. Flag changes to payment terms. Modified payment terms are one of the patterns a behavioural-fingerprint system flags. A sudden change in terms on an otherwise routine invoice deserves the same pause as a new bank account.
3. Watch for vendors that do not fit the pattern. Phantom vendors — suppliers with no history in your records — are the other flag that pattern-based checking raises. Vendor verification, in the systems that offer it, runs as a continuous background check on supplier accounts rather than a one-time setup step.
4. Treat the two lists differently. A duplicate can usually be resolved inside your own records. An alteration flag should be resolved with the supplier, out of band, before payment.

Head to head: platform, pattern layer, or your own checks

The trade-off is discipline against cost. The manual version uses tools a small business already has, but it only works on the days someone actually runs it. The platform versions run on every invoice whether the day is busy or not — and charge accordingly.

The bank-detail rule that stops the expensive one

If only one rule survives from this page, make it this one: no payment ever goes to a bank account that differs from the account on record for that supplier until the change has been verified independently. Duplicates cost you one payment, recovered with effort. A payment sent to a swapped account is the loss the documented case was built around, and it is the hardest to reverse. Put the rule in writing, name who can approve an account change, and make the approval sit with someone other than the person who entered the invoice.

What success looks like: every invoice in a payment run has passed the three-field duplicate match, every supplier bank account in the run matches the account previously paid or carries a recorded independent verification, and every flag raised was cleared before — not after — the money moved.

When the volume justifies paying for a platform

Use this decision framework, in order. First, count: if a person can run both checklists on every invoice without a backlog forming, the manual workflow is the proportionate tool. Second, look at your misses: a duplicate that reached payment, or a bank-detail change nobody noticed, is evidence the manual check is failing at your volume. Third, look at pattern risk: if suppliers, terms, and bank details change often enough that history comparison is itself a chore, a pattern-based layer earns its place. Pay for automation when the check you skip is the expensive one — and keep the bank-detail rule in force either way, because it costs nothing and stops the worst case.

— Dex Carter, Tech Writer