Block explorer to ERP: Mapping every step where crypto accounting breaks

The manual crypto accounting workflow has a lot of steps. Each one is a place where data can degrade, get misclassified, or require human intervention that wasn't in anyone's job description.

This piece maps the full workflow — from raw on-chain data to a posted journal entry — with a specific focus on where things go wrong and why.

The Full manual workflow

Prerequisite: Maintain a complete wallet and exchange account listing

Before any transaction data can be pulled, there's a prerequisite that most teams overlook until it causes a problem: you need an accurate, complete listing of every wallet address and exchange account the organization controls.

This sounds obvious. It rarely is actioned in practice.

Wallets and exchange accounts can be spun up in minutes — by engineering for R&D testing, by marketing for promotions, by operations for vendor payments. Without a formal process for registering and tracking each one, the organization quietly accumulates crypto exposure that no one in accounting knows about. By the time you're trying to close the books, you're working from an incomplete picture.

The standard isn't new. Traditional companies maintain a list of every bank account — its purpose, owner, and access controls. Crypto demands the same discipline.

In practice, a wallet is more than just an address. It's an organizing primitive — a human-readable identifier tied to either a self-hosted address or a third-party custodian, with specific signatories and signing arrangements. Each wallet holds one or more Wallet/Asset Pairs: the atomic unit that tells the story of where a specific token lives and why. Those pairs can be tagged with a Role — a user-defined category that reflects how the asset is being used (treasury, operations, custodial holdings, R&D, etc.) — enabling roll-up views that mirror how management actually thinks about the business. This structure isn't just organizational hygiene; it's the foundation for cost basis tracking, tax lot segregation, and restricted asset identification.

Your wallet listing should capture, at minimum:

• Wallet address / account identifier
• Wallet / Asset Pair
• Blockchain or exchange
• Business purpose / Role (e.g., R&D, treasury, payroll, promotions)
• Owning department and custodian
• Access controls (signatories, signing arrangements, key holders)
• Active/inactive status

Without this foundation, everything downstream — transaction pulls, cost basis tracking, reconciliation — is structurally incomplete. Garbage in, garbage out, and in crypto, the garbage is invisible.

For a team without purpose-built infrastructure, closing a single month of crypto activity typically looks like this:

Step 1: Pull transaction data from each source

• Export CSVs from each centralized exchange (Coinbase, Kraken, Binance, etc.)
• Use a block explorer (Etherscan, Solscan, etc.) to pull wallet-level transaction history
• For DeFi positions, manually check each protocol's interface or subgraph for activity records
• Consolidate into a master spreadsheet, de-duplicating transfers that appear on both sides
• End-of-month balance snapshots. Teams manually capture screenshots of crypto balances across exchanges, protocols, and self-custody wallets to support period-end reconciliations between internal records and external sources.

Where it breaks: Exchange CSV formats are inconsistent. Block explorers show raw transaction data, not accounting-ready records. DeFi protocols have no standardized export format. Multi-hop transactions appear as separate line items that must be manually linked. And as mentioned in the prerequistite, if your list of wallets and exchange accounts are incomplete, then you potentially have gaps in your transaction data.

Step 2: Identify and classify each transaction

• Assign a transaction type to each line: purchase, sale, transfer, staking reward, fee, DeFi event, etc.
• Identify the counterparty (internal wallet, external exchange, unknown)
• Flag transactions that don't fit a standard category for manual review

Where it breaks: DeFi transactions — LP deposits, yield claims, bridge transfers, token swaps — don't map cleanly to standard categories. A single Uniswap LP deposit can generate multiple taxable events that a spreadsheet treats as one line item. Internal wallet transfers must be identified and excluded from gain/loss calculations, but require knowing all your own wallet addresses.

Step 3: Calculate cost basis for each disposal

• For each sale, swap, or transfer out, identify the originating lot(s)
• Apply the selected cost basis method (FIFO, HIFO, specific identification)
• Calculate the cost basis, proceeds, and realized gain or loss

Where it breaks: Cost basis tracking requires a continuous ledger that spans every acquisition, including staking rewards, airdrops, and fork-received assets. A spreadsheet can handle this for simple portfolios, but breaks quickly when assets move between wallets, get wrapped or unwrapped, or pass through DeFi protocols that alter the token structure.

Step 4: Fair value and impairment

Apply fair value measurement

• For assets in scope under ASU 2023-08, pull the fair value at the measurement date
• Source prices from a principal market per ASC 820
• Update carrying values and calculate the period-end fair value adjustment

Where it breaks: Price sourcing at scale requires either manual lookup for each asset at each measurement date, or a data feed that doesn't always cover illiquid or long-tail tokens. For DeFi positions — LP tokens, staking derivatives — "fair value" requires additional calculation beyond spot price.

Impairment of indefinite-lived intangible assets

Under legacy U.S. GAAP (pre-ASC 350-60), crypto assets held by most entities were classified as indefinite-lived intangible assets — and that classification carries a one-way ratchet: you can write down, but you can never write up.

Accounting teams are required to assess for impairment at least annually, though best practice — and what most auditors expect — is monthly. The test is straightforward in concept: if the fair value of the asset drops below its carrying value at any point during the period, an impairment loss must be recognized immediately. You can't wait for recovery. You can't average across the month.

In practice, this means teams are manually pulling intraday or daily low prices, comparing them against cost basis records, calculating impairment exposure, and journaling entries — every month, for every asset held. At scale, across a portfolio of tokens with volatile price histories, this becomes a significant operational burden.

Where it breaks: impairment tracking across hundreds of lots is a manual, error-prone grind.

