Your US client says:

Send me your bank details and I’ll get the invoice paid.

Do not reply with a screenshot of your banking app.

Send a short, copyable payment-instruction block that tells the payer exactly who to pay, in which currency, through which payment rail, which account identifiers to use and what reference to attach to the transfer.

For most international client payments, the seven things to confirm are:

The exact fields depend on the route. An ACH payment from a US client should not be given wire instructions merely because both payments are in dollars.

If you have not chosen the route yet, first check how Nigerian freelancers can get paid by US, UK and EU clients. A US payer may need ACH or domestic-wire details, while UK and European payment routes use different account identifiers.

And if the client specifically asks whether they should use ACH or wire, the answer should come before you send the account numbers. The ACH vs wire guide for Nigerian freelancers explains why the two rails can have different routing details, fees and failure modes.

First, ask one question: “How are you sending the payment?”

“Bank transfer” is too vague. Before you give a client any account details, ask which transfer method their finance team plans to use. For a US client, that may be:

• ACH credit;

• domestic wire;

• an international wire;

• a payroll or contractor platform;

• a payment provider that asks for US account details.

Why does this matter?

Because a routing number is not a universal address for every kind of US payment. The Federal Reserve maintains routing information separately for FedACH and Fedwire participants. In other words, the fact that a receiving institution participates in one payment rail does not prove that your specific account and instructions support another. Your provider may:

• support ACH but not wire;

• provide separate ACH and wire routing numbers;

• accept domestic US payments but not international SWIFT;

• restrict which payer types can send to the account;

• require extra information for a particular route.

Use the payment instructions for the exact route.

The 7 bank details to send an international client

1. Beneficiary name

Send the beneficiary name exactly as it appears in your current receiving-account instructions. Do not casually shorten it. If your account says:

Adaeze Chiamaka Okafor

do not send:

Ada Okafor

unless the provider explicitly tells you that variation is acceptable. For a business account, use the business beneficiary name if that is what the receiving instructions show. This name can matter when:

• the payer creates you as a vendor;

• the payer’s bank asks for the recipient name;

• the payment platform checks account ownership;

• support later needs to compare the submitted payment with your account record.

Copy it from the live account screen rather than typing it from memory.

2. Currency

Write the currency explicitly. Use:

Currency: USD

rather than assuming the client understands $ to mean US dollars. This becomes more important when you work with clients across several countries or maintain several receiving currencies.

A USD account number should not be treated as a generic destination for GBP or EUR unless the provider explicitly supports that route.

The currency on your invoice should also agree with the payment instructions. If the contract says USD 2,000, avoid sending a separate payment message that makes the client guess whether they should pay dollars or convert the amount first.

If you need a full invoicing workflow, use the guide to invoicing a US client from Nigeria in USD.

3. Transfer method

State the rail by name. For example:

Transfer method: ACH credit

or:

Transfer method: US domestic wire

Do not write:

Transfer method: bank transfer

if your provider gave you route-specific instructions. This one line prevents a common payment problem: a client sees US account details, chooses whichever bank-transfer button seems familiar and submits the payment through a rail the receiving account does not support.

For recurring client payments, the payer should know the exact route before saving your details in their finance system.

4. Account number or IBAN

Now provide the actual account identifier issued for that route. For a US receiving route, this will often be an account number. For an IBAN-based route, use the full IBAN exactly as issued. Do not:

• retype it from an old invoice if you can copy it from the current account;

• remove leading zeros;

• insert digits manually;

• substitute an IBAN for a local account number;

• assume an old account remains active after a provider change.

If you use walllet.com receiving details, the walllet.com IBAN Account guide explains an important distinction: an IBAN identifies an account, but the identifier alone does not prove that every currency, payment scheme or payer type is supported.

5. Routing, clearing or bank identifier

The next field tells the banking system where the account sits. Its name depends on the payment route.

Do not assume the ACH routing number and wire routing number are identical.

Do not search Google for the bank's routing number and replace the one your account provider gave you.

The correct source is the current receiving instruction for your account and your payment method.

6. Bank or provider details required by that route

