It’s time for everyone’s favorite topic: reversing impairment and adopting fair value accounting under ASU 2023-08 Accounting for and Disclosure of Crypto Assets. This article may seem stale since we’re in October 2025 now, but you’d be surprised how many of my newer clients haven’t transitioned to this guidance yet. Let’s face it - reversing impairment and re-stating your books is a nuisance, but luckily you just need to rip the band-aid off once. Most of my bigger customers are on Bitwave, an enterprise-grade crypto subledger, so we’ll be demoing the reversal in that system. Before getting into the reversal process, I have one disclaimer - make sure your books are clean under the impairment methodology before switching to fair value. In particular, if your Bitwave instance is full of mistakes like negative cost basis errors and ending balance variances, I recommend fixing these first. It’ll make future reconciliations much easier. :)

Let’s dive into it! 🏊

To assist with our article, see here for a spreadsheet with example numbers and below for a review Loom!

‍

Guidance per ASU 2023-08

350-60-65-1 An entity shall recognize the cumulative effect…as an adjustment to the opening balance of retained earnings (or other appropriate components of equity or net assets in the statement of financial position) as of the beginning of the annual reporting period in which the entity first applies the pending content that links to this paragraph.

The adjustment to the opening balance of retained earnings (or other appropriate components of equity or net assets in the statement of financial position) shall be calculated as the difference between the carrying amount of crypto assets as of the end of the prior annual reporting period and the fair value of those crypto assets To situate our understanding, here is an excerpt straight from the horse’s mouth: in which the entity first applies the pending content that links to this paragraph.

350-60-45-2 Gains and losses from the remeasurement of crypto assets shall be included in net income and presented separately from changes in the carrying amount of other intangible assets.

Carrying value is cost basis minus impairment, so the total cumulative adjustment is calculated as:

Fair value of assets at beginning of adoption period
(Minus Carrying value of assets right before adoption)

Our goal with transitioning to ASU 2023-08 is to true up your crypto asset balance from its carrying value to whatever the fair value is on 1/1/2025 (or whenever your company adopts the standard). It seems easy in theory but there’s a few quirks when implementing it in Bitwave:

• In the Actions report (Bitwave’s cost basis tracking report that has realized gain/loss information), impairment directly affects the cost basis stack. When crypto assets are disposed, Bitwave disposes the carrying value, not the cost basis (so impairment is baked into the realized gain/loss value).
• This implies that when assets are disposed of, a mix of original cost basis and accumulated impairment is getting disposed of as well (aka the carrying value). This is important because when reversing impairment, you’re not reversing 100% of the all impairment ever booked - you’re reversing the impairment that’s left.
• The customer might not want to reverse impairment on all of the crypto assets. Some holdings might be out of scope of the new ASU and are subject to impairment rules still. In this case, you’ll have to create two different reporting realities in Bitwave, one under fair value and the other under impairment, and “frakenstein” the two reports together (i.e. mash your own rollforward together).

As a refresher, here’s what assets are in scope of ASU 2023-08:

1. Meet the definition of intangible assets as defined in the Codification
2. Do not provide the asset holder with enforceable rights to or claims on underlying goods, services, or other assets
3. Are created or reside on a distributed ledger based on blockchain or similar technology
4. Are secured through cryptography
5. Are fungible
6. Are not created or issued by the reporting entity or its related parties.

Off the bat, the standard excludes NFTs, governance tokens (for the issuing entity or entities related to it), wrapped tokens and tokenized assets. It’s common practice for companies to examine all of their crypto holdings and tag which kind of asset it is (Fair value or CLI - cost less impairment).

How to Do the Calculation Correctly in Bitwave

Assuming your books are already reconciled under cost less impairment, you’re ready for the next step!

Step #1 - Run a Cost Basis Rollforward under your Current Impairment View

Under Inventory Views, head to the view that contains the carrying value numbers for the latest period (i.e. the time period before you adopt fair value). The ending carrying value from the cost basis rollforward* should tie out to your balance sheet. Run the rollforward for all time so it captures all of the data from company inception to right before the adoption (i.e. in the screenshot, the date range is from 1/1/2022 to 12/31/24 and the company is transitioning to fair value on 1/1/25).

We’re running all-time numbers because we need to know the total cumulative impairment that should appear in the books. Most of my customers have two balance sheet accounts for crypto assets:

• Crypto assets (represents cost number)
• Impairment (contra-asset account, displays cumulative impairment since inception)
• The sum of these two accounts should equal the ending carrying value per the roll

As I was writing this, I realized the “Crypto Assets” account isn’t pure cost over time because of the way Bitwave bakes impairment into disposal numbers. You can think of this account as cost basis comingled with impairment that was disposed of during dispositions. If the “Impairment” contra-asset account is equal to true cumulative impairment since inception, you’ll be okay during the reversal.

