Crypto Invoice Template for USDT and USDC Payments

This crypto invoice template is for a real USDT or USDC payment, not a wallet address pasted below a total. It tells the customer what was sold, the fiat price, exact token and network, quote window, fee rule, completion evidence, and what happens after a short payment, late transfer, or refund. Official sources reviewed August 26, 2026.

A crypto invoice is still a commercial invoice. The token transfer is the settlement method, not the description of what you sold. Keep the service price in the agreed invoice currency, then add precise payment instructions for the asset and blockchain network.

This guide provides an operational payment template. It does not determine whether the document satisfies tax, VAT, accounting or electronic-invoicing rules in your jurisdiction. Add any legally required registration numbers, tax fields and retention details after checking local requirements.

Real Coinbase Help page captured on 2026-08-26. It shows the product workflow—choose a customer, add line items, amount, tax and due date, then review and send—not a real customer invoice or a promise that Coinbase Business is available in your country.

Use this guide for: writing the invoice and its payment rules. For sending, confirming and reconciling the actual transfer, use the accepting crypto payments from abroad.

In this guide

• Decide the commercial terms first
• Calculate the token amount without hiding the price
• Use this worked invoice example
• Copy this crypto invoice template
• Define exceptions before they happen
• Move the invoice through a controlled lifecycle
• The invoice is ready to send when
• Issue a paid receipt without rewriting the invoice

Decide the commercial terms first

Do not start with a wallet address. First agree in writing on the work, price, due date and payer. Then choose the settlement route using the choosing a USDT or USDC network.

Never paste an address from an old invoice without checking the current receiving screen. Some providers change deposit addresses, networks, minimums or memo requirements. Verify the full destination through a separate trusted channel if the invoice travels by email.

Calculate the token amount without hiding the price

Use a simple rule:

token amount = invoice amount ÷ agreed token-to-invoice-currency rate

Example: a website project is priced at USD 750. If both sides agree to settle in USDC and the recorded rate is 1.000 USDC per USD, the requested settlement amount is 750 USDC. If the executable rate is 0.998 or a provider adds a spread, the parties must apply the written rule rather than assume every stablecoin always equals one dollar.

Choose one of these approaches before sending the invoice:

• Fixed token amount: valid until a stated deadline; simplest for a short payment window.
• Recalculated at payment: use a named, accessible rate source at the stated timestamp; better when settlement may be delayed.
• Minimum net receipt: payer sends enough so the agreed token amount arrives after payer-side fees; recipient-side conversion or withdrawal costs remain separate unless agreed otherwise.

Official issuer information helps identify the asset, but it is not a guarantee of a secondary-market price. Review Circle's USDC information or Tether's transparency information and document the asset you actually accepted.

Use this worked invoice example

The network is intentionally not hard-coded in this example. The correct route is the one currently supported for that asset by both the sender and the receiver—not the cheapest network mentioned in an old article.

Copy this crypto invoice template

Replace every bracketed field. Remove options that do not apply, but never leave an ambiguous asset, network or destination.

CRYPTO PAYMENT INVOICE

Seller
Legal/business name: [SELLER NAME]
Address and registration/tax details: [AS REQUIRED LOCALLY]
Contact: [TRUSTED EMAIL OR PHONE]

Bill to
Customer legal/business name: [CUSTOMER NAME]
Address and tax details: [IF REQUIRED]
Authorized payer/contact: [NAME AND CONTACT]

Invoice
Invoice number: [UNIQUE NUMBER]
Issue date: [DATE AND TIME ZONE]
Due date: [DATE AND TIME ZONE]
Contract / purchase order: [REFERENCE]

Description: [SERVICE, PRODUCT, PERIOD, QUANTITY]
Subtotal: [AMOUNT AND INVOICE CURRENCY]
Tax or adjustment: [AMOUNT / NOT APPLICABLE]
Total due: [AMOUNT AND INVOICE CURRENCY]

Crypto settlement instructions
Asset: [FULL ASSET NAME AND TICKER]
Network: [EXACT BLOCKCHAIN NETWORK]
Destination address: [CURRENT VERIFIED ADDRESS]
Memo/tag: [EXACT VALUE OR NOT REQUIRED]
Token amount: [AMOUNT]
Rate source: [NAMED SOURCE]
Rate observation: [TIMESTAMP AND TIME ZONE]
Rate validity/tolerance: [RULE]
Fees: [WHO PAYS WHICH FEES]

Test transfer
Send [TEST AMOUNT] first, above the receiving minimum.
Wait for written confirmation that it is credited before the balance.
[DEDUCT / DO NOT DEDUCT] the test from the total.

