Accounting Methodology

The accounting engine is CryptaCount's core differentiator. It transforms classified blockchain transactions into proper double-entry journal entries, calculates cost basis under eight internationally recognized methods, and produces rollforward schedules that reconcile period-over-period — the fundamental requirement for audit-ready financial reporting.

Double-Entry Bookkeeping

Every transaction processed by CryptaCount generates one or more journal entries following double-entry accounting principles. Debits always equal credits. There are no single-sided entries, no unexplained balance adjustments, and no opaque calculations.

For a simple ETH purchase at €2,100:

| Account | Debit (EUR) | Credit (EUR) | |---|---|---| | Digital Assets — ETH | 2,100.00 | | | Cash / Bank | | 2,100.00 |

For a more complex DeFi staking reward claim (0.5 LINK at FMV €7.25):

| Account | Debit (EUR) | Credit (EUR) | |---|---|---| | Digital Assets — LINK | 7.25 | | | Staking Income | | 7.25 |

The journal structure supports a full chart of accounts, allowing businesses to map crypto transactions into their existing accounting framework.

Tamper-Evident Journal Integrity

Each journal entry is cryptographically hashed upon creation. The hash chain links each entry to its predecessor, creating a tamper-evident ledger. Any modification to a historical journal entry breaks the hash chain, making unauthorized changes immediately detectable.

This mechanism provides the audit evidence that the ledger has not been retroactively modified — a fundamental requirement for financial statement audits. Corrections are still possible but must be transparent and traceable, consistent with accepted accounting practice.

Cost Basis Methods

CryptaCount implements eight cost basis methods, covering the full range of internationally recognized approaches:

| Method | Description | Common Jurisdictions | |---|---|---| | FIFO | First In, First Out — oldest lots disposed first | US (default), UK, many EU states | | LIFO | Last In, First Out — newest lots disposed first | Permitted in some jurisdictions | | HIFO | Highest In, First Out — highest-cost lots disposed first | Tax optimization where permitted | | WAVG | Weighted Average Cost — single blended cost per asset | France (mandatory), IFRS common | | FMV | Fair Market Value — mark-to-market | Trading firms, certain fund structures | | NRV + FIFO | Net Realizable Value (FIFO basis) | IAS 2 inventory valuation | | NRV + Weighted Average | Net Realizable Value (WAVG basis) | IAS 2 inventory valuation | | Specific Identification | Specific Identification — user selects lots | Permitted in US, others |

Three-Level Resolution Hierarchy

The cost basis method resolves through a three-level hierarchy:

1. Asset-specific override — A method set on a particular asset (e.g., "use HIFO for LINK") takes highest precedence 2. Asset class level — A method set for an asset class (e.g., "use WAVG for all stablecoins") applies to all assets in that class unless overridden at level 1 3. Workspace default — The workspace-level default (e.g., "FIFO") applies to everything not overridden at levels 1 or 2

This hierarchy accommodates the real-world requirement where a portfolio may need different methods for different asset categories within the same jurisdiction, or where a specific asset has a regulatory carve-out.

For example, an accounting firm managing a Luxembourg client might set FIFO as the workspace default, WAVG for stablecoins (asset class level), and Specific Identification for a particular large ETH position where lot selection matters for tax optimization (asset-specific level).

Fair Market Value (FMV)

The platform sources fair market value data for pricing transactions and positions. FMV is captured at three granularities:

• Transaction-time FMV — The market price at the exact timestamp of each transaction, used for cost basis and income recognition
• Daily closing rate — End-of-day prices used for reporting and position valuation
• Monthly average rate — Used for FMV Revaluation per IAS 21 methodology

All FMV data is stored in both USD (primary pricing currency) and translated to the workspace's reporting currency (typically EUR) using the applicable exchange rate.

Five-Column Rollforward

The rollforward is the central reconciliation artifact. It tracks each asset position across a reporting period in five columns:

| Column | Description | Source | |---|---|---| | Quantity | Number of units held | Transaction in/out aggregation | | Cost (USD) | Historical cost in USD | Acquisition price at purchase | | FMV (USD) | Fair market value in USD | Current market price × quantity | | Cost (EUR) | Historical cost in EUR | Cost USD × FX rate at acquisition | | FMV (EUR) | Fair market value in EUR | FMV USD × FX closing rate |

The rollforward reconciles: Opening Balance + Additions − Disposals ± Revaluations = Closing Balance, verified across all five columns.

FX Translation Methodology

For workspaces reporting in EUR (or any non-USD currency), the platform applies IAS 21-aligned translation:

• FMV Revaluation (EUR) uses the monthly average exchange rate — this smooths daily FX volatility in revaluation gains/losses, consistent with IAS 21 guidance for income and expense items
• FX Translation uses the closing rate — the balance sheet date exchange rate applied to monetary items
• FX on Revaluation is the balancing difference — the residual that arises from the interaction between FMV changes and FX rate changes. This is not independently calculated; it is derived as the amount needed to balance the rollforward after FMV Revaluation and FX Translation are applied

This three-component approach (FMV Revaluation, FX Translation, FX on Revaluation) ensures that the EUR rollforward columns always reconcile while properly attributing value changes to their economic sources.

Realized and Unrealized Gains

Realized gains/losses are calculated at disposal (sale, trade, transfer out) as the difference between proceeds and cost basis under the selected method. The gain or loss is denominated in both USD and the reporting currency.

Unrealized gains/losses represent the mark-to-market difference between current FMV and historical cost for assets still held. These are computed at any point-in-time for reporting purposes without affecting the underlying cost basis.

For jurisdictions that distinguish short-term and long-term capital gains (based on holding period), the platform tracks acquisition dates at the lot level. The holding period classification is jurisdiction-dependent and resolved through the tax profile system.

Transaction Classification

The platform automatically assigns transaction types based on on-chain event analysis:

| Category | Transaction Types | |---|---| | Transfers | Transfer in, Transfer out | | Trading | Trade, Swap | | Fees | Gas and network fees | | Income | Staking reward, Mining reward, Airdrop, Other income | | Expense | Expense | | DeFi | Liquidity add/remove, Stake/unstake, Borrow/repay, Reward claim, Wrap/unwrap, Bridge in/out | | NFT | NFT mint, NFT trade |

Classification is automatic but overridable. Users can reclassify individual transactions or define bulk reclassification rules. Every classification change is logged in the audit trail, ensuring full traceability of any professional judgment applied.