Ledger crypto accounting

Connect Ledger to CryptaCount with your public addresses or a Ledger Live CSV and turn cold-wallet activity into clean books. CryptaCount reads your history, calculates cost basis, and posts journal entries to your ERP — with the detail held in the sub-ledger.

Your hardware wallet as a source for the sub-ledger

Treasury held on a Ledger is invisible to your accounting system until someone reconciles it by hand. CryptaCount reads that activity into a crypto sub-ledger, applies cost basis and your measurement policy, and produces summarized journal entries for your general ledger.

How to connect

Ledger is a hardware wallet, so there's no API key — you connect by public address or CSV (a read-only, watch-only view):

1. Public addresses. For each chain your Ledger holds (Bitcoin, Ethereum, and others), copy the public address (or extended public key, where used) from Ledger Live. In CryptaCount, go to Integrations → Add wallet → Ledger and paste it.
2. Ledger Live CSV. In Ledger Live, export your operation history as a CSV and upload it — one file covering all accounts.

Never enter your 24-word recovery phrase. CryptaCount only needs your public addresses or a CSV — both watch-only and read-only. Your recovery phrase stays on your device.

What flows into your books

On-chain activity across the chains and accounts Ledger manages: buys and sells, transfers, swaps, staking and rewards, and fees — each classified for accounting, with transfers between your own wallets matched.

Built for finance teams

• Multi-chain treasury — one set of books across every chain, via our on-chain data infrastructure
• Automated cost basis — 12 disposal methods (FIFO, LIFO, HIFO, WAVG, Specific ID, and more); jurisdiction-mandated treatments (UK Section 104 pooling, Canada ACB) apply automatically
• Journal entries to your ERP — QuickBooks, Xero, NetSuite, or Sage → ERP integrations →
• Audit-ready — every GL line drills back to the on-chain transaction

See the sub-ledger → · Accounting for firms →

How CryptaCount ingests your Ledger activity into the sub-ledger

A Ledger hardware wallet is connected by its public addresses — one per chain it holds — or by a Ledger Live CSV, both watch-only views that let CryptaCount read history without any ability to sign or move funds. From those addresses CryptaCount reads on-chain activity across every chain the device manages and writes each transaction as a discrete, timestamped record in the crypto sub-ledger: the buy, the sell, the transfer, the swap, the staking reward, the fee. Your general ledger receives only summarised journal entries, while the full detail stays underneath for reconciliation, cost basis and audit.

Cold-storage treasury is exactly the activity that tends to be invisible to an accounting system until someone reconciles it by hand, often months late. CryptaCount makes it continuously visible and idempotent to re-read — each transaction is keyed to its chain identifiers, so refreshing a wallet, adding a chain, or extending history never double-counts. The sub-ledger becomes a dependable single source of truth for what the hardware wallet holds and how it got there, ready to be turned into accounting.

Classifying and reconciling on-chain transactions

CryptaCount classifies each transaction the Ledger's addresses produced into an accounting event your books can use — a buy or sell, a transfer in or out, a swap (a disposal of one asset and an acquisition of another, priced independently), a staking or reward receipt, or a fee. A swap is recognised as the two-sided event it is, so the realised gain embedded in it is captured rather than hidden, and a deposit or withdrawal is distinguished from a genuine disposal so basis is treated correctly.

Reconciliation proves the books against the chain. CryptaCount tracks the running balance of each asset implied by your classified history and compares it to the on-chain balance of the address, so a missing transaction, an unconnected chain, or an unclassified interaction surfaces as a discrepancy rather than quietly distorting positions. The chain is the authority for what the wallet holds, and the sub-ledger should reconcile to it — that status flows through to your crypto sub-ledger → for reviewers to inspect.

Cost basis and gain/loss for the books

Every disposal from the Ledger — a sale, a swap into another asset, or a transfer your policy treats as a disposal — needs a cost basis so the realised gain or loss can be measured and posted. CryptaCount maintains acquisition lots per asset and consumes them on disposal under your chosen method, then books the gain or loss to the general ledger alongside the on-chain movement. The lots live in the sub-ledger, so the posted figure is never a black box: you can drill from a gain on the GL back to the acquisitions it consumed — including assets bought on an exchange and later moved into cold storage.

The engine supports the full range of disposal strategies a finance team may be required to use and applies jurisdiction-mandated treatments automatically where they apply. The method is a deliberate policy choice applied consistently across every chain the device holds, not a per-transaction decision — see the available cost-basis methods → for how each one consumes lots.

Transfers between your own accounts

A hardware wallet is usually the destination or origin of internal movements — assets are moved from an exchange into cold storage for safekeeping, or out of cold storage to transact — and each move can be mistaken for a disposal. Nothing has been sold when an asset merely changes location within the organisation, yet a naive import sees a withdrawal on one side and a deposit on the other and risks booking a phantom gain. CryptaCount matches the two legs of an internal transfer into a single movement of the same asset, carrying the original cost basis across the move so it is neither reset nor crystallised.

