複式簿記のテーブル設計：仕訳ヘッダ・明細、勘定科目マスタ、貸借一致

確認日 2026-10-31（調べ方）・制度は変わることがあります。個別の判断は公式の資料と専門家に確かめてください。

複式簿記のデータは、仕訳ヘッダ、仕訳明細、勘定科目マスタの3つのテーブルが基本です。1つの取引を1つのヘッダで表し、借方と貸方の各行を明細で持ちます。明細の借方合計と貸方合計は、伝票ごとに必ず一致させます。

このページでは、その土台の設計を説明します。法令が帳簿に求める項目と、編集部の設計の例は分けて書きます。テーブル名と列名は説明用で、特定の製品の構造を示すものではありません。

法令が帳簿に求めていること

法人税法施行規則は、青色申告法人について次のように定めています。

• 取引を複式簿記の原則に従い、整然と明瞭に記録する（第53条）
• 仕訳帳と総勘定元帳などを備える（第54条）
• 仕訳帳には、発生順に取引の年月日、内容、勘定科目、金額を書く（第55条第1項）
• 総勘定元帳には、勘定ごとに記載の年月日、相手方勘定科目、金額を書く（第55条第2項）

別表二十四は、売掛金や売上などの項目ごとの記載事項を定めています。たとえば売掛金は、相手方別に年月日、品名、数量、単価、金額などです。これらはテーブルの形を決めたものではありません。どの項目を持てるかの確認項目として読みます。

上の仕訳帳と総勘定元帳は、システムではテーブルごとに別々に持つ必要はありません。多くの設計では、仕訳明細を発生順に出せば仕訳帳、科目別に出せば総勘定元帳になります。

仕訳ヘッダと仕訳明細

なぜ分けるかは、1つの例で分かります。消費税つきの売上は、借方1行、貸方2行です。

全体の形は次のとおりです。

列を置く場所の考え方は次のとおりです。

計上日と入力日を分けるのは、月次の締めのためです。reversal_of は赤伝のためです。どの業務イベントで仕訳を作るかは仕訳連携で扱います。

金額の持ち方は3通りあります。

このサイトの例では side と正の金額で書きます。マイナス伝票を許すなら、amount の正の制約は外します。

勘定科目マスタ

勘定科目マスタは、集計の軸です。分類（category）で貸借対照表と損益計算書に分かれ、残高の側（normal_side）で残高の増える向きが決まります。

設計で押さえる点です。

• コードは体系を決める。桁で分類を表す形が一般的です。ただし、コードの体系はあとから変えにくいので、経理と最初に決めます
• 補助科目を分ける。売掛金の取引先別、預金の口座別のように、科目の下の内訳です。必須かどうかを requires_sub で検査します
• 科目を物理削除しない。過去の仕訳が参照しています。valid_to で使えなくします
• 名称の変更は履歴を持つ。国税庁の一問一答の問18は、単価などのマスターデータは期中に改定されるので、取引記録に関連するものを全部保存する必要があるとしています。課税期間の終わりの時点だけでは足りません
• 税区分は別のマスタにする。同じ科目でも税率や課税区分が分かれるためです。消費税の端数処理も見てください

貸借一致のチェック

伝票の借方と貸方の合計が一致することは、このテーブルの不変条件です。1行ずつの INSERT の途中では一致していないので、CHECK 制約では書けません。トランザクションの終わりに検査します。PostgreSQL の例です。

CREATE FUNCTION assert_journal_balanced() RETURNS trigger AS $$
DECLARE diff numeric;
BEGIN
  SELECT SUM(CASE side WHEN 'D' THEN amount ELSE -amount END)
    INTO diff
  FROM journal_lines
  WHERE journal_id = NEW.journal_id;

  IF diff <> 0 THEN
    RAISE EXCEPTION '伝票 % の貸借が一致しません（差額 %）', NEW.journal_id, diff;
  END IF;
  RETURN NULL;
END $$ LANGUAGE plpgsql;

CREATE CONSTRAINT TRIGGER trg_journal_balanced
AFTER INSERT ON journal_lines
DEFERRABLE INITIALLY DEFERRED
FOR EACH ROW EXECUTE FUNCTION assert_journal_balanced();

この検査は、確定の段階でも通します。

複数通貨を扱うなら、外貨の金額と円換算の金額の両方を持ち、貸借の一致は記帳通貨で見ます。円換算の端数で差が出たときの調整の扱いは、経理と決めます。

試算表は、明細の集計で作れます。

SELECT a.code, a.name,
       SUM(CASE l.side WHEN 'D' THEN l.amount ELSE 0 END) AS debit_total,
       SUM(CASE l.side WHEN 'C' THEN l.amount ELSE 0 END) AS credit_total
FROM journal_lines l
JOIN journal_headers h ON h.id = l.journal_id
JOIN accounts a ON a.code = l.account_code
WHERE h.entry_date BETWEEN '2026-10-01' AND '2026-10-31'
GROUP BY a.code, a.name
ORDER BY a.code;

この例は当月の発生額です。残高まで出すなら、前月までの繰越を足します。

件数が増えて集計が遅くなったら、月次の残高テーブル（期間、科目、補助、部門ごとの増減）を持ちます。残高テーブルは計算の結果にすぎないので、明細の集計と一致することを定期的に検査します。

訂正と履歴

確定した仕訳は、行を書き換えず、取り消しの仕訳を足して直す設計がよく使われます。理由と法令の範囲は赤伝の記事で説明しています。

電子帳簿保存法の優良な電子帳簿では、訂正削除の事実と内容を確認できること、通常の期間を過ぎた入力を確認できることなどが要件です（電帳規則第5条）。ヘッダの reversal_of と created_at は、この要件の検討にも関わる列です。自社がどの要件を目指すかは、経理に確認します。

帳簿は保存の期間も長くなります。法人税法施行規則第59条は起算日から7年の保存を定めています。パーティションで古い期間を分けるなど、データが増え続ける前提で設計します。

判断の練習

会計システムの設計と連携の図解記事

システム設計2026-10-31

赤伝・黒伝とは何か：確定した仕訳を UPDATE せずに直す設計

システム設計2026-10-31

消費税の端数処理をシステムでどう作るか：1請求書1回と、明細との差額

システム設計2026-10-31

ERPとは何か：基幹システムとの違いと、データが1つにつながる意味

システム設計2026-10-31

仕訳連携（会計連携）の設計：単位、集約、差分と洗い替え、再実行

システム設計2026-10-31

月次決算の締め処理の設計：仮締め・本締め、ロック、過去月の修正

システム設計2026-10-31

入金消込のシステム設計：多対多の中間テーブルと、差額のパターン