会計APIの支払済先行— 台帳整合の手順

1. なぜ「支払済だけ先行」が起きるのか

1-1. 会計は金の動き、台帳は取引状態

会計APIは振込完了や消込を速く返しますが、受領日・検収・書面交付は購買側の入力です。
同期キーが請求書番号だけだと、発注番号単位の状態が置き去りになります。

1-2. 部分支払・仮払い・前払い

一部だけ支払済になると、台帳全体を完了扱いにしてしまいがちです。
残高と支払ステータスを分けて持たないと、未完了が消え込みます。

1-3. 手動消込の先行

経理が会計側で先に消込し、台帳担当への通知が無いと、ダッシュボードの未払件数が実態とずれます。
「会計正」か「台帳正」かをプロセスごとに決めてください。

2. 検知のための必須指標

2-1. 支払済×未検収

会計支払済かつ台帳検収未完了の件数を毎日出します。
検収遅延の見方は検収中ステータスの放置防止と揃え、放置リストに載せます。

2-2. 支払済×受領日空欄

受領日が空なのに支払済だと、60日起算の説明ができません。
起算の前提は支払60日ルールの起算点に戻し、空欄を別KPIにします。

2-3. 支払済×書面未交付

適用取引で書面が無いのに支払だけ完了している案件は、監査で強く見られます。
書面の型は発注書面の3条明示で点検し、未交付をクローズ条件に含めます。

2-4. 金額不一致

台帳契約額と会計支払額の差分（源泉・値引き・部分支払）をラベル付けします。
ラベル無しの差額は、週次で自動エスカレーションします。

3. 整合の手順（運用）

3-1. 同期キーを発注番号＋請求キーの二段に

会計伝票だけをキーにすると分割請求で壊れます。
発注番号を親、請求・支払を子として紐づけ、子だけ完了でも親を完了にしない設計にします。

3-2. 「支払済」は会計由来、「取引完了」は台帳由来

フラグを混ぜないことが最重要です。
ダッシュボードの未完了は取引完了で数え、支払済は別ウィジェットにします（ダッシュボードKPI（60日））

3-3. 差分チケットの必須項目

差分理由、担当、解消期限、証跡パスを必須化し、理由空欄のクローズを禁止します。
CSV監査で差分を拾う場合は発注台帳CSVの監査の突合観点も併用できます。

4. 現場シナリオ

4-1. 月末に会計だけ先に締めた

会計締め後に台帳更新が遅れると、翌月の監査説明で差分が一気に出ます。
締め当日は「支払済×未検収」リストを固定し、翌営業日に購買へ一斉依頼します。

4-2. クレジット決済で支払日が曖昧

カード会社の引落日と社内支払確定日がずれるため、台帳の支払日定義を先に固定します。
定義が無いとAPI同期のたびに日付が揺れます。

4-3. 値引き後の差額支払

値引き合意があるのに台帳契約額が更新されていないと、会計支払済でも差額が残ります。
減額該当性の社内判定と契約額更新を同じチケットに載せ、会計だけ先に進めないでください。

5. FAQ

Q. 会計を常に正にしてよいか？

金額・消込は会計正、受領・検収・書面は台帳正が現実的です。
どちらか一方に寄せると、コンプラ項目が消えます。

Q. API遅延で一時的にずれるのは許容か？

許容するなら「遅延許容時間」と「遅延中の表示ラベル」を決めます。
無期限の「同期待ち」は未完了の隠れ蓑になります。

Q. 監査用に何を残すか？

差分リスト、解消チケット、同期ログの3点です。
案件単位のリンク集は監査用の発注〜支払リンク集に合わせて保存します。

6. 差分ラベルの標準セット

6-1. よく使うラベル

API遅延、部分支払、仮払い、源泉差額、値引き未反映、案件紐づけ誤り、手動消込先行、の7つを標準にします。
自由記述だけだと集計できず、再発防止に繋がりません。
週次でラベル別件数を出し、最多ラベルからシステム改修か運用改修かを決めます。

6-2. 部分支払の台帳表現

親案件の支払ステータスは「一部支払」、子の支払行に金額と日付を持ちます。
親を支払済にしない限り、未完了KPIから消えません。
会計側が全額消込でも、台帳上の検収・書面が残っていれば取引完了にしないでください。

6-3. 会話例：経理が「もう払ったから閉じて」と言うとき

「支払済フラグは会計から取り込み済みです。取引完了は検収と書面の確認後にします」と切り分けます。
閉じる権限を会計側に寄せると、コンプラ項目が消え込みます。
急ぐ場合でも、不足項目をチケット化してから暫定クローズの可否を決めます。

6-4. 週次の突合会議アジェンダ

支払済×未検収、支払済×受領日空欄、金額不一致の3リストだけを議題にします。
それぞれの所有者と期限を決め、翌週に持ち越し理由を確認します。
議題を増やしすぎると、差分の消化速度が落ちます。

今夜やる最小の整合

まず「支払済×未検収」を1枚抽出し、理由ラベルを付けるだけで翌週の説明が楽になります。
API連携は便利ですが、フラグを混ぜた瞬間に台帳の意味が消えます。
支払済と取引完了を分けた画面定義を、今週中に文書化してください。

7. 連携障害時の退避手順

7-1. API停止中の扱い

同期が止まったら、ダッシュボードに「最終同期時刻」を大きく出し、数値の鮮度を明示します。
停止中に手動で支払済へ更新する場合は、後でAPI再開時に上書き衝突しないよう印を付けます。
鮮度不明のまま監査説明に使うのは避けてください。

7-2. 再開後の再突合

再開後24時間以内に、停止期間中の支払・消込を再突合します。
差分ラベル「API遅延」が残ったまま放置されないよう、期限付きキューに載せます。
再突合完了まで、経営報告の確定数値に使わないルールも有効です。

7-3. 二重計上の疑いが出たとき

同一発注に支払行が二重で付いたら、会計側の消込キーと台帳の子行IDを突き合わせます。
先に片方を消さず、根拠が揃ってから取消処理をします。
取消ログが無いと、後から金額不一致の原因追跡ができません。

7-4. 月次締めチェックリストへの組み込み

月次締めで「支払済×未検収がゼロに近いか」「理由ラベル未記入が無いか」を必須確認にします。
締め完了の定義に台帳整合を入れないと、会計締めだけが先行し続けます。
チェック結果は締め資料の別紙として残します。

8. 初期導入時の90日計画

最初の30日は検知だけ、次の30日は差分チケット運用、最後の30日で承認ゲートやKPI確定に進みます。
いきなり自動クローズを入れると、支払済先行のまま取引完了扱いになります。
90日の間にラベル別件数の上位3つを潰し、残差が運用許容内かを経営と合意します。
合意なきまま「連携したから完了」と宣言しないでください。

9. 導入判断の一言

会計API連携は支払の見える化を早めますが、取引完了の定義を会計に預けた瞬間に台帳は壊れます。
支払済と取引完了を分け、差分を毎週消化する運用が整ってから自動化を広げてください。
今夜は差分リスト1枚とラベル定義だけで十分です。

10. 現場向けの短い判断表

会計が支払済で台帳が未検収なら、取引完了にせず検収担当へ依頼します。
会計が支払済で受領日が空なら、起算不能として入力担当へ当日中に依頼します。
金額が一致しないなら、ラベルを付けて週次突合へ回し、勝手に契約額を書き換えません。
この3分岐だけ現場に貼っておくと、問い合わせ対応が均一になります。

注意

本記事は発注台帳と会計連携の一般的な運用整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
会計処理・監査対応の要否は専門家確認に従ってください。