OUR, SHA, and BEN: Who Bears Wire Charges and Why Credit Can Arrive Short
OUR, SHA and BEN allocate wire charges. None proves what the beneficiary received; use bank records and the payment reference to investigate short credit.
OUR, SHA and BEN allocate wire charges but do not prove the amount credited to the beneficiary. Compare the payment instruction, bank fees, FX terms and account credit before classifying a short payment.
OUR, SHA and BEN specify who is to bear wire-transfer charges, not what amount a beneficiary actually received. Under OUR, the sender is instructed to bear the charges; UOB expressly says correspondents or the beneficiary bank may still deduct fees or fail to pass on the full amount. Under SHA, the sender bears its bank's charges and the beneficiary bears other transaction charges. Under BEN, the beneficiary bears all transaction charges. When a credit is short, compare the ordered amount, charge instruction, bank messages, fee records, FX terms and beneficiary account credit before assigning a cause.
A supplier invoices $50,000 and later sees a smaller credit. The payment may have carried an OUR, SHA or BEN charge instruction, but that code alone cannot settle the investigation. It says who is supposed to bear charges. It does not report the money credited to the beneficiary account.
That distinction is easy to miss. UOB's telegraphic-transfer page says full payment can be effected by selecting OUR and, for USD, adding /FULLPAY/. The same page then says UOB is not liable if a correspondent or beneficiary bank disregards the instruction and deducts fees, or if the full payment fails to arrive for another reason. An invoice gap can also come from a different ordered amount, an FX conversion or a receiving-bank charge. The operator needs the bank records before labelling it a correspondent deduction.
What each charge instruction says
For a legacy MT103, field 71A is the charge-bearer instruction. ISO 20022 uses charge-bearer codes whose meaning is comparable, although the message and service context still matter. This table describes the intended allocation, not a guaranteed account credit.
| Instruction | MT103 field 71A | ISO charge code | Intended allocation | What it does not establish |
|---|---|---|---|---|
| OUR | OUR | DEBT | Sender/debtor bears transaction charges | That every bank complied or the full invoice amount reached the beneficiary |
| SHA | SHA | SHAR | Sender bears its side; beneficiary bears the other charges | That a fee was deducted on this particular payment |
| BEN | BEN | CRED | Beneficiary/creditor bears transaction charges | The exact net credit before bank and FX records are checked |
The Swift MT standards define the legacy codes. ISO 20022's charge-bearer definitions describe the debtor, creditor and shared forms. Neither definition turns an instruction into an end-to-end payment guarantee.
When a wire arrives short
Begin with the ordered amount, not the invoice amount. If the payer instructed less than the invoice, the difference is not explained by a charge option. Then compare the sending bank's instruction with the beneficiary's account credit in the same currency. If a currency conversion occurred, identify the conversion amount and rate before calling the remainder a fee.
| Record to request | Question it answers | What it cannot prove alone |
|---|---|---|
| Payer's bank debit and original instruction | What amount and currency did the payer order? Which charge code was selected? | What reached the beneficiary |
| Bank payment message and UETR | Which payment should the banks trace, and what charge details were carried? | That every deduction is visible to the payer or that the beneficiary was credited |
| Sending/intermediary bank fee records | Which banks reported charges, and where were they applied? | Whether an unreported beneficiary-bank charge also occurred |
| FX quote or conversion detail | Whether conversion changed the amount in the beneficiary's currency | That the remaining difference was a bank fee |
| Beneficiary account entry and bank advice | What was actually credited, in which currency and on what date? | Why the amount differed without the upstream records |
Swift gpi tracking can improve visibility into status and deductions, depending on what the participating banks expose. A UETR locates the payment; it is not a receipt for the invoiced amount. An intermediary update should also not be mistaken for the beneficiary account entry.
If the beneficiary received less than the original instruction, ask the sending bank to investigate with the UETR and the beneficiary's evidence. Ask whether its OUR product promises a full-value credit for this corridor, how exceptions are handled and whether an incoming charge at the beneficiary bank sits outside that promise. If the ordered amount was already lower, resolve the payer or invoice discrepancy separately.
Choosing a charge option for B2B payments
OUR is worth discussing when the contract or automated accounts receivable process depends on a particular credited amount. It gives the sender responsibility for transaction charges under the instruction. It does not remove the need to confirm actual receipt or the bank's service terms. UOB's public warning is one concrete counterexample to the idea that selecting OUR alone guarantees a full credit.
SHA can be acceptable where the parties have agreed how to handle beneficiary-side charges and the recipient can reconcile a smaller amount. BEN allocates transaction charges to the beneficiary and is a poor starting assumption when the recipient expects to close an exact-value invoice. Neither choice automatically establishes a breach of contract or a specific deduction on an individual payment; those conclusions need the actual terms and records.
Before setting a treasury policy, obtain from your bank:
- Its supported charge instructions for the currencies and destinations you use, and the default if the field is left blank.
- The quoted price or charging method for each option. Do not assume every OUR service uses one flat surcharge.
- Whether it offers a full-value commitment, what that commitment covers and how a short-credit claim is handled.
- Whether the beneficiary bank may charge separately and how those charges appear in advice or statements.
- The message, fee and tracking records your team can retrieve when a payment does not match an invoice.
Record the selected instruction in the payment template and reconcile against the actual credited amount. For field-level mapping, see the MT103 to pacs.008 reference. For a broader matching process, see the PSP reconciliation failure runbook.
Sources & methodology (4)
MT payment field 71A carries the BEN, OUR and SHA charge codes and states which customer bears transaction charges
Checked:
UOB says OUR can effect full payment (with /FULLPAY/ for USD), but also disclaims liability if correspondents or the beneficiary bank disregard the instruction or the full payment does not arrive
Checked:
DEBT, SHAR and CRED are ISO 20022 charge-bearer codes for debtor-borne, shared and creditor-borne charges
Checked:
Swift gpi provides payment and deduction visibility through tracking services, subject to the bank's access and implementation
Checked:
Source types explained in our Methodology.
By Shaun Toh · Director, Digital Payments · Razer