Overview · Methods · Exports · Events · Records · Help
When the report is incorrect
A report that is simply incorrect — the total disagrees with your exchange, or with your own expectation — is almost never a calculation bug. Read the direction of the error before auditing anything; it points at the cause far faster than checking everything.
| Symptom | Most likely cause | Check this first |
|---|---|---|
| Reported gain too high | Internal transfers counted as sales | Withdrawal rows appearing without matching deposits |
| Reported gain too low | Income events missing from the records | Staking and airdrop activity the venue never reported |
| Total slightly off, by a small amount | Rounding accumulated across partial sales | Whether partial lot splits were rounded each time |
| Basis for a token is wrong, gain looks right | Fee handling | Whether fees were added to basis and to proceeds consistently |
| A whole year or venue is missing | Incomplete or truncated export | The earliest date in the file against the venue's history |
| Numbers change when you re-run | Live price used for a past event | Whether historical values are pinned to the event date |
Transfers counted as disposals
By far the most common cause of an overstated gain, and easy to confirm.
Open both exports — the source venue and the destination — and look for a withdrawal row with no matching deposit. Every such pair is an internal movement that has been treated as a sale followed by a purchase.
The effect is twofold: a disposal that never happened, and a fresh basis that is too high, which suppresses future gains and makes the portfolio harder to reason about long after the original error.
Missing income
The opposite case. Income the venues did not report leaves reported gains understated.
Compare the token quantities you held over the period against what your records say you acquired. If you hold more than the trades and income explain, something arrived that nobody logged — usually auto-compounding staking rewards, an airdrop, or tokens from a bridge.
Work backwards from the balance rather than forwards from the transactions. The difference is exactly the income you are missing.
Fees on the wrong side
A fee paid on a buy belongs in the basis of the lot. A fee paid on a sell reduces proceeds. Applying both to the same side produces a small but systematic error.
It often presents in a confusing way: the total gain looks nearly right, while the basis of the remaining position is wrong. That matters more than it appears, because the wrong basis carries forward into every later disposal.
Also check fees paid in a third asset. A fee denominated in a different token has to be converted, and venues are inconsistent about whether the amount shown is before or after that conversion.
Rounding drift
Selling half a lot leaves half a lot. If each partial sale is rounded to a fixed number of decimal places independently, the fragments do not reassemble exactly.
Over hundreds of trades the total can drift by a small percentage, which is usually dismissed as a rounding artefact. It is more likely that somewhere a basis is being truncated rather than the arithmetic being imprecise.
Compare a single token's total basis against what the exchange itself reports for that position. They should match to the last decimal, and if they do not, the drift is in the calculation rather than in the display.
Live prices used on past events
If re-running the same data produces different numbers, something is being priced at the current moment rather than at the event date.
This usually affects income events, where the value at receipt has to come from a historical source rather than a live feed. A calculation that looks up today's price is producing a correct answer to a different question.
A debugging order
- Confirm the exports are complete Earliest and latest dates, and row counts against the venue's own history. Everything else depends on this.
- Reconcile token balances Compare final holdings against trades plus income. The difference is missing income, and it is usually the whole problem.
- Match transfers in both directions Pair withdrawals with deposits. Every unmatched row is a phantom disposal.
- Check one token end to end Pick a single token and trace every lot by hand. The first divergence you find is almost certainly representative.
- Only then re-run Fixing inputs before re-running saves a great deal of wasted effort.
When the numbers are right but the position is not
Sometimes the calculation is fine and the expectation is wrong.
A portfolio down 40 percent shows no tax loss, because the loss is unrealised. A large gain recorded this year may have produced a taxable amount you did not expect if a method you cannot use in your jurisdiction was applied by default. And a fee deducted from proceeds is still income to the venue.
Before treating a mismatch as an error, confirm the rule being applied is the rule you actually intended to use.
If the inputs are gone, say so early. A professional can often work around a missing export with alternative evidence. What they cannot do is reconstruct a specific price at a specific moment that nobody captured.