The Audit Trail Question: How a Non-Custodial Crypto Setup Looks to Your Auditor

An audit walkthrough I sat through last year: the auditor pulled up the merchant’s general ledger, found a $14,200 digital asset receipt from May, and asked the question every auditor asks. “How do I know this transaction actually happened?”

The merchant pointed to their gateway dashboard. The auditor pointed back and said, “That’s a screen showing me what the gateway is telling me. I need to verify it independently.”

For card payments, this question is usually answered by tying the payment processor’s settlement to the bank deposit. For a non-custodial crypto setup, where the funds flow directly to your wallet without a processor holding them in between, the answer involves a different evidence chain. The inputs are different. The work isn’t necessarily harder, and in some cases the evidence is stronger.

This post walks through what your auditor will want to see for crypto receipts, how non-custodial flows produce that evidence, and a three-way reconciliation that ties everything together. If you’re choosing between a custodial and non-custodial gateway and audit defense is part of the decision, this is the post you want.

What an auditor actually wants

The American Institute of CPAs publishes a Practice Aid on auditing digital assets that lays out the assertions an auditor needs to test. The same framework applies whether you’re being audited as a merchant for your income tax return, an SOC 2 / 1 examination, a financial-statement audit by a CPA firm, or any other context where someone independent is verifying your numbers. There are five core assertions for assets and revenue:

1. Existence: the assets and transactions actually exist. The crypto receipt is real, not fabricated.
2. Rights and obligations: you actually own the assets at the balance sheet date.
3. Valuation: the amounts recorded are correct, covering both fair market value at receipt and any subsequent remeasurement.
4. Completeness: all transactions that should have been recorded have been recorded.
5. Cutoff: transactions are recorded in the correct period.

For traditional card payments, evidence for each assertion comes from a few places: processor statements, bank reconciliations, settlement files, your accounting system. The processor’s statement is treated as authoritative because the processor is the custodian of the funds during settlement.

For non-custodial crypto, the authoritative source moves. Instead of a third-party processor’s statement, the authoritative source is the blockchain itself. Every assertion has a different evidence chain.

Existence: prove the transaction happened

For each crypto receipt, your auditor wants to verify that an on-chain transaction actually moved the recorded amount from the customer to your wallet.

The evidence is the transaction hash. With the hash, the auditor can pull up the transaction on any block explorer (Etherscan for Ethereum, Tronscan for TRON, mempool.space for Bitcoin) and independently confirm:

• The transaction exists and was mined into a specific block.
• The amount transferred matches what’s on your books.
• The receiving address matches one of your wallet addresses.
• The block timestamp matches your recorded receipt time.
• The transaction is confirmed (sufficient block depth for finality on that chain).

In some ways this is stronger than a processor statement. A processor statement is a representation from the processor. A block explorer query is a direct read of a public, cryptographically-verified ledger. A confirmed on-chain record is much harder to alter than a processor statement. Your auditor still has to test the right chain, the right token contract, confirmation depth, wallet ownership, and whether the transaction hash actually supports the amount on your books.

The risk to existence assertion in a non-custodial setup is rarely “the public ledger is wrong.” It’s “the tx hash on your books might not actually correspond to the dollar amount you claim.” That’s a bookkeeping discipline problem, not a technology problem.

Rights: prove the wallet is yours

An auditor can see that 0.5 BTC arrived at wallet address `bc1q…`. They cannot tell from the public ledger alone whether that wallet is yours.

Rights assertion in crypto auditing typically requires one of:

1. Signed message proof: at audit time, you sign a message (“I, [Merchant], control this wallet”) using the wallet’s private key. The auditor verifies the signature against the wallet’s public address. This proves you control the private key at the moment of testing, which is the strongest possible rights assertion.
2. Wallet generation documentation: records of when and how the wallet was generated, who controls the keys, and chain of custody for any hardware wallet or key management process.
3. Transactional inference: a history of outbound transactions from the wallet to addresses you control (e.g., to your exchange account, to a known supplier you paid) that demonstrates effective control.

