Crypto accounting for Sage Intacct

CryptaCount is the crypto sub-ledger for Sage. A direct Sage Intacct (coming soon) integration is on the roadmap: it will ingest your on-chain and exchange activity, calculate cost basis and gains, and post clean period journal entries to Sage Intacct — mapped to your chart of accounts and dimensions — while the transaction-level detail stays in the sub-ledger.

The Sage Intacct connector is coming soon. Today you can run the full crypto sub-ledger in CryptaCount and export journal entries for import into Sage.

How it will work

Sage is your GL; it isn't built to reconcile wallets and token cost basis across thousands of transactions. CryptaCount will handle that and feed Sage clean entries:

1. Ingest every transaction from your exchanges and wallets,
2. Calculate cost basis and realized gains/losses (your choice of method) and apply your measurement policy,
3. Summarize the activity into journal entries per period, and
4. Post them to Sage Intacct, mapped to your chart of accounts.

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

How it will connect

In CryptaCount, you will go to Integrations → Sage and connect to Sage Intacct via its API (web-services credentials — no stored user password). You will map your crypto GL accounts — digital assets, realized gain/loss, income (staking, mining, rewards), and fees — to your chart of accounts, assign dimensions (entity, department, location) where you use them, and set your posting frequency.

On Sage 50 or Sage 200? You'll export journal entries from CryptaCount for import.

Available today: export for Sage

Until the direct connection ships, you can run the full sub-ledger in CryptaCount and export summarized journal entries to import into Sage — the same double-entry, period-level postings, mapped to digital assets, realized gain/loss, income, and fees.

What will sync

• Period journal entries — summarized, double-entry
• Chart of accounts + dimensions — mapped and kept aligned
• Multi-entity — entries routed by entity dimension
• Drill-down — every posted line traces to transaction-level detail in the sub-ledger

Why finance teams use CryptaCount

• 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
• Dimension-aware — posts aligned to your Sage Intacct dimensional structure
• Clean close — summarized entries, not raw transactions, in the GL
• Audit-ready — a traceable trail from each GL line to the source transaction
• IFRS / US GAAP — measurement handled in the sub-ledger per your policy

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

Why the sub-ledger posts summaries, not every transaction

Sage Intacct is your general ledger — built for dimensional reporting and multi-entity finance — but it was not designed to reconcile wallets and token cost basis across thousands of on-chain events. That is the job of CryptaCount, the crypto sub-ledger that sits in front of your GL. When the connector is live it will post summarized journal entries per period rather than a line for every transfer, swap, fee and reward. A busy month can generate thousands of events, and pushing each into Sage would bloat the ledger, slow reporting and bury the net figures the financial statements actually need — without adding any accounting value, because the GL only requires the effect on each account and dimension.

It is the same model finance teams already rely on for payroll or a high-volume billing system: the operational engine keeps the line-by-line record, and only 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. The ledger stays clean and the detail stays reconcilable. The crypto sub-ledger → page describes the engine behind the entries.

Mapping to your chart of accounts and dimensions

Sage Intacct's strength is its dimensional model, and the connector is designed to respect it. Before anything posts, you map each kind of crypto activity to a specific GL 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 — and assign the dimensions you use, such as entity, department and location. That way the crypto postings slot into the same dimensional structure as the rest of your reporting, rather than sitting in an undifferentiated lump that breaks your analytics.

• 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
• Dimensions — entity, department, location and others, aligned to your Sage Intacct structure

Mapping is set once and reused every period, so the entries stay consistent close after close and dimension-aligned every time. Add an exchange, wallet or token and it flows into the same structure with no rebuild. See how postings are assembled on the journal entries → page.

What the integration will and will not do

A clean boundary between the sub-ledger and Sage Intacct 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 will do: ingest activity from your exchanges and wallets, calculate cost basis and realized results under your policy, summarize each period into double-entry journal entries, map them to your chart of accounts and dimensions, and post them to Sage Intacct with drill-down back to the source transactions. What it will not do: it will not push raw transactions into your ledger, will not disturb your existing financial workflows, and will not make accounting-policy decisions for you. Measurement, classification and method selection stay under your control inside the sub-ledger; Sage Intacct remains the system of record. On Sage 50 or Sage 200 you will export journal entries from CryptaCount for import.

