We paid the same vendor invoice twice — how do I find duplicate payments and get the money back?

How does one invoice end up paid twice?

A duplicate happens when two routes to payment are open for one obligation and nothing marks it settled after the first is used. Look for one of these patterns:

• Two instruments. A check goes out, and someone also pays online, by card or through the vendor's portal.
• A statement or reminder. The invoice is paid, then paid again from the vendor's statement or a past-due notice that still lists it.
• A repeated payment run. A batch is released twice, or one bill is picked up by two runs.
• A duplicated record. The bill was entered twice, or the vendor exists as two records and each carried the bill.

When the payments went through different channels, such as a check and a card charge, they never sit side by side in one register, so finding them means pulling every channel into one list.

Did money really leave twice, or is one payment recorded twice?

Start with the bank side. A duplicate payment shows two separate outflows on your bank or card statements, with two check numbers or two transfer or card references, both for the same invoice. A duplicated entry shows one outflow on the statement and two payments in the ledger, for example when a bank-feed transaction was added and a hand-entered payment was kept as well.

A duplicate payment is recovered from the vendor, and both payments stay in your books because both happened. A duplicated entry is corrected in the ledger and involves the vendor not at all; removing a bank transaction recorded twice is covered in the related question on duplicate bank transactions. Treating one as the other either breaks the bank reconciliation or abandons money you could recover.

Don't rely on the vendor account alone: a bill entered twice, a re-dated bill or a duplicated vendor record looks the same there with no money at stake.

How do I search for duplicates systematically?

Work from one combined list rather than from any single register:

1. Gather every channel. Export the payments from each bank account, each business card, any bill-pay or payment service and the payables ledger, all for the same dates. Cover a period that reaches back past your longest vendor payment terms plus one statement cycle. On each rerun, overlap the previous period instead of starting where it ended.
2. Use the same columns. Give every row the date, the payee as paid, the amount, the invoice or reference number, the channel and the bank's reference or check number. Rows from different exports that share a bank reference or check number are one payment. Merge them into one row, keeping the invoice number from the ledger or payment service, before you run the comparisons.
3. Clean the keys. Add one column with each vendor's name in a single spelling and another with each invoice number in a standard form, without spaces, hyphens or leading zeros and in one letter case.
4. Run the comparisons. Flag every row that matches another on one of the pairs in the table below.
5. Test each flag. Clear the look-alikes, then confirm what remains against the bank statement and the vendor's statement.

Each comparison catches a different cause:

In a spreadsheet, Excel's COUNTIFS function counts the number of times all criteria are met, according to Microsoft. With the cleaned vendor name in column B and the cleaned invoice number in column C, =COUNTIFS(B:B,B2,C:C,C2) copied down every row returns 2 or more wherever that vendor and invoice pair repeats. With amounts in column D, =COUNTIFS(B:B,B2,D:D,D2) runs the vendor-and-amount test.

Before treating a flag as a duplicate, clear it with these tests:

A flag survives only when one invoice, for one delivery or period, has two outflows on the statements.

A monthly statement of account from each regular vendor surfaces duplicates you haven't found: a credit balance, or a payment the vendor couldn't match to an invoice, is how its records show money you overpaid. Once you have a suspect, the same statement confirms which payments the vendor received and how it applied them.

When one duplicate turns up, run the routine over earlier periods too, and raise any others with the same vendor in one request.

What should I send the vendor?

Put the whole position on one page, with copies attached:

• The obligation. Give the invoice number, date and amount, and what it was for.
• The first payment. Give its date, amount, channel and reference, with the bank or card statement line.
• The second payment. Give the same details for the second outflow, with its statement line or cleared-check image.
• The resulting balance. Show your vendor account with the invoice settled once, and the due-from balance holding the extra amount owed back.
• The request. Ask for a refund, or for a credit and the invoices it should be applied to.

Ask the vendor to confirm in writing which it will do. If the vendor says it received only one payment, ask your bank, or the card issuer or payment service that sent it, where the second went before pressing further. If it reached a payee record or bank details that aren't the vendor's, it is a misdirected or possibly fraudulent payment, not a duplicate the vendor holds. Ask that institution at once whether it can be recalled, and handle it as a misdirected payment.

Can the second payment still be stopped?

If the second payment is a check that hasn't been cashed, or an electronic payment still scheduled or pending, contact your bank, or the card issuer or payment service that sent it, before you contact the vendor, and ask whether it can be stopped or recalled. The answer depends on the payment type and that institution's own terms. Reverse the second payment in your books only once the institution confirms it has been stopped, and tell the vendor not to expect it. If the payment has cleared, move on to recovery.

Should I ask for a refund or a credit, and what if the vendor won't pay?

The vendor's position decides the route:

A credit needs tracking until it is used up. Note on it which duplicate payment it came from, apply it only to that vendor's bills, and check each vendor statement until it shows as fully used. A credit applied to an unrelated bill without that note becomes untraceable, and one applied twice goes unnoticed.

