EWAにおけるSettlementとReconciliationの違いとは？

SettlementとReconciliationは関連するものの、目的が異なるレイヤーです。EWAの構造では、Settlementは取引または精算期間の財務結果を完了して記録し、Reconciliationは独立した情報源を比較して、勤務記録、銀行取引、給与システムが同じ結果を記録しているか確認します。

まず、どちらもお金に関係するが、答える質問が異なる

二つの概念は取引作成後に現れるため、同じ意味で使われることがあります。

しかし、次のように明確に分けられます。

• Settlement：「この金銭債務を最終的にどう完了し、記録するか？」
• Reconciliation：「独立したシステムが同じ結果を記録しているか？」

二つを一つにすると、独立した照合を行っていないのに「記録済みだから正しい」とシステムがみなすおそれがあります。

本記事におけるSettlementの意味

「settlement」は銀行、決済ゲートウェイ、給与システムによって異なる意味で使われる場合があります。

本記事では、Settlementを取引または業務期間の最終的な財務結果を確定する段階とします。

EWA取引の例：

• 申請が作成される
• 銀行が結果を確認する
• システムが実際の支払額を確定する
• 取引台帳が受取済み金額を記録する
• 残りの給与を更新する

給与期間レベルでは、Settlementに次も含まれます。

• 確認済みEWA支払額の集計
• 正しい合計額の給与システムへの反映
• 期間中に支払う残額の確定
• 処理済み債務の完了

したがってSettlementは、金銭債務の完了に重点を置きます。

Reconciliationの意味

Reconciliationは、二つ以上の独立したデータソースを比較して一致を確認する工程です。

例えば：

• EWA台帳に500,000 VNDの支払いが記録される
• 銀行明細にも対応する取引が必要
• 期末給与に受取済み金額が正しく反映される
• 給与明細で二重に控除しない

情報源が一致すれば、取引または期間は照合済みとみなされます。

一致しなければ、差異を例外キューに入れます。

Reconciliationは取引を作成せず、報告を合わせるために数字を勝手に修正すべきでもありません。

SettlementとReconciliationの比較

基準	Settlement	Reconciliation
主な質問	金銭債務はどう完了したか？	台帳は一致しているか？
時点	取引ライフサイクル中／後または期末	複数ソースのデータ入手後
主なデータ	取引状態、金額、期間	EWA台帳、銀行、給与
結果	支払済み／精算済み／残額	一致または例外
取引を作成するか	取引完了に関与する場合がある	いいえ
差異を検出するか	可能だが主目的ではない	はい、主目的である
期間を締めるか	債務の締めに関与する場合がある	締め前にデータを確認する
不明な場合	適切な状態を維持	例外／調査へ送る

二つのレイヤーは連携すべきですが、互いに代替できません。

取引はSettlementをどう通過するか？

一般的な流れ：

1. 申請が条件を満たす
2. Payment Orchestrationが取引を作成する
3. 銀行が処理する
4. 最終状態を確定する
5. 成功した取引を「受取済み」台帳に記録する
6. 関連価値を再利用できないようロックする
7. 取引債務を完了とする

銀行状態が不確かな場合、Settlementが勝手に結論を出すべきではありません。

ここではフェイルクローズ原則を適用します。結果が不明なら成功または失敗として締めません。

取引はReconciliationをどう通過するか？

独立データが得られた後、システムは次を比較します。

1. 内部取引ID
2. 銀行コード／参照番号
3. 金額
4. 受取人
5. 時刻
6. 状態
7. 給与期間
8. 給与に反映した金額

すべて一致すれば、取引を照合成功と記録できます。

一つでも異なれば、システムは例外を作成します。

重要なのは、Reconciliationが独立した情報源でシステムの記録結果を検証することです。

API応答だけでは照合といえない理由

銀行APIは処理時点で「success」を返すことがあります。

これは重要な信号ですが、財務システムにはその後の独立した照合レイヤーが必要です。

