Kraken crypto accounting

Connect Kraken to CryptaCount and turn your exchange activity into clean books. CryptaCount ingests every transaction, calculates cost basis, and posts journal entries to your ERP — with the detail held in the sub-ledger.

Kraken as a source for your sub-ledger

Kraken records your trades and ledger movements; CryptaCount turns them into accounting. It pulls your Kraken 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

1. Read-only API (recommended). In Kraken Pro, go to Settings → API → Create API Key and grant only these permissions: Query, Query Ledger Entries, and Export Data. In CryptaCount, go to Integrations → Kraken and paste it.
2. CSV import. Export your ledgers from Kraken as a CSV and upload it.

Those permissions are read-only — CryptaCount can see your history but can't trade or withdraw.

What flows into your books

Your Kraken trades, ledger entries (deposits and withdrawals), staking and rewards, and fees — each classified for accounting, with gains and income calculated and transfers matched.

Built for finance teams

• 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 Kraken transaction
• IFRS / US GAAP — measurement per your policy

See the sub-ledger → · Accounting for firms →

How CryptaCount ingests your Kraken activity into the sub-ledger

Kraken exposes both trades and a detailed ledger of every balance movement, and CryptaCount uses both. With your read-only key connected — Query, Query Ledger Entries and Export Data — CryptaCount pulls the trade and ledger history and keeps it current, writing each event as a discrete, timestamped record in the crypto sub-ledger. The ledger view is especially valuable for accounting because it captures the granular debits and credits behind every deposit, withdrawal, trade settlement and reward, which is exactly the level of detail reconciliation and cost basis depend on.

Ingestion is idempotent: each Kraken trade and ledger entry is keyed to its own identifiers, so re-syncing a period never double-counts. You can refresh after a close, after a corrected export, or after extending history, and trust that quantities and balances stay stable rather than drifting with each sync. The result is a dependable single source of truth for everything that happened on Kraken, ready to become accounting — with the GL receiving only summarised entries while the detail stays available underneath.

Classifying and reconciling Kraken transactions

CryptaCount classifies each Kraken record into an accounting event: a trade, a deposit or withdrawal from the ledger entries, a staking or reward receipt, or a fee. Because Kraken's ledger itemises the components of each movement, classification can be precise — a trade's asset leg, fiat leg and fee leg are each recognised for what they are, and a token-to-token trade is treated as a disposal and an acquisition priced independently rather than a single opaque swap.

Reconciliation then proves the books against the exchange. CryptaCount tracks the running quantity of each asset implied by your classified history and checks it against the position Kraken reports, so a gap in history, a missing ledger entry, or an unclassified line surfaces as a discrepancy rather than silently distorting balances. The reconciliation status flows through to your crypto sub-ledger → so reviewers can see exactly where the books and the venue agree — the same discipline an accountant brings to a bank reconciliation, applied to crypto.

Cost basis and gain/loss for the books

Every disposal on Kraken — a sale to fiat, a token-to-token trade, 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 gain or loss to the general ledger alongside the asset 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 specific acquisitions it consumed.

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 periods, not a per-transaction decision — see the available cost-basis methods → for how each one consumes lots and shapes reported results.

Transfers between your own accounts

Moving assets between Kraken and your other venues or wallets is routine, and each move is a chance to mis-book a disposal. When you withdraw an asset from Kraken to your own wallet, or deposit one in from elsewhere, nothing has been sold — the asset has only changed location — yet a naive import sees a withdrawal and a deposit and risks recognising a gain that never happened. 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 instead of resetting it or crystallising a phantom gain.

Matching uses asset, quantity, timing and direction, and flags anything it cannot confidently pair for human confirmation. That keeps you in control of the basis being carried — exactly what an auditor expects when an asset crosses between accounts. The carried basis follows the asset into whichever wallet or venue received it, so a later disposal there is measured against the true original cost rather than a reset figure.

Fees and internal movements

Kraken charges fees on trades and withdrawals, and because the ledger itemises them, CryptaCount can treat each fee precisely under your policy — capitalising a trading fee into an acquisition's basis, netting it against proceeds on a disposal, or booking it as an expense. Reported cost and gain therefore reflect what the activity actually cost. Per-transaction fees are easy to lose by hand but meaningful in aggregate; leaving them out understates cost and overstates gains across a period.

• Trading fees — capitalised into basis or netted against proceeds per your measurement policy, drawn from the itemised ledger.
• Withdrawal / network fees — captured against the movement so the asset reduction is fully accounted for.
• Staking and reward receipts — recognised at fair value on receipt and given a cost basis for the eventual disposal.
• Internal movements — paired across accounts and excluded from gain calculations, with basis carried forward intact.

Controls and audit trail

The Kraken connection is read-only by design — Query, Query Ledger Entries and Export Data give CryptaCount your history only, never trading or withdrawal access — a control you can evidence directly. Every general-ledger line is traceable: a posted journal entry drills back through the sub-ledger to the exact Kraken trade or ledger entry behind it, with its date, asset, quantity and the cost-basis lots consumed. That unbroken chain from GL to source event is what makes crypto books auditable, and it is generated through normal processing rather than reconstructed at year-end.

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

