By: Money Navigator Research Team
Last Reviewed: 28/01/2026
FACT CHECKED
Quick Summary
When a Tide account is closed, incoming payments sent to the old sort code and account number usually either:
- Return to sender
- Redirect if a switch/redirection mechanism is in place
- Arrive as a “stranded” refund that needs manual handling because the original account is no longer active
Which outcome happens depends on the payment type (bank transfer vs card refund), the rail (Faster Payments, Bacs, CHAPS), and whether the account is closed versus merely restricted.
This article is educational and not financial advice.
Closed vs Restricted: Why It Changes Incoming Outcomes
Incoming-payment behaviour can differ depending on whether the account is closed or restricted. A restriction may still allow certain credits to land while blocking debits or outbound transfers, whereas closure typically ends normal payment functionality and pushes more items into “return” or “needs manual handling” pathways.
For Tide-specific definitions, see Tide business account: restricted vs closed and Tide account locked or frozen: what usually still works.
The Three Common Post-Closure Outcomes for Incoming Money
1) Returned to sender
For many bank-transfer types, if the destination account can’t accept the credit (because it is closed), the usual practical outcome is a return back through the payment system.
From a business-operations perspective, that can look like a delay rather than a permanent loss, because the sender often sees the money leave and only later sees a return.
2) Redirected to a new account (where switching/redirection exists)
Tide’s closure guidance references using the Current Account Switch Service so that payments sent to the old details are redirected to the new account. Tide describes this as a way to ensure payments made to the old account are automatically redirected.
See Managing your Tide account closure.
The scheme itself describes that payments sent to the old account will be redirected. See Current Account Switch Service.
3) Arriving as a refund after closure (card refunds in particular)
Card refunds can be initiated after an account is closed (for example, a merchant processes a refund late). Tide’s closure guidance includes a specific “refund into your closed account” scenario and describes a manual transfer process to another bank account after identity checks. See Managing your Tide account closure.
Bank Transfers to a Closed Tide Account: Faster Payments, Bacs, CHAPS
Faster Payments
Faster Payments are designed to move quickly, which reduces the chance of a sender spotting a problem before sending. Once sent, the payment can’t simply be cancelled in the way a queued instruction can, and recovery tends to follow established mistake-recovery processes rather than “undo”.
Pay.UK explains that, due to their real-time nature, once sent Faster Payments cannot be cancelled. See How Faster Payments work.
Where a closed destination can’t accept the credit, the practical effect is usually that the sender sees a return later. Businesses often experience this as: funds sent > temporary gap > funds returned > payer asked to resend to new details.
Bacs credits
Bacs runs on a staged cycle. That matters because “sent” and “received” can be separated by days, and closure can happen inside the cycle window. Bacs sets out the three-day processing cycle (input, processing, entry). See Bacs Direct Credit.
In practice, if a business is expecting Bacs credits (for example, payroll receipts, supplier rebates, or other scheduled credits), closure can increase the chance of “late discovery” because the issue may only become visible at the entry stage.
CHAPS
CHAPS is a sterling same-day system often used for time-critical payments. The Bank of England describes CHAPS and its operating hours. See CHAPS.
For inbound CHAPS, the “closed destination” problem tends to show up quickly once settlement can’t be applied to the beneficiary account. Operationally, this can look like same-day urgency for the sender to obtain correct beneficiary details once a return/rejection is identified.
Returns and “Bouncebacks”: What They Usually Look Like in Practice
A “return” is usually experienced at the edges: the sender sees funds come back, and the recipient sees nothing land.
That’s why reconciliation can be hard after closure: the intended recipient may not have a transaction record to point to, while the sender’s bank statement shows an outbound and then a later inbound return.
This is one reason many closure scenarios create secondary operational issues: invoices marked paid that weren’t, subscriptions lapsing, or platform payouts failing.
These knock-on problems are often payment-chain issues rather than “accounting errors”. A useful framework for understanding where inbound money can get stuck is the chain described in Merchant account vs EMI balance vs bank balance: the payments chain.
Card Refunds, Chargebacks, and Platform Payouts After Closure
Not all “incoming money” is a bank transfer. Common inbound items include:
Card refunds (merchant-initiated)
Chargeback reversals/adjustments (scheme-driven timelines)
Marketplace or payment-processor settlements (payout schedules)
Tide’s closure guidance explicitly addresses the “refund into a closed account” scenario and describes a support-led transfer path. See Managing your Tide account closure.
For chargeback-linked holds and withheld funds dynamics (which can affect what appears to be “incoming”), see Chargebacks and card disputes with EMI settlements: who can withhold funds.
For the specific operational problem of updating payout destinations during closure, see Switching card processor payouts to a new bank account during closure.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| Customer sends Faster Payment to closed Tide details | Often returns to sender later | Customer believes it has been paid; recipient sees no credit |
| Supplier sends Bacs credit while account closes mid-cycle | May fail at entry stage and return | Longer gap before anyone realises; reconciliation delay |
| Time-critical CHAPS sent to closed details | Rejection/return typically becomes visible quickly | High urgency for sender to confirm new beneficiary details |
| Switch/redirection is active | Payment redirects to new account | Payer may not change records immediately; mixed records for a period |
| Merchant issues card refund after closure | Refund may not credit normally | Refund handled via manual transfer path after verification |
| Marketplace/processor payout sent to old details | Payout may bounce or pause | Settlement schedules disrupt cash flow reporting |
| Account is restricted rather than closed | Some credits may still land | “Incoming works but outgoings don’t” can occur in some cases |
Where Product Structure Can Matter
Tide’s business account offering can sit within different structural models (for example, “app-led” accounts that may be bank-based or e-money based).
The practical handling of closures, redirection, and returns can vary across structures, even when the user experience feels similar.
For a neutral explainer on how to check whether an app-based business account is a bank or e-money provider, see App business accounts: bank or e-money.
For the protections angle often confused with closure outcomes, see Safeguarding vs deposit cover: EMI protections vs FSCS bank accounts and the structural contrast in E-money provider closes account: EMI exit vs bank closure.
Records and Proof: What Typically Remains After Closure
Post-closure, “proof” often matters more than payment functionality, because senders, customers, platforms, and accountants may all ask what happened.
Tide’s help content states that it will send a copy of full transaction history after closure, and also describes a window for requesting transaction history after closure with identity verification. See What happens if I close my Tide account?.
Separately, the “when will remaining balances be returned” question tends to arise where inbound items stop arriving but historical balances still need reconciling. For the general timing mechanics, see How long banks return the remaining balance after account closure.
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| Incoming payment sent after closure | Beneficiary account can’t accept credit | Return to sender through the rail’s return handling |
| Incoming payment sent before closure but credits after | Timing crosses a closure boundary | Sender sees debit; recipient may see nothing; return may follow |
| Switching/redirection in place | Redirection rules apply to old details | Credit lands at new account rather than returning |
| Card refund issued post-closure | Refund routed to closed account details | Refund handled via support-led transfer path |
| Processor payout linked to old details | Settlement chain uses stale beneficiary details | Payout bounces, pauses, or is re-routed after updates |
| Restriction rather than closure | Account may accept some credits but restrict usage | “Credits appear but funds can’t be moved” is possible in some cases |
| Inbound and outbound effects overlap | Closure disrupts both sides of cash movement | “Paid but not received” disputes increase; admin load rises |
Tide Business Bank Account
Tide’s account experience is app-led, and the practical impact of closure is usually felt through what happens to payment rails and records access rather than a single “on/off” moment.
For an overview of Tide’s business account positioning within our wider comparisons, see Tide business bank accounts.
Frequently Asked Questions
Not always, but return-to-sender is a common practical outcome when the beneficiary account cannot accept a credit. The sender may see the outgoing payment succeed initially and only later see a return, depending on rail and timing.
Where switching/redirection is active, the incoming credit may redirect rather than return. This can create mixed records for a period: the payer believes they used the old details, while the recipient sees the money land in a different account.
Return timing varies by rail and by the stage at which the credit fails. Some outcomes become visible quickly, while others surface only after scheme processing completes.
The operational reality is that many disputes arise during the “visibility gap” between the sender’s debit and the later return. That gap can look like a missing payment even when the rail is working as designed.
- A rejection typically means the payment can’t be applied and doesn’t settle to the beneficiary account.
- A return is the later movement of funds back to the sender following that failure.
- A recall usually refers to the sender attempting to recover funds after sending, which is not the same as a standard return.
In practice, senders often use “recall” for any situation where money didn’t end up with the intended recipient. But the underlying mechanism matters, because it shapes what evidence exists and what timelines apply.
In some restriction scenarios, incoming credits can still appear while other functions are limited. That “credits land but usage is constrained” pattern is one reason businesses sometimes see incoming payments behave differently from outgoing payments during review windows.
Once the account is fully closed, the balance of outcomes tends to shift towards returns, redirects, or manual handling for certain item types (notably refunds).
If a merchant issues a card refund after the account is closed, the refund may not credit to the closed account in a normal, self-serve way. Some closures leave a “stranded refund” situation where the provider handles onward transfer after checks.
Operationally, this is one of the most confusing post-closure problems because the customer sees a refund processed, but the business doesn’t see a matching inbound credit.
Yes, dispute timelines can run beyond closure, and the net effect can look like inbound money appearing, being withheld, or being offset by adjustments depending on the settlement chain. This is especially visible where a processor or scheme applies holds or netting.
This is less about Tide specifically and more about how dispute systems work: closure doesn’t necessarily end external scheme timelines that were already in motion.
Where payouts are sent as bank transfers to old account details, common outcomes include returns or payout delays while the platform retries or requests updated details. Where payouts are linked to multi-party settlement chains, the “where did it go?” question can be more complex than a simple bank transfer.
This category often creates operational risk because a business may have multiple payout sources that need updating, and failures may not be noticed until a scheduled payout date is missed.
Yes. Each rail has different timing and processing characteristics.
- Faster Payments often compresses the timeline
- Bacs can stretch it across a cycle
- CHAPS is typically used for time-critical same-day sterling payments
From a returns perspective, the key practical difference is when the failure becomes visible. For some rails, the sender may discover issues quickly; for others, the issue may only be obvious after the processing cycle completes.
Typically, the sender has proof of initiation (bank confirmation, statement line, or payment reference). The recipient may have no inbound record at all if the payment never credited due to closure, which makes “absence of evidence” a real issue.
This is why post-closure record access and transaction-history availability often become central to dispute resolution, even though they don’t restore payment functionality.
Incoming and outgoing problems often overlap in closure periods because both sides of cash movement can be disrupted. An account can be closed while outbound items are in flight and inbound items are still being attempted by payers.
For the outbound “in flight” mechanics (which often explain timing clashes and reconciliation gaps), see If Tide closes an account mid-processing: what happens to outgoing payments.
Incoming-payment disruption after closure is usually not a single event; it is a set of rail-specific outcomes that appear inconsistent because different rails fail at different points.
The same “closed account” condition can produce a return, a redirect, or a manual-handling scenario depending on whether the inbound item is a bank transfer, a scheduled credit within a cycle, or a card refund initiated after the account stopped operating normally.
The most persistent operational problem is the visibility gap: senders often see a successful outbound payment before the system later returns it, while the recipient sees nothing at all. That asymmetry is what turns a routine return mechanism into a practical dispute and reconciliation burden.
Related Content
