変更不可能な複式簿記台帳APIの要件とは

マーケットプレイスの台帳の本質は、単に資金の移動を記録するかどうかでは決まりません。ほとんどのシステムはそれを実現しています。真価が問われるのは、決済事業者（PSP）が同じウェブフックを2回送信したとき、セラーへの出金が完了した後に返金が発生したとき、あるいは監査人からセラーの残高が現在の数値に至った経緯を尋ねられたときです。そうした場面において、変更不可能な（immutable）複式簿記台帳を備えているのか、あるいは都合の良い名前が付けられた書き換え可能な単なる残高フィールドに過ぎないのかが浮き彫りになります。

マーケットプレイスプラットフォームにとっての結論は次のとおりです。変更不可能な複式簿記台帳APIとは、財務に影響を与えるすべての事象をバランスの取れた仕訳トランザクションとして記録し、アトミックに（原子的に）計上し、決して上書きせず、残高の導出、外部システムとの突合（リコンシリエーション）、および履歴のエクスポートをプログラムから実行できるようにするものです。その他の要素は、すべてこの中核部分に付随する詳細に過ぎません。

実行残高フィールドではなく、バランスの取れた仕訳

最も明確な試金石は、APIがセラーの残高をどのように表現しているかです。もしその残高がアプリケーションから直接インクリメントされる数値であるならば、それは複式簿記台帳ではありません。一方、残高が計上された仕訳明細からの導出ビューであれば、それは複式簿記台帳の要件を満たしている可能性があります。

すべてのトランザクションには、同額の借方と貸方が含まれている必要があります。買い手が100ユーロの商品代金を支払い、マーケットプレイスが15ユーロの手数料を徴収する場合、台帳には、決済口座の借方100ユーロに対し、セラー買掛金の貸方85ユーロと手数料収益の貸方15ユーロが記録されます。両側の合計は常に一致します。この構造上のルールにより、レポート作成前に多くのバグを水際で防ぐことができます。

仕訳トランザクションには、少なくとも以下の情報が含まれている必要があります。

• 一意で変更不可能なトランザクションID
• 借方および貸方の明細。それぞれに勘定科目、金額、通貨が含まれる
• 発生日（effective date）および計上タイムスタンプ
• ビジネスイベントの種類（販売、返金、出金、チャージバック）
• べき等性キー（idempotency key）
• 注文、決済、または事業者イベントへのソース参照
• ステータス（保留中、計上済み、取消済み）
• それを作成したサービスまたは資格情報

その結果、セラーの利用可能資金は、アプリケーションコード内で誰かが更新した値ではなく、それらの明細に対するクエリとして算出されます。直接書き換えられる残高ではすべての資金移動の理由が失われてしまうため、この点が極めて重要です。Nordletのモデルでは、複式簿記台帳を信頼できる唯一の書き込みパス（authoritative write path）として扱っています。すべてのドキュメントはバランスの取れた仕訳として計上され、データベース自体がバランスの崩れた仕訳を拒否します。これは、マーケットプレイスに会計機能を組み込むすべての人にとって正しいデフォルトの動作です。

取消修正を伴う追記型（append-only）の計上

「変更不可能（immutable）」とは、計上された仕訳をその場で編集できないことを意味します。誤りは消去するのではなく、前進修正（fix forward）によって修正されます。誤った手数料の仕訳に対しては、元の仕訳を打ち消す取消仕訳を行い、その後に意図した結果を記録する正しい仕訳を追加します。両者は元の仕訳にリンクされ、監査履歴には誰がいつ変更を開始したかが記録されます。

APIは、計上済みの会計記録に対する通常の UPDATE および DELETE を拒否する必要があります。ただし、金額、勘定科目、タイムスタンプを変更しない限りにおいて、サポートケースの参照番号などの非財務メタデータを添付することは許可される場合があります。

混同されやすい3つの概念を区別しておくと理解が容易になります。

• 運用の変更不可能性: アプリケーションユーザーが計上された行を変更または削除できないこと。
• 監査の変更不可能性: 履歴が変更されていないことをシステムが証明できること。
• 法定保存期間: 適用される法律で要求される期間にわたり記録が保持されること。

厳格な権限管理、バックアップ、および規律ある取消ワークフローを備えた追記型のリレーショナルデータベースを採用すれば、真に変更不可能な台帳を実現できます。ここではブロックチェーンは必須ではなく、EUの会計データにおいては、ブロックチェーンが追加する改ざん検知のメリットよりも、プライバシーや修正の困難さというデメリットの方が大きくなるのが一般的です。

