Skip to content

SMSF Bitcoin Audit Guide

This page explains how Bitcoin held in self custody within an SMSF can be substantiated for audit purposes. The key issue is whether the fund's records clearly support the holding, the reporting date balance, the reporting date value, and the separation of fund assets from personal assets. It is intended for SMSF trustees, accountants, and auditors.

New to SMSF bitcoin? Start with BitcoinSuper's SMSF pathway and custody overview: SMSF Setup Path, Bitcoin SMSF Custody, and Bitcoin SMSF FAQs.

For an EOFY oriented walkthrough that sits upstream of this detail, see the SMSF Bitcoin EOFY checklist.

At a glance

  • Bitcoin is held on-chain in a self-custody 2-of-3 multisig structure.
  • Evidence follows assertions: existence, rights and attribution, completeness, and valuation.
  • The Annual Statement of Position is the anchor artefact: reported position plus embedded transaction and reconciliation evidence.
  • Trustee/director attestation is part of SMSF attribution evidence when it names the fund, vault, reporting date and position and reconciles to the Statement of Position. It does not, by itself, establish ownership.
  • Additional wallet disclosure should have a defined evidentiary purpose, not be a default technical procedure.
  • Optional read-only visibility: trustees can use TBA Vault Watcher or Bitcoin Super to reconcile on-chain balances and history with fund records.

Auditor summary

The fund holds its bitcoin in a collaborative 2-of-3 multisig vault. The trustees hold keys and direct the vault. The Bitcoin Adviser holds one key as a co-signer and cannot move funds alone. The fund owns its bitcoin: The Bitcoin Adviser holding one signing key does not make that bitcoin The Bitcoin Adviser's asset.

The annual Statement of Position (the PDF is titled Statement of Holdings) shows each vault's opening and closing BTC balance and every transaction in the year, each with its full TXID linked to a block explorer. Where the 30 June holding can be rebuilt exactly from the vault's history, it also lists the unspent outputs that make up the closing balance: TXID, output number (vout) and amount. It does not list addresses, xpubs or descriptors.

A TXID shows that an identified output existed on-chain at 30 June. It does not show which legal entity owned it. Multisig architecture alone is not proof that the SMSF is the beneficial owner. Each assertion has its own evidence:

  • Existence: TXID, output number, amount, and whether the output was still unspent at 30 June.
  • Completeness: the fund's recorded wallet outputs add up to the stated BTC balance.
  • Ownership: SMSF trustee records, the wallet's designation as a fund asset, acquisition records, and supporting declarations where appropriate.
  • Valuation: the BTC balance times a documented 30 June AUD market price.
  • Control: wallet configuration, signing arrangements and trustee authority.

To check the holding: open each TXID; find the output by its number and confirm the amount; confirm the transaction was mined on or before 30 June; if the output has since been spent, check whether that spend was confirmed before or after 30 June; add up the outputs and reconcile them to the closing BTC balance.

The trustees may still be asked for bank statements and exchange or broker confirmations for purchases, trustee minutes or resolutions, the wallet's designation as a fund asset, and the valuation method. The ATO's SMSF crypto investment guidance covers keeping fund assets separate and valuing them at 30 June.

A statement's TXIDs are for the fund's trustees, accountant and auditor. Do not publish them: a block explorer can show amounts and how transactions connect.

Guide: thebitcoinadviser.com/smsf-bitcoin-audit-guide. Revised 14 October 2026.

Download this summary as a one-page PDF

How to verify a 30 June balance

Start from the statement's Holding at 30 June list for the vault. Each line is a TXID, an output number (vout) and an amount. A fund with a few outputs is a short check; a vault with a long history takes longer, because each output in the list is checked.

  1. Open the full TXID. Each TXID in the statement links to mempool.space; any block explorer will do.
  2. Find the output by its number and confirm the amount. Outputs are numbered from 0, so vout 1 is the second output.
  3. Confirm the transaction was mined on or before 30 June. Statements use Australian eastern time: the cutoff is midnight at the end of 30 June.
  4. If the explorer shows the output as spent, open the spending transaction and check when it was confirmed. A spend confirmed after 30 June does not remove the output from the 30 June holding.
  5. Add up the outputs in the list and reconcile the total to the vault's closing BTC balance. They should match exactly, to the satoshi (0.00000001 BTC).