理由：

• リアルタイム応答が誤る、または失われる可能性
• 内部システムが誤った状態を記録する可能性
• 取引が二重に記録される可能性
• 明細に内部記録のない取引が現れる可能性
• 給与システムが誤った期間を使う可能性

Reconciliationが最終検証を行います。

期末Settlementと取引ごとのSettlementの違い

二つのレベルがあります。

取引レベル

特定の支払いが実行されたか、金額はいくらかを確定し、取引台帳に記録します。

給与期間レベル

期間内の全取引を集計し、次を確定します。

• 受取済み総額
• 返金／調整額
• 給与に反映する金額
• 残りの給与

どちらにも追跡可能なデータが必要です。

「数字を合わせるために修正する照合」が危険な理由

二つの台帳が合わないとき、一方を手作業で変更して合計を一致させるのは危険です。

原因の証拠が失われるためです。

正しい手順：

1. ソースデータを保持する
2. 例外を作成する
3. 原因を調べる
4. 誤った台帳を特定する
5. 追跡可能な業務調整を行う
6. 承認を得る
7. 再照合する

すべての調整に監査証跡が必要です。

SettlementとReconciliation間でよくある例外

システムは成功だが銀行明細にない

取引と銀行証跡を調査します。

明細に出金があるがシステムはpending

API応答が失われた可能性があります。新しい支払指示を再送してはいけません。

取引は成功したが給与に反映されない

受取済み金額が期末に再度支払われるリスクがあります。

給与で控除したが取引は失敗した

従業員が受け取っていないのに給与が減るリスクがあります。

取引が誤った期間に属する

カットオフ規則と対象期間を確認します。

重複取引がある

両方の記録を保持し、原因を特定して手順に従い処理します。

二つのレイヤーは誰が担当すべきか？

同じチームである必要はありません。

次のように分担できます。

• Payment Operations：取引ごとのSettlementを監視
• 会計／照合：銀行とのReconciliation
• 給与：期末Settlementと照合
• Engineering：状態、冪等性、ログを保証
• Product Operations：例外を調整

差異が生じた際の責任を明確にします。

二つのレイヤーをつなぐデータ

最低限、次が必要です。

• 取引ID
• 従業員ID
• 受取口座
• 金額
• 時刻
• 顧客
• 給与期間
• 取引状態
• 銀行参照番号
• 給与への反映額

氏名や自由形式の振込内容を主な照合キーにすべきではありません。

いつ期間を「締め済み」とみなせるか？

給与処理が終わっただけで期間を締めるべきではありません。

締める前に企業は次を確認します。

• 勤務記録が最終状態である
• 成功取引が集計されている
• pending取引に処理方針がある
• 銀行台帳と内部台帳が照合されている
• 給与に正しく反映されている
• 残る例外に担当者がいる
• ブリッジ報告書が保存されている

すべての例外を即時解消する必要はありませんが、未解決の例外は識別し、管理する必要があります。

SettlementとReconciliationで別々に追跡すべきKPI

Settlement

• 最終状態確定までの時間
• pending取引数
• 介入が必要な取引率
• 再試行取引数
• 重複取引数

Reconciliation

• 自動一致率
• 例外数
• 例外の経過期間
• 銀行差異数
• 給与差異数
• 照合締めまでの時間

一つのKPIにまとめると、問題が取引処理か台帳比較か判断しにくくなります。

まとめ

SettlementとReconciliationは同じ統制チェーンの異なるリンクです。Settlementは金銭債務を完了して記録し、Reconciliationは独立した情報源を使って結果の一貫性を証明します。 二つを分けることで、pending取引、差異、カットオフ、給与を管理しやすくなり、取引から給与明細までの追跡性を保てます。

著者： Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

企業向け既得賃金アクセスのご相談： Hotline 0937.022.655 · Email info@nhankiet.vn · 企業向け既得賃金アクセス