Why Mining Revenue Needed Its Own Playbook

Mining revenue looks simple — machines run, coins arrive — until you audit it. Rewards accrue to pool accounts before wallets, payouts lag blocks by days, fees net invisibly inside pool statements, hash rate moves between pools mid-month, and hosting contracts blur the line between service income and mining income. The AICPA’s August 2026 practice-aid update answers with structured example procedures for the two dominant models: mining pool participants and data center hosts. This guide turns that chapter into fieldwork.

Pair with DeFi Smart Contract Auditing Standards, DeFi Audit Scope Gaps, Cryptocurrency Tax Reporting, and Stablecoin Issuer Audit.

Model 1: Mining Pool Participants

The participant contributes hash rate to a pool operator; the pool finds blocks and allocates rewards net of fees. Audit focus: entitlement, measurement, and cut-off.

Revenue trigger. Recognition follows entitlement under the pool’s documented allocation rules — accepted shares, found blocks, or payout thresholds — measured at fair value when the right to the reward is established. Cash receipt into the participant’s wallet is a settlement event, not the recognition event. Provisions sitting in pool balances at period-end are receivables to test, not “not yet earned.”

Pool-statement reconciliation. Build the bridge every period: opening pool balance + allocated rewards per pool statements − payouts received − fees withheld = closing pool balance, tied to the GL and to on-chain wallet receipts. Investigate every break — unallocated shares, stale payout addresses, and fee-rate changes mid-period are the classic causes. Confirm fee schedules against the signed pool agreement, not the dashboard default, and re-perform the math on a sample month end to end.

Hash-rate allocation evidence. Tie reported hash rate to the physical fleet: deployed miner inventory (make, model, serial/asset tag), uptime logs, pool-side worker statistics, and power consumption that reconciles — roughly — to the claimed hash rate. A facility drawing power for 80% of its fleet cannot have earned at 100% allocation all month. Cross-check pool switches mid-period; allocation follows the hash rate and its timestamps, not the month-end pool.

Cut-off testing. Blocks do not respect period ends. Select payouts straddling year-end, trace each back to the block height and timestamp of the underlying reward, and verify the allocation period matches the block date — not the payout date. Test both directions: rewards earned pre-cutoff but paid after (accrue), and payouts received post-cutoff for pre-cutoff blocks (no double-count).

Contract review checklist. Pool agreement version in force during the period; allocation methodology and any changes with effective dates; fee structure (percentage, withdrawal fees, inactivity terms); payout thresholds and timing; who holds keys to the payout wallet; termination and final-settlement terms. File the version that governed this period — pools update terms silently, and last year’s agreement proves nothing about this year’s allocations.

Model 2: Data Center Hosts

The host sells capacity — space, power, cooling, maintenance — and may also self-mine on the same racks. The audit problem is separation: service revenue versus mining revenue, with shared costs allocated, not guessed.

Service revenue vs mining revenue. Hosting fees accrue as services are performed (typically monthly per contract terms); mining rewards follow the pool-participant model above. For mixed operations, the general ledger must keep them distinct from the first journal entry — commingled “crypto income” forces a reconstruction that neither the auditor nor the tax return can rely on. Confirm the distinction ties to Revenue Recognition performance-obligation analysis and to tax positions — see Crypto Tax Reporting.

Cost allocation that survives testing. Shared power, the dominant cost, must split between hosted clients and own mining on a documented, consistently applied basis — metered draw where available, contracted capacity ratios where not, with variance investigation when metered and billed diverge. Depreciation follows asset assignment: client-owned rigs the host merely houses are not the host’s depreciable assets, while host-owned fleet is. Maintenance labor splits by work-order records, not estimates. Document the methodology memo once, apply it monthly, and retain the support — see Fixed Assets.

Host-specific contract review. Hosting agreements (term, pricing per kWh vs flat, uptime SLAs and credits, curtailment rights, who bears power-price volatility), customer-owned asset custody terms, and termination/data-return provisions. Curtailment clauses deserve special attention: if the host can throttle miners during peak pricing, verify uptime credits were actually issued — unissued credits are understated liabilities.

Pool Participant vs Host: Recognition Touchpoints Compared

Touchpoint Pool participant Data center host
Revenue trigger Entitlement under pool rules (shares/blocks) Service performed (hosting); block entitlement (own mining)
Measurement Fair value at entitlement point Contract rates for hosting; fair value for mined coins
Cut-off risk Allocation period vs payout date Service-period cut-off + miner-side block cut-off
Key reconciliation Pool statement → GL → on-chain wallet Client billings → power meters → GL; fleet-to-hash-rate tie-out
Contract focus Allocation methodology, fees, payout terms Hosting terms, curtailment, custody, uptime SLAs
Cost question Mostly pool fees and power Power split, depreciation assignment, labor allocation

Quality Management: SAS 146 and 148 on Crypto Engagements

Digital-asset work magnifies every quality risk — novel accounting, volatile measurement, self-custodied evidence, specialist dependence. SAS 146’s quality-management framework applies in full:

  • Engagement-level quality objectives documented up front: what could go wrong on this mining engagement (new pool mid-year? hosting/hosted mix? key-person dependence?) and what resources answer each risk.
  • Competence and specialists. Blockchain analytics, valuation, and IT controls expertise assigned — not “reviewed by someone who owns crypto personally.” Document why the team composition fits the risks.
  • Direction, supervision, and review calibrated to risk. High-judgment areas — allocation methodology changes, impairment of fleet, going-concern where power costs exceed coin value — get partner-level attention with the reasoning recorded, not just the conclusion.
  • Documentation that stands alone. Another experienced auditor should be able to re-perform the pool tie-out, the cut-off test, and the cost allocation from the file alone. Crypto files that read “discussed with management — satisfied” fail this standard on contact.

Pair quality documentation with Q1 Audit Prep and External Audit PBC discipline — the evidence pack that satisfies mining-revenue testing looks like every other good packet: complete, signed, and tied.

Common Findings (Design Procedures Around These)

  • Unreconciled pool balances carried for months — treat any unreconciled pool account like unreconciled cash: investigate, don’t roll forward.
  • Fee changes missed — pool raises fees mid-year; revenue and expense both misstated until someone reads the notice. Calendar fee-schedule confirmation quarterly.
  • Wallet control gaps — payout addresses changed without dual approval; keys held by departed staff. Test address-change logs against HR leaver lists.
  • Host/client hash-rate confusion — hosted rigs counted in the host’s production metrics, inflating both revenue and asset base. Fleet-to-ledger mapping is the control.
  • Power-cost mismatches — billed power vs metered draw diverging without investigation; the difference is either unbilled usage or some else’s miners on your meter.

FAQ

Should pool rewards be tested on-chain or from pool statements?

Both, tied together: pool statements establish the allocation, on-chain records establish receipt, and the bridge between them is the audit evidence. Either leg alone leaves the assertion half-supported.

How do auditors handle rapidly changing pool terms?

Freeze the agreement version in force for each period tested, confirm mid-period changes directly with the operator, and re-perform one full allocation cycle under the new terms before relying on them.

Next Steps

  1. Classify each mining arrangement as participant, host, or mixed — then apply the corresponding procedure set; mixed operations need both, kept separate from the first journal.
  2. Build the monthly pool-to-GL-to-wallet reconciliation and the power-to-hash-rate tie-out into the close calendar now, not at year-end.
  3. Document the SAS 146 quality objectives for the engagement before fieldwork starts, with specialist assignments and review milestones named.