Matching considers asset, quantity, timing and direction across all of your connected accounts, and flags anything it cannot confidently pair for human confirmation. That keeps you in control of the basis being carried, which is exactly what an auditor expects when assets move into or out of cold storage. The carried basis follows the asset into whichever account received it, so a later disposal is still measured against the true original cost rather than a reset figure.

Fees and internal movements

On-chain activity from a Ledger incurs network fees, and those fees are part of the economics of the transactions they pay for. CryptaCount captures each fee and treats it per your policy — adding the fee on an acquisition to that asset's cost basis, netting it against proceeds on a disposal, or booking it as an expense — so reported cost and gain reflect the true cost of moving and transacting. Network fees are easy to overlook one at a time but meaningful in aggregate, and leaving them out understates cost and overstates gains.

• Network fees — capitalised into basis, netted against proceeds, or expensed per your measurement policy.
• Staking and reward receipts — recognised at fair value on receipt and given a cost basis for the eventual disposal.
• Swaps — recognised as a disposal and an acquisition, each priced independently, so embedded gains are captured.
• Internal movements — paired across accounts and excluded from gain calculations, with basis carried forward intact.

Controls and audit trail

The defining control of a hardware wallet is that the keys never leave the device — and CryptaCount reinforces it by only ever holding public addresses or a CSV export, both watch-only and read-only. CryptaCount never asks for your 24-word recovery phrase, and the connection physically cannot sign or move funds, which is straightforward to evidence to an auditor. Every general-ledger line is then traceable back through the sub-ledger to the exact on-chain transaction behind it, with its hash, date, asset, quantity and the cost-basis lots consumed — and because the chain is public and immutable, that reference is strong evidence.

Summarised entries keep your ERP clean while the on-chain detail stays in the sub-ledger, and the same data feeds your crypto compliance reporting → so statements and sub-ledger stay aligned. The journals — debits, credits and account mappings — are reviewable before posting via journal entries →, so nothing reaches the GL unseen.

Multi-entity and treasury considerations

Organisations that hold treasury on Ledger devices frequently run several devices, many addresses across many chains, and more than one legal entity. CryptaCount's workspace model lets you assign each entity's wallets to its own set of books, with its own measurement policy and chart of accounts, while still consolidating across the group when needed. A fund custodying assets in cold storage, a firm managing client treasuries, or a corporate group spanning subsidiaries can keep each entity's holdings cleanly separated rather than commingled.

That separation underpins accuracy and governance. Cost basis, transfer matching and gain calculation run within an entity's books, so a movement between two entities' wallets is treated as an intercompany transfer rather than netted away. Permissions and review can be scoped per workspace, supporting the segregation of duties an auditor expects — particularly important where a single device may hold significant value across multiple chains.

Common pitfalls when accounting for Ledger activity

• Missing a chain or address. A Ledger can hold many chains; an unconnected address leaves a gap that breaks transfer matching and balances.
• Booking moves into or out of cold storage as sales. Transferring to or from your Ledger is not a disposal — matching the legs preserves basis and prevents phantom gains.
• Treating swaps as non-events. A swap is a disposal and an acquisition; ignoring it hides a realised gain or loss.
• Ignoring network fees. Fees are part of transaction cost; omitting them understates cost and overstates gains.
• Reconciling cold storage only at year-end by hand. Late, manual reconciliation invites errors; a continuously read, watch-only feed keeps the books current.

How CryptaCount uses your Ledger data

CryptaCount reads your Ledger public addresses, or a Ledger Live CSV, as a watch-only source, ingests on-chain activity across every chain the device holds, classifies buys, sells, transfers, swaps, staking and fees into accounting events, reconciles balances against the chain, calculates cost basis and realised gains under your policy, and posts summarised journal entries to your ERP — with the full detail retained in the sub-ledger so every number is traceable to its source. It never holds your recovery phrase and never moves funds. To see how it would handle your cold-storage treasury, our team can walk through your setup.

Should we add public addresses or import a Ledger Live CSV?

Either works. Adding the public address per chain gives a continuously updated, watch-only feed that stays current as the wallet transacts, which suits an ongoing treasury. A Ledger Live CSV export covering all accounts is convenient for a one-off backfill or historical period. Because ingestion is idempotent, you can use both without double-counting overlapping transactions.

How does CryptaCount account for assets moved from an exchange into Ledger cold storage?

When both the exchange account and the Ledger address are connected, CryptaCount pairs the withdrawal and the deposit as a single internal movement and carries the original cost basis across into cold storage. No gain is recognised on the move itself; the basis simply follows the asset, so a later disposal from the Ledger is measured against the true original cost.

Does connecting our Ledger expose any signing risk?

No. CryptaCount only ever holds public addresses or a CSV — both watch-only and read-only — and never asks for the 24-word recovery phrase. The recovery phrase stays on your device, and there is no path by which a connected address could sign or authorise a transaction. The access is observation only.

How are staking rewards on a Ledger treated in the books?

Staking and reward receipts are recognised as income at fair value on the date received, and that value becomes the cost basis of the received asset. A later disposal is then measured against that basis, keeping the income event and the subsequent gain or loss distinct in the books rather than collapsed into a single number.