注文額・決済代行の明細・入金額が違うとき、何を基準に照合するか

課題と判断基準

注文画面では19万ウォンなのに、口座には13万5,800ウォンしか入っていません。同じ日付の注文ファイルと決済代行会社（PG）の精算ファイルを並べても合計が合いません。取消が含まれるのか、手数料が多く引かれたのか、まだ入金されていないのかを区別する必要があります。後半で、この数字を架空のデータで検算します。

照合の基準は、ある画面の総額ではなく、同じ取引を結び付けた記録です。 注文と承認・取消を結び、そのうち今回の精算に含まれる取引を選んで、支払明細と銀行入金を照合します。注文額と入金額の差がすべて誤りとは限らず、合計が一致しても全取引が正しく反映されたとは限りません。

実務では問いを分けます。注文システムは「いくら受け取るべきだったか」、PGの取引記録は「いくら承認・取消されたか」、精算明細は「何を反映していくら支払うか」、銀行記録は「実際にいくら入ったか」を確認する資料とします。異なる問いへの答えを一つの列に入れないことが出発点です。

本記事は2026年9月26日に確認した公式文書を基に、韓国のPGの具体例としてToss Paymentsを使います。以下の関連付けと例外処理は実装に向けた設計案です。会計上の収益認識や税務処理の基準を定めるものではありません。

同じ日付のファイルから合わせると範囲がずれる

まず比較表の「日付」列の意味を明確にします。

精算サイクルと手数料条件は契約に照らして確認します。Toss Paymentsの説明でも精算売上日は決済日と常に同じではありません。注文期間で選んだ結果と入金期間で選んだ結果をそのまま差し引くと、そもそも異なる取引集合を比べる可能性があります。精算の概念とサイクル。

Toss Paymentsの取引照会はtransactionAt基準で、当日の記録を照会できます。精算照会は翌日から可能で、dateTypeの既定値はsoldDate、支払日基準ではpaidOutDateを使います。まだ照会できない精算記録と、実際の欠落を区別します。 コアAPI：取引・精算照会。

照会条件とともに「何時まで収集を完了したか」も残します。終了日に今日を指定しても、収集が午前中に終わったなら今日全体を確認したことにはなりません。照会範囲の境界、タイムゾーン、全ページの収集完了を決めずに不一致を通知すると、データ収集の問題と取引の問題を区別しにくくなります。

一つの注文を一行の取引に縮めない

一つの注文を二回に分けて支払う場合や、一つの決済を何度も一部取消する場合を表現できる必要があります。Toss Paymentsも承認と各取消・一部取消を別々の取引として説明しています。注文の現在残高だけを保存すると、どの取消がどの精算に含まれたかを遡れません。取引の定義と記録。

次の対応表を推奨します。右側の独自識別子は、PGが自動発行するフィールドではなく、内部で管理する値です。

Toss PaymentsではpaymentKeyが決済を、transactionKeyが承認・取消取引を識別します。取消配列にも個別取引キーがあります。コアAPI、決済の取消。

保存キーには供給者、加盟店ID、テスト・本番環境も含めます。内部注文番号が同じという理由で、別の加盟店や環境の取引を結び付けてはいけません。一つの業務注文を複数の決済要求に分けるサービスでは、業務注文IDとPGに渡す要求別注文IDを分けて管理する方が安全です。

精算グループIDが明示的に提供されない場合もあります。Toss Paymentsの公開Settlementスキーマには、共通の支払グループIDや銀行入金参照は記載されていません。Settlementオブジェクト。同じ支払日の行を集めただけで、一件の銀行入金の確定構成要素として扱わないでください。加盟店・通貨・支払明細・入金通知を確認してから対応表を確定し、根拠が足りなければ候補グループとして残します。

海外決済も扱うなら供給者ごとの差異を残します。StripeのPayout reconciliation reportは自動支払を中心に取引グループを説明し、手動支払には別のBalanceレポートを案内しています。その構造を韓国のPGにそのまま適用できる根拠にはなりません。Stripeの支払照合レポート。

関連付ける前に金額と状態の意味をそろえる

原本CSVを一枚のシートにまとめる作業と、照合可能なデータを作る作業は異なります。次の項目を先に収集ルールに入れます。