原子性（アトミック性とべき等性）

マーケットプレイスのイベントはアトミックに計上されなければなりません。すべての仕訳行がコミットされるか、あるいは一切コミットされないかのどちらかです。100ユーロの入金を記録した一方で15ユーロの手数料の記録に失敗した場合、バランスが崩れた誤解を招く結果となり、後で誰かがそれを解明しなければならなくなります。Nordletはこれをアプリケーション層の下で強制しています。遅延データベーストリガーにより、コミット時にすべての計上のバランスが取れていることが確認されるため、バランスの崩れたトランザクションをコミットすることは物理的に不可能です。

べき等性（idempotency）は、多くのインテグレーションで静かに破綻するポイントです。決済システムはネットワーク障害時にリトライを行い、決済ファイルは再送されます。テナントやアカウントのスコープに限定されたべき等性キーがなければ、リトライされた単一のリクエストによって重複した会計データが作成されます。同じキーを持つ繰り返しリクエストは、2つ目のトランザクションを作成するのではなく、元のトランザクションを返す必要があります。

このキーは、発生元のイベント、イベントの種類、事業者のイベントID、法人の識別子、およびリクエストペイロードのハッシュに結び付けられている必要があります。同じキーで異なる金額や通貨のリクエストが届いた場合、APIはそれを衝突（collision）とみなし、新しいペイロードを暗黙的に受け入れるのではなく、拒否する必要があります。暗黙的な受け入れは監査証跡を形骸化させる原因となります。NordletのIdempotency-Key ヘッダーはこのように動作します。同じキーとペイロードによるリトライは保存されたレスポンスを再送し、同じキーで異なるペイロードが送信された場合は idempotency_key_reuse エラーとして拒否されます。これは小規模な機能に見えますが、突合処理に対して絶大な効果を発揮します。

マルチパーティの分割会計

マーケットプレイスの注文は、単一の資金移動では完結しません。1件の販売で、買い手の資金、セラーの売上金、マーケットプレイスの手数料、決済処理手数料、手数料に対する付加価値税（VAT）、配送料、およびリザーブ（留保金）など、複数の要素が絡み合うことがあります。台帳は、これらを1つのネットの数値に押し潰すのではなく、個別に保持する勘定科目構造を備えている必要があります。

ここで、よくある誤った前提に反論しておく価値があります。決済事業者の「スプリットペイアウト（分割出金）」機能は、マーケットプレイスの会計と同一ではありません。受取人間で資金を分割することは、現金をルーティングしているに過ぎません。それは、獲得した手数料、徴収したVAT、返金義務、または留保されたリザーブの完全で変更不可能な記録を提供するものではありません。依然として自社の台帳が必要であり、決済事業者とそれを突合させる必要があります。

また、マーケットプレイスの台帳は、セラーの残高を複数の状態に分けて管理する必要があります。

残高ステータス	表す内容
保留中 (Pending)	イベントに紐づいているが、まだ出金対象になっていない資金
利用可能 (Available)	リリース、リザーブ、返金、および紛争のルールをクリアした資金
留保 / リザーブ (Held / reserved)	チャージバック、返品、または不正対策のために保留されている金額
出金済み (Paid out)	セラーに送金された金額
マイナス / 回収可能 (Negative / recoverable)	返金や手数料が利用可能資金を超過したことでセラーが負っている金額

保留中から利用可能への資金移動自体も、単なるラベルの書き換えではなく、バランスの取れた仕訳トランザクションとして実行されるべきです。

取消、返金、およびマイナス残高

マーケットプレイスの資金は双方向で動き、多くの場合、順序が前後します。困難なケースとして、出金後の返金や、数週間後に到着するチャージバックがあります。本格的な台帳では、セラーの利用可能資金が返金をカバーできない場合にどう処理するかを定義します。マイナス残高の作成、セラー売掛金への振替、リザーブからの引き出し、あるいはさらなる出金の制限などを行います。

これらのイベントはいずれも、元のトランザクションを参照し、それを保持していなければなりません。台帳は返金の会計上の結果を記録するものであり、マーケットプレイスの返金ポリシーや法的責任を決定するものではありません。この境界線を明確に保つことで、設計時の混乱を防ぐことができます。

通貨と精度