Here’s a refresher on what the cost basis rollforward columns mean in our context:

* I know it’s confusing but in a view with impairment turned on, the cost basis rollforward is really a carrying value rollforward since it factors in cumulative impairment.

At this stage, check that the total cumulative impairment is on your balance sheet and that the total carrying value per Bitwave ties out to your books (if they don’t, you’ve got some reconciling to do).

Step #2 - Run the Actions Report for the Same Time Period & Reverse Impairment

In our example, let’s say all of your assets are in scope of the new ASU and will be transitioning to fair value accounting. Run the actions report for the same time period as the rollforward and the sum the values in these columns (they will be way off to the right):

• total_costBasisRelieved → in your Actions report, this is really carrying value relieved
• total_impairmentExpenseDisposed
• total_originalCostBasisDisposed

I think of the formula this way:

total_costBasisRelieved = total_impairmentExpenseDisposed + total_originalCostBasisDisposed

This ties back to what I wrote earlier about dispositions being carrying value disposed, which inherently contains both original cost and impairment. Depending on the volume of data in your system, this actions report (especially when run for all-time) can be huge. You can also ask the Bitwave team to grab these numbers on your behalf since they can query your transactions directly.

Here’s what our working file looked like:

The actual impairment to reverse ($71k) was the difference between cumulative impairment (coming from the rollforward → $73k) and the impairment that was already disposed through crypto sends ($1.9k). Therefore, the opening balance adjustment (credit) to retained earnings was for $71k, not the full cumulative impairment.

This part really tripped me up when I was doing reversals for the first time. We were initially advised to clear our impairment account to $0 and credit retained earnings for the full cumulative impairment, but that’s not correct and won’t tie out to future Bitwave fair value rollforwards. You need to only reverse the impairment Bitwave thinks is still on your balance sheet (or put another way, the impairment related to crypto assets that haven’t been disposed of yet).

Our reversal entry (before factoring in the fair value adjustment) looked like this:

Debit Impairment Contra-Asset xx → for full cumulative impairment on the rollforward, this clears the account to $0

Credit Retained Earnings  xx → remaining impairment to reverse (factors in dispositions already)

Credit Crypto Assets  xx → difference between the two accounts, this gets your crypto assets account to pure cost

To verify the accuracy of the journal entry, I recommend running a cost-only view in Bitwave using the same relief methodology as your impairment view (i.e. FIFO, LIFO, average cost basis). The ending_fiat_value per the cost-only roll should tie to the ending balance in the crypto assets account.

Step #3 - Layer on Fair Value Adjustment

The final (and easiest step in my opinion) is marking your crypto cost basis up or down to fair value on the date of adoption. Fair value can be found by running a balance report on the adoption date or running a GAAP fair value view in Bitwave and checking the “Include FMV” box (see screenshots below). I recommend my clients keep cost basis in one account and track fair value changes in a separate account, often called Crypto Fair Value Adjustment.

In our example, the fair value adjustment was $1,125 (difference between cost basis and fair market value, assuming no other transactions on 1/1/25). The second entry to record on the adoption date is:

Debit Crypto Fair Value Adjustment    $1,125

Credit Retained Earnings $1,125

And your fair value adjustment is complete! I always ensure the books reconcile to Bitwave’s cost basis rollforward (including the fair value column). When using the cost only or GAAP FMV views, realized gain/loss is also only including cost and doesn’t factor in any historical impairment, which aligns with the reversal we did in the books.

A quick note on something that confused me - per ASC 350-60-65-1-c, the adjustment to the opening balance of retained earnings…shall be calculated as the difference between the carrying amount of crypto assets as of the end of the prior annual reporting period and the fair value of those crypto assets as of the beginning of the annual reporting period in which the entity first applies the pending content.

In our example, the opening balance adjustment is:

Fair Value on 1/1/2025

(Minus Carrying Value on 12/31/24)

There might be transactions on 1/1/2025, so those will need to be accounted for under the new ASU and included in the overall fair value adjustment.

—

And there you have it! There’s so many minor steps to this important calculation, but you’ll know if you’re right by running the cost-only view. That’s the beautiful thing about accounting; even when there’s a million transactions, debits and credits bring us home. 🐻

See below for example Bitwave inventory view settings you can use for the ASU adoption.

Impairment View Settings

Cost-Only View Settings

GAAP Fair Value View (note: picking GAAP Fair Value valuation will still show cost only in the starting_fiat_value and ending_fiat_value columns - fair value is only displayed as a separate column the in-line cost basis rollforward if you check the relevant box)