Under ASC 350-60, every impaired lot must be continuously assessed against the lowest intraday price observed during the period. For teams managing this in a spreadsheet, that means manually pulling the monthly low, scanning each lot individually, and calculating whether additional impairment is required. With tens of lots this is tedious. With hundreds, it becomes nearly impossible to do accurately — and the risk of a missed or miscalculated lot grows with every acquisition.

Step 5: Format journal entries for the ERP

• Convert the transaction data into debit/credit journal entries
• Map accounts to your chart of accounts
• Format for import into NetSuite, QuickBooks, Sage, or your ERP of choice
• Upload and post

Where it breaks: Every ERP has a different import format. The mapping from crypto transaction types to GL accounts requires judgment that isn't captured in the spreadsheet. Journal entries need to match the subledger balance — which may itself contain errors accumulated across prior steps.

ERP blind spot: ERPs don't speak crypto

Successfully importing dollar-denominated transaction values into your ERP feels like a win — and it is, partially. But there's a critical gap that surfaces immediately after: your ERP has no concept of the underlying crypto asset quantity.

Most ERPs are built around whole or simple decimal currencies. They were never designed to track assets like ETH, which is divisible to 18 decimal places, or the dozens of other tokens with similarly granular precision. The ERP knows you recorded $4,200. It has no idea whether that represents 1 ETH, 0.5 ETH, or 1,000,000 DOGE.

This matters for several reasons:

• Inventory tracking — you cannot rely on your ERP to tell you how much of any given asset you actually hold
• Cost basis calculations — lot-level tracking requires quantity precision your ERP cannot maintain
• Audit support — auditors will ask for a crypto inventory schedule; your ERP cannot produce one

The workaround most teams resort to is a manual spreadsheet — a shadow ledger running alongside the ERP, tracking crypto quantities, lot layers, and cost basis outside the system of record. It works until it doesn't: reconciling the spreadsheet to the ERP becomes its own month-end close task, and the risk of drift between the two is constant.

Step 6: Reconcile

• Compare the subledger balance (or spreadsheet total) to the actual wallet and exchange balances
• Investigate and resolve any discrepancies
• Document the reconciliation

Where it breaks: Any error in Steps 1–5 surfaces here. Timing differences between on-chain settlement and exchange reporting create apparent discrepancies. Missing transactions — especially small gas fees, dust amounts, or failed transactions — can leave unexplained residuals that take hours to trace.

Where the biggest losses occur

Not all steps are equally painful. The highest-impact failure points are:

DeFi classification (Step 2): Complex on-chain activity is where manual workflows break most completely. A team can handle simple buy/sell/transfer workflows reasonably well. DeFi is where the manual process becomes unsustainable — not because of volume, but because of complexity.

Cost basis continuity (Step 3): Errors here compound over time. A misclassified transfer in January creates an incorrect cost basis that distorts every subsequent gain/loss calculation through the rest of the year. By year-end, the error is often unrecoverable without reconstructing the entire ledger.

ERP formatting (Step 5): The last mile is often the most manual. Even teams with reasonable classification and cost basis processes frequently hit a wall at journal entry formatting — spending hours reformatting data that a purpose-built tool would generate automatically.

What tools with coverage gaps do to this workflow

Tools that claim broad coverage but fail on specific transaction types don't eliminate this workflow — they push it downstream.

If a tool can't handle a Curve LP deposit, a staking derivative claim, or a cross-chain bridge transfer, those transactions fall out of the automated workflow and land on someone's desk for manual handling. The more complex your on-chain activity, the larger that residual pile becomes.

The manual workflow described above doesn't disappear. It just shrinks to the transactions the tool can't handle — and those are, by definition, the hardest ones.

The benchmark

A team with the right infrastructure should be able to close the gap between "raw on-chain data" and "posted journal entries" in five business days or less, with 95%+ of transactions auto-classified and no manual steps between the subledger and the ERP.

If your current workflow requires human intervention at Steps 1, 2, 3, 4 and 5 — and reconciliation reveals errors at Step 6 — you're not dealing with a staffing problem. You're dealing with an infrastructure problem.

Frequently asked questions

What is crypto accounting automation?

Crypto accounting automation replaces manual steps in the month-end close with software that handles data ingestion, transaction classification, cost basis calculation, fair value measurement, and journal entry generation. The goal is to get from raw on-chain data to posted ERP entries with minimal human intervention and a complete audit trail.

Why is manual crypto accounting a problem?

Manual crypto accounting breaks at nearly every step. Exchange CSV formats are inconsistent, DeFi transactions don't map to standard categories, cost basis errors compound forward across the year, and journal entry formatting requires manual reformatting for every ERP. Each step introduces risk that surfaces at reconciliation — or worse, at audit.

How does crypto accounting automation handle DeFi transactions?

DeFi is where manual workflows fail most completely. A single LP deposit or yield claim can generate multiple taxable events that a spreadsheet treats as one line item. Purpose-built crypto accounting automation identifies each sub-event, applies the correct classification, and maintains continuous cost basis tracking — without requiring manual intervention for every complex on-chain transaction.

Why can't I just use my ERP for crypto accounting?

ERPs don't track underlying crypto asset quantities. They record dollar-denominated values but have no concept of lot-level holdings, decimal precision for tokens like ETH, or cost basis by asset. That forces most teams to run a manual shadow ledger alongside the ERP — a reconciliation risk that grows every month and can't be eliminated without purpose-built crypto accounting infrastructure.

CoinTracker Enterprise automates the full workflow from data ingestion to ERP journal entry — including deep DeFi coverage, cost basis calculation, ASU 2023-08 fair value measurement, Impairment on Indefinite-lived Intangible Assets and direct integration with NetSuite, QuickBooks, and Sage.