How to Invoice Clients in Stablecoins

Picture this: you wait five business days for a wire from a client on another continent. Then 3% of it disappears, eaten up by intermediary bank fees and a bad exchange rate. That's why crypto invoicing, or invoicing clients in stablecoins, is something more B2B finance teams are searching for. A stablecoin invoice is exactly what it sounds like. It's a normal invoice. Your client settles it in a stablecoin like USDC, paid into an account in your business's name, instead of through a bank wire.

The part most guides still get wrong is how much you have to decide up front. You don't need to ask your client which blockchain they use. You don't need to paste a wallet address into an email. You don't need to send one version of the invoice for the clients who want to pay in crypto and another for the ones who want to pay from a bank account. On a platform like Request Finance, you label the invoice in a currency and send it. The payer picks how to settle it. This guide walks through that flow. It also covers the accounting questions worth answering before your first invoice goes out.

Why invoice in stablecoins at all

For a domestic client paying in the same currency you invoice in, none of this matters. A normal invoice and a bank transfer work fine. The case for stablecoins shows up specifically in cross-border B2B billing.

Wire and card network fees stack on the client's side and yours. A client paying a $10,000 invoice from another country can lose 2 to 5% to intermediary bank fees and conversion spread before you even see the money. That's on top of whatever your own bank charges to receive it.

Settlement depends on banking hours, not on either of you. A same-day domestic transfer can still take two to five business days to clear internationally. Longer around weekends or local holidays. That's a real problem when it's the difference between making payroll on time or not.

Currency mismatch creates its own friction. Invoicing a client in your currency, when they hold a different one, means either you or they absorb a conversion, often at a worse rate than either of you would get on your own.

A USDC payment settles in seconds to minutes, 24/7. No banking hours dependency. Both sides transact in the same unit of account. It doesn't remove every friction (more on the accounting side below). But it removes the slowest and most expensive part.

What you decide, and what your client decides

Most of a stablecoin invoice is just an invoice: your business details, the client's, a description of the work, the amount, and payment terms. What's changed is that the crypto-specific details are no longer yours to solve in advance. The table below shows the difference between the two ways of doing this.

The only currency decision you make is the invoice currency. That's a labeling choice, the unit the amount is expressed in, not a constraint on how the client pays it.

How it works, end to end

1. Get verified once. When your business clears KYB (know your business) verification, Request Finance opens both sides of the account at the same time: virtual accounts in fiat, and crypto wallets. There's no separate application for the stablecoin part. Nothing to set up in a wallet app first. This verification is also the compliance layer, it's what lets a stablecoin payment count as an auditable business transaction, not an anonymous transfer.

2. Create the invoice and label it in a currency. USD, for example. Standard invoice fields otherwise.

3. Choose where you want the money to land. The simple path is your Request Business Account, or send it out to an external wallet you control, if you'd rather hold it yourself.

4. Send it. One invoice, one link. No payment instructions to write out, no address to copy into an email and hope it survives.

5. The payer chooses how to settle. This step used to be a back-and-forth. Now it isn't. Your client opens the invoice and picks: pay in crypto, or pay in fiat. On the crypto side, that currently means USDC on Ethereum, Base, or Solana; EURC on Ethereum; or USDT on Ethereum or Tron, each at 0% fee, with small minimums (2 USDC, or 3 EURC). On the fiat side, they pay by bank transfer to the virtual account, the same way they'd pay any other supplier. You never had to know which one they'd choose.

6. It all lands in the same balance. Whichever rail your client used, the payment arrives in one balance on your side. A USD invoice settles into your USD balance. No reconciling three wallets against one invoice. No working out which chain the money came in on.

7. Offramp when it suits you. That balance sits in your account until you move it. You can send it to your own bank account on your own schedule, rather than converting each payment the moment it arrives.

8. Pull a statement when you need one, over any period you choose, an opening and closing balance, plus a line for every transaction. This is the part that makes month-end stop being a special case. More on that below.

