The reconciliation count, rows against tax events

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

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. This page explains why those numbers differ and why showing the difference is the point.

Rows are what a file contains, tax events are what tax law sees. A source file counts lines. The engine counts things that matter to a UK tax computation. The two differ for honest reasons:

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.

Why this is on screen at all. 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, so a mismatch is a visible line you can click, not a mystery. If the numbers still look wrong after reading the breakdown, count mismatch walks through the cases that deserve a second look.