Per-Wallet Crypto Basis Tracking: The IRS Killed the Universal Method and Beancount Might Be Your Only Hope

tax_tina · March 29, 2026, 8:31am

Per-Wallet Crypto Basis Tracking: The IRS Killed the Universal Method and Beancount Might Be Your Only Hope

The IRS just made crypto tax tracking exponentially harder, and most people don’t realize it yet.

What Changed in 2026

Starting with your 2025 tax return (filed in early 2026), the IRS eliminated the “universal method” for tracking cryptocurrency cost basis. Previously, you could aggregate all your Bitcoin holdings across every wallet, exchange, and platform into one big pool and use a single cost basis tracking method (like FIFO or specific identification).

That’s gone now.

Under the new digital asset regulations, you must maintain separate cost basis records for each wallet and exchange account. If you hold Bitcoin in:

Coinbase
Kraken
A Ledger hardware wallet
A MetaMask hot wallet
Aave lending protocol
Uniswap liquidity pool

You’re now tracking SIX separate Bitcoin cost basis pools. Each with its own purchase history, FIFO queue, and tax lot tracking.

Why This Is a Nightmare

For anyone with a diversified crypto strategy (and if you’re serious about DeFi, you SHOULD be diversified), this creates exponential complexity:

10 platforms × 5 tokens = 50 separate tracking pools
Each DEX trade moves tokens between wallets (new cost basis event)
Each liquidity provision creates new tracking requirements
Staking rewards arrive in specific wallets and must be tracked there
Hardware wallet transfers are now basis-changing events

The commercial crypto tax software I evaluated (CoinTracker, TokenTax, Koinly) charges $300-$1,000/year for plans that handle this complexity. And they STILL struggle with:

DeFi protocol transactions (especially exotic ones)
Cross-chain bridges
NFT trading
Layer 2 solutions (Arbitrum, Optimism, Base)
Staking derivatives (like Lido stETH)

The Beancount Solution

I’ve been tracking my crypto portfolio in Beancount for 2 years now, and I accidentally built exactly what the IRS now requires. Here’s my approach:

Account Structure for Per-Wallet Tracking

; Centralized exchanges (each is a separate cost basis pool)
2024-01-15 open Assets:Crypto:Coinbase:BTC
2024-01-15 open Assets:Crypto:Kraken:BTC
2024-01-15 open Assets:Crypto:Gemini:BTC

; Hardware wallets  
2024-01-15 open Assets:Crypto:Ledger:BTC
2024-01-15 open Assets:Crypto:Trezor:BTC

; Hot wallets
2024-01-15 open Assets:Crypto:MetaMask:ETH
2024-01-15 open Assets:Crypto:Rainbow:ETH

; DeFi protocols
2024-01-15 open Assets:Crypto:Aave:USDC
2024-01-15 open Assets:Crypto:Compound:DAI

Every purchase, trade, transfer, and reward is recorded with the specific wallet/platform it occurred in.

Lot Tracking with Metadata

Beancount’s lot tracking is perfect for this:

2025-03-15 * "Buy BTC on Coinbase"
  Assets:Crypto:Coinbase:BTC    0.05 BTC {47000.00 USD, 2025-03-15}
  Assets:Bank:Checking         -2350.00 USD

2025-06-20 * "Transfer BTC to Ledger"
  Assets:Crypto:Ledger:BTC      0.05 BTC {47000.00 USD, 2025-03-15}
  Assets:Crypto:Coinbase:BTC   -0.05 BTC {47000.00 USD, 2025-03-15}

The {47000.00 USD, 2025-03-15} syntax tracks the cost basis AND acquisition date, which are both required for tax reporting.

Per-Wallet Basis Queries

At tax time, I can query cost basis for any specific wallet:

bean-query ledger.beancount "SELECT account, sum(position) WHERE account ~ 'Coinbase:BTC'"

This gives me the exact cost basis pool for my Coinbase Bitcoin—separate from my Kraken Bitcoin, my Ledger Bitcoin, etc.

The Tax Season Workflow

When I receive my 1099-DA forms from exchanges (starting February 2026 for 2025 transactions), here’s what I do:

Export Form 8949 data from Beancount - filtered by account (Coinbase only, Kraken only, etc.)
Reconcile against 1099-DA gross proceeds - exchanges report sales, but NOT cost basis yet (that starts in 2027 for 2026 transactions)
Identify discrepancies - my Beancount ledger includes DeFi transactions the exchange doesn’t see
Generate complete Form 8949 - with cost basis the IRS won’t receive from exchanges