An output can be spent today and still belong in the 30 June holding. The question is whether it was unspent at the end of 30 June, not whether it is unspent now.

An invented example. TXIDs are shortened to letters here; a statement prints them in full.
OutputAmount (BTC)MinedSpentIn the 30 June holding?
TXID A, vout 00.2500000012 March 2025Not spentYes
TXID B, vout 10.100000004 May 20263 July 2026Yes, spent after 30 June
TXID C, vout 00.0500000020 January 202615 June 2026No, spent before 30 June

The 30 June holding is TXID A and TXID B: 0.35000000 BTC, which must equal the vault's closing balance of 0.35000000 BTC. The spend of TXID C appears in the year's transactions instead.

SMSF Bitcoin audit evidence follows a simple hierarchy

  1. Start with the Statement of Position. Identify the relevant reporting-period vaults and balances before independent on-chain verification. A fund may have more than one vault in the statement, including a zero-balance vault. Starting from an independently chosen address is the wrong abstraction for this model.
  2. Treat the Statement of Position as the reported position plus embedded transaction and reconciliation evidence, not a static balance snapshot.
  3. Fill remaining gaps with SMSF attribution evidence (trustee/director attestation plus, where applicable, acquisition/source-of-funds and fund records) and independent valuation evidence.
  4. Identify any remaining gap: Existence, Rights and attribution, Completeness, Valuation.
  5. Supply targeted additional evidence: the least sensitive information that addresses that gap. Additional wallet disclosure should have a defined evidentiary purpose, not be requested as a default technical procedure.
  6. For existence/quantity, that means targeted on-chain corroboration of the reporting-period vault identified in the Statement of Position: relevant TXIDs, transaction outputs, and reporting-date UTXOs where appropriate. Not "the public address of the vault."
  7. Escalate to extended wallet metadata only where targeted transaction/output evidence is insufficient: descriptors, xpubs, derivation paths, full multisig configuration.
  8. Never: private keys, seed phrases, signing secrets.

This guide is operational evidence, not SMSF advice. This page is for information only and does not constitute financial, legal, tax, or audit advice. Trustees and their advisers should rely on their own professional advice and the Australian Taxation Office (ATO) and other official guidance where applicable. This guide focuses on Australian SMSFs; if you are outside Australia, consult your local regulations. Sufficiency and appropriateness of audit evidence remain a matter of the auditor's professional judgement.

Contents

Boundary

Our role

The Bitcoin Adviser provides non-custodial advisory services. We do not hold assets, custody Bitcoin, control client funds, or provide storage services.

  • We do not take custody of Client Bitcoin.
  • We do not manage, control, or unilaterally access Client funds.
  • Where applicable, we may act as a co-signer or backup key holder within a multisignature arrangement.
  • We cannot move Bitcoin without the client's explicit authorisation and participation in accordance with the applicable multisig policy.
  • The client retains full beneficial ownership and ultimate control of all Bitcoin at all times.

This is consistent with our Terms of Service (Section 4: Non-Custodial Services Statement).

Context

How the SMSF holding model works

Collaborative security in this context refers to a 2-of-3 multisignature (multisig) arrangement: multiple keys are held by different parties, and a configured threshold of signatures (e.g. two of three) is required to move funds. In plain terms:

  • Multiple keys exist; no single key can move the Bitcoin alone.
  • Trustees (or their delegates) retain control; they are signers and direct the use of the vault.
  • No single party, including The Bitcoin Adviser or the software platform, can unilaterally move funds.
  • There are no pooled assets; the vault is attributed to the SMSF (or the client).
  • There is no unilateral third-party authority over the assets.

2-of-3 in practice

Any two of the three keys can authorize a move: Key A + Key B, or Key A + Key C, or Key B + Key C. The transaction can be signed. No single key can move funds alone.

