How to write an invoice in USDC or bitcoin

An invoice that will be paid in crypto is still just an invoice. It has to contain everything an ordinary invoice contains, plus one extra block: the amount in the coin, the exchange rate you used to calculate it, the receiving address and the network you want to be paid on. The most important decision you make in that block is which of the two amounts leads, the euro amount or the coin amount.

This article is about the document you send, not about what arrives afterwards. How you record and convert a payment once it lands is a separate story, and we cover it in why keeping your blockchain bookkeeping matters. Here we stay with what you put on paper beforehand, so your client knows what to do and you know later which invoice a payment belongs to.

What has to be on it regardless

The basic requirements for an invoice do not change because payment happens in USDC. Across the EU the list is broadly the same: your own name and address, your VAT identification number, in the Netherlands your Chamber of Commerce number as well, your client's name and address, an invoice number from a sequential series, the invoice date, the date you delivered the service, a description and quantity, the amount excluding VAT, the VAT rate, the VAT amount and the total.

If you supply a business client in another EU country, additional rules apply, such as your client's VAT number and a note if VAT has been reverse charged. Exactly what has to appear depends on who your client is and where they sit. If you are not sure, that is a question for your accountant, and the payment method changes nothing about it. We go through the detail in how VAT works on stablecoin payments.

One point does matter here: the VAT should be expressed in euro. Even if you state the rest of the invoice in another currency, the VAT amount has to be findable on the invoice in euro. That is precisely why an invoice drawn up entirely in bitcoin creates more work than a euro invoice with a payment instruction attached.

Euro or coin: which amount leads

There are two ways to do it. You invoice in euro and add the crypto amount as a payment instruction. Or you invoice in the coin itself and add the euro equivalent for the VAT.

For nearly every freelancer the first version is the sensible one. Your price is fixed in the currency you pay your own costs in, your VAT amount is fixed, and any movement in the rate between sending and paying falls to your client: they simply transfer the equivalent of EUR 1,839.20, whatever the rate does. Invoice in the coin ("0.021 BTC") and that risk sits with you. Your invoice can be worth a few percent less on Monday than it was on Friday.

Put it on the invoice explicitly so there is nothing to argue about later. One sentence is enough: the euro amount leads, the USDC amount is indicative and calculated at the rate stated. With a stablecoin the gap is small but not zero. With bitcoin it can grow meaningfully within a payment term.

The rate: which source and which moment

A rate without a source and a timestamp is not a rate, it is an estimate. So state three things: the currency pair, the source and the moment. For example: "EUR/USDC 1.0812 per [your rate source], 8 June 2026 at 09:14 UTC."

Pick one source and stay with it all year, for every invoice and later for your conversion on receipt as well. Switching sources because one happens to suit you better on a given day is exactly the kind of inconsistency an audit picks up on. Note the time in UTC, because blockchain transactions are timestamped in UTC and you do not want to be working out afterwards whether 09:14 was local time.

What this rate does not do is decide what you eventually put in your books. The rate on the invoice is a calculation aid for your client. The value you record depends on the payment itself, which belongs to the next stage of the route rather than to this document.

Address and network: the field where it goes wrong

The receiving address belongs on the invoice, and the network belongs next to it. That second part is the one most often left off, and it causes the most expensive mistakes. USDC exists on Ethereum, on Base, on Polygon, on Solana and on a handful of other networks. All of them are genuine USDC, but they are not interchangeable balances. If your client sends USDC over Polygon to an address you only control on Ethereum, the money is recoverable with technical help at best and gone at worst.

Write the address out in full, in a single block, without a line break in the middle. Name the network in plain language beside it: "USDC on Base", "USDT on Ethereum (ERC-20)", "Bitcoin (mainnet)". If you want to receive on more than one network, name one as your preference and at most one alternative. The more choice you offer, the higher the chance something goes wrong. If you are still choosing, see which network is cheapest for stablecoins.

Where you can, use a separate receiving address per client or per invoice. It costs you nothing and saves a lot later: a payment that arrives at a unique address more or less matches itself to the right invoice.

Payment terms and what you agree if the rate moves

A crypto payment is usually final within minutes, so a long payment term serves little purpose and only widens your exposure to rate movement. Fourteen days is common, and seven days is defensible for bitcoin. Do not cut it so short that your client cannot meet it.

Beyond that, agree two things an ordinary invoice never needs. First, who carries the network fee. The usual arrangement is that the client pays it, so that the amount arriving with you equals the amount on the invoice. Write that down literally, or you will get invoices that land a few euro short.

Second, what happens if the rate moves between sending and payment. A workable arrangement is a tolerance: payments landing within, say, 1% of the euro invoice amount count as settled in full, and anything beyond that triggers a top-up payment or a credit note. That is a commercial agreement between you and your client rather than a tax rule, but it stops you having to issue a correction over EUR 4.

A worked example

Here is what it looks like in practice. Studio Vermeer, a sole trader in Amsterdam, invoices a client in Berlin for UX research and wants to be paid in USDC.

• Invoice 2026-041
• Invoice date: 8 June 2026
• Delivery date: May 2026
• From: Studio Vermeer, Havenstraat 12, 1013 AB Amsterdam, VAT NL001234567B01, CoC 87654321
• To: Nordlicht GmbH, Torstrasse 40, 10119 Berlin
• UX research, 16 hours at EUR 95.00: EUR 1,520.00
• VAT 21%: EUR 319.20
• Total due: EUR 1,839.20

Payment in USDC

• Amount payable: 1,988.54 USDC
• Rate: EUR/USDC 1.0812 per [rate source], 8 June 2026, 09:14 UTC
• Network: Base
• Address: 0x9f2c4b8e1d7a3056fbc9e2a41d80b6537c1e4a92
• Payment term: 14 days, due 22 June 2026

Conditions for payment in crypto

The euro amount of EUR 1,839.20 is leading. The USDC amount is indicative and calculated at the rate stated above. Network fees are for the account of the client, and the amount received must equal the amount stated. Payments with a value within 1% of the invoice amount count as settled in full. Pay only on the network stated, because payments sent via another network cannot be processed.

That is all there is to it. Four extra lines and a short block of conditions, and the rest is the invoice you were making anyway.

In short

Invoice in euro, add the crypto amount as an instruction, and make explicit which of the two leads. State the rate, the source and the moment. Write the address and the network out in full and leave no doubt about that network. Keep the payment term short, and record who carries the network fee and what deviation you accept. After that it is up to the payment, and that is the point where the manual work begins.

stbl admin generates a unique receiving address per invoice, watches for the payment that arrives on it, values it in euro against a fixed rate source and matches it back to the right invoice. Your keys stay yours: stbl admin is non-custodial and never touches your money. The Pro plan is EUR 49 per month excluding VAT.

This article is general information and not tax advice. Your situation may differ and rules can change. Speak to a qualified tax adviser or your accountant for guidance on your circumstances.