Fireblocks crypto accounting

Fireblocks crypto accounting turns institutional custody activity into auditable books. Fireblocks is an MPC custody and treasury platform — assets sit in secure vaults, move between them and out to counterparties, and earn or deploy into DeFi — and all of that has to reach the general ledger correctly. CryptaCount ingests Fireblocks activity into a crypto sub-ledger, reconciles it to the platform, and posts summarised journal entries to your GL, built for treasuries, funds and the firms that serve them.

Fireblocks as a source for your sub-ledger

Fireblocks is where institutional assets are custodied and moved; CryptaCount is where that activity becomes accounting. It pulls vault transfers, disposals, staking and DeFi activity into a crypto sub-ledger, applies your measurement policy, and produces summarised journal entries for your general ledger with full detail behind every line.

How to connect

1. Read-only API (recommended). In Fireblocks, create an API key with read-only permission only — leave trading and withdrawals unchecked. In CryptaCount, go to Integrations → Fireblocks and paste it.
2. CSV import. Export your transaction history from Fireblocks and upload it.

A read-only key lets CryptaCount read your history for the books but never move funds — a control you can evidence directly to an auditor.

What flows into your books

A Fireblocks workspace records several kinds of treasury activity, and each books differently. Sorting the history into these buckets is most of the accounting work:

Vault-to-vault and internal transfers

Moving assets between your own Fireblocks vaults, or to your own external wallets, is a transfer, not a disposal — matched across legs rather than booked as a sale.

Disposals and conversions

Selling or converting an asset held in Fireblocks is a disposal with a gain or loss, measured against its cost basis.

Staking and rewards

Assets staked from Fireblocks earn rewards that are recognised as income at fair value on receipt, then carried forward as basis.

DeFi and on-chain activity

Where treasury assets are deployed into DeFi, each interaction can create a disposal or income depending on what it does.

Counterparty settlements

Transfers to and from counterparties are payments or receipts, classified for the books rather than mistaken for trades.

Built for finance teams

• Built for treasury scale — vault movements, settlements and on-chain activity run high; the sub-ledger ingests them and posts summarised entries
• 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 Fireblocks transaction behind it
• IFRS / US GAAP — measurement applied in the sub-ledger per your policy

See the sub-ledger → · Accounting for firms →

Accounting for an MPC custody platform

Fireblocks secures assets with MPC and organises them into vaults, and most of what happens on the platform is movement — between vaults, to and from external wallets, and out to counterparties — rather than trading. The accounting challenge is to tell those movements apart: an internal transfer between your own vaults is not a disposal and must never create a gain, while a transfer out to a counterparty in settlement of an obligation is a real economic event that books differently. CryptaCount classifies each Fireblocks movement by what it actually is and maps it to the right accounts, so the security model does not turn into an accounting fog.

Because everything Fireblocks does is recorded and addressable, the sub-ledger can reconstruct the full treasury history and reconcile it against the platform, so a missing settlement or an unclassified movement surfaces as a discrepancy rather than quietly distorting balances. Cost basis follows assets across vault moves and external transfers, so a later disposal is measured against what was actually paid, even after the asset has moved several times within the custody setup.

Treasury movements, staking and DeFi

Institutional treasuries do more than hold: they stake for yield, deploy into DeFi, and settle with counterparties. Each is a distinct accounting event — staking rewards are income at fair value on receipt; DeFi interactions can be disposals or income depending on what they do; settlements are payments or receipts. CryptaCount reads each from the Fireblocks record and the chain, classifies it, and posts it to the right account, so a sophisticated treasury operation produces books that an auditor can walk line by line rather than a balance that hides the activity behind it.

How CryptaCount ingests Fireblocks activity into the sub-ledger

Once your read-only key is connected, CryptaCount pulls your Fireblocks history and keeps it current, writing each event as a discrete, timestamped record in the crypto sub-ledger. The general ledger only ever sees summarised journal entries, but the underlying detail is preserved in full so reconciliations, gain calculations and audit queries always have something concrete to stand on.

Ingestion is idempotent: each Fireblocks event is keyed to its own identifiers, so re-syncing a period never duplicates an entry. That matters because you will refresh the data repeatedly — after a close, after a corrected export, after adding history — and balances must stay stable across every refresh rather than inflating each time. The sub-ledger becomes a dependable single source of truth for everything that happened on Fireblocks, ready to be turned into accounting at scale.

Classifying and reconciling Fireblocks transactions

