Revenue Procedure 2024-28: What You Need to Know + Strategy On Allocation (USA)

Cryptocurrency News and Public Mining Pools

Revenue Procedure 2024-28: What You Need to Know + Strategy On Allocation (USA)

USA Only

Background

Earlier this year, the IRS released Revenue Procedure 2024-28, implementing changes with significant impacts to how taxpayers are allowed to track cost basis effective January 1, 2025.

I've seen some chatter, speculation, and misinformation across various sources and subreddits regarding this. I'm a licensed CPA (CA) and would like to clarify what is changing, what isn't changing, and how to go about the change in order to remain compliant.

Universal Cost Tracking vs Wallet-Based Cost Tracking

Most people have multiple wallets and multiple exchanges. If you sell and asset, you need to determine the cost basis for that asset in order to calculate your gain or loss. As discussed later, the default method is First-In-First-Out ("FIFO"), meaning if you have multiple ETH, and sell just one ETH, the cost to be used would be your first ETH purchased of the bunch.

Wallet-Based Cost Tracking: Wallet-Based Cost Tracking looks at each wallet individually and requires you to track cost at the wallet by wallet level. Meaning if you had 3 ETH in Wallet A and 5 ETH in Wallet B, and then you sold one ETH from Wallet B, the cost basis to be used would be the earliest purchased ETH from Wallet B only. Under Wallet-Based Cost Tracking, since you sold from Wallet B, you must pull the cost basis from that wallet and cannot pull the cost basis from any other wallet.

Universal Cost Tracking: Under Universal Cost Tracking, cost basis is not required to be tracked at the wallet level, but rather looked at holistically. In that same example where you have 3 ETH in Wallet A and 5 ETH in Wallet B, if you sell 1 ETH from Wallet B, then all 8 ETH should be considered when determining the earliest cost basis ETH. Meaning, if your earliest purchased ETH was in Wallet A, this is the cost basis tax lot that should be used in calculating your gain/loss even though the actual asset was being sold from Wallet B. In other words, your cost basis tax lots are not separated by wallets but are rather looked at all together.

Prior to Rev Proc 24-28

Prior to this new rev proc, taxpayers largely relied on IRS Crypto FAQs 39-41 for guidance on cost basis for digital assets. Notably, First-In-First-Out (FIFO) is the default cost basis method for tax payers, with no obligation to track cost basis at the wallet level (this is called the "universal cost tracking" method). However, if certain data requirements are met, including wallet-based cost tracking, taxpayers could elect to utilize the Specific Identification (Spec ID) method instead. This method allows taxpayers to specifically identify the cost basis tax lots being sold, giving way for more tax-favorable methods such as LIFO, HIFO, Optimized HIFO, etc.

Post Rev Proc 24-28

Effective January 1, 2025, ALL taxpayers will be required to track cost basis at the wallet level. In other words, if you have ETH in Wallet A and ETH in Wallet B, and then you sell some ETH in Wallet B, you cannot pull the cost basis from Wallet A (which was previously allowed when wallet based cost tracking was not required).

Tax payers have been given a Safe Harbor to "reasonably allocate" their cost basis as of the start of 2025. In other words, if you were using FIFO and not using wallet-based cost tracking, you will need to assess all of your current tax lots and allocate them based on your actual holdings in each wallet/exchange. After the allocation is made, and all wallets and exchanges have cost basis tax lots assigned to them, the allocation will be considered complete and from that point forward cost basis will need to be tracked at the wallet level. Meaning assets sold from Wallet A will need to have their cost basis pulled from Wallet A, even if you are just using FIFO.

How to Allocate Cost Basis

I won't sugarcoat this, this will be a huge challenge for most people. This will require that you have detailed records showing all of your tax lots as of 11:59PM on 12/31/2024. While software tools have been imperative to accurate tax preparation and reporting, without proper features to implement this transition, users will be largely unable to "finesse" the software to allocate the transition. On the bright side, it seems like the major softwares have this on their radar and are working on a solution. I have been in touch with a few different softwares, including the team at Koinly, Bitwave, and others, and they have indicated that their team is working on solutions for an easy transition.

If you don't use a software, then you will have to do this allocation manually in excel. To do so, you'll need to aggregate all of your tax lots as of 11:59PM 12/31/2024 into a list. Then, you will need to look at all of your wallets/exchanges and their balances as of that time. After that, start assigning each tax lot to a wallet until you get to the right amount of crypto held in that wallet at that time. This process will be very manual and very painful, I suggest using a software instead.

Do We Have to Use FIFO?

No, while FIFO will remain the default, if you meet the data requirements in Q40 of the crypto FAQ you can still utilize specific ID to cherry pick which assets are being sold. Really, the only big change here is that wallet based cost tracking will be required for those using FIFO now (was already required for those using specific ID).

My Thoughts on Allocation Approach

My thoughts for softwares is that each cost basis tax lot can be proportionally split between the wallets based on the amount of crypto that is in each wallet. For example, if Wallet A has 1 ETH and Wallet B has 3 ETH, then each individual cost basis tax lot should have 1/4th allocated to Wallet A and 3/4ths allocated to Wallet B. This approach should be fairly easy from a software perspective and would allow for a very easy transition for users.

A second approach would be to assign a hierchy based on either short/long holding period or high/low cost basis. For instance, a user might just want Wallet B to have the lowest cost basis ETH and Wallet A to have the highest cost basis. In that instance, the software would look at all of the cost basis tax lots and assign them accordingly based on the user's hierarchy assigned. This approach seems like it may be more difficult to implement from a software perspective, but hey what do I know I am not a software engineer.

I would love to hear the community's thoughts on additional approaches to make the transition as easy as possible for users. Let me know if there is a better way!

TLDR

  • Wallet based cost tracking will now be required for those previously using FIFO with the universal method
  • Those people will need to allocate their cost basis as of January 1, 2025
  • FIFO is NOT required moving forward, but remains the default (Specific ID is still allowed)

submitted by /u/JustinCPA
[link] [comments]