A 2-of-3 vault is not one stable public blockchain address. The wallet derives many script addresses over time from the multisig policy. What exists publicly on-chain are individual transaction outputs and script addresses generated by that wallet, not a single canonical vault address.

In this arrangement, coordination platforms are not Bitcoin custodians for your fund in the pooled-custody sense. The platform that coordinates multisig (e.g. Unchained, Theya) supplies software and coordination. It does not hold Bitcoin in a custodial capacity for the SMSF; assets remain on the Bitcoin network and are controlled by the key holders according to the multisig policy. Wording here describes this model, not every possible service structure elsewhere.

Scope and limitations. This guide focuses on Australian SMSFs. Lost keys, inheritance of SMSF Bitcoin, and tax implications of multisig transfers are complex; trustees should seek specific professional advice. If you are outside Australia, consult your local regulations.

Bitcoin held in an SMSF under this model is on-chain: it exists as entries on the Bitcoin network, controlled by the keys that form the multisig vault. The trustees (or their authorised signers) control those keys and are responsible for access and decisions. Trustees remain responsible for the fund's investment strategy, record-keeping, and compliance. This is consistent with self-custody principles and with the Australian Taxation Office's expectations that SMSF trustees understand and control fund assets. For current guidance, see the ATO's pages on self-managed super funds and, where applicable, crypto assets.

Assertions

Four audit assertions

For account balances, Australian auditing standards identify assertions including existence, rights and obligations, completeness, and accuracy, valuation and allocation. Mapped to SMSF Bitcoin:

Existence / quantity

What must be established: the SMSF held X BTC at 30 June.

The Statement of Position shows the reporting-date position and underlying transaction record. If more is needed: targeted on-chain evidence for the reporting-period vault identified in the Statement of Position, including relevant TXIDs, transaction outputs and reporting-date UTXOs where appropriate.

This is not a request for "the public blockchain addresses where the Bitcoin was stored."

Completeness / movements

What must be established: relevant purchases, disposals and movements during the period are recorded.

The Statement of Position contains the recorded vault movements and transaction history. If more is needed: expanded transaction/reconciliation evidence only if the embedded Statement of Position history is insufficient. Completeness is not a back-door to full wallet history, descriptors, or xpubs.

Valuation

What must be established: the BTC balance has been translated into an appropriate AUD market value at 30 June.

The auditor can independently verify this from objective historical pricing. Wallet configuration is irrelevant to valuation. The Statement of Position does not independently determine market value. An xpub does not solve an unresolved valuation assertion.

Evidence set

Standard audit evidence set

Three core layers replace a flat equal-weight checklist. The Statement of Position is the anchor. Balance, FY transaction history and TXIDs are not listed again as separate artefacts; they are already inside that document.

1. TBA Annual Statement of Position

The reported Bitcoin position plus embedded transaction and reconciliation evidence. Typical contents include:

  • Reporting period and statement date
  • Named client
  • Aggregate closing BTC balance
  • Vault-level opening and closing balances
  • Number of transactions
  • Transaction history
  • TXIDs
  • Movement amounts and running balances

Limitation: The Statement of Position reports and supports the Bitcoin position recorded by TBA from the relevant vault data. It does not by itself establish legal ownership of the asset by the SMSF or independently determine market value.

2. SMSF attribution evidence

Trustee/director attestation plus, where applicable, acquisition/source-of-funds and fund records linking the identified vaults and reported position to the SMSF.

The attestation should name the fund, relevant vault, reporting date and BTC position, and reconcile to the Statement of Position. It carries weight as part of the evidence set. It does not, by itself, establish ownership.

Separation from personal holdings remains one of the strongest practical protections for attribution.

3. Independent valuation evidence

Objective 30 June BTC/AUD market price and the auditor/accountant valuation methodology. The auditor can verify this independently. See Valuation methodology.

Statement of Position, SMSF attribution evidence, and independent valuation can form a complete evidentiary package where, taken together, they give the auditor sufficient appropriate evidence of existence, rights/attribution, completeness and valuation.

Taken together, these layers are designed to address the principal audit assertions relevant to an SMSF Bitcoin holding. The auditor remains responsible for determining whether the evidence obtained is sufficient and appropriate in the circumstances.

