How to Create a Crypto Invoice for Clients: Fields, Rate Locks, and Reconciliation

A Berlin dev shop billed a client 18,000 USDT on Ethereum. Four days later the client paid, from a Kraken account, on Tron. What landed was 17,996 USDT at an address nobody in finance recognized, with no invoice number attached to anything.

Nobody broke a rule.

The invoice just didn't say enough, which is how it goes wrong when you create a crypto invoice for clients: not fraud, not a hack, just a receivables ledger that no longer matches the chain.

Templates mostly treat a crypto invoice as a normal invoice with a wallet address glued to the bottom, and that works until the second one. What follows is the operational side: what goes on the document, how you match an anonymous transfer back to a customer, and what to do when the payment lands 4 USDT short.

What a crypto invoice template needs that a normal invoice doesn't

Fiat invoices carry a payer, an amount, a currency, a due date, and bank details. The rails do the rest quietly: what arrives is what was sent, the sender's name comes attached, and a missing reference can be traced.

None of that holds on-chain. A transfer is value moving between two addresses. No payer name, and on Ethereum and Tron no usable memo field. So the document has to carry the routing information the rails don't.

Rate source matters because there is no single price for anything. USDT trades a fraction either side of a dollar on any afternoon: noise on a stablecoin invoice, not on an ETH one. Name the venue and the timestamp.

The reference instruction matters because you probably can't use one. XRP and Stellar have destination tags; ERC-20 and TRC-20 transfers carry no field your payer's exchange will let them fill in. Which is why issuers who've been burned do one of two things: a fresh receiving address per invoice, or the amount itself as the identifier, with distinctive trailing cents (18,000.41 USDT, not 18,000.00).

Cheap, and it works at low volume, until two clients round differently.

The gap between issuing and getting paid

Here's the part nobody puts in a template. You issue Monday, their finance team approves Wednesday, their treasury sends Friday. In those four days, the asset you invoiced in moved.

Invoice in a stablecoin and the exposure is small, mostly issuer risk. Invoice in ETH and a four-day window on a $30,000 bill can swing several thousand dollars either way.

Three approaches, in the order most businesses should consider them:

1. Denominate in fiat, settle in stablecoin. USD 18,000, payable in USDT or USDC at 1:1. Price risk roughly disappears. Most B2B issuers do this, and it's usually right.

2. Denominate in fiat, settle in a volatile asset, with a rate lock. USD 18,000, payable in ETH at the quoted rate, valid 60 minutes. Anything later re-quotes. This needs tooling; a human recalculating rates over email is a slow-motion argument.

3. Denominate in the asset. "0.4 BTC, due in 30 days." Sane only between parties who both hold that asset in treasury. Rare in services, common protocol to protocol.

A fourth pattern you'll be sold: dynamic invoices whose crypto amount updates live until payment lands. Elegant in a demo, but your AR aging becomes a moving target and the receivable's carrying value moves with no economic event behind it.

And if a client pays two days after the quote lapsed, at the old amount, you're short on a position you never agreed to hold. Decide whether you re-invoice the difference or absorb it, and put it in your terms.

How to create a crypto invoice and reconcile it, step by step

One invoice, quote to closed book. This is how to create a crypto invoice for clients without a reconciliation mess three months later, and it's the sequence I'd hand a new finance hire on day one.

Step 1. Fix the denomination and the settlement pair. Write the fiat amount first. Then pick one asset and one chain, and confirm the client can send that pair from wherever their money sits. USDT on Tron and USDT on Ethereum are different instruments here; the tradeoff between ERC-20 and TRC-20 is fees against counterparty reach.

Step 2. Generate a receiving address for this invoice. One address, one invoice, if your setup allows it. That alone removes most of the reconciliation work later, because the address becomes the invoice number. Stuck with a shared address? Use unique trailing cents.

Step 3. Quote the rate and stamp it. Rate, source, UTC timestamp, on the invoice. For a stablecoin at 1:1 it's a formality. Do it anyway: "1:1" with no source is an assertion, not a record. Every invoice you send lands in the payables process on the other side, where matching and approval decide when you actually get paid.

Step 4. Put the tolerance and fee rules on the document. Sender pays network fees. Underpayments inside the band close the invoice; anything beyond stays open. Overpayments go back to a nominated address, less the return fee. Three sentences, half your future disputes gone.

Step 5. Send instructions that survive a copy-paste. Address as selectable text and as a QR, chain named on the same line, amount in both fiat and crypto, expiry in UTC. Assume the person paying is an ops assistant with an exchange login, not a crypto native.

Step 6. Watch the address, not your inbox. Set the confirmation threshold you'll treat as final. Tron confirms in seconds; on Ethereum a dozen confirmations is normal for business-sized amounts. Don't release work on a zero-confirmation sighting.

Step 7. Match the transaction to the invoice. Capture the hash, the sending address, the exact amount received, the block timestamp, and the fiat value at that timestamp. Those five items are your audit trail.

