OUR, SHA, and BEN: Why SWIFT Payments Arrive Short

A $50,000 invoice settled via SWIFT wire. The recipient’s bank credits $49,712. No error alert. No failed-payment notification. Just a gap your accounts receivable team must investigate manually — and a call from the counterparty asking whether you intentionally short-paid them.

This is not a bank error. It is SWIFT’s charge instruction system — specifically, the SHA (shared) default — operating exactly as designed.

Understanding OUR, SHA, and BEN, when each applies, and how to specify the correct instruction requires one additional field on a wire transfer form. It needs no new infrastructure and costs nothing to implement. It eliminates an entire category of AR reconciliation exception.

The Three Charge Options

Every SWIFT MT103 wire transfer carries field 71A — “Details of Charges” — which instructs the correspondent banking chain who bears the fees at each hop.

Instruction	MT103 (Field 71A)	ISO 20022 (pacs.008 ChrgBr)	Originating bank fee	Correspondent fees
OUR	OUR	DEBT	Paid by sender	Paid by sender (collected by originating bank)
SHA	SHA	SHAR	Paid by sender	Paid by recipient (deducted from principal in transit)
BEN	BEN	CRED	Paid by recipient (deducted from principal)	Paid by recipient (deducted from principal)

OUR instructs the originating bank to collect all charges — from every correspondent in the chain — from the sender. The recipient receives the full transfer amount, subject only to any incoming wire fee the receiving bank charges on its own (which OUR does not cover — it controls charges within the SWIFT correspondent chain, not the receiving bank’s internal credit fee).

SHA is the market default. The sender pays the originating bank’s fee directly. Each correspondent bank in the chain deducts its own fee from the principal as the payment passes through. The recipient receives whatever remains after all in-transit deductions — an amount the sender cannot predict in advance.

BEN means the beneficiary absorbs everything, including the originating bank’s fee, which is deducted from the principal before the payment enters the correspondent chain. BEN is almost never used in B2B contexts.

How Each Option Affects the Recipient

Consider a USD wire from a US company to a European supplier, routing through two correspondent banks.

Under OUR: The sender pays the full invoice amount plus the originating wire fee plus the bank’s OUR surcharge (a flat fee the originating bank charges to cover collecting correspondent fees on the sender’s behalf). Each correspondent processes the payment without deducting from the principal. The recipient’s bank credits the full invoiced amount — minus any incoming wire fee the receiving bank charges independently.

Under SHA: The sender pays the invoiced amount plus the originating wire fee. Correspondent bank 1 deducts its processing fee from the principal before forwarding. Correspondent bank 2 deducts its own fee from the reduced amount. The recipient may also face an incoming wire fee from its own bank. The recipient receives the invoiced amount minus all intermediate deductions.

Correspondent fees are not standardised. Each bank sets its own schedule, which varies by institution, currency, corridor, and volume relationship. The sender cannot predict in advance what each correspondent will deduct. The recipient receives no automatic notification explaining the gap.

Under BEN: The originating bank’s fee is deducted from the principal before forwarding. Correspondents deduct further. The recipient receives the least predictable amount across all three options.

For the $50,000 invoice: OUR delivers the closest approximation to a guaranteed full-amount credit. SHA delivers a partial credit of an unknown amount until the recipient checks their bank account. BEN delivers the lowest predictability for both parties.

Why SHA Is the Default

SHA’s dominance as the interbank default is an operational convenience for originating banks.

Under OUR, the originating bank must collect correspondent fees from the sender — which requires tracking what every correspondent in the chain actually deducted, then billing the sender for the total. For dynamic multi-hop corridors, this requires post-settlement reconciliation and retrospective billing across institutions that do not coordinate fee schedules in advance.

Under SHA, each bank deducts its fee at the moment of processing and forwards the remainder. No inter-institutional coordination, no retroactive billing, no cross-bank charge reconciliation. SHA is the path of least operational friction for the banking system.

The consequence for operators: unless you specify otherwise, your SWIFT wire goes SHA, your counterparty receives less than invoiced, and neither party receives an automatic explanation.

When to Use OUR

OUR is the correct default instruction for B2B invoice settlement in most cases. The conditions that justify the additional sender cost:

Reconciliation is automated. If your counterparty’s AR system matches payments by amount and invoice reference, SHA creates an amount mismatch that blocks auto-matching even when the invoice reference survives the correspondent chain intact. OUR eliminates the amount discrepancy. At $2–3 per manual reconciliation intervention and a 10–15% manual-intervention rate on cross-border wires, the AR labor saving frequently exceeds the OUR surcharge at moderate invoice volumes.

Expected correspondent deductions exceed the OUR surcharge. Confirm your originating bank’s OUR flat fee. If that fee is lower than the corridor’s expected correspondent deductions under SHA, OUR reduces total payment cost for the full chain — the sender pays a smaller known cost instead of passing larger unknown fees to the recipient.

