補助元帳と総勘定元帳：実際のシステムの階层構造

総勘定元帳には、勘定科目ごとに1つの残高のみが保持されます（例：売掛金 9,300 €）。一方、**補助元帳（subledger）**にはその背景にある詳細データが保持されます。どの顧客に対して、どの請求書が、いつ発行され、いつが期日であり、いくらが未決済のまま残っているかという情報がこれに該当します。

実際の会計システムはすべてこのように階層化されており、この階層化は単なるストレージの最適化ではありません。総勘定元帳を財務諸表作成に十分な小ささに保ちつつ、ビジネスを運営するのに十分な詳細な業務データを維持するために不可欠な仕組みなのです。

統制勘定の関係

補助元帳を集計する総勘定元帳の勘定科目は、**統制勘定（control account）**と呼ばれます。この関係は不変条件（invariant）です。

補助元帳の残高の合計 = 統制勘定の残高

総勘定元帳の売掛金は、未決済の顧客請求書の合計と一致します。棚卸資産は在庫評価額の合計と一致します。固定資産は固定資産台帳の合計と一致します。これらのいずれかが一致しない場合、どちらか一方が間違っており、どちらが正しいかを特定するまでは、両方とも信頼することはできません。

一般的な補助元帳の例：

補助元帳	統制勘定	保持される詳細データ
売掛金元帳	2410 売掛金	顧客ごとの請求書、年齢調べ、入金状況
買掛金元帳	4430 買掛金	仕入先請求書、支払期日
在庫元帳	2040 販売用商品	品目、数量、先入先出法（FIFO）の原価レイヤー
固定資産元帳	12xx	個別の資産、減価償却スケジュール
給与台帳	4460–4463	従業員、総支給額、控除額
消費税台帳	4492 / 2441	分類コードおよび税率別の取引

なぜすべてを総勘定元帳に含めないのか？

含めることは可能ですが、実用的なシステムではなくなります。

取引量： 月に5,000件の請求書を発行する企業の場合、売掛金だけでも月に15,000行の総勘定元帳の仕訳が追加されることになります。試算表は誰も読むことのできない文書になってしまいます。

異なる問い： 総勘定元帳は「当社の財務状況はどうなっているか？」という問いに答えます。一方、売掛金補助元帳は「誰が当社に支払うべきであり、どれだけ支払いが遅れているか？」という問いに答えます。後者には期日、連絡先、支払条件が含まれますが、これらは元帳の1行に含めるべきものではありません。

異なるライフサイクル： 請求書は、下書き、発行済み、一部入金済み、入金済み、係争中という状態を遷移します。しかし、元帳が気にするのは「売掛金が発生した時点」と「それが決済された時点」の2つの瞬間のみです。仕訳においてライフサイクル全体をモデル化することは、会計上の影響を持たないステータス変更に対しても仕訳を起票することを意味します。

異なる保持期間とアクセス権： 顧客の連絡先詳細、支払条件、与信枠は、独自のプライバシーおよびアクセスルールを持つ運用データです。一方、元帳は財務記録です。

レイヤー間の接続方法

補助元帳が情報源（ソース）であり、総勘定元帳はその補助元帳から導出されます。請求書は売上補助元帳で作成され、それを発行することで仕訳が起票されます。この方向性が重要であり、これを逆転させることがシステムの破損につながります。

ここから、すべての整合性を保つためのルールが導き出されます。それは、統制勘定に直接仕訳を起票しないということです。

顧客の残高を「修正」するために2410勘定を貸方に記入する手動仕訳を行うと、補助元帳を変更せずに総勘定元帳だけが変更されてしまいます。その結果、統制勘定と請求書一覧の間で不整合が生じ、その後のすべての突合において差額が引き継がれることになります。さらに、年齢調べレポート（aging report）は補助元帳を参照し、貸借対照表は元帳を参照するため、どのレポートもこの差額の説明ができません。

