システム設計公開 2026-10-31・更新 2026-10-31

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

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

月次決算の締め処理は、ある月の入力を止め、調整の仕訳を入れて、その月の数字を確定する作業です。システムとしては、会計期間に状態を持たせ、状態に応じて仕訳の登録を制限します。

設計で大事なのは3点です。一度にロックせず段階を分けること、ロックをアプリだけでなく DB 側でも効かせること、そして締めたあとの修正の道を最初から用意することです。修正の道がないと、締め解除が日常になり、ロックの意味がなくなります。

月次の締めは誰が決めているのか

最初に、法令と社内の決めを分けておきます。

法人税の確定申告は、事業年度終了の翌日から2か月以内が原則です（法人税法第74条）。会社法第432条は、適時に正確な会計帳簿を作ることを求めています。これらの単位は事業年度で、月ごとに締めることを定めたものではありません。

月次の締めの時期、仮締めや本締めの段階は、各社が経営管理のために決めている仕組みです。「毎月5営業日で確定」といった日程も社内の決めです。そのため、要件定義では経理の締めスケジュールを最初に聞きます。

帳簿の電子保存に関わる点として、電子帳簿保存法の優良な電子帳簿では、通常の期間を過ぎて入力した事実を確認できることが要件です。一問一答の問29は、通常の期間を日次、週次、月次の業務処理サイクルと説明し、最長2か月のサイクルまでを通常の期間として取り扱うとしています。問28は、入力月と取引月の関係から追加入力が確認できる月次単位の保存も、要件を満たすとしています。

締めの流れ

典型的な流れを示します。順番と日程は設計の例です。

見越しの背景にある発生主義は業務フローと仕訳のハブで説明しています。

会計期間のテーブルと状態遷移

会計期間を1行ずつ持ち、状態を管理します。売掛、買掛のように補助元帳ごとに締める時期が違うなら、モジュールの列を足します。

状態遷移の例は次のとおりです。

仮締めと本締めの言葉には決まった定義がありません。製品や会社で指すものが違うので、「仮締めでは誰が何を入力できるのか」を具体的に確認します。

状態の変更の権限は、通常の経理担当者とは分けます。締め解除の履歴は、内部統制の点でも確認の対象になりやすい部分です。ITGC の記事も合わせて見てください。

ロックの実装

判定は入力日でなく、計上日（entry_date）で行います。10月に入力しても、計上日が9月なら9月の数字が変わるからです。入力日は自動で付け、別の列で持ちます。

アプリの検査だけでは、バッチや別の経路をすり抜けることがあります。DB 側でも止める例です。

CREATE FUNCTION assert_period_open() RETURNS trigger AS $$
DECLARE s text;
BEGIN
  SELECT status INTO s
  FROM fiscal_periods
  WHERE ledger_id = NEW.ledger_id
    AND module = 'GL'
    AND period = to_char(NEW.entry_date, 'YYYY-MM')
  FOR SHARE;  -- 締めの実行と競合しないようにする

  IF s IS NULL OR s = 'closed' THEN
    RAISE EXCEPTION '期間 % は計上できません', NEW.entry_date;
  END IF;
  IF s IN ('soft_closed', 'reopened')
     AND COALESCE(current_setting('app.role', true), '') <> 'accounting' THEN
    RAISE EXCEPTION '期間 % は経理のみ計上できます', NEW.entry_date;
  END IF;
  RETURN NEW;
END $$ LANGUAGE plpgsql;

CREATE TRIGGER trg_period_open BEFORE INSERT ON journal_headers
FOR EACH ROW EXECUTE FUNCTION assert_period_open();

FOR SHARE は、締めの実行と登録が同時に走ったときの抜けを防ぐためです。締めの処理は FOR UPDATE で期間の行を取り、進行中の登録が終わってから状態を変えます。

current_setting は設定がないと NULL を返します。そのまま比べると判定が NULL になって例外が出ないので、COALESCE で空文字に置き換えています。なお、この例は journal_headers の INSERT だけを見ています。既存の伝票に明細を足せる経路が残るなら、journal_lines にも同じ検査を置きます。

取り込み中のバッチが、月をまたいで動くこともあります。連携の側では、締まった月の行をエラーで止めず、保留にして経理の判断を待ちます。仕訳連携の記事のエラーの扱いと同じ考え方です。

締めの実行の前には、次の確認を入れます。

• 全伝票の貸借が一致している
• 売掛・買掛などの補助元帳の残高が、総勘定元帳と一致している（入金消込の残高も含む）
• 連携の保留がゼロ、未処理のファイルがない
• 仮受金や仮払金など、一時的な科目の残高が説明できる
• 振戻の予定が登録されている

本締めのあとは、期末の残高を別のテーブルに固定しておくと便利です。あとで明細を集計した値と比べれば、締めた月に変更が入っていないことを検査できます。

締めたあとの修正

締めた月の誤りが見つかったときの方法は2つです。

どちらの方法でも、元の行は書き換えません。赤伝を入れます。

どちらにするかは金額の大きさ、報告の状況、年度をまたぐかで変わります。これは経理の判断なので、システムは両方の道を用意します。とくに事業年度をまたぐ修正は、月次の話では済みません。企業会計基準第24号は、作成時に入手できた情報を使わなかった、または誤って使ったことによる誤りを「誤謬」と定義し、わざとかどうかを問いません（第4項（8））。データの収集や処理の誤りも例に挙がっています。

基準は、過去の財務諸表に誤謬が見つかったら修正再表示すると定めています（第21項）。比較情報として並べる過去の期の数字に訂正を反映する方法です。ただし基準は重要性を考慮するとしており（第35項）、結論の背景は、重要性の判断で修正再表示しないときは性質に応じて営業損益か営業外損益で認識すると説明しています（第65項）。公表済みの財務諸表そのものの訂正は、各開示制度の話です（同項）。当時の情報で最善の見積りをしていたなら、実績との差は誤謬ではなく、差が確定した期の損益です（第55項）。

この基準が扱うのは財務諸表で、社内の月次の数字をどう出し直すかを定めたものではありません。税務申告への影響も別にあります。経理や会計士と確認する前提で、システムでは「前期以前の修正」が画面で特定できるよう理由コードを持たせます。

再オープンを使う場合は、設計の例として次のように制限します。

• 再オープンできる権限者を限定し、理由を必須にする
• 開けられる月を、直前の月などに限る
• 再オープン中に許可するのは調整の仕訳だけで、連携は止める
• 閉じ忘れを防ぐために、期限で通知する

経過勘定の振戻

締めの仕訳の代表が見越しです。たとえば、9月分の電気代の請求が10月に届く場合、9月末に費用を立てます。

振戻は、9月に計上した分を10月で二重にしないための処理です。簿記では再振替仕訳と呼びます。実際の請求が来たときに、そのまま普段どおり計上できるのが利点です。

振戻の設計で気をつける点です。

• 振戻の計上日を翌月初に固定し、翌月が開いていることを検査する
• kind で訂正の赤伝と区別する。集計の対象や画面の表示が違うことがある
• 見越しの伝票を取り消したときは、振戻の予定も取り消す
• 毎月の繰り返しは定型の仕訳として登録する

前払費用や前受収益のように月をまたいで按分するものは、スケジュールのテーブルで持つと管理しやすくなります。考え方はサブスクの記事で扱います。

判断の練習