The reconciliation count, rows against tax events

Checked against app build 2026-08-26-01-41 on 2026-08-26.

Every import ends with a line like this one, read 16 of 17 rows, 17 rows become 16 tax events, and then the arithmetic, item by item.

Why does my import show fewer tax events than rows?

Because rows are what a file contains and tax events are what tax law sees, and the two differ for honest reasons.

A source file counts lines. The engine counts things that matter to a UK tax computation. Three cases account for almost every difference you will meet.

A transfer between your own wallets is often two rows in an export, the leaving row and the arriving row, but it is one movement of your own property and no disposal at all. The engine links the pair and holds it as one linked event, fee-aware, so the satoshis lost to the network fee are accounted rather than vanished.

A money-only row, a bank deposit, a standalone fee in pounds, is a row with no cryptoasset movement. It is set aside and shown as set aside, not guessed into a trade.

A crypto-to-crypto swap is one row in most exports but two things to tax law, a disposal of one asset and an acquisition of another. The engine treats it as both, which is how the 30-day rule catches traders who never noticed they triggered it, see the UK rules.

Why is the arithmetic on screen at all?

So that a mismatch is a visible line you can click rather than a mystery you have to accept.

Most tools swallow these differences and present a total. When your total and their total disagree, you have nothing to inspect. Here the count is reconciled in front of you at import time, before anything is added.

What if the numbers still look wrong?

Read the breakdown first, then work through the five known causes in order.

Count mismatch walks through the cases that deserve a second look, refused rows, deduplication, quarantined spam and scan page caps among them. If the shortfall is real acquisitions rather than counting, missing acquisitions is the page you want.