クロスボーダーのマーケットプレイスでは、明示的な通貨のハンドリングが求められます。金額にはISO 4217の通貨コードを使用し、浮動小数点数ではなく、整数による最小通貨単位（minor units）または固定精度の10 décimal（小数点）文字列による正確な表現を用いるべきです。暗黙的な丸め処理は避けます。換算が発生した場合、台帳は元の金額、為替レート、レートのソース、タイムスタンプ、および換算後の金額を保持し、丸めの差額は定義された勘定科目に計上する必要があります。

バランスの取れた単一のトランザクションにおいて、明示的な為替メカニズムなしに複数の通貨を混在させるべきではありません。もしそれを許容すると、月次決算の際にレポートが現実と乖離し、原因の特定が極めて困難になります。

外部システムとの突合

内部でバランスが取れているだけでは、その台帳は信頼できる情報源（オラクル）とはなり得ません。外部の世界、すなわち決済事業者のトランザクション、事業者手数料、決済レポート、銀行明細、出金ファイル、チャージバックレポートと一致している必要があります。

成熟したAPIは、外部からインポートされたイベントや、一致（matched）、部分一致（partially matched）、不一致（unmatched）、重複（duplicate）、金額不一致（amount mismatch）、要確認（needs review）といったマッチングステータスをサポートしています。突合の差異は、明確な例外レコードまたは会計エントリとして作成されるべきであり、台帳の履歴をひそかに書き換えてはなりません。銀行の突合と決済のマッチングに対するNordletのアプローチはこの原則に基づいています。インポート済みの明細やStripeのエクスポートは重複してインポートされず、決済候補は金額、参照番号、相手方、IBANによってスコアリングされ、ワンクリックマッチングで通常のケースを処理し、例外は隠蔽せずに表面化させます。

APIが尊重すべきEUの境界、そして尊重できない境界

ここは、マーケティング上の主張が現実から乖離しやすい領域です。台帳はEUの義務への対応を支援しますが、それ単体で要件を完全に満たすわけではありません。

VAT（付加価値税）。 台帳は、管轄区域、税率、税区分、および税率の決定方法といった税務上重要なディメンションを保持する必要があります。セラーから買い手への販売と、マーケットプレイスの手数料を区別し、手数料に対するVATと単に通過するだけの資金を分離しなければなりません。Nordletは、国別のVAT計算、VIESの検証、i.SAFのデータ生成に加え、EUのマーケットプレイスが直面するOSSおよびIOSSのシナリオを処理します。台帳は税務上の証拠および税務エンジンとして扱い、税務上の助言として扱ってはなりません。

DAC7。 プラットフォームの報告規則では、セラーの身元、管轄区域、取引合計、手数料、返金、および出金の間に信頼性の高いリンクが存在することが求められます。バランスの取れた台帳は取引の証拠を生み出しますが、セラーが報告対象であるかどうかを判定するものではなく、KYC、オンボーディング、または報告ワークフローの代替にはなりません。取引会計と規制上の報告は、別個のものとして管理してください。

PSD2と資金の保管。 資金の移動を記録することは、認可された決済サービス事業者（PSP）になることや資金を保護することとは異なります。台帳は資金の流れと関係者を明確にする必要がありますが、それ単体で決済サービスの認可を提供したり、特定の口座に現金が保持されていることを証明したりすることはできません。それは依然として、規制上の役割および利用しているPSPに関する問題です。

GDPR（EU一般データ保護規則）。 変更不可能性は、データ保護原則と実際の緊張関係を生み出します。最も安全なアーキテクチャは、金銭的事実を変更不可能なコアに保持し、個人データをその外部に置くことです。仕訳行では、安定した仮名化されたセラーおよび顧客の参照を使用します。変更可能な個人詳細情報は、独自の保持および削除ワークフローを備えた、アクセス制御された別のシステムに保存します。「変更不可能」とは、すべての決済ペイロードを永遠に保持してよいという免罪符ではありません。

台帳APIを評価するためのチェックリスト

機能のラベルなど安価なものです。代わりにサンドボックス環境で動作をテストしてください。以下のシナリオを実行し、その証拠を確認してください。