Some payment forms ask for more than the beneficiary and account identifiers. Depending on the route, the payer may be asked for:

• bank name;

• bank address;

• beneficiary address;

• account type;

• intermediary-bank instructions;

• branch or clearing information.

Only send fields that your provider supplies or confirms. Do not fill a required-looking box by guessing.

For international wires in particular, payment messages can contain beneficiary name, account details and institution information. Current Fedwire guidance also distinguishes creditor/beneficiary information from the bank identifiers used to route the payment.

If a client’s finance portal asks for a field that is not present in your receiving instructions, ask your provider what belongs there before the client sends the money.

7. Payment reference

Give the payment a reference that both you and the client can recognize later. For freelance work, the invoice number is usually the cleanest option:

Payment reference: INV-2026-041

Use the same reference in:

• the invoice;

• your payment instructions;

• the client’s transfer memo where the rail permits it;

• your own payment records.

A useful reference makes a later support conversation much easier. Compare:

My $1,850 payment from a client hasn't arrived.

with:

USD 1,850, invoice INV-2026-041, sent by ABC Labs through ACH on September 1.

The second case gives the bank or payment provider something specific to investigate.

Copy this payment-instruction block

For a US client paying by ACH:

PAYMENT INSTRUCTIONS

Beneficiary name:

[Exact beneficiary name]

Currency:

USD

Transfer method:

ACH credit

Routing number:

[Current ACH routing number]

Account number:

[Current account number]

Account type:

[Only if your provider specifies one]

Bank / provider:

[Name shown in your payment instructions]

Payment reference:

[Invoice number, e.g. INV-2026-041]

Amount:

USD [amount]

Important:

Please use ACH credit only. If your bank cannot use this payment method, please contact me before sending the payment.

For a domestic wire, change the transfer method and use the wire instructions supplied for the account. Do not take the ACH block above, replace “ACH” with “wire,” and leave everything else unchanged.

Why a screenshot is a poor way to send bank details

A screenshot feels convenient because all the information is already visible. It creates several operational problems.

The client has to retype the numbers

Account and routing numbers in an image are not reliably copyable. One mistyped digit can turn a straightforward payment into a return, rejection or investigation.

The screenshot may contain too much information

An account screen can expose data the payer never needed:

• balances;

• transaction history;

• other account identifiers;

• internal IDs;

• notifications;

• profile information.

Payment instructions should contain the minimum information required to complete the payment.

The screenshot may not tell the client which rail to use

A picture showing:

Routing number: XXXXXXX

does not necessarily tell an accounts-payable employee whether that routing number belongs to ACH or wire instructions. Label the route explicitly.

Screenshots go stale

You may still have an old image in WhatsApp, Slack, email or your Downloads folder months after your provider updates the receiving details. Current instructions should come from the live account. This is particularly important after:

• an account migration;

• a banking-partner change;

• account replacement;

• a new currency account;

• closure or reissuance of receiving details.

If an ACH payment is sent to old or invalid details and comes back, use the ACH return-code guide for freelancers to identify whether the problem relates to a closed account, invalid account number, refusal or another return reason.

Should you put bank details directly on your invoice?

You can include payment instructions on the invoice when bank transfer is the agreed route, but keep them structured and current. A good invoice payment section might say:

Payment method: ACH credit
Beneficiary: [Exact beneficiary name]
Routing number: [Current ACH routing number]
Account number: [Current account number]
Reference: INV-2026-041

There are three situations where I would separate the detailed payment instructions from the invoice:

The payment details have recently changed.
Send the updated instructions through the agreed channel and make the change obvious.

The client's procurement system has its own bank-information workflow.
Use the vendor portal instead of forcing the accounts-payable team to copy details out of a PDF.

The document will be widely forwarded.
An invoice may pass through project managers, procurement, bookkeeping and external accountants. Do not expose more financial information than those people need.

The goal is not to make payment details secret. The goal is to control which information you share, keep it current and make the payer's instructions unambiguous.

How to share bank details more safely

Bank payment details are different from banking credentials. A client may legitimately need your beneficiary name, routing details and account number to pay you. They do not need:

• online-banking password;

• PIN;

• card PIN;

• CVV;

• one-time password;

• authenticator code;

• passkey;

• recovery code;

• answers to security questions.

Never add those to an invoice or payment-instruction document. The bigger practical risk for businesses is often payment redirection.

A criminal compromises or imitates an email account and tells the payer that the beneficiary's bank details have changed. The FBI's Internet Crime Complaint Center specifically recommends using a secondary channel or two-factor verification to confirm requests to change account information. So if you change bank details for an existing client:

1. Do not bury the change inside a normal invoice.

2. State clearly that the payment instructions changed.

3. Ask the client to verify the change through a known channel.

4. For an important payment, confirm it by a phone number, Slack account or other contact method the client already trusts.

5. Do not use contact information contained only in the unexpected “new bank details” message to perform the verification.

The same rule protects you when the situation is reversed. If a client suddenly sends new instructions about refunds, overpayments or money you are supposed to send back, verify them independently.

If your client is ready to pay and you want to see which receiving routes are currently available for your account, check your walllet.com receiving options before you send the payment instructions.

ACH details vs wire details: do not mix them

For a US client, this deserves its own check. A payer may see both options in online banking:

ACH

and:

Wire

These are different payment rails. A simple instruction sheet should make the difference obvious:

Some accounts use the same account number across both routes. Some do not. Some institutions use one routing number for both. Others distinguish them.

The right answer is whatever the receiving provider currently shows for that account. This is also why “Here are my US bank details” is weaker than “Here are the ACH instructions for invoice INV-2026-041.”

What if the client is outside the US?

Do not automatically send your US ACH details to every overseas payer. Start with the payer’s available route.

A company in London might prefer a UK local transfer.
A eurozone payer might use SEPA.
A US company might use ACH.
A multinational company may send a SWIFT wire.

Then check whether your receiving account supports that exact route.

If your client must send an international wire and the money later appears short, intermediary banks may be one reason. The guide to what a $1,000 freelance payment really costs explains how deductions can occur before the money reaches the final receiving provider.

What should the client send you after payment?

Agree on the proof before there is a problem. For a normal payment, ask for enough information to identify the transaction:

• amount;

• currency;

• date sent;

• payment method;

• invoice/reference number;

• sender name;

• bank or platform confirmation if needed.

Do not assume a screenshot saying Paid proves the money reached your account. It proves, at most, what the sender's interface says at that moment.

If an international wire does not arrive, you may eventually need more formal payment evidence such as the transfer reference, UETR or MT103 information depending on the route. A client-facing receipt and a bank-trace document serve different purposes.

Before you send the details, run this 60-second check

Payer:
Who is sending the money: the client personally, their company, an agency, payroll provider or platform?

Currency:
Does your instruction say USD, GBP, EUR or another exact currency?

Rail:
Did you explicitly name ACH, wire, SWIFT or the required local route?

Beneficiary:
Does the name match the current receiving instructions?

Account identifiers:
Did you copy them from the live account rather than an old PDF or screenshot?

Payer restrictions:
Does the account accept this type of sender and payment?

Reference:
Did you give the client a unique invoice/reference number?

Fee responsibility:
If transfer costs matter, have you agreed who pays them?

Evidence:
Do you know what confirmation to request after the client sends the payment?

Fallback:
If the payer cannot use this route, have you told them to stop and ask rather than improvise another transfer method?

If any answer is uncertain, fix that before the client presses Send.

A payment instruction should be boring

A good payment instruction does not need branding, an app screenshot or a long explanation.

It should let an accounts-payable employee copy the correct fields into the correct payment form without asking you another question. Use this order:

Beneficiary → Currency → Transfer method → Account identifier →  Routing / bank identifier → Required bank/provider information → Payment reference → Then add one short instruction:

If your finance team cannot use the payment method above, please contact me before sending funds.

That sentence is far cheaper than troubleshooting a payment that travelled through the wrong rail. Your client should not have to guess how to pay you. See the receiving routes available in walllet.com, keep your global income in the form you need, and use supported options to spend, convert or cash out in Nigeria.