The DeFi Gap

Here’s the critical part: 1099-DA forms only cover centralized exchanges. They don’t report:

Uniswap trades
Aave lending/borrowing
Curve LP positions
Convex staking rewards
NFT sales on OpenSea
Cross-chain bridge transactions

If you’re active in DeFi, you’re tracking 50%+ of your crypto activity in places that will NEVER appear on a 1099-DA form. The IRS knows this. They’re counting on you to self-report accurately.

Beancount is the only way I’ve found to maintain the authoritative record.

My Question for the Community

I’ve been heads-down building this system for my own portfolio (currently tracking 12 wallets, 8 exchanges, 4 DeFi protocols). But I’m wondering:

Has anyone built importers for hardware wallets? I’m manually entering Ledger transactions right now.
How are you handling staking rewards? Do you book them at fair market value on the day received, or use a different methodology?
What about NFTs? I’m treating each NFT as a unique asset with its own cost basis, but I’m not confident this is optimal.
Have you reconciled actual 1099-DA forms from your 2025 tax filing? Any surprises or missing transactions?

The IRS just made crypto tax compliance 10x harder. But if you’re using Beancount with proper per-wallet account structure, you’re already ahead of 95% of crypto investors.

Tracking 47 wallets and counting. Send help (or importer scripts).

helpful_veteran · March 29, 2026, 8:32am

This is EXACTLY the kind of post that reminds me why I love this community. Tina, you’re absolutely right—and I’ll add that I learned this lesson the hard way during my 2024 tax season.

My Per-Wallet Migration Story

I was tracking crypto in a spreadsheet before discovering Beancount. When the IRS announced the per-wallet requirement, I had to reconstruct 3 years of basis tracking across 8 different wallets. It was painful, but Beancount made it survivable.

The key insight that helped me: treat each wallet/exchange as if it’s a separate person’s portfolio. That mental model makes the account structure click.

Hardware Wallet Importers (Answer to Question 1)

I’ve been manually entering Ledger transactions too. Here’s why I haven’t automated it yet:

Low transaction volume - I transfer TO hardware wallets for long-term holds (maybe 2-3 transactions per month)
High accuracy requirement - These are significant transactions, and I want manual review
On-chain data needs reconciliation - Blockchain explorers give you the transaction, but you still need to match it to your cost basis

That said, I did build a simple Python script that:

Pulls transactions from a blockchain explorer API (Etherscan, Blockchain.com)
Generates Beancount transaction templates with the wallet addresses
Leaves cost basis blank for me to fill in manually

I can share that script if there’s interest. It’s not fully automated, but it saves typing.

Staking Rewards Methodology (Answer to Question 2)

I book staking rewards as income at fair market value on the day received, using CoinGecko’s historical price API:

2025-08-15 * "Staking rewards - Ethereum validator"
  Assets:Crypto:Validator:ETH    0.032 ETH {3200.00 USD, 2025-08-15}
  Income:Crypto:Staking         -102.40 USD

The {3200.00 USD, 2025-08-15} cost basis means when I eventually sell that ETH, my cost basis is $3,200 per ETH (the FMV when I received it). This is conservative and IRS-compliant.

Critical tax note: You owe income tax on that $102.40 in the year received, THEN capital gains tax on any appreciation when you sell. Double taxation on crypto income is real.

The NFT Question (Answer to Question 3)

Your approach is correct—each NFT is a unique asset. I use this account structure:

2025-02-10 open Assets:Crypto:NFT:BoredApe-1234
2025-02-10 open Assets:Crypto:NFT:Azuki-5678

Each NFT gets its own account because:

They’re non-fungible (can’t aggregate cost basis)
Transaction history is per-token
Sale tracking needs to match specific purchases

It feels verbose, but it’s the only accurate way to track cost basis for unique assets.

What I Wish I’d Known Earlier

Start with per-wallet structure from day one. I migrated from a universal pool structure, and it required reconstructing transaction history by cross-referencing exchange statements with blockchain explorers. If you’re just starting with crypto in Beancount, use Tina’s account hierarchy immediately.

Document wallet addresses in metadata. I add wallet addresses to my account opening directives:

