How to send bank details to an international client

Your client has approved the work. Now someone in finance asks for your bank details.

You could reply with an account number. But an international payment may also need a specific transfer method, beneficiary name, bank identifier, reference, and currency. If the person paying receives an incomplete instruction, they have to fill the gaps themselves—or send another email.

The best payment handover is a short, complete instruction that survives being forwarded to someone who has never spoken to you.

This guide explains which details matter, why the fields differ across countries, how to share them safely, and what to ask for after a client sends the payment. It includes an email template and examples you can adapt without relying on any particular payment platform.

First agree how the client will pay

Before collecting identifiers, settle three questions: which currency the client will send, which payment method they will use, and which receiving account or service will accept it.

A client asking for “international bank details” might mean a SWIFT transfer from their bank. They might also have access to a local transfer service, a corporate payment platform, or an existing vendor-payment process. Those are different instructions.

For example, a U.S. client may be able to send USD to local U.S. receiving details by ACH. Another client may only be able to send an international wire. An account number that works for the first route should not be assumed to work for the second.

Ask the client’s accounts-payable contact what they can actually send. Then obtain the matching instructions directly from your bank or payment provider. If no compatible route exists, resolve it before the due date rather than translating fields yourself.

A useful first message is: “Our invoice is in EUR. Can your finance team pay by SEPA bank transfer, or do they require international wire instructions?” Adapt the currencies and methods to the options you really have.

The details an international payment may require

The required fields depend on the route. Use this table to understand their roles, not as a universal form that every payer must complete.

Detail	Why it matters
Beneficiary or account-holder name	Identifies the person or entity specified by the receiving institution.
Account number or IBAN	Identifies the receiving account under the relevant system.
Routing, sort, or bank code	Helps identify the financial institution or domestic routing destination.
BIC or SWIFT code	Identifies an institution or business party in financial messaging.
Currency	Tells the payer which currency the receiving route accepts for this payment.
Transfer method	Distinguishes, for example, a domestic ACH payment from an international wire.
Required payment reference	Helps allocate funds when the receiving instructions require it.
Beneficiary or bank address	Supplies address information when requested for the specific route.
Intermediary instructions	Supplies additional routing information only when the receiving institution provides it.

Do not combine details from different accounts just to fill every field on a form. A bank address found online, a routing number from an old statement, and a new virtual account number do not necessarily form a valid set of instructions.

If a mandatory field is absent from the instructions you were given, ask the issuing institution how the payer should proceed.

Understand the identifiers before copying them

IBAN identifies an account under an international standard

An International Bank Account Number follows a country-specific format within the IBAN standard. It is more than a label placed in front of an ordinary account number. Swift maintains the official IBAN registry as the registration authority for the standard. Swift: International Bank Account Number.

An IBAN’s format does not establish which currencies the account accepts or whether a particular platform permits the intended payment. A format check also does not prove that the account belongs to your intended recipient.

Use the IBAN supplied by the receiving institution. Do not generate an IBAN from a domestic account number using an unverified website.

A BIC identifies an institution, not your individual account

A Business Identifier Code is often called a SWIFT code in banking interfaces. Swift explains that BICs identify business parties and can include an optional branch identifier. Not every BIC is connected to the Swift network. Swift: Business Identifier Code.

This matters because a BIC and an IBAN perform different jobs. Providing one does not automatically replace the other when both are requested.

Domestic identifiers depend on the country and rail

For UK domestic payments, the combination commonly includes the payee name, sort code, and account number. Some account arrangements also require secondary reference information. Pay.UK’s Confirmation of Payee explanation describes how those details can be checked together.

In Mexico, Banco de México identifies the 18-digit CLABE as one identifier used for SPEI transfers, alongside other supported options in participating institutions’ services. Follow the actual account’s instructions rather than substituting a card number or phone number simply because the broader system can support them. Banco de México: SPEI information.

The same principle applies elsewhere: local payment systems use their own identifiers and rules. Your client’s banking form is not a universal dictionary for translating between them.

For a field-by-field reference across all six currencies, read IBANs, BICs, routing numbers, and local identifiers. Format checks and beneficiary verification answer different questions.

Use the exact beneficiary name

Your brand name, invoice issuer, trading name, and receiving account-holder name can be related without being identical.

Suppose a fictional studio trades as “North Studio,” while its account is registered to “North Studio Design Limited.” The client should use the name specified in the receiving instructions, and the studio should explain the connection in its vendor information if needed.

Payment-service arrangements can introduce another distinction: an account may be identified by a provider-issued number or a required allocation reference. That does not give you permission to replace the specified beneficiary name with your preferred brand name.

If the client receives a name mismatch warning, investigate it. Do not instruct them to ignore the warning simply because you recognise the account number. Confirm the details through your bank or provider and the client’s existing contact channel.

For a company client, do this during vendor setup. Discovering a name mismatch on the payment due date can turn a simple correction into another approval cycle.

Keep the invoice number separate from a required reference

An invoice number identifies the commercial request. A receiving reference may identify where an incoming transfer should be allocated. Sometimes an invoice number is an appropriate transfer reference; sometimes a different value is mandatory.

Here is a fictional example:

• The invoice is NS-2026-018.
• The receiving provider requires the payment reference EXAMPLE-572.
• The client should use EXAMPLE-572 in the transmitted field specified for that route.
• The client can send remittance advice identifying invoice NS-2026-018 separately.

Adding the invoice number to a mandatory reference can change the value the receiving system expects. So can removing spaces, truncating text, or typing a friendly project description instead.

Your instruction should label the values clearly. Read payment references explained for more examples, including partial payments and one transfer covering several invoices.

Write an email the finance team can act on

