Which exchange rate do you book a crypto payment at?

For most freelancers the answer is: the rate at the moment the payment arrives, not the rate on the invoice date. Your invoice fixes what you are owed in euro; the rate at receipt determines what actually enters your books. The choice between those moments matters less, though, than the question underneath it: which rate source do you use, and do you apply it the same way every time?

This article is only about that: which euro amount lands in your books in the first place, and how you explain that choice later. For the wider picture of recording on-chain payments, see why keeping your blockchain bookkeeping matters.

Two moments, two amounts

A crypto payment contains two moments that ask for a rate, and it helps to separate them.

The first is the invoice date. If you invoice in euro, by far the sensible route for a freelancer, you need no rate at all at that point. There is a euro amount on your invoice, that amount is your revenue, and VAT is calculated on it. The rate plays only a practical role: your client needs to know how much USDC or BTC to send. That is a payment instruction, not a bookkeeping entry.

The second moment is receipt. A quantity of coin lands in your wallet, and it has to be converted into euro before you can post it. This is the conversion that matters. Whatever the rate did between invoice date and payment date does not change your invoice, at most whether the payment covers the invoice amount exactly. Invoice in the coin itself ("0.07 BTC") and there is no euro amount at all until payment, so you have to create two instead of one.

Which rate source do you use?

For ordinary currencies there is an obvious answer: the European Central Bank publishes euro reference rates against a range of other currencies every working day. For bitcoin or USDC no such official euro rate exists. There are only markets, all quoting something slightly different on 18 March at 14:12.

In practice you choose from three families. The first is the exchange you actually trade or cash out on, such as Kraken, Bitvavo or Coinbase; if you really convert the coin there, your entry lines up with what happened. The second is an aggregator publishing a weighted average across several exchanges, such as CoinGecko or CoinMarketCap: less sensitive to an outlier on a single venue, and the historical series stays retrievable. The third is a two-step detour: you value a dollar stablecoin against the dollar first, then convert those dollars at the ECB reference rate for that day, so the heavier leg rests on a source no bookkeeper will question.

Which source suits you depends on how you get paid and what you do with the coin afterwards; none is right or wrong by definition. What a bookkeeper or an inspector wants to do is reproduce your number: same source, same date, same figure. A source that is public, remains retrievable historically and cannot be influenced by you meets that test. A screenshot of a rate you saw somewhere does not.

Which moment within the day?

Within a single day you still have to choose. The three common methods are the rate at the exact timestamp of the transaction, the closing rate of that day, and the daily average. For stablecoins that rarely differs by more than a few tenths of a percent; for bitcoin, on a busy day, it can run into whole percentage points.

Watch one practical detail: blockchains stamp in UTC and your books run in local time. A payment you receive on 18 March at 00:40 sits on the blockchain with a timestamp of 17 March 23:40 UTC. Pick one and stay with it, or transactions around the turn of the year drift into the wrong financial year.

Consistency counts for more than precision

The temptation is to hunt for the "correct" rate on each individual payment. That is the wrong reflex: the moment you take a different source or timestamp per transaction, your amounts were chosen rather than calculated, which is hard to explain even if every single rate was accurate.

So write your method down once, in a few sentences with a date on it: which source, which moment, which time zone, how you round. If you later switch source because the old one disappeared, note the date and the reason and apply the new method from that point forward. Not retroactively.

What you record per payment

For every incoming payment you want to retrieve six things later:

• the transaction hash
• the timestamp including time zone
• the coin and the exact number of units
• the rate used
• the name of the source
• the euro amount that follows from it, plus the invoice number you matched it to

That takes thirty seconds at the time, and an afternoon if you reconstruct it in January. Store the rate itself, not only the source: aggregators sometimes revise their historical series and exchanges disappear.

A worked example

On 4 March 2026 you send invoice 2026-014 to a client in Berlin: EUR 3,500 excluding VAT, 21% VAT is EUR 735, total EUR 4,235. You invoice in euro and agree that the client pays in USDC at the rate applying at the moment of payment. If you are unsure how VAT sits on a crypto invoice, see how VAT works on stablecoin payments.

On 4 March USDC sits at EUR 0.9180. Your payment instruction notes this is indicative: EUR 4,235 works out to 4,613.29 USDC at that moment. The client pays only on 18 March at 14:12 UTC, and your rate source then quotes EUR 0.9210 per USDC.

If things go well, your client converts at the moment of payment and sends 4,598.26 USDC. You value that receipt at the same 0.9210 and arrive at EUR 4,235.00. The invoice is settled exactly, nothing to post.

If things go the way they usually go, the client copied the indication from your email and sends 4,613.29 USDC. You post the receipt at the rate at the moment of receipt: 4,613.29 × 0.9210 = EUR 4,248.84. Your invoice stays at EUR 4,235: revenue stays EUR 3,500 and VAT stays EUR 735, because those are determined by what you invoiced, not by how the rate behaved afterwards. The difference of EUR 13.84 is an exchange result and belongs on a separate exchange differences account, not in your revenue. How exactly you classify it is for your bookkeeper; the point is that you keep it separate.

Had the same invoice been paid in bitcoin, the mechanism would have been more visible. Suppose bitcoin stood at EUR 61,400 on 18 March at 14:12 UTC (an illustrative rate) and the client sends 0.06897 BTC. If you only look in your wallet on 20 March and conveniently use the rate at that moment, say EUR 60,100, you post 0.06897 × 60,100 = EUR 4,145.10. That is EUR 89.90 less, a difference that disappears into the noise with stablecoins and does not with bitcoin.

When the coin is not pegged to the euro

This is the part most often skipped: USDC and USDT are pegged to the dollar, not to the euro. A euro-based business paid in stablecoins therefore carries plain dollar exposure. The move from EUR 0.9180 to EUR 0.9210 above is not a wobbling peg; that is the dollar moving against the euro. "Stable" means stable in dollars.

That has two consequences. You need a real rate for stablecoins too: 1 USDC is not 1 euro, and an entry that assumes it is will be wrong. And an exchange difference arises between receipt and the moment you convert the coin into euro. Receive on 18 March and cash out on 3 April, and that second moment is a separate event with its own rate. For how those amounts end up in your return, see how tax on stablecoins works in the Netherlands.

The same holds for bitcoin, only larger. That does not make your invoice wrong; it means you record two events rather than one.

In short: convert at the moment of receipt, pick one source and one time of day, record the hash, the timestamp, the rate and the source per transaction, and keep exchange differences out of your revenue. The method does not have to be clever, it has to be reproducible.

stbl admin does that conversion for you: every incoming transaction is valued against a fixed rate source at the transaction timestamp, with the rate and source stored alongside the entry, matched to the right invoice, and exportable for your bookkeeper. Your keys stay yours, stbl admin is non-custodial. The Pro plan is EUR 49 per month excluding VAT.