ERC20 invoices: USDT on Ethereum, and when it is the right call

Treasuries that hold on Ethereum, funds and protocols with on-chain accounting, and anyone whose custody or multisig setup lives there. For those clients, moving funds to another chain to pay you means a bridge, an extra approval and a line in an audit trail they would rather not add.

There are also clients who simply cannot withdraw on TRON from their custodian. When the constraint is on their side and it is real, the cheaper network is not the better one — an invoice they cannot pay is worth nothing.

Ethereum fees are paid by the sender in ETH and vary with network conditions. That is the client's cost, not yours, but it becomes your problem if they try to net it out of the payment. The same single sentence applies: the amount received must equal the amount due.

Because gas can be meaningful on smaller amounts, ERC20 tends to suit larger invoices. For a 200 USDT invoice, asking a client to pay Ethereum gas is a favour you are extracting; for a 20,000 USDT invoice nobody notices.

Ethereum addresses start with 0x and are 42 characters. The problem is that BNB Smart Chain uses the identical format, so an address that is correct on one chain looks equally correct on the other — and a payment sent to the wrong one of the two lands somewhere you may not be able to reach.

This is precisely why the network must be written next to the address rather than assumed. 'USDT on Ethereum (ERC20)' and 'USDT on BNB Smart Chain (BEP20)' are visually distinguishable in a way that two 0x strings are not.

Verity Audit Labs bills a protocol client 24,000 USDT for a smart contract review. Tax invoice INV-2026-0092, issued 12 September, due 26 September. Two lines: 'Contract review, 4 modules — 1 × 20,000.00' and 'Remediation re-review — 1 × 4,000.00'.

The payment block reads 'USDT on Ethereum (ERC20)', the 0x address in full on its own line, and 'Amount received must equal 24,000.00 USDT — Ethereum gas is paid by the sender.' The client's treasury pays from a multisig on Ethereum, which is why ERC20 was requested in the first place. Verity checks the wallet, files the transaction hash, and marks the invoice paid.

Putting a 0x address on an invoice without naming the chain. ERC20 and BEP20 share the format, and the network is the only thing distinguishing them.

Using ERC20 for small invoices out of habit. Gas on a small amount is a real deterrent; ask whether the client actually needs Ethereum.

Letting the client deduct gas from the payment. State the required received amount.

Offering ERC20 when you cannot actually receive on Ethereum. Only save wallets you control on that chain.

Assuming a pending transaction is a paid invoice. Wait for it in your own wallet before you change the status.