Accounts receivable

Customer Says They Already Paid an Invoice? Here's What to Do

July 2026 · 5 min read

"This was paid last week — please check your records." It's one of the most common invoice replies there is, and one of the trickiest to handle well. Most of the time it's true, and the payment is sitting unreconciled somewhere in your books. Sometimes it's a mistake — they paid a different invoice, or a different vendor. Occasionally it's a stall. You can't tell which from the email, and treating a true claim like a stall (or vice versa) damages exactly the relationship you're trying to collect from.

Here's a process that works for all three cases without you having to guess which one you're in.

Step 1: Ask for the two details that settle everything

Before checking anything on your side, reply and ask for the payment date and the payment reference — check number, ACH/wire confirmation, or the last four digits of a transaction ID. Keep it neutral:

Thanks for the heads up — happy to get this reconciled. Could you send over the payment date and any reference number (check #, ACH confirmation)? That'll let me track it down on our end quickly.

This framing does two jobs at once: it treats the customer as honest (which they usually are), and it politely puts the burden of proof where it belongs. A customer who actually paid can answer in thirty seconds. A customer who's stalling usually goes quiet — which is itself information.

Step 2: Reconcile against your records, not your memory

With date and reference in hand, check three places in order: your bank feed around the claimed date (± a few business days — ACH and checks lag), your payment processor if you use one, and unapplied or misapplied payments in your accounting system. The most common resolution by far: the payment exists but was applied to the wrong invoice, or landed as an unapplied credit because the customer didn't include the invoice number.

Step 3: Close the loop explicitly — whichever way it goes

If you find the payment

Tell them, confirm which invoice it's now applied to, and apologize briefly for the chase. Then fix the root cause on your side (usually: payments arriving without invoice numbers — start putting the invoice number in your payment instructions and remittance requests).

If you can't find it

Say exactly what you checked, and ask for the proof of payment itself — a bank statement line or check image. Stay collaborative in tone:

I've checked our deposits from [date range] and the processor, and I'm not finding a payment matching that reference. Could your bank send over the transaction confirmation or a copy of the cleared check? If it went out, we'll find where it landed.

A real payment produces proof in one email. If two requests for proof produce excuses instead, reclassify this in your head from "reconciliation problem" to "collection problem" and follow up accordingly — see our follow-up templates for the escalation ladder.

The part everyone skips: track the claim itself

An already-paid claim isn't a resolved status — it's an open one with a deadline. The failure mode is reading the email, thinking "I'll check the bank tomorrow," and letting the invoice silently exit your follow-up rotation for a month because it feels handled. Log the claim with the claimed date and reference, set a next action ("reconcile by Thursday"), and treat a claim that stays unresolved past a week as a red flag, not a background task.

It's also worth tracking who makes these claims. A customer whose invoices routinely go through an already-paid-claim cycle before resolving — whether from sloppy AP processes or as a deliberate delay tactic — is a pattern worth knowing about before you extend them net-60 on the next job.

InvoiceReply classifies these automatically. When a customer replies claiming an invoice was already paid, InvoiceReply flags it as an already-paid claim, extracts the claimed date and reference, sets it as an open item to reconcile, and spots the customers who do this repeatedly. Join the pilot →