金額・通貨・符号。 供給者の単位と通貨を確認し、元の値も保存します。本記事の例はKRWのウォン単位の整数です。他の通貨やレポートに同じ単位を強制しないでください。正確な金額計算が必要な場合、PostgreSQL文書も浮動小数点ではなく正確な数値型を案内しています。十分な範囲の整数か明示した小数精度を選び、丸めは供給者の実際のルールに合わせて別に定めます。PostgreSQLの数値型。

原本の取消額が正か負かを確認してから内部符号に変換します。すでに負の取消額をもう一度引いたり、取消後残高から取消額を再度差し引いたりしないようにします。換算が必要なら決済通貨と精算通貨、適用レートと時点、両替関連項目を区別します。換算根拠のないウォンとドルは合計を分けます。

取引状態・精算状態・入金状態。 三つを一つの「完了」にまとめません。Toss PaymentsのPayment.statusでDONEは決済承認状態、カードのacquireStatusは売上確定処理の状態です。paidOutDateも銀行入金の証拠に代わるものではありません。コアAPIの状態・精算フィールド。

内部では次のように列を分けることを提案します。これらはPGの公式状態コードではありません。

手数料・重複・訂正。 精算の控除総額と構成項目を分けます。Toss Payments文書はfees、supplyAmount、vat、payOutAmountを区別しています。Settlementオブジェクト。複数のフィールドをすべて独立費用として足さず、合計と内訳の包含関係を確認します。本記事は付加価値税率や仕訳方法を定めません。

取引を結ぶキーと原本行の重複確認キーも区別します。取引ファイルと精算ファイルを分けて管理し、一取引が手数料・調整など複数の精算行に分かれる形式なら、供給者の行IDや項目・順番も残します。取引キーが同じという理由で別の精算行を削除したり、関連行の数だけ決済元本を重複加算したりしてはいけません。

ファイル名が変わっても新しい取引になるわけではありません。原本ファイルのハッシュと収集履歴を残し、その形式の行識別基準で重複を確認します。同じキーで内容が同じなら再収集、金額や状態が変われば訂正候補として記録します。「最後のファイルが正解」というルールで過去の値を上書きしません。

19万ウォンが13万5,800ウォンになる過程を検算する

設計例であり、実際の顧客データ、特定PGの応答、契約手数料、精算日程ではありません。 架空の一加盟店、KRWのウォン単位、2026年9月21日23:59:59韓国時間までに収集した資料を仮定します。当初注文額には最終請求額が反映され、すべての注文が承認されています。以下の取消と手数料以外に、追加税控除・保留・両替・調整・チャージバックはありません。

O-Aは10万ウォン決済後に2万ウォンを取消しました。O-Bは6万ウォンを二決済に分けました。O-Cの3万ウォンは今回の支払グループの外にあり、後の精算で確認します。

次は同じ注文を個別取引イベントに展開した表です。手数料控除は支払額から引く値を正、戻す値を負で示します。取消時に600ウォンが戻ることも、この例だけの仮定です。

B-01は精算原本の四取引行を確認して付けた内部グループIDです。精算基準日は9月14日・15日、支払予定日は9月21日という架空明細を仮定します。基準日が異なる明細も、支払明細で同じグループと確認できれば一緒に照合できます。

銀行記録は入金取引D-01、入金日9月21日、金額135,800ウォンです。PG入金通知と銀行明細に対応可能な参照REF-01があり、担当者がREF-01とB-01の対応を確認済みと仮定します。

したがって検算は次のとおりです。

全注文190,000ウォン − 確認済み取消20,000ウォン = 純決済170,000ウォン
純決済170,000ウォン − 今回の対象外取引30,000ウォン = グループ取引増減140,000ウォン
グループ取引増減140,000ウォン − 純手数料控除4,200ウォン = 支払額135,800ウォン
支払額135,800ウォン − 対応銀行入金135,800ウォン = 照合差額0ウォン

純決済と銀行入金の差34,200ウォンは、手数料4,200ウォンと対象外元本30,000ウォンで説明できます。30,000ウォンは次回の入金額そのものではなく、今回の支払にまだ含まれていない取引元本です。後の手数料と精算明細を再確認する必要があります。この式をすべての期間・PGに通用する万能式にしてはいけません。

