Cleared isn't final

When you pull money from a bank account, “it went through” is the start of the story. The bank can still send it back.

Card people learn about chargebacks early. Bank-debit people often learn about returns the hard way.

Here’s how it goes. You debit a customer’s account. The batch is accepted. A day later the money shows up. Your system marks the invoice paid, ships the thing, maybe pays out a partner. Everyone moves on.

Then a return file lands. Not enough funds. Account closed. Customer says they never authorized it. The money you counted is leaving again, and the invoice you closed is open, except nothing in your product knows that yet.

Nobody did anything wrong in that story. The system just believed that “cleared” meant “final.” It doesn’t.

Returns are normal, not rare

Bank debits run on trust first and checks later. The receiving bank lets the debit post, then has a window to send it back with a reason code.

Most returns come back fast, within a couple of banking days. Some reasons, like an account holder disputing that they ever authorized the debit, can come back weeks later. The exact windows depend on the rail and the country, so read your own rules. The point is the same everywhere: for a while after money arrives, it can still un-arrive.

If your volume is low, you might go months without noticing. Then you grow, returns become a steady trickle, and every one of them is a manual cleanup.

”Paid” needs more than one state

The fix starts in your model, not your code.

If a payment has two states, pending and paid, there’s nowhere for a return to go. Someone flips paid back to pending by hand, or worse, makes a new negative payment that nothing links to the original.

Give money a few more honest states:

1. Initiated — you sent the debit.
2. Funds received — it showed up in a report.
3. Final — the return window you care about has passed.
4. Returned — it came back, with a reason code, linked to the original.

You don’t have to show all of that to the customer. You do need it in your ledger. And you need to decide, on purpose, which actions are safe at “funds received” and which wait for “final.”

Decide what you’ll risk before the window closes

This is a business call, not a technical one.

Some things are cheap to reverse: access to a feature, a receipt email, a status on a dashboard. Fine to do early.

Some things are expensive to reverse: paying out to a third party, shipping physical goods, releasing a big credit line. Those either wait for the return window, or you accept the risk knowingly and price it in.

What hurts is when nobody made the call, and the system just did the expensive thing the moment money showed up.

A return is an event on the original payment

Same lesson as refunds. A return is not “undo.” It’s a new event that points at the payment it reverses.

That only works if you can find the original. Which means your own id has to survive the round trip: on the debit you send, in the report you get back, in the return file. If the only link between the return and the payment is “same amount, same customer, roughly the same week,” you’re matching by hope.

When a return lands:

• Match it to the original by your reference first.
• Record it as its own ledger entry, with the reason code.
• Move the payment to returned. Don’t delete history.
• Re-open whatever the payment closed: the invoice, the balance, the entitlement.
• Route anything that doesn’t match cleanly into an exception queue with an owner and an age.

Reason codes are instructions

Not all returns mean the same thing, and treating them the same is how you annoy good customers and keep retrying bad accounts.

Not enough funds might be worth one retry later, if your rules and your customer agreement allow it. Account closed is not worth a retry; you need new details. Unauthorized means stop, talk to the customer, and look at how you collected consent.

Map each reason code you actually see to one next action in your system. Retry, ask for new details, stop and review. Small table, big difference. The codes your rail sends are an input; the action is yours.

Watch the trend, not just the row

One return is an ops task. A rising return rate is a signal.

It can mean a bad signup flow, stale bank details, a billing date that lands before payday, or fraud. Rails and banks watch return rates too, and high ones get attention you don’t want.

So count them. Returns by reason, by week, by how you collected the account details. You don’t need a fancy dashboard. You need someone who looks at it on a schedule.

Boundary

Futurify builds software. We don’t hold funds and we’re not a processor. We build the ledger, matching, return handling, and ops around payment state — and under Run, we operate with you after go-live.

Next step

Do this part first — two minutes, useful whether or not you talk to us.

Find the last bank debit that came back. Write down: how did you find out? How long after you marked it paid? What did someone have to touch by hand to fix it?

If the answers are “a person noticed,” “no idea,” and “a lot,” you already know where to start.

Send that to hello@futurify.io if you want a second pair of eyes on your payment states and return path. We’ll tell you what we’d fix first. If it turns into a longer conversation, good — that’s the work. If it doesn’t, you still know what “paid” really means in your system.