Crypto Transaction Reconciliation for Audits

An auditor does not want your portfolio. They want to know that every movement into and out of it is accounted for, categorised, and traceable to a counterparty or a reason.

That is a different data problem from valuation, and it is usually the one that consumes the quarter.

Why raw transaction data is not a ledger

A transaction hash tells you that value moved. It does not tell you what happened in accounting terms.

The middle three are where naive tooling produces wrong answers. A tool that treats a deposit into Aave as a disposal manufactures a taxable event that did not occur. One that treats a bridge as a sale does the same thing, twice.

Labelling is the bottleneck

The hard part is not fetching transactions. It is assigning each one a meaning.

For a fund with a few hundred addresses across a dozen chains, this is tens of thousands of events per quarter, most of which are mechanically identical to each other and a minority of which are genuinely ambiguous.

The workable approach is to make the machine handle the mechanical majority and route the ambiguous minority to a human:

1. Classify automatically by protocol and method — a Uniswap swap is a swap.
2. Resolve internal transfers by knowing which addresses you control, so wallet-to-wallet movement is not booked as a disposal.
3. Flag the residue — transfers to unrecognised counterparties, unusual protocols, anything that does not match a known pattern.
4. Record the decision so the same counterparty is not re-adjudicated next quarter.

Step two is worth dwelling on. Most of the false disposals in crypto accounting come from treating your own address book as external. An address book that the reconciliation process actually reads eliminates that class of error entirely.

Pulling the data

/v1/transactions returns labelled history filterable by chain, type, protocol and date range, across 53 transaction types:

curl -s https://api.octav.fi/v1/transactions \
  -H "Authorization: Bearer $OCTAV_API_KEY" \
  -G \
  --data-urlencode "addresses=0xYourAddress" \
  --data-urlencode "dateRange=2026-04-01,2026-06-30" \
  --data-urlencode "limit=500"

Two operational notes. The first sync of a busy address costs one credit per 250 transactions on top of the call, so budget before looping over a full address book. And addresses above roughly 100k transactions need support to index — worth discovering in advance of a reporting deadline rather than during one. See the endpoint reference.

What auditors ask for

In rough order of how often it derails a close:

• Completeness. Every address in scope, with evidence the list is complete.
• Consistent valuation. One price source and timestamp convention, applied uniformly. Not a mix of venues chosen per asset.
• Reproducibility. The same query run in six months returns the same answer — which is what snapshots provide and recomputation does not.
• Traceability. Each ledger line links back to a transaction hash.
• Treatment of DeFi positions. How lending, LP and staking positions are classified, and whether that treatment is consistent.

The last one connects reconciliation back to valuation: if your portfolio data misses a sector entirely, the reconciliation cannot surface transactions that were never enumerated. See Why Portfolio APIs Disagree About Net Worth and What Is NAV Reporting for Crypto Funds?.

This article describes data engineering practice, not tax advice. Treatment of crypto transactions varies by jurisdiction and by fund structure — confirm classification with your accountant before relying on it.