Step 8. Resolve the gap. Compare received against expected. Inside tolerance, close it and book the shortfall as a fee expense. Outside it, request a top-up or credit-note the balance. Don't leave a $62 residual open for nine months.

Step 9. Book it in fiat, then close. Revenue at the fiat value on the receipt date, the asset on the balance sheet at that same value, and every movement afterward is treasury gain or loss, not revenue. Getting that boundary wrong is the most common error in crypto accounting for businesses, and it compounds before anyone notices.

Step 10. Send a receipt with the hash on it. Your client's accountant needs the same trail you do. Give it to them and the March emails stop.

Where crypto invoicing breaks in practice

Wrong network is the famous failure and, honestly, the least common now. Tron addresses start with T, Ethereum addresses with 0x, and most wallets refuse the obvious mismatch. Riskier is the same-format, different-chain case: Ethereum, Arbitrum, BNB Chain, and Polygon all use 0x addresses. A payer who picks "USDT (BEP-20)" from a dropdown and pastes your Ethereum address produces a transfer that succeeds on the wrong chain.

Control the key and it's recoverable with effort. With a custodial deposit address on an unsupported chain, recovery ranges from a support ticket to nothing.

Then the asset swap. You invoiced USDT; USDC arrives. Same dollar, different issuer, different contract, and a strict matching rule rejects it. Plenty of teams accept the substitution and note it. Some can't, because their off-ramp takes only one.

Partial payments come mostly from exchange mechanics. On most exchanges the network fee is deducted from the amount typed rather than added on top, so a payer who enters your invoice total to the cent always sends slightly less. It's a UI default, not the client being cheap.

Which is what the tolerance band is for.

Dust arrives in two flavors. Benign dust is the sub-dollar residue left after partial sweeps, tedious at year-end when you're valuing 47 balances of three cents. Malicious dust is address poisoning: an attacker sends a near-zero transfer from an address whose first and last four characters match yours, hoping your client copies the wrong one next time. Tell clients to copy the address from the invoice, never from history.

Last, the quiet one. Your client pays from a sanctioned-adjacent address, and the provider flags the deposit after it lands. Screening inbound addresses before you credit them isn't paranoia; it's the difference between an inconvenience and a frozen balance. Anyone running a serious flow for accepting USDT payments builds that check in.

Reconciling a payment sent from an exchange

The majority case in B2B, and where naive matching logic dies.

When a client pays from Binance or Kraken, the sending address belongs to the exchange's hot wallet, not the client. It's shared by thousands of users and may be a different one next month. Matching on sender address works for self-custody payers and produces nothing here. So you match on what you controlled: receiving address, then amount, then timing.

Everything else is a guess.

A rule that holds up: never accept a payment method that gives you fewer identifiers than open invoices. Forty invoices, one shared address, round amounts, and you have forty payments a month you can't match deterministically.

Your customer, for KYC purposes, is the legal entity on the invoice. The exchange is the pipe. Keep the invoice, the client's payment confirmation, and the hash together, because if a bank later asks how a stablecoin balance arose, the chain alone won't answer it. That trio is what makes crypto bookkeeping survivable rather than archaeological.

Recurring crypto invoices

Recurring crypto invoicing isn't the card problem with different plumbing. Nobody can pull funds from a self-custody wallet. Every payment is a push.

That leaves three options. Manual recurrence, where your system sends on a schedule and the client pays each cycle: unglamorous, and what most retainers run on. On-chain approvals, where the payer signs a token allowance and a contract pulls: clean, but impossible for anyone paying from an exchange. And streaming payments through protocols like Sablier or Superfluid, popular for DAO contributor pay and almost absent from vendor billing.

Between two normal companies, option one wins on boring practicality. Set the schedule, send early enough for the client's approval chain, use a fresh address each cycle, and re-quote each time instead of locking a price for a year. Where the recurring flow is really contributor payroll, the Web3 payments side is a better starting point.

VAT, sales tax, and the accounting side of crypto invoicing

Getting paid in USDT changes the settlement rail, not the tax event. In most jurisdictions the supply happens when the work is delivered, and VAT or sales tax is computed on the fiat value of the consideration. Show tax in fiat, at the rate applicable on the tax point date.

In the EU, exchanging crypto for fiat has generally been treated as VAT-exempt since the CJEU's 2015 Hedqvist decision. Hedqvist covers the exchange itself, not the underlying supply. Selling design work for USDT still carries VAT on the design work.

In the US, the IRS treats digital assets as property, so receiving USDT is receipt of property at fair market value and disposing of it later is a taxable event measured against that basis. Form 1099-DA now applies to digital asset transactions, and the 1099-NEC threshold moved to $2,000 under OBBBA. FASB ASU 2023-08 requires fair-value measurement of crypto holdings, welcome news for anyone tired of impairment-only treatment.

