By: Money Navigator Research Team
Last Reviewed: 04/02/2026
FACT CHECKED
Quick Summary
Tide supports sending USD payments to the US via ACH (where the feature is available and your account is eligible), and it publishes a specific set of recipient details required to set up and approve a payee.
Tide also states that receiving USD via ACH is not currently supported, and that Tide accounts are paid in GBP and EUR only (with other inbound currencies rejected).
This article is educational and not financial advice.
What “USD via ACH” means in Tide
ACH (Automated Clearing House) is a US domestic transfer method used by banks and credit unions to exchange batches of electronic credits and debits (for example payroll direct deposit and bill payments).
The Federal Reserve describes the ACH system as a nationwide network for batch electronic credit and debit transfers, and notes the role of operators in receiving, sorting and settling payment files.
In this context, Tide’s “USD via ACH” feature is about delivering USD to a US account using an ACH transfer route, rather than sending an international SWIFT wire.
Nacha (which governs the ACH Network’s rules) explains ACH as a file-based process involving originators, banks and ACH operators, with settlement timing that can vary by payment type and processing window.
That matters because “ACH” usually behaves more like a processed transfer than an instant payment rail.
When USD payments via ACH are available in Tide
Tide states that it supports USD payments to the US via ACH as an international payment type (alongside EUR via SEPA), and it also states that USD payments are subject to eligibility criteria that Tide cannot disclose for security reasons. In practical terms, availability has two layers:
Product availability in the app
Tide describes an in-app activation step for USD payments (enabling USD/ACH). This suggests the feature may appear as an option, but still requires activation in your account settings.Eligibility to use the rail
Tide notes that eligibility criteria exist and are not disclosed. That means two businesses can see different behaviour even if they follow the same steps.
For Tide’s broader rail options (SWIFT vs SEPA vs ACH) in a single place, see our internal explainer: Tide international transfers: SWIFT vs SEPA vs ACH.
What Tide can and can’t do with USD (send vs receive)
Tide’s published position is clear on two points that are easy to mix up:
Sending USD to the US via ACH: Supported (subject to availability and eligibility). See Tide’s feature explanation on sending USD with your Tide account.
Receiving USD via ACH: Not currently supported. Tide explicitly states you can’t receive USD via ACH, and separately states Tide business accounts can only be paid in GBP and EUR (other inbound currencies are rejected). See what currencies can I be paid in.
This is an important distinction: supporting an outbound USD payment route is not the same as holding a USD balance or accepting inbound USD.
What information is required to send USD via ACH (and why it matters)
Tide lists specific recipient fields for setting up a USD payee via ACH. The required data typically centres on:
Recipient legal name (so the payee record can be approved and matched correctly)
US routing number (the US bank/credit union identifier used for ACH delivery)
US account number (the destination account within that institution)
Recipient address (used for payee records and compliance/validation checks)
Tide sets this out in its support guidance on what information is needed to send USD payments via ACH.
Why these fields matter in practice:
Routing number + account number are the core delivery instructions. If either is incorrect, the payment may fail validation, be rejected, or be returned.
Name and address can affect payee approval and downstream processing (for example, mismatches can trigger manual checks at different points in the chain).
Tide also indicates that if incorrect recipient details are entered, the payment may not be processed and may not appear in transaction history (depending on where the failure occurs), which is operationally different from a “processed then returned” scenario.
How the payment moves end-to-end (a practical, Tide-specific view)
Tide’s published flow for USD payments via ACH can be understood as:
Enable USD payments (ACH) in the app (where available).
Create/approve a recipient using the required details.
Enter the amount in GBP and review the converted USD amount and FX/fees.
Confirm the payment, after which it enters processing.
Tide describes these mechanics in Send USD with your Tide account and outlines international payment types (EUR via SEPA; USD to the US via ACH) in Can I make international payments?.
At a system level, ACH is widely described as a batch-based network where banks send and receive files through operators. The Federal Reserve’s overview of the ACH system explains batch processing and operator roles (including receiving files, sorting and settlement).
See Federal Reserve Board – Automated Clearinghouse Services. Nacha provides a process walk-through that helps explain why timing and returns can be different from instant rails. See How ACH payments work (Nacha).
Typical timings (and why “ACH” often isn’t instant)
Tide provides a general guideline for international USD sending timeframes and notes it cannot guarantee exact timing. In its USD sending guidance, Tide gives a broad working-day estimate for sending money outside the UK and highlights dependency on local/intermediary systems. See Send USD with your Tide account.
Two structural reasons ACH timing can vary:
Batch processing and operator windows: ACH commonly processes as files rather than single real-time messages, which naturally introduces cut-offs and settlement windows. The Federal Reserve’s ACH overview describes batch exchange between depository institutions and the operator’s sorting/settlement role. See Automated Clearinghouse Services.
Returns and exception handling: ACH can generate return notifications (for example insufficient funds, closed account, invalid account), which can extend the total time to “final outcome”. The CFPB notes that ACH can sometimes take several days because of processing and precautions, and that ACH transactions can trigger return notifications. See CFPB money transfer frequently asked questions.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| USD via ACH is enabled and the business is eligible | Payment can be initiated and submitted for processing | Operationally workable for US suppliers/payroll, but timing is not instant |
| USD via ACH option exists, but account is not eligible | Payment route may be unavailable or blocked | Planning risk: payments may need an alternative rail/arrangement |
| Attempting to receive USD into Tide | Inbound USD is not supported (other currencies rejected) | US customers/senders must use an allowed inbound currency/rail instead |
| Routing number or account number is incorrect | Payment may fail validation, be rejected, or be returned | Delays, admin time, and possible FX differences if funds are returned later |
| Recipient name/address mismatches payee record | Payee approval or processing may be delayed or declined | More time spent resolving payee setup; may require re-entry of details |
| Payment is submitted close to non-working days | Processing/settlement can extend over weekends/holidays | “End-to-end days” can increase even if “working day” estimate is unchanged |
Common errors (and how they usually show up)
1) “It won’t let me send USD” (availability/eligibility)
If the USD option is missing or cannot be activated, that can indicate the feature is not available for the account, or eligibility criteria are not met. Tide states eligibility criteria exist and are not disclosed. See Can I make international payments?.
2) Payee setup errors (data field issues)
The most common ACH blockers are basic instruction errors: routing number, account number, legal name, address. These can prevent a payee being approved or a payment being processed. Tide lists the fields it asks for in payee setup. See required recipient information for USD via ACH.
3) “Submitted” vs “processed” vs “returned”
With batch systems, there can be a meaningful difference between:
Not accepted for processing (fails early checks; may not appear as a processed transfer), and
Accepted then returned (goes through processing and later returns due to recipient-bank reasons).
The CFPB notes that ACH can take several days and that return notifications can occur. See CFPB money transfer frequently asked questions.
4) Confusing ACH with SWIFT/SEPA fields
ACH does not use IBAN/BIC in the same way as European rails. If you’re dealing with SWIFT beneficiary fields (IBAN/BIC), see Tide SWIFT payments: details needed and why. If the payment is EUR via SEPA, see Tide SEPA payments explained: timings and common errors.
Scenario Table
| Scenario-level | Process-level | Outcome-level |
|---|---|---|
| First-ever USD ACH payment from Tide | Enable USD payments > add recipient > approve recipient > confirm payment | Higher chance of setup friction; once configured, repeat payments are typically simpler |
| Repeat payment to an existing recipient | Select recipient > enter amount/reference > confirm | Fewer data-entry errors; timing still depends on processing windows |
| USD payment returned after submission | Recipient bank issues a return > funds flow back > FX is re-applied at return time (where applicable) | Final received amount in GBP can differ from the original outflow due to FX timing |
| Attempted inbound USD to Tide | Sender initiates USD transfer to Tide | Rejected because inbound USD is not supported; sender may need re-issue using supported inbound currency/rail |
| Compliance/controls trigger a pause | Payment or payee flagged > additional checks > processing delay | Timing becomes less predictable; operational knock-on effects (supplier/payroll timing) |
Fees and FX: what Tide says you may see
Tide explains that fees for USD via ACH depend on plan allowances (free transactions vs per-payment fees above allowance), and also describes applying an FX markup (with different levels for paid plans). See fees to send or receive USD via ACH.
Separately, Tide’s international payment guidance describes reviewing the exchange rate and converted amount during confirmation, and notes that if a payment is returned, FX at the time of return may affect the amount received back. See Send USD with your Tide account.
Tide Business Bank Account
Tide is a business banking platform with UK business account options, and it supports different payment rails for different use cases (for example GBP inbound via SWIFT, EUR via SEPA, and USD to the US via ACH where available and eligible).
Product structure and supported rails can change, so it’s worth separating “which rail does Tide support?” from “which currencies can this account receive?”.
For a broader, UK-focused overview of Tide’s business account proposition (features, pricing structure and trade-offs), see our hub page: Tide business account review.
Frequently Asked Questions
Tide states that it can’t currently receive USD via ACH, even though it supports sending USD to the US via ACH in certain cases. That means “USD via ACH” in Tide is primarily an outbound capability rather than an inbound currency feature.
Tide also states its business accounts can only be paid in GBP and EUR, and that payments sent in other currencies will be rejected. In practice, this affects how US customers or platforms pay a Tide account: if they try to pay in USD directly to the Tide business account, the payment may fail and require re-issuing in an accepted currency/rail.
ACH is a US domestic network, but Tide frames USD via ACH as an option within its international payments feature set (alongside EUR via SEPA). Functionally, that usually means a UK-based business is initiating a payment that is delivered into the US banking system via ACH.
This distinction matters because it can blend two ideas: the destination rail is domestic (ACH), but the payment initiation, FX conversion and compliance controls can behave more like an international transfer product.
Tide publishes the recipient fields it asks for when setting up a USD payee, centred on legal name, routing number, account number, and address. This data is used to create and approve a recipient record and to route the payment to the correct institution and account.
If any of these fields are wrong or inconsistently formatted, the issue can show up at different stages: failure to add/approve the payee, failure before processing, or a later return from the recipient bank. Operationally, those outcomes feel very different because only some of them generate a “returned payment” journey.
ACH instructions typically use a US routing number and US account number rather than IBAN/BIC. Mixing up these field sets is a common source of delays when a business is dealing with multiple rails at once (for example, paying a EUR supplier via SEPA while paying a US supplier via ACH).
Where a counterparty provides international banking coordinates (IBAN/BIC), it’s worth confirming whether they expect a SWIFT wire or a local US ACH transfer. The rail choice changes the data fields required.
Tide provides a working-day guideline for international payments and states it cannot guarantee exact timing, as timing depends on local and intermediary systems. Even when everything is set up correctly, the end-to-end time can vary.
From a network perspective, ACH is a batch-based system. Batch rails often have cut-offs, operator windows and exception processing (including returns), which can turn “a couple of days” into “several days” depending on when the file is submitted and whether any downstream rejection occurs.
There are two broad pathways.
- The payment can fail before processing (for example, validation fails early)
- It can be accepted and then later returned by the receiving side
The user-facing symptoms differ: one can look like “it never went through”, while the other looks like “it went through and came back”.
Where a return happens, the final amount received back can be impacted by the timing of FX conversion, because the exchange rate at return time may differ from the exchange rate at send time.
Batch and file-based payments can be difficult to stop once they move into processing, because the instruction is exchanged between institutions as part of file processing rather than held as a single pending message.
In practice, the outcome depends on when cancellation is attempted relative to processing steps and cut-off times. The most common “reversal” experience is not a successful recall, but a later return (for example due to invalid details) that sends funds back after processing completes.
Tide states USD payments are subject to eligibility criteria that it can’t disclose for security reasons. That means a business can have the general payments feature set, but not have USD via ACH enabled or available.
Another operational factor is that availability is sometimes segmented by plan, account type, or product configuration. That doesn’t necessarily indicate an error; it can be a product-eligibility outcome.
Tide describes plan-based allowances (some plans include a number of free payments and then charge per payment above allowance), and also describes applying an FX markup, with reduced FX markup on paid plans.
That means the total cost of a USD payment can have multiple components: (a) any per-payment charge (depending on allowances) and (b) FX markup embedded in the conversion. Separately, if a payment is returned, the FX rate at the time of return can affect the GBP amount received back.
Tide frames EUR via SEPA and USD to the US via ACH as outbound international payment options, while GBP inbound is supported via SWIFT (and Tide states it can’t send via SWIFT). These rails are designed for different geographies and field requirements.
Practically, the difference shows up in:
- What details are required
- Typical processing patterns (batch rails vs network messaging)
- What Tide supports inbound vs outbound
A business dealing with EU and US counterparties often ends up maintaining separate payee data standards for each rail.
“Availability” for payment rails often combines three separate constraints:
- Whether the app exposes the rail
- Whether the provider enables it for the specific account
- Whether the account can actually receive funds in that currency
ACH adds a fourth practical constraint: it is built around file exchange and returns, so the operational truth is not just “sent” vs “not sent”, but “accepted”, “settled”, “returned”, or “stopped before processing”.
For Tide users, the key mental model is: USD via ACH is an outbound delivery route into the US banking system, not a statement that the account functions as a USD-receiving account.
Keeping “rail capability” separate from “inbound currency support” reduces confusion and prevents avoidable payee-data errors when switching between ACH, SEPA and SWIFT workflows.
Related Content
