How to invoice a client in crypto.

An invoice paid in crypto is an ordinary invoice with four extra lines and one risk that ordinary invoices do not have. Get the four lines right and the risk mostly goes away. Get them wrong and the usual outcomes are an awkward conversation about who eats a shortfall, or money that is simply gone.

The four lines

Every crypto invoice needs these, stated without ambiguity.

The asset. Not "crypto". Not "USDT or equivalent". The exact token, by name and symbol.

The network. This is the line people leave off, and it is the one that loses money. USDT on Ethereum and USDT on Tron are different tokens that share a name. Sending one to an address for the other is how funds disappear.

The amount, and how long it holds. Either a fixed token amount, or a fiat amount converted at a stated rate with a stated expiry.

The address, and how it will be confirmed. The address itself, plus the sentence that stops it being swapped in transit. More on that below.

Everything else on the invoice stays exactly as it was: your details, the client's, the work, the dates, the terms.

Quote in your currency, settle in a stablecoin

Your costs are in your local currency. Your rent is in your local currency. So the price of the work should be too, and the crypto is a payment rail rather than a unit of account.

In practice that means one of two formats.

Fixed token amount. "2,000 USDT (TRC-20)". Simplest to pay, simplest to reconcile, and with a stablecoin the exchange risk over a few days is small. This is the right default.

Fiat amount with a conversion window. "1,850 EUR, payable in USDT at the rate on the date of payment. Rate quoted 30 July 2026: 2,010 USDT. This amount is valid for 5 business days." Use this only if the client insists on the fiat figure being the contractual one.

If a client wants to pay in something volatile, that is their prerogative and your risk. A 2,000 invoice settled in a coin that moves 8 percent while it confirms is a 1,840 invoice, and there is no version of that conversation you win afterwards. Either quote a token amount with a short expiry and hold them to it, or say no.

Picking the network

Two things decide it: where the client's money already is, and what the transfer costs.

• Tron (TRC-20) is where most business stablecoin flow sits. Fees are small and predictable.
• Solana and the cheaper Ethereum layer twos are inexpensive and fast, and increasingly normal for business payments.
• Ethereum mainnet (ERC-20) works everywhere and costs the most. Fine for a 20,000 invoice, absurd for a 400 one.

Offer one network and a fallback, not a menu. Every extra option is another chance for the wrong one to be used. And check before you offer: your own wallet or exchange must actually support receiving that token on that network. An exchange deposit address for USDT on one chain will not save a deposit that arrives on another, and support recovery, if it exists at all, is slow and sometimes paid.

State it on the invoice the way it will be typed: USDT, Tron network (TRC-20). Not "USDT (Tron/ETH)".

The risk that is not on any other invoice

A bank transfer to the wrong account can often be recalled. A crypto transfer cannot. There is no reversal, no chargeback, and nobody to write to.

The attack that exploits this is old and still works. Someone with access to an email thread, yours or the client's, sends a polite follow up with an updated address. It looks like your invoice, it uses your wording, and the money leaves for good. Nothing about the blockchain is broken in this scenario. The email was.

Three habits, none of which are difficult.

Confirm the address on a second channel. Send the invoice by email and the address by a different route, a call or a chat the two of you already use. One sentence: "the address ends in 9fK2, confirm it matches". A recipient who knows to check the last four characters is a recipient who cannot be redirected quietly.

Say on the invoice that the address never changes by email. Write it in plain words: "our payment address is never changed by email. If you receive an updated address, phone us before sending anything." That single line has saved more money than any technical control.

Ask for a small first transfer with a new client. 10 or 20, confirmed as arrived, then the rest. It costs a few cents and takes ten minutes, and it catches a wrong network, a wrong address and a client whose wallet does not do what they thought.

Who pays the network fee

State it, or you will absorb it. One line: "network fees are payable by the sender. The invoice amount must arrive in full."

Without that line, some clients will send 2,000 minus the fee and consider it settled. With a cheap network the difference is trivial and not worth an email. On an expensive one it is not trivial, and a client who is sending from an exchange may also be charged a withdrawal fee that has nothing to do with the chain. That is theirs, not yours, and the invoice should say so.

What to keep for your accounts

Whatever your local rules, the same three facts do the work.

• The transaction hash. It is the receipt. It proves an amount arrived at an address at a time, and it is the only piece of evidence that cannot be edited.
• The value in your local currency on the day it arrived. Almost everywhere, income is recognised at the value on the date of receipt. Record the rate you used and where it came from, and use the same source every time.
• What it cost you to receive. Withdrawal fees, conversion spread, the transfer out. Often deductible, and always relevant to what the job actually paid. Those costs are itemised here.

Also worth noting the day the reserve for tax moved, if you set one aside, which you should.

A short template

Payable in USDT on the Tron network (TRC-20). Amount: 2,000 USDT. Valid until 6 August 2026. Address: TXy...9fK2 Network fees are payable by the sender. The full amount must arrive. This address is never changed by email. If you receive a message updating it, call us on the number above before sending anything.

Five lines. Copy them onto every invoice.

Keeping track once they start arriving

One invoice is easy. Nine, across two chains, two clients paying late and one paying in two parts, is where it stops being easy, because the payment arrives as a line on a chain with no invoice number attached to it.

That matching problem is what money in exists for: invoices you send, what has been paid, what is late, and an arriving payment recorded against the invoice it settles rather than as an anonymous credit that you identify by size in three months. The wider picture, where crypto arriving is just income and shows up next to everything else, is on the freelance page.