顧客残高に対する正しい修正方法は常に文書（入金、クレジットノート、貸倒処理など）を伴うものです。文書は両方のレイヤーを同時に更新するためです。

突合（リコンシエーション）

各期末締め（period close）時に以下を実行します：

1. 補助元帳を集計する - 顧客ごとの未決済請求書の合計を算出します。
2. 統制勘定の残高を読み取る。
3. 差額を調査する - 一般的な原因：統制勘定への直接仕訳、誤った勘定科目に起票された文書、または一方のレイヤーのみに適用された入金。
4. 補助元帳ごとに繰り返す - 売掛金、買掛金、在庫、資産、消費税。

突合は、正常に機能している場合は迅速に完了し、問題がある場合には診断の手がかりとなります。これを省略すると、不整合の発見が期末まで持ち越されることになり、その原因となった仕訳が何ヶ月も過去のものになってしまいます。

Nordletにおける階層構造

Nordletでは補助元帳は後付けではなくファーストクラスの機能として扱われ、総勘定元帳は常にそこから導出されます：

• 売上および仕入請求書は、ライフサイクル、取引先、日付、支払ステータスを持つ独自のエンティティです。それらの発行や登録は、設定可能な起票ルールを通じて元帳に仕訳を登録します。
• 在庫は、残数量を持つ先入先出法（FIFO）の原価レイヤーを保持します。在庫の消費は、在庫統制勘定に対する売上原価（COGS）を起票します。
• 固定資産は、資産ごとの取得原価、耐用年数、減価償却累計額を保持します。月次処理によってその集計値が起票されます。
• 給与、消費税、決済は、それぞれ専用の起票ルールを持つ独自の詳細データを備えています。

起票はルール駆動型であるため、各補助元帳の統制勘定は規約ではなく設定によって決まります。これは、設定を誤ったルールがシステム内部から不整合を発生させる唯一の原因になり得ることも意味しており、企業の設定時に一度確認する価値があります。

手動の仕訳（journal entries）は、技術的には統制勘定を含む任意の起票可能な勘定科目を対象に指定できます。システムがそれを防ぐことはないため、規律が求められます。もし2410勘定に直接仕訳を切ろうとしている自分に気づいたなら、実際に必要なのは仕訳ではなく文書です。

突合ビューとしては、売掛金および買掛金用に POST /v1/reports/partner-balances と /v1/reports/debt-aging が、在庫用に /v1/reports/stock-balance が、そして元帳側用に /v1/reports/trial-balance が用意されています。

FAQ

補助元帳とは何ですか？

単一の総勘定元帳勘定を裏付ける詳細な記録です。売掛金の背後にある顧客請求書、固定資産の背後にある個々の資産、在庫の背後にある在庫レイヤーなどがこれに該当します。元帳が集計する実務上の詳細データを保持します。

統制勘定とは何ですか？

補助元帳の合計を保持する総勘定元帳の勘定科目です。その残高は常に補助元帳の記録の合計と一致しなければならず、両者の差額は決算前に解決すべき突合上の課題となります。

なぜ統制勘定に直接仕訳を起票してはいけないのですか？

補助元帳を変更せずに総勘定元帳だけが変更されてしまい、両者の間で恒久的な不整合が生じるためです。顧客残高の調整は、入金、クレジットノート、貸倒処理といった文書を用いて行う必要があり、これにより両方のレイヤーが同時に更新されます。

補助元帳と総勘定元帳の突合はどのくらいの頻度で行うべきですか？

決算の一部として、すべての期に行うべきです。すべてが一致している場合はすばやく完了し、そこで発見される差額は、発生した月に説明する方が期末に説明するよりもはるかに低コストです。

情報源（信頼できる唯一の情報源）となるのは、総勘定元帳ですか、それとも補助元帳ですか？

補助元帳が情報源であり、総勘定元帳はそれから導出されます。文書が補助元帳のレコードを作成し、起票によってそれらが仕訳に変換されます。そのため、修正は文書レベルで行う必要があります。