The close and reconciliation workflow

The close with crypto follows a repeatable sequence once the sub-ledger is in place. CryptaCount ingests each period's transactions across every connected exchange and wallet and flags whatever needs a 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 the period entries and posting them with their dimensions attached.

Review at the Sage end is quick because the entries are summarized and dimension-aligned: a few lines per account and dimension, 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 closed periods stay closed. The same controlled process repeats every period.

Controls and the audit trail

Auditability is the core reason to run a sub-ledger. Every summarized line posted to Sage Intacct will trace to the exact disposals, receipts and fees behind it, and each of those ties to a transaction hash or an exchange record — financial statement to journal to lot to transaction to blockchain, with dimensions intact. That chain is recorded as activity happens rather than reconstructed at year-end. Cost-basis method, measurement policy and classification are applied consistently and retained, so any figure can be reproduced for a reviewer. For how this supports your obligations, see crypto compliance reporting →.

Multi-entity and multi-currency considerations

Sage Intacct's multi-entity and dimensional model fits the sub-ledger well. CryptaCount keeps a sub-ledger scope per entity and posts entries routed by your entity dimension, so intercompany crypto movements stay clean and consolidation is not distorted by mismatched bases or double-counted transfers. Transactions are valued when they occur and can be presented in your functional or presentation currency, so the entries reaching Sage reflect the reportable position 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 Sage and slows reporting; the sub-ledger posts dimension-aligned 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
• Postings with no dimensions — crypto activity that ignores your dimensional structure breaks your analytics; entries carry the right dimensions
• 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

How CryptaCount will work with Sage Intacct

CryptaCount will do the crypto-specific work — ingestion, cost basis, classification and reconciliation — and hand Sage Intacct what a general ledger should receive: clean summarized journal entries mapped to your accounts and dimensions. Today you can run the full sub-ledger and export those entries for import into Sage; when the direct connector ships it will post them for you, with drill-down behind every line. Sage stays the system of record; the transaction detail stays where it can be reconciled and audited. Explore the crypto sub-ledger → and journal entries → to see the engine in detail.

Will the entries carry our Sage Intacct dimensions?

Yes. You assign the dimensions you use — entity, department, location and others — to the mapped entries, so the crypto postings report through the same dimensional structure as the rest of your finances rather than sitting outside it.

Which Sage product does the direct connector target?

The planned direct connection is for Sage Intacct via its API. If you run Sage 50 or Sage 200, you will export summarized journal entries from CryptaCount and import them, getting the same period-level, double-entry postings.

How will it authenticate to Sage Intacct?

Through Sage Intacct's web-services credentials — the API-level access designed for integrations — so no individual user password is stored. The connector posts entries within the scope you grant it.

Does it disturb our existing Sage workflows?

No. The connector only adds crypto journal entries to your GL. Your existing accounts payable, receivable, reporting and dimensional workflows continue exactly as before, with the crypto entries posted alongside them to the accounts and dimensions you choose.

How are fees and income kept separate in the Sage entries?

Income is recognized at value on receipt and fees are kept separate from trading results, each mapped to its own accounts and dimensions. Staking, mining and reward income posts to the revenue or other-income accounts you nominate, while network and exchange fees go to expense accounts rather than being netted into proceeds where they would distort both the gain on a disposal and your fee reporting. Because the entries carry your dimensions, you can still analyze crypto income and costs by entity, department or location in Sage Intacct.

Can we run the sub-ledger before the direct connector ships?

Yes. You can run the full crypto sub-ledger today — ingestion, cost basis, classification and reconciliation — and export summarized journal entries for import into Sage. The accounting result is the same period-level, double-entry posting mapped to your accounts and dimensions; the direct connector simply automates the posting step when it is available, so there is no need to wait to get your crypto books reconciled and audit-ready.