Additional records only if a named assertion remains unresolved: bank statements, broker confirmations, trustee resolutions, targeted TXIDs, outputs and reporting-date UTXOs. Not a vault address list. Not full wallet configuration as a default.

Assertion mapping

AssertionPrimary evidence layer
Existence / quantityStatement of Position
Rights / attributionTrustee/director attestation plus acquisition/source-of-funds and fund records
Completeness / movementsStatement of Position (recorded vault movements and transaction history)
ValuationIndependent 30 June market pricing
Valuation

Valuation methodology at reporting date

For reporting and audit purposes, the fund should use a documented valuation approach based on objective and supportable market data at the relevant reporting date. The ATO points auditors to objective historical pricing (for example, a 30 June closing value published by a crypto exchange). The method used should be retained with the fund's records and applied consistently unless a deliberate policy change is made and documented.

The auditor can independently verify valuation. Wallet configuration is irrelevant to this assertion.

If open, close, spot, or exchange-specific methodology is used, it should be applied consistently. The formulas below are tools to implement a chosen policy, not a substitute for one.

Spreadsheet tools to support your valuation policy

Optional quick historical price check (uses a public API)

Figures are for convenience only; your fund's valuation policy and professional judgment govern. The request can be slow or return no data for some dates.

Valuation calculator: get the Bitcoin price for a specific date and currency (for audit and reporting).

Bitcoin valuation by date

Runs in your browser only; we don't collect or store any data you enter.

Our reports show balances and movements in Bitcoin. For audit purposes, accountants often need market value and fiat amounts for each transaction. You can look up the Bitcoin price for any date and in your chosen currency using built-in spreadsheet functions in Google Sheets or Excel.

Google Sheets: Current price in AUD: =GOOGLEFINANCE("CURRENCY:BTCAUD"). For the closing price on the date in cell A2:

=INDEX(GOOGLEFINANCE("CURRENCY:BTCAUD","close",A2,A2,"DAILY"),2,2)

You can use "open", "high", or "low" instead of "close". For other currencies, replace BTCAUD with BTCUSD, BTCEUR, BTCCAD, etc. Data may be delayed by up to 20 minutes.

Excel (Microsoft 365): For a single date in cell A2, returning date and close price in AUD:

=STOCKHISTORY("BTCAUD", A2, A2, 0, 1, 0, 1)

Ticker ("BTCAUD", "BTCUSD", "BTCEUR", etc.), then property codes: 0 = Date, 1 = Close, 2 = Open, 3 = High, 4 = Low, 5 = Volume. Requires Microsoft 365; data is end-of-day.

Valuation basis (open, close, high, or low) is a matter of professional judgment and documented fund policy. The formulas above help you apply your chosen basis consistently; they do not substitute for that policy.

Boundaries

Evidence boundaries and escalation

Evidence should be proportionate to the assertion being tested. If the first request is all xpubs, all addresses, or the full multisig configuration, the prior question is which assertion remains unresolved after the three core layers.

If those three layers address the relevant assertions, additional wallet disclosure should have a defined evidentiary purpose rather than simply being requested as a default technical procedure.

Level 1: Standard evidence

The three core layers: Statement of Position, SMSF attribution evidence, and independent valuation. Normally supplied.

Level 2: Targeted corroboration

If Level 1 does not establish something, the next question becomes: which audit assertion remains unresolved?

  • Existence / quantity: targeted on-chain evidence for the reporting-period vault identified in the Statement of Position, including relevant TXIDs, transaction outputs and reporting-date UTXOs where appropriate. Do not prefer "public addresses" or a single vault address.
  • Attribution: if ownership remains unresolved, an xpub does not solve it. SMSF bank records, acquisition records and trustee documentation do.
  • Valuation: if market value remains unresolved, an xpub does not solve it. Independent price data does.
  • Completeness: expanded transaction/reconciliation evidence if the embedded Statement of Position history is insufficient.

Level 3: Extended wallet metadata