• セラーとマーケットプレイス間で分割された100ユーロの注文を計上し、明示的な勘定科目を持つバランスの取れた仕訳を確認する。
• 同じリクエストを2回送信し、トランザクションが1つだけで重複がないことを確認する。
• 計上されたエントリを編集しようとし、それが拒否されるか、または非財務メタデータに限定されることを確認する。
• 誤った手数料を修正し、リンクされた取消仕訳に加えて修正済みの仕訳が作成されることを確認する。
• 出金後に部分返金を発行し、必要に応じてセラー売掛金またはマイナス残高を伴う追跡可能な返金が行われることを確認する。
• 事業者のウェブフックを再送し、重複が検知されることを確認する。
• 複数通貨の決済を処理し、FXの詳細と換算会計を確認する。
• 期間終了時のセラー残高をクエリし、文書化されたカットオフを伴う再現可能な結果を確認する。
• 事業者の決済データをインポートし、履歴を損なうことなく例外ステータスを伴うマッチングが行われることを確認する。
• 1ヶ月間のアクティビティをエクスポートし、完全で、ページ分割された、再現可能な抽出データを確認する。

最も強力な証拠は、ドキュメントと再現可能なテストです。「リアルタイム」「監査対応」「変更不可能」といった言葉は、その裏にあるデータモデル、エラーセマンティクス、保持動作が伴わなければ何の意味も持ちません。

私たちが最初に確認するポイント

明日マーケットプレイス向けの台帳APIを評価するとしたら、他の何を見るよりも先に、次の2つの点から始めます。第一に、セラーの残高が書き換え可能なフィールドではなく仕訳明細から導出されていることを証明させます。下流のすべての処理がそれに依存しているからです。第二に、同じウェブフックを再送し、正確に1つの会計結果が得られることを確認します。これら2つのテストは、機能リストのどれよりも、基盤となる設計の品質を雄弁に物語ります。

その上で、チームの開発スピードを左右するAPIファーストの考慮事項が重要になります。型付きSDK、sale_invoice.paid などのイベント向けウェブフック、動作するサンドボックス環境、そして締められた月を保護するためのピリオドロック（期間ロック）などです。Nordletはこのモデルを中心に構築されており、アプリ経由と同じ機能セットがAPI経由でも公開されています。これにより、プラットフォームはサードパーティのチェックアウトシステムを後付けすることなく、自社製品内で監査対応の帳簿を運用できるようになります。このような台帳がマーケットプレイスのスタックにどのように組み込まれるかの全体像については、マーケットプレイス会計のための複式簿記台帳APIガイドをご覧ください。

FAQ

複式簿記は会計が正しいことを保証しますか？

いいえ。台帳は完全にバランスが取れていながら、間違った勘定科目に計上されていたり、誤ったVAT処理が適用されていたり、間違ったセラーに資金が帰属していたりする可能性があります。バランスの維持は、算術的エラーやトランザクションの片側の漏れを検出するための構造上の統制に過ぎません。ビジネスロジックがイベントを正しくマッピングしているかどうかについては何も保証しません。そのため、バランスチェック単体よりも、実際のシナリオに基づいたサンドボックスでのテストが重要となります。

決済事業者の台帳だけでマーケットプレイスに十分ですか？

通常は不十分です。PSPは自社システム内の資金を追跡しますが、これは資金移動や出金には便利です。しかしマーケットプレイス側には、手数料収益、セラーに対する負債、手数料に対するVAT、返金、リザーブ、紛争、および経営報告のための独自の記録が依然として必要です。これら2つのシステムは突合されなければならず、事業者のビューをそのまま自社の会計とみなしていると、監査の際に表面化するギャップを残すことになります。

台帳を変更不可能にするためにブロックチェーンは必要ですか？

いいえ。厳格な書き込み権限、制御された修正ワークフロー、監査ログ、および信頼性の高いバックアップを備えた追記型のリレーショナルストアを使用すれば、運用の変更不可能性と監査の変更不可能性を実現できます。ブロックチェーンは分散型の改ざん検知を追加しますが、EUの会計要件やGDPRの要件に逆行するプライバシー、パフォーマンス、および修正の困難さをもたらします。ほとんどのマーケットプレイスにとって、それは解決する必要のない問題を解決しているに過ぎません。

変更不可能な台帳はGDPRのもとでデータを永遠に保持できますか？

法律で義務付けられた期間にわたり会計記録を保持することは問題ありません。台帳が変更不可能であるという理由だけで、完全な個人データや決済ペイロードが無期限に保持することは認められません。金銭的事実と仮名化された参照情報は変更不可能なコアに保持し、個人詳細情報は適切な保持および削除機能を備えた別のシステムに保持します。変更不可能性が適用されるのは財務イベントに対してであり、それに付随するすべてのデータに対してではありません。