Bitfinex crypto accounting
Bitfinex crypto accounting has a recognition question most exchanges don't raise: funding income. Bitfinex's funding market lets you lend crypto or dollars to margin traders and earn interest — income that must be recognised at receipt, not buried in trades — alongside margin results and derivatives. CryptaCount ingests it all into a crypto sub-ledger, recognises the income correctly, reconciles to the venue, and posts summarised journal entries to your general ledger, built for finance teams, funds and treasuries.

Bitfinex as a source for your sub-ledger
Bitfinex is built for active traders, with spot, margin, a funding (lending) market and derivatives; CryptaCount is where all of it becomes accounting. It pulls each 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
- Read-only API (recommended). In Bitfinex, create an API key with read-only permission only — leave trading and withdrawals unchecked. In CryptaCount, go to Integrations → Bitfinex and paste it.
- CSV import. Export your transaction history from Bitfinex 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 Bitfinex account mixes spot, margin, funding and derivatives, and each books differently. Sorting the history into these buckets is most of the work:
Spot trades
Each spot disposal carries a cost basis and posts to realised gain/loss.
Margin trades
Margin positions post a realised gain or loss when closed, with financing costs attached — separate from plain spot trades.
Funding (lending) income
Interest earned lending into the funding market is recognised as income at receipt — a stream of small receipts and Bitfinex's most distinctive accounting item.
Derivatives
Closed perpetual positions post realised PnL, with funding booked as cost or income, in their own ledger.
Transfers
Movements of your own assets are matched across legs rather than booked as disposals.
Built for finance teams
- Income-aware — funding interest, margin results and derivatives PnL all post correctly; the sub-ledger ingests them and reconciles to the venue
- 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 Bitfinex transaction behind it
- IFRS / US GAAP — measurement applied in the sub-ledger per your policy
See the sub-ledger → · Accounting for firms →
Recognising funding (lending) income in the books
Bitfinex's funding market is what sets its accounting apart. When you place crypto or dollars into the funding book, you are lending to margin traders and receiving interest in return — and in the books that interest is income recognised at the time you receive it, not a capital gain and not a trade. It arrives as a stream of many small receipts, which is exactly why a trades-only import misses it: there is no buy or sell to hang it on, yet leaving it out understates income and distorts the account's results.
CryptaCount reads the funding ledger explicitly, recognises each interest receipt as income at fair value on the date received, and posts it to the income account you map — separate from any trading or capital activity. That distinction matters for the financial statements and for an auditor: lending income and trading gains are different things, recognised on different bases, and the books should show them as such rather than netting one into the other.
Margin and derivatives
Bitfinex's margin trading is the other side of the funding book: positions opened with borrowed funds realise a gain or loss when closed, and the financing cost attaches to that activity rather than to ordinary spot trades. Its derivatives post realised PnL and funding in their own ledger. CryptaCount keeps margin results, derivative PnL and spot disposals in separate lanes within the sub-ledger, each mapped to the right accounts and each drilling back to the position that produced it — so a busy Bitfinex account reconciles cleanly and the financing costs sit where they belong.
How CryptaCount ingests Bitfinex activity into the sub-ledger
Once your read-only key is connected, CryptaCount pulls your Bitfinex 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 Bitfinex 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 Bitfinex, ready to be turned into accounting at scale.
Classifying and reconciling Bitfinex transactions
CryptaCount turns raw Bitfinex data into accounting events by classifying each record: a spot trade; a margin open or close with its result and financing cost; a funding (lending) receipt recognised as interest income; a derivatives position with its realised PnL; or a transfer. Each maps to the right accounts — realised gain/loss, interest income, derivative PnL, financing cost and fees — so income is booked as income and disposals as disposals, not conflated.
Reconciliation proves the books against the exchange. CryptaCount tracks the running balance implied by your classified history and compares it to the position Bitfinex 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 Bitfinex — 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 Bitfinex 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 Bitfinex 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
Bitfinex 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.
- Trading and financing fees — capitalised, netted or expensed per your measurement policy; margin financing attaches to the position.
- Funding (lending) interest — recognised as income at receipt, on its own line rather than buried in a trade.
- Derivatives funding — recorded as cost or income on perpetuals, kept distinct from trading fees.
- Internal movements — paired across your own accounts and excluded from gain calculations, with basis carried forward intact.
Controls and the audit trail
The Bitfinex 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 Bitfinex 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 Bitfinex at scale rarely run through a single account or a single legal entity. CryptaCount's workspace model keeps each entity's Bitfinex 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 Bitfinex activity
- Treating funding interest as a trade or a gain. It is interest income recognised at receipt and belongs on its own line.
- Mixing margin results into spot. Keep the ledgers distinct so financing costs attach to the right activity.
- Skipping the derivatives ledger. Perpetual PnL and funding are separate again from margin and spot.
- Omitting small funding receipts. They arrive as a stream and add up; a trades-only view misses them.
- Hand-keying summaries into the GL. Manual entry breaks the trail back to the Bitfinex event behind each figure.
How CryptaCount uses your Bitfinex data
CryptaCount reads your Bitfinex history through a read-only connection, classifies every spot trade, margin position, funding (lending) receipt, derivative position and transfer into accounting events, recognises interest income at receipt, keeps margin and derivatives in their own lanes, reconciles back to the venue, and posts summarised journal entries to your ERP — with full detail retained in the sub-ledger so every figure is traceable to its source.
FAQ
As interest income at fair value on the date each receipt arrives — on its own line, not a capital gain or a trade. CryptaCount reads the funding ledger explicitly and posts the income to the account you map, separate from trading activity.
Margin positions post a realised gain or loss when closed, with the financing cost attached to that activity rather than to ordinary spot trades. CryptaCount keeps margin results in their own lane, distinct from spot and derivatives.
Yes. Interest income, margin and derivative results, and spot disposals are each classified and mapped to the right accounts, so income is booked as income and capital activity as capital activity rather than netted together.
Yes. A read-only API key gives transaction history only — never trading or withdrawals. You can also import by CSV. The read-only scope is a control you can show an auditor.
Yes. CryptaCount posts summarised journal entries to QuickBooks, Xero, NetSuite or Sage, with the full transaction-level detail retained in the sub-ledger behind every line.
Yes. The sub-ledger ingests high transaction counts and the workspace model keeps each legal entity's books separate, so you can reconcile and post per entity and still report across the group.