Descriptors, xpubs, derivation paths and the complete multisig configuration are extended wallet metadata, not standard audit-pack evidence. Considered only after the auditor concludes targeted transaction/output evidence is insufficient for an identified assertion.

A complete multisig wallet configuration is not part of TBA's standard SMSF audit evidence set. It may contain persistent public-key and derivation information relating not only to the trustee but also to independent co-signers. Although it does not contain private keys or confer signing authority, disclosure can materially increase wallet visibility and therefore should not be treated as routine audit documentation.

Neither the ATO guidance nor Australian Auditing Standards prescribe disclosure of a multisig wallet configuration as a standard requirement for an SMSF Bitcoin audit. The auditor may still decide they need additional evidence; that is different. Independent corroboration from another source is a legitimate auditor request; jumping to full wallet configuration is not the same thing. If the auditor has assessed the evidence and still needs extended metadata, the trustee can still choose to provide it. Nothing is prohibited; it is not the default.

Level 4: Never disclose

Private keys, seed phrases, signing material, or anything that exposes signing authority. These are not provided to anyone, including auditors or accountants.

Documentation

What we provide

We help trustees and accountants assemble a coherent, proportionate documentation set aligned with the three core layers, without asking for private keys or weakening wallet security. The aim is clearer records and less unnecessary disclosure, within our non-custodial role. The auditor remains responsible for whether the evidence obtained is sufficient and appropriate.

We provide the following to support trustees, accountants, and auditors:

  • Annual Statement of Position: the reported Bitcoin position plus embedded transaction and reconciliation evidence (reporting period, named client, aggregate and vault-level balances, transaction history, TXIDs, movements and running balances).
  • Supporting materials for attribution: engagement context and, where relevant, coordination on trustee/director attestation that reconciles to the Statement of Position.
  • Service agreement: the client's agreement with The Bitcoin Adviser (our Terms of Service and any engagement terms).
  • Invoices: for fees paid for advisory and co-signing services.

Verification does not require disclosure of private keys, seed phrases, or any action that would weaken the security of the SMSF's Bitcoin. Relevant evidence can be supported through the documentation above and, where appropriate, view-only or export-based records that do not expose signing authority.

Optional read-only tools for trustees

TBA Vault Watcher (/tba-vault-apps) on iPhone and iPad shows vault balances and transaction history from watch-only configuration: no private keys, no signing, and data stays on the device.

Bitcoin Super (bitcoinsuper.io/bitcoin-super-app) is a watch-only SMSF companion on the same iPhone: Australian financial year statements with AUD valuations, trustee education, and illustrative scenarios. Available on the App Store in Australia and New Zealand only. It shares vault configuration with Vault Watcher on the same device through on device storage only.

Either tool can help cross-check fund records, TXIDs, and the Statement of Position against the public blockchain. That supports the same reconciliation idea as the evidence hierarchy; neither is a formal attestation or a substitute for the documented evidence set.

Need help preparing your audit pack? Contact us

Clarifications

Common misconceptions

The following are often raised; in this holding model, they are not ordinarily the relevant mechanism:

"The software platform holds the Bitcoin."

In this holding model, that is not ordinarily the relevant mechanism. The platform provides software and coordination for multisig; it does not hold Bitcoin in a custodial capacity for the fund in the pooled-custodian sense. The Bitcoin is on the Bitcoin network; the keys are held by the signers (e.g. the trustee and their delegates, and where applicable The Bitcoin Adviser as a co-signer).

"A self-custody SMSF must have a custodian."

In this holding model, that is not ordinarily the relevant mechanism. There is no separate pooled custodian of the fund's Bitcoin. The client (and the SMSF trustees) retain self-custody via multisig. Our role is advisory and, where agreed, co-signing; we do not take custody. Our Terms of Service govern the advisory and co-signing relationship, not a custody relationship.

Custodian-style attestations (SOC, Proof of Reserves)

SOC reports. In this holding model, SOC-style reports are not ordinarily the primary evidence. They matter most where a custodian or service organisation holds or processes client assets in a way this guide is not describing. Here, auditors usually rely on the Statement of Position, fund records, and independent valuation.

Proof of Reserves

