"Our reconciliation would have caught this"

"We reconcile every month."

Then you are ahead of most platforms, and I mean that without qualification. Monthly reconciliation is real, unglamorous work that somebody has to argue for, and the teams doing it properly tend to be the ones who find this class of problem at all.

It also works. A refund that left money in a connected account will show up as a gap between what your ledger says your revenue was and what your Stripe balance actually did. Nothing about the leak is hidden from a competent reconciliation. It is arithmetic, and the arithmetic is available.

So the question is not whether you will find it. It is when, and what is still true by then.

"So we would find it eventually."

Yes. Somewhere between two and thirty-five days after it happened, depending on where in the month it fell.

Here is what that interval costs. A transfer reversal is not a bookkeeping adjustment — it is a movement of funds out of the connected account's Stripe balance, and it requires the funds to still be reachable. On the day of the refund they usually are. After the seller's next payout, they frequently are not.

await stripe.transfers.createReversal(transferId, { amount: 211200 });
// succeeds if the connected account can cover it
// otherwise the balance goes negative, or the account is gone

Three things close that door, and all three are more likely the longer you wait: the funds are paid out, the account balance is already negative, or the account has been restricted or closed. None of them is exotic. They are the normal life of a connected account.

Most platforms only notice the leak when they close the books.

"Eventually is fine, it is only bookkeeping."

This is the sentence I would push back on hardest, because it treats a recoverable amount and an unrecoverable one as the same kind of number.

A discrepancy you find on the day is a task: create the reversal, note it, move on. A discrepancy you find eight weeks later against a seller who has been paid out four times since is not a task. It is either a negative balance you are asking someone to earn off, an awkward conversation, or a write-off. The line item looks identical in both cases and the outcomes are not remotely comparable.

Reconciliation tells you the size of the problem. It does not, on its own, tell you which part of it you can still do something about — and that second number is the one that determines what the month actually cost.

"We can just claw it back later."

Sometimes, and the three routes are worth naming because platforms tend to default to the worst one.

• Reverse it now, letting the balance go negative if it must, on the assumption the seller keeps trading and earns it back. Fine for an active seller, useless for one who has left.
• Net it against their next transfer, reducing what you send on their following sale. Cleaner commercially, but it needs to be something your agreement permits and something the seller has been told about.
• Write it off and fix the code. The right answer for small or old amounts, and the only honest one for a closed account.

What almost never works is the fourth option, which is a silent bulk clawback across a historical backlog. Technically it is the easiest of the four. Commercially it converts a payments bug into a support crisis, because the first thing a seller learns about it is a balance that dropped overnight for a transaction from March.

"How early would we need to know?"

Early enough that the funds are still in the account, which in practice means before the seller's next payout rather than before the end of the month. For a platform on daily payouts that is hours. For weekly, a few days.

That is the entire argument for detecting this at the event rather than at close, and it is not an urgency device — it is arithmetic about a shrinking window. The proportion of a leak that is recoverable is highest on day zero and falls from there, and no amount of reconciliation rigour changes the shape of that curve. It only changes where on it you are standing when you find out.

The detection itself is not complicated, which is the frustrating part. A charge.refunded event with no corresponding reversal against the linked transfer is the whole signal. If you already have webhooks, you already have the input.

Run a free audit

FeeGuard is an independent product and is not affiliated with, endorsed by, or sponsored by Stripe, Inc. "Stripe" and "Stripe Connect" are trademarks of Stripe, Inc., referenced descriptively.