AIで精算システムを構築する前に決めるべき7つの方針

精算は単なる減算機能ではない。注文ごとの権利と義務を確定し、プラットフォームが保管または支払うべき資金を分離し、返金・紛争・税金・送金失敗まで追跡する元帳システムである。

生成AIはコードやテストの作成を支援できるが、精算ポリシーの責任主体にはなれない。ポリシーが未定義であれば、AIはもっともらしいデフォルト値を作成したり、例外を見落としたりする可能性があり、その結果、過払い、重複支払い、税務上の誤り、または流動性事故につながり得る。

2024年 티몬・위메프事態から確認すべき原則

2024年の티몬と위메프による大規模な販売代金の未精算は、精算の遅延が販売者と消費者にどれほど大きな連鎖的被害を与え得るかを示した。ただし、事態の原因を長い精算サイクルだけに断定してはならない。資金運用、流動性、ガバナンス、内部統制など、複数の要因を併せて検討する必要がある。

運営者が得るべき重要な教訓は明確である。

• まだ支払っていない販売代金を、自由に使える会社の現金と見なさない。
• 精算サイクルが長いほど、1回の障害や流動性不足にさらされる未払い残高が増える。
• 販売代金残高と実際の保管資金を毎日照合する。
• 精算条件と遅延理由を販売者に透明性をもって公開する。
• 関連法令、契約構造、PGサービスの範囲をそれぞれ確認する。

販売代金の法的帰属と保護方法は、取引構造によって異なる場合がある。したがって、日常的には「他人のお金」であるという警戒心を維持しつつ、実際の会計・法務処理は契約と現行法令に基づいて判断しなければならない。

実装前に決めるべき7つの精算ポリシー

1. 精算基準日と支払サイクル

まず、注文がいつ精算可能な状態になるかを定義する。注文日や決済日だけを基準にすると、配送前のキャンセルや返品可能な金額が支払対象に含まれる可能性がある。

一般的な商品取引では、次のような流れを設計できる。

1. 決済承認
2. 配送完了
3. 購入確定、または約定期間の経過による自動確定
4. 返品・紛争・異常取引の有無を検査
5. 精算対象を確定
6. 支払バッチに編入
7. 送金および照合完了

必ず決定すべき項目は次のとおりである。

• 商品、デジタルコンテンツ、サービスなど、取引タイプ別の精算基準イベント
• 自動購入確定までの期間と起算時点
• 毎日、毎週、または月単位の支払サイクル
• 週末と祝日の処理方法
• 精算締切時刻と、締切後の取引が帰属するバッチ
• 最低支払額と少額残高の繰越有無
• 販売者ランク別に異なるサイクルを許可するかどうか
• 法令または契約上の支払期限を超過していないか確認する手続き

精算可能日と実際の支払日は区別しなければならない。たとえば、eligible_atは支払条件を満たした時刻、scheduled_payout_atは支払バッチに編入された時刻、paid_atは送金成功が確認された時刻である。

2. 手数料計算と精算明細書

販売者に最終支払額だけを表示すると、検算が難しくなり、問い合わせや紛争が増える。注文単位の明細と期間別の合計がどちらも必要である。

手数料ポリシーには、計算基準も明記しなければならない。割引前の販売価格と割引後の決済額のどちらを基準とするか、送料と付加価値税を含めるか、一部返金時に手数料をどのように戻すかを決める必要がある。

金額は浮動小数点型で計算しない方が安全である。ウォンのように最小通貨単位が整数の場合は整数で保存し、外貨や小数計算が必要な場合は、固定小数点型と通貨別の丸め規則を使用する。

3. 返金とマイナス精算

すでに販売者へ支払った注文が、後から返金される場合がある。この場合、返金額と払い戻す手数料を調整元帳に記録し、次回の支払額から差し引かなければならない。

たとえば、今回の精算予定額が30万ウォンで、以前の注文に関する返金控除額が40万ウォンであれば、次のように処理できる。

• 今回の支払額：0ウォン
• 未回収残高：マイナス10万ウォン
• 次回精算へ繰り越す金額：10万ウォン控除

ポリシーには次の項目が必要である。