Two records make this manageable, the same two from step 7: the fiat value at receipt, and the hash.

What to look for in a crypto invoice generator

Five questions, rather than another ranking. Each one is really asking the same thing: how cleanly a paid invoice lands in your accounting records, and how much manual work is left when you reconcile that payment against the ledger at month end.

Does it issue a unique receiving address per invoice, or make you share one? Biggest single determinant of how much manual matching you'll do.

Can it hold a rate for a stated window and show the expiry to the payer? Anything vaguer and you're arbitrating rates by email.

Does it screen inbound addresses before crediting, or after? Post-hoc screening gives you a log file and a frozen balance.

Does the export carry hashes, timestamps, and fiat values into your ledger, or hand you a CSV of crypto amounts? Ask to see a real one before you sign.

And what does a payment cost, all in? Pricing models diverge more than feature lists do. Some providers take a percentage of volume; VaultNow charges $0.50 per transaction plus gas and supports USDT on ERC-20 and TRC-20, USDC on ERC-20, ETH, and TRX. Which model wins depends on your average invoice size, so run a month of real invoices through both. The overview of stablecoin payment processors is worth reading alongside.

Be skeptical of anything marketed as a standalone crypto invoice generator. Producing a PDF with an address on it is the easy 5% of the problem. Watching the chain, matching payments, handling tolerance, and exporting something your accountant accepts are the rest.

Where to start on Monday

Pull your last twenty invoices. For each, check whether you could identify the payer from on-chain data alone, and whether the amount received matched the amount billed to the cent. If more than two or three fail either test, the template isn't your problem: you have no per-invoice identifier and no stated tolerance.

Fix that before you evaluate a single vendor.

Then write down your rate policy, your tolerance band, and your refund rule, and fold them into your standard terms. How to create a crypto invoice for clients stops being an open question the moment those three decisions are written down instead of made per-invoice by whoever happens to be looking at the wallet that afternoon.

If you'd rather not build the matching and screening layer in-house, VaultNow does invoicing, AML address screening, and wallet tracking from one dashboard.

Frequently asked questions

How do I create a crypto invoice for clients?

To create a crypto invoice for clients, start with a fiat amount, then add the six fields a normal invoice lacks: settlement asset, network, receiving address, the rate and its source with a UTC timestamp, a quote expiry, and an underpayment tolerance. State that the sender pays network fees, and use a unique receiving address per invoice, since it does the job of the reference ERC-20 and TRC-20 transfers can't carry.

What should a crypto invoice include?

Everything a fiat invoice carries, plus five things the rails no longer supply: the settlement asset, the network, a receiving address, the rate with its source and timestamp, and an underpayment tolerance. A regular invoice relies on the banking system to deliver the sender's identity, the exact amount, and a traceable reference. Blockchain transfers deliver none of the three, so the document has to carry that routing information itself.

How do I handle price volatility between issuing and getting paid?

Denominate in fiat and settle in a stablecoin, which removes almost all the exposure. If the client insists on paying in ETH or BTC, quote a rate with a short expiry, typically 15 to 60 minutes, and re-quote when it lapses. Put your policy for expired quotes in your terms rather than negotiating case by case.

What happens if a client underpays a crypto invoice?

Nothing dramatic, provided the invoice stated a tolerance band. Most shortfalls are a few dollars, caused by the exchange deducting the network fee from the amount typed rather than adding it on top. Set the band at something like 0.5% or USD 10, whichever is greater. Anything inside it closes the invoice and books as a fee expense; anything larger stays open until the client tops it up or you credit-note the difference.

What happens if a client sends USDC when I invoiced USDT?

You've received the same dollar value from a different issuer on a different contract, so the money is fine, but reconciliation flags a mismatch. Most businesses accept the substitution and note it on the invoice record. You can't do that if your off-ramp handles only one of the two, which is why the accepted asset belongs on the invoice explicitly.

Can I send recurring crypto invoices?

Yes, though not as automatic direct debits. Nobody can pull funds from a self-custody wallet, so recurring billing means a scheduled invoice the payer pushes each cycle, unless they sign an on-chain token approval letting a contract pull. Exchange-based payers can't sign approvals. Schedule the send, use a fresh address per cycle, and re-quote each time.

Do I still charge VAT on a crypto invoice?

Yes. Being paid in stablecoins changes the settlement rail, not the tax event. VAT or sales tax is calculated on the fiat value of the supply at the tax point and must appear in fiat on the document. The EU's 2015 Hedqvist ruling exempts crypto-to-fiat exchange itself, but it doesn't touch the goods or services you're billing for.

How do I match a blockchain payment to the right invoice?

Match on the receiving address first, the exact amount second, timing third. Sender address is unreliable, because exchange payments come from shared hot wallets serving thousands of users. Give each invoice its own receiving address, or make the amount distinctive with non-round trailing cents. Record the hash, sender, amount, block timestamp, and fiat value at that timestamp.