もう一つ落とし穴があります。T-A2の−19,400ウォンとT-B2の+19,400ウォンが同時に欠けても、支払合計は135,800ウォンのままです。 合計だけを検査すると取消一件と承認一件の欠落を見逃します。B-01の構成要素がT-A1・T-A2・T-B1・T-B2の四件で、各キーと金額が原本に対応するかも確認します。

自動で関連付ける項目と人が確認する項目を分ける

自動一致は、識別根拠と金額検算の両方を満たす場合に限定します。供給者・加盟店・通貨が同じで、取引キーで結ばれ、承認・取消の意味が正しく、同じ行が複数グループに割り当てられていないか確認します。銀行段階でも支払参照と構成要素の確認が必要です。

振込人も金額も同じでも対応可能な明細が二つあれば、「一致候補が二件」です。最初の行に結び付けたり、合計が合う組合せを探して確定したりしません。金額と日付は候補を絞る条件で、同一性を証明するキーではありません。人が確定する場合も、選んだ原本、根拠、確認者、時刻を残します。

許容差をすべての差額を消す仕組みにもしません。対象項目・通貨・丸め根拠・上限を定め、許容範囲として処理した差額を別集計します。説明できない差は1ウォンでも未説明のまま残す方が適切です。

精算済み決済の後日取消も別に扱います。Toss Paymentsの取消ガイドは次回精算金からの相殺を案内しています。過去の入金額を取消後の数字で上書きせず、元決済と取消、後の反映を関連付け、過去の記録と後続の変化を説明します。決済の取消。

表の保留・調整・チャージバックは、すべてのPGに同じフィールドがあるという意味ではありません。例えばStripeは残高取引の紛争・紛争返戻・準備金を別に分類しています。韓国のPGでは実際の契約・明細・通知で確認した項目だけを対応させ、不明なコードは「その他手数料」ではなく未分類例外とします。Stripeのレポート分類。

ファイルを再取得しても以前の判断を説明できるようにする

照合結果だけを保存すると、原本が訂正されたとき、前回締めとの差を説明しにくくなります。収集原本、計算結果、人による例外判断を分けて管理します。

収集記録には出所・加盟店・期間・照会条件・収集時刻・ハッシュ・完了状態を残します。計算記録には原本版、変換ルール版、照合ルール版、実行IDを結びます。例外記録には担当者・確認期限・処理根拠・再処理履歴・再開の有無を残します。同じ原本とルールで再計算した結果が違えば、取引差より先に処理過程を調べられます。

訂正版は新しい原本版として保存し、どの既存行を置き換え・調整するかを供給者文書と確認結果で関連付けます。過去の確定結果を残して影響するグループだけを再計算し、閉じた例外を再開する条件も定めます。訂正ファイル全体を過去ファイルにそのまま加えると、再収集と新取引を混同します。

原本保存は認証情報や個人情報の無制限保存を意味しません。収集範囲を絞り、アクセス権と保存期間を定めます。照合確認には参照権限を優先し、返金実行・支払要求・会計伝票確定の権限を分けます。照合プログラムは差を見つける役割であり、差の検出だけで自動的に資金を動かしてはいけません。

小規模なチームは表計算から始めてもよい

資料の出所が少なく、キーが安定し、担当者が例外を処理できるなら、新システムの購入前に原本保存・対応表・差異分類を整理できます。まず一加盟店、一通貨、一支払グループで計算を説明します。説明できないまま関連付けだけを自動化すると、誤った照合も速く繰り返されます。

複数加盟店・チャネルで訂正ファイルが繰り返され、過去結果の再現が難しく、担当者不在の例外が積み上がるなら、収集と履歴管理の自動化を検討します。判断基準は自動一致率の向上だけではありません。未分類差額、支払期限超過、キーのない記録、重複割当、処理期限を過ぎた例外が見えるかも確認します。

既存の決済精算の照合ルール・運用ランブック書式には、共通キー、不一致処理、ランブックを整理する構造があります。本記事の例で関連付けを理解したうえで、実際の業務ルールをその資料に記録できます。

整理する問いは四つです。何の取引か、どの精算に入ったか、実際に入金されたか、残る差は誰が確認するか。 これらに答えて初めて差額ゼロに意味があります。精算額は会計上の売上や利益と同じではなく、照合記録は会計元帳に代わりません。

データの出所、関連付けキー、例外処理範囲を一緒に設計する必要がある場合は、IXC精算自動化サービスの対応範囲を確認できます。