Crypto Accounting Microsoft Dynamics 365 Integration

Integrating crypto into Microsoft Dynamics 365 turns on two product-specific facts: which Dynamics you run, and how it tags transactions. Business Central (for SMEs) and Finance (for larger, often multi-entity enterprises) share the same general-journal target but differ in scale, and both use dimensions — financial dimensions in Finance, dimension codes in Business Central — to record attributes like entity, department, and cost center beyond the account code. For crypto, the subledger should map each wallet or exchange account to a dimension value so balances can be reconciled to on-chain holdings per custody source; a GL that dumps all crypto into one account code with no dimension tag cannot be reconciled at the wallet level, which is what an audit needs. Posting reaches Dynamics through its journal APIs and data-integration mechanisms (Business Central exposes journals via its API and Dataverse; Finance imports through the General journal data entity), and the wider on-chain-to-GL flow is the universal subledger pattern. The accounting is an auditor judgement.

In short

• Neither Business Central nor Finance has a native crypto concept; integrate 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 to the Dynamics GL.
• Posting goes through Dynamics' journal APIs and data-integration (Business Central via its API and Dataverse; Finance via the General journal data entity). Configure to current Microsoft docs, since interfaces vary by product and version.
• Map each wallet to a dimension value (financial dimensions in Finance, dimension codes in Business Central) so the GL reconciles to on-chain balances per custody source.
• Finance is the more multi-entity product, so the entity dimension and consolidation matter more there.
• Post summarised journals; the subledger keeps the transaction detail for audit. Export is not final — classification is an auditor judgement. Not accounting advice.

No native crypto

Dynamics 365 — Business Central for SMEs, Finance for larger enterprises — has no native wallet, blockchain, or token concept. Crypto integrates via the standard subledger pattern: an external subledger connects to the wallets and exchanges, applies cost basis and classification, and posts summary journals to the Dynamics GL. Dynamics stays the system of record; the accounting is an auditor judgement.

How the subledger posts

Dynamics 365 exposes APIs and data-integration mechanisms for posting journals programmatically, or entries can be delivered through a supported import. Business Central offers a journals API and integrates with Dataverse for create/read/update/delete operations; Finance imports vouchers through the General journal data entity. The interface and field mapping must be configured against Microsoft's current Dynamics documentation, since the platform and its APIs evolve across versions and environments. The mechanism is delivery, not an accounting change.

Business Central vs Finance

The core pattern is identical: a subledger posts mapped summary journals to the GL. What differs is scale and structure. Business Central serves SMEs with simpler structures; Finance serves larger, often multi-entity enterprises where the entity dimension and consolidation matter more (see multi-entity crypto CoA). The subledger configuration — granularity, entity mapping — is adjusted to the specific product and the firm's structure, and confirmed with the administrator.

Journal granularity

Generally summarised journals — periodic entries for holdings, realized and unrealized results, income, and fees — rather than raw transactions, with the subledger retaining the transaction detail for audit. The granularity is a design choice; the Dynamics summary plus the subledger detail together form the audit trail.

Export is plumbing

The integration delivers structured journals; it does not validate classification, cost basis, or fair value, which remain accounting judgements subject to review and audit. The accounting correctness is established separately and confirmed with the auditor.

Practical guidance

1. Use the subledger pattern; Dynamics has no native crypto.
2. Configure the interface (Business Central API and Dataverse, or the Finance General journal data entity) against current Microsoft docs.
3. Map each wallet to a dimension value, and use the entity dimension for multi-entity Finance deployments.
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 Dynamics administrator. APIs change, and this is not accounting advice.

Data Model Mapping: From On-Chain to Dynamics 365

Before any journal is posted, the subledger must translate the on-chain data model into Dynamics' data model. The mapping decisions made here determine whether the resulting ledger is auditable and whether the Dynamics close process works cleanly.

Wallet and Account Inventory as Dimensions

Dynamics 365 uses dimensions (Business Central) or financial dimensions (Finance) to tag transactions with attributes beyond the account code — department, project, cost center, entity. For crypto, the standard practice is to map each wallet address or exchange account to a dimension value so that balances can be filtered and reconciled per custody source. A Dynamics GL that aggregates all crypto activity into a single account code without dimension tagging cannot be reconciled to on-chain balances at the wallet level — which is what an audit requires.

In Business Central, this is typically handled with custom dimension codes. In Finance, it uses the financial dimension framework that also supports multi-entity consolidation. The mapping should be configured before the first journals are posted; retrofitting dimension tags to historical entries is costly.

Transaction Type to Journal Line Type

Each category of on-chain event maps to a distinct journal entry type in Dynamics:

The intercompany transfer row is the most common posting error in multi-entity Dynamics Finance deployments: a transfer of crypto from one group entity's wallet to another is not a disposal at arm's length and should not generate a realized gain/loss line. Configuring the entity-dimension logic to detect and correctly route intercompany flows is mandatory before go-live.

