USDT Invoice Template for Cross-Border Sellers

A USDT invoice template needs everything a standard commercial invoice has — buyer and seller details, line items, totals, trade fields — plus three things a bank-style template doesn't account for: a receiving wallet address, a clearly labeled network/token, and a field for the buyer to submit proof they paid. Miss any of those three and the invoice looks complete but leaves the actual payment step to a side conversation.

Here's what to include, section by section.

Core commercial invoice fields you still need

Getting paid in USDT doesn't remove any of the basics a cross-border buyer, their finance team, or a customs broker expects to see:

  • Seller and buyer name, address, and contact details
  • Invoice number and issue date
  • Line items: description, quantity, unit price, line total
  • Invoice total and currency (in this case, USDT)
  • Relevant international trade fields — country, shipping terms, or other details your buyer's side needs for their own records

None of that changes just because the payment rail is crypto instead of a bank wire. A USDT invoice is still a commercial invoice first.

The crypto-specific fields a template can't skip

Receiving wallet address

The wallet address needs to live on the invoice or payment page itself — not in a follow-up chat message. A buyer who has to go dig up the address separately is a buyer who might end up paying an old, mistyped, or wrong-network address instead.

Network and token, explicitly labeled

USDT exists on more than one blockchain, and a wallet address by itself doesn't tell a buyer which one to use. A template should state the required network in plain language — for example, "USDT on TRON (TRC20) only" — rather than assuming the buyer already knows. Sending USDT on the wrong network to a correctly-copied address is one of the most common and most unrecoverable mistakes in crypto payments.

A place to submit the transaction hash

Once the buyer pays, they need a defined next step: submitting the transaction hash (the unique ID their wallet or exchange shows after sending the payment) back to the seller. Without this, "proof of payment" defaults to a screenshot in a chat thread — which shows a transfer happened, but not that it was the right amount, to the right wallet, on the right invoice. See what actually counts as proof of payment in crypto trade for the full breakdown, and InvoCert vs. spreadsheets and wallet screenshots for why the manual version of this step tends to fall apart.

A QR code for mobile payment

Most buyers pay from a mobile wallet app. A QR code encoding the wallet address saves a manual copy-paste step and reduces the chance of a mistyped address.

Where static templates run out of road

A Word doc or a static PDF can hold all of the fields above. What it can't do is confirm, on its own, that a submitted transaction hash actually corresponds to a real payment for that invoice — the right token, the right wallet, the right amount, confirmed on-chain. That check has to happen somewhere, and with a static template it defaults to the seller manually looking up the transaction themselves, invoice by invoice.

NeedStatic PDF/Word templateInvoCert invoice
Line items, totals, trade fieldsYesYes
Wallet address and network labelManually typed in, every timeSet once per workspace, shown with a QR code
Buyer submits proof of paymentNo defined field — usually a chat screenshotTransaction hash field on the payment page
Confirms the payment actually matches the invoiceManual, by the sellerVerified automatically against on-chain data
Partial payment trackingManual notes or a spreadsheetRecorded on the same invoice

InvoCert's invoice builder covers the commercial invoice fields cross-border sellers need, attaches your wallet address and QR code automatically, and gives the buyer a payment page with a transaction hash field built in — so verifying the payment isn't a separate manual step after the invoice goes out. See the homepage for how the full workflow fits together, or the plan comparison for what's included at each tier.

FAQ

What information must a USDT invoice include?

The same core fields as any commercial invoice — seller and buyer details, invoice number and date, line items, currency, and total due — plus the crypto-specific fields a bank-style invoice skips: your receiving wallet address, the token and network (USDT on TRON/TRC20), and a way for the buyer to submit their transaction hash once they pay.

Should I put my wallet address directly on the invoice?

Yes — the wallet address belongs on the invoice or payment page itself, not in a separate chat message. Keeping it attached to the invoice record reduces the chance a buyer copies an old or wrong address, and it means the address is still there if the buyer needs to reference it later.

Can I use a Word or PDF template for USDT invoices?

You can, and it covers the basics: line items, totals, and a wallet address. What a static template can't do is give the buyer a place to submit a transaction hash or confirm on its own whether a payment actually matches the invoice — that part still has to happen somewhere else.

Does a USDT invoice need to mention which blockchain network to use?

Yes. USDT exists on multiple networks, and a wallet address alone doesn't indicate which one to use. InvoCert's MVP supports USDT on TRON (TRC20) only, so every invoice and payment page explicitly labels the required network to reduce the chance of a buyer sending funds on the wrong chain.

Can I track partial payments on a USDT invoice?

Yes. Partial payments and top-ups can be recorded against the same invoice, each with its own verified transaction hash, so the payment history stays attached to the invoice instead of split across separate notes or spreadsheet rows.


Start free with 5 invoices/month — no credit card, no buyer account required. Create your first invoice.

USDT Invoice Template for Cross-Border Sellers · InvoCert