Crypto Accounting Sage Intacct Integration: The Multi-Entity Pattern

What makes a crypto integration into Sage Intacct distinct from any other ERP is Intacct's multi-entity architecture and its dimension model. Intacct is built for groups that run several legal entities on one instance, each with its own currency, and it tags transactions with dimensions (entity, department, location, class) rather than overloading the account code. A crypto subledger has to respect both: it posts journals to Intacct's REST API (the modern interface, alongside the legacy SOAP/XML web services) and carries an entity dimension that maps to Intacct's entity structure, so an intercompany transfer of crypto between two group entities is not booked as an external disposal and consolidation does not double-count. Get the entity dimension wrong and the multi-entity books are wrong; everything else follows the universal subledger pattern. The accounting is an auditor judgement.

In short

• Sage Intacct has no native crypto; it is a multi-entity cloud GL, and crypto integrates via the universal subledger pattern.
• The subledger connects wallets and exchanges, applies cost basis and classification against the chart of accounts, and posts summary journals into Intacct's GL.
• Intacct exposes a documented REST API alongside legacy SOAP/XML web services; the subledger posts programmatically or by file import. Configure against the current Intacct docs.
• The distinctive part is multi-entity: carry an entity dimension mapped to Intacct's entities so an intercompany transfer is not an external disposal and consolidation does not double-count (see multi-entity crypto CoA).
• Post summarised journals; the subledger keeps the transaction detail for audit.
• Export is not final; classification stays an auditor judgement. Not accounting advice.

No native crypto

Sage Intacct is a multi-entity cloud accounting and ERP platform with no native wallet, blockchain, or token concept. Crypto integrates via the standard subledger pattern: an external crypto subledger connects to the wallets and exchanges, applies cost basis and classification, and posts summary journal entries into Intacct's GL. Intacct stays the system of record; the accounting is an auditor judgement.

How the subledger posts

Intacct exposes a documented REST API, alongside the older SOAP/XML web services, that a subledger uses to create journal entries programmatically; entries can also be delivered by file import where that fits. The interface and field mapping should be configured against Intacct's current API documentation, since the two interfaces coexist with different auth models (legacy session-based for SOAP, OAuth 2.0 for REST). The mechanism is delivery; it does not change the underlying accounting.

The multi-entity angle

Intacct is commonly used by groups running several entities on one instance, and crypto held across those entities raises intercompany and consolidation questions: an intercompany transfer must not post as an external disposal, and consolidation must not double-count. The subledger should carry an entity dimension mapped to Intacct's entity structure so the per-entity books and the consolidation are both correct (see multi-entity crypto chart of accounts and internal transfer vs disposal). The treatment is an auditor judgement.

Journal granularity

Generally summarised journals — periodic, per entity, for holdings, realized and unrealized results, income, and fees — rather than raw transactions, which keeps the Intacct ledger manageable while the subledger retains the transaction detail for audit. The granularity is a design choice set with the accountant and Intacct administrator.

Export is plumbing

The integration delivers correctly structured journals; it does not validate classification, cost basis, or fair value, which remain accounting judgements subject to review and audit. Intacct's reporting and controls then operate on those journals like any other. The accounting correctness is established separately and confirmed with the auditor.

Practical guidance

1. Use the subledger pattern; Intacct has no native crypto.
2. Configure the interface (REST or the legacy SOAP/XML) or file import against current Intacct docs.
3. Map an entity dimension to Intacct's entities to protect intercompany and consolidation.
4. Post summarised journals and keep the transaction detail in the subledger.
5. Treat the export as plumbing; classification correctness is a separate question.
6. Confirm the posting design with your auditor and Intacct administrator. Capabilities change, and this is not accounting advice.

Evaluating a tool for Sage Intacct

Vendors such as Cryptio and Bitwave offer Sage Intacct integrations that post summary journals to the GL. The differentiators for Intacct specifically are the dimension model and multi-entity handling, so before committing, confirm the tool:

• posts through Intacct's current interface (the REST API or the SOAP/XML web services) rather than a generic file that drops Intacct's required fields;
• writes the entity dimension on every journal so each entry lands on the correct entity, not the top-level consolidation entity;
• routes intra-group transfers to intercompany accounts instead of generating a realized gain or loss;
• maps to your own chart of accounts, with separate realized and unrealized accounts.

The tool delivers the journals; the classification and the multi-entity treatment are auditor judgements.

Where Wag3s fits

