You invoiced a client 500 USDT. They say they sent 500. Your deposit history shows 499. Nobody is lying: the client typed 500 into their exchange’s withdrawal screen, the exchange took its withdrawal fee out of that 500, and the rest went on-chain to you. The missing dollar is the sender’s fee, paid out of your payment because nobody agreed who would cover it.
The sender’s side pays the fees for a crypto transfer, but if the sender withdraws from an exchange, that fee is usually taken from the amount they type unless they add it on top. So agree in writing that fees are paid by the sender and the full amount must arrive, and the payer enters the invoice amount plus the fee.
Why 499 arrived: the fees on the sender’s side
There are two different costs when someone sends you USDT from an exchange, and both sit with the sender. You, the receiver, don’t pay anything to receive an ordinary on-chain deposit. What you can lose is the part of your payment that was used to pay the sender’s costs.
The network fee. Every transfer on a blockchain costs something to process, and the account that sends the transaction pays it. On TRON, the network many people use for USDT, this works through resources. USDT on TRON is a smart-contract token, and the TRON developer docs explain that smart-contract calls consume energy on top of bandwidth. If the sender’s account has no staked energy or free quota to cover it, the network burns TRX, TRON’s own coin, from the sender’s balance. That is why someone sending USDT from their own wallet sometimes says “I need to buy some TRX first”: the USDT can’t move until the TRX or energy is there. The cost comes from the sender’s balance, not from the USDT you receive.
The exchange’s withdrawal fee. When the sender uses an exchange, they don’t handle energy or TRX themselves. The exchange sends the transaction and charges a withdrawal fee instead, shown on the withdrawal screen for each coin and network. This is the one that makes payments arrive short. On many platforms the sender types an amount, and the screen then shows the fee and a smaller “you will receive” or “receive amount” figure. If the sender doesn’t read that line, the receiver gets the smaller figure. Some platforms work the other way and add the fee on top, taking amount plus fee from the sender’s balance. The payer’s screen tells them which way their platform works, so ask them to look at the “receive amount” line before they confirm.
Fees differ between networks, between exchanges and over time, so don’t quote a fee to your payer from memory. Let them read the figure on their own withdrawal screen for the network you agreed.
What this means in practice:
- If the payer sends from their own wallet, the network fee comes out of their TRX or other coin, and the full USDT amount usually arrives.
- If the payer sends from an exchange, the withdrawal fee is usually taken from the amount they enter, and you get less unless they add the fee on top.
- Either way, the rule you want in your terms is about the result: the amount that arrives in your account.
How to word the fee terms
State the fee term as a result, not a process: say what amount must arrive, and who covers anything on top. Payers don’t all know how their platform takes fees, but everyone understands “the full amount must arrive”.
There are two honest versions, and both are fine as long as they are agreed before the payment:
| Term | What it means | When to use it |
|---|---|---|
| “Fees paid by the sender. The full 500 USDT must arrive.” | The payer covers any network or withdrawal fee, so they enter 500 plus the fee | Client work, sales, anything with an invoice |
| “Fees deducted from the payment.” | You accept whatever arrives after the sender’s fees | Small or informal payments, family, or when you have priced the fee in already |
For invoices, I’d use the first version every time. It puts the cost with the person who chooses the platform and the network, and it gives you something clear to point to if 499 arrives. For a relative sending money home, the second version is often kinder and simpler, as long as you both know the amount will be a little lower.
Put the line in two places: in your invoice, and in the message with your payment details. Something like this:
Fee line for your payment message
Please cover the network and withdrawal fees so that the full 500 USDT arrives in my account. On most exchange withdrawal screens this means entering 500 plus the fee shown, and checking that the "receive amount" line says 500 before you confirm.
The rest of the payment message, with the coin, network and address lines, is in what to send the person paying you. If you are writing a full invoice, the guide to invoicing a client in USDT shows where the fee clause sits alongside the due date and the rate clause, and the free invoice maker adds a fee line for you.
Worked example: asking for enough to cover the fee
When the fee comes out of the payment, the amount the payer enters has to be what you need plus the fee:
amount to enter = amount that must arrive + withdrawal fee
The numbers below are invented and round, to show the arithmetic. Your payer’s real fee is whatever their withdrawal screen shows for the network you agreed.
Example 1: the short payment. You need 500 USDT. The payer’s platform deducts a withdrawal fee of 1 USDT from the amount entered.
- Payer enters 500.
- Fee: 1.
- Arrives: 500 − 1 = 499. One short.
Example 2: the fixed version. Same fee, but the payer follows your fee term.
- Payer enters 500 + 1 = 501.
- Fee: 1.
- Arrives: 501 − 1 = 500. Correct.
- Total cost to the payer: 501.
Example 3: a platform that adds the fee on top. The payer enters 500 and the platform takes the fee separately.
- Payer enters 500.
- Taken from the payer’s balance: 500 + 1 = 501.
- Arrives: 500. Correct, and the payer paid the same 501 as in Example 2.
Example 4: with a first-time test payment. You ask for a 20 USDT test before the rest, fees paid by the sender, and the platform deducts its fee from each amount entered. Each transfer is charged separately, so the fee is paid twice.
- Test: payer enters 20 + 1 = 21, you receive 21 − 1 = 20.
- Main payment: 500 − 20 = 480 still due. Payer enters 480 + 1 = 481, you receive 481 − 1 = 480.
- You receive 20 + 480 = 500.
- Payer’s total cost: 21 + 481 = 502. The test cost them one extra fee of 1.
That extra fee is the price of the test, and in my view it is worth paying every time with a new payer, because a wrong address or network on the full amount costs far more. Agree up front who covers it. With a client, “fees paid by the sender” already covers it. With family, you might offer to cover it yourself, in which case they enter 20 and 481, and you receive 19 + 480 = 499.
If you accept “fees deducted” but still need 500. Then price the fee in yourself: invoice 501 with fees deducted, and 501 − 1 = 500 arrives. This only works if you know the fee in advance, which usually means asking the payer to read it from their screen before you set the price.
Transfers with no network fee, and the costs that come after
If you and the payer both have accounts on the same exchange, an internal transfer between users doesn’t go on-chain, so there is no blockchain network fee at all. The exchange just moves the balance from one account to the other in its own records. On Binance, for example, sending to another user by email, phone number or account ID through its Pay feature is credited straight away, and because nothing is broadcast to a blockchain, no network fee applies. The platform may still show its own fee or limits on the send screen, so the sender should read the confirmation screen before confirming, as with any payment. Internal transfers also can’t be recovered if the sender enters the wrong details, so the ID should be copied, not typed. Whether to give an account ID or a deposit address is covered in which to give: an account ID or a deposit address.
Where this comes from checked September 2026
The network-fee explanation follows the TRON developer docs on the resource model, which describe energy for smart-contract calls and TRX burned from the sender’s balance when resources run short. The point about internal transfers follows Binance’s help page on sending crypto to another user with Pay, which says these transfers are credited immediately and can’t be recovered if the details are wrong. That page doesn’t list fees, so we don’t state any. The fee examples are invented round numbers.
Once the USDT is in your account, the fee question moves to your side. Turning USDT into local money usually involves costs you pay yourself: the price a buyer offers per USDT, which can be a little above or below the plain dollar rate in your currency, any trading fee the platform charges, and whatever your bank or mobile-money provider charges to receive the local payment. None of that is the payer’s concern, and it shouldn’t be in their fee term, but it belongs in your own pricing. If you need a set amount of local money from a job, work backwards from what lands in your bank, not from the USDT that lands in your exchange account. The steps and where each cost shows up are in selling USDT on P2P for the first time.
So when you set your price, check two numbers: the fee the payer will see on their withdrawal screen, and the cost of your own conversion. The first one goes in your fee term. The second one goes in your rate.