When a Payment Bounces or Lands on the Wrong Invoice

Most payment problems happen before the money moves — a card declines, a customer disputes a charge. This article is about the two that happen after, when your books already say you were paid:

1. The bank takes it back. An ACH returns NSF three days later, or a check bounces.
2. The money went to the wrong place. A payment was keyed against the wrong invoice, or occasionally the wrong customer entirely.

Both used to get fixed the same wrong way — by voiding or refunding the payment and starting over. That works, and it also costs you money and confuses the customer. There are now proper tools for each.

Why you shouldn't just void or refund

Void and Refund both send a real instruction to your payment processor. That's the right thing when the customer is genuinely getting their money back. It's the wrong thing in both situations above:

• For a bounced payment, the money is already gone — the bank pulled it. Sending a refund on top tries to send it again. Best case the processor rejects it; worst case you pay the customer twice.
• For a misapplied payment, nothing should move at all. The customer paid the right amount to the right business. Refunding and re-charging costs you processing fees in both directions, and the customer watches a refund and a new charge appear on their statement for money that was never in question. On a $2,000 ACH payment that's real money for a clerical fix.

Recording a returned ACH or bounced check

What Suprata already does on its own

For ACH through USIO, Suprata checks each of your bank payments with your processor several times a day, for the full 60 days a payment can still be sent back. For Stripe, returns arrive automatically. When one is found, Suprata handles it end to end with no action from you:

• The payment is marked Returned and its balance comes off the invoice.
• The invoice reopens if it had been closed, so the customer shows as owing the money again.
• An entry lands on both the invoice audit trail and the customer's timeline, recording the return code and reason.
• A notification is raised for your team.
• If the return code means the bank account is dead (closed, frozen, authorization revoked), the saved bank account is switched off so your recurring billing stops firing at an account that can't pay.
• For any other return (insufficient funds is the common one), the bank account stays on and future automatic payments keep running as scheduled. The bounced payment itself is never re-tried automatically — call the customer, and if they say run it again, take the payment from the invoice.
• Your automations fire on the same trigger a failed payment uses — so any dunning workflow you've built already covers returns.

When you have to do it by hand

Automatic detection is good but it isn't complete, and the gaps are predictable:

• Bounced checks. There's no processor involved, so nothing can report it. Your bank statement is the only source.
• Returns older than 60 days. Beyond that window Suprata stops checking, because the payment can no longer be sent back — if one surfaces later it has to be recorded by hand.
• Anything your processor didn't report cleanly, or a payment whose reference your processor no longer recognises.

For these, open the invoice, click the payment in the payment list, and choose Mark Returned. You'll be asked for the return code (a dropdown of the common NACHA codes for ACH — blank is fine for a check) and a reason.

Everything then happens exactly as it would automatically. It is the same mechanism, not a separate one, so a hand-recorded return and a processor-reported return are indistinguishable downstream — same reversal, same audit entries, same automations. The only difference is one line in the audit note saying it was recorded by staff rather than reported by the gateway, which is what you want when you're reconciling later and asking "how did we know about this one?"

This is only available for ACH and check payments. If a card payment comes back, that's a chargeback, not a bank return — the processor runs that process on its own timetable and you handle it through the dispute flow. See Handling a customer dispute.

Moving a payment to the correct invoice

Open the invoice the payment is currently on, click the payment, and choose Move to Another Invoice. Search for the correct invoice by number or customer name, pick it, type a reason, and confirm.

What happens:

• The payment moves. Same payment, same transaction ID, same card or bank account on file.
• Your processor is never contacted. No refund, no new charge, no fees.
• The original invoice's balance goes back up, and reopens if it had been closed.
• The correct invoice is paid down.
• Both invoices and both customer timelines get an audit entry naming the other side and your reason.

If the payment is bigger than the invoice needs

Say a customer sent $500 and it was applied to the wrong invoice. The correct invoice is only $300. Suprata applies $300 to that invoice and turns the remaining $200 into account credit on the customer.

That's deliberate, and it's how you split one payment across several invoices. The credit is real spendable balance — go to any other open invoice for that customer and use Pay with Balance to apply it. Repeat until the $500 is fully allocated.

The reason it works this way rather than chopping the payment into pieces is that one payment from the customer's bank should stay one payment in your records. Splitting it would leave you with two half-transactions pointing at a single bank debit, which makes reconciliation against your processor statement considerably harder and refunds messier later.

Moving a payment to a different customer

This is allowed, because the "recorded against the wrong customer" mistake has no other remedy. But it is the one correction worth being slow about, so Suprata makes it loud:

• Invoices belonging to a different customer are flagged (different customer) in the search results.
• Selecting one shows a red warning before you can confirm.
• Both customers' timelines are audited, each naming the other.
• If you use QuickBooks, the payment is deleted and re-created under the correct customer automatically — QuickBooks doesn't permit simply reassigning a payment to a different customer. If that automatic step fails for any reason, you'll be told in plain terms so you can fix QuickBooks by hand. The move in Suprata still stands.

What can't be moved

The option won't appear for payments where moving it isn't meaningful:

You also can't move a payment onto a closed invoice, or onto one with nothing owing. Reopen the closed one first — Suprata won't silently un-close a settled invoice as a side effect of a correction, because that's a decision someone should make deliberately. As for an invoice with a zero balance: moving a payment there would turn the whole thing into account credit and leave a payment attached to an invoice it paid nothing towards. If credit is what you want, issue credit directly.

Common mistakes

• Refunding a bounced ACH. The bank already took the money. Refunding tries to send it a second time. Use Mark Returned.
• Voiding and re-taking a misapplied card payment. You pay processing fees twice and the customer sees two transactions on their statement for a clerical error. Use Move to Another Invoice.
• Assuming automatic detection covers checks. It can't — no processor is involved. Someone has to read the bank statement. Decide who, and how often.
• Skipping the reason field. It's required for a reason. Six months later, the audit entry is the only thing that explains why money moved between two invoices, and "correction" tells the next person nothing. Write what actually happened: "keyed against INV-1042 in error, customer was paying for INV-1108."
• Treating a returned payment as a collections problem only. It's also a payment-method problem. If the return code was "account closed" or "authorization revoked", Suprata switches off the saved bank account for you — but somebody still has to ask the customer for a new one before the next recurring invoice comes around.
• Leaving surplus account credit unallocated. After moving a large payment onto a smaller invoice, the leftover sits as account credit. It's visible on the customer's record, but it isn't applied to anything until someone applies it. Finish the job in the same sitting.

Who can do these

Both are restricted, and they're separate permissions from each other and from refunds:

• Mark Payment Returned — records something the bank did to you.
• Move Payment Between Invoices — corrects your own books.
• Process Void/Refund Transaction — sends money back through the processor.

Three different levels of authority, so nobody gets one by being granted another. Neither new permission is switched on for anyone by default — an administrator has to grant it to the roles that should have it. If a manager says the option isn't there, that's almost always why.

Related articles

• The Accounting Dashboard
• Credits vs. refunds vs. voids
• Setting up ACH and when to prefer it
• Refunds and partial refunds
• Handling a customer dispute
• Saved payment methods and when to use them