Wag3s Ledger maps wallet and exchange activity to a configurable chart of accounts with an entity dimension and posts summarised journals to Sage Intacct by its API or file import, retaining the transaction detail for audit. The classification, the multi-entity treatment, and the accounting correctness are established separately and confirmed with the auditor. See the Ledger product page.

Step-by-step: configuring a crypto subledger for Sage Intacct

The following sequence describes the typical setup, in order, for a multi-entity group using Sage Intacct as its system of record.

Step 1 — Map your Intacct entity structure. In Intacct, each legal entity is a separate company entity in the multi-entity framework. Export the list of entity IDs and their currency assignments. The subledger must carry a matching entity dimension so every journal is posted to the correct entity, not to the top-level consolidation entity.

Step 2 — Confirm your Intacct chart of accounts. Identify the accounts that will receive crypto journals: typically one or more digital-asset asset accounts (per token class), a realised-gain/loss account, an unrealised-gain/loss account, a fee/expense account, and potentially a staking-income account. If these do not exist in Intacct, create them before configuring the subledger mapping. The CoA design is auditor-confirmed and covered in the crypto chart of accounts design guide.

Step 3 — Choose the interface method. Sage Intacct supports API-based posting (REST or SOAP/XML) and CSV file import via the Intacct import framework. For automated recurring closes, the REST/API path is preferable because it creates journals programmatically with a verifiable audit trail. For smaller volumes or one-off migrations, a CSV import can be sufficient. Confirm the current endpoint and authentication method with Intacct's current developer documentation — the SOAP API and REST API coexist but have different auth models (legacy SID-based vs OAuth 2.0).

Step 4 — Define journal granularity. The most common choice is one journal entry per accounting period (month) per entity, with one debit line per account type and one credit line per account type. This keeps the Intacct GL clean while the subledger retains transaction-level detail for any audit query. More granular (one journal per transaction) is possible but creates ledger volume that makes period-end review slow. Agree the granularity with the Intacct administrator and the auditor before live posting.

Step 5 — Configure the intercompany rules. For any wallet-to-wallet transfer between entities in the group, the subledger must generate a pair of offsetting intercompany journal entries — a debit in the receiving entity and a credit in the sending entity — rather than a debit to the asset account and a credit to a disposal/gain account. Confirm Intacct's intercompany elimination accounts are set up and that the subledger routes to them for intra-group transfers.

Step 6 — Run a test period post and reconcile. Before live deployment, post one month of historical data to a test Intacct company, reconcile the resulting trial balance back to the subledger's data (token by token, entity by entity), and resolve any mapping gaps. Common issues at this stage: accounts that don't exist in Intacct yet (configuration error), period mismatches (journal dates landing in the wrong accounting period), and missing entity IDs (a wallet not tagged to any entity).

Step 7 — Lock and sign off. Once the test reconciliation is clean, lock the test period and have the auditor or controller sign off on the journal mapping before live data is posted. The posting design is the auditor's confirmation to give; the subledger's job is to deliver correctly structured journals.

Configuration checklist for Sage Intacct crypto integration

• Entity IDs from Intacct exported and matched to subledger entity dimension
• CoA accounts for digital assets, realised/unrealised gain-loss, fees, and income exist in Intacct
• API interface confirmed (REST OAuth 2.0 vs SOAP SID) against current Intacct docs
• Journal granularity agreed with Intacct admin and auditor (per-period vs per-transaction)
• Intercompany accounts configured; subledger routes intra-group transfers to intercompany accounts, not disposal accounts
• Test-period post completed and trial balance reconciled
• Journal mapping signed off by controller/auditor before live deployment

Further reading

• Crypto-to-ERP Journal Entry Export
• Multi-Entity Crypto Chart of Accounts
• Crypto Subledger to ERP API Integration
• Crypto Accounting NetSuite Integration
• Crypto Accounting ERP Selection Guide
• Internal Transfer vs Disposal (Crypto)

Sources

• Sage Intacct — Create a journal entry (REST API) and Get started with the Sage Intacct REST API: document the journal-entry create endpoint and the REST interface a subledger posts to (the SOAP/XML web services remain available alongside it).
• For the unrealized fair-value entries referenced in the setup, FASB — ASU 2023-08 (Subtopic 350-60) requires in-scope crypto assets to be measured at fair value each reporting period.
• The multi-entity and intercompany treatment (entity dimension mapped to Intacct entities so transfers are not external disposals and consolidation does not double-count) is an auditor judgement; confirm the posting design with your auditor and Intacct administrator. Not accounting advice.