Cost Basis Method Configuration

Dynamics 365 does not natively support crypto cost-basis methods (FIFO, LIFO, weighted average). The subledger must compute the cost basis per method before posting, and post the computed realized gain/loss figure to Dynamics as a single journal line. The posting to Dynamics is the output of the cost-basis computation, not the input. This means changing the cost-basis method in the subledger — for example, switching from FIFO to weighted average — would require reprocessing all historical positions and re-posting the difference, a potentially significant retrospective adjustment.

The cost-basis method should be selected once, documented as an accounting policy, and confirmed with the auditor before any production posting.

Month-End Close Workflow for Dynamics 365 Crypto Entities

The month-end close for a Dynamics entity with crypto activity has several steps that do not exist in a purely fiat-denominated entity.

Step 1: Wallet Reconciliation (T+1 to T+5)

At the first business day of the new month, the subledger pulls the prior month's complete on-chain activity for all wallets and exchange accounts in scope. It reconciles the ending on-chain balance for each asset in each wallet against the Dynamics GL crypto-asset account balance (filtered by wallet dimension). Any discrepancy — a missing transaction, a mis-classified transfer, an omitted wallet — must be investigated and resolved before journals are posted. This is the reconciliation checkpoint before any entries hit the GL.

Step 2: Fair-Value Pricing Run (T+2 to T+5)

For period-end unrealized gain/loss entries (where the accounting policy requires fair-value measurement), the subledger pulls market prices at the close date and computes the unrealized movement since the prior period-end. The entry is the difference, not the absolute value. For periods with multiple price-source options (closing bid, volume-weighted average, specific exchange reference price), the pricing source must be consistently applied and documented. Under French PCG (provisioning model), unrealized losses are provisioned; unrealized gains are not — the entry asymmetry must be correctly coded in the Dynamics account mapping.

Step 3: Journal Import and Posting (T+3 to T+7)

The subledger generates the period's journal entries and imports them via the Dynamics API or supported import file. Journals should be posted as a batch keyed to the accounting period, not individual transactions, so the close process treats them as a single reconcilable unit. After posting, the Dynamics trial balance for the period's crypto accounts should be exported and reconciled line-by-line against the subledger's computed period-end balances — the final in-period reconciliation.

Step 4: Auditor Review Package

At the Dynamics close, the accountant prepares a crypto reconciliation package for the auditor or reviewer:

• Wallet inventory at period-end with on-chain balances vs Dynamics GL balances
• Cost-basis schedule (per asset, per wallet) showing beginning balance, acquisitions, disposals, and ending balance at cost
• Realized gain/loss summary by asset and disposal date
• Unrealized movement and provisioning entries (where applicable)
• Fair-value pricing source documentation

This package is what a Dynamics external auditor or a vérificateur from the DGFiP (for French entities) expects to find pre-built, not assembled on request during the audit.

Evaluating a tool for Dynamics 365

Vendors such as Cryptio and Bitwave offer Microsoft Dynamics integrations that post summary journals to the GL. The Dynamics-specific things to check are the product variant and the dimension handling, so before committing, confirm the tool:

• posts to the variant you run — Business Central via its API or Dataverse, or Finance via the General journal data entity — rather than only one of them;
• writes a dimension value per wallet so the GL reconciles to on-chain balances per custody source;
• carries the entity dimension for multi-entity Finance deployments, so intercompany transfers are not booked as external disposals;
• maps to your own chart of accounts, with separate realized and unrealized accounts.

The tool delivers the journals; the classification is an auditor judgement.

Where Wag3s fits

Wag3s Ledger maps wallet and exchange activity to a configurable chart of accounts and posts summarised journals to Dynamics 365 through its API or supported import, retaining the transaction detail for audit. The classification and accounting correctness are established separately and confirmed with the auditor. See the Ledger product page.

Further reading

• Crypto-to-ERP Journal Entry Export
• Crypto Accounting Sage Intacct Integration
• Crypto Subledger to ERP API Integration
• Multi-Entity Crypto Chart of Accounts
• Crypto Accounting ERP Selection Guide
• Crypto Chart of Accounts Design

Sources

• Microsoft — Business Central journals API and integration overview (Dataverse): document the journal API and the Dataverse CRUD integration a subledger posts through in Business Central.
• Microsoft — Finance Financial dimensions and tags and the General journal data entity: document the dimension model used to tag transactions and the entity used to import vouchers into Finance.
• For the period-end unrealized entries in the data-model mapping, FASB — ASU 2023-08 (Subtopic 350-60) requires in-scope crypto assets to be measured at fair value each reporting period; the French PCG provisioning model referenced is a separate jurisdiction treatment.
• The classification, multi-entity, and intercompany treatments remain auditor judgements; confirm the posting design with your auditor and Dynamics administrator. Not accounting advice.