Content
Quarter-end is three days out. The journals are posted, the trial balance ties, and then the PBC request lands from your external auditor: trace 18 months of crypto transactions from the financial statement line back to the originating wallet activity. You have the summary data. You have the journal entries. What you don't have is a system that can demonstrate, step by step, how that data moved from the on-chain source through categorization, into the subledger, and out to the GL. That gap is exactly what the wrong crypto accounting software creates at the worst possible moment.
PCAOB AS 1105.10A, effective for audits of financial statements for fiscal years beginning on or after December 15, 2025, requires auditors to evaluate the reliability of external electronic information that a company provides as audit evidence. Reliability has to be demonstrated, not assumed. The PCAOB's accompanying Board Policy Statement makes the implication concrete: auditors need to understand the source of the information and the company's process for receiving, maintaining, and processing it, then test either the information itself or the relevant controls.
Layered on top of that, FASB ASU 2023-08 now requires an annual aggregate fair value rollforward for in-scope crypto assets showing additions, disposals, and remeasurement gains and losses. Producing that rollforward is an audit trail problem before it's a reporting problem: the disclosure is aggregate, but the support behind it still has to tie back to transaction-level activity. If your system can't retrieve that history, you're rebuilding it at year-end, and that reconstructed record is precisely what auditors scrutinize.
This guide covers the six criteria that determine whether a transaction reporting platform's audit trail will hold up under external review, how five leading platforms compare, and the control gaps that consistently generate audit findings in crypto-holding companies. By the end, you'll know whether your current setup is audit-ready or whether it's a liability waiting to surface.
What Auditors Actually Check
When an external audit team evaluates the reliability of your transaction records, they aren't reading your platform's feature page. They're asking six questions. The platform you choose needs to answer all of them.
- Source-data completeness across wallets, exchanges, custodians, and chains. PCAOB crypto-asset inspection observations frame completeness as a wallet-inventory control problem: companies may omit crypto assets held at certain distributed ledger addresses. Under ASU 2023-08, an incomplete source registry means the aggregate rollforward, the disaggregated disclosure for significant holdings, and the related-party identification process are all potentially incomplete. Auditors will not sign off on an audit trail that starts from an incomplete inventory.
- Immutable transaction history with timestamps, user activity, and field-level edits. PCAOB AS 1105.10A puts auditor focus on source reliability and controls over how external electronic information is received, maintained, and processed. Timestamps, user activity, and field-level change logs help demonstrate that the transaction record was not silently changed after ingestion.
- ERP sync that preserves subsidiary, chart-of-accounts, and dimension context. When journal entries lose their source transaction context during ERP sync, the auditor can no longer trace from the financial statement line back to wallet activity. Flattened multi-entity structures are the most common break point.
- SOC 1 Type 2 attestation (not just SOC 2). SOC 2 covers controls relevant to security, availability, processing integrity, confidentiality, and privacy. SOC 1 covers controls relevant to user entities' internal control over financial reporting (ICFR). A properly scoped SOC 1 Type 2 report can help user auditors rely on service-organization controls, subject to report scope, period covered, exceptions, and complementary user-entity controls. SOC 2 alone doesn't accomplish the same ICFR purpose.
- Approval workflows, role-based access, and segregation of duties. These are the control activities auditors document when evaluating ICFR design. Without them, the system passes data but doesn't control it.
- Auditor-ready exports: rollforwards, trial balances, daily balance snapshots, drill-down to source. The annual ASU 2023-08 rollforward must show additions, disposals, and remeasurement gains and losses, with adoption-year interim disclosure considerations for SEC registrants per Deloitte's DART implementation guidance. Your system has to produce the supporting data on demand, not rebuild it each quarter.
These six criteria are the evaluation spine for the platform comparison below.
Five Transaction Reporting Platforms Finance Teams Are Evaluating in 2026
The platforms in this comparison appear consistently in RFP shortlists for crypto-holding operating companies. They split into two architectural categories: dedicated crypto subledgers (on-chain ingestion, sync to your existing ERP) and multi-entity general ledgers with a native crypto module. That architectural distinction matters more for deployment fit than any individual feature claim.
One framing note before the comparison: several vendor materials use the phrase "PCAOB certified" or "PCAOB compliant." PCAOB does not certify software platforms. The correct question is whether a vendor's SOC 1 report scope is sufficient for an external auditor to rely on the platform's controls for ICFR purposes. Where that language appears below, it has been reframed accordingly.
Cryptio
Cryptio positions itself as an institutional-grade system of records. It ingests across 150+ blockchains, exchanges, custodians, DeFi protocols, and internal systems using node-based indexing, which captures source data at a layer designed for accounting accuracy, not just display.
For audit trail purposes, the most important credential Cryptio holds is SOC 1 and SOC 2 Type 1 and Type 2 attestation. That combination is a strong ICFR reliance signal in this competitive set. When external auditors review Cryptio as a service organization, a properly scoped SOC 1 report may reduce the amount of direct testing they need to perform over the platform's controls. The internal controls product includes role-based permissions, segregation of duties, and automatic capture of audit activities as audit evidence.
Cryptio's NetSuite integration is well substantiated in its product materials, with subsidiary-aware journals, pre-sync validation, and an enterprise customer list that includes Uniswap, GSR, Paxos, Ramp, and Consensys.
Where the evaluation gets nuanced: Cryptio is priced and scoped for enterprise deployments. Teams new to crypto accounting or operating at lower transaction volumes should factor in the implementation and support investment. As framed above, the relevant question is not whether the software is "PCAOB certified," because PCAOB does not certify software. It is whether the SOC 1 scope and the buyer's own controls give the audit team enough evidence to rely on the workflow.
Bitwave
Bitwave markets itself as "audit-proven and battle-tested" and backs that with SOC 1 and SOC 2 Type 2 certifications, plus published Deloitte Tax partner commentary on blockchain-to-finance workflows. Its audit-readiness story covers immutable audit trails, role-based access, period locking, and segregation of duties. Those four elements map closely to what auditors evaluate when they consider ICFR control criteria.
On the ERP side, Bitwave integrates natively with NetSuite, Sage Intacct, and QuickBooks. Automated detection of internal transfers and transaction rollups before ERP sync reduces the manual intervention that tends to generate control deficiency findings.
For companies issuing or materially using payment stablecoins, Bitwave should also be evaluated against the GENIUS Act implementation timeline. The Act was signed on July 18, 2025, but its general effective date is the earlier of January 18, 2027 or 120 days after final implementing regulations are issued, so buyers should ask how any platform's controls and reporting roadmap map to that rulemaking process.
The honest caveat: Bitwave is built for large, complex crypto operations. If your team is scaling into crypto treasury management for the first time, weigh the capability depth against your current operational bandwidth and implementation capacity.
TRES Finance
TRES Finance offers broad blockchain and financial-platform coverage with AI-driven workflows and audit-oriented financial data infrastructure. On coverage breadth alone, it belongs in any serious shortlist evaluation.
There is a material context item every buyer evaluating TRES in 2026 needs to factor in: TRES Finance has been acquired by Fireblocks. Fireblocks announced the acquisition on January 7, 2026, and the acquisition is also disclosed on the TRES website. The downstream effect on TRES's product roadmap, compliance-attestation scope, and standalone availability for non-Fireblocks customers is not publicly documented in detail. TRES may remain a viable procurement option outside the Fireblocks ecosystem, but that needs to be confirmed directly with the vendor before the platform goes on a shortlist.
For teams already operating within the Fireblocks infrastructure, TRES may represent a natural integration. For teams that aren't, the acquisition introduces procurement uncertainty the other platforms here don't carry.
SoftLedger
SoftLedger takes a different architectural approach from the three platforms above. It's a multi-entity, API-first general ledger with a native crypto accounting module, not a subledger that syncs to an existing ERP. It supports cost basis tracking, gain/loss calculations, multi-entity consolidation, and multi-currency reporting, and is SOC 1 Type II compliant.
For finance teams building their stack from scratch without an existing ERP, SoftLedger's positioning makes sense. The architecture is designed to serve as the GL, not to layer on top of one.
For teams already running NetSuite or Sage Intacct, the fit is different because SoftLedger is primarily a GL rather than a dedicated crypto subledger layered onto an existing ERP. Buyers should confirm whether its crypto-specific workflows meet their needs around stablecoin handling, multi-chain reconciliation, and ERP handoff. For a controller whose audit trail problem is multi-chain crypto volume running through an existing ERP, the architectural mismatch is worth evaluating carefully before committing.
Cryptoworth
Cryptoworth is purpose-built to answer the question this article has been building toward: a crypto subledger that turns on-chain transaction data into audit-ready records, then delivers those records to your existing ERP with entity structure intact.
Against the six evaluation criteria:
- Source-data completeness: 230+ blockchain coverage with direct integrations across major exchanges, custodians, and DeFi protocols.
- Immutable transaction history: daily balance snapshots and user activity history provide timestamped, attributable support for AS 1105.10A reliability evaluation.
- ERP sync with entity context: integrations with NetSuite, QuickBooks, and Xero help preserve accounting context so journals arrive at the GL with entity and account mapping, not as unsupported flat imports.
- SOC attestation: Cryptoworth holds SOC 1 Type 1, SOC 2 Type 1, and SOC 2 Type 2. SOC reports are available to customers upon request. One practical note for teams in active audit engagements: SOC 1 Type 1 confirms that controls are suitably designed at a point in time, while SOC 1 Type 2, which some competitors hold, also covers operating effectiveness over an observation period. Buyers in public-company or Big 4 audit contexts should discuss reliance implications directly with their auditor team.
- Approval workflows and access controls: role-based access and segregation of duties are built into the platform.
- ASU 2023-08 fair value support: native fair value revaluation mechanics built in, including period-end fair value support that ties to the principal market under ASC 820, which is where audit comments on pricing governance tend to land.
Pricing is more transparent than most platforms in this list: the public pricing page lists Business Starter at $300/month, Data Access from $499/month, and custom enterprise tiers. Sandbox access is available for evaluation, but buyers should confirm current sandbox pricing directly before building it into a procurement comparison.
The Control Gaps That Consistently Surface in Crypto Audits
Knowing which platforms are available is one part of the evaluation. Knowing where audit findings actually originate is the other. These four gaps show up repeatedly in crypto-holding company audits, and each maps directly to a platform control capability.
An Incomplete Wallet Registry That Undermines the Rollforward
The ASU 2023-08 aggregate rollforward requires additions, disposals, and remeasurement gains and losses for in-scope crypto assets, supported by transaction-level detail. The failure mode that PCAOB observations have flagged isn't usually a missing journal entry; it's a missing wallet. Companies may omit crypto assets held at certain distributed ledger addresses, either because those addresses weren't in the original registry or because related parties controlled addresses that were never captured. If the source inventory is incomplete, the rollforward is incomplete, and no amount of downstream subledger accuracy fixes that. Wallet discovery and registry management are foundational before everything else on the audit trail checklist.
The Subledger-to-ERP Handoff Where Source Context Gets Lost
The on-chain transaction gets captured. Categorization runs. The journal entry is posted. Then, at the ERP sync boundary, the subsidiary context or chart-of-accounts mapping gets stripped, and the auditor's trace breaks. Generic crypto tools that treat a multi-entity ERP as a flat import target create this problem systematically, forcing controllers into heavy month-end correction work and leaving the auditor unable to trace from an income statement line back to the originating wallet activity without manual reconstruction.
Manual Categorization at Scale Becomes Evidence of a Control Deficiency
At hundreds or thousands of transactions per period, manual tagging creates a meaningful risk of inconsistent classification, missed transfers, and unsupported adjustments. When that process gets evaluated by an external auditor, it may stop being described as "our current workflow" and start being documented as a control deficiency. Automated categorization with audit-ready change logs is not a convenience feature. It's the difference between a process that can be tested and one that requires manual reconstruction.
Confusing SOC 2 for SOC 1 Leaves an ICFR Coverage Gap
Buyers regularly accept a vendor's SOC 2 report and assume it covers ICFR. It doesn't. SOC 2 evaluates security, availability, processing integrity, confidentiality, and privacy. SOC 1 evaluates controls relevant to user entities' internal control over financial reporting. Without a properly scoped SOC 1 Type 2 from the subledger vendor, your external auditor may need alternative procedures or direct testing over the relevant workflow, which can add time and cost to the audit. The practical question is not whether a badge exists, but whether the report scope maps to the controls your auditors need to rely on.
The consequence of getting it wrong is documented in the public record. A 2019 SEC Form 10-K from a publicly traded crypto-holding company disclosed material weaknesses including failure to map processes to control objectives, inadequate system and manual controls, and insufficient segregation of duties, all in connection with errors in accounting for cryptocurrency investments. In that case, the company restated previously issued financial statements. The pattern is consistent: when finance can't demonstrate the system that produced the numbers, the audit risk moves quickly from data cleanup to control deficiency.
What This Comes Down To
The audit trail isn't a feature. It's the deliverable. Every capability on the comparison table above, ingestion, reconciliation, fair value support, ERP sync, exists for one reason: to produce a transaction record that an external auditor can evaluate as reliable under PCAOB AS 1105.10A.
The platform that holds up isn't the one with the longest blockchain coverage list. It's the one built to answer the auditor's question at the transaction level: where did this number come from, who touched it, and how do I know it hasn't changed?
If your current stack can't answer that question cleanly, the audit risk is likely to surface when the team has the least time to rebuild the record. Ready to see how Cryptoworth handles the full transaction record from wallet ingestion to GL export to audit-ready reporting? Book a demo and walk through the workflow with the team.