Crypto accounting for Zoho Books

CryptaCount is the live, two-way Zoho Books connector for crypto. It ingests your on-chain and exchange activity, calculates cost basis and gains, and posts clean period journals to Zoho Books — mapped to your chart of accounts — while the transaction-level detail stays in the sub-ledger. The sync runs both ways: it imports your chart of accounts from Zoho Books so mapping is automatic, and exports (posts) the reconciled journals back.

How it works

Zoho Books is your books; it isn't built to reconcile wallets and token cost basis across thousands of transactions. CryptaCount handles that and feeds Zoho Books clean entries:

1. Ingests every transaction from your exchanges and wallets,
2. Calculates cost basis and realized gains/losses (your choice of method) and applies your measurement policy,
3. Summarizes the activity into journals per period, and
4. Posts them to Zoho Books as journal entries, mapped to your chart of accounts.

Your GL stays clean; every line drills back to the underlying transactions in CryptaCount.

How to connect

In CryptaCount, go to Integrations → Zoho Books and authorize the connection (secure OAuth — you sign in to Zoho and approve access). Map your crypto accounts — digital assets, realized gain/loss, income (staking, mining, rewards), and fees — to your chart of accounts, set your posting frequency, and you're set.

What syncs

• Period journals (export) — summarized, double-entry journal entries posted to Zoho Books
• Chart of accounts (import) — pulled from Zoho Books so mapping stays aligned
• Drill-down — every posted line traces to transaction-level detail in the sub-ledger

Why finance teams use it

• Cost basis at scale — 12 disposal methods (FIFO, LIFO, HIFO, WAVG, Specific ID, and more) across exchanges and wallets; jurisdiction-mandated treatments (UK Section 104 pooling, Canada ACB) apply automatically
• Clean close — summarized journals instead of thousands of raw lines
• Audit-ready — a traceable trail from each journal line to the source transaction
• IFRS / US GAAP — measurement handled in the sub-ledger per your policy, entries posted to Zoho Books

Explore the engine: Crypto sub-ledger & cost basis → · Accounting for firms →

Why the sub-ledger posts summaries, not every transaction

Zoho Books is your general ledger — strong at invoicing, bills and bank reconciliation — but it was not built to hold tens of thousands of token movements, each with its own cost-basis lot. That is the job of CryptaCount, the crypto sub-ledger that sits in front of your GL. Instead of pushing raw transactions into Zoho Books, the connector posts summarized journal entries per period: the net effect of the period's activity on each account. A single active month can produce thousands of on-chain and exchange events, and posting each one individually would clutter the ledger, slow reports and obscure the handful of figures the financial statements actually need.

It is the same pattern teams already use for payroll or a payments processor: the operational system holds the line-by-line record, and only the summarized debits and credits reach the GL. CryptaCount aggregates each period into entries that move digital assets, realized gain/loss, income (staking, mining, rewards) and fees by their net amounts, with every posted line drilling back to the underlying transactions. You get a clean ledger and a complete, reconcilable record together. The crypto sub-ledger → page explains the engine behind the entries.

Mapping to your chart of accounts

Because the Zoho Books connector is two-way, it imports your chart of accounts so mapping follows your real account structure. You assign each kind of crypto activity to a specific Zoho Books account — holdings to asset accounts, disposals to realized gain/loss, staking and reward income to a revenue or other-income account, and network and exchange fees to expense accounts. Because you own the mapping, the entries match the structure your stakeholders and auditors expect instead of bending your books to fit the tool.

• Digital asset accounts — combined, or split by asset, venue or strategy
• Realized gain / loss — disposals measured under your chosen cost-basis method
• Income — staking, mining, rewards and airdrops recognized at value on receipt
• Fees — network (gas) and exchange fees, kept separate from trading results
• Revaluation / remeasurement — where your policy requires period-end adjustments

Mapping is configured once and reused every period, so the entries stay consistent close after close. Add a new exchange, wallet or token and it flows into the same account structure with no rebuild. See how the postings are built on the journal entries → page.

What the integration does and does not do

Keeping a clean boundary between the sub-ledger and Zoho Books is what makes both trustworthy, so the scope is worth stating plainly. The connector is a mapping and posting bridge — not a second set of books.

What it does: ingests activity from your exchanges and wallets, calculates cost basis and realized results under your policy, imports your chart of accounts from Zoho Books, summarizes each period into double-entry journal entries, and posts them to Zoho Books with drill-down back to the source transactions. What it does not do: it does not push raw lines into your ledger, does not disturb your invoicing or bank reconciliation, and does not make accounting-policy decisions for you. Measurement, classification and method selection stay under your control inside the sub-ledger; Zoho Books remains the system of record.

The close and reconciliation workflow