Proof-of-Reserves is a custodian-led idea. In this model the fund's Bitcoin sits in a self-custody multisig vault, not in a pooled custodial account. Verification is by on-chain data and fund documentation, not by a third-party reserve attestation.

References

References & further reading

ATO links last checked: March 2026. Auditing Standards links last checked: August 2026.

For technical background on multisignature Bitcoin (without endorsement of any custody or advisory relationship), software providers such as Unchained publish educational material on how multisig works; trustees and auditors may find such resources useful for context only.

FAQ

Frequently asked questions

How does an auditor know the wallet belongs to the SMSF?

Attribution rests on SMSF attribution evidence: trustee/director attestation that names the fund, vault, reporting date and position and reconciles to the Statement of Position, plus acquisition/source-of-funds and fund records where applicable.

The Statement of Position names the client and vaults; it does not by itself establish legal ownership. See the SMSF attribution evidence layer.

Is trustee attestation enough on its own?

No. Attestation alone does not establish ownership.

It carries weight as part of the attribution layer when it identifies the fund, relevant vault, reporting date and BTC position and reconciles to the Statement of Position and fund records. Sufficiency remains the auditor's judgement.

Where should verification of the Bitcoin position start?

Start with the Annual Statement of Position so the relevant reporting-period vaults and balances are identified first.

A 2-of-3 vault is not one stable public address. Independent on-chain corroboration then targets the TXIDs, outputs and reporting-date UTXOs for the vaults named in the statement.

Does multisig mean a third party has custody?

No. In this model the coordination platform provides software and coordination, not pooled custodial holding of fund Bitcoin.

Assets are on the Bitcoin network and controlled by the key holders. No single party can unilaterally move funds.

Do auditors need private keys or seed phrases?

No.

Those are never disclosed. Relevant evidence can be provided through the Statement of Position, fund records, on-chain corroboration of TXIDs and outputs, and supporting documentation without exposing keys or seed phrases.

Do auditors need xpubs or the full multisig configuration?

Those are extended wallet metadata, not standard audit evidence-set items.

They are considered only after a named assertion remains unresolved and, for existence/quantity, after targeted TXID, output and reporting-date UTXO evidence is insufficient. Never share private keys or seed phrases.

How should Bitcoin be valued at 30 June?

Use a documented valuation approach based on objective, supportable market data at the reporting date. The auditor can independently verify this.

Retain the method with the fund's records and apply it consistently. Spreadsheet functions can support a chosen policy. Wallet configuration is irrelevant to valuation.

What documents typically support an SMSF Bitcoin audit?

The three core layers: Annual Statement of Position, SMSF attribution evidence, and independent valuation evidence.

Taken together, they are designed to address the principal assertions. The auditor remains responsible for whether the evidence obtained is sufficient and appropriate. See the standard audit evidence set.

If there is no pooled custodian, how is ownership evidenced?

Through the Statement of Position plus SMSF attribution evidence (attestation and fund records), not through custodian-style attestations.

See the four audit assertions and evidence set.

Why do other clients provide xpubs, but The Bitcoin Adviser does not?

An xpub can let someone reconstruct a wallet's activity, and some providers use that for audit reporting. It also exposes that activity to whoever holds it and can affect the fund's financial privacy.

In a multisig vault one xpub may not be enough; more of the wallet configuration may be required. Full TXIDs, output numbers, whether each output was unspent at 30 June, and a holding that reconciles to the closing balance can evidence identified outputs without extended public keys. See How to verify a 30 June balance.

Can we qualify the audit or report the fund to the ATO because no xpub was provided?

The auditor judges whether there is sufficient appropriate evidence for each assertion. A missing xpub does not by itself prove the assets cannot be verified.

The auditor may still need more evidence for ownership, completeness, control or another assertion. If the evidence is still insufficient, the auditor uses their own judgement and the reporting duties that apply. This guide does not tell the auditor what conclusion to reach.

Questions about this guide or about verification for your SMSF audit? Contact us at contact@thebitcoinadviser.com or reach out on X @AndyBTCAdviser.

Terms of Service

© 2026 The Bitcoin Adviser

Back to top