Crypto bookkeeping: the complete guide for EU freelancers

A payment in crypto is, for your books, just a payment. You record it in euro, you match it to an invoice, you file the VAT on it, and you close the year — exactly as you would with a bank transfer. The only real differences are two: you have to establish yourself what the payment was worth in euro at the moment you received it, and you get no bank statement with your client's name on it.

Those two differences cause almost all the confusion. This guide walks the entire route a crypto payment travels through your bookkeeping, from the agreement with your client to the year-end close, in eight steps. Each step covers what you need to record, where it goes wrong, and where the line sits between what you can handle yourself and what belongs with your accountant.

Why crypto bookkeeping feels harder than it is

With an ordinary bank payment, your bank quietly does three things for you. It states the amount in euro, it attaches the payer's name, and it produces a statement your accounting software imports automatically. A blockchain does none of the three. You see an amount in a token, an address of 42 characters and a timestamp in UTC. Who is behind it and what it belongs to is something you have to add.

The rest of your bookkeeping does not change. Your invoice is still the basis of your revenue, your VAT is still calculated on the invoice amount in euro, and your return looks no different from one where the client paid by bank.

What does change is visibility. Since 1 January 2026, EU crypto-asset service providers must record and verify customer and transaction data under DAC8. The first report, covering the year 2026, must be filed with the tax authority by 31 January 2027. The OECD equivalent, CARF, runs in parallel and has been activated across 48 countries, with data collection from 2026. This does not create a new tax. It means that what you declare and what the tax authority already knows are increasingly laid side by side. More on what DAC8 means for freelancers paid in crypto.

Step 1: the agreement with your client

Your bookkeeping starts before there is an invoice. When you take on work that will be paid in crypto, you agree three things: which currency you invoice in, which coin you are paid in, and which moment sets the exchange rate.

The sensible arrangement for a freelancer is to invoice in euro and let the client pay the equivalent in USDC, USDT or BTC. Your price is then fixed, and the rate risk between invoice date and payment date sits with the client. If you invoice in the coin itself ("0.04 BTC"), you carry that risk, and an invoice sent on Friday can be worth a few percent less by Monday.

The moment that sets the rate matters just as much. Agree explicitly that the rate at the time of the transaction applies, not the rate on the day the invoice was drawn up. Put it in your quote and repeat it on the invoice. Without that sentence you get discussions about a fifty-euro difference that cost far more time than fifty euro is worth.

Agree as well on who pays the network fees and which network you want to be paid on. The same USDC exists on several blockchains, and a client who sends to the wrong network costs you an afternoon at best. See which network is cheapest for receiving stablecoins.

Step 2: the invoice

An invoice for a crypto payment is an ordinary invoice. All the usual requirements apply in full: your name and address, your VAT identification number, your company registration number, your client's details, a unique invoice number, the invoice date, a description of what you delivered, the amount excluding VAT, the rate and the VAT amount. Being paid in crypto changes none of that.

What you add is a payment instruction. It states the receiving address, the network, the coin, and the sentence about which moment sets the rate. It also helps to include a reference the client can send along, or to tie the invoice to a unique receiving address, so you know later which incoming transaction belongs to which invoice.

The amount on the invoice stays in euro. Even if the payment arrives in USDT, your revenue is the euro amount on the invoice and your VAT is the VAT amount on the invoice. You may add the expected crypto amount for information, but say clearly that it is an indication based on the rate at that moment.

If you supply a business client in another EU country, the ordinary reverse charge rules apply and you state that on the invoice. The payment method plays no part.

Step 3: receiving the payment

The moment the transaction is confirmed, something exists that you have to record. Capture at least five things: the transaction hash, the time of confirmation, the coin and the exact number of units, the receiving address, and the sending address.

The transaction hash is your evidence. It is the equivalent of the line on your bank statement and anyone can verify it on the blockchain. Keep it in your records alongside the invoice, the way you would keep a payment reference. If the tax authority asks three years from now where that revenue came from, the hash is the shortest answer. See also how to prove your crypto income.

Watch the timestamp. Blockchains log in UTC while your books run on local time. In summer that is a two-hour gap, and two hours is enough to push a transaction confirmed at 00:30 on 1 January into the wrong financial year. Convert timestamps consistently.

What arrives is often not exactly the invoiced amount. Clients send a rounded figure, network fees are sometimes deducted, and the rate has moved between invoice and payment. That is normal. Your invoice stays leading; the difference is dealt with in step 6.

Step 4: valuing it in euro

This is the only step that is genuinely new compared with an ordinary payment. Your books and your return are in euro, so you have to convert the crypto you received into a euro amount. You do that at the rate at the moment of receipt, and you record which rate source you used.

That last part matters more than which source you pick. There is no single official rate for bitcoin or USDC; different exchanges and data providers report slightly different numbers for the same second. What you need is a defensible, consistent method: one source, one moment (the confirmation time of the transaction), and the same choice all year. Switching sources because one happens to give a nicer number is precisely what you should not do.

An example. You send an invoice for EUR 2,000 excluding VAT; with 21% VAT that is EUR 2,420 including. The client pays in USDC. At the moment of confirmation the rate is 1 EUR = 1.09 USDC, so the equivalent is 2,637.80 USDC. The client rounds down and sends 2,635 USDC. At the same rate that is EUR 2,417.43 — a shortfall of EUR 2.57.

Your revenue stays EUR 2,000 and your VAT stays EUR 420. Those follow from the invoice, not from what happened to land in your wallet. The EUR 2.57 difference is a payment difference you record separately. Bitcoin works identically, only the amounts are larger: an invoice of EUR 3,000 paid with 0.0342 BTC at a rate of EUR 87,700 per BTC comes to EUR 2,999.34.

