Preventing Duplicate and Fraudulent Payments With Matching Controls

To prevent duplicate payments, a three-way match is not enough on its own. A second copy of an invoice you already paid points at the same purchase order and the same receipt, so a match that checks each invoice in isolation approves it again. You need one of two things on top: a match that knows how much of each receipt has already been billed, or a separate duplicate check on vendor, invoice number and amount. Matching does close two other leaks cleanly, the bill for goods nobody ordered and the bill for more than arrived, and the controls work best together.

Why a duplicate passes the match

We tested this on the Invoice-PO-Receipt 3-Way Match's own sample AP run. Invoice INV-5001 bills 100 steel brackets and 500 mounting bolts, and both lines match their PO and receipt exactly. We added a second copy of INV-5001, and a third copy renumbered INV-5001A. All three passed every line check at a 100% match, which is the gap: the PO and the receipt are real. All three came back HOLD, because the engine also compares the invoices in a run with each other. It flags the same vendor and invoice number twice, and the same vendor, total and PO under two numbers. That comparison stops at the edge of the run. The engine does not remember what it approved last week, so a repeat that arrives in a later run passes these checks unless you include the earlier invoices in the input.

The fix inside the match is to feed it the receipt quantity that is still unbilled, not the total ever received. Once the first INV-5001 is paid, the open quantity on those receipt lines is zero. Run the repeat against that, and it fails the received-quantity check and comes back BLOCK PAYMENT. Some accounting systems track billed quantity against each receipt, so check whether yours does. If it exports only total received, you have to subtract what was already billed yourself, and that subtraction is easy to get wrong.

What a duplicate check looks at

The second layer compares each new invoice with invoices already entered or paid. An exact repeat of vendor, invoice number and amount is the easy case. The near-misses cause the trouble:

• Reformatted numbers. INV-5001, INV5001 and 5001 are one invoice entered three ways. Strip punctuation and prefixes before comparing.
• Same vendor, same amount, new number. A vendor reissues an invoice under a new number, or sends a "past due" notice that gets keyed as a fresh bill. Flag the same vendor and amount within a short window for a person to compare.
• Two inboxes. The same invoice arrives by email and by post, and two people enter it. A shared entry queue removes the second copy before it exists.

We will not quote an industry duplicate-payment rate. A figure from other companies' books tells you nothing about yours. Your own number takes one export: pull 12 months of payments and sort by vendor and amount. Every pair that sits close together is worth a second look.

The two leaks matching does close

1. Invoices with no purchase order. In the same sample run, "Ghost Vendor Inc" bills a $2,500 consulting fee against PO-999, which does not exist. It has no PO and no receipt, fails six of the seven checks and comes back BLOCK PAYMENT.
2. Bills for more than arrived. "Label Works LLC" bills 200 label rolls against a receipt for 150. Every other check passes, so the match score is 86%, and it is still BLOCK PAYMENT, because one over-bill decides it.

The controls that make it hold

• PO enforcement. An invoice without an approved PO goes down a separate, stricter approval path. Otherwise the match is easy to dodge by never raising a PO.
• Duplicate detection. Every new invoice is checked against what has already been entered and paid, on vendor, normalized invoice number and amount.
• Separation of duties. The person who approves a payment is not the person who can create a PO, log a receipt or add a vendor.
• Payment-detail change control. A change to a vendor's bank account is confirmed through a known contact before the next payment.

Each of these produces flags, and someone has to work them, or the controls exist only on paper. Software can run the match and the duplicate check on every invoice. It should not decide whether a flag is fraud or an honest mistake, as our post on where a human must still sign off explains.

Pairs well with

A duplicate check is only as good as the invoice numbers it compares, so validate them first with the Document Field Validator ($79), which runs fixed format and required-field rules on every record. The Finance & Reporting Automation Kit ($129) catches what slips through at month end, when a tie-out reads Review or Does not reconcile. For a bookkeeper running AP alongside everything else, AI for the Bookkeeper ($39) includes a month-end review-and-flag checklist.