# Crypto Transaction Reconciliation for Audits

> Turning raw on-chain activity into an auditable ledger. Why transaction labelling is the bottleneck, and what an accountant actually needs from the data.

- **URL:** https://octav.fi/blog/crypto-transaction-reconciliation
- **Published:** 2026-03-23
- **Author:** Octav Team — Portfolio Intelligence for Digital Assets
- **Topic:** Tax & Compliance
- **Tags:** reconciliation, audit, compliance
- **Source:** Octav, Practical guides on crypto NAV reporting, multi-chain portfolio management and digital asset APIs, from the team behind Octav.

---
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.

| On-chain event | What the ledger needs to say |
| --- | --- |
| Transfer out to an unknown address | Payment, transfer between own wallets, or disposal? |
| Swap | Disposal of asset A and acquisition of asset B, with cost basis |
| Deposit to a lending protocol | Not a disposal — still your asset |
| Claim of rewards | Income, at the value on the claim date |
| Bridge | Not a disposal — the same asset on a different chain |

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:

```bash
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](/crypto-portfolio-api-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](/daily-crypto-portfolio-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](/why-portfolio-apis-disagree) and
[What Is NAV Reporting for Crypto Funds?](/what-is-crypto-nav-reporting).

> 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.