This guide explains the thinking behind Summ's advanced reconciliation engine: what problem it solves, how it fills gaps in your data, and why turning it on from a date creates an adjustment. It assumes no prior knowledge of crypto tax. If you just want to switch the engine on or off, see Advanced reconciliation engine: how to turn it on or off.
First, what is a tax record?
When you buy crypto, Summ remembers that purchase as a tax record, sometimes called a lot: "You bought 1 ETH on 5 January for $1,000." Every purchase creates one. When you later sell, Summ picks a record to match against the sale, and the difference between what you paid and what you sold for is your capital gain, the part you pay tax on.
The purchase price on a record is its cost basis. If you bought the same asset several times, your inventory method decides which record a sale uses, for example the oldest first.
The problem: sales with nothing to match
In a perfect world every sale has a matching purchase. Real data is messier:
You imported Coinbase but forgot the exchange where you first bought the coins.
A transfer arrived on-chain from a wallet Summ has never seen, so nobody knows what you paid for it.
Your only transaction for an asset is a sale, and the purchase happened somewhere that is not connected.
When Summ cannot find a purchase to match a sale, it does not know the cost basis. Every reconciliation engine has to decide what to do at that moment. The two engines make different choices.
How the standard engine handles it
The standard engine keeps three separate running totals for each asset: the balance in each account, an overall tax-engine balance, and the tax records themselves. Each follows its own rules, so they can quietly disagree.
Incoming transactions did not always create a record. If 5 ETH arrived from an unknown source, your Coinbase balance went up by 5, but no record was created because the cost was unknown. When you later sold, a zero-cost buy appeared at the moment of the sale, disconnected from the incoming transaction that caused it.
Outgoing transactions could push a balance below zero. Selling coins Summ had no record of simply produced a negative balance, which is where most Missing Purchase History warnings came from.
Uncategorised transactions were set aside. An incoming or outgoing transaction you had not categorised was treated as an unmatched transfer and left out of the calculation until you dealt with it.
The rule the advanced engine adds
The advanced engine introduces one strict rule: your tax records, your tax-engine balance, and your account balances must always agree. For every asset, at every moment, the three totals are one number. Whenever the data would break that rule, the engine fills the gap on the spot and marks the transaction that caused it, so you can fix the right thing.
Here is how each of the old problems is handled.
Incoming transactions always create a record
When 5 ETH arrives from an unknown source, the engine creates a tax record for it immediately. Because it does not know what you paid, the record gets an assumed cost basis, which is zero by default. That is deliberately the worst case for your tax: if you sell those coins, the whole sale price counts as gain. It is a nudge to go back and categorise the incoming transaction, for example as a transfer from your own wallet or a purchase at a known price.
The important difference is timing. The record is created when the coins arrive and is tied to that transaction, which carries an Assumed cost basis warning. When you see a large gain later, you can trace it straight back to the incoming transaction and fix it there.
Balances are never allowed below zero
The engine watches every account balance. If a sale, send, or other outgoing transaction is about to take a balance below zero, it steps in first and creates an assumed-cost record for exactly the missing amount. Say your only transaction is "Sold 5 BTC on Coinbase". The balance would go from 0 to −5. Instead the engine adds a 5 BTC record at $0 just before the sale, the balance goes 0 → 5 → 0, and the sale has something to match against.
The transaction that would have gone negative is flagged with an Assumed cost basis warning. Summ also keeps track of what the balance would have been without the assumed records, so you can still see where your data has gaps.
Transfers are checked both ways
When you move coins between your own accounts, Summ processes a send and a receive. The advanced engine treats a matched pair as one movement, so the records that leave one account are the ones that arrive in the other. A send or receive with no partner is treated as a complete movement on its own rather than waiting for a match that may never come.
If the two sides do not agree on the amount, the engine resolves the difference:
Sent more than received (a network fee, for example): the missing amount is treated as a disposal, valued at the moment you sent it.
Received more than sent: the extra amount gets an assumed-cost record at the destination.
Uncategorised transactions count
An uncategorised incoming transaction is treated as an acquisition with an assumed cost basis, and an uncategorised outgoing transaction reduces your balance as a non-taxable disposal. Nothing sits outside the calculation. The uncategorised transaction toggles in your tax settings still let you change this treatment.
What you see
Transactions that caused an assumed-cost record carry an Assumed cost basis warning. The Transactions page can be filtered by it.
A sale that used an assumed record shows as two parts: one against your real record, one against the assumed record with its $0 cost.
Fix the source, by importing the missing account, categorising the incoming transaction, or adding the missing history, and the assumed record is replaced with the real cost on the next recalculation. The warning disappears with it.
Why turning it on from a date creates an adjustment
New accounts start on the advanced engine, so the rule holds from the first transaction. An existing account has history that was processed under the standard engine's rules, where the three totals were allowed to drift apart.
When you turn the engine on from a chosen date, everything before that date stays exactly as it was, and Summ marks the boundary with an unlocked period ending the day before. At the boundary, the engine compares your tax records with what you actually held at that moment. Where they differ, it brings them into line: missing amounts get assumed-cost records, surplus records are removed. Balances that were changed show a Migration adjustment marker. From that day on, the one-number rule applies.
Locked periods are respected throughout. A period you have filed against is never recalculated, so the engine can only start after your latest locked period ends. If you choose From the beginning instead, there is no boundary and no adjustment: the whole history is recalculated under the new rule, and every gap shows up as an Assumed cost basis warning on the transaction that caused it.
For what an adjustment means for your account, see Understanding the balance adjustment in Summ.
Glossary
Cost basis: what you originally paid for an asset, needed to work out the gain.
Tax record (lot): Summ's record of one acquisition: quantity, cost basis, date, and account.
Capital gain: sale price minus cost basis.
Inventory method: the rule that decides which record a sale uses, such as first in, first out.
Assumed cost basis: the cost the engine gives a record it had to create without purchase history, zero by default. A zero-cost buy is the same thing seen from the sale side.
Missing purchase history: the warning you see when an account's balance would be negative without assumed records.
Boundary period: the unlocked period Summ creates when you turn the engine on from a date. It ends the day before the engine starts.
Migration adjustment: the correction applied at the boundary so records match holdings.
Frequently asked questions
Why is the gain on one sale so much higher than I expected?
The sale probably used a record with an assumed cost basis of $0, so the whole sale price counted as gain. Look for the Assumed cost basis warning on the transaction that created the record and fix it there.
Why does one sale show two disposals?
Your real records only covered part of it. The sale was split: one part against the coins Summ knew about, and one part against an assumed-cost record for the shortfall.
Why is a transaction flagged that I did not change?
It is the transaction that would have pushed a balance below zero. The engine flags the point where the gap became visible, which is usually the best clue to what is missing before it.
Do assumed-cost records change what I own?
No. They exist only in your tax records so the calculation can continue. Your actual holdings are unchanged, and Summ still tracks the balance without them.
Does fixing the source really remove the record?
Yes. Once the incoming transaction is categorised, or the missing history is imported, the next recalculation replaces the assumed record with the real cost and clears the warning.
Are airdrops and other deliberately zero-cost categories flagged?
No. A categorised airdrop has a zero cost basis on purpose and is not treated as a gap.
Is an assumed cost basis always zero?
By default, yes. Zero is the conservative choice and the one Summ applies unless your account has been set up differently.
If you have any questions, reach out to our Support Team via the in-app chat. 😇