The 1099-DA Reconciliation Gap: Why Broker Reporting Captures Only Half of Crypto Activity
When the first wave of Form 1099-DA reporting hit taxpayers, the early conversations were predictable. Clients called their accountants with screenshots, totals circled in red, and a single question that sounded almost too simple for how anxious it felt.
"Why does my 1099-DA show $500K when I know I did way more than that?"
It's tempting to treat this as normal first-year friction—a little education, a few FAQs, and everyone moves on. But the real problem isn't confusion about a new form. The real problem is that 1099-DA is structurally partial, and the gap between what a broker reports and what your client actually did on-chain is often enormous.
We've seen this pattern repeatedly: a client has $500K of gross proceeds on their exchange statement, but $950K of total activity across exchange trading, self-custody wallets, Solana DeFi positions, and validator staking rewards. In this real-world example from a multi-entity client, broker reporting captured about 53% of what matters. The missing 47% isn't optional—it's taxable activity that requires classification and cost basis work.
If you're serving crypto clients at any meaningful scale, this isn't a one-off situation. It's your new operational reality, and it's showing up in your inbox right now.
With the April 15 filing deadline approaching, you have less than 60 days to close this reconciliation gap. The work that used to be "we'll clean it up later" is now the work you have to do first—before you can even start to advise.
What 1099-DA actually reports (and what it doesn't)
For the 2025 tax year filed in 2026, 1099-DA covers broker-facilitated transactions. It's a report of gross proceeds for activity that occurred on that broker's platform. It doesn't try to be a complete ledger of your client's crypto life.
In practice, this means Coinbase reports Coinbase transactions, Binance reports Binance transactions, and any activity outside those walled gardens is invisible to broker reporting. Self-custody wallet operations? Not reported. DeFi protocol activity? Not reported. Validator and staking operations? Only if the broker facilitates them directly.
That's not a bug. That's the design boundary.
The problem is your clients don't live inside design boundaries.
A modern crypto client often spans five categories of activity:
- Exchange transactions
- Self-custody wallet operations
- DeFi protocol positions
- Validator or staking rewards
- Wrapped token conversions and mechanical token movements
Only the first category is reliably captured by broker 1099-DA reporting today.
The reconciliation question becomes unavoidable. When the IRS has third-party broker totals and your return includes additional activity or different classifications, you need to show your work. Not with vibes, not with "the software says so," but with a defensible reconciliation that ties broker-reported activity to complete on-chain activity.
The reconciliation gap isn't "more data"—it's different data
In our conversations with mid-sized accounting firms, we commonly hear about crypto clients using an average of 4-6 platforms: exchanges plus wallets plus DeFi plus staking or validator exposure. For a regional firm with 50 crypto clients, that's 200-300 unique data sources.
But the real pain isn't the count. The pain is that each source speaks a different dialect.
Broker exports are tidy, even when they're incomplete. Blockchain transactions are not tidy. They include instruction sets, account creations, rent deposits, program calls, and protocol-specific state changes. The economic event you care about—the actual trade or transfer—is often buried inside mechanical steps that are required to make the protocol work.
If your tooling treats blockchains like bank feeds, it will fail. And it will fail in ways that show up as reconciliation headaches, cost basis drift, and inconsistent classifications across clients.
This is why 1099-DA isn't just a compliance event. It's an infrastructure event.
Why generic aggregation tools break (even when they look "close enough")
Most generic crypto aggregation tools—tools built primarily for retail tax filing—work well for the simplest shape of crypto activity: buy an asset, hold it, sell it, record the gain.
They break down when activity is protocol-defined, off-wallet, or chain-specific.
Let's walk through three common examples you're seeing in client files right now.
Example 1: Solana swaps, rent deposits, and the difference between mechanics and economics
Your client swaps 10 SOL for USDC via Jupiter. If you only look at net balance changes, you see what you expect: 10 SOL out, USDC in.
But the chain-level transaction often includes wrapped SOL account creation, rent deposits that are refundable, transfers into and out of program accounts, creation of new token accounts, closure of temporary accounts, and rent refunds.
A generic aggregator that doesn't parse Solana instruction-level mechanics can easily treat rent deposits as economic spend—folding them into cost basis or treating them as additional outflows. A protocol-aware parser separates what's refundable, what's a fee, what's swap consideration, and what's purely mechanical.
The difference matters because cost basis errors are cumulative. If a tool is "only off by a little" on each complex transaction, it doesn't stay a little over time.
And when an auditor questions your client's cost basis three years from now, "the software made a mistake" isn't a defense that protects your firm's reputation.
Solana isn't a niche edge case. It's a mainstream source of exactly the kind of activity that broker reporting doesn't see.
Example 2: DeFi positions that are off-wallet but still on the balance sheet
Your client deposits 10,000 USDC into a lending protocol like Aave and receives a receipt token (aUSDC). The underlying value sits in a protocol contract. Interest accrues continuously. Mark-to-market changes happen without a neat on-chain "interest payment" transaction.
Wallet-only tools often track what the wallet holds—the receipt token count—not the underlying position value plus accrued interest. For financial statements and serious reconciliation work, you need the underlying economics.
That requires querying protocol state, not just wallet balance deltas.
This is the visibility gap that hits you during review season. Your client insists the funds are "in Aave," the wallet shows some receipt token, and the tool output looks incomplete. None of this is fraud or confusion—it's simply the mismatch between generic aggregation and protocol-defined finance.
Example 3: Validator rewards that demand classification, not just counting
Consider a Solana validator earning 150 SOL per epoch (roughly $35,000 at recent prices). A generic tool may capture "150 SOL received" and stop there. But compliance requires more than counting. Classification depends on jurisdiction, reward components have different tax characteristics, and the documentation burden rises fast when operations are international.
Even in a US-only context, staking and validator activity introduces exactly the type of question that 1099-DA doesn't answer. The broker form captures broker activity. The chain captures everything else. Your work papers have to reconcile both.
The April 15 choice point for your firm
This is where you make a decision—sometimes without realizing it.
Path one is the default path. Manual reconciliation. Spreadsheets with 47 tabs. Partner time spent reconciling broker statements to blockchain data at $400/hour. The familiar April crunch where a client mentions their Solana validator rewards on April 10th, and suddenly you're researching epoch mechanics at 11 PM.
Path two is a deliberate investment in protocol-aware infrastructure. Automated reconciliation from blockchain to broker report to ledger. Chain-specific parsing so the mechanical steps don't pollute the economics. Standardized work paper outputs that an audit team can follow.
The key point is leverage.
In our conversations with mid-sized firms, we commonly hear estimates of 3-5 hours per crypto client spent on reconciliation work. With 50 clients, that's 150-250 hours spent on work clients never see—and rarely value.
If you invest once in infrastructure, you amortize it across your client base, standardize methodology, and move partner time back to advisory, planning, risk mitigation, and higher-trust conversations.
Imagine redirecting those 200 hours to the work you actually got into accounting for: strategic tax planning conversations, entity structure optimization, helping clients think through their staking operations from a tax perspective. The work clients remember, refer you for, and pay premium fees for.
And this choice point matters beyond this filing season.
Why this gets harder in 2026 and beyond
For 2025 reporting filed in 2026, cost basis is deferred in many cases, and 1099-DA focuses on gross proceeds. But the direction of travel is clear. As cost basis reporting becomes mandatory, historical reconstruction becomes a core requirement.
This shift to mandatory cost basis reporting has two consequences for your firm.
First, you can't fix cost basis at the end if your transaction parsing was wrong at the beginning. Protocol-aware tracking isn't a luxury feature—it's the foundation of defensible lots.
Second, enforcement dynamics change. The industry shifts from voluntary self-reporting toward a world where the IRS has third-party totals. Mismatches trigger attention. Your ability to defend a return becomes inseparable from your ability to show a complete reconciliation: broker-reported activity plus off-exchange documented activity equals complete taxable activity, with lineage back to the blockchain source.
In other words, "we used a tool" isn't a defense. A repeatable methodology, audit trail, and source documentation are the defense.
What protocol-aware infrastructure actually means in practice
"Protocol-aware" can sound like marketing language until you define it operationally.
In practice, protocol-aware infrastructure means four things—and more importantly, what they do for your firm.
Chain-specific parsing—not just balance changes pulled from explorers. On Solana, that's instruction-level parsing that separates rent, account creation, and mechanical program steps from economic transfers. On Ethereum, that means separating fee components and capturing validator and MEV-related mechanics correctly. On Cosmos-style chains, it means handling reward accrual dynamics that aren't cleanly represented as simple inflows. Which means you can trust your cost basis calculations hold up under audit scrutiny.
Off-wallet position tracking—not just wallet balances. If value is sitting in a protocol contract, the system needs to query protocol state directly and translate that into positions your work papers can support. Which means you see the complete financial picture, not just what sits in custody wallets.
Multi-jurisdiction classification capability. Global operations aren't an edge case anymore. Rule sets and reporting thresholds differ across jurisdictions, and the system needs to support classification logic that can be applied consistently. Which means you can serve international clients without building custom methodology for each jurisdiction.
A complete audit trail that preserves lineage from transaction hash to parsed data to classification logic to valuation methodology to journal entry. The question an auditor asks isn't "did you export a CSV"—it's "can I trace this number back to a source, and do I understand why you classified it this way." Which means you can answer an auditor's questions in minutes, not hours of scrambling through files.
At NODE40's scale—processing approximately 500,000 Solana accounts alone—edge cases aren't rare events. They're the daily workload. That's why protocol-aware infrastructure becomes a moat. The hard part isn't computing a gain. The hard part is recognizing what the transaction actually is, consistently, across millions of transactions and hundreds of thousands of accounts.
A practical way to approach implementation at your firm
If you're reading this with April 15 in mind, the most useful next step isn't to debate theory. It's to evaluate your current client mix and your current reconciliation posture.
Start with your client reality. How many clients have crypto exposure, and what's the shape of that exposure? Is it exchange-only, or do they have self-custody wallets? Are they active in DeFi? Do they have staking, validator exposure, or protocol incentive programs?
Then look at your infrastructure reality. Can you reconcile broker-reported totals against complete on-chain activity in a way you can defend? Can you see off-wallet positions? Can you generate standardized work papers that don't change method from client to client?
If you don't like the answers, set a short timeline and execute.
A workable approach looks like this: Use the next week to assess activity and identify gaps. Use the following 2-3 weeks to implement protocol-aware infrastructure and run parallel reconciliation to validate accuracy. Then use the final stretch before April 15 to produce work papers and file with complete audit trails.
The specific dates will vary by firm, but the underlying point doesn't. Waiting until April to solve reconciliation is how you lose margin, lose confidence, and lose clients.
Common questions we hear from firms
"Isn't it too late to switch tools with April 15 approaching?"
Implementation typically takes 1-2 weeks including data validation. Most firms run NODE40 in parallel with their existing process for the first few clients to validate accuracy before fully transitioning. You're not switching everything overnight—you're validating on test cases first.
"We're already using [generic tool]. Can NODE40 work alongside it?"
Yes. Many firms use their existing tools for simple exchange-only clients and NODE40 for clients with complex activity—DeFi, staking, multi-chain operations. You don't have to switch everything at once. Start with your most complex clients where the reconciliation gap is largest.
"What does implementation actually involve on our end?"
We handle the technical setup. You provide wallet addresses and API connections. We validate reconciliation accuracy on 2-3 test clients before you use it for filing. No massive IT project, no months-long rollout.
Closing: The gap is now the work
The 1099-DA reconciliation gap isn't going away. It becomes more important as cost basis reporting ramps and as third-party reporting becomes the norm.
You have two options.
You can continue to reconcile manually each season, burn partner time on work that should be systematized, and accept a higher audit risk posture caused by inconsistent methodology.
Or you can invest in protocol-aware infrastructure once, apply it across your client base, standardize work papers, and shift your team back toward high-value advisory work.
NODE40 exists for the parts that generic aggregation tools can't do reliably, especially at scale: instruction-level parsing, off-wallet DeFi position tracking, multi-jurisdiction-aware classification support, and audit trails that preserve blockchain-to-ledger lineage.
Take the next step
If you're looking at your client list and recognizing this reconciliation gap, let's talk through what protocol-aware infrastructure looks like for your specific firm and client mix.
On a 30-minute call, we'll:
- Review your current client profile and reconciliation approach
- Identify specific gaps in your current tooling
- Show you what automated blockchain-to-broker-to-ledger reconciliation looks like in practice
- Map out a realistic implementation timeline (even with April 15 approaching)
No sales pitch, no pressure—just a practical conversation about whether NODE40's infrastructure makes sense for your firm.
Schedule time with Perry Woodin: https://www.node40.com/meeting-perry/
Or if you want to see the technical details first, reach out for our accounting firm technical brief that walks through protocol-aware parsing, off-wallet position tracking, and audit trail documentation.