Signed message proof is the strongest. If your wallet setup permits it (most do; hardware wallets, software wallets, multisig arrangements all support signed messages), make it your default audit evidence.

For a non-custodial gateway, the rights assertion is straightforward because you own the wallet directly. There’s no shared custody to untangle, and the signed-message proof is yours to provide.

For a custodial gateway, rights is more complex. The auditor has to test whether the gateway holds segregated client funds, what the bankruptcy waterfall looks like, what happens if the gateway is hacked. These tests are more involved.

Valuation: prove the USD amounts are right

Valuation assertion in crypto auditing has two parts: valuation at receipt (the basis under tax and accounting rules) and valuation at the balance sheet date (for any remeasurement under ASU 2023-08).

For receipt-time valuation, the auditor will test:

• The price source you used (which exchange, which index, which gateway-quoted rate).
• The timestamp at which the price was captured.
• Whether the policy was applied consistently across all receipts in the period.
• Spot-checks: pull the price source for a sample transaction and confirm the recorded USD value is correct.

For balance-sheet-date valuation of in-scope assets under ASU 2023-08 (BTC, ETH, etc.), the same logic applies: which price source, which moment of day, applied consistently.

What wins valuation assertion is having a written FMV policy and actually following it. Pick CoinMarketCap, Coinbase, or your gateway’s quoted rate, and use the same source for every transaction in the period.

Completeness: prove nothing is missing

This is the assertion that catches people. Existence proves what’s on your books is real. Completeness asks the opposite question: is everything that should be on your books actually there?

The auditor will start from a source outside your accounting system and work in. For crypto, that means pulling your wallet’s complete on-chain transaction history and asking: “Is every inbound transaction on this list represented in your books?”

The procedure typically looks like:

1. Auditor obtains a complete inbound transaction list for each of your wallet addresses, sourced directly from the chain (not from your gateway, not from your accounting system).
2. Auditor reconciles the chain list against your gateway’s transaction list. Every chain inbound should appear in the gateway list with a matching tx hash.
3. Auditor reconciles the gateway’s list against your accounting system. Every gateway entry should be in the GL.
4. Discrepancies trigger investigation.

The three sources (chain, gateway, GL) must reconcile. Three-way matching is what the audit defense rests on.

If chain shows an inbound that gateway doesn’t, you may have received crypto outside your gateway’s flow (e.g., a customer paid you directly, an old wallet got reused). Investigate.

If gateway shows an entry chain doesn’t, your gateway has a data integrity problem. Escalate.

If GL is missing entries from the other two, your bookkeeper is behind. Catch up.

Non-custodial gateways generally make the chain↔gateway reconciliation easier because the gateway’s transaction list is basically a labeled view of the chain. Every gateway entry has a tx hash, and every chain inbound to your wallet should appear in the gateway’s list if it flowed through the gateway’s checkout.

Cutoff: right period, right transaction

Cutoff asserts that transactions are recorded in the period in which they occurred, not pulled forward or pushed back. For card payments this is straightforward; settlement files are dated, and the processor’s bookkeeping is the cutoff.

For crypto, the block timestamp is the cutoff anchor. A transaction confirmed at 23:58 UTC on December 31 belongs in this year. One confirmed at 00:02 UTC on January 1 belongs in next year. The block timestamp lives on the chain. It’s not subject to your gateway’s clock, your dashboard’s update lag, or your bookkeeper’s data-entry timing.

The audit test: pull all transactions from the last few days of the period and the first few days of the next period. Confirm each is booked in the correct period using block timestamp. Discrepancies (a transaction booked in the wrong period) are cutoff failures.

Non-custodial setups have a cleaner cutoff story than custodial ones because there’s no settlement lag. The transaction is final at block confirmation, so you don’t get the “gateway received it on Dec 31 but didn’t settle to your wallet until Jan 3” issue.

The three-way reconciliation, in practice

Practically speaking, what makes an audit clean is a monthly reconciliation discipline:

Source	Where it comes from	Granularity
On-chain inbound list	Block explorer query or direct node access, filtered to your wallet addresses	One row per inbound transaction
Gateway transaction list	Gateway’s reconciliation interface, admin export, or API	One row per order, with tx hash linking to chain
General ledger entries	Your accounting system’s digital asset accounts	One JE per receipt, with tx hash in memo

Every row in source 1 should have a matching row in source 2 (matched by tx hash). Every row in source 2 should have a matching JE in source 3 (matched by tx hash in the JE memo). Discrepancies get investigated and resolved within the close cycle.

This reconciliation is not new technology. Card payment merchants have been doing processor-to-bank-to-GL reconciliation for decades. The crypto version replaces “processor statement” with “on-chain query” and uses the tx hash as a universal join key across all three sources.

For non-custodial setups specifically (Aurpay is structured this way), the tx hash is exposed through the gateway’s reconciliation interface, which makes the chain↔gateway match trivial. Custodial setups, where funds pool in the gateway’s wallets and settle to you later, require an additional reconciliation step between the gateway’s internal records and the on-chain reality of the gateway’s pooled wallets, which the gateway typically doesn’t expose.

The ASU 2023-08 disclosure layer

On top of the audit assertions, ASU 2023-08 added specific disclosures under ASC 350-60-50 for in-scope crypto holdings. Your auditor will review these as part of testing presentation and disclosure:

• Per-asset name, cost basis, fair value, and units for significant holdings (interim and annual).
• Aggregate fair value and cost basis for non-significant holdings (interim and annual).
• Contractual sales restrictions on holdings, including fair value, nature, duration, and lapse circumstances (interim and annual).
• Annual reconciliation of beginning to ending holdings, with cumulative realized gains and losses shown separately, plus narrative on the nature of additions and dispositions.
• Annual disclosure of cost-basis determination method (FIFO, specific identification, average cost, etc.).

Your audit defense for each of these disclosures rolls back to the underlying transaction records, which means the same three-way reconciliation that supports existence and completeness also supports your disclosures.

Why non-custodial is sometimes cleaner

I want to be careful here, because I’m aware “non-custodial is better for audits” is exactly the kind of self-serving claim that should make you skeptical. The honest version is more nuanced.

Non-custodial setups have audit advantages:

• Funds flow directly to your wallet, so there’s no settlement lag, no pooled wallets, no third-party custody to test.
• Rights assertion is a clean signed-message proof against a wallet you control.
• Cutoff is anchored to block timestamps, not gateway settlement schedules.
• Existence assertion is verifiable against the public chain, so the evidence is independent of the gateway itself.

Non-custodial setups also have audit costs:

• You’re responsible for your own wallet operational security. The auditor will test your key management.
• Some gateways’ reconciliation interfaces are less mature than incumbent processors’ settlement reporting.
• If you use multiple wallets across multiple chains, the reconciliation work scales with that complexity.

For most merchants the net effect is that non-custodial is comparable to custodial for audit defense in the worst case, and stronger when the evidence chain runs through the public ledger rather than a third party’s books.

Three questions to bring to your auditor

1. For each AICPA assertion, what specific evidence will you accept for our crypto holdings? Walk me through what you’d want to see for existence, rights, valuation, completeness, and cutoff.
2. For our three-way reconciliation (chain, gateway, GL), what level of automation would you expect for our company size, and what manual sign-off do you want to see?
3. What are the most common audit findings you’ve issued on crypto-accepting merchants in our size range, and how do we avoid them?

The audit defense for crypto receipts comes down to discipline. Same transaction hash, same wallet, same FMV policy, every month, signed off by a named person. Get that right and your auditor’s questions become check-the-box. Get it wrong and the audit drags on.

---

This article is general information for merchants and finance leads. It is not audit, accounting, or legal advice, and does not establish a client relationship. Specific audit procedures and evidentiary standards depend on your auditor’s professional judgment, applicable auditing standards, and the specifics of your business. Consult your independent auditor or a licensed CPA for advice tailored to your situation.