グループ間債権債務・取引高の照合を自動化する
各社から集めた「相手先別の債権債務・取引高」を機械的に突き合わせ、差異のある組み合わせと差異額だけを一覧にする方法です。プログラムはAIに書かせ、差異の原因判断と修正は人が行います。
1. Before ― 手元はどうなっているか
架空のITコンサル企業、オリオンテクノロジーズ株式会社の連結決算。子会社5社からグループ間の債権債務残高と取引高の報告を受け、照合しています。様式は統一するよう依頼していますが、実際に届くものはこうなっています。
- 2社が独自様式で提出してくる。列の順番が違い、1社は科目名が英語。
- 1社だけ締め日が違う。月末ではなく20日締めで、月末までの取引が翌月報告に乗る。
- 相手先の会社名の表記がそろわない。「オリオン商事(株)」「オリオン商事株式会社」「ｵﾘｵﾝ商事」が混在している。
- 税込みと税抜きが社によって違う。明記されていないので、金額だけでは判断できない。
- 通貨が混ざる。海外子会社1社は現地通貨で報告してくる。
この状態から突合を始めるので、毎回「照合する前の整え作業」に時間が取られます。
2. 問題の分解 ― 何を整えれば進むのか
(a) 様式をそろえる
列の対応付け、科目名の対応、税込・税抜の統一、通貨の換算。ルールが決まれば毎月同じ作業。
(b) 突合のキーを決める
会社コード＋科目区分＋対象期間。名前ではなくコードで突き合わせる。
(c) 突合する
機械的な処理。
(d) 差異を分類する
片方のみ計上、金額違い、期ずれ、など。
(e) 判断する
どちらが正しいか、未達をどう処理するか。ここは人。
(a)の様式変換は、対応表が固まったあとは固定処理にします。毎月AIに変換させると、月によって結果が変わりうるうえ、連結の数字は前月との継続性が命なので、処理が揺れること自体がリスクです。また、会社名の名寄せもAIの推測に任せず、会社コードの対応辞書で行います。AIを使うのは、対応表・辞書のたたき台作り、変換プログラムの作成、差異一覧の設計です。
3. AIに任せること／人が判断すること
- 各社の残高表（相手先別）を読み込み、組み合わせごとに突き合わせるプログラムの作成
- 差異のある組み合わせ・科目・差異額の一覧化と、通貨換算の機械的な処理
- 差異の「型」の推定（片方だけ計上、金額の桁違い、締め日のずれの可能性など）
- 各社への差異照会メールの下書き
- 提出データの形式の統一（各社の残高表の様式・締め日・通貨の取り決め）
- 差異の原因の特定と、どちらの会社が修正するかの判断
- 未達取引の連結上の処理（未達仕訳）の決定
- 照合結果の承認と、相殺消去仕訳への反映
4. 実行 ― AIとのやりとり
- 提出様式を決める。各社から「相手先会社／科目（売掛金・買掛金・売上・仕入など）／金額／通貨／締め日」の列でExcelを提出してもらいます。様式が揃っていれば、プログラムは単純になります。
- 対応表を作る。「親会社の売掛金 ⇔ 子会社の買掛金」「売上 ⇔ 仕入」のように、突き合わせる科目の対応表と、為替レート表を用意します。
- Claude Codeにプログラムを書かせる。下の指示文のように、ファイルの列名と対応表を伝えて照合プログラムを作らせます。実データは自分のパソコンの中で処理し、AIに渡すのは列名と構造だけで済みます。
- 差異一覧を人が見る。差異の型ごとに原因を確認し、修正する会社と処理を決めます。未達取引は連結上の未達仕訳として処理し、その記録を残します。
出力のイメージ（差異一覧の抜粋）
| 会社A | 会社B | 科目A／科目B | A側（円） | B側（円） | 差異 | 差異の型 |
|---|---|---|---|---|---|---|
| 親会社 | 子会社X | 売掛金／買掛金 | 12,500,000 | 10,300,000 | 2,200,000 | 締め日のずれの可能性（A側に月末計上あり） |
| 子会社Y | 子会社Z | 売上高／仕入高 | 3,000,000 | 0 | 3,000,000 | 片方のみ計上 |
※ 説明用の架空の例です。
往復1回目 ― AIが会社名を勝手に名寄せした
表記ゆれの統一を頼んだところ、「オリオン商事(株)」「オリオン商事株式会社」「ｵﾘｵﾝ商事」を1社にまとめたうえで、「オリオン物流株式会社」も同じグループに入れていた。
前の3つは同じ会社ですが、オリオン物流は別法人です。名前が似ているだけで、AIがまとめてしまいました。連結でこれをやると、消去すべきでない取引を消去することになります。
「会社名の名寄せは、こちらが渡す会社コード対応辞書に載っているものだけ行ってください。辞書に無い表記は、まとめずに『要確認』として一覧に出してください。似ている名前を推測でまとめないでください。」
辞書にある3表記だけが統一され、オリオン物流は別会社のまま残りました。辞書に無い新しい表記は「要確認」に出るようになりました。
「要確認」に出た表記を確認し、正しければ辞書に追加します。辞書の更新は人が承認します。
往復2回目 ― AIが差異の原因を断定した
差異一覧に「締め日のずれによるものです」という原因が書かれていた。
締め日が違う会社が1社あるのは事実ですが、その差異が本当に締め日によるものかは、取引の明細を見ないと分かりません。単純な計上漏れかもしれません。原因が書かれていると、それ以上調べずに済ませてしまいます。
「差異の原因を断定しないでください。考えられる差異の型を候補として複数挙げ、それぞれについて『どの資料を見れば確定できるか』を添えてください。どちらの会社が正しいかは書かないでください。」
「候補：①期ずれ（確認方法：○社の当月20日〜末日の取引明細）②片方のみ計上（確認方法：双方の該当科目の明細）③税込・税抜の相違（確認方法：金額を1.1で割った値が一致するか）」という形になりました。
候補を1つずつ潰し、原因を確定します。確定してから未達処理を決め、承認を受けます。
5. エラーと例外 ― うまくいかないとき
仕様表
| INPUT入れるもの | 各社から届いた報告ファイル、会社コード対応辞書、科目対応表、為替レート表、対象年月。 |
|---|---|
| PROCESSすること | 元ファイルは読むだけ。様式を揃え、通貨を換算し、会社コード＋科目＋期間で突合する。 |
| OUTPUT出るもの | 一致一覧、差異一覧（差異の型の候補と確認方法つき）、要確認一覧（辞書に無い表記など）、実行ログ。 |
| VALIDATION正しさの確かめ方 | 各社の報告合計と、取り込んだ後の合計が一致するか。双方向の照合（A社→B社とB社→A社の両方から突合し、結果が同じになるか）。差異の合計が、一致分と合わせて全体と合うか。 |
| ERROR止める条件 | 辞書に無い会社表記／科目対応表に無い科目／為替レートが未設定／税込・税抜が判別できない／合計が一致しない。推測で埋めない。 |
| RE-RUNやり直し | 連結パッケージは再提出が起きる。何度でも実行でき、提出版を上書きせずに版数を分けて保存する。どの版で照合したかをログに残す。 |
| CHANGE変更対応 | 新しい子会社が増えたら、会社コード対応辞書と科目対応表に追記するだけで済む形にする。締め日の違いは設定値で持つ。 |
6. 検証 ― 正しいとどう言えるか
- 双方向照合：A社側から見た突合結果と、B社側から見た突合結果が一致するか。
- 合計の確認：各社の報告合計＝一致分＋差異分＋要確認分。
- 差異ゼロの確認方法：最終的に、相殺消去後のグループ内債権債務の合計が0になるか。
- 前月との継続性：前月に差異として残った項目が、当月どうなったかを追えるか。前月の差異一覧と当月の差異一覧を並べます。
- 抜き取り：一致した組み合わせを3件選び、双方の元資料と突き合わせる。一致した側も確認します（照合ロジックが間違っていれば、誤って一致することもあります）。
7. 注意点
8. After ― 翌月以降、何が変わるか
- 様式がそろっていないことを前提にした作りになるので、「今月も様式が違う」で作業が止まらなくなります。
- 差異一覧に確認方法が付いているので、担当者が代わっても調べ方が分かります。
- 前月の差異が当月どうなったかを追えるので、毎月同じ差異が出続ける取引に気づけます。
- 子会社が増えても、辞書と対応表の追記で回ります。
- 先月の各社報告ファイルを開き、列の順番と科目名が何通りあるかを数える
- 相手先会社名の表記を全部拾い、何通りの書き方があるかを数える
- その一覧を、会社コード対応辞書の最初の版にする
応用 ― 難易度を下げる場合
★★：Coworkで各社の残高表が入ったフォルダを指定し、「相手先ごとに突き合わせて差異一覧を作って」と頼む方法でも、会社数が少なければ十分です。プログラムを作るほどではない規模のグループは、ここから始めて、会社数が増えたらプログラム化に進むのが無理のない順番です。