• 一部返金時の商品価格、送料、手数料の配分方法
• マイナス残高の繰越期間と相殺順序
• 長期間販売実績がない販売者から回収する方法
• 保証金や支払準備金を設定できる契約上の根拠
• 販売者の退会前に未決済義務を確認する手続き
• 返金取消や紛争結果の変更時に逆仕訳する方法

既存の取引記録を上書きせず、原取引と調整取引を関連付けなければならない。そうすることで、どの返金がどの精算を変更したのかを再現できる。

4. 支払保留と解除

販売者アカウント全体の支払いを一律に停止するのではなく、注文、金額、または理由別に保留できなければならない。代表的な保留理由は次のとおりである。

• 消費者紛争または返品手続き中
• 自己取引、アカウント乗っ取り、または異常決済の疑い
• 販売者本人・事業者・口座認証の失敗
• 裁判所、捜査機関、または関係機関からの適法な要請
• 契約上の精算書類の未提出

各保留記録には、対象金額、理由コード、根拠資料、開始時刻、検討期限、担当者、解除条件を保存する。販売者向け画面には、公開可能な範囲で保留金額と理由、必要な措置、問い合わせ方法を表示する。

運営者が恣意的に保留を繰り返せないよう、作成権限と解除権限を分離し、高額な保留の解除には二重承認を適用することが望ましい。

5. 販売代金の分別管理とPG・エスクロー構造

未払いの販売代金と会社の運営費を同じ利用可能な現金として管理すると、流動性不足がそのまま未精算に波及する可能性がある。少なくとも内部元帳と口座運用において、販売代金関連資金と運営資金を明確に区分し、毎日残高を照合しなければならない。

ただし、別口座を開設したという事実だけで、法的な倒産隔離や完全な資金保護が自動的に成立するわけではない。信託、預託、支払保証など、保護方法の効力と義務については、適用法令および契約構造を検討する必要がある。

プラットフォームが決済と支払過程でどのような役割を果たすかによって、電子決済代行業など、電子金融取引法上の登録問題が生じる場合がある。すべてのプラットフォームが一律にPG登録の対象となるわけでもなく、単に精算データを計算したという理由だけで常に登録対象となるわけでもない。実際の資金の受領・保管・伝達方法と契約関係に基づいて判断しなければならない。

初期段階のプラットフォームは、登録PGが提供する決済、エスクロー、または販売者別の分割精算サービスを検討できる。ただし、PGを利用しても次の責任はなくならない。

• どの注文をいつ支払対象として渡すかを決定
• 手数料と調整額の計算
• 返金とマイナス繰越の管理
• 販売者情報と口座の検証
• PGの処理結果と内部元帳の照合
• 障害と支払失敗への対応

エスクロー義務と例外も、取引タイプや決済手段などによって異なるため、電子商取引法と下位規則を確認しなければならない。

6. 源泉徴収、付加価値税、証憑

「個人販売者からは無条件に3.3%を差し引く」という規則は正確ではない。3.3%は一般に、事業所得に対する所得税3%と個人地方所得税0.3%を合わせた表現である。実際の源泉徴収の有無は、販売者の事業者登録の有無だけでなく、所得の性質、契約関係、支払項目、例外規定によって異なる。

登録と契約の段階で、次の情報を受け取る必要がある。

• 個人、個人事業者、法人などの販売者タイプ
• 国内外の居住者または法人であるかどうか
• 課税、免税、簡易課税などの税務上のステータス
• 事業者登録番号や住民登録番号など、法定申告に必要な情報
• 所得の性質と支払理由
• 税金計算書、計算書、または源泉徴収票などの必要な証憑

事業者である販売者についても、「常に税金を一切控除せず100%支払う」と一般化してはならない。プラットフォーム手数料を差し引く契約であれば、取引総額、手数料、付加価値税、実際の送金額を区分しなければならない。プラットフォームが提供した仲介サービスの手数料に対する税金計算書の発行主体と時点も、契約および税法上の供給関係に合わせて決定する。

源泉税には通常、支払日が属する月の翌月10日までに申告・納付する仕組みが適用されるが、例外や期限変更の可能性があるため、実際の申告時点における規則を確認しなければならない。税務規則をコードに固定するよりも、適用開始日と終了日を持つバージョン型ポリシーとして管理する方が安全である。

7. 支払失敗、精算管理画面、監査ログ