CryptaCount turns raw Fireblocks data into accounting events by classifying each record: an internal vault transfer, a disposal or conversion with its realised result, a staking reward, a DeFi interaction, or a counterparty settlement. Each maps to the right accounts — digital assets, realised gain/loss, income and fees — so secure custody movements become clean journal entries rather than an opaque log of vault activity.

Reconciliation proves the books against the exchange. CryptaCount tracks the running balance implied by your classified history and compares it to the position Fireblocks reports, so a gap in history or an unclassified line surfaces as a discrepancy instead of quietly distorting balances. Any break between the sub-ledger and the venue is explainable and visible in your crypto sub-ledger → — the same control discipline an accountant applies to a bank reconciliation.

Cost basis and gain/loss for the books

Every disposal on Fireblocks — a sale, a conversion into another asset, or a withdrawal 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 resulting gain or loss to the general ledger alongside the asset movement.

Because the lots live in the sub-ledger, the posted figure is never opaque: you can drill from a gain on the GL back to the specific acquisitions it consumed, even across thousands of trades. See the available cost-basis methods → for how each consumes lots and shapes your reported results.

Transfers between your own accounts

Finance teams frequently move assets between Fireblocks and other venues or wallets, and every one of those movements is a chance to mis-book a disposal. When you move an asset out of Fireblocks into your own wallet, or in from another account, nothing has been sold — yet a naive import sees a withdrawal and a deposit and risks recognising a gain that never occurred. CryptaCount matches the two legs into a single movement of the same asset, carrying the original cost basis across the move instead of resetting it.

Matching considers asset, quantity, timing and direction, and flags anything it cannot confidently pair for human confirmation rather than guessing — exactly what an auditor wants to see when an asset crosses between accounts.

Fees and internal movements

Fireblocks charges fees on its activity, and in aggregate those fees are a material part of the economics. CryptaCount captures each fee and treats it per your policy — adding a trading fee to an acquisition's cost basis, netting it against proceeds on a disposal, or booking it as an expense — so reported cost and gain reflect what activity actually cost.

• Network / gas fees — captured against the movement so the asset reduction is fully accounted for.
• Staking rewards — recognised at fair value on receipt and given a cost basis for the later disposal.
• Counterparty settlements — classified as payments or receipts per your policy, not netted into trading results.
• Internal vault movements — paired across your own vaults and wallets and excluded from gain calculations.

Controls and the audit trail

The Fireblocks connection is read-only — transaction history only, never trading or withdrawal access — a control you can evidence directly to an auditor or board. Every general-ledger line CryptaCount produces is traceable: a posted journal entry drills back through the sub-ledger to the exact Fireblocks event behind it, with its date, asset, quantity and the figures that produced it. That unbroken chain from GL to source is what makes high-volume crypto books auditable, produced as a by-product of normal processing rather than reconstructed under deadline pressure at close.

Summarised entries keep your ERP clean while the transaction-level evidence stays in the sub-ledger, and the same data feeds your crypto compliance reporting → so statements and sub-ledger never diverge. The journals — debits, credits and account mappings — are reviewable before they reach the GL via journal entries →, so nothing is posted blind.

Multi-entity and treasury considerations

Organisations operating on Fireblocks at scale rarely run through a single account or a single legal entity. CryptaCount's workspace model keeps each entity's Fireblocks activity in its own books, with its own measurement policy and chart of accounts, while still reporting across the group when needed — a fund running several strategies, a firm serving multiple clients, or a treasury spanning subsidiaries.

That separation underpins both accuracy and governance. Cost basis, transfer matching and gain calculation all run within an entity's books, so a movement between two entities is treated as the intercompany transfer it is, not netted away. Review and permissions are scoped per workspace, supporting the segregation of duties auditors expect.

Common pitfalls when accounting for Fireblocks activity

• Booking vault-to-vault moves as sales — internal transfers between your own vaults are not disposals.
• Confusing internal transfers with counterparty settlements — they book to different accounts.
• Missing staking and DeFi income — treasury yield is income at receipt and easy to overlook.
• Losing basis across vault moves — cost basis must follow the asset through every movement.
• Hand-keying treasury summaries into the GL — manual entry breaks the trail back to the Fireblocks record.

How CryptaCount uses your Fireblocks data

CryptaCount reads your Fireblocks activity through a read-only connection, classifies every vault transfer, disposal, staking reward, DeFi interaction and counterparty settlement into accounting events, matches internal movements, reconciles back to the platform, calculates results under your policy, and posts summarised journal entries to your ERP — with full detail retained in the sub-ledger so every figure is traceable to its source. It turns an institutional custody operation into auditable books without ever touching your funds.