カード決済は、注文をすでに特定しているアクワイアラーのレポートを通じて帳簿に反映されます。USDCの送金は、アドレス、金額、トランザクションハッシュは届きますが、それ以外の情報はありません。暗号資産決済の消込は、請求書に取引の参照番号が含まれていれば機能します。送金自体にはその情報を含めることができないためです。
このガイドは、ステーブルコインを受け付けてユーロで決済する加盟店、PSP、EMIの経理・業務チーム向けです。各請求書レコードに必要なフィールド、一部入金や誤ったコインでの入金の扱い、WebhookとAPIが台帳にデータを反映する方法、そしてすべての記録をどれだけ保存するかを決めるEUの規則を整理しています。
主なポイント
要点
- ERC-20の送金に含まれるのは、送信者、受信者、金額だけです。注文の参照番号は送金そのものではなく、請求書側に持たせる必要があります。
- 請求書はEUR建てで発行し、そのユーロ建ての金額を帳簿に計上してください。暗号資産の金額は派生的な数値であり、監査証跡のために保管します。
- 作業の大半は例外処理にあります。一部入金、期限切れの請求書、誤ったコインでの入金が該当します。月末ではなく毎日確認してください。
- Webhookをトリガーとして使い、正となるデータはIDで請求書を再取得して確認します。さらに、請求書一覧を毎晩取得してセーフティネットとし、CSVエクスポートの元データにもしてください。
暗号資産決済の消込がカード決済より難しいのはなぜですか？#
ブロックチェーンの送金には注文番号を記録するフィールドがないため、暗号資産決済の消込は難しくなります。Ethereumでは、ERC-20トークン標準（EIP-20）が、送金イベントを`Transfer(address _from, address _to, uint256 _value)`と定義しています。つまり、誰が送り、誰が受け取り、いくら送ったかです。メモ、請求書番号、顧客名を記録する項目はありません。
銀行決済やカード決済はこれとは逆の仕組みになっています。SEPA送金には支払人が記入する送金情報（通信）欄があり、アクワイアラーの決済レポートは各カード取引を加盟店の参照番号とともに一覧にします。会計システムはその参照番号で照合します。
ステーブルコインでは、さらに次の3点が障害になります。
- 金額がきりのよい数字になることはほとんどありません。USDCで建てた250 EURの請求額は279.2846 USDCのような数字になるため、規模が似た2件の請求書が同じように見えてしまうことがあります。
- 支払いは即座に確定しません。Ethereumでは12秒ごとにブロックが生成されますが、ethereum.org（2026年10月更新のページ）によれば、「Ethereumのブロックが確定するまでには約15分かかります。」送金は見えていても、まだ有効とはみなされない場合があります。
- 支払人はミスをします。送金額が不足していたり、二重に送ったり、別のコインで送ったり、請求書の期限切れ後に支払ったりします。
そのため、支払人が支払う前に紐づけを済ませておく必要があります。注文ごとに1件の請求書を発行し、注文IDと専用の支払アドレスを記載します。こうすることで、入金された各送金は、その用途をすでに把握しているレコードに対応づけられます。
暗号資産の請求書レコードにはどのフィールドが必要ですか？#
すべての請求書には、注文、ユーロ建ての価格、オンチェーンの送金、最終ステータスという4つの要素を結びつける固定のフィールドセットが必要です。いずれかが欠けると、担当者が手作業で照合することになります。以下の表は、ItisPayの請求書APIのフィールド名を使用しています。他のプロバイダーでは、同じ概念に別の名前を使う場合があります。
| フィールド | 格納する内容 | 会計上の必要性 |
|---|---|---|
| invoice_id | プロバイダーが割り当てる一意のID | すべての検索とすべての台帳行の主キー |
| order_id | 注文または契約の番号。注文ごとに一意 | ERP、ショップ、CRMとの連携キー。カード決済では自動的に得られる参照番号 |
| order_name | 注文の簡単な説明 | ショップを開かなくても、担当者が例外を確認できる |
| fiat_amount, fiat_currency | EUR建ての価格 | 計上する売上金額 |
| currency, crypto_amount | 請求したコインと請求額 | 支払人に送金を求めた内容を示す |
| actual_crypto_amount_paid | 実際に着金した金額 | 入金不足と超過入金を検出する |
| currency_paid | 請求したコインと異なる場合に、実際に使用されたコイン | 誤ったコインでの入金を確認対象としてフラグ付けする |
| network, address | ブロックチェーンのネットワークと支払アドレス | 送金先を証明する。追跡や返金に必要 |
| transactions (tx_hash, amount, status) | 着金した送金ごとに1行 | 1件の請求書に複数の送金が入ることがある。各ハッシュがオンチェーンの証拠になる |
| status | new, pending, completed, expired, cancelled, paid_partial | 計上、出荷、催促、締めのいずれかを判断する |
| created_at, updated_at, expires_at | タイムスタンプ | 月末のカットオフと、注文が支払われた時点の証明になる |
このうち2つのフィールドが、大部分の役割を担います。`order_id`は、ブロックチェーンの送金では運べない参照番号です。自社システムで設定し、顧客ごとではなく注文ごとに一意にしてください。`transactions`の一覧が重要なのは、請求額が常に一度に支払われるとは限らないためです。送金ごとにハッシュとステータス付きの行が作られるため、どの送金が支払額を構成しているかを確認できます。
暗号資産の金額は、小数点以下をすべて残した状態で別の列に保存してください。総勘定元帳はユーロセント単位で処理されます。暗号資産の列は根拠データであり、帳簿上の金額ではありません。
帳簿に計上すべきユーロ金額はどれか？#
請求書に記載されたユーロ建ての価格を売上として計上します。請求書がEURで発行される場合、プロバイダーは現行レートで暗号資産の金額に換算し、支払人はその金額を送金します。支払いがユーロであなたの口座に決済される場合、請求書上のユーロ金額が売上であり、暗号資産の金額は入金の仕組みに関する技術的な詳細にすぎません。
このため、EURへの換算を伴って暗号資産決済を自動的に受け付けるチームは、暗号資産の会計処理をほとんど必要としません。月末に評価すべきコインが貸借対照表上に存在しないからです。
ステーブルコインを保有し続ける場合は話が異なります。IFRS解釈指針委員会は2019年6月に、暗号資産の保有が通常の事業過程で販売目的とされる場合はIAS 2（棚卸資産）、それ以外の場合はIAS 38（無形資産）に該当するとの決定を下しました。同委員会による暗号資産の定義には、保有者と別の当事者との間に契約を生じさせる資産は含まれません。USDCは異なります。Circleは、USDCが「米ドルと1:1で償還可能」であると述べています。また、2024年7月以降、Circleはフランスの規制当局ACPRによる電子マネー免許に基づき、EUでUSDCとEURCを電子マネー・トークンとして発行しています。保有するステーブルコインの分類方法は、監査人に確認すべき問題です。受領時にユーロで決済すれば、この論点は生じません。
一部入金や誤ったコインはどう扱うか？#
`completed`以外のすべての請求書は、担当者と期限を定めた例外として扱ってください。暗号資産決済の照合作業の大部分はここに集中します。全額支払い済みの請求書は、それ自体で照合が完了します。
以下は、ItisPayのステータスごとの経理上の意味です：
| ステータス | 発生した事象 | 経理の対応 | 出荷・リリースするか？ |
|---|---|---|---|
| new | 請求書は未決済、受領なし | 計上なし | いいえ |
| pending | 送金を確認、まだ確定していない | ステータスの変更を待つ | いいえ |
| completed | 全額支払い済み | ユーロ建ての価格で売上を計上し、注文をリリースする | はい |
| paid_partial | 金額の一部が到着 | 残額を請求、返金、または合意のうえでクローズ | 状況次第 |
| expired | 全額の支払いがないまま期限切れ | 注文をクローズし、遅延送金がないか確認する | いいえ |
| cancelled | 請求書を無効化した | 計上なし。顧客が支払いを希望する場合は再発行する | いいえ |
部分払い#
部分払いは通常、支払人のウォレットまたは取引所が金額から手数料を差し引いたこと、あるいは支払人が金額を誤入力したことを意味します。ItisPayは各送金を個別に記録するため、2回目の送金で請求書を完了させることができます。また、請求書には`allowed_error_percent`設定があります。これは請求書ごとに設定する小さな許容範囲で、わずかに不足した支払いも支払い済みとして扱われます。方針として一度設定し（例：銀行振込でも少額差異として償却する水準）、ケースごとに変更しないでください。
残額が届かない場合は、一定の日数以内に判断してください。不足分を受け入れて償却する、受け取った金額を返金する、または注文をキャンセルする、のいずれかです。支払い済みとされた注文の裏付けとなる入金額が少ない理由を監査人が確認できるよう、判断を請求書の記録に残してください。
誤ったコインまたは遅延支払い#
支払人が請求書と異なるステーブルコインを送金した場合、`currency_paid`フィールドにその内容が表示されます。自動的に計上しないでください。金額とユーロ換算額を確認したうえで、受け入れるか返金してください。期限切れの請求書への送金も同様です。資金はオンチェーンにありますが、注文はクローズされているため、注文を再開するか資金を返却するかを誰かが判断しなければなりません。自社側で注文を無効化した場合は、遅延送金が届く前に記録上クローズとして表示されるよう、APIで請求書をキャンセルしてください（ステータス更新）。
WebhookとAPIは暗号資産決済の照合にどう活用すべきか？#
3つの層を使ってください。Webhookは何かが変わったことを知らせ、請求書を再取得すれば何が正しいかがわかり、夜間の全請求書の取得で最初の2つが見落としたものを捕捉します。
- 各請求書には`callback_url`を含めることができ、プロバイダーはそこにステータス更新を送信します。そのメッセージはトリガーとして扱い、証拠として扱わないでください。
- Webhookを受信するたびに`GET /invoices/{invoice_id}`を呼び出し、そのレスポンスのステータスと金額に基づいて対応してください。APIの呼び出しにはAPIキーが必要なため、エンドポイントへの偽造または再送されたリクエストから保護されます。
- ハンドラーを冪等にしてください。同じステータスが2回届くことがあります。台帳の記録は`invoice_id`とステータスをキーにし、同じ通知が重複して届いても何も変わらないようにしてください。
- 毎晩、`updated_at`の新しい順に請求書を一覧取得し、前回の実行時点まで遡ってページングしてください。また、まだ`new`、`pending`、`paid_partial`の状態にあるすべての請求書を再確認してください。それらを台帳と照合してください。プロバイダーの記録では支払い済みなのに自社では未決のものは、例外として扱ってください。
テスト用に、ItisPayには請求書のステータス変更をシミュレートするエンドポイントと、`invoice_id`または`order_id`で最新のWebhookを再送信するエンドポイントがあります。サーバーがダウンしていた場合は再送信を使用してください。1つの決済オーケストレーションレイヤーを通じて複数の決済手段を扱うチームは、すべての決済ルートに同じパターンを適用します。
会計用のCSVエクスポートはどう作成しますか？#
請求書一覧APIから、請求書1件につき1行、送金1件につき1行の形でエクスポートを作成します。ItisPayでは、`GET /invoices` でステータス、暗号資産の種類、作成日によるフィルタリングができ、日付または金額で並べ替えられ、1ページあたり最大100件の請求書とページ数を返します。小さなスクリプトで1日分または1か月分のページを順に取得し、上の項目表にある列を書き出せます。
ファイルは1つより2つに分けた方が扱いやすくなります。
- `invoices.csv`：invoice_id、order_id、fiat_amount、fiat_currency、currency、crypto_amount、actual_crypto_amount_paid、status、created_at、updated_at。会計担当者がこのファイルを取り込み、売上と照合します。
- `transfers.csv`：invoice_id、tx_hash、amount、currency、transfer status、time。これは監査人向けの証跡ファイルです。
請求書ファイルは、カード決済の決済レポートを扱うのと同じ要領で会計ツールに取り込みます。注文1件につき1行、ユーロ建てで、照合キーは注文IDです。
暗号資産決済の記録に影響するEUのルールは何ですか？#
背景となるEUのルールは3つあります。いずれも加盟店を暗号資産サービスプロバイダー（CASP）にするものではありませんが、存在するデータと保存期間を定めています。
- 資金移動規則（EU）2023/1113。2024年12月30日以降、支払人側の暗号資産サービスプロバイダーは、各送金に支払人と受取人に関する情報が添付されていることを確保しなければなりません。これには氏名や台帳アドレスなどが含まれます（第14条）。このデータは送金に並走して伝えられるもので、送金の中に含まれるわけではありません。セルフホスト型ウォレットとの間で1,000ユーロを超える送金がある場合、関係する側のプロバイダーは、そのウォレットが自社の顧客のものかどうかを評価しなければなりません（第14条および第16条）。これはライセンスを持つプロバイダーの役割であり、決済が審査中に留め置かれる理由の一つでもあります。
- 記録保存。現行のAML指令（EU）2015/849の第40条により、義務対象事業者は、取引記録を業務関係の終了後または取引の実施後5年間保存します。新しいAML規則（EU）2024/1624も5年の保存期間を維持しており（第77条）、2027年7月10日から適用されます。
- DAC8指令（EU）2023/2226。2026年1月1日から、暗号資産サービスプロバイダーは利用者の暗号資産取引を税務当局に報告します。自社の記録は、プロバイダーの報告内容と一致している必要があります。
ライセンスを持つパートナーを通じて取引する場合、MiCA CASPライセンスのガイドで説明しているとおり、MiCAおよびこれらのルールに基づくCASPの義務はパートナーが負います。それでも、注文記録と自社側の証跡は保持する必要があります。
暗号資産の照合で人の判断が必要な場面はどこですか？#
全額支払い済みのケースは自動化で処理できます。それ以外のケースには、責任者の指名と、簡潔な文書化された方針が必要です。
向かないケース
- 返金は取消ではなく、新たな出金送金です。アドレスまたはIBANへの支払いと、それに対応する記録が必要です。
- 取引所アカウントから送金する支払人は、送信元アドレスだけでは特定できないことがあります。送信者ではなく、請求書で照合してください。
- 期限切れの請求書への支払い、重複支払い、誤ったコインによる支払いはいずれも、人による判断が必要です。
- ネットワーク手数料と端数処理によって小さな差異が生じます。許容範囲を一度決めて、それを守ってください。
5つのステップで行う日次の暗号資産決済照合ルーティン#
短い日次ルーティンを回せば、月末の締めは形式的な作業になります。
- 前回の実行以降に作成または更新された請求書をAPIから取得し、請求書ファイルと送金ファイルを更新します。
- `completed` のすべての請求書について、ショップまたはERPに対応する支払い済みの注文があることを確認し、その逆も確認します。
- 例外リストを処理します：`paid_partial`、期限切れの請求書への支払い、誤ったコイン。それぞれ判断を文書に残したうえでクローズします。
- 銀行口座へのユーロの決済入金を、期間内に完了した請求書の合計と照合します。IBANへの決済の段階でバーチャルIBANを使うと、事業ラインごとに資金の流れを分けられます。
- 両方のファイルを少なくとも5年間アーカイブします。
この仕組みを自前で構築せずにステーブルコインを受け付けてユーロを受け取りたい場合、ItisPayがAPI、請求書発行、照合データを提供します：請求書IDと注文ID、送金ごとのハッシュ、ステータス、Webhookです。ライセンス取得、KYC、IBANへの決済は、EUでライセンスを受けたCASP兼決済機関（Payment Institution）のパートナーを通じて行われ、多くのチームはKYBから最初の取引まで1週間未満で進みます。
本記事は情報提供のみを目的としており、法的または規制上の助言を構成するものではありません。
