銀行エンジニアリング 10：総勘定元帳と補助元帳、Clearing AccountとSuspense Account
総勘定元帳（GL）の1つの残高には、必ず「誰の・どの取引の分か」という内訳があります。MiniBankの4つの補助元帳と、未決済為替・仮受金という銀行特有の勘定を学びます。
v8以降に実装した台帳・記帳エンジンなどを実際に動かし、正常時と異常時の両方から銀行システムの構造を学ぶ。
Prerequisite: BANKING SYSTEMLEARNING GOALS
このページで学ぶこと
- GL（統制勘定）と補助元帳の関係
- 7つの補助元帳照合と差異の検出
- Clearing Account（未決済為替）と Suspense Account（仮受金）の役割
PLAIN LANGUAGE
まず、ここだけつかむ
GLの統制勘定と、その内訳（補助元帳）の合計を照合します。
MiniBankでは普通預金・定期預金・未決済為替・仮受金に、v14で貸出金・未収収益・貸出金利息を加えた7つを照合します。
仮受金は入金先が分からないお金の一時置き場で、特定できたら顧客へ振り替えます。
DIFFICULT PARTS, STEP BY STEP
難しいポイントを、順番にほどく
専門用語を覚えることより、「なぜ必要か」「このシステムのどこで使うか」を理解することが目標です。
Control Account（統制勘定）
内訳を持つGLの科目です。
全体と明細を別の粒度で管理するためです。
gl.accounts の subledger 列がある科目。
Clearing Account
決済が終わるまで一時的に置く勘定です。
受付と決済の間の義務を表すためです。
2300 未決済為替（INTERBANK_OUTBOUND_PENDING）。
Suspense Account（仮受金）
誰の分か分からない入金を置く勘定です。
分からないまま誤った口座に入れないためです。
2900 仮受金と gl.suspense_items。
Level 1 基礎：合計と内訳
GLの「普通預金」は全顧客の預金の合計です。その内訳（口座ごとの残高）を持つのが補助元帳です。合計と内訳の合計が一致していれば、少なくとも数字の抜けや重複はないと確かめられます。
Level 2 銀行業務：MiniBankの7つの補助元帳（照合）
| GL | 統制勘定 | 補助元帳（内訳） |
|---|---|---|
| 2100 | 普通預金 | 口座ごとの残高（bank_accounts.cached_balance） |
| 2200 | 定期預金 | 有効な定期預金の元本（time_deposits） |
| 2300 | 未決済為替（Clearing Account） | 未決済の他行宛送金（interbank.payments） |
| 2900 | 仮受金（Suspense Account） | 未解消の仮受金明細（gl.suspense_items） |
| 1300 | 貸出金（v14） | 融資契約の元本残高（lending.contracts） |
| 1400 | 未収収益（v14） | 融資契約の未収利息（lending.contracts） |
| 4110 | 貸出金利息（v14・収益） | 融資契約の利息計上の合計（lending.accrual_events、訂正済みを除く） |
Level 2 銀行業務：Clearing AccountとSuspense Account
- 01未特定の入金（SUSPENSE_RECEIPT：中央銀行預け金／仮受金）
- 02調査（振込人・金額・日付の照合）
- 03振替（SUSPENSE_CLEAR：仮受金／顧客の預金）
- 未決済為替（2300）：顧客から預かったが、まだ他行へ決済していない送金。v9の資金確保で増え、決済で減る
- 仮受金（2900）：お金は届いたが、誰の預金にすべきか分からない入金を一時的に置く場所。特定できたら顧客の預金へ振り替える
- どちらも「一時的に置く」勘定なので、残高が残り続けること自体が調査のきっかけになる
Level 3 システム：MiniBankでの実装
- gl.subledger_reconciliation() が7つの科目（v14で融資の3科目を追加）について GL残高・明細合計・差額・MATCHED/MISMATCH を返す
- 仮受金の振替は管理責任者だけが行え、同じ明細を2回振り替えることはできない（GL005）
- DBテストでは、テスト用DBに限り1口座の残高キャッシュを7円ずらし、普通預金が MISMATCH（差額 −7）になり、日次締めが BLOCKED になることを確認している
異常時：GLと補助元帳に差異がある
| 段階 | 内容 |
|---|---|
| 症状 | 照合の普通預金が MISMATCH、日次締めが SUBLEDGERS_MATCHED で BLOCKED |
| 調査 | v8 の残高再計算で、どの口座のキャッシュが仕訳と食い違うかを特定する |
| 考えられる原因 | キャッシュの直接更新、記帳漏れ、状態だけ変わった支払 |
| 対応 | 原因の口座を残高修復手続きで直す。GL側（仕訳）は正なので触らない |
| 再発防止 | 差異がある限り締めを止め、翌日以降の数字に混ざらないようにする |
Level 4 アーキテクチャ：統制勘定という設計パターン
統制勘定（Control Account）と補助元帳を分けると、会計は少ない科目で全体を把握でき、業務は明細で個別に管理できます。2つの粒度を定期的に照合することが、別々のテーブルに分かれたデータの整合性を保証する最も確実な方法です。
どこを確認すればよいか
- 管理画面「銀行会計・締め」→ GLと補助元帳の照合
- 仮受金の一覧と振替
CHECK YOUR UNDERSTANDING
3問で理解チェック
答えを頭の中で考えてから、各項目を開いて確認してください。
Q1普通預金のGLと口座残高の合計が7円違ったら、締めはどうなりますか？
SUBLEDGERS_MATCHED で BLOCKED になります。
Q2仮受金の振替を2回できますか？
できません（GL005）。
Q3差異があるとき、仕訳を直しますか？
仕訳は正なので、原因の明細（キャッシュ等）側を調べて直します。
完全に暗記する必要はありません。大切な考え方を説明できそうなら押してください。
SOURCE TRAIL
根拠と関連教材
CURRENT IMPLEMENTATIONは確認したrepository内の実装です。HISTORICAL IMPLEMENTATIONは導入・修正の履歴で、後続migrationによる再定義があり得ます。RELATED LESSONは教材への案内で、実装の一次Sourceではありません。ASSUMPTIONは仮定、UNKNOWNは未確認を表します。
確認基点: d02eae8914f39cbf06bfe422dc39c71886f82b3e / 2026-09-11。稼働環境への適用確認: UNKNOWN。パス実在の自動検査と、記述した技術的事実の確認は別です。
Implementation Status: IMPLEMENTED IN MINIBANK（この教材が扱うコードの範囲）
- RELATED LESSON/docs/be-payment-exceptions未決済送金の照合（v9）
- RELATED LESSON/docs/accounting-assurance会計保証と証拠の設計
- CURRENT IMPLEMENTATION
supabase/migrations/20260930100000_v14_lending.sqlgl.subledger_reconciliationGLと補助元帳の照合（v10の4科目に、v14で融資の2科目を追加） - HISTORICAL IMPLEMENTATION
supabase/migrations/20260924120000_v10_bank_accounting.sqlv10で導入した4つの補助元帳の照合（現在の定義は v14 が引き継ぎ） - CURRENT IMPLEMENTATION
supabase/migrations/20260924120000_v10_bank_accounting.sqlgl.suspense_receipt仮受金の計上 - CURRENT IMPLEMENTATION
scripts/banking/v10-accounting.test.mjsBS/PL、補助元帳差異の検出、仮受金、締めのDBテスト