Step 5: recording it in your books

Now that you have a euro amount, you can post it. In most accounting packages the clean solution is to treat your wallet as a separate payment account, next to your business bank account. You create a ledger account per coin or per wallet, and receipts land there.

You recognise revenue on the invoice date, not the payment date. That is the same logic as with an ordinary debtor: on the invoice date the receivable and the VAT liability arise, and the receipt in steps 3 and 4 clears that receivable. If you work on a cash basis, different moments apply — that depends on your situation and is something to settle with your accountant.

For the wallet itself you track how many units you hold and at what euro value they came in. You will need that historical value later, because as long as you hold the crypto the rate keeps moving. The moment you convert to euro or spend it, a difference arises between the value at receipt and the value at conversion. That difference is not revenue: it is an exchange result and belongs on its own ledger account. This is one reason why blockchain bookkeeping matters.

Take the bitcoin payment from step 4. You received 0.0342 BTC worth EUR 2,999.34. Two months later you convert at EUR 89,200 per BTC and receive EUR 3,050.64. The revenue was and remains EUR 3,000 per the invoice; the EUR 51.30 difference is posted as an exchange result. How such a result is treated for tax depends on whether the crypto forms part of your business assets and how your books are set up — settle that once with your accountant and then apply it consistently.

Step 6: reconciling against the invoice

Reconciliation is where most of the time goes and most of the errors come from. On one side you have a list of open invoices; on the other, a list of incoming transactions with no name attached. You have to tie the two together.

What makes it awkward is that the amounts rarely match exactly. Through rounding, network fees and rate movement, EUR 2.57 too little or EUR 4.10 too much arrives. One client pays two invoices in a single transaction; another pays in three instalments. Searching by amount then fails, and searching by name is impossible, because there is no name.

Two practical approaches keep this manageable. The first is to use a unique receiving address per client or per invoice; the address then identifies the payment and matching becomes trivial. The second is to work with a tolerance: anything landing within, say, half a percent of the invoice amount is matched to that invoice and the remainder is booked as a payment difference. Pick one tolerance and record why.

For the EUR 2.57 shortfall in our example you can leave it outstanding and remind the client, or write it off as a payment difference. For two euro the second is usually sensible, but write down what your rule is, so you do not end the year with twenty small residual items nobody can explain. Letting these pile up is one of the five biggest mistakes in crypto bookkeeping.

Step 7: the VAT return

Your VAT return does not change because you are paid in crypto. You declare revenue and VAT as they appear on your invoices, in euro. The standard rate in the Netherlands is 21%; which rate or scheme applies to you depends on what you supply and to whom.

Two points are worth making. First, VAT is due on the invoice amount, not on what arrived. If EUR 2,417.43 came in against an invoice of EUR 2,420, you still remit EUR 420 in VAT. The EUR 2.57 shortfall is a payment difference, not a discount on the VAT. If you want to treat it as a discount, that requires a credit note, and then the VAT changes too.

Second, you remit VAT in euro while your proceeds sit in crypto. On an invoice of EUR 2,420, EUR 420 is effectively the tax authority's money. Anyone who leaves it all in place and watches the rate fall can have a problem the following quarter. A simple habit helps: on every receipt, convert the VAT portion to euro straight away and park it in a separate account.

If you supply clients abroad, the ordinary rules on reverse charge and EU sales listings apply. Here too the payment method is irrelevant; the place of supply and your client's status determine everything. More detail in VAT on stablecoin payments.

Step 8: the year-end close

At year end your accountant wants one thing: an overview that ties back to your invoices. Concretely, that means a list of every incoming transaction with date, coin, units, rate used, euro value, transaction hash and the invoice it is matched to, plus a closing balance per wallet at 31 December.

That closing balance is one of the few genuine extras compared with ordinary bookkeeping. Per wallet you need how many units are held at 31 December and at what value they were received. On that basis your accountant determines the balance sheet position and whether there are unrealised exchange differences to deal with. How that works depends on your legal form and on whether the crypto is held as a business or private asset — a conversation with your adviser, not a do-it-yourself job. On the tax side, see tax on stablecoins in the Netherlands.

The usual retention obligations apply, including to the data your euro conversion rests on. A screenshot of a rate website from three years ago is not bookkeeping; a recorded rate source, timestamp and value per transaction is. Capture it at the time, not in January.

Do not schedule the close for March. In December, run through your open items, clear up payment differences, and check that every transaction hangs off an invoice and every invoice has been paid. What costs an hour in December costs a day in March.

The route in short

In summary: you agree which coin and which moment sets your rate, you send an ordinary euro invoice with a payment instruction, you record the transaction with hash and timestamp, you convert it at a fixed rate source, you post it through a wallet account, you match it to the right invoice, you declare VAT on the invoice amount, and you close the year with a complete transaction list and a wallet balance.

It is not difficult, but it is laborious, and it goes wrong the moment you let it pile up. Five transactions a month are ten minutes of work if you record them immediately and half a day of puzzling if you start in January. People who get stuck here rarely have a knowledge problem; they have a backlog problem.

stbl admin takes over steps 3 through 6: it watches your wallets, values every incoming transaction in euro against a fixed rate source, matches it to the right invoice, and produces an export at quarter or year end that your bookkeeper can use directly. You keep control of your own keys — stbl admin is non-custodial and never touches your money. The Pro plan is EUR 49 per month excluding VAT.