What does needs_review mean in a crypto tax classification?
It is a first-class classification outcome, not an error. needs_review means the evidence did not support a single defensible tax treatment, so no treatment is asserted: the record carries needs_review: true with taxable returned as null, and it routes to a human rather than into the books. Under the CryptoTaxEdge Classification Standard a null taxable always travels with needs_review: true, and a consumer must never coerce that null to false.
Key takeaways
- needs_review is a first-class outcome: taxable is null if and only if needs_review is true, and a consumer must never coerce that null to false.
- A flagged row costs a reviewer minutes; a confident, unflagged, wrong row is the expensive error class, and by the published definition a flagged row cannot be a silent wrong.
- The record arrives with the evidence attached: the legs, the protocol identification, and the review note.
The invariant: null is not false
null and false are two different claims. false is a positive finding that no recognition event occurred. null says taxability was not asserted at all. Coerce one into the other and an open question quietly becomes an unbooked taxable event that nothing later asks anyone to check, which is why the Standard fixes the pairing as a contract rather than a convention: taxable is null if and only if needs_review is true.
It is also worth separating two things that both look like something went wrong. A batch item carrying an error is a failed request: no classification was produced. A needs_review record is a completed classification whose answer is that the evidence does not settle the treatment. One is a retry; the other is a work item.
Why a transaction lands in review
Ambiguous protocol shape. The economic event does not resolve to one category. A nested aggregator route, a bundled multicall, or an unidentified contract can produce legs that are honestly consistent with more than one shape, and picking one of them is a guess presented as a finding.
Conflicting signals across independent sources. Several sources parse the same receipt and describe the movement differently. When independent reads fail to corroborate each other, the honest output is the conflict itself, not a majority vote served as a verdict.
A grey area where the house default should not be applied silently. Some positions are genuinely contested, and the engine carries a documented default for each. Where the specific facts of a row make that default the wrong thing to apply without anyone seeing it, the row surfaces instead of inheriting it.
Unmatched transfers
The most common review-shaped row in any crypto tax tool, whatever the tool calls it, is the unmatched transfer: an asset left one place or arrived somewhere, and the software could not prove the other side belongs to the same taxpayer. The stakes are concrete. Matched, the move is non-taxable and basis carries over. Unmatched, the same rows quietly become something else: the outbound leg a disposition to a stranger, the inbound leg income or a zero-basis acquisition. The honest handling is to name what is known and flag what is not: the engine names the counterparty on plain transfer rows, documents the limit that the transfer category alone does not prove the counterparty was verified (GAP-1 in the Standard), and routes to review the shapes where asserting either reading would be a guess. Resolving one is ordinary work -- confirm both addresses are the client's, record it, and the whole chain of that asset's basis stays intact.
Review loops in crypto tax software
A different failure mode is the row that keeps coming back: cleared in one session, flagged again after the next sync. Loops usually have a mechanical cause. A re-import re-derives the book and drops manual edits that were never recorded as durable decisions. An integration re-decodes the same transaction differently after an update. Or the underlying question was never actually decided, just dismissed, so every fresh look re-asks it. The way out is to make the decision once, at the transaction level, and write it down: classify the raw hash, record the chosen treatment and its basis, and apply that decision to every matching row so a future sync has something to defer to. A review queue should shrink because questions get answered, not because they get suppressed.
What a practitioner does with one
Treat it as a queue item, not a dead end. The record arrives with the evidence attached: the receipt-derived legs (what left the wallet, what arrived, and gas), the protocol identification where one was made, and the review note where one applies. The reviewer picks the treatment, records the basis for it, and applies the same decision to every matching row in the book rather than case by case. That written decision is what survives a later question about the return. A default applied silently leaves nothing to point at.
Why abstaining beats a confident guess
In a filing context the two failure modes do not cost the same. A flagged row costs a reviewer a few minutes. A confident, unflagged, wrong row can cost an amended return, and it is the error class least likely to be caught, because nothing about it asks to be checked. Our published benchmark work uses the same definition: a silent wrong is a confident, unflagged, wrong answer, so a flagged row cannot be one. Deferring is designed behavior of a conforming implementation, not a failure state.
Frequently asked questions
Is needs_review an error?
No. An error is a failed request: no classification was produced, and the fix is a retry. A needs_review record is a completed classification whose honest answer is that the evidence does not settle the treatment, and the fix is a human decision. One is infrastructure; the other is a work item.
What should I do with a flagged transaction?
Treat it as a queue item. The record carries the receipt-derived legs, the protocol identification where one was made, and the review note. The reviewer picks the treatment, records the basis for it, and applies the same decision to every matching row in the book. That written decision is what survives a later question about the return.
Why not just serve the most likely treatment?
Because the failure modes are not priced the same. A flagged row costs minutes of review. A confident, unflagged, wrong row can cost an amended return, and it is the error class least likely to be caught because nothing about it asks to be checked. Deferring on thin evidence is designed behavior, not a failure state.
Accounting firm with crypto clients? See the Firm plan.
This is informational only, not tax advice; verify with a qualified tax professional before filing.