Why You Received Less Than Your Invoice: SWIFT, Intermediary And Lifting Fees
Quick answer
You got less because a SWIFT wire isn’t direct. It passes through intermediary banks that each take a cut from the money in transit, and your Indian bank can add a receiving fee on top. All of this is separate from the exchange-rate loss.
Take your last foreign invoice and do the arithmetic nobody asks you to do. Multiply the dollars by the exchange rate you saw on Google the day the money landed, then compare that to what actually hit your account. The second number is always smaller, usually by more than you’d guess.
Part of that gap is the exchange rate, which is its own story. The rest is a set of fees taken out of the money while it was still moving, charged by banks you never chose and can’t see on your statement. Those are the ones worth understanding, because unlike the rate, you can actually do something about them.
Key Takeaways
- A SWIFT wire is relayed from bank to bank, and each bank in the chain can take a fee from the money in transit. That is why the credit is smaller than the invoice.
- The single biggest lever is the charge code. SHA, the default, makes you absorb the intermediary fees; OUR puts them on your client instead.
- Your Indian bank may add a small inward fee plus 18% GST, but many private banks charge nothing to credit the payment, and none of this is the exchange-rate markup.
- The one move that ends the problem: get your client to pay on OUR with a written instruction, or skip SWIFT entirely with a local-rail account.
Where did the missing money actually go?
A SWIFT wire feels like it should go straight from your client’s account to yours. It doesn’t. SWIFT is a messaging system, not a pipe for money. It carries the payment instruction; the actual cash is passed along a chain of banks that hold accounts with each other, and the money only reaches you at the end of that chain. Three separate charges get taken along the way, and they are worth keeping straight because you have different amounts of control over each.
The send fee is the one you’d expect. Your client’s bank charges them to initiate an international wire, usually a flat amount, commonly somewhere around $20 to $50 depending on the bank and country. Under the normal setup it comes out of your client’s pocket, not yours. Your credit isn’t touched by it. It still matters, though, because it’s often why a client picks the cheapest routing rather than the one that leaves you whole.
The intermediary cut is the one you can’t see. If your client’s bank has no direct relationship with your Indian bank, and most don’t, the payment gets relayed through one or more correspondent banks. Each of them can deduct a fee straight from the principal as it passes through, typically somewhere in the $10 to $30 range per bank, across one to three banks depending on the route. The exact figure isn’t published anywhere, and you can’t know it before the money moves. Nobody tells you it’s happening. The money simply arrives lighter.
The receiving fee lands last. Your Indian bank may charge an inward remittance or handling fee to credit a foreign payment, with GST of 18% on top of any such fee. This one varies: several private banks, HDFC among them, credit inward remittances with no explicit fee and make their margin on the exchange rate instead. So the receiving-bank fee is often small or zero, and the rate is where the bigger receiving-side cost hides.
Say a US client pays a $2,000 invoice by SWIFT wire under the default code. Their bank takes a send fee to initiate it, out of their pocket, not yours. On the way, a correspondent bank lifts something in the $10 to $30 range from the principal. If your bank charges an inward fee, add that plus 18% GST; if it’s one of the banks that doesn’t, add nothing here. Either way, before the exchange rate has done a thing, the wire itself has already skimmed a slice off a payment you sent out whole. And the rate is usually the largest leak of the lot, a separate deduction with a separate fix.
What is a lifting fee, and who took it?
Here’s where the jargon trips people up. “Lifting fee” gets used loosely for two different charges. Some people mean the cut a correspondent bank takes from the payment mid-route. Others, including a lot of Indian banks, use it for the fee your own bank charges to lift the foreign currency out of the wire and credit it to you. Same words, two different banks, two different points in the journey.
What both have in common is how they’re taken. The fee comes straight out of the money in transit, not billed to you afterwards. You never agreed to it in advance. And you often can’t predict it, because at the moment the wire is sent, nobody knows how many correspondent banks it will cross or what each one charges. A payment that goes through two hops loses more than one that goes through none, and you find out which happened only after the rupees land.
This is why two freelancers can send an identical $1,000 invoice to the same country and receive different amounts. Different banks, different correspondent relationships, different number of hands the money passed through. The fee isn’t a percentage of your invoice, it’s a flat charge per bank, which means it bites hardest on smaller payments. A $20-odd deduction on a $300 invoice is brutal. On a $10,000 invoice it’s background noise.
What do OUR, SHA and BEN actually mean for you?
Every SWIFT wire carries a three-letter code that decides who pays the fees in the chain. Your client sets it when they initiate the transfer, and most of them have never thought about it. This is the most useful thing on the whole page, because it’s the one part of the process you can change with a single sentence to your client.
| Charge code | Who pays the intermediary fees | What you receive | Best when |
|---|---|---|---|
| OUR | The sender covers all charges in the chain | The full invoice amount | You need the exact amount to land |
| SHA | Shared: sender pays their bank, you absorb intermediary and receiving fees | Less than invoiced | Routine, low-stakes payments |
| BEN | The beneficiary pays everything, including the sender’s own fee | The least of the three | Almost never, for a freelancer |
SHA is the default on most wires, which is exactly why the shortfall feels like a default fact of life. It isn’t. Ask a client to switch to OUR and the fees move off your side of the ledger and onto theirs.
One honest caveat: OUR isn’t bulletproof. If an intermediary bank’s charge wasn’t pre-covered when the wire went out, it can still get shaved off in transit. OUR gets you the full amount far more reliably than SHA, but “guaranteed to the rupee” is a promise no charge code can actually make.
How do you find out exactly where the money was cut?
When a payment lands short, you don’t have to guess. Most people, myself included, assume the exchange rate ate the difference, and often that’s only part of it. The SWIFT system generates a record called an MT103 for every wire, and it shows you the route the money took and where the fees came off. Here’s how to use it.
- Ask for the MT103. Request it from your own bank, or have your client ask theirs, using the payment date and amount. If your client has the UETR, the unique tracking number for the wire, that makes it faster to pull.
- Check Field 71A. This shows the charge code that was used: OUR, SHA or BEN. If it says SHA, you’ve found why the intermediary fees came out of your side.
- Check Field 56A. This names the intermediary or correspondent institution the payment was routed through, the likely point a fee came off in transit. Field 57A names the account-with institution, usually the bank that credited you.
- Compare Field 32A to your credit. Field 32A is the amount and currency that were actually sent. The gap between that and what your bank credited, once you strip out the currency conversion, is the chain’s cut.
There’s a limit to what this document settles, and it’s worth being straight about. The MT103 tells you where the money went. It won’t tell you how these charges net against your tax, or whether any of it is recoverable in your books. That’s a question for your CA, not for a SWIFT field.
How do you stop receiving less than you invoiced?
Once you can see where the leak is, the fixes are specific. Receiving foreign money cleanly is most of what a working payment setup is for, so it’s worth getting these right rather than absorbing the loss every month.
Fix the rate as a separate job. The exchange-rate markup is usually the bigger number and it has nothing to do with the wire chain, so treat it as its own line to attack.
Put the charge code in writing. Ask the client to pay on OUR, and add a line to the invoice: sender covers all bank, correspondent and lifting charges, full amount to credit. A code they have to actively choose is a code they forget, so make it a written instruction, not a hope.
Skip SWIFT where you can. A local-rail account that receives via ACH, SEPA or FPS through a virtual USD, EUR or GBP account bypasses the correspondent chain entirely, so there are no intermediary hops to take a cut. Which of those routes is cheapest for your client mix is a question worth working through properly.
Batch your payments. Because the fees are flat and per-transfer, fewer and larger payments spread the fixed cost thinner. One $6,000 transfer beats six $1,000 ones on fee load.
Frequently Asked Questions
Does the OUR charge code guarantee I receive the full invoice amount?
Mostly, but not with total certainty. OUR means the sender covers all charges in the chain, so it’s the most reliable way to receive the full amount. If an intermediary fee wasn’t pre-covered when the wire was sent, a small deduction can still happen in transit.
What is the difference between an intermediary bank and a correspondent bank?
In practice, not much for your purposes. Both terms describe a bank sitting between the sender’s bank and yours that relays the payment because the two ends have no direct relationship. Each one in the chain can deduct a fee from the money as it passes through.
Can I get the intermediary bank fees refunded?
Generally no. These fees are deducted in transit by banks you have no account or relationship with, so there’s no one to claim a refund from. The practical fix is preventing them with the OUR code or a local-rail account, not recovering them afterwards.
How do I get an MT103 for my payment?
Ask your own bank, or have your client ask theirs, for the SWIFT copy or MT103 of the transfer. Give them the payment date, amount and reference, or the UETR tracking number if the client has it. Banks can usually retrieve it even weeks after the payment.
Do this today: Pull the MT103 for your last foreign payment and look at the intermediary bank fields. If you can see a correspondent bank took a cut, you know SHA was used and the fix is telling your next client to pay on OUR in writing. Sort that one instruction before your next invoice goes out, while it still costs you nothing to change.
Reviewed and updated: [July 2026]
Sources and official verification
- HDFC Bank. “Remittance: Fees and Charges.”
https://www.hdfc.bank.in/remittance/fees-and-charges - Central Board of Indirect Taxes and Customs. “GST Goods and Services Rates.”
https://cbic-gst.gov.in/gst-goods-services-rates.html - Swift. “Swift GPI.”
https://www.swift.com/products/swift-gpi
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