In QuickBooks Online, Intuit's help page "Enter vendor credits and refunds in QuickBooks Online" (updated 9/15/2026) gives the vendor-credit method for businesses that track expenses using bills and plan to apply the credit to future payments. On the vendor credit, enter the due-from account as the category, not the original expense category or an item, and note on it the duplicate invoice and payment. This mirrors the Apr 2 entry below. The same page says QuickBooks automatically applies the available credit to the bill you select to pay, so check the credit applied before saving.

How do I carry the second payment until it's recovered?

Post it to a separate current-asset account, such as "Due from vendors – duplicate payments", with the vendor, invoice and payment reference in the memo. If it was coded to an expense account, reclassify it: debit the due-from account and credit that expense account for the amount.

Nothing was bought with the second payment, so it isn't a cost; what the business holds is an amount it expects the vendor to return. Left in expense, it overstates cost and nothing prompts anyone to chase it.

Don't delete or void the second payment while the bank shows it left. The books would then disagree with the bank statement, and you'd lose the record your claim depends on.

If your software has put the second payment inside the vendor's payable account, as an unapplied payment or a balance in your favor, move it to the due-from account before recording any outcome: debit due-from, credit accounts payable – vendor, with a memo naming the invoice and payment. The entries below assume it is there.

What entries record each outcome?

This example uses the accrual basis, with the invoice entered as a bill. Invoice 4471 for $2,400.00 of supplies is paid by check on March 5 and again by bank transfer from the vendor's statement on March 20:

If the payment is still uncategorized when you find the duplicate, post it straight to the due-from account. If it was applied to a second entry of the bill, reverse that entry's expense (debit accounts payable – vendor, credit supplies expense), which leaves a 2,400.00 debit in the vendor account. Then move that debit to the due-from account (debit due-from, credit accounts payable – vendor) and keep the payment itself.

Refund received. The vendor returns the money on April 10:

The refund clears the amount owed back; it is not income, and supplies expense stays at 2,400.00. In QuickBooks Online, Intuit's help page records a refund as a bank deposit coded to "the same Category/Account used for the original expense" where the purchase was recorded "as an expense or check (not a bill)". For "a refund check for a bill you have already paid" it gives a vendor credit followed by a deposit to Accounts Payable. For a duplicate carried in the due-from account, use that account wherever either method asks for the original expense or bill category. That substitution is an adaptation, not Intuit's instruction.

Credit issued and used. The vendor issues a credit on April 2, bill 4530 for $3,000.00 arrives on April 15, and you pay the $600.00 balance on April 30:

The credit moves the amount owed back into the vendor account, where it reduces the next bill. It is neither income nor a discount.

Written off. On June 30 you conclude the vendor won't pay:

This entry is a direct write-off, for a business that keeps no allowance for credit losses. FASB's ASU 2016-13, written for loans, trade receivables and other financial assets, says write-offs "shall be deducted from the allowance" and are recorded in the period the asset is deemed uncollectible. If you report under U.S. GAAP and keep such an allowance, ask your accountant whether it covers this amount. If it does, debit the allowance instead of the loss account. The same standard says a recovery of an amount previously written off is recorded when it is received, so money that arrives later goes in then. It also notes that practices differ on where recoveries are credited; credit yours to the account the write-off was charged to. File the evidence for the conclusion with the entry: the vendor's written refusal, your dated requests that went unanswered, or notice that it has closed.

The position after each stage:

On the cash basis, with no bills entered, the first payment goes to supplies expense and the second, once confirmed, to the due-from account; the refund and write-off entries are the same. A credit is recorded when you pay the next invoice net of it:

On either basis, each invoice's cost reaches expense once.

How do the bank reconciliation and the vendor account stay in agreement?

Both payments stay in the books as cleared outflows because both appear on the bank statement, so the reconciliation agrees with no adjusting entry. A refund is a deposit in the period it arrives, matched to its statement line. A credit never touches the bank; it shows only as a smaller later payment.

When the refund lands somewhere other than where the duplicate left, such as a check refunding a card charge, record it in the account it actually reached. The due-from account ties the outflow and the return together.

Until the duplicate is settled, check at each month-end that:

• The due-from account equals your list of open duplicates by vendor.
• Each vendor's statement agrees with your vendor account plus the due-from balance for that vendor. Until the vendor issues a credit, the duplicate sits on its statement as a credit or unmatched payment, and in your books in the due-from account.
• The bank reconciliation carries no adjustment for either payment.

What if the duplicate is in a period that's already closed?

If the period is still open, post the reclassification in it. If the period was closed and its figures already reported, where the correction belongs is a separate decision about correcting a closed period, to be made before posting.

What stops it happening again?

Fix the control that failed, matched to the cause you found:

Across every cause, keep entering bills and releasing payments with different people where staffing allows. In a one-person business, run the detection routine before each payment run and include the run's proposed payments in the list, so each is compared with payments already made. Compare open bills with vendor statements every month.

A match before release confirms that a bill hasn't already been paid; it does not confirm where the money goes. A bill or message that changes a vendor's payment details needs verifying before anything is paid, and that is a separate question.