A useful handover contains the payment request, the complete route instructions, and a way to resolve questions before sending. Keep the actual account values together so the recipient does not need to reconstruct them from a conversation.

Use the following template only after replacing the brackets with verified instructions. Remove fields that your route does not require.

The template intentionally does not ask the client to choose your later withdrawal method. Their task is to send the agreed payment correctly. Your internal conversion or payout decision can remain separate.

Adapt the handover to the client’s process

A single email is not always the final instruction. Larger organisations often maintain supplier records that outlive the employee who first hired you.

Ask whether the client needs a vendor form, purchase-order number, supplier ID, or invoice upload. Find out who owns the supplier record and who approves changes. Give those people a complete set of instructions rather than assuming the project contact will forward everything.

Consider a fictional designer whose project manager accepts the invoice on Monday. The finance team pays only approved supplier records on Thursday. If the new receiving details are still awaiting verification, the payment may miss that run even though the invoice itself is correct.

A practical handover therefore has two acknowledgements:

1. Commercial acknowledgement: the invoice and amount have been accepted for payment.
2. Operational acknowledgement: the finance team has the correct payment instructions and can use them.

Neither acknowledgement proves a transfer has been sent. They simply help you locate the next responsibility without repeatedly asking everyone for an update.

Share payment details without sharing account access

Receiving instructions are meant to be given to legitimate payers. Login credentials, one-time codes, recovery codes, and wallet seed phrases are not payment instructions.

Use the client’s established supplier portal or verified contact channel when available. Limit documents to what is necessary for the stated purpose. For example, if a client needs proof of account ownership, ask your bank for an appropriate confirmation rather than immediately sending a full statement containing unrelated transactions.

Bank details still deserve care. They can reveal personal or commercial information, and a convincing message containing real details can be reused in fraud. Avoid publishing private receiving instructions in public support threads or broadly accessible documents.

For recurring clients, keep a dated source of truth. When instructions change, identify the superseded version and make sure the authorised finance contact updates the saved payee. An accurate new email does not remove an inaccurate old vendor record.

Treat changes to payment instructions as a separate check

Business email compromise can involve fraudulent messages inserted into a believable invoice conversation. The FBI recommends verifying changes to account numbers or payment procedures directly and using contact information obtained independently of the suspicious request. FBI: Business email compromise.

Build the check into ordinary operations. Tell clients in advance how you will confirm genuine changes. For a larger business, consider having one person request a supplier update and another approve it.

If the email account used for the existing conversation might be compromised, replying to the same thread is not independent verification. Use a contact method that was already established outside the change request.

A small successful test payment can check a permitted route, but it does not prove that an instruction change was legitimate. Verify the destination first, and use test payments only where the institutions and transaction limits allow them.

What to request after the client sends the payment

Ask for useful evidence, not an unfiltered screenshot of the client’s finances.

A transfer confirmation should help establish the amount and currency sent, submission date, beneficiary, payment method, and the available tracking identifier. The client should remove unrelated balances or transactions before sharing it through an appropriate channel.

Different rails use different identifiers. An ACH trace number, a U.S. wire’s IMAD, and a SWIFT UETR are not interchangeable. A reference entered by the client may identify the invoice without providing the bank’s tracking information.

Keep your acknowledgement precise: “Thank you, we have received the sending confirmation and will check for the incoming payment.” Only confirm receipt after checking the relevant receiving records.

If the transfer is delayed, compare the actual method and submission time with the provider’s processing window. “Sent Friday evening” is not enough to establish that a business-day route has missed its expected timeframe.

Fix common problems at the right stage

Problem	Useful next step
The bank requires a SWIFT code, but the route only provides local details	Confirm whether the payer selected the wrong transfer type or needs a different supported route.
The beneficiary name produces a warning	Verify the registered name and account arrangement before sending.
A required reference does not fit	Ask the sender’s bank and receiving provider how to proceed; do not abbreviate it yourself.
The client used saved details from an old invoice	Compare the submitted beneficiary with the current instructions and contact the relevant institutions.
The client says “paid,” but no incoming transfer appears	Request the actual sending confirmation and tracking information, then investigate the existing payment.
Less arrived than the invoice amount	Check the sent amount, deductions, conversion, and agreed fee allocation before asking for a balance payment.

Do not ask for a second transfer merely because the first is not visible. First establish whether the original payment is pending, rejected, returned, or credited somewhere unexpected. Two unresolved transfers are harder to reconcile than one.

Frequently asked questions

Can I send bank details by email?

A legitimate payer needs receiving information, and email may be part of an agreed process. Use verified contacts, include only necessary information, and independently verify changes. Prefer an established supplier portal if the client provides one. Never include account access credentials.

Do I always need both an IBAN and SWIFT code?

No. The combination depends on the account, countries, and route. Some domestic instructions use entirely different identifiers. Follow the issuing institution’s instructions rather than assuming every international commercial payment uses SWIFT.

Can I use my trading name as the account-holder name?

Use the name specified for the receiving account or service. If a trading name is supported, obtain confirmation from the institution. Explain differences in vendor documentation rather than changing the receiving instructions yourself.

Should the client pay in my currency or theirs?

Agree that commercially before sending the invoice. Compare the exchange rate, fees, and receiving compatibility for both choices. Our international client payment planning guide explains the currency and cash-flow trade-offs.

Does a confirmation email prove the money arrived?

No. It may show that a request was submitted or accepted. Check the payment’s actual status and your receiving records. Keep submission, receipt, and availability distinct when communicating with the client.

Before sending your next handover, forward a copy to yourself and read it as the finance team would. If it needs earlier messages to explain the currency, destination, or required reference, complete those details first.