Count mismatch, when our number differs from your source

This page is a stub. The full guide is written against the shipped app version and is on its way.

Your old tool or exchange says one transaction count, gains.tax shows another. Before assuming loss, know that the app printed the explanation at import time, and the causes come in five kinds, in the order worth checking.

One, rows versus tax events, the usual answer. Files count lines, the engine counts events that matter to tax. Transfers pair two rows into one linked move, money-only rows are set aside, swaps count both sides. The import report prints this as a literal equation, source rows in, tax events out, difference itemised, covered fully in the reconciliation count.

Two, refused rows, each shown with its reason. Rows the import could not honestly use, deleted inside the source app, bank money only, no sent or received amount, are listed at import with the reason per row, first rows open by default. Nothing was guessed at. Re-open Import and read the refusal list, the count difference is usually sitting right there.

Three, duplicates were caught. Overlapping exports deduplicate at preview, so two files describing the same trade become one row here while your source counted both, see duplicates.

Four, quarantined spam. Spam airdrop tokens moved to quarantine leave the counts and the computation entirely. Koinly and friends often keep counting them.

Five, a scan hit its page cap. Very deep on-chain histories read in passes, and the app says so when it happens, rescan to continue, already-held rows are skipped.

If the difference survives all five checks with your source’s count still higher, something real may be missing, go to missing acquisitions, and if it is lower here than it should be, check the refusal list again before anything else.