Firms and funds using Kraken often run multiple accounts across multiple legal entities. CryptaCount's workspace model keeps each entity's Kraken activity in its own books, with its own measurement policy and chart of accounts, while still allowing a consolidated view across the group. A fund administrator with several vehicles, an accounting firm with many clients, or a corporate treasury spanning subsidiaries can connect each account to the right workspace without data bleeding across boundaries.

This separation supports both accuracy and governance. Cost basis, transfer matching and gain calculation all operate within an entity's books, so a movement between two entities is treated as an intercompany transfer rather than netted away. Permissions and review can be scoped per workspace, supporting segregation of duties — the people who reconcile one entity need not be those who close another, which is exactly the control structure an auditor looks for.

Common pitfalls when accounting for Kraken activity

• Ignoring the ledger detail. Kraken's ledger itemises movements; reconciling only to trade summaries misses fee and settlement components that belong in the books.
• Treating token-to-token trades as non-events. Each is a disposal and an acquisition; ignoring it hides a realised gain or loss.
• Booking internal transfers as sales. Withdrawing to your own wallet is not a disposal — matching the legs preserves basis and prevents phantom gains.
• Dropping fees. Omitted trading and withdrawal fees overstate gains across a period.
• Hand-keying summaries into the GL. Manual entry breaks traceability to the source ledger entry and invites reconciliation gaps.

How CryptaCount uses your Kraken data

CryptaCount reads your Kraken trades and ledger entries through a read-only connection, classifies every trade, movement, reward and fee into accounting events, reconciles the resulting positions back to the exchange, calculates cost basis and realised gains under your policy, and posts summarised journal entries to your ERP — with the full ledger-level detail retained in the sub-ledger so every number is traceable to its source. It is the layer that turns a Kraken account into auditable books without touching your funds. To see how it would handle your Kraken setup, our team can walk through it with you.

Why does CryptaCount need the Query Ledger Entries permission?

Kraken's ledger entries record the granular debits and credits behind every deposit, withdrawal, trade settlement and reward. That detail is what reconciliation and cost basis rely on, so reading the ledger lets CryptaCount account precisely for each movement rather than inferring it from trade summaries alone. The permission is still read-only — it cannot trade or withdraw.

Can we import Kraken history by CSV instead of API?

Yes. You can export your ledgers from Kraken as a CSV and upload it, which is useful for historical periods or one-off backfills. Ingestion is idempotent, so importing a CSV that overlaps with API-synced data will not double-count the transactions that are already present.

How are Kraken staking rewards 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 measured against that basis, so the income event and the subsequent gain or loss remain distinct in the books rather than collapsed into a single figure.

Does the Kraken sub-ledger reconcile to our reported balances?

Yes. CryptaCount tracks the running quantity of each asset implied by your classified Kraken history and compares it to the position the exchange reports. Any mismatch surfaces as a discrepancy to investigate, so your sub-ledger is proven against the venue rather than assumed correct — the foundation of an auditable close.

Where Kraken fits in your monthly close

A connected exchange is only useful for accounting if it makes the close faster and more defensible, not just more visible. Because the Kraken connection is read-only and idempotent, the practical workflow is to keep the sub-ledger current through the month and treat period end as a verification step rather than a rebuild. You refresh after the last trading day, confirm the running quantities agree to what Kraken reports, review the classified trades and ledger entries, and approve the journals before they post. Nothing is reconstructed under deadline because the activity has been captured and reconciled as it happened — the close becomes a review, not an excavation, and a corrected export or a late entry can be re-synced without any risk of double-counting what is already booked.

A reliable Kraken close tends to hit the same checkpoints:

• Positions reconcile to the venue — the running quantity implied by the classified history agrees to what Kraken reports, with any gap surfaced as a discrepancy to investigate.
• Internal transfers are paired, so withdrawals to your own wallets carry basis across instead of crystallising a phantom gain.
• Fees are reflected per your policy, so cost is not understated and gains are not overstated across the period.
• Journals are reviewed before posting, so nothing reaches the general ledger unseen and every line traces back to its source ledger entry.

Handled this way, Kraken stops being a CSV to wrestle at month-end and becomes a reconciled source feeding clean books. CryptaCount holds the trade and ledger-level detail in the crypto sub-ledger, posts only summarised entries up to your ERP, and aligns measurement to the standard each entity reports under — the same records then feed your crypto compliance and reporting so the statements and the sub-ledger stay in step. For a firm running several Kraken accounts across entities, the same routine repeats per workspace without the books bleeding across boundaries, so each entity closes on its own terms and still rolls up into a consolidated view. The result is a Kraken close a reviewer can sign without reopening the exchange, because the evidence sits behind every posted figure and the books prove out against the venue every time, period after period.