For years, we heard stories about duplicate payments occurring when the payment was made by a wire transfer and then by check. While definitely a serious issue, it didn’t cause much concern because the number of wires was generally small and the dollar amounts so large that a duplicate payment stood out like a sore thumb. With the increased usage of p-cards in corporate environments, duplicate payments because of multiple-payment vehicles have suddenly become an issue deserving the attention of everyone involved in the payment world.

How Serious Is the Problem?

A recent survey on duplicate payment conducted by Accounts Payable Now & Tomorrow, asked its readers if they had noticed an increase in duplicate payments due to use of different payment vehicles, i.e. a check and a p-card or ACH, or wire. Surprisingly, one out of two (53%) answered yes. While this number is startling in and of itself, we believe it actually understates the problem.

A number of respondents indicated they “were not aware of such a problem.” While some may be lucky because the problem doesn’t exist in their organization, this is not true in most companies in which the problem is hidden and has yet to be discovered.

And, of course, those who haven’t uncovered an existing problem cannot report it. What’s more, as you will see below, a number of the respondents indicated using controls that do not work or only partially addresses the problem. As organizations continue to move away from paper checks, the problem will get worse unless appropriate action is taken and proper controls put in place.
 
Absolute Best Control

The best way to make sure that duplicate payments aren’t initiated by using duplicate payment vehicles is to pay each vendor with only one vehicle. Organizations that take this approach often include this designation in their master vendor file. However for many of our readers, this solution is not always practical. Either the dollar limits on their p-card program or the necessities of their business operation make the one payment vehicle rule impossible to enforce or use.

By the way, should you be able to use the one payment vehicle per supplier rule, do not be lulled into a false sense of security that you have your potential duplicate payment issue under control. There are many other things you’ll need to do before you can rest easy on that front.

Controls That Don’t Always Work

Many of the survey respondents acknowledge that they haven’t addressed the issue of duplicate payments through multi-payment vehicles. Others noted the controls used in their companies were not foolproof.

Here’s look at why some controls don’t work:

1. Do nothing. We don’t really need to discuss why this doesn’t help, do we?
2. Relying on the “system” to reject duplicate invoice numbers. This assumes that the invoice number is entered correctly both times. Even if it is entered correctly the second time, many processors will simply add a blank space or a period at the end of the invoice number to force the invoice through. Experience has shown that this is not an effective duplicate payment control.
3. Approval by purchaser. One would think this would work, but sadly it doesn’t. “Our biggest problem is due to payments made on the p-card and still receiving invoices approved and coded,” wrote one respondent.
4. Relying on human memory or manual checking. While many accounts payable processors do an excellent job, depending on them to find all duplicate payments is beyond what any reasonable person should expect.
   
   As one professional who relies on this approach recently wrote me “Now that I type that out, it doesn't seem like the smartest solitary tool.”
5. Vendor notification. Vendors rarely return duplicate payments. There is no reason to believe their behavior will change if they are paid using two different payment vehicles.

Other Strategies

Preventing duplicate payments due to the use of multiple-payment vehicles is reliant on the general set of best practices used to stop the duplicates in addition to some specialized checking. Strong master vendor file controls, coding standards and appropriate segregation of duties are still the foundation of any program designed to make only appropriate payments and only once.