EWAが勤怠・給与・銀行を連携する必要があるのはなぜか？

勤怠、給与、銀行は、賃金に関する異なる事実を持っています。勤怠は実施・承認済みの仕事、給与は期間・単価・精算規則、銀行は実際の送金結果を示します。どれか一つが欠けると、利用可能額と最終給与の整合性を保つことが難しくなります。

三つのシステムは三つの異なる問いに答える

EWAは労働データを自ら作成したり、給与システムを代替したりできません。

システム	主な問い
勤怠	どの日・シフトの勤務が完了し承認されたか？
給与	勤務価値、給与期間、期末精算をどう決めるか？
銀行	どの支払いが実際に送金され、最終状態は何か？

EWAは三領域を監査可能な一つのチェーンにつなぎます。

勤怠は成立した勤務を確認する

勤怠データがなければ、実際の勤務量を把握できません。

最低限必要なデータは次のとおりです。

• 労働者;
• 勤務地;
• 日付;
• シフト;
• 時間または勤務日数;
• 承認状態;
• 変更履歴。

重要なのは、記録済みの勤務が必ずしも承認済みではないことです。

退勤記録の欠落、シフトの誤り、確認待ちがあり得ます。適切な承認を経たデータだけを財務計算に使用します。

給与は勤怠にない文脈を提供する

勤怠が8時間を示しても、次の情報は持たない場合があります。

• 適用単価;
• 給与期間;
• 賃金変更の発効日;
• 単価に対応する勤務地;
• 精算規則;
• 期間中の受領済み額の扱い。

これが給与システムの役割です。

EWAは利用可能額を算出する前に、勤務が正しい期間と給与設定に属することを確認します。

EWAの原則は次のとおりです。

利用可能額＝（承認勤務日数×日額）－期間中の受領済み額－企業規則による留保額。

勤怠と給与のデータは同じ計算内で結び付く必要があります。

銀行は資金に実際に起きたことを確認する

支払依頼の作成は、労働者の受領を意味しません。

取引状態は次の可能性があります。

• 処理中;
• 成功;
• 失敗;
• 不明;
• 調査中。

そのためEWA台帳を銀行の支払証跡と連携させます。

依頼送信だけで「受領済み」にすると未受領額が給与から控除されます。銀行が支払い済みでもシステムが未記録なら、同額を再度支払うおそれがあります。

三つのシステムは共通の連携キーを使う必要がある

連携は「APIがある」だけではありません。同じ対象を一貫して識別する必要があります。

安定したキーが必要なのは：

• 労働者;
• 顧客または勤務地;
• 勤怠コード;
• 給与期間;
• 取引;
• 受取口座。

複数勤務地で働く人を氏名だけで照合すると、勤務と単価が混在します。明確な業務キーと管理されたマッピング表が必要です。

勤怠と銀行だけを連携するとどうなるか？

勤務と送金可能性は分かりますが、給与がなければ次を実行できません。

• 正しい期間の特定;
• 正しい単価の適用;
• 受領額の精算先の決定;
• 期末の二重支払い防止。

資金は動いてもPayroll Integrityは弱いままです。

給与と銀行だけを連携するとどうなるか？

給与は周期処理ですが、EWAは進行中の期間に成立した勤務を把握する必要があります。

承認勤務がなければ利用可能額が実際の仕事と切り離された推定値や上限となり、ここで説明するEWAに合いません。

勤怠と給与だけを連携するとどうなるか？

金額は正しく計算できても、銀行が実際に何を送金したか確定できません。

次の処理が難しくなります。

• 二重支払い防止;
• タイムアウト処理;
• 取引調査;
• 正しい受領済み総額の精算。

銀行は実行済み資金移動の正しい情報源です。

データチェーンをどう閉じるか？

理想的な流れは：

1. 勤怠記録;
2. 権限者の承認;
3. Earned Wage Engineによる既得賃金計算;
4. Eligibility Engineによる条件確認;
5. Payment Orchestrationによる取引作成;
6. 銀行処理;
7. 状態確認;
8. Reconciliationによる照合;
9. 給与への受領済み額反映;
10. 給与明細への正しい残額表示。

これにより、すべての支払いを実施済み勤務まで追跡できます。

連携に一つの技術だけが必要なわけではない

連携方法は：

• ファイル;
• Google Sheet;
• API;
• 複数方式の組み合わせ。

重要なのは、明確なスキーマ、安定したキー、定義済みの正しい情報源、タイムスタンプ、状態、重複防止、監査証跡、例外処理です。

冪等性や監査機能のないリアルタイムAPIは、厳格に管理されたバッチファイルより優れているとは限りません。

三つのシステムが一致しない場合は？

「もっともらしい」という理由で数字を選んではいけません。

例：

• 勤怠は8時間;
• 給与は6時間;
• EWAは8時間分を支払い済み。

必要な対応は：

1. 元データを保存;
2. 承認版を特定;
3. 実行済み取引を確認;
4. 影響を計算;
5. 追跡可能な業務調整;
6. 再照合。

最終数字を手作業で変えて差異を隠してはいけません。

各領域は誰が所有すべきか？

• 運用/顧客：勤怠情報源;
• HR/Payroll：期間と賃金規則;
• 財務：取引と照合;
• IT/Engineering：連携と信頼性;
• Product Operations：EWAフロー調整。

RACIは企業ごとに異なりますが、各データ源には所有者が必要です。

追跡すべき連携KPI

• 勤怠と労働者の照合率;
• 期限内承認率;
• 重複記録数;
• 同期エラー数;
• pending取引数;
• 明細との取引一致率;
• 給与差異数;
• 例外処理時間;
• マッピング修正数;
• 完全に閉じた照合期間の割合。

目標は「APIが動く」だけでなく、エンドツーエンドでデータが一致することです。

結論

EWAが勤怠、給与、銀行をつなぐのは、一つのシステムだけでは全事実を持たないからです。勤怠が仕事を証明し、給与が正しい期間と規則を適用し、銀行が実際の支払いを確認します。共通キー、監査証跡、照合統制により、EWAはPayroll Integrityを守りながら迅速に運用できます。

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

企業向けEWA相談： Hotline 0937.022.655 · メール info@nhankiet.vn · 企業向けEWAについて