Worth sitting with how short that list is on your side. You issue one invoice, in one currency. The two decisions that used to cause all the friction (which stablecoin, which network) now get made by the person paying, at the moment they pay, against payment details the invoice generates for them. Your client's experience is closer to picking a payment method at checkout than to making a crypto transfer.

The accounting and tax questions to answer before you send one

This is general practice, not tax advice. The specifics depend on your jurisdiction and your accountant's guidance. But a few questions are worth raising before your first stablecoin invoice goes out, rather than after.

How is the payment recognized for revenue purposes? In most treatments, receiving a stablecoin in payment of an invoice is recognized like any other payment; at the invoice amount, in the currency the invoice was denominated in. The figure your accountant wants is the value on the day it arrived: the USD amount credited to your balance.

Is there a gain or loss to track? A stablecoin is pegged to (usually) the US dollar, but it isn't identical to holding dollars. Some jurisdictions may still treat it as a digital asset for tax purposes. That means a small gain or loss could technically arise between receipt and conversion. Whether that's material enough to track is your accountant's call. Answering it needs the asset amount and the value at the moment it landed, both sit on the same statement line.

What if the client pays in a stablecoin pegged to another currency? Take EURC settling into a USD balance: a conversion happens, a rate gets applied, and your accountant will want to see it. The statement carries both sides of that line, the asset amount received, and the USD amount credited.

Does the payment need to be reported the same way a fiat payment would? In the US, for example, contractor and vendor payments over certain thresholds typically trigger 1099 reporting, regardless of the payment rail used. A stablecoin payment doesn't exempt either side from existing reporting obligations. Worth confirming this, rather than assuming it.

Can you hand your accountant one document? This used to be the question with the worst answer. Rebuilding a quarter of stablecoin receipts from a block explorer, matching hashes to invoices by hand, that's what makes finance teams avoid crypto rails altogether. Request Finance issues an account statement for the Request Business Account over whatever period you choose. It includes an opening and closing balance, then a line per transaction: date in UTC, counterparty, network used, transaction hash, the amount in the asset your client paid in, and the amount in USD. It reads like a bank statement, what an accountant, an auditor, or a tax authority expects to be handed.

The questions above still deserve five minutes with your accountant. The answers still depend on where you file. What's changed is that you now answer them from a document, not a block explorer.

Common mistakes to avoid

Asking the client which network they want before you invoice. An understandable habit, but now an unnecessary round trip. Send the invoice and let them answer that question at payment time.

Sharing a raw wallet address instead of sending an invoice. This is where wrong-network losses actually happen; a stablecoin sent on a network the receiving wallet doesn't support can be unrecoverable. When the payment details come from the invoice, that risk goes away. You also get a record tied to the invoice, not a transaction hash in a chat thread.

Accepting payment in a volatile asset instead of a stablecoin. If a client offers to settle in something other than a stablecoin, that introduces real price movement between invoicing and payment. That's exactly what a stablecoin invoice avoids. Stablecoins are pegged to a currency with no fluctuation.

Leaving verification until you need it. Some businesses design a whole invoicing workflow before realizing KYB is the gate for the accounts and wallets it depends on. Then they hit the delay on a live invoice, with a client waiting. It's a matter of days, not weeks. But do it before you need it, not after.

Assuming the accounting is identical to a fiat invoice. Most of it is, but the questions above are cheaper to ask your accountant before your first invoice than after your tenth.

Getting started

Invoicing in stablecoins solves a specific, expensive problem: getting paid by cross-border clients without losing days to bank rails, or a chunk of the invoice to fees and spread. What's changed recently is how little of it you have to think about. Get verified. Label the invoice. Send it. Let your client settle it however they like (in crypto or from their bank). It lands in one balance, and you move it to your own account whenever you choose.

See how Request Finance's Accounts Receivable tools handle this end to end.

Weighing invoicing platforms against each other? See our shortlist of the best crypto invoicing platforms.