暗号資産の税務記録：取得価額・交換・手数料・取引台帳の作り方

税務台帳は価格表ではなく、各eventの証拠chain

暗号資産の税務記録は、誰が、いつ、どのassetを、何単位、何と交換し、どのfeeを払い、どの法定通貨価値だったかを再現するevent ledgerです。日本では暗号資産の売却・使用等の利益は原則として雑所得に区分される旨が国税庁から示されていますが、事業との関係、法人、NFT、staking、外国税、年度改正等で扱いが変わります。この記事は記録設計であり税務助言ではありません。

当局の最新資料、居住地、取引年度、選定した評価方法を確認し、税理士等へ相談します。CARF等によりservice providerの情報収集・報告が広がっても、納税者の自己記録が不要になるわけではありません。第三者reportと自分のledgerに差が出る可能性があるため、account ID、tax residence、asset mappingを照合します。

正式なevent分類と評価は適用法・当局資料・専門家により確認します。

CSV・statement・on-chain証拠を加工前のまま保存する

取引所からCSV、annual statement、deposit/withdrawal history、fee report、reward reportをperiodごとに取得し、file nameへprovider、account code、period、download date、timezone、versionを付けます。元fileはread-onlyで保存し、column名や行を直接変更しません。加工は別fileへ行い、import scriptやmapping versionを残します。service終了後は再取得できないため定期downloadが必要です。

自己保管ではpublic address、network、contract、tx hash、block timestamp、from/to、token transfer、gasを保存します。explorerのlabelや法定通貨換算は後日変わることがあるため、raw transaction dataと換算dataを分離します。screenshotだけではmachine-readable集計が難しく、CSVだけではwallet ownershipや取引目的が分からないため、両方を補完します。

• 原始file: providerから取得したままhashとdownload dateを保持。
• mapping: provider symbolをnetwork・contract・tax asset IDへ対応。
• ownership: 自己wallet、共同wallet、事業用、第三者custodyを分類。
• evidence URL: explorer transactionとofficial termsの確認日を保存。

tickerではなくcontract、timezone、換算sourceを固定する

同じtickerが複数networkや偽tokenに使われ、token migrationで旧・新contractが併存します。tax asset IDにnetwork、contract、decimal、issuerを含め、wrapped tokenやliquid staking receiptを元assetと自動統合しません。bridgeはtransfer、swap、mint/burnのどのeventとして扱うかを証拠と地域ruleで判断します。

取引所timestamp、block timestamp、bank statement、local calendarの日付境界を揃えます。UTCとJSTを混ぜると年末取引が別年度へ移ります。法定通貨換算は、実際のpair price、official rate、reliable market price等のsourceと時刻を定め、一貫して適用します。bid、ask、mid、daily closeのどれを使ったかを記録します。

評価方法・期首残高・fee・roundingをversion管理する

日本の個人の暗号資産評価では総平均法と移動平均法に関する国税庁の計算書・届出案内があります。どの方法を選定・届出したか、assetごとの期首数量・期首評価額、期中取得、期中処分、期末数量を保存します。methodを都合よく年度途中で切り替えず、変更手続を確認します。法人や別法域は別ruleです。

移動平均の架空例で、2 BTCを平均3,000,000円で保有し、0.5 BTCを4,000,000円、取得関連fee 1,000円で追加するなら、新平均は（6,000,000＋2,000,000＋1,000）÷2.5＝3,200,400円/BTCです。ただしfeeを取得価額へ含めるか、どの時点で認識するかは税務確認が必要です。

staking・DeFi・bridge・NFTを一つのnet行へ潰さない

staking rewardはaccrual時かclaim時か、自由に処分可能になった時かで記録時点が論点になります。liquid stakingでreceipt tokenを受け取る、lendingでinterest-bearing tokenへ交換する、LP tokenを受け取る、bridgeでwrapped tokenをmintする操作は、法域によりtransfer、exchange、deposit、所得等の分類が異なり得ます。protocol名だけで自動分類しません。

一つのtransactionにapproval、swap、LP deposit、reward claim、gas paymentが含まれることがあります。explorerのouter transactionだけでなくtoken transfers、internal calls、event logsを分解します。gasをどのeventへ配賦するか、失敗transactionのfee、native tokenで支払ったfeeの処分性を確認します。DeFiのcontractとapprovalで技術的意味を先に確定します。

自動tax softwareの分類は必ず原始証拠へ照合します。

数量reconciliation・未確認queue・変更履歴で締める

assetごとに期首数量＋取得＋reward＋incoming transfer−処分−fee−outgoing transfer＝期末数量を計算し、取引所statementとwallet balanceへ照合します。差異はrounding、missing CSV page、internal transfer、delisted asset、rebase、airdrop、chain fork、spam token、migrationのどこかに分類します。差額をmanual adjustmentで消さず、reason、evidence、reviewer、dateを残します。

未確認eventは0円やtransferと断定せず、unknown queueへ置き、ownerと期限を付けます。tax returnへ使ったledger version、calculation method、software version、exchange rate table、専門家のadjustmentをlockし、その後の修正は新versionにします。保存期間、個人情報、相続、事業記録は地域ruleに従い、backupを暗号化・分散します。

1. 01全sourceをfreeze

   CSV、statement、address、tx、bankを期ごとに保存。

2. 02eventを正規化

   asset ID、時刻、数量、rate、fee、purposeを同じschemaへ。

3. 03数量を照合

   期首から期末までasset単位でreconcile。

4. 04unknownを解決

   推測せずevidence ownerとdue dateを付ける。

5. 05review versionをlock

   method、rounding、adjustment、approverを保存。

Financial Templates Hubは取引台帳、source list、未確認事項、review sign-offの骨組みに使えます。秘密鍵・seed・完全な本人確認書類は入力しません。国税庁の最新暗号資産資料と計算書を必ず直接確認し、具体的な申告は税理士等へ相談してください。