Crypto Payment Journal Entries: A Complete Chart of Accounts and Six Standard JEs for Merchants

I’ve seen the same three bookkeeping mistakes across a dozen merchants this year. They all believe they’re doing it right until their CPA opens the file at year-end.
One: they dump every crypto receipt into a single “Crypto” account. By December the ledger is a soup of BTC, ETH, USDC, and USDT, and no one can produce a per-asset reconciliation. The CPA bills $4,000 to untangle it.
Two: they record the dollar amount but throw away the transaction hash. When an auditor asks “prove this $12,400 receipt actually happened,” there’s a Stripe-style receipt PDF but no on-chain proof. That receipt is worth less than the merchant thinks.
Three: a customer asks for a refund, the merchant sends a new crypto transfer, and books it as an expense. Three months later sales tax filings don’t reconcile because the sale was never reversed.
None of these is hard to avoid. You need a chart of accounts that doesn’t pool assets, a small set of standardized journal entries, and the habit of capturing three pieces of data at every receipt. Below: the chart of accounts, six standard journal entries (receipt, fair-value remeasurement, disposition, refund, chargeback dispute, gas fee), and the monthly three-way reconciliation that ties on-chain data back to your general ledger.
If you haven’t read the companion piece on ASU 2023-08, do that first. The entries below assume you’ve already picked a measurement basis for each asset class. Short version: BTC and ETH go to fair-value-through-net-income. USDC and USDT typically sit at cost.
A minimum viable chart of accounts
You need one separate account per distinct crypto asset. Not “Crypto.” Not “Digital Assets.” A separate ledger account for BTC, ETH, USDC-ERC20, USDC-TRC20, USDT-ERC20, USDT-TRC20, and any other token you actually receive. The disclosure rules in ASU 2023-08 (codified at ASC 350-60-50-1 through 50-3) require per-asset detail for any significant holding. Your auditor will not accept commingling at year-end.

