Your client says the transfer was sent. They send a screenshot. Their account may already show a debit. On their side, the payment looks finished.
On your side, nothing has arrived.
This is where the conversation often becomes frustrating. The client repeats that they paid. You repeat that you have not received the money. Both statements may be true. A screenshot cannot tell you whether the payment is still with the sender’s bank, moving through an intermediary bank, waiting for a compliance check, rejected by the receiving institution, or already on its way back.
You need the payment’s trace information.
If an international wire has not arrived, ask the sender for a bank-issued payment confirmation and the Unique End-to-end Transaction Reference, or UETR. Depending on the bank’s systems, it may also provide an MT103 document or payment details based on the newer ISO 20022 pacs.008 message. The sender’s bank will usually need to start the formal trace because it originated the transfer. Do not ask the client to send the money again until the original payment has been traced, returned, or formally confirmed as failed.
Before starting a trace, confirm that the client used the correct route. A US client, a UK client, and an EU client may need different payment instructions, even when the invoice is denominated in dollars. The guide to receiving payments from US, UK, and EU clients in Nigeria explains how the sender’s country, currency, rail, and payer type affect the payment details you should provide.
The first ten minutes: check these details
Before asking a bank to investigate, compare what the client entered with the original payment instructions. Check:
The exact beneficiary or account-holder name
The account number or IBAN
The receiving bank or institution
The SWIFT or BIC code, where required
The payment currency
The amount
The transfer method
The invoice or payment reference
The sender’s legal name
The date the transfer was initiated
The value date, if shown
Do not assume that an account capable of holding USD can receive every type of USD payment. The route may accept ACH but not an international wire, or SEPA transfers but not a non-SEPA payment. It may also restrict payments from individuals, unsupported countries, or senders whose names do not match the invoice.
If the payment was sent to an IBAN-based route, check what the walllet.com IBAN account is designed to do before treating the account number itself as proof that the transfer should have worked. Currency support, eligible senders, payment rails, limits, fees, and review rules depend on the receiving provider and the user’s current account status.
A payment can also reach the correct institution and still remain unavailable. The guide to why freelance payments get held, reviewed, or delayed covers the verification, sender, account, settlement, and compliance checks that can interrupt a payment after it has been initiated.
A familiar situation
Imagine that you completed a project on Monday and issued a $2,000 invoice. Your client sent the wire on Wednesday. By Friday, they had marked the invoice as paid and sent you a screenshot from their banking dashboard.
You had planned around that payment. A software subscription is due. Your internet bill cannot wait until next week. Part of the money may be for rent or family expenses.
The receiving account still shows zero.
At that point, “please check again” is not a useful answer. Neither is opening five support tickets with slightly different descriptions.
You need one record containing the correct payment details, one formal trace, one case owner, and a date for the next update.
Screenshot, payment receipt, MT103, UETR: what do you actually need?
These records do different jobs.
Evidence | What it can show | What it cannot prove |
Client screenshot | The client created or viewed a transfer in their banking interface | That the bank released the payment |
Bank payment confirmation | Amount, date, beneficiary and bank reference | That the recipient received usable funds |
MT103 or pacs.008 payment details | Structured information about the payment instruction and route | That the payment passed every bank and review |
UETR | The unique reference used to identify the payment across the Swift chain | That the payment has been credited |
Formal bank trace | The status found by the institutions involved | That the issue will be resolved immediately |
Recipient account statement | Whether a credit reached the account | Whether a missing payment was never sent or was returned elsewhere |
The screenshot is often the start of the conversation. It should not be the end of the investigation.
Managing international income should not require separate systems for receiving money, holding digital dollars, paying for work tools, converting funds, and cashing out. Explore walllet.com for global income management.
What is an MT103?
An MT103 is a Swift message used for a single customer credit transfer. It records structured information about an international payment, including details about the sender, beneficiary, amount, currency, banks, references, and charge instructions.
It is sometimes described as proof of payment. That description needs a limit.
An MT103 can help show that a payment instruction was created and transmitted with certain details. It can help banks identify the transfer and investigate where it went. It does not automatically prove that the beneficiary’s account was credited or that the funds are available.
A payment can still be:
Waiting at an intermediary institution
Under compliance review
Rejected because of incorrect details
Held because the beneficiary could not be identified
Returned to the sender
Credited by one institution but not yet reflected by the receiving service
Swift identifies MT103 as the traditional Single Customer Credit Transfer message. Cross-border payment instructions on Swift have since moved to ISO 20022, where the related customer credit transfer message is pacs.008. A bank may therefore provide an MT103-style confirmation, a pacs.008 document, or another customer-facing transfer report generated from its payment system. The exact document name matters less than whether it contains the information needed to identify the payment.
What is a UETR?
UETR stands for Unique End-to-end Transaction Reference. It is a unique 36-character reference attached to payment instructions carried over Swift. Banks use it to identify the same payment as it moves through the institutions involved in the transfer. It usually looks similar to this:
123e4567-e89b-12d3-a456-426614174000
That is only an example format, not a real payment reference. The UETR is different from:
Your invoice number
The client’s internal payment reference
A transaction number generated by a payment app
Your account number
A support ticket number
The beneficiary reference displayed on a receipt
Those identifiers may help the sender or recipient reconcile the payment. The UETR is the identifier used within the relevant Swift payment chain. Swift’s tracking services use the UETR to help participating financial institutions follow payment status and confirm outcomes such as credit, rejection, transfer outside Swift, or a payment being placed on hold. These tracking tools are primarily used by Swift customers and financial institutions. A freelancer normally gives the UETR to the banks or payment providers involved rather than tracking the transfer through a public consumer search page.
MT103 vs UETR
MT103 or pacs.008 payment details | UETR | |
What it is | A structured payment message or customer-facing record derived from it | A unique payment identifier |
What it contains | Sender, beneficiary, amount, currency, banks and other payment data | A 36-character reference |
Main use | Understanding and reconciling the payment instruction | Locating the same payment across the transfer chain |
Who can provide it | Usually the sender’s bank or payment provider | Usually the sender’s bank or payment provider |
Can it support a trace? | Yes | Yes |
Does it prove final credit? | No | No |
You may need both. The detailed payment record tells the receiving institution what it should be looking for. The UETR helps the institutions identify the exact payment being investigated.
How to ask your client for the MT103 or UETR
Do not send a vague message saying, “The money is missing. Please check.” Ask for specific records.
Message to send to the client
Hi [Client Name],
The payment has not appeared in the receiving account yet. Could you ask your bank or payment provider for the bank-issued transfer confirmation and the payment’s UETR?
If the payment was sent through Swift, please also request the available MT103, pacs.008, or equivalent detailed payment document.
The document should show the amount, currency, transfer date or value date, sender details, beneficiary details, and bank reference.
Please do not resend the payment yet. We should trace the original transfer first to avoid creating a duplicate.
The client may need to contact their finance team rather than their bank directly. In a larger company, the employee who approved your invoice may not have access to the bank records or authority to open an investigation.
Ask them to involve the person who initiated the transfer or manages accounts payable.
Who should start the trace?
The sender’s bank normally starts the formal trace because it originated the payment. The recipient can and should contact the receiving institution, but that institution may only be able to confirm whether it can see an incoming payment or whether the account has an active review. Use this map:
Situation | Who should act next? |
The client only has a screenshot | Client or sender asks the sending bank for formal proof |
The payment is still pending at the sender’s bank | Sending bank |
The sender used incorrect beneficiary details | Sending bank, after the recipient confirms the correct details |
The payment was released and has a UETR | Sending bank starts a trace; recipient gives the UETR to the receiving institution |
The receiving institution can see the payment under review | Receiving institution or its financial partner |
The payment has been rejected or returned | Sending bank confirms the reason and return status |
The payment was credited but cannot be used | Receiving institution |
A payment platform initiated the transfer | Platform support or its banking partner |
The client paid through a non-Swift route | The provider responsible for that specific rail |
This distinction matters because support teams sometimes push the problem back and forth. The sending bank says the beneficiary should ask their bank. The receiving institution says it cannot search without a trace. The freelancer becomes the messenger between two organisations, while neither one clearly owns the case. The way out is to document the payment and ask each institution a narrow question:
To the sending bank: Has the payment been released, and will you open a formal trace using the UETR?
To the receiving institution: Can you locate an incoming payment with this UETR, amount, currency, value date, and beneficiary name?
Information needed for an international wire trace
Put the following information in one message or document:
UETR
MT103, pacs.008, or equivalent detailed payment record
Sender’s bank reference
Exact amount
Currency
Transfer initiation date
Value date
Sender’s full legal name
Sending bank or provider
Beneficiary’s exact name
Account number or IBAN used
Receiving institution
Invoice number
Payment purpose or reference
Existing support case number
Any rejection, return, or review notice
A statement or screenshot showing that the expected credit is absent
Do not send: Your password, one-time passwords, PINs, card CVV, passkey credentials, private keys, wallet recovery information or full identity documents through an unverified support channel.
The bank may legitimately request identity or source-of-funds evidence. Confirm the request inside the provider’s official app, website, or recognised support channel before uploading sensitive documents.
How to trace a missing international wire
1. Confirm that the payment was actually a wire
Not every international payment uses Swift. A client may have paid by ACH, SEPA, Faster Payments, a platform payout, card, internal transfer, or stablecoin. An MT103 workflow will not help if the payment did not travel through the relevant Swift route.
The guide to receiving USD in Nigeria without PayPal compares several receiving options and helps separate bank-transfer routes from payment platforms and digital-dollar transfers.
2. Compare the beneficiary details
Check the payment document against the details you sent with the invoice. A single difference may matter:
An abbreviated legal name
The wrong account number
An old IBAN
A different currency
An ACH routing number used for a wire
A personal payment sent to a business-only route
An unsupported sender country
A missing or incorrect payment reference
Do not correct these details by editing the receipt yourself. Identify the difference and send it to the bank handling the trace.
3. Get bank-issued evidence
Ask for the document generated by the sender’s bank or payment provider. A screenshot from the client’s banking interface can be useful, but it may show a transfer that is scheduled, pending, cancelled, rejected, or waiting for internal approval. The evidence should show, where available:
Payment status
Amount and currency
Sender
Beneficiary
Date
Bank reference
UETR
Payment route
Charge instruction
4. Give the UETR to the receiving institution
Open one case. Include every relevant fact in the first message. Do not open several tickets with different descriptions unless the provider tells you to create a separate case. Ask the receiving institution to confirm:
Whether it can find the payment in its incoming records
Whether the beneficiary details match
Whether the payment is under review
Whether another institution currently holds the next action
Whether it needs more evidence
When you should expect the next update
5. Ask the sender’s bank to open a formal trace
The client should ask their bank to investigate the payment using the UETR and transfer details. The request should produce a trace or investigation reference. Keep that number.
Do not accept “we have checked” as the entire result. Ask what the bank confirmed:
Was the payment released?
Which institution received it next?
Was it rejected?
Is it on hold?
Was it credited?
Was it returned?
Is the return still in progress?
Which institution owns the next action?
6. Record the current state
Use one of these states:
State | Meaning |
Created | A payment instruction exists but may not have been released |
Pending | The sending institution is still processing or reviewing it |
Released | The payment instruction left the sender’s institution |
In progress | One or more institutions are processing the transfer |
Under review | An institution needs to complete checks before proceeding |
Credited | The receiving institution reports that it credited the beneficiary |
Rejected | An institution refused the payment |
Returned | The payment is going or has gone back to the sender |
Unmatched | The institution received funds but could not apply them to the beneficiary |
Available | The beneficiary can see and use the funds |
A provider may use different wording. Ask what its status means operationally.
“Completed” can mean that the sender’s bank finished its part. It does not always mean that the recipient has usable money.
7. Assign the next action
Write down:
The current payment state
The institution currently handling it
What evidence it needs
Who must send that evidence
The case reference
The date of the last update
The next update deadline
This sounds administrative because it is. It also stops a financial problem from turning into an endless email thread where everyone asks for information already sent three days ago.
8. Do not request a duplicate payment yet
A second payment may arrive while the first is still moving. You then have two transfers to reconcile, a client who may need a refund, possible additional bank fees, and another compliance question about why the same invoice was paid twice. Wait until the original payment is:
Formally rejected
Returned to the sender
Cancelled before release
Confirmed by the sending institution as failed
If the payment is urgent, the client can ask their bank whether the original transfer can be recalled. A recall is a request, not a guaranteed reversal.
Message to send to the receiving institution
Subject: Incoming international payment not credited — trace requested
I am expecting an international payment that has not been credited to my account. The sender’s institution has confirmed that the payment was released.
Amount: [Amount]
Currency: [Currency]
Transfer date: [Date]
Value date: [Date, if available]
Sender name: [Legal name]
Beneficiary name: [Exact name used]
Sender reference: [Reference]
UETR: [UETR]
Invoice reference: [Invoice number]I have attached the bank-issued payment confirmation and the available MT103, pacs.008, or equivalent transfer record. Please confirm:
Whether the payment appears in your incoming records
Whether it is pending, under review, rejected, returned, credited, or unmatched
Whether further evidence is required
Which institution currently owns the next action
The case reference and expected date of the next update
Do not put your complete account details or identity-document numbers in the email subject.
Why a wire may be delayed
A trace tells you what happened to one payment. It should not start with a guess. Possible causes include:
Incorrect beneficiary information
An unsupported currency or payment route
A sender-name mismatch
An account that does not accept third-party payments
Compliance or sanctions screening
Source-of-funds verification
Missing payment-purpose information
Processing after a bank cutoff
Weekends or banking holidays
Intermediary-bank processing
An account restriction
A payment the receiving institution cannot match
A rejection followed by a return
An internal reconciliation delay
A difference between the instructed and received amount
Do not tell the client that an intermediary bank “lost” the transfer without evidence. Do not assume that a compliance review means either party did something wrong. The trace exists to replace speculation with a payment state.
When an MT103 or UETR will not solve the problem
An MT103 or UETR is not the right tool in every case. It may not solve the issue when:
The client did not send a Swift payment
The transfer was created but never released
The payment went through ACH, SEPA, or another local rail
The beneficiary details were invalid
The account could not receive the selected currency
The payment was already returned
The receiving service credited the payment but restricted account access
The document belongs to a different transfer
The sender’s platform uses its own banking partner and investigation process
The payment was made in USDT or USDC
A stablecoin transfer has a different form of trace evidence. You need the transaction hash, blockchain network, token contract, sender address, recipient address, and on-chain status.
Before accepting one, use the stablecoin payment checklist for freelancers. For the wider payment and wallet workflow, see how Nigerian freelancers can get paid in USDT or USDC safely.
Do not ask a stablecoin sender for an MT103. Do not ask a wire sender for a blockchain transaction hash. First identify the rail.
Mistakes that make a missing payment harder to resolve
Treating the screenshot as final proof
It may only show that the client submitted the transfer.
Opening several support cases
Multiple tickets can split the evidence across different agents and create conflicting answers.
Giving each institution different information
Use the same amount, currency, sender name, beneficiary name, dates, and references in every case.
Searching only by invoice number
The bank may never have received your invoice reference or may store it differently. Include the UETR and bank reference.
Assuming the recipient must solve everything
The recipient cannot always start an investigation into an outgoing transfer initiated by someone else.
Asking the client to resend immediately
This can create a duplicate payment.
Sharing the full payment document publicly
An MT103 or related record may contain names, account details, bank identifiers, addresses, references, and other sensitive information. Redact it before sharing outside the official investigation.
Accepting an update without a deadline
Ask when the institution will update the case again. “We are investigating” needs a case number and a follow-up date.
Keep a payment-trace record
Use this table for every delayed international payment.
Field | Your record |
Client | |
Invoice number | |
Invoiced amount | |
Payment currency | |
Expected payment date | |
Actual transfer date | |
Value date | |
Sender’s legal name | |
Sending institution | |
Receiving route | |
Sender reference | |
UETR | |
MT103, pacs.008, or equivalent received | Yes / No |
Current payment state | |
Current case owner | |
Sending-bank case number | |
Receiving-institution case number | |
Evidence requested | |
Last update | |
Next update date | |
Final outcome |
Keep the invoice, contract or scope of work, payment instructions, client confirmation, bank document, account statement, and support correspondence together. If the payment later becomes part of a tax, compliance, accounting, or client dispute, you will need a record showing more than “the client said they paid.”
Official sources
Getting paid is only the first part of managing international income. walllet.com brings supported receiving routes, digital-dollar management, online spending, conversion, and local access into one workflow for eligible users. Product availability, currencies, payment rails, fees, limits, and review conditions depend on current account and partner coverage.
