Finance & AccountingFree
Duplicate Payment Detection and Anomaly Scan
Scored on vendor spelling and invoice shape, then ranked by what is still recoverable today rather than by what is largest.
River's duplicate payment scan reads your payment history and scores every pair that could be the same invoice paid twice, matching across vendor spellings and invoice formats rather than demanding they be identical. Then it does the part that decides whether you see the money again. It groups each confirmed duplicate by how it was paid and how long ago it settled. An ACH from Tuesday and a wire from March need two entirely different letters, sent to two different parties, and only one of them can be sent without permission.
Every product in this category dedups on vendor, invoice number and amount together, which is the one combination your AP system already blocks at entry. In a 41,882 payment history the scan found 31 real duplicates and exact matching would have caught 3 of them. The other 28 hid behind a second vendor record, an invoice number typed without its prefix, or an early-pay discount that made the amounts differ. Statements arrive as PDFs first, so bank statement conversion usually runs before this.
Written for the AP manager or controller who suspects it happened and cannot prove which one, and for the bookkeeper inheriting a year of somebody else's coding. It sits beside card statement matching for spend that never touches AP, and merchant settlement reconciliation where the money moves through a processor. The monthly control that should have caught all of it is the bank reconciliation pack, run every month rather than once a year when somebody notices.
The rail and the date decide what you can recover
Once a duplicate is confirmed, the recovery route is set by the payment rail and the clock, not by the amount. A duplicate ACH entry can be reversed, but the reversal has to reach the receiving institution within five banking days of the erroneous entry's settlement date. A check that has not been presented can be stopped, and that order holds for six months, lapsing after 14 calendar days if you only phoned it in. Past those windows you are asking, not instructing.
A wire is the hard case. After the receiving bank has accepted the payment order, canceling it is not effective unless that bank agrees or a funds transfer system rule allows it. The only realistic route left is the beneficiary's own consent. That inverts the usual ranking. Of Thornlow Building Supply's 487,300 dollars in confirmed duplicates, 75,700 was recoverable without asking anyone, and the single largest item, a 58,900 wire, was not part of it.
Sort that same list by amount and the two payments whose reversal window closes within two banking days sit third and ninth. They are worth 42,600, which is 56 percent of everything still recoverable unilaterally, and on an amount-sorted report they get read on Thursday. Of the 22 cases already past their window, 13 vendors carried an open balance large enough to net the duplicate off the next run. The other nine have to send money back.
How it works
Add the history
Any AP register, bank export or payment ledger, in whatever shape your system produced it.
Say what worries you
Which vendors, which period, and anything you have already checked so it is not rechecked.
River scores and routes
Candidates ranked by likelihood, then confirmed duplicates grouped by rail and by window remaining.
Send the letters
Reversal requests, stop payment orders and vendor demands come out drafted and ready to send.
What you get
- Candidate pairs scored on vendor similarity, invoice shape and date proximity, not exact equality
- Each confirmed duplicate routed by payment rail, with the window that is still open named
- The recovery letter itself, addressed to your bank or to the vendor as the rail requires
- Vendors carrying an open balance flagged for offset, which needs no refund from them
- Round-number flags restricted to vendors whose other payments are never round, keeping it short
- New vendors paid inside the week they were created, with the ones never paid again
Common questions
Why not just match on vendor, invoice and amount?
Because your AP system already refuses that combination at entry, so the duplicates that survive are the ones where a key differs. In the worked history, exact matching found three of 31. The other 28 turned on a second vendor record, an invoice number typed without its prefix, or an early-pay discount taken on one run and not the other.
Can we still get an ACH duplicate back?
If it is recent. A reversing entry for a duplicate has to be made available to the receiving institution within five banking days of the erroneous entry's settlement date, so the answer changes over a week. Past that there is no reversal, and it becomes a refund request or an offset against the vendor's next invoice.
What about a duplicate wire?
That is the one where the rules are against you. Once the receiving bank has accepted the payment order, cancellation is ineffective unless that bank agrees or a funds transfer system rule permits it. The letter goes to the beneficiary and asks, and the sheet says plainly that this one rests on goodwill rather than on a rule.
Does it write to the vendor or to the bank?
Whichever the rail requires, and it says which. An in-window ACH duplicate is a reversal request to your own originating bank and the vendor never hears about it. An unpresented check is a stop payment order. Everything past its window is a letter to the vendor, with the offset offered first because it settles faster.
Will a round-number flag light up half the ledger?
It would if applied flatly. In the worked history 1,204 payments of 41,882 were exact multiples of a thousand, which tells you nothing. Restricting the flag to vendors whose every other payment is not round leaves 38. Retainers and round contracts stop being noise once the vendor's own pattern is the baseline. Owner spending mixed into the ledger is a different pattern, covered by the owner draw review.
How do you handle a credit the vendor already issued?
It gets matched to the duplicate and taken off the recovery list, because chasing money you already hold is how these projects lose their credibility. An unapplied credit nobody nets off is its own finding, and an aging one eventually becomes a state unclaimed property question rather than a receivable.
Who should not be running this scan?
Anyone who can both create a vendor and release a payment run, because a scan is evidence and evidence should not be handled by the party it might implicate. The segregation of duties review shows whether that combination exists in your system before this becomes an awkward conversation.
Duplicate Payment Detection and Anomaly Scan
Fill in the form and your workspace opens with the work already underway.