Duplicate and fraud detection

The useful output of duplicate and fraud detection is a payment hold with a specific cite, or an empty exception list. If the invoice is a duplicate of one already in the ledger, the hold names that invoice. If the bank account on the remittance does not match the vendor master, the hold names the field and both values. If the pattern looks like vendor impersonation (new banking details, rushed urgent-payment language, a near-match legal name), the hold names the pattern. If none of those fire, the quality outcome stays empty. The payment continues.

AP still releases the payment. Detection does not become a silent block, and it does not become a fraud-rate dashboard. A percentage of caught fraud is not the outcome. The outcome is a cited hold a payments lead can act on, or a clean run.

This sits after extracted invoice fields from invoice OCR and extraction, and before the payment file is built. It is not a substitute for three-way match agent. Match answers whether goods or services were received against PO and receipt. Duplicate and fraud detection answers whether this payee and this invoice should be paid at all.

Tools in this class, AppZen, Trustpair, and the controls inside Workday and SAP payment runs, compare documents, master data, and payment instructions. They raise exceptions. They do not own the release.

Run the comparison on the payment candidate, not on a screenshot of the PDF. Use the invoice number, vendor identifier, amount, currency, remittance account, and legal name, the same fields AP would type into the ERP.

Check duplicates against open and recently paid invoices for the same vendor, and against near-duplicates: same amount and date with a mutated invoice number, same invoice number with a different vendor code. Check bank details against the vendor master, not against last month's payment file. Last month's file can already be wrong if an earlier impersonation succeeded. Strip spaces from IBANs and uppercase invoice numbers before you compare, so format drift does not look like a mismatch.

Check impersonation patterns as a bundle, not as a single score. Typical signals include a bank-detail change that skipped the vendor-master process, a contact email on a domain that is not the vendor's, an invoice outside the usual channel, and copy that pressures same-day payment. None of those alone is proof. Together they justify a hold with cites.

Do this before payment timing optimizer moves the item into an earlier or later batch. Timing should not accelerate a payment that still has an open duplicate or bank mismatch.

Workday and SAP already store vendor master and payment proposals. AppZen and Trustpair typically sit alongside that master data and the invoice image. The pattern is the same: read invoice fields, read vendor master, write an exception with field-level cites, leave release with AP.

A hold without a cite is a rumor. AP will either ignore it or spend a day reconstructing why it fired.

For a duplicate, cite the matching invoice number, vendor, amount, and date, and say whether the match is exact or near, for example INV-4419 versus INV-4419A. For a bank mismatch, cite the master account identifier, masked except last four, and the invoice remittance value. For impersonation, cite the pattern pieces: bank-detail change without an approved master-data ticket, display name off by one character from the master legal name, payment requested to a new country.

Point the reviewer at the vendor master record and the prior invoice, not at a model confidence number. Confidence can rank the queue. It is not what AP needs to decide.

If the check is clean, write nothing. Do not invent a low-risk badge that still lands in the exception inbox. Empty is the quality outcome for a clean payment.

The queue is for humans. A payments lead or AP clerk opens the hold, compares the cited records, and either clears the hold or stops the payment.

Clearing means the apparent duplicate is a legitimate second invoice (two shipments, two projects, a credit-and-rebill), the bank change was approved, or the impersonation pattern was a false read of a real domain. Stopping means the prior invoice already paid this amount, the bank details are wrong, or the vendor contact cannot confirm the request.

After the decision, AP releases in the ERP the same way they always do. The model does not auto-void. It does not change the vendor master. Master-data changes stay on the vendor-master path.

For example, a cleaning contractor invoices 12,400 on the first Tuesday of the month, same as the standing monthly invoice. The detector holds the payment and cites invoice 8841, posted nine days earlier, same vendor, same amount, invoice number 8841 versus 8841-REV. AP opens both. 8841-REV is a rebill after a credit memo that has not posted yet. They leave the hold until the credit posts, then release 8841-REV. No fraud percentage is recorded. The cite named the colliding invoice, so AP did not pay twice and did not bounce a real rebill without looking.

Holding a clean payment. Over-tight duplicate rules treat a second legitimate invoice in the same week as a clone. Over-tight bank rules hold every account number stored in a different format (spaces versus no spaces, IBAN versus local account plus sort code). Over-tight impersonation rules hold every new vendor. Each false hold delays a supplier and trains AP to click through the queue. If AP cannot see why two invoices collided, the match is too fuzzy. If AP keeps clearing the same format mismatch, normalize the field before you compare.

Paying past a duplicate. Rules that match only exact invoice numbers let INV-100, INV100, and INV-100-FINAL all pay. Rules that search only open invoices miss a duplicate of something paid last week. Rules that ignore amount-plus-date near-matches miss the classic resubmit. The failure is silent: the payment file looks clean because the exception list is empty. Empty is correct only when the comparison ran against paid history and normalized identifiers.

Inventing a fraud percent. Leadership will ask how much fraud you stopped. Duplicate detection mostly stops double-pay and bad bank details. Impersonation that never reached payment has no loss to count. If you publish a fraud rate, you either count every hold as fraud (overstated) or wait for confirmed loss (too late). Do not make that number the KPI. Measure cited holds that AP agrees with, time-to-review, and duplicate payments that still escaped.

Duplicate and fraud checks do not code the invoice. GL coding suggestion can still propose the account after the invoice is accepted as payable. A bad payee with a perfect GL code is still a bad payment.

They do not replace three-way match. A duplicate can match PO, receipt, and invoice if someone submitted the packet twice. Run match and duplicate detection as separate questions.

They should not fight payment timing. Once AP clears the hold or confirms the list is empty, timing can pull the item into the next run. If a hold is open, timing should skip it.

Keep vendor tools in one class. AppZen, Trustpair, Workday, and SAP may differ in screens and in how they ingest master data. The contract is the same: compare invoice to vendor master and payment history, hold with cites, let AP review, then pay. If a product cannot name the colliding invoice or the mismatched bank field, it is not producing the quality outcome.