Per-wallet balancing, the check that catches overstated tax

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

One assertion runs continuously under your workspace, for every asset in every wallet, the running unit balance never goes negative. Buys, income, forks and transfers-in add units, sells, spends, gifts, losses and transfers-out subtract them, a trade subtracts one asset and adds the counter asset, and a both-sided transfer moves units between the two named wallets. A wallet cannot send what it never received.

When the check fails, a red marker appears on the asset row with one expandable warning per wallet, and the confidence score takes its heaviest deduction, 20 points, the same weight as missing cost basis. A negative balance means the history at that wallet is incomplete or mislabelled, a receipt is missing, or a transfer names the wrong wallets.

Why you should care, in one sentence. Units the engine never saw arrive carry no cost, so when they are sold the entire proceeds read as gain, and your tax is overstated. This check exists to catch that inflation before you trust a report, it protects you, not HMRC.

The subtlety worth understanding. The tax computation itself follows HMRC’s rule and pools each asset per owner, across all your wallets, the section 104 pool does not care where you kept the coins. Balancing is per wallet because that is where bookkeeping errors show. The two views agreeing, wallets that balance and pools that compute, is what reconciliation means here.

Housekeeping notes, quarantined spam tokens sit outside balancing entirely, and a row with no asset or quantity cannot move a balance. If a marker is standing, missing acquisitions walks through the usual causes and fixes.