2024-01-15 open Assets:Crypto:Ledger:BTC
  wallet-address: "bc1qxy2kgdygjrsqtzq2n0yrf2493p83kkfjhx0wlh"

This makes reconciliation easier when you’re looking at blockchain transactions and need to match them to Beancount accounts.

Community Collaboration Idea

Would there be interest in creating a shared repository of crypto importers? We could build importers for:

Major exchanges (Coinbase, Kraken, Gemini)
DeFi protocols (Uniswap, Aave, Curve)
Blockchain explorers (for hardware wallet transactions)
NFT marketplaces (OpenSea, LooksRare)

Each importer could follow a standard template and include cost basis handling. I’m happy to contribute what I’ve built so far.

Thanks for starting this discussion, Tina. The IRS complexity is frustrating, but at least we have Beancount to handle it!

newbie_accountant · March 29, 2026, 8:32am

Okay, this is both terrifying and helpful. I’ve been dabbling in crypto for about a year (mostly just holding ETH and BTC on Coinbase), and I had NO idea the IRS changed the tracking requirements.

I’m a software developer by day, so the plain text accounting philosophy makes total sense to me—I already use Git for everything, and having my financial data in version control sounds amazing. But I’m completely overwhelmed by the accounting side.

My Newbie Questions

1. Do I need to track EVERY transaction, even if I’m just holding?

Like, if I bought 0.5 ETH on Coinbase in March 2024, transferred it to my MetaMask wallet in June 2024, and it’s just been sitting there… do I need separate cost basis tracking for the Coinbase purchase AND the MetaMask hold? Even though I haven’t sold anything?

2. How do I handle the historical data migration?

I’ve been using a spreadsheet (basically just: date, exchange, amount bought, price). Do I need to go back and reconstruct every transaction with full double-entry bookkeeping? Or can I start fresh with Beancount today and just document my current holdings?

3. Is this overkill for a small portfolio?

I’m tracking maybe $15K worth of crypto across 3 wallets. Am I overthinking this? Should I just use TurboTax’s crypto import and call it a day?

What’s Drawing Me to Beancount

The thing that appeals to me about Beancount (vs. commercial crypto tax software) is:

Transparency: I can see exactly how cost basis is calculated
Auditability: Git history means I can prove what I did and when
No vendor lock-in: If the software shuts down, I still have plain text files
Automation: As a developer, I love that I can script queries and reports

But I’m nervous about the learning curve. The examples in this thread are helpful, but I don’t fully understand double-entry bookkeeping yet. When you write:

2025-03-15 * "Buy BTC on Coinbase"
  Assets:Crypto:Coinbase:BTC    0.05 BTC {47000.00 USD, 2025-03-15}
  Assets:Bank:Checking         -2350.00 USD

Why does the bank checking account have a negative sign? Is that saying “money left the checking account”? And why don’t the amounts balance (0.05 BTC vs $2350)?

My Plan (Need Validation)

Here’s what I’m thinking for getting started:

Document current state - List all my crypto holdings as of today with current cost basis
Set up per-wallet accounts - Use Tina’s structure (one account per exchange/wallet)
Start tracking forward - Beginning today, log every purchase, transfer, sale
Backfill historical data - Over time, reconstruct 2024-2025 transactions from exchange statements

Does this order make sense? Or should I do the historical reconstruction FIRST before tracking new transactions?

Also, if I’m holding long-term (no plans to sell in 2026), do I still need to file anything with the IRS this year? Or is cost basis tracking only relevant when I actually sell?

Thanks for being patient with basic questions! This community seems way more helpful than crypto Reddit.

finance_fred · March 29, 2026, 8:33am

Sarah, your plan is solid—and as someone who tracks every financial metric obsessively for FIRE, I can answer your questions from the “is this worth it?” perspective.

Answering Your Questions

1. Yes, track EVERY transaction (even transfers between your own wallets)

Here’s why: that March 2024 Coinbase purchase → June 2024 MetaMask transfer is TWO separate cost basis pools under the new IRS rules. When you eventually sell, you need to know:

Did you sell from the Coinbase wallet or the MetaMask wallet?
What was the cost basis in THAT specific wallet?

If you don’t track the transfer, you won’t know which wallet holds which cost basis. This matters for FIFO/LIFO calculations.

2. Start fresh + backfill is the right approach

Don’t get paralyzed by historical reconstruction. Here’s the practical workflow I used:

Today: Open your exchange statements, list current holdings, document cost basis
This week: Set up Beancount accounts for each wallet/exchange
Going forward: Track every new transaction in real-time
Next month (when you have time): Backfill 2024-2025 from statements

The key insight: you need accurate cost basis for tax reporting when you SELL. If you’re holding, you can backfill gradually. But track new transactions immediately so you don’t create more reconstruction work later.

3. For a $15K portfolio tracking 3 wallets, Beancount is NOT overkill—it’s the right tool

Here’s the math:

TurboTax crypto import: $89-$129/year + doesn’t handle DeFi or complex scenarios
CoinTracker Premium: $199-$599/year depending on transaction volume
Beancount: $0/year + full control + audit trail

Over 10 years (your crypto holding period?), commercial tools cost $1,000-$5,000. Beancount costs zero.

But the REAL reason to use Beancount: when you’re tracking for FIRE, you need cost basis precision for tax optimization strategies. If you’re planning to hold crypto through early retirement, you’ll want to do tax-loss harvesting, Roth conversion planning, and capital gains management. Commercial tools don’t give you that level of control.

The Double-Entry Bookkeeping Question (Great Question!)

Why does the bank checking account have a negative sign?

Yes! Negative means “money leaving,” positive means “money arriving.”

In double-entry bookkeeping, every transaction has two sides that must balance. When you buy crypto:

2025-03-15 * "Buy BTC on Coinbase"
  Assets:Crypto:Coinbase:BTC    0.05 BTC {47000.00 USD, 2025-03-15}  ; You gained 0.05 BTC
  Assets:Bank:Checking         -2350.00 USD                           ; You lost $2,350

The amounts DO balance—but in different units:

0.05 BTC at $47,000/BTC = $2,350 (Beancount understands this through the cost notation)
-$2,350 USD from checking (Beancount verifies the USD amount matches)

Beancount’s lot syntax {47000.00 USD, 2025-03-15} means “this crypto was purchased at $47K per unit on March 15.” That’s your cost basis.

Think of it like version control for money: every transaction is a “commit” that moves value between accounts, and Beancount enforces that the books balance.

My FIRE-Optimized Crypto Tracking Setup

I’m tracking crypto as part of my path to financial independence (currently 63% to FI, aiming for 2029 retirement). Here’s my structure:

; Track crypto by wallet AND by tax treatment
2024-01-01 open Assets:Crypto:Taxable:Coinbase:BTC
2024-01-01 open Assets:Crypto:Taxable:MetaMask:ETH
2024-01-01 open Assets:Crypto:IRA:iTrustCapital:BTC  ; Yes, I hold crypto in my Roth IRA

Why the extra layer? Tax-advantaged crypto holdings have ZERO cost basis reporting requirements. If I hold BTC in my Roth IRA, I never file Form 8949 for those transactions. Separating taxable vs. IRA accounts makes tax season trivial.

Automation I’ve Built

Since you’re a developer, here are the scripts I use:

Daily price updates - Cron job that fetches closing prices from CoinGecko and updates my prices.beancount file
Exchange importers - Python scripts that convert Coinbase/Kraken CSV exports to Beancount transactions
Net worth dashboard - Custom Fava extension that shows crypto as % of total net worth (currently 8.3% of my portfolio)

If you’re interested, I can share these on GitHub. They’re not polished, but they work.

The FIRE Perspective: Is Crypto Tracking Worth Your Time?

Time investment for Beancount crypto tracking:

Initial setup: 4-6 hours (learning curve + account structure)
Historical backfill: 2-4 hours (depending on transaction volume)
Ongoing maintenance: 15 minutes/week (logging new transactions)

That’s roughly 30 hours/year to maintain complete, audit-ready crypto records.

Compare to:

CoinTracker subscription: $599/year for 10,000 transactions
CPA crypto tax prep: $300-$800/year for complex returns
IRS audit defense costs: $5,000-$15,000 if you can’t document cost basis

For a $15K portfolio growing to potentially $100K+ over the next decade, spending 30 hours/year to save $600-$800 in software costs + build audit-proof documentation is a $20-$25/hour return on your time. That’s worth it.

And the knowledge you gain about accounting, tax optimization, and financial tracking? That’s worth even more for your FIRE journey.

Sarah, start with Beancount. Your developer background means you’ll pick it up fast. And once you have it working, you’ll never want to use commercial crypto tax software again.