Here’s a starter chart of accounts you can adapt. The numbering follows a common small-business GAAP convention (1xxx Assets, 2xxx Liabilities, 4xxx Revenue, 5xxx COGS, 7xxx Other Income, 9xxx Other Expense). Your accountant may renumber. The structure is what matters.
| Account # | Account Name | Type | Notes |
|---|---|---|---|
| 1110 | Cash — Operating | Asset | Your normal USD bank account. |
| 1210 | Digital Asset — BTC | Asset (intangible) | Fair value under ASC 350-60. |
| 1211 | Digital Asset — ETH | Asset (intangible) | Fair value under ASC 350-60. |
| 1220 | Digital Asset — USDC (ERC-20) | Asset | Stablecoin; cost-less-impairment or financial asset; consult CPA. |
| 1221 | Digital Asset — USDC (TRC-20) | Asset | Separate from ERC-20 — different chain, different reconciliation. |
| 1230 | Digital Asset — USDT (ERC-20) | Asset | Same logic as USDC. |
| 1231 | Digital Asset — USDT (TRC-20) | Asset | Separate per chain. |
| 1290 | Crypto Suspense / Disputes | Asset (contra) | Holding account during chargeback disputes. |
| 2210 | Sales Tax Payable | Liability | Always in USD. |
| 2310 | Customer Refunds Payable | Liability | Refund owed but not yet sent. |
| 4100 | Sales Revenue | Revenue | Standard. |
| 4110 | Sales Returns & Allowances | Contra-revenue | Standard. |
| 5310 | Cost of Revenue — Network Fees | COGS | Gas / network fees on accepted payments. |
| 7210 | Unrealized Gain on Digital Assets | Other income | From quarterly remeasurement. |
| 7220 | Realized Gain on Disposition | Other income | From sale or trade. |
| 9210 | Unrealized Loss on Digital Assets | Other expense | Mirror of 7210. |
| 9220 | Realized Loss on Disposition | Other expense | Mirror of 7220. |
| 9310 | Bad Debt — Chargeback Losses | Other expense | When a dispute is lost. |
That’s eighteen accounts. You can run a working crypto-accepting business on this. Add more granularity (separate gain/loss accounts per asset, separate revenue accounts per product line) only when you have a real reason.
The three numbers to capture at every receipt
Every journal entry below assumes you have three pieces of data for every payment received:
- USD fair market value at the block timestamp. Not at “the time the email confirmation hit your inbox.” Block timestamp.
- Transaction hash. The 64-character hex string that uniquely identifies the on-chain transaction. Without this, you cannot prove receipt.
- Receiving wallet address. The address that received the funds. This proves the asset is yours, not someone else’s that you’re holding.
If your payment integration doesn’t expose these via API or CSV, switch to one that does. Non-custodial gateways that settle to your own wallet (Aurpay is one example) usually expose the tx hash and block timestamp through a reconciliation endpoint or admin CSV. If your gateway can’t produce this data, your books are sitting on quicksand.
JE 1: Receive a USDC payment
Customer pays 1,000 USDC for a $1,000 sale. Sales tax is 8% ($80) included in the total, so the breakdown is $920 revenue plus $80 sales tax.
Transaction details to record on the supporting workpaper: tx hash 0xabc…, block timestamp 2026-05-17 14:23:11 UTC, receiving wallet 0x123…, USDC contract address 0xA0b8… (ERC-20).
| Account | DR | CR |
|---|---|---|
| 1220 Digital Asset — USDC (ERC-20) | $1,000 | |
| 4100 Sales Revenue | $920 | |
| 2210 Sales Tax Payable | $80 |
Notice what’s happening. The USDC sits on the balance sheet at $1,000. Sales tax payable is in dollars, not crypto, because every state I know of expects the tax remitted in USD regardless of how the customer paid. No revaluation question yet. USDC is not in ASU 2023-08 scope.
JE 2: Receive a BTC payment, then remeasure at quarter-end
Customer pays 0.01 BTC for a $1,000 sale (BTC = $100,000 at block timestamp). Sales tax 8% = $80, revenue $920.
JE 2a — at receipt:
| Account | DR | CR |
|---|---|---|
| 1210 Digital Asset — BTC | $1,000 | |
| 4100 Sales Revenue | $920 | |
| 2210 Sales Tax Payable | $80 |
You record the BTC at fair value at the moment of receipt — that’s your initial cost basis under ASC 350-60.
JE 2b — quarter end, BTC has risen to $120,000:
Your 0.01 BTC is now worth $1,200. The $200 increase is unrealized but ASU 2023-08 requires you to put it through net income.
| Account | DR | CR |
|---|---|---|
| 1210 Digital Asset — BTC | $200 | |
| 7210 Unrealized Gain on Digital Assets | $200 |
If BTC had dropped to $80,000, the entry flips: DR 9210 Unrealized Loss $200 / CR 1210 BTC $200. Same logic in either direction — fair value through net income, no impairment-only floor like the old model.
Pick a fair value methodology and write it down: which exchange’s price you use, and how you handle gaps. Apply it the same way every period. ASC 350-60-30-1 directs initial measurement at fair value. Subsequent measurement at ASC 350-60-35-1 references the ASC 820 framework. For most merchants this means a major spot exchange’s mid-price at the measurement instant, recorded in writing.
JE 3: Convert BTC to USDC (disposition with gain)
A month later you sell the 0.01 BTC (now carried at $1,200 after the quarter-end remeasurement) for 1,300 USDC. The dollar value increased from $1,200 to $1,300 between the remeasurement and the conversion.
| Account | DR | CR |
|---|---|---|
| 1220 Digital Asset — USDC (ERC-20) | $1,300 | |
| 1210 Digital Asset — BTC | $1,200 | |
| 7220 Realized Gain on Disposition | $100 |
The $100 gain is realized, distinct from the unrealized $200 that already hit net income at quarter-end. For disclosure under ASC 350-60-50, you’ll separate realized and unrealized on the year-end reconciliation. Your bookkeeping needs to track which is which.
For US federal tax purposes, this is a separate calculation. Tax basis was $1,000 (the original cost). The realized gain for tax is $300 (sale proceeds $1,300 minus basis $1,000). Book and tax diverge here; your tax preparer will handle the reconciliation. Don’t try to make the book accounts match the tax calculation — that way lies madness.
JE 4: Refund a customer
Customer who paid 1,000 USDC in JE 1 wants a refund a week later. The original sale never reverses on-chain — crypto transactions are not refundable in the way card payments are. You must send a new transaction.
Say USDC is still at $1.0001 — effectively flat — and you send back 1,000 USDC.
JE 4a — reverse the original sale:
| Account | DR | CR |
|---|---|---|
| 4110 Sales Returns & Allowances | $920 | |
| 2210 Sales Tax Payable | $80 | |
| 2310 Customer Refunds Payable | $1,000 |
Sales tax payable gets debited because you no longer owe the state that $80. Most states let you claim back the tax remitted on a returned sale, either as a credit on the next return or via amendment. The mechanics vary by state, and how well your sales tax software automates this matters. If you handle returns at any real volume, check your state’s department of revenue guidance or talk to a sales tax preparer.
JE 4b — send the refund on-chain:
| Account | DR | CR |
|---|---|---|
| 2310 Customer Refunds Payable | $1,000 | |
| 1220 Digital Asset — USDC (ERC-20) | $1,000 |
Two entries. One reverses the sale and creates a liability. The second extinguishes the liability when you actually move the asset. Don’t combine them. The gap between deciding to refund and actually sending can be hours or days, and the period-end picture matters.
If you refund in BTC and BTC has moved between the original sale and the refund, you’ll have an additional realized gain or loss on the BTC disposition. The reverse-sale logic is unchanged; the disposition logic adds on top.
JE 5: Chargeback dispute (the suspense account)
Crypto payments don’t have card-network chargebacks, but you still get disputes. A customer claims the product never arrived. They threaten a fiat-side chargeback if they paid via a hosted checkout that took a card and converted. They claim the wallet was hacked. While a dispute is open, you may have already refunded informally, or you may be sitting on the funds.
Example: customer paid 500 USDC, disputed the sale, you put the funds in a holding account while you investigate.
JE 5a — move to suspense:
| Account | DR | CR |
|---|---|---|
| 1290 Crypto Suspense / Disputes | $500 | |
| 1220 Digital Asset — USDC (ERC-20) | $500 |
The asset is still yours, just earmarked. Treat this as a balance sheet reclass, not a P&L event.
JE 5b — dispute resolved in your favor:
| Account | DR | CR |
|---|---|---|
| 1220 Digital Asset — USDC (ERC-20) | $500 | |
| 1290 Crypto Suspense / Disputes | $500 |
JE 5c — dispute lost, you refund (and write off):
| Account | DR | CR |
|---|---|---|
| 9310 Bad Debt — Chargeback Losses | $500 | |
| 1290 Crypto Suspense / Disputes | $500 |
And separately, if you sent funds back, JE 4-style entries for the actual on-chain refund.
JE 6: Network fees (gas)
Two situations to keep distinct:
Gas you pay to send a refund or to consolidate funds. This is an operating cost. Book it as Cost of Revenue if it’s directly attributable to a customer transaction, or as a general operating expense if it’s part of treasury operations.
| Account | DR | CR |
|---|---|---|
| 5310 Cost of Revenue — Network Fees | $5.00 | |
| 1211 Digital Asset — ETH (or whichever you paid in) | $5.00 |
Gas the customer pays. If your customer paid the gas to get the transaction onto the chain, you never touched it. Don’t record it. It’s not your asset or your expense.
Gateway service fees. If you used a gateway that takes a percentage (e.g. Aurpay at 0.8%), that’s a fee on the gross receipt. Add a 5320 Payment Processing Fees account to your chart if you don’t already have one. The cleanest treatment for a $1,000 sale with 0.8% gateway fee:
| Account | DR | CR |
|---|---|---|
| 1220 Digital Asset — USDC (received net) | $992 | |
| 5320 Payment Processing Fees | $8 | |
| 4100 Sales Revenue | $920 | |
| 2210 Sales Tax Payable | $80 |
Gross sale, fee recorded separately, net asset received. The principle follows ASC 606: recognize revenue at the gross amount the customer paid, then expense your processor’s fee separately. If you net the fee against revenue, you understate gross sales and you lose payment-processing cost as a metric you can manage.
Three-way reconciliation, monthly
Every month, three sources must agree:
- On-chain transaction list: every inbound and outbound from your wallet addresses, pulled from a block explorer or via direct node access. This is the ground truth — the blockchain doesn’t lie.
- Gateway reconciliation: your payment processor’s transaction list with order IDs, timestamps, and tx hashes. For non-custodial gateways, this is typically an API endpoint or admin CSV export. The hashes must match column 1 of the on-chain list.
- General ledger: your accounting system’s digital asset account balances and per-transaction details. Per-transaction memos should include the tx hash, so each GL entry can be tied back to columns 1 and 2.
If all three agree, your books are clean. If column 1 has transactions not in column 2, your gateway missed something, or someone sent crypto outside the gateway flow — investigate. If column 2 has rows not in column 3, your bookkeeper hasn’t posted recent activity. If column 3 has entries not in columns 1 or 2, someone made a typo.
Running this monthly, in writing, with a sign-off, is what separates an audit you can defend from one you can’t. The companion post in this series on audit trails goes deeper on what your auditor will want as documentation.
Common mistakes I keep seeing
- Pooling assets into one account. Already covered. Don’t.
- Booking the fiat-equivalent at the wrong timestamp. Use the block timestamp, not the email timestamp or the gateway dashboard timestamp. The block is the source of truth.
- Netting gateway fees against revenue. Already covered.
- Forgetting to reverse sales tax on refunds. If you remitted the $80 to the state already, you need to claim it back on the next filing or take a credit. Don’t leave it sitting in Sales Tax Payable forever.
- Treating BTC sitting in your wallet as cash. It’s an intangible asset under ASC 350-60. It gets remeasured. It can move your earnings. It is not cash.
- Sending refunds in BTC after collecting in BTC, weeks later. You realize a gain or loss on the BTC disposition in addition to reversing the sale. This catches people every quarter.
Three questions to bring to your CPA
- Does this chart of accounts give us the per-asset detail we need for ASC 350-60-50 disclosures? Where would you add accounts?
- For our stablecoin holdings, which measurement basis are we using and is it documented in our accounting policies?
- What’s our monthly close calendar going to look like with the three-way reconciliation, and who signs off?
The mechanics aren’t hard. Doing them the same way every month is what keeps year-end cheap.
This article is general information for merchants and finance leads. It is not accounting, tax, or legal advice, and account names, numbering, and treatment will vary based on your specific business, your industry, and your auditor’s interpretation of GAAP. Consult a licensed CPA before applying any of this to your books.