Contractual payment terms require full invoice settlement. Some supplier agreements specify that the invoiced amount must be credited in full. SHA is not contractually compliant with this requirement. OUR is.

The corridor has a long correspondent chain. US-to-frontier-market corridors may route through two or three intermediaries. Each hop under SHA adds a deduction. OUR caps the sender’s cost at the originating bank’s surcharge regardless of chain length.

Why BEN Is Rarely Suitable for B2B

BEN appears appealing to senders — you pay only your bank’s wire fee — but creates problems that make it unsuitable for B2B invoice settlement:

• The sender cannot predict what the recipient will receive, making it impossible to confirm full settlement before the wire clears
• Originating bank fees under BEN are deducted from principal before forwarding, visible to neither party until after the fact
• Correspondent deductions compound on an already-reduced principal
• Recipients receiving BEN wires cannot reconcile the credited amount against an invoice without manual investigation

BEN is used in consumer remittance contexts where the recipient wants to receive any amount and fees are secondary, or in specific institutional arrangements with pre-agreed fee structures. For standard B2B invoice settlement, BEN is the wrong instruction.

How to Instruct Your Bank

In MT103 terms, field 71A accepts a single instruction: OUR, SHA, or BEN. In ISO 20022 pacs.008, the equivalent is the ChrgBr element: DEBT (OUR), SHAR (SHA), CRED (BEN). SWIFT gpi does not change the charge mechanics — it adds tracking visibility via the UETR reference, making it possible to see deductions at each hop retrospectively, not prevent them under SHA.

In practice, most treasury teams interact with charge instructions through a bank’s wire transfer form or treasury management system. Common friction points:

The field is not exposed. Some banking platforms — particularly retail and SMB-tier interfaces — do not surface a charge instruction field at all. They default to SHA silently. If your wire form has no “Details of Charges,” “Fees Paid By,” or similar field, your payment goes SHA. Contact your relationship manager.

OUR requires a separate process. Some banks only accept OUR instructions via phone, secure message, or a separate form — not through the standard online wire interface. Know your bank’s process before a time-sensitive settlement requires it.

Not all banks support OUR for all corridors. Certain destination markets have regulatory or correspondent-relationship constraints that make OUR difficult to execute reliably. Verify OUR availability for each active currency and destination before setting it as a default.

OUR does not cover the receiving bank’s incoming wire fee. Even under OUR, the recipient’s bank may deduct an incoming international wire processing fee from the credited amount. This is the receiving bank’s own fee schedule — outside the SWIFT correspondent chain that OUR covers.

AR Reconciliation Implications

The operational effect of SHA on cross-border B2B AR automation is systematic. When a payment matches on invoice reference but not on amount — the reference survived the correspondent chain, but the amount was reduced — automated AR matching fails. The system sees a $49,712 payment against a $50,000 invoice and cannot auto-close the item. Manual reconciliation is required to confirm the $288 discrepancy is correspondent fees, not a short payment or dispute.

The ISO 20022 migration (mandatory cutover for cross-border SWIFT traffic in November 2025) improves remittance data structuring — more structured invoice references, better payment detail carriage. It does not change how charge options work. A pacs.008 message with ChrgBr: SHAR still routes SHA; structured remittance data does not prevent the amount mismatch.

Virtual IBAN collection eliminates SHA-related reconciliation failures for EUR, GBP, and USD payers by routing through domestic payment rails that carry no correspondent chains. Where SWIFT wire is unavoidable, OUR is the clean path.

Operator Checklist

1. Identify your bank’s default charge instruction — confirm your online wire platform exposes the field and what it defaults to.
2. Confirm OUR availability for active corridors — not universally supported; verify per currency and destination market.
3. Obtain your bank’s OUR surcharge in writing — know the flat fee before building it into payment policy.
4. Set OUR as your default for B2B invoice payments — a practical scope: any invoice where the recipient must reconcile the exact credited amount, or any payment where amount mismatch triggers AR exceptions.
5. Update TMS/ERP payment templates — if your treasury system generates SWIFT instructions, confirm ChrgBr: DEBT (OUR) is set rather than defaulting to SHAR.
6. Advise key counterparties who pay you — if you receive SHA wires short of invoiced amounts, include an explicit OUR request in your remittance instructions; most counterparties will comply once the reconciliation reason is explained.
7. Account for residual receiving-bank fees under OUR — some receiving banks charge an incoming wire fee not covered by OUR; know whether your key receiving banks do this.

For the full mechanics of the SWIFT correspondent chain — MT103 structure, ISO 20022 migration, gpi tracking, and when to use alternatives — see SWIFT Payment Processing: MT103, ISO 20022, and gpi Explained. For a comparison of SWIFT against local rail alternatives for specific corridors, see SWIFT gpi vs Local Payment Rails. For the AR infrastructure that eliminates SWIFT-related reconciliation failures at scale, see Cross-Border B2B Accounts Receivable.