Completion
Payment is complete only when [RECEIVING ACCOUNT] credits the agreed
asset and net total on the agreed network. A screenshot or transaction
hash alone does not prove that the invoice is paid.

Exceptions
Underpayment: [BALANCE AND DEADLINE RULE]
Overpayment: [VERIFICATION AND REFUND RULE]
Material depeg/rate movement: [PAUSE AND RE-AGREE RULE]
Wrong asset/network/address: [STOP, INVESTIGATE, NO RECOVERY PROMISE]
Refunds: [SAME CUSTOMER, VERIFIED ROUTE, ASSET/RATE/FEE RULE]

Compliance and records
The payer may be asked for identity, business-purpose and source-of-funds
information through an approved secure channel. No third-party payer is
accepted without prior written approval and verification.

Customer acceptance
Name / role: [NAME]
Written acceptance reference: [EMAIL, CONTRACT OR TICKET]

For a real payment, send the invoice together with a route card containing only the exact asset, exact network, current destination, memo/tag state and test instruction. Do not put passwords, recovery phrases or one-time codes in any document.

Define exceptions before they happen

Underpayment: keep the invoice open and request the exact balance under the same verified route. Do not silently mark it paid.

Overpayment: verify the original payer and transaction before refunding. Do not refund to a new address supplied in an urgent message; that can turn a compromised invoice into a second loss.

Material depeg or rate movement: pause. Recalculate under the written rule and obtain both parties' written acceptance. Do not alter an issued invoice without an audit trail.

Wrong network, token or missing memo: stop sending. Save the transaction hash and receiving-screen details, then contact the official provider channel. Recovery may be unavailable or charged; never promise it.

Refund: link the credit note or refund record to the original invoice, identify the verified recipient, record asset, network, rate, amount, fees and transaction hash, and screen the route again.

Move the invoice through a controlled lifecycle

1. Draft the commercial and settlement fields.
2. Verify the receiving route and destination.
3. Send a read-only copy and obtain written acceptance.
4. Receive and confirm the crypto test transaction guide.
5. Receive the balance and wait for provider credit—not only an explorer status.
6. Match credited test plus balance to the required net amount.
7. Mark paid with timestamp, transaction hashes and any rate evidence.
8. Archive the contract, invoice, messages, provider statement and later selling USDT and cashing out in Cambodia.

If identity, business purpose or payment origin does not match, use the KYC, AML, sanctions and Travel Rule workflow before proceeding.

The invoice is ready to send when

The invoice is ready only when another person can answer all of these without messaging you:

• Who are the seller, customer and authorized payer?
• What was supplied, in what period, and for what invoice-currency price?
• What exact asset, exact network, current destination and memo/tag state apply?
• How was the token amount calculated, and how long is that quote valid?
• Who pays fees, and how is a test transfer treated?
• What event marks the invoice paid?
• What happens after underpayment, overpayment, depeg, wrong route or refund?
• Which documents will connect the invoice to the transaction and accounting entry?

Issue a paid receipt without rewriting the invoice

Do not overwrite the issued invoice after payment. Keep it as the commercial record and attach a separate paid receipt or settlement note:

CRYPTO PAYMENT RECEIPT
Invoice number: [NUMBER]
Payer / customer: [VERIFIED NAME]
Invoice total: [FIAT AMOUNT AND CURRENCY]
Asset and network: [TOKEN] on [NETWORK]
Test credited: [AMOUNT, TXID, RFC3339 TIME WITH OFFSET]
Main payment credited: [AMOUNT, TXID, RFC3339 TIME WITH OFFSET]
Total net credited: [TOKEN AMOUNT]
Rate evidence: [SOURCE, OBSERVATION TIME, RATE]
Fees or deductions: [ITEMIZED]
Fiat value recognized: [AMOUNT AND BASIS]
Status: [PAID / PARTIALLY PAID / OVERPAID]
Exception or refund reference: [IF ANY]

The receipt should reconcile to the credited balance, not merely the amount the payer says was sent. If the payment is short, leave the invoice partially paid and issue a balance request. If it is overpaid or refunded, create a linked adjustment record rather than deleting the original evidence.

Official references

• Circle: USDC
• Tether: Transparency
• Ethereum.org: Transactions
• National Bank of Cambodia: Prakas and Circulars
• Securities and Exchange Regulator of Cambodia: Current Sandbox List

Educational information only; not legal, tax, accounting, banking or financial advice. Requirements, provider support and networks change. Confirm current local rules and live account instructions before invoicing or paying.