SHA vs OUR vs BEN: Who Actually Pays The Wire Charges When A Client Pays You?
Quick answer
OUR, SHA, and BEN decide who pays the correspondent bank fees on a SWIFT wire. OUR means the client covers them and you receive the full invoice. SHA and BEN both take the fees out of your money, so you get less than you billed.
You invoice a foreign client $2,000, and something less than that lands in your account. Most people blame the exchange rate. Sometimes it is the rate, but a lot of the time the real culprit is three letters your client picked on the wire form and never mentioned: OUR, SHA, or BEN. That code quietly decides who pays the banks sitting between you and your client. And by default, that’s usually you.
The catch for freelancers in India is that you’re on the receiving end. You don’t fill in the wire form, your client does. So the one setting that most affects what lands in your account is a setting you don’t control. This is about understanding it well enough to ask for the right one.
Key Takeaways
- OUR is the only code that gets you the full invoice, because the client agrees to pay every bank in the chain.
- SHA and BEN both pull the fees out of the transfer before it reaches you, and SHA is the silent default on most wires.
- You don’t choose the code, your client does, so your real move is to ask them to send OUR or to skip the SWIFT chain altogether.
- One question settles it: did the money travel through SWIFT correspondent banks, or through a local account that never touches them.
What do OUR, SHA, and BEN actually mean?
They’re instructions on a SWIFT payment that tell the banks who pays the transfer fees. On the old MT103 message they sat in a box called field 71A, “details of charges.” Since November 2025, cross-border SWIFT payments moved to a newer format called ISO 20022, where the same instruction is called the charge bearer and uses different words: DEBT, SHAR, and CRED. Same three choices, new labels. Your bank may still show you the old OUR/SHA/BEN on a confirmation, so both are worth knowing.
Here’s what each one does:
OUR (DEBT): your client pays everything. Their bank collects the fees for the whole chain up front, and the payment travels without anyone skimming it. You get the full invoice amount.
SHA (SHAR): the fees are split. Your client pays their own bank’s sending fee, and every correspondent bank along the way takes its own cut out of the money in transit. Whatever’s left is what you receive. This is the default on most wires.
BEN (CRED): you pay for all of it. Even the client’s own sending fee comes out of the transfer before it leaves. You receive the least of the three.
Notice the pattern. Only one of these three leaves your money untouched.
Who pays what under each code?
| Charge code | Client’s sending fee | Correspondent bank fees | What you receive |
|---|---|---|---|
| OUR (DEBT) | Client pays | Client pays | Full invoice amount* |
| SHA (SHAR) | Client pays | Taken from the transfer | Invoice minus correspondent fees |
| BEN (CRED) | Taken from the transfer | Taken from the transfer | Invoice minus every fee |
*OUR covers the banks in the middle. It does not cover your own bank’s fee for crediting foreign money to your account, which is a separate charge in India. More on that below.
The column that matters to you is the last one. Under OUR, the number you invoiced is the number that arrives, before your own bank’s inward charge. Under SHA and BEN, the arriving number is a surprise, because nobody can tell you in advance how many banks will touch the payment or what each will take.
Why does the money arrive short when nobody chose BEN?
Because SHA is what happens when no one makes a decision. A lot of banking apps, especially the retail and small-business ones your client might use, don’t even show a “who pays the fees” option. The wire just goes out as SHA. Your client thinks they sent the full $2,000, and they did. What they didn’t pay for was the road it travelled on to reach you.
And that road is rarely direct. A SWIFT payment from, say, a US client to your Indian bank usually hops through one to three correspondent banks that hold accounts on both ends. Each one deducts a fee from the principal as it passes through. Those fees follow each correspondent’s own tariff and aren’t published anywhere central, which is exactly why the shortfall is unpredictable. HDFC’s own remittance page says as much: the charges it lists are its own and don’t include what originating or correspondent banks levy, over which it has no control. In practice the deductions are commonly reported in the region of $10 to $30 per intermediary bank, but that’s a ballpark, not a rate card.
Here’s the mechanism with round numbers. Your client sends $2,000 SHA. Say it passes through two correspondents and each takes a cut. By the time it reaches your bank, the wire is worth less than $2,000, and your bank converts whatever arrived into rupees. You never see the deductions itemised. I’ve watched this happen and gone hunting through the statement for an itemised fee that simply isn’t there, because under SHA those cuts come off the wire mid-route, off the message your bank ever sees.
That’s the part that stings. The shortfall isn’t a fixed number you can plan around. It depends on the route, and the route changes.
You’re the receiver, not the sender. What can you actually do?
You can’t set the code yourself. But you’re not powerless either. Three real options, roughly in order of effort:
- Ask your client to send it OUR. This is the cleanest fix and it costs you nothing. Add one line to your invoice or payment instructions: “Please send by wire with charges marked OUR, so the full amount arrives.” Most business clients will do it without blinking, since the extra fee on their end is usually small. The friction is just that they’ve never been asked.
- Build the fee into your price. If a client refuses OUR, or keeps forgetting, pad the invoice enough to absorb a typical shortfall. It’s clumsy, but if you know roughly what SWIFT costs you on this corridor, quoting a little higher means the amount you actually need still lands.
- Get off SWIFT entirely. The charge-code problem only exists because the money is crawling through the correspondent chain. Platforms that give you a local US, UK, or EU account number let your client pay you as a domestic transfer on their side, which means no correspondent banks and no OUR-versus-SHA question at all. For most freelancers taking regular foreign payments this is the real answer, one piece of the bigger question of how to get paid from abroad without losing money to the banks, and it’s worth checking what the cheapest way to receive USD actually costs against a bank wire.
Does OUR really get you the full amount?
Mostly, with two honest caveats.
First, OUR controls the fees inside the SWIFT chain. It does not cover your own bank’s charge for receiving foreign money. In India this is often called an inward remittance or “lifting” fee, and it varies by bank: some charge nothing to credit the money, others take a few hundred rupees. On top of whatever the fee is, the bank adds GST at 18% on its own commission and charges, which HDFC’s published tariff states plainly. So even a clean OUR payment can land a little short of the invoice because of a domestic charge at your end.
Second, the instruction isn’t ironclad. Some intermediary banks have their own policies and will deduct anyway, then in theory reimburse it later. In practice, “in theory” is doing a lot of work in that sentence.
None of this touches the other big deduction: the exchange rate your bank uses to turn the wire into rupees. That markup is a separate leak from the wire charges, and often a bigger one. The charge code decides who pays the banks in the middle; the forex markup buried in your conversion rate decides how much you lose turning dollars into rupees. Fixing one doesn’t fix the other, which is a large part of why the amount you receive rarely matches your invoice.
For the tax and compliance side, the charge code doesn’t change what you owe or what you file. That part is a question for your CA, not your bank’s wire form.
Frequently Asked Questions
Is SHA or OUR better when a client pays me from abroad?
OUR is better for you. It means your client pays the correspondent bank fees and you receive the full invoice amount. Under SHA, those fees come out of the transfer, so you receive less than you billed.
Can I change the charge code after my client has sent the payment?
No. The charge code is set when the wire is initiated and cannot be changed once the payment is on its way. If a payment arrived short because of SHA, the only fix is to ask your client to use OUR on the next one.
What are the ISO 20022 equivalents of OUR, SHA, and BEN?
DEBT means OUR, SHAR means SHA, and CRED means BEN. Cross-border SWIFT payments moved to the ISO 20022 format in November 2025, so newer systems use these labels, though many banks still show the old codes on customer confirmations.
Do payment platforms like Wise or Payoneer use these codes?
Usually not, because platforms such as Wise, Payoneer, and Skydo mostly avoid the SWIFT correspondent chain. When a client pays into a local account one of them provides, the money moves as a domestic transfer on their side, so the OUR, SHA, or BEN choice doesn’t apply the way it does with a traditional bank wire.
Do this today: Pull up your last SWIFT payment from a foreign client and put the invoice amount next to what actually hit your bank. If there’s a gap the exchange rate alone doesn’t explain, that’s the charge code eating into your money. Message that client before you send the next invoice and ask them to mark the wire OUR, or move them onto a local-currency account that skips the correspondent chain, so the next payment lands whole.
Reviewed and updated: [August 2026]
Sources and official verification
- SWIFT. “MT to ISO 20022 conversion.”
swift.com/standards/iso-20022/iso-20022-faqs/mt-iso-20022-conversion - HDFC Bank. “Fees & Charges for Fund Transfer to India.”
hdfc.bank.in - Reserve Bank of India. “Foreign Exchange Management Act (FEMA) / inward remittance.”
rbi.org.in
Ritesh Yengkhom
I'm Ritesh — I've freelanced for over five years, largely through Upwork, and I'm the writer behind WealthWali. I have a B.Com from Delhi University, but most of what's on this site came from somewhere else: chasing late invoices, guessing at tax, and learning the hard way what nobody tells you about freelancing in India. Everything here is what I've actually used, paid for, or gotten wrong myself. Where something needs a CA or a lawyer, I'll say so plainly instead of pretending I know more than I do.
View Author Profile