正常に生成された支払いも、口座エラー、名義人の不一致、取引制限、銀行メンテナンス、またはPG障害によって失敗する可能性がある。失敗を単に「未払い」と表示せず、ステータスと再処理規則を細分化する。

推奨ステータスの例は次のとおりである。

• scheduled：支払予約
• submitted：銀行またはPGへリクエストを送信
• processing：外部機関で処理中
• paid：成功確認
• failed_retryable：再試行可能な失敗
• failed_final：情報修正などが必要な最終的失敗
• reversed：成功後の取消または返却

再試行には、同一の支払いを識別する冪等性キーを使用しなければならない。応答遅延を失敗と誤認して再び送金すると重複支払いが発生する可能性があるため、外部取引番号を照会し、既存リクエストの結果を先に確認する。

監査ログには次の情報を残す。

• 行為者と使用した運営者アカウント
• 実行時刻とアクセス元などのセキュリティ情報
• 変更前後の値
• 保留・解除・手動調整の理由
• 承認者と実行者
• 関連する注文、精算バッチ、外部取引番号
• 失敗コードと再試行履歴

監査ログは一般の運営者が修正または削除できないように保護し、個人情報と金融情報には、最小限の収集、アクセス制御、暗号化、保存期間のポリシーを適用する。

精算データモデルの最小構成

AIに画面から作らせるより、次の元帳を先に定義することが望ましい。

各元帳には、通貨、ポリシーバージョン、作成時刻、原取引との関連付けキーが必要である。注文ステータスを変更するだけで、過去の精算金額が気付かれないまま変更されてはならない。

必ず維持すべき統制規則

精算システムは、次のような不変条件を自動的に検査しなければならない。

• 1つの精算項目は、正確に1人の販売者と1件の原取引に関連付けられる。
• 同一の支払キーで2回送金しない。
• 支払完了額、未払額、保留額、調整額の合計が元帳と一致する。
• 手動調整には理由と承認者が存在する。
• すでに締め切った精算は修正せず、逆仕訳と新しい調整によって訂正する。
• 内部の販売代金関連残高とPG・銀行残高との差異を毎日調査する。
• 税金と手数料の計算には、適用したポリシーバージョンを記録する。

AIに渡すポリシー仕様の例

次のように要件を構造化すると、漏れを減らすことができる。

注文ステータスと精算ステータスを分離して設計する。取引タイプ別の購入確定条件、毎週水曜日の支払バッチ、休日処理、手数料基準、一部返金の配分、マイナス繰越、取引ごとの支払保留、源泉徴収ポリシーのバージョン、支払の冪等性キー、変更不可能な監査ログを実装する。金額は整数または固定小数点で処理する。すべての手動調整には、二重承認と理由が必要である。実装前に、最低支払額、自動購入確定期間、長期マイナス残高の回収、保留期限、再試行回数など、未決定のポリシーを質問リストとして提示せよ。

AIにはコードだけを依頼せず、次の成果物も併せて要求する。

• ステータス遷移図と例外一覧
• データベーススキーマと制約条件
• 権限・承認体系
• 正常系、境界値、障害、重複リクエストのテスト
• 日次照合レポートの形式
• 障害復旧と手動処理の手順
• 個人情報と金融情報の保護チェックリスト

リリース前チェックリスト

• 取引タイプ別の精算基準日が文書化されている。
• 販売者が精算明細を注文単位で検算できる。
• 一部返金とマイナス繰越のテストに合格している。
• 保留理由、期限、解除権限が定義されている。
• 販売代金関連資金と運営資金の管理基準が区分されている。
• PG・エスクロー・電子金融業への該当有無を専門家と確認している。
• 販売者および所得タイプ別の税務処理を検討している。
• 重複支払いの防止と失敗時の再試行テストを完了している。
• 銀行・PG・内部元帳の日次照合が可能である。
• 運営者による手動変更が監査ログに残る。
• 精算障害時の販売者への告知と問い合わせ対応手順がある。

結論

安全な精算システムの出発点はAIプロンプトではなく、明示的なポリシーと分離された元帳である。AIは確定した規則をコード、テスト、文書へ移すためのツールとして活用し、資金保管構造と電子金融・税務上の判断は、PG、会計・税務専門家、および法律専門家とともに検証しなければならない。