With the live Zoho Books connector, the close runs to a predictable rhythm. CryptaCount ingests the period's transactions from every connected exchange and wallet and flags whatever needs a human decision — an unknown counterparty, an unrecognized token, or a transfer that may be an internal move rather than a disposal. You resolve those exceptions, confirm on-chain balances reconcile to the sub-ledger, and review the cost-basis results before generating and posting the period entries.

Review at the Zoho Books end is quick because the entries are summarized: a few lines per account, each backed by a full transaction list you can open on demand. Self-transfers between your own wallets net to zero rather than creating phantom gains, balances reconcile to the chain before anything posts, and a closed period stays closed. The whole sequence repeats the same way each period, which is what makes a crypto close boring in the best sense.

Controls and the audit trail

Auditability is the whole reason for a sub-ledger. Every summarized entry in Zoho Books traces to the precise disposals, receipts and fees behind it, and each of those ties to a transaction hash or an exchange record. That unbroken chain — financial statement to journal to lot to transaction to blockchain — is what an auditor walks, and it is recorded as activity happens rather than reconstructed later. Cost-basis method, measurement policy and classification are applied consistently and retained so any figure can be reproduced. For how this supports your obligations, see crypto compliance reporting →.

Multi-entity and multi-currency considerations

If you run more than one Zoho Books organization, you keep a sub-ledger scope per entity and map each to its own chart of accounts, so intercompany crypto movements stay clean and consolidation is not distorted by mismatched bases or double-counted transfers. CryptaCount values transactions when they occur and can present results in your functional or presentation currency, so the entries posted to Zoho Books reflect the position you report rather than raw token quantities. Measurement under IFRS or US GAAP is applied in the sub-ledger per your policy — see IFRS crypto accounting →.

Common pitfalls this design avoids

• Raw transactions in the GL — clutters Zoho Books and makes reports unusable; the sub-ledger posts summaries instead
• Lost cost basis on transfers in — coins arriving from another platform with no basis distort every later gain; CryptaCount carries basis with the asset
• Self-transfers booked as sales — moving funds between your own wallets should never create a disposal or a phantom gain
• Inconsistent cost-basis methods — switching method mid-period produces results no one can reconcile; the engine applies your method consistently
• Spreadsheet closes — error-prone and unauditable; a reconciled sub-ledger replaces the spreadsheet
• Fees hidden in trade lines — network and exchange fees mixed into proceeds hide real costs; CryptaCount keeps them separate

How CryptaCount works with Zoho Books

CryptaCount handles the crypto-specific work — ingestion, cost basis, classification and reconciliation — and gives Zoho Books what a general ledger should receive: clean summarized journal entries mapped to your accounts. The connector is live and two-way, so it imports your chart of accounts to drive mapping and posts the reconciled entries back, with full drill-down behind every line. Zoho Books stays the system of record; the transaction detail stays where it can be reconciled and audited. The net effect is that your accountants work in the tools they already know, your crypto activity arrives as clean period entries they can review in minutes, and the underlying record is always one click away when a question comes up. Explore the crypto sub-ledger → and journal entries → to see how it fits together.

Will the connector change our Zoho Books invoicing or banking?

No. It only adds crypto journal entries to your ledger. Invoicing, bills, bank reconciliation and every other Zoho Books workflow continue exactly as before, with the crypto entries posted alongside them to the accounts you choose.

Do we choose which Zoho Books accounts receive the entries?

Yes. The two-way sync imports your chart of accounts, and you map each crypto event type — holdings, gains and losses, income, fees — to the specific account you want. Nothing posts to an account you have not nominated.

How often do entries post?

At the cadence of your close, typically monthly or quarterly. You set the posting frequency to match your accounting periods, so each period's crypto activity arrives as one summarized set of entries rather than a constant stream.

What if we restate a closed period?

Because every posted line traces to its source transactions, a restatement is transparent: you can see which transactions changed and review the revised summary before reposting. The sub-ledger retains the history, so prior-period adjustments stay auditable.

How are fees handled in the Zoho Books entries?

Fees are recognized separately from trading results so your real cost of activity is visible. Network (gas) fees and exchange fees are summarized and posted to the expense accounts you map them to, rather than being buried inside proceeds where they would distort both the gain on a disposal and your expense reporting. Keeping them in their own accounts also makes period-on-period fee analysis in Zoho Books straightforward, because the numbers are not tangled up with realized gains and losses.

Does the connector ever overwrite our Zoho Books data?

No. The import side only reads your chart of accounts to drive mapping; it does not change it. The export side adds new summarized journal entries each period and never edits your existing transactions, invoices or reconciliations. Zoho Books remains the system of record, and the connector contributes only the crypto entries you have configured, each one traceable back to the underlying activity and reversible if a period is revised.