bookkeeper_bob · March 29, 2026, 8:34am

This thread is gold. I’m coming at this from a different angle—I’m a bookkeeper who’s starting to get crypto questions from clients, and honestly, I’ve been terrified of this compliance burden.

The Client Reality

I work with 20+ small businesses, and THREE of them have started asking about crypto tracking in the last 6 months:

Freelance graphic designer - Gets paid in ETH sometimes, holds it across 2 exchanges + hardware wallet
E-commerce store owner - Accepted Bitcoin payments in 2024, has ~$8K sitting in Coinbase
Consultant - DCA’ing into crypto as part of retirement strategy, active on multiple exchanges

None of them are crypto traders. They’re regular small business owners who now need per-wallet cost basis tracking. And they’re looking at me to help them.

Why I’m Exploring Beancount for Client Work

I’ve been a QuickBooks user for 10 years. It’s what I know, it’s what clients expect. But QuickBooks has ZERO crypto functionality—you can’t track cost basis, lot-level detail, or per-wallet pools.

Commercial crypto tax software (CoinTracker, TaxBit) is designed for individual investors, not business bookkeeping. They don’t integrate with QuickBooks. They don’t handle business-specific scenarios (crypto as payment for services, crypto used to pay vendors).

Beancount might be the only tool that can handle business crypto accounting properly.

The Questions I’m Wrestling With

1. Client education - How do I explain Beancount to non-technical clients?

My graphic designer client barely understands Excel. She’s not going to edit plain text files or run command-line queries. I need to:

Handle all Beancount bookkeeping myself (she sends me monthly statements)
Generate reports she can understand (Fava web interface?)
Deliver Form 8949-ready data at tax time

Is this realistic? Or am I setting myself up for a support nightmare?

2. Hybrid workflows - Can I run QuickBooks + Beancount simultaneously?

For now, I’m thinking:

QuickBooks: Business income/expenses in USD (the bookkeeping system of record)
Beancount: Crypto tracking only (cost basis, per-wallet pools, tax reporting)
Tax season: Export crypto data from Beancount, merge with QuickBooks P&L

Has anyone built this kind of hybrid workflow? Or is it asking for reconciliation headaches?

3. Pricing - What do I charge for crypto bookkeeping complexity?

My standard small business bookkeeping rate is $150/month (basic P&L, bank recs, AP/AR). Adding crypto tracking means:

Learning Beancount
Setting up per-wallet account structures
Monthly transaction entry (crypto purchases, transfers, sales)
Tax season Form 8949 generation

That’s easily another 2-3 hours/month of work. Should I charge $250/month for crypto clients? $300/month? What’s the market rate for crypto bookkeeping in 2026?

What I Love About This Community Discussion

The thing that’s clicking for me from this thread:

Tina’s per-wallet account structure is EXACTLY what the IRS requires, and Beancount makes it manageable
Mike’s migration story proves I’m not the only one reconstructing historical data (that’s billable client work!)
Fred’s FIRE perspective shows there’s a market for people who want precision crypto tracking (not just “good enough” TurboTax imports)
Sarah’s questions mirror what my clients are asking (“Do I track holdings? How much historical data?”)

I’m realizing: clients NEED this level of tracking, commercial tools can’t deliver it, and professional bookkeepers who can offer Beancount crypto services have a competitive advantage.

My Learning Plan

Here’s what I’m doing over the next month:

Week 1: Set up Beancount for my own personal crypto holdings (I have a small BTC position)
Week 2: Build the account structure for one pilot client (the graphic designer)
Week 3: Reconstruct her 2024 transactions, generate Form 8949
Week 4: Train on Fava web interface, create client-friendly reports

If this works, I’m going to offer “Crypto Bookkeeping” as a premium service tier. There’s a gap in the market, and Beancount fills it.

A Question for the Group

For those tracking client crypto (not just personal holdings):

How do you handle client confidentiality with plain text files?

With QuickBooks, client data lives in their cloud account with role-based access. With Beancount, I’m editing plain text files on my laptop. Best practices for:

File encryption at rest?
Secure file transmission (client sends me exchange statements)?
Version control without exposing client data to Git hosting?

I’m thinking: local Git repo, encrypted filesystem, no cloud sync. But curious what others are doing.

Thanks for this discussion, everyone. I’m printing out Tina’s original post and Mike’s wallet address metadata tip—this is immediately useful for client work.