Sources: our own experience from over 500 crypto accounting cases. As of June 2026.
Key Takeaways
- ✓ Most report errors come from missing or incomplete data, not from a wrong calculation by the tool.
- ✓ API imports are often patchy (limited look-back, missing fiat movements, ID changes). A CSV reconciliation reveals the gaps.
- ✓ DeFi, bridges, pre-sales and wallet purchases are not reliably classified automatically by any tool. They need manual assignment with evidence.
- ✓ A manual edit without data evidence only moves an error instead of solving it.
- ✓ Missing fiat deposits and withdrawals are often irrelevant for the calculation, but decisive for the source-of-funds proof your bank asks for.
You generate your tax report and there's a gain that never happened. Or a dashboard deep in the red. Or a warning that reappears somewhere else after every fix. The first thought is almost always the same: the tool is making mistakes.
It usually isn't. Koinly, CoinTracking, Blockpit, Awaken, Summ and others import thousands of transactions automatically and calculate correctly. They simply can't reconstruct what was never documented cleanly: closed exchanges, forgotten wallets, DeFi across years, missing euro deposits.
The experience from over 500 crypto accounting cases shows an almost identical pattern: it's not a tool problem, it's a documentation problem. This article shows the ten most common errors: what you see, why it happens and how to fix it. Tool-agnostic, because they affect every tool.
01 Phantom gain: why does the report show a gain that never happened?
What you see: The report shows an enormous gain on one exchange that never existed in reality.
Why it happens: The exchange is connected via API but delivers wrong or negative balances. Over the API, data is missing: trades, deposits and withdrawals, or rewards from earlier years. A classic case is APIs that import only a limited period back, sometimes just a few months. Whoever traded there in 2023 and reconnects today is missing the old years entirely. Wrong balances on one coin trigger a warning on every trade with that coin, and those create the phantom gain.
How to fix it: Reconcile the exchange's CSV export against the API, add the missing periods, straighten out the balances. The phantom gain then disappears because the cost basis is correct again.
From practice: It's a topic in nearly every Data Check. Depending on the portfolio, the warnings grow very large because the trading volumes accumulate, sometimes higher than the portfolio itself. Mid five- to six-figure phantom gains in the report are often the reason clients come to us.
02 Dismissed warnings: why does the error reappear somewhere else?
What you see: An unlinked transaction throws a warning. It gets "solved" with a quick manual entry and reappears somewhere else.
Why it happens: Instead of researching where the transaction comes from, it's linked to some booking. Example: an old bitcoin deposit whose origin no one remembers is connected to a withdrawal from another exchange. The warning disappears. But the coins are now missing on the other exchange, a negative balance arises, and that throws the next warning. Every edit without data evidence only moves the error.
How to fix it: Work at the root: on-chain research, a conversation with the client, reviewing CSV data, evaluating screenshots and exchange emails to reconstruct the real history.
From practice: We see this regularly in accounts someone has worked on before, sometimes with bookings on exchanges the client wasn't even using at the time.
03 Wrong fiat balance: why is there a deep minus on the dashboard?
What you see: The dashboard shows a strongly negative euro amount, for example minus 150,000 €.
Why it happens: API and CSV often don't import the fiat deposits and withdrawals. The euro amounts you bought crypto with are then missing, and the dashboard slips into the minus. This usually has no effect on the calculation as long as a fiat currency is in the negative (a crypto balance in the negative, by contrast, creates real errors, see point 1).
Why it still matters: These very euro movements are the reconciliation with your bank account and the basis for the source-of-funds proof a bank wants to see. If this money flow is missing from the documentation, you'll later be missing the proof.
How to fix it: Add the fiat deposits and withdrawals and reconcile them with the bank account.
From practice: We add these euro deposits as part of the source-of-funds proof so they correspond with the bank statements. That's a double proof of completeness. In a recent case the data was no longer retrievable and had to be reconstructed from the account statements.
04 Card purchase (Moonpay & co.): why does the tool warn about the origin?
What you see: ETH or SOL simply appears in your wallet (e.g. Phantom). Buy with it, and a warning about unknown origin pops up.
Why it happens: When you buy directly into your wallet via a service like Moonpay, on the blockchain it's only a transfer from A to B. The tool doesn't recognise that a card purchase sits behind it. It looks as if you sent the coins from a wallet of your own. The origin isn't traceable.
How to fix it: Enter the tranche manually as a fiat purchase, with the corresponding euro payment before it. Note in the comment which card it was bought with.
From practice: Affects practically everyone who buys with fiat directly via the wallet (Phantom, Ledger and co.) through Moonpay and similar services.
05 DeFi misimported: why does the report invent rewards and gains?
What you see: Invented rewards, inflated gains, and bridge operations that show up as trades.
Why it happens: DeFi is complex, constantly changing, and exists across dozens of blockchains with different protocols. No tool maps this correctly on its own. Tools often recognise the individual movements of a DeFi transaction but don't classify them, importing them only as a deposit and a withdrawal. The rest you have to assign yourself. Typical errors:
- A liquidity-pool withdrawal is counted entirely as a reward. That creates gains that never flowed.
- A bridge swap (token A into blockchain X, token B out on blockchain Y) isn't recognised as a single operation.
- Some bridges have quirks: with deBridge, tools often book a trade against a small USDC tranche instead of the withdrawal. In the background, deBridge swaps into USDC, sends it to the other chain, and buys the target token there.
How to fix it: Manual classification per protocol, after an on-chain reconciliation.
From practice: deBridge has come up several times this year, for example on bridges from Solana to BNB Chain or to Ethereum.
06 Convert, card and P2P buys on exchanges: why are they booked as income?
What you see: Constant USDT "deposits", sometimes even booked as taxable income.
Why it happens: With savings plans or regular card purchases on some exchanges, the API doesn't read the operations correctly. The purchased currency simply appears as a deposit, for example as recurring USDT inflows. Only through follow-up questions and a CSV reconciliation does it become clear that these are euro converts into USDT, or card or P2P buys. Worse: some tools book such fiat purchases not as a deposit but as taxable income. You only find that when you look closely at the report.
How to fix it: Enter the tranche manually as a fiat purchase with the corresponding fiat payment, and note the background in the comment.
From practice: Common among savings-plan buyers. About one in five cases.
07 API re-import: why do duplicates suddenly appear?
What you see: Suddenly duplicates, doubled balances, and new warnings, even though everything was clean before.
Why it happens: Two causes. First: you imported via CSV and completed it manually, then reconnect the API without setting a start date. The API imports everything again, and duplicates arise. Second: exchanges change their internal IDs for trades and deposits/withdrawals. During the API sync, the tool reconciles these IDs; new IDs count as new transactions even though they were imported long ago. Duplicates again.
How to fix it: Before every re-import, save a snapshot and set a start date for the import.
From practice: Fairly often, especially with multi-year histories. Exchanges and their APIs have changed over the years.
08 Closed exchange: what to do when the history no longer exists?
What you see: Entire periods are missing.
Why it happens: Platforms were shut down and the history never or only partially saved. Examples are MtGox, Coinbase Pro, FTX, Bittrex, Bitpanda Pro, Bitvavo (before Bitvavo by Hyphe), Celsius, and others.
How to fix it: Reconstruction across several sources: support requests, on-chain analysis, reconciliation with corresponding exchanges and the client's wallets, old exports, screenshots, and exchange emails. More on this: reconstructing crypto history.
From practice: Most recently Coinbase Pro, before that Hotbit, for example. There we reconstructed roughly what was bought when from screenshots of the time, old balance screenshots, and on-chain research.
09 Missing wallet addresses: why don't the balances add up?
What you see: Activity is missing and balances don't add up because entire wallets are missing from the tool.
Why it happens: Anyone who experiments a lot (bridging, airdrop farming on smaller chains, testing DeFi protocols, privacy-conscious behaviour) often uses a new address for each new chain, each new protocol, or after a while. Over a crypto lifetime this quickly adds up to 20 to 40 addresses or far more. On top of that comes switching between cold wallets (Ledger, Trezor, Tangem) and hot wallets (MetaMask, Rabby). Anyone who doesn't document these addresses over the years forgets some, and their activity is missing from the tool.
How to fix it: On-chain analysis to find the missing addresses and their movements and close the gaps.
From practice: A classic case: someone took part in several ICOs and used a separate address for each, which fell into oblivion over the years.
10 IDOs, ICOs and pre-sales: why does the tool see only two transfers?
What you see: An ETH outflow to an unknown address, months later the inflow of a token unknown until then. To the tool, two unconnected transfers.
Why it happens: With IDOs, pre-sales and ICOs, the tool sees only the two transfers, not the connection. Linking them only works through on-chain research and the client's context. It gets more involved with vestings, when the token is unlocked in tranches over long periods.
How to fix it: Reconstruction via on-chain analysis and consultation with the client. The acquisition can be mapped cleanly through a dedicated pre-sale structure plus vesting.
From practice: Common with accounts that were already active in 2017 and 2021.
The Pattern Behind All Ten
Look at the ten points: almost none is a calculation error of the tool. They are missing data, unrecognised connections, and incomplete histories. A tool can only map what is cleanly documented. That's exactly where crypto accounting starts: bringing data together, reconciling, reconstructing, and substantiating it, so the report is correct and also holds up with the bank.
The Sequence:
Crypto Accounting
All exchanges, wallets, and DeFi activities cleanly brought together. The foundation for everything.
Tax Calculation
The tool calculates gains and losses based on the available documentation. The report is the result.
Compliance
Tax authority, bank, and DAC8 reconciliation build on the report. If the documentation is faulty, everything after it is faulty.
That's also why DAC8 makes things more serious. Regulated crypto service providers record the data from 2026, and the EU-wide exchange with the tax authorities starts in 2027. The tax authority then reconciles the reported values with your return, and even a discrepancy triggers an inquiry. A report built on incomplete data stands out more easily. The solution isn't the next tool, but complete documentation underneath.
Co-Founder & Documentation Specialist
Robert Thorn is Co-Founder of TX-Partner. Brings experience from over 500 documented crypto portfolios, from simple Bitcoin trading to six-figure DeFi setups across multiple chains and years. Closes the gap between raw data and clean documentation for tax and banks.
