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.
| Need | Static PDF/Word template | InvoCert invoice |
|---|---|---|
| Line items, totals, trade fields | Yes | Yes |
| Wallet address and network label | Manually typed in, every time | Set once per workspace, shown with a QR code |
| Buyer submits proof of payment | No defined field — usually a chat screenshot | Transaction hash field on the payment page |
| Confirms the payment actually matches the invoice | Manual, by the seller | Verified automatically against on-chain data |
| Partial payment tracking | Manual notes or a spreadsheet | Recorded 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.