A supplier issues an invoice for 0.4 BTC, net 30. The client pays on day 29. Whatever the invoice was worth on day one, it is worth something else now, and the difference is a currency result that nobody budgeted for and the accounting system has no field for. The fix costs nothing: the invoice says EUR 12,000, payable in bitcoin at the rate quoted at the moment of payment. The amount of coin is calculated at settlement, not at issue.
That single change removes most of the pain from crypto invoicing. What remains is operational: which networks you accept, how long a quoted rate stays valid, what you do with an underpayment, and how the transaction lands in the ledger with a fiat value attached.
The price-lock window is the whole product
Every crypto payment processor works the same way. The payer opens the invoice, the processor quotes an amount of coin against the fiat total, and that quote holds for a fixed window, commonly measured in minutes rather than hours. Pay inside the window and the processor takes the price risk. Miss it and the quote is recalculated.
Short windows protect the processor and irritate the payer, particularly on networks where confirmation is slow. This is one reason stablecoin rails dominate business-to-business crypto invoicing: with a coin pegged to a currency, the window matters far less, and the settlement value is close to the invoice value by construction. The trade-offs between the major stablecoins are about issuer, reserves and network support rather than about volatility.
Where the payer insists on paying in a volatile asset, the practical answer is a processor that converts on receipt and settles to you in fiat or a stablecoin. Holding the coin is a treasury decision, and it should be taken deliberately rather than absorbed by accident through the invoicing flow. The mechanics of that conversion sit in settlement value handling.
Network choice, and the underpayment problem
The same token exists on several chains, and a payment sent on the wrong one is not a late payment, it is a lost payment. Any crypto invoice needs the network named as prominently as the address, and the address itself should be network-specific rather than reused. The difference between the common USDT networks is fee level, confirmation speed and wallet support, and clients will have a preference driven by whatever exchange they are withdrawing from.
Underpayment is the other recurring failure. The payer's wallet deducts the network fee from the sent amount, so an invoice for 1,000 units arrives as 998. Decide the policy in advance and write it on the invoice: either a tolerance band that treats small shortfalls as paid in full, or an automatic balance line on the next invoice. Chasing two units of a stablecoin through email costs more than it recovers.
| Invoice field | What to put | Failure it prevents |
|---|---|---|
| Amount | Fiat total, with the coin amount marked as indicative | Currency exposure between issue and payment |
| Network | Named explicitly, one address per network | Funds sent on a chain you cannot access |
| Quote validity | The exact window in minutes | Disputes about which rate applied |
| Fee treatment | Who absorbs the network fee | Systematic underpayment on every invoice |
| Tolerance | The shortfall you accept as settled | Manual chasing of trivial balances |
Recording it so the books survive an audit
Accounting treatment varies by jurisdiction, and this is territory for your own accountant rather than a blog. The mechanical requirement is consistent everywhere: each incoming payment needs a fiat value recorded at the moment of receipt, a reference to the transaction hash, and the source used for the rate. Recording only the coin amount leaves someone reconstructing rates from history a year later, which is how small discrepancies become large ones.
Keep the transaction hash in the same record as the invoice number. It is the only durable link between the ledger entry and the chain, and it is what a reviewer will ask for first. Processors export this, but exports get lost when contracts end, so the hash belongs in your own system too.
Crypto invoicing sits inside AML obligations, not outside them. Accepting payment from an unknown wallet is a counterparty risk decision, and firms in regulated activities carry screening and source of funds duties that apply to a chain payment exactly as they apply to a wire.
Who you are allowed to accept from
Business-to-business crypto invoicing usually involves counterparties you already know, which makes the compliance question narrower than it is for retail deposits. It does not make it disappear. Screening the paying wallet against sanctions and known-illicit clusters is standard practice at any processor worth using, and firms should keep the screening result attached to the payment record. The general shape of these duties is covered in sanctions screening.
Where the transfer crosses a threshold and both sides are regulated service providers, originator and beneficiary information travels with the payment under the travel rule. That obligation falls on the service providers rather than on the invoicing business, but it explains why a processor asks for details you did not expect to supply.
When crypto invoicing is the wrong tool
For a domestic invoice between two firms with accounts at ordinary banks, a bank transfer is cheaper, faster to reconcile and easier to reverse when something goes wrong. Crypto invoicing earns its place on cross-border payments where the alternative is a correspondent chain, on corridors where account access is unreliable, and where the counterparty already holds the asset. Outside those cases it adds reconciliation work for no benefit, and the honest recommendation to a small firm is usually to keep the bank rail as the default and offer crypto as the exception.
"Write the invoice in euros and let the wallet do the conversion at the moment of payment. Every firm I have seen get burned by crypto invoicing wrote the amount in the coin."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Denominate the invoice in fiat and calculate the coin amount at payment, so the exchange rate risk never sits on your balance sheet.
- Name the network beside every address, and set a written policy for network fees and small underpayments before the first invoice goes out.
- Record a fiat value, the rate source and the transaction hash against each payment, in your own system rather than only in the processor's export.
- Crypto invoicing pays off on cross-border and account-constrained corridors, and adds work without benefit on ordinary domestic invoices.
Frequently Asked Questions
Should an invoice be payable in bitcoin or in a stablecoin?
A stablecoin removes almost all of the price movement between issue and payment, which is the main operational problem. Bitcoin invoicing works when the payer holds bitcoin and a processor converts on receipt.
What happens if a client pays after the quote window expires?
The processor recalculates at the current rate. Depending on direction the payment then over or under-covers the invoice, so a written tolerance and balance policy avoids arguing about it case by case.
Does accepting crypto invoices require a licence?
Accepting payment for your own goods or services is different from providing crypto services to others. Firms already in regulated activity should check whether the flow touches their permissions, and take local advice before assuming it does not.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.