リコンサイル（reconcile）は「照合」と訳されますが、どの分野の話かで指すものが入れ替わります。経理では帳簿と銀行明細の突合、証券会社や銀行のバックオフィスでは約定照合と外貨預け金残高の確認、企業年金ではカストディアンの保管残高との定期照合、そしてITの現場では「あるべき状態」へシステムを収束させ続ける制御ループを指します。同じ言葉を別の意味で使ったまま会話が進み、要件定義や監査対応で食い違うことは珍しくありません。ここでは語源から4分野の違いを対照し、差異が出たときの切り分けと、自動化をどこで止めるべきかまでを整理します。
まとめ｜分野で変わるリコンサイルの意味と共通する実務の型
リコンサイルは分野ごとに照合する相手が違うだけで、「自分が持っているデータ」と「外側にある記録」を突き合わせ、ずれの原因を特定するという型は共通しています。
- 会計・経理：帳簿の勘定残高を銀行明細や請求書と突合する、決算数値の信頼性を担保する統制活動。
- 金融バックオフィス：フロントオフィスの約定と自社記録・取引相手・振替機関のデータを突合する、事務リスクの管理。
- 企業年金・カストディ：帳簿上の残高と、カストディアンが実際に保管している残高の定期照合。
- ITシステム：あるべき状態と現在の状態の差分を、人ではなくシステムが自律的に埋め戻す仕組み。
読者の立場によって必要な章が変わります。経理の実務手順を探している場合は会計のセクション、システム要件でこの語に出会った場合はITのセクションから読み進めてください。
語源と分野別の意味｜reconcileが「照合」を指すようになった経緯
辞書を引くと reconcile の第一義は「和解させる」です。和解と照合が同じ単語である理由をたどると、この語が分野をまたいで使われる背景が見えてきます。
ラテン語reconciliareから会計用語へ転じたreconcileの語義
語源辞典 Etymonline によれば、reconcile の英語での初出は14世紀中頃（mid-14c.）の reconcilen で、古フランス語 reconcilier（12世紀）を経てラテン語 reconciliare に由来します。reconciliare は re-「再び」と conciliare「友好的にする」から成り、当初は人と人の仲を戻す意味でした。1550年代になって「矛盾する事実や記述の辻褄を合わせ、見かけ上の不一致を取り除く（to make discordant facts or statements consistent, rid of apparent discrepancies）」という語義が加わっています。
つまり会計での「照合」は、人ではなく記録どうしを仲直りさせるという比喩から派生した用法です。この理解があると、bank reconciliation（銀行勘定調整）や reconciling items（調整項目）といった英文の会計表現も、単語を丸暗記せずに読めるようになります。なお英語の綴りは動詞が reconcile、名詞が reconciliation で、reconsile・reconcilation・recouncile はいずれも誤綴りです。日本語側には「レコンサイル」「リコンシリエーション」という表記ゆれがありますが、指す業務は同じです。
会計・金融・年金・ITの4分野で異なる照合対象と相手方
分野ごとに「何を」「何と」照合するのかを並べると、違いが一目で分かります。
| 分野 | 照合する自社データ | 突き合わせる相手方 | 典型的な呼び名 | 一般的な頻度の目安 |
|---|---|---|---|---|
| 会計・経理 | 帳簿の勘定残高 | 銀行明細・請求書 | bank reconciliation | 月次 |
| 金融バックオフィス | 約定・ポジション記録 | 取引相手・振替機関 | 約定照合・決済照合 | 日次 |
| 企業年金・カストディ | 帳簿上の残高 | カストディアンの保管残高 | 保管残高照合 | 定期 |
| ITシステム | あるべき状態の定義 | システムの現在状態 | reconciliation loop | 常時 |
押さえるべきは、ITだけ「相手方」が外部組織ではなく自分自身の稼働状態である点です。他者との記録の食い違いを扱う3分野に対し、ITは宣言と実態の食い違いを扱います。この差が設計にどう効くかは後述します。
金融機関のリコンサイル｜約定照合・決済照合と外貨預け金残高の突合
日本語で「リコンサイル」とカタカナ表記される場合、Wikipediaも金融業務用語集も、金融機関のバックオフィス業務を語の中心に据えています。
フロントオフィスとバックオフィスの取引データ突合という原型
Wikipediaはリコンサイルを「営業部門（フロントオフィス）と事務管理部門（バックオフィス）との、お互いが持っている取引データを突合し、誤差等の原因究明を行う作業」と定義し、リスク管理手法として位置づけています。金融業務用語集のiFinanceも、社内で行う照合の例としてフロントオフィスとバックオフィスのデータ照合を挙げており、両者の説明は一致しています。
ディーラーが約定した内容と、バックオフィスが受け取った約定通知の内容がずれれば、決済不能や誤発注の見逃しにつながります。金額の正誤を確認する経理の照合とは異なり、ここでの主眼は事務リスクを翌営業日に持ち越さないことです。この原型を知っておくと、金融系システムの開発で「リコンサイルバッチ」という要件が出てきたときに、それが月次の決算作業ではなく日次のリスク管理処理を指していると即座に判断できます。
T+2決済で照合に使える時間と対外照合の対象
照合の締切は決済サイクルで決まります。国内の株式等は、日本証券業協会・東京証券取引所・日本証券クリアリング機構の対応により、2019年7月16日約定分から決済期間が約定日から起算して3営業日目（T+2）へ短縮されました。約定日から受渡日までの猶予が1営業日減ったため、照合を後ろ倒しにできる余地はその分だけ縮んでいます。さらに2024年9月には金融庁・日本証券業協会・日本証券クリアリング機構・東京証券取引所を事務局とする「T＋１化に関する勉強会」が設置され、2025年7月15日に議論の中間整理が公表されました。実施時期は未定ですが、照合工程の前倒しを前提に業務設計を見直す段階に入っています。
iFinanceは、対外的な照合対象として約定照合・決済照合、証券保管先や振替機関との証券残高照合、担保差入先との担保残高照合を挙げています。対内的な照合には、外国の銀行に保有する自行口座（いわゆるノストロ勘定）の取引明細・残高の照合が含まれます。この口座は送金の時差と為替の影響で差異が出やすく、未照合残高が残ると、その分だけ利用可能残高の把握が実態からずれていきます。
カストディアン・年金資産の保管残高との定期照合
企業年金の運用実務でも同じ語が使われます。三菱UFJ信託銀行の『2023年版 年金用語集』は、リコンサイルを「外国証券等について、帳簿上の残高とカストディアン等が実際に保管している残高を定期的に照合すること」と定義しています。
資産を預ける側と保管する側で記録が二重に存在する構造は、証券のカストディ業務でも年金資産でも共通です。自社に帳簿があるからといって残高を確定させず、保管者側の記録と突き合わせて初めて残高を確定させる——この発想が、後述するITのリコンサイルにおける「正の状態を先に決める」考え方につながります。
会計・経理のリコンサイル｜勘定照合の対象と銀行勘定調整表との違い
事業会社の経理でリコンサイルといえば、帳簿と外部証憑の突合、いわゆる勘定照合を指します。差異を見つけて終わりではなく、原因を特定し修正仕訳を起票するところまでが業務範囲です。
預金・売掛金・買掛金で突き合わせる相手方データと月次の流れ
業種を問わず最初に対象になるのは預金・売掛金・買掛金です。預金は会計帳簿の残高と銀行の残高証明書・入出金明細を照合し、残高の一致に加えて未取立小切手や振込済み未着金といった時間差項目を洗い出します。売掛金は自社の売掛金元帳と取引先が認識する買掛金残高を突き合わせ、取引先が多い場合は残高上位から重要性に応じて範囲を絞ります。棚卸資産や仮払金・仮受金、有価証券も、残高が動く企業では対象に加わります。
買掛金でとくに差異が出やすいのは、自社が出荷基準、取引先が検収基準といった計上タイミングの前提が違うケースです。金額が正しくても認識日が異なれば期末に必ず差額が立つため、照合時は「金額の一致」と「認識時点のずれ」を分けて記録しておくと、翌月の解消確認が楽になります。
月次クローズの中では、残高証明書と明細データの取得、帳簿残高との突合、差異一覧の作成、原因区分の付与、修正仕訳の起票、調書の保存という順に進みます。差異を潰しきってから次の勘定科目に移るのではなく、先に全科目の突合を回して差異を一覧化すると、同じ原因が複数科目にまたがっていることに早く気づけます。
銀行勘定調整表がリコンサイルの一形態にとどまる理由
簿記で学ぶ銀行勘定調整表は、当座預金勘定の帳簿残高と銀行残高の差異を、未取立小切手や未渡小切手といった時間差項目で説明する調書です。対象は預金勘定に限定されます。
これに対しリコンサイルは、売掛金と得意先元帳、買掛金と仕入先請求書、有価証券と証券会社の報告書、グループ会社間の債権債務まで対象が広がります。データソースも紙の帳票からCSV、API連携による自動取得まで多様です。銀行勘定調整表はリコンサイルの一形態であって同義ではない、と整理しておくと、自社でどこまで照合範囲を広げるべきかを設計しやすくなります。
グループ間取引の債権債務照合と連結消去の前提
連結決算を組む企業では、グループ会社間の売上と仕入、債権と債務が消去対象になります。消去する前提として、両社の計上額が一致していなければなりません。親会社が出荷基準、子会社が検収基準を採っていれば、期末時点でグループ間の債権債務に必ず差額が立ちます。
ここでの照合は、差異を見つけることよりもどちら側で調整仕訳を入れるかを決めることが本題です。連結パッケージの設計時に、照合の粒度（個別取引単位か月次合計か）と調整を入れる側のルールを先に決めておくと、決算期末に各社へ問い合わせる往復が減ります。基幹システム側でグループ間取引を識別できるコード体系になっているかも、あわせて確認すべき点です。標準機能の守備範囲は主要10分野のERPモジュール一覧で確認できます。
内部統制報告制度における統制活動としての位置づけ
上場企業にとって照合は任意の作業ではありません。金融商品取引法に基づく内部統制報告制度（J-SOX）は2008年4月1日以後に開始する事業年度から適用され、経営者が財務報告に係る内部統制の有効性を評価・報告することを求めています。実務ではリスクと統制活動の対応を整理するRCM（リスク・コントロール・マトリクス）上で、リコンサイルが「照合」「突合」という統制として繰り返し登場します。
さらに2023年4月に改訂された評価・監査の基準および実施基準は、2024年4月1日以後に開始する事業年度から適用されており、およそ15年ぶりの大きな見直しとなりました。改訂後の評価実務や3点セットの扱いは対象企業・3点セットと2023年改訂後のJ-SOX実務で詳しく扱っています。非上場企業にJ-SOXの直接適用はありませんが、会社法が求める計算書類の正確性や税務調査での帳簿と証憑の整合性を考えると、規模を問わず照合の型は必要です。どこから手を付けるかは規模別に整える経理の内部統制の優先順位にまとめています。
ITシステムのリコンサイル｜あるべき状態へ収束させる制御ループ
IT分野にも同名の概念がありますが、中身は会計とかなり違います。この違いを知らないまま設計に入ると要件が噛み合いません。
Kubernetesのコントローラが回すreconciliation loop
Kubernetesの公式ドキュメントは、コントローラを「クラスタの状態を監視し、必要に応じて変更を加えたり要求したりする制御ループ（control loop）」と説明しています。各リソースは spec フィールドにあるべき状態（desired state）を持ち、コントローラは現在の状態をそこへ近づけ続けます。Jobコントローラであれば、Pod自体を起動するのではなくAPIサーバーにPodの作成・削除を依頼し、処理が終われば対象のJobオブジェクトを完了状態に更新します。
この文書には、クラスタは常に変化するため全体として安定状態に達しないこともあるが、コントローラが動き有用な変更を加えられる限り問題ではない、という趣旨の記述があります。差分がゼロになる瞬間を目指すのではなく、差分を埋め続ける動作そのものがリコンサイルという考え方です。
マイクロサービス間で決済データの整合を取り戻す仕組み
サービスを分割すると、1つの業務処理が複数サービスのデータ更新にまたがります。途中で失敗すれば、一方は決済済み・他方は未処理という不整合が残ります。メルカリのエンジニアリングブログ「メルコイン決済基盤における分散トランザクション管理」（2023年6月14日公開）は、複数サービスにまたがる決済トランザクションにSagaパターンを採用したうえで、「決済データの不整合によるリスクを回避するために自動的にリコンサイルを行う仕組みを導入しています」と述べています。
サービス分割の判断そのものに迷いがある場合は、モノリスとの違いと分割単位の決め方を確認してから照合の設計に進むと、手戻りが減ります。そもそも分割しなければ、サービス間のリコンサイル機構は不要です。
会計のリコンサイルとITのリコンサイルを分ける決定的な違い
両者を同じ言葉で語ると必ず混乱するので、ここは言い切ります。会計のリコンサイルは人が差異を調べて仕訳で直す業務、ITのリコンサイルは差異をシステムが自動で埋める仕組みです。会計側ではRCM上の統制として差異の原因究明そのものが成果物であり、調書として証跡を残す必要があります。IT側では原因を人が読む前に収束が完了しているのが正常で、むしろ同一リソースで収束が終わらないまま再試行が繰り返される状態（ホットループ）は、spec と実態のどちらかに誤りがあるシグナルになります。
したがって、金融系システムの要件定義で「リコンサイル機能」と書かれていたら、日次バッチの残高照合を求めているのか、分散処理の自動復旧を求めているのかを最初に確定させるべきです。両者を1つのモジュールに詰め込むと、監査で求められる証跡の粒度と、自動復旧に必要な実行頻度が両立しません。
差異の切り分け｜期ずれ・転記ミス・キー不一致の見分け方
照合すれば差異は必ず出ます。重要なのは検出することではなく、調査すべき差異と構造的に発生する差異を仕分ける基準を持つことです。
翌月に反転するかで判別する期ずれ項目
もっとも多いのは、同じ取引を自社と相手先が別の日に記録することで生じる期ずれです。月末に振り込んだ資金の着金が翌月になる、月末発行の請求書が相手先に翌月届く、カード決済の売上計上に対して入金が翌月以降になる、月末出荷分が検収基準の得意先で翌月仕入になる、月末最終営業日の夜間処理が翌営業日扱いになる——いずれも不正でもミスでもありません。
実務的な判定基準は、翌月に反転して解消するかどうかの一点です。調書上は期ずれ項目として区分し、翌月の照合で消えることを確認します。翌月の照合でも解消しない項目は、前提の異なる別原因が混じっている可能性が高く、明細レベルまで戻して調査対象にすべきです。
期ずれ以外では、金額の桁違いや数字の転置といった転記ミス、そして自社の注文番号と取引先の請求書番号が対応しないキー不一致が続きます。とくに残高が一致していても借方・貸方の相手勘定が誤っている「科目違い」は、残高照合だけでは検出できません。明細単位で突き合わせる工程を残しておく必要があります。
許容差異の閾値設定と勘定科目ごとの使い分け
閾値をゼロにすると端数処理レベルの微差まで全件調査対象になり、業務が回りません。逆に緩めれば本来調べるべき差異を見逃します。現実的なのは勘定科目の性質ごとに水準を変える運用です。預金勘定は原則として差異ゼロを求め、外貨建取引や売掛金は端数処理・レート差を織り込んで一定幅を許容する、といった設計が使えます。
外貨建の照合では、先に外貨ベースの元本金額が一致しているかを確認し、次に適用レート（TTM・TTB・TTSのいずれを使う社内ポリシーか）を検証する二段階に分けると、レート差と実額差を混同せずに済みます。設定した閾値以下の差異を一定期間サンプリングし、実際に問題のある差異が紛れていないかを検証した記録は、監査対応での説明資料としても機能します。統制設計全体の考え方は内部統制の4つの目的と6つの基本的要素で確認できます。
自動化の判断基準｜マッチングルール設計と自動化しない方がよい領域
照合件数が増えれば自動化の検討に入りますが、ツールを入れても設定次第でマッチング率は大きく変わります。どこまで機械に任せ、どこから人が判断するかで、削減できる工数が変わります。
照合キーの選定とまとめ払いで崩れる自動マッチング率
自動マッチングの精度を左右するのは、まず照合キーの選定です。取引番号・金額・日付・取引先コードのどれを使うかで結果が変わり、キーを増やせば精度は上がる一方、データ品質が低いとかえって不一致が増えます。次に許容範囲の定義で、日付は前後何営業日まで、金額は何円または何パーセントまでを同一取引とみなすかを決めます。
見落とされやすいのが1対多の扱いです。取引先が複数請求分をまとめて1回で振り込む運用では、1件の入金に複数の売掛金が対応します。1対1前提のルールしか組んでいないと、まとめ払いが全件マッチング失敗として例外リストに落ち、自動化したはずの工数が戻ってきます。導入前に自社の入金パターンを実データで確認しておくべき箇所です。
取引先との番号体系が根本的に噛み合わない場合は、ルール調整より先に番号のマッピングを整えるほうが効果的です。EDIや電子インボイスで標準化された取引IDをやり取りできれば、金額と日付による推定マッチングに頼る必要がなくなります。
自動化に寄せるべきでない照合と人が判断すべき領域
すべてを自動化しようとすると失敗します。自動化に向かないのは次の領域です。閾値を超えた差異の原因判定は、期ずれか転記ミスか不正かの見極めに取引の背景知識が要るため、機械が付けたラベルをそのまま採用すべきではありません。グループ間取引の調整仕訳をどちら側で入れるかの判断も、各社の会計方針と連結上の影響を踏まえる必要があり、ルール化した瞬間に例外が積み上がります。
また、差異が発見されたが調査の結果「問題なし」と結論づけた場合、その判断理由を残す作業は自動化できません。J-SOXの評価では統制が実施された証跡そのものが問われるため、ここを省くと後日の監査で当時の判断根拠を再現できなくなります。自動化の目標は照合の無人化ではなく、人が判断すべき件数まで絞り込み、判断と記録に時間を回すことだと位置づけると、ルール設計の優先順位を誤りにくくなります。
よくある質問
リコンサイルの語源は何ですか
ラテン語の reconciliare です。re-「再び」と conciliare「友好的にする」から成り、原義は「再び結びつける」でした。英語には14世紀中頃に古フランス語 reconcilier を経て入り、1550年代に「矛盾する事実や記述の辻褄を合わせ、見かけ上の不一致を取り除く」という語義が加わっています。
リコンサイル処理とは何を指しますか
自社が保有するデータと、外部にある記録を突き合わせ、不一致の原因を特定して解消する処理を指します。経理では帳簿と銀行明細の照合、金融のバックオフィスでは日次の約定照合や残高照合、ITシステムではあるべき状態と現在の状態を比較して差分を埋める処理が該当します。文脈によって指すものが変わるため、まずどの分野の話かを確認してください。
証券のリコンサイルとはどのようなものですか
約定内容の照合（約定照合）、決済内容の照合（決済照合）、証券保管先や振替機関との証券残高照合、担保差入先との担保残高照合が中心です。国内株式等は2019年7月16日約定分から約定日起算3営業日目（T+2）の決済に移行しており、さらにT+1化の検討が2025年7月の中間整理として公表されています。
reconcileとreconciliationはどう使い分けますか
reconcile が動詞、reconciliation が名詞です。実務では reconcile the bank statement（銀行明細を照合する）のように動詞で使い、成果物や作業そのものを指すときは bank reconciliation（銀行勘定調整）、調整項目は reconciling items と表現します。account reconciliation は勘定照合を指す一般的な言い回しです。
ITのリコンサイルは会計のリコンサイルと同じ意味ですか
目的が異なります。会計は人が差異の原因を調査して仕訳で修正し、証跡を残す業務です。ITはKubernetesのコントローラのように、あるべき状態と現在の状態の差分をシステムが自動的に埋め続ける仕組みを指します。金融系システムの要件で「リコンサイル機能」と書かれている場合は、日次の残高照合なのか分散処理の自動復旧なのかを最初に確定させてください。
