ACH, Wire or SWIFT? Match the Transfer to the Receiving Account
The right transfer depends on where the recipient’s account sits, what it can receive and which currency must arrive—not simply where the vendor lives. Here is how finance teams can make that distinction before releasing a payout.
Choose ACH for routine payments to eligible US accounts, a domestic wire for urgent US bank payments, and an international wire using SWIFT when the receiving account requires that route. For overseas accounts, also check whether a local bank transfer is available. Paying internationally does not automatically require SWIFT.
The important distinction: ACH is a clearing network, a wire is a transfer method, and SWIFT is a messaging network used to communicate payment instructions. They are not three interchangeable systems.
For teams paying hundreds of international vendors, contractors or sellers, the practical question is not simply “ACH, wire or SWIFT?” It is: Which transfer can this account receive, in the required currency, under the provider’s rules? Answer that before comparing price or speed.
ACH, domestic wire and SWIFT at a glance
As Revolut’s payment-method explainer distinguishes, SWIFT carries instructions between financial institutions; it does not itself hold or settle the money. An international wire can use SWIFT messaging while settlement occurs through banks and their account relationships.
| Option | How it works | Receiving requirements | Timing considerations | Best for: editorial assessment |
|---|---|---|---|---|
| US ACH credit | Batch-based clearing between participating institutions | ACH-enabled US account and routing details | Processing windows, bank cutoffs and availability rules | Routine, cost-sensitive USD payouts |
| US domestic wire | Bank transfer, commonly settled through Fedwire | Domestic wire instructions accepted by the receiving bank | Often same business day before cutoff; reviews can delay credit | Urgent or high-value US payments |
| International wire using SWIFT | Bank messaging with settlement through banking relationships | International receiving instructions and supported currency | Depends on banks, corridor, screening and beneficiary posting | Accounts or currencies requiring international wire access |
| Local payout outside the US | Provider delivers through a destination-country payment system | Eligible local account and country-specific details | Depends on the local scheme and provider funding | Recurring local-currency payments where supported |
These are starting points, not guarantees. Account restrictions, provider limits and compliance checks can disqualify an otherwise suitable method.
Start with the account, not the vendor’s address
A foreign vendor may have eligible US receiving details
A contractor based outside the US may provide USD receiving details associated with a US bank. That can make an ACH credit possible, but a routing number alone is not enough.
Ask whether the details accept business ACH credits from your payer type, whether the beneficiary name must match exactly, and whether the account is individually assigned or part of a pooled collection arrangement. Some arrangements require a reference to allocate incoming money correctly.
Do not assume that US receiving details make the entire arrangement domestic for compliance purposes. The payment structure still matters.
A USD account abroad is not automatically ACH-accessible
A supplier may hold USD in a bank outside the US. The currency does not turn that account into a US ACH destination. Its receiving instructions may instead specify a SWIFT/BIC, beneficiary account number and correspondent bank.
Likewise, a US company’s overseas account may need an international transfer. Separate the vendor’s legal address, the receiving bank’s country and the account’s supported currencies in your records.
Bank details must be validated for the selected method
US banks may use different routing numbers for ACH and wires; some use the same one. Never infer wire eligibility from an ACH routing number. A SWIFT/BIC identifies an institution, while an IBAN or other account identifier identifies the destination account. Not every country uses IBAN.
Collect method-specific instructions through a controlled onboarding process, such as a vendor portal, rather than storing a single unqualified “bank details” field. For destination-specific requirements, use the country-by-country contractor payment guide as a starting point and confirm the current receiving instructions.
Separate the funding leg from the recipient’s payment
A provider can accept your funding through ACH and deliver the vendor’s payment through a different system. Conversely, you might fund a provider by wire while it pays recipients through local bank transfers.
This creates separate operational questions:
- Funding: When is your money available for the provider to use?
- Delivery: Which system reaches the recipient’s account?
- Conversion: Where does FX occur, and who sets the rate?
- Evidence: Which status confirms recipient credit rather than provider receipt?
A fast delivery method cannot compensate for funding that is still unavailable. Ask providers to identify both legs when quoting a payment ETA.
“Global ACH” and IAT do not mean the same thing
“Global ACH” is commonly a provider label for international payments delivered through local clearing systems. It is not one universal ACH network.
International ACH Transaction, or IAT, is a specific classification under Nacha rules. Nacha’s IAT guidance addresses ACH entries that form part of payment transactions involving a financial agency outside US territorial jurisdiction and the additional information needed for compliance.
Do not classify a payment solely from the vendor’s nationality or mailing address. Ask the originating bank or provider whether the structure meets the IAT definition, whether it supports that flow, and what party information it requires.
Compare the same economic outcome
ACH generally has lower transaction fees than wires, but advertised transfer fees are not a complete cross-border comparison. Ramp’s ACH-versus-SWIFT discussion highlights the additional fee and currency-conversion considerations associated with international transfers.
Request quotes against the same requirement: the recipient must receive the agreed amount in the agreed currency by the agreed date. Compare:
- Sender fees and any expected receiving or intermediary charges.
- The quoted FX rate, its expiration and who performs conversion.
- Whether the beneficiary amount is guaranteed or only estimated.
- Funding deadlines, release cutoffs and expected account credit.
- Charges and procedures for returns, amendments or investigations.
An ACH payment into a vendor’s US collection account can look inexpensive while shifting withdrawal and conversion costs to the vendor. A SWIFT payment can look expensive but avoid an unwanted conversion if the supplier needs to retain the invoice currency. Evaluate the whole path, not only the sender’s debit.
For a deeper cost review, see the framework for reducing cross-border payment fees.
Hypothetical example: an overseas supplier provides two accounts
A supplier invoices in USD and offers both US receiving details and a USD account at its home-country bank.
The US details may support ACH, but finance should verify that the supplier accepts payment there as fulfillment of the invoice, that the account accepts the intended business credit, and that any required allocation reference can be transmitted.
The overseas USD account may require an international wire. Finance should establish whether fees could reduce the amount credited and whether the supplier can receive USD without automatic conversion.
Neither route wins automatically. ACH may be preferable when the supplier wants funds in its US receiving account. SWIFT may be preferable when the supplier needs USD directly in its overseas operating account. Document the supplier’s accepted destination rather than choosing solely from its country of incorporation.
Pre-release checklist for finance operations
- Confirm the payment obligation. Record the invoice currency, required recipient amount and due date.
- Confirm destination eligibility. Verify account country, receiving currency, accepted transfer methods and payer restrictions.
- Validate method-specific details. Check ACH or wire routing instructions, SWIFT/BIC, account identifiers and required references.
- Resolve international classification. Obtain the bank’s or provider’s requirements for IAT and other cross-border information where applicable.
- Confirm available funding. Separate the funding ETA from the recipient-delivery ETA.
- Verify changed instructions independently. Use an established contact channel, not the contact details supplied in the change request.
- Define completion and recovery. Know which event proves credit, how returns appear and who handles a trace or recall.
Do not treat recovery as a substitute for verification. As Plaid’s ACH and wire comparison explains, the methods differ materially in processing and reversibility. ACH reversals and returns are governed by specific rules; they are not an unrestricted undo function. A wire recall request does not guarantee recovery.
Make receiving capability part of every payout record
The best answer to “ACH, wire or SWIFT?” starts with verified receiving capability. Store eligible methods, accepted currency, instructions and funding dependencies alongside each beneficiary—not as assumptions buried in an invoice email.
Then compare cost and timing only among eligible options. Payouts.com’s payout automation brings global payment execution into a unified money workflow. Before automating your next batch, review beneficiary records for missing method-specific instructions: those gaps should be resolved before release, not after a payment fails.
Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.
Discussion
39 commentsRelated resources
How to Pay International Contractors: A Country-by-Country Bank Payment Guide
A successful contractor payment delivers the agreed amount—not just a completed transfer instruction. Build a country-specific payment plan around bank details, currency, fees, and the date funds become available.
How to Reduce Cross Border Payment Fees: A Finance Playbook
Lower transfer fees do not always mean cheaper payouts. Learn how to negotiate, operationalize, and verify savings across your international payment program.
Xero Supplier Payment on Account: Record and Allocate Advances
A supplier advance should remain visible until it is allocated or refunded—not disappear into a reconciled bank transaction. Here is how to manage that workflow in Xero, including cross-border payment checks.
Run your entire money cycle on one ledger
Global payouts, AP/AR automation, and AI agents with their own wallets and spend limits.
Get started
The statement that 'a SWIFT/BIC identifies an institution while an IBAN identifies the account' oversimplifies routing for non-IBAN countries. We pay suppliers in Thailand, India, and Hong Kong regularly and the receiving instructions vary wildly—sometimes SWIFT/BIC plus local account number, sometimes SWIFT plus IFSC or branch code, sometimes a clearing code system that has nothing to do with IBAN. Would be helpful to address how teams should structure their data model when half your payee countries don't use IBAN at all.
Agreed, the article's SWIFT/IBAN framing works for Europe but breaks down fast in APAC. We maintain a country-specific routing field matrix now—some need SWIFT plus IFSC, others need branch codes, and a few still require physical branch addresses for compliance. The lack of standardization makes validation at onboarding the only scalable approach.
Same experience with APAC payments. The article's framing is still useful as a first-pass filter, but you're right that the actual field requirements need to be looked up per country. We maintain a separate reference table that maps destination country to required field set, and even that needs quarterly updates.
The distinction between funding availability and delivery method is something we learned the hard way. We had a provider who advertised 'same-day international payments' but buried in the fine print was that our ACH funding took two days to clear on their side before they'd initiate anything. The recipient's bank was fast, but we were still missing SLAs because we were measuring the wrong leg.
We ran into nearly the same issue with a provider advertising 'next-day' delivery. Turned out they meant next day after their internal funding settlement, which itself was T+2 from our ACH push. Now we ask every provider to document both legs with actual calendar-day examples before onboarding.
We ran into nearly the same issue with a provider advertising 'next-day' delivery. Turned out that was next-day after their internal reconciliation team validated our wire funding, which added another 12-24 hours we hadn't budgeted for. Now we always ask providers to break down the timeline into funding receipt, funding availability, and beneficiary credit windows separately.
The part about separating the vendor's legal address, the receiving bank's country, and the account's supported currencies is more complicated in practice when you're dealing with payment service providers that layer their own accounts in between. We collect all three fields now but still run into cases where the PSP changes the underlying rails without notice and suddenly a 'local' payment routes through a correspondent.
We started flagging those as intermediary accounts in our system and requiring a fourth field for the ultimate beneficiary country. Doesn't solve the whole problem but at least surfaces when the provider's pooled account sits in a different jurisdiction than where the money actually ends up.
We map the provider's own account details separately in our vendor record and treat it as an intermediary leg. Helps with reconciliation but doesn't fully solve the currency path question when they're converting through their own book before final delivery.
The framing around 'start with the account, not the vendor's address' is the cleanest articulation of this problem I've seen. We've been burning cycles arguing with AP staff who want to route based on the supplier's registered country, and this gives me a better way to structure that conversation internally.
We had the same problem and used this exact framing in our last AP process review. What helped was adding a checklist question during vendor setup: 'Does this account accept the transfer type you intend to use?' Forced the conversation upstream before the first payment attempt.
We had the same problem and used this exact framing in our last AP process review. What helped was creating a payment method eligibility matrix that forces the team to collect account type, currency, and supported rails before vendor country even enters the decision tree. Reduced our routing errors by about 60% in the first quarter.
The section on validating bank details for the selected method is spot on. We wasted two weeks last quarter chasing a failed wire because our vendor portal allowed freeform entry and the supplier gave us their ACH routing number in the wire instruction field. Now we have method-specific forms with field validation, but I wish more payout platforms enforced this at the API level instead of passing garbage through and letting it fail at the bank.
We went through the same pain and ended up building a workflow that requires the vendor to select the payment method first, then the form fields change based on that selection. Still doesn't prevent them from choosing the wrong method entirely, but at least the field labels match what we're actually collecting.
Same lesson here. We added field-level validation that checks the routing number format against the selected method, but the real fix was splitting the collection flow entirely. ACH form asks for account and routing, wire form asks for receiving bank name and wire routing, international asks for SWIFT/BIC and correspondent if needed. Cut our failure rate by about 70%.
The point about US banks using different routing numbers for ACH versus wire transfers is something that tripped us up during an audit. We had stored a single routing number per vendor and assumed it worked for both methods, which delayed several urgent payments when we switched a contractor from ACH to wire for a time-sensitive milestone. Now we explicitly collect and validate both sets of instructions during onboarding, even if we only plan to use one method initially.
Same experience. What helped us was treating wire instructions as a completely separate payment method in our vendor master rather than a routing variation. Now we require vendors to submit wire details through a distinct form that explicitly states it's for wire only, and we flag accounts where we only have one or the other.
Same issue here. We ended up creating separate fields in our vendor master for ACH routing, wire routing, and SWIFT/BIC after a similar situation. The annoying part is that some regional banks do use the same number for both, so vendors push back on providing duplicate info even when it's actually needed.
The vendor portal approach for collecting method-specific instructions makes sense, but how do you handle cases where vendors push back on providing multiple sets of banking details upfront? We've had suppliers refuse to give us wire instructions until we actually need to send a wire, which defeats the whole validation workflow.
We added a clause in our payment terms that says we'll default to the slowest available method if we don't have complete instructions on file. That usually motivates them to provide wire details upfront, especially for larger vendors who prefer faster settlement options when needed.
We added a clause in our vendor agreements requiring full banking details for all payment methods available to them within 30 days of onboarding. The ones who still refused, we marked as wire-only in our system and routed everything through the more expensive method—finance leadership was fine with that once we showed them the operational cost of chasing details on demand. Most vendors comply once they realize delays hit their own cash flow.
The distinction between funding leg and delivery leg is critical and something most AP automation tools completely gloss over. We've had situations where a provider confirms receipt of our wire within hours but the actual beneficiary credit in Brazil took four days because of local banking holidays and their funding cycle with the local partner. Would be helpful to see providers surface both timelines upfront rather than burying it in support tickets after the vendor starts asking where their money is.
This is why we now require providers to expose both the provider-receipt timestamp and the beneficiary-credit timestamp through their API. The SLA should always be measured against the second one, not the first, but most contracts are written ambiguously enough that you can't enforce it.
We've seen this exact scenario with India payments. The provider's SLA clock stops when they receive our funds, but their delivery SLA is often buried in a separate document with different terms. Now we track both timestamps separately and only consider the payment complete when the beneficiary confirms credit in their statement.
The IAT classification piece is still ambiguous even after reading this. If a US employee of a foreign parent company receives payroll via ACH to their US bank account, does that trigger IAT treatment because the employer is foreign? Our payroll provider gave us three different answers on this and we're still not sure we're compliant.
The receiving institution being US-based is key here. If the ACH entry credits a US bank account and settles entirely through the US ACH network, it typically wouldn't meet the IAT definition even if the originator is foreign. The foreign parent's location matters less than whether a foreign financial agency participates in the payment chain. That said, your payroll provider should have a definitive answer based on how they structure the entries, not three conflicting ones.
Nacha's IAT definition hinges on whether a foreign financial agency is part of the payment chain, not just the employer's domicile. If the US employer entity is the ODFI customer and the employee's US account is the receiver, that's typically domestic. But if funds originate from a foreign account or the foreign parent is the actual originator in the ACH file, you're likely in IAT territory. Your payroll provider should be looking at the originating depository financial institution relationship and where the debit occurs.
The provider funding versus delivery distinction finally clicked for me after reading this. We had been troubleshooting ETAs with our payout vendor for months assuming the delay was on their side, but it turned out our ACH funding wasn't settling in time for them to hit same-day local rails in the destination country. Nobody on either side was mapping those two legs separately in the SLA conversation.
We had a similar issue with SEPA payments to EU contractors. The provider would accept our same-day wire but then batch outbound deliveries overnight, so the 'instant' service we paid for was irrelevant. Now we ask for the provider's batch cutoff times upfront and schedule funding accordingly.
We had a similar issue with SEPA payments to EU contractors. The provider would accept our wire funding same day but wouldn't batch the SEPA leg until the following morning, so we were always a day behind what the marketing materials promised. Now we just fund T-1 and the timing works.
Would appreciate more detail on the IAT classification question. We have a handful of Canadian contractors with USD accounts at Canadian banks, and our bank keeps flagging some as IAT and others not, even though the structure looks identical to us. The inconsistency makes it hard to build reliable automation rules.
We hit the same thing with Mexican contractors holding USD accounts. Best explanation I got was that the IAT determination depends on the correspondent banking chain, not just where the account sits. If the receiving bank uses a US correspondent for USD settlement, some systems treat it as domestic with foreign beneficiary. If it settles offshore, IAT. Your bank may be looking at different correspondent arrangements even when the surface details look the same.
We hit the same thing with Mexican contractors holding USD accounts. Best explanation I got from our bank was that the IAT determination depends on whether the receiving institution has correspondent relationships that trigger cross-border reporting, not just the account currency or contractor address. Still frustratingly opaque.
This is a useful framework but misses the reconciliation burden. When you're routing 300+ monthly payouts through mixed methods—some ACH, some local rails via a provider, some SWIFT—the back-end matching becomes a nightmare because each system returns different status codes and reference formats. The operational cost of that complexity often outweighs the per-transaction savings from optimizing the rails.
Agreed, and the status normalization problem gets worse when you layer in compliance holds. A domestic wire might clear in hours but show 'pending' in your provider's dashboard for two days while they run screening, while a local rail in Mexico posts same-day with a cryptic Spanish reference code your ERP can't parse without manual intervention.
Exactly this. We solved part of it by requiring providers to include our internal reference ID in their callback webhooks, but even then you're still manually mapping SWIFT MT103 fields to local rail confirmations. The article's point about asking which status confirms recipient credit is critical—we stopped reporting a payment as complete until we see beneficiary confirmation, not just our provider's debit.
The point about US routing numbers differing for ACH versus wire is something our AP team learned the hard way last quarter. We delayed a critical supplier payment by 48 hours because we assumed the ACH routing on file would work for a wire transfer. Now we have separate validated fields in our ERP for each method.
We went through the same pain and ended up building a workflow that requires the vendor to specify which method they want payment through, then we only collect the relevant fields for that method. Cuts down on the guesswork but added friction to onboarding.
We built a separate wire instruction collection form after the same issue. The frustrating part is some smaller banks actually do use the same routing number for both, which made our team assume it was universal. Now we validate both methods during onboarding even if we only plan to use ACH initially.