You're reviewing a proposal to move $50 million from conventional bank deposits into a stablecoin. Treasury argues it's operationally superior: 24/7 settlement, rapid transfers, and access to digital-asset markets. The issuer looks solid. Compliance has vetted the custodian. Risk has signed off on concentration limits.
The board paper describes the move as "redeploying dollars into another form of dollar liquidity."
Here's the decision you're facing: Does your approval process stop at regulatory permissibility, or does it require an accounting determination before execution?
Why This Decision Matters
When compliance, treasury, finance, and risk examine the same crypto asset, they're often measuring different things. Treasury sees economic liquidity. Finance sees balance-sheet classification. Risk sees volatility exposure. Compliance sees an approved counterparty.
None of those perspectives is wrong. The control failure occurs when they're reached separately.
For material crypto transactions, accounting can't be a post-execution reporting exercise. It needs to be part of the pre-transaction approval framework. You don't need to determine the accounting treatment yourself, but you do need to ensure the accounting answer exists before you approve the transaction.
Key Factors That Affect Your Choice
Balance-sheet impact vs. economic value
Under IFRS, cryptocurrency evaluated by the IFRS Interpretations Committee may be classified under IAS 38 unless it qualifies as inventory under IAS 2. It's not treated as cash merely because it can be sold quickly. A $30 million Bitcoin purchase that treasury views as a liquid reserve could shift $30 million from current to non-current assets, dropping your current ratio from 2.0x to 1.7x and your cash ratio from 1.0x to 0.7x. Economic value hasn't changed, but reported liquidity has.
Accounting standard in effect
Tesla recognized approximately $101 million of Bitcoin impairment losses in 2021 under the then-applicable US GAAP treatment for indefinite-lived intangible assets. Declines triggered impairment charges; subsequent increases couldn't flow back through earnings unless the asset was sold. FASB's ASU 2023-08 changed this, requiring qualifying crypto assets to be measured at fair value with changes recognized in net income. The reform didn't eliminate the need to model financial-reporting consequences; it changed which consequences you need to model.
Activity vs. asset
Approving ETH as a treasury holding is not the same as approving staking that ETH. The token hasn't changed, but the activity has. Staking introduces validator exposure, liquidity restrictions, slashing risk, different custody arrangements, staking rewards, and new reconciliation requirements. A decision framed as "we already own it, so let's earn a return" can materially alter the risk and control profile of an already-approved asset.
Path A: Require Accounting Sign-Off Before Transaction Approval
Choose this path when:
- The transaction is material to your balance sheet or income statement
- The asset could affect liquidity ratios, financing covenants, or credit analysis
- You're entering a new asset class or structure without established internal precedent
- The board paper describes economic benefits without modeling financial-statement effects
- The proposed activity involves staking, lending, collateralization, or other yield-generating structures
What this path requires:
Before compliance approves the transaction, finance must determine:
- The proposed accounting treatment under your applicable framework (IFRS, US GAAP, or other)
- Balance-sheet classification (current vs. non-current; cash equivalent vs. intangible vs. other)
- Earnings-statement consequences under realistic upside and downside scenarios
- Effect on internal treasury limits and contractual liquidity metrics
- Valuation methodology and pricing sources
- Financial-reporting controls and reconciliations required post-transaction
- Whether changes in use (e.g., moving from holding to staking) trigger renewed approval
Control design:
Add a mandatory finance review gate to your crypto approval workflow. The compliance sign-off cannot proceed until finance has documented the accounting treatment and modeled the financial-statement impact. For covenant-sensitive companies, include a secondary review confirming the transaction won't breach existing credit agreement definitions of liquidity or tangible net worth.
Path B: Allow Post-Transaction Accounting Determination
Choose this path when:
- The transaction is immaterial to financial statements and covenants
- You're acquiring an asset with established internal accounting precedent
- The activity is a straightforward purchase-and-hold with no staking, lending, or collateralization
- Treasury limits are defined in economic terms without reference to accounting classifications
- No board reporting or investor communication will describe the asset using accounting terminology
What this path requires:
Compliance can approve based on regulatory permissibility, counterparty due diligence, and risk limits. Finance determines accounting treatment during the normal close cycle.
Risk you're accepting:
You may discover after execution that "liquid reserves" on treasury's dashboard don't match "cash and cash equivalents" on the balance sheet. If the asset's market price moves before the next reporting period, you could recognize impairment or volatility that wasn't modeled in the approval memo. If the transaction triggers questions from lenders or auditors, you'll be explaining the decision retrospectively rather than documenting it prospectively.
Path C: Establish Asset-Specific Accounting Precedents
Choose this path when:
You expect recurring transactions in the same asset class and want to avoid case-by-case finance reviews for every execution.
What this path requires:
Finance and compliance jointly establish documented accounting treatments for specific assets and activities. For example: "USDC held in custody at [approved custodian] and not deployed into lending protocols will be classified as [classification] under [standard]." Treasury can then execute within pre-approved parameters without transaction-by-transaction finance sign-off.
Control design:
Document the approved accounting treatment, the factual assumptions it relies on (e.g., issuer reserves, redemption rights, custody structure), and the triggers that require renewed finance review (e.g., change in issuer, change in activity, change in accounting standard). Review the documented treatments annually or when facts change.
Summary Matrix
| Decision Point | Path A: Pre-Transaction Accounting | Path B: Post-Transaction Accounting | Path C: Precedent-Based |
|---|---|---|---|
| Best for | Material transactions, new asset classes | Immaterial holdings, established precedent | Recurring activity in approved assets |
| Finance involvement | Required before approval | During normal close cycle | At precedent establishment, then exception-based |
| Approval speed | Slower (additional review gate) | Faster (fewer gates) | Fast for in-scope transactions |
| Covenant risk | Modeled in advance | Discovered after execution | Managed through precedent parameters |
| Suitable when | Board expects accounting-aware decision | Economic value is the primary concern | Operational efficiency matters and risk is bounded |
The control question isn't whether crypto is permissible. It's whether you know what your financial statements will say before you approve the transaction. If treasury's "liquid reserves" and finance's "cash and cash equivalents" measure different things, you need to reconcile them before execution, not after.
