2026.10.27 業務システム

締め処理とは：売上締め・請求締め・月次締めの違いと、締め後訂正の赤黒処理・締日跨ぎをコードで実装

締め処理とは、一定期間の売上や請求の数字を確定させ、その期間のデータの登録・修正・削除を止める処理です。20日締めの取引先なら、前月21日から当月20日までの売上を集計して請求額を確定させ、以後はその期間の伝票を書き換えられなくします。この記事では、売上締め・請求締め・月次締めの違い、締日から請求期間を出すコード、締め済み期間を守るデータベースの仕組み、締め後に誤りが見つかったときの赤黒処理、締日跨ぎと会計連携の仕訳の生成時点までを、販売管理システムを作る側の目線で示します。

まとめ：締め処理の実装で決める締めの単位・締め後の訂正方法・仕訳の生成時点

締め処理の設計で先に決めることは3つです。1つ目は締めの単位で、取引先ごとの請求締め、全社の月次締め、日々の売上締めのどれを、どの順に実行するかです。2つ目は締め後の訂正方法で、元の伝票を書き換えず、打ち消しの赤伝票と正しい黒伝票を当期間の日付で起こす赤黒処理を標準にします。3つ目は会計へ仕訳を送る時点で、売上計上の都度か、請求締めの時点か、月次締めの時点かを決めます。

実装の要点は、締め済みの期間をアプリの画面制御だけで守らないことです。締め管理のテーブルを持ち、データベースのトリガで締め済み期間への書き込みを拒否すると、バッチや管理ツールからの更新も止まります。取引先ごとに締日が違い、締め後の訂正が月に数件以上ある業務では、パッケージ標準の締めでは足りず、個別の作り込みが要ります。

締め処理の定義と、売上締め・請求締め・月次締めの3種類の違い

「締め」と一口に言っても、販売管理の現場では対象と目的の違う3つの処理が同じ言葉で呼ばれます。要件定義の会話で最初にそろえるべき区別です。

締め処理が期間の数字を確定させ、以後の登録と修正を止める仕組み

締め処理が守るのは、外へ出した数字との一致です。請求書を取引先へ送ったあとに、その期間の売上伝票を書き換えられると、システムの請求残高と相手の手元にある請求書が合わなくなります。会計へ渡した仕訳と販売管理の売上合計も同じで、片方だけが動くと月次の突合で差額が出ます。

そのため締め処理は、集計と確定とロックを1つの操作で行います。期間内の伝票を集計し、結果を締め結果として保存し、期間内の伝票を変更不可にします。ロックが無い締めは、ただの集計レポートです。

売上締め・請求締め・月次締めの対象データと業務別の実行単位の比較

種類	確定させるもの	実行単位
売上締め	集計範囲の区切り	全社・日次や随時
請求締め	取引先への請求額	取引先の締日ごと
月次締め	会計月の売上と仕訳	全社・月1回

請求締めは取引先ごとに締日が違うため、同じ日に締める取引先と締めない取引先が混在します。月次締めは会計の都合で全社一斉に行うので、10月の月次締めの時点で、20日締めの取引先には10月21日以降の売上は未請求のままです。この2つを同じ処理として作ると、月次の売上と請求の合計が合わない理由を誰も説明できなくなります。

弥生販売の締切機能に見る、売上集計の締めと請求金額確定の締めの違い

市販の販売管理ソフトもこの区別をしています。弥生販売のマニュアル「今回の売上締切」は、集計範囲を区切る売上締切とは別に、請求先への請求額や仕入先への支払額を確定させるには請求締切・支払締切が必要だと説明しています。直前に行った今回の締切は1回だけ取り消せ、2回以上さかのぼる取消はできません。

一方の「請求の締切」では、請求締切を行うと締め切った期間の売上伝票や入金伝票は修正も削除もできなくなり、直すには［請求締切の取消］が必要とされています。ロックが掛かるのは金額を確定させる請求締めの側です。自社で作る場合も、集計のための締めと、外へ出した金額を守る締めを分けて設計します。

請求締めの実装：締日から請求期間を出し、前回繰越つきの請求額を集計する

請求締めのコードで間違えやすいのは、期間の計算と前回からの繰越の2か所です。どちらも取引先マスタの持ち方で決まります。

20日締め・末日締め・都度請求を取引先マスタに持たせる列設計と既定値

取引先マスタには、締日（1〜31の日付か、末日を表す99）と請求方式（締め請求か都度請求か）の2列を持たせます。末日を31で代用すると、30日までしかない月の扱いがコードの各所でばらばらになるため、末日は専用の値で表すのが安全です。都度請求の取引先は売上1件ごとに請求額が確定するので、請求締めの対象から外します。

五十日（ごとおび）や15日と月末の月2回締めのように、1か月に複数の締日がある取引先は、締日を1列で持てません。締日を別テーブルに複数行で持つ設計にしておくと、後から月2回締めの取引先が増えても列を足さずに済みます。

締日から請求対象期間を計算するPythonコードと月末・2月の扱い

請求期間は「前月の締日の翌日から当月の締日まで」です。当月に締日の日付が無い月（30日締めの2月など）は月末を締日とみなします。

import calendar
from datetime import date, timedelta

MATSU = 99  # 末日締め

def closing_date(year, month, closing_day):
    last = calendar.monthrange(year, month)[1]
    return date(year, month, min(closing_day, last))

def billing_period(year, month, closing_day):
    """year年month月分の請求期間（開始日, 締日）を返す"""
    end = closing_date(year, month, closing_day)
    py, pm = (year, month - 1) if month > 1 else (year - 1, 12)
    start = closing_date(py, pm, closing_day) + timedelta(days=1)
    return start, end

print(billing_period(2026, 3, 20))     # 2026-02-21 〜 2026-03-20
print(billing_period(2026, 1, 20))     # 2025-12-21 〜 2026-01-20
print(billing_period(2026, 2, MATSU))  # 2026-02-01 〜 2026-02-28
print(billing_period(2026, 3, 30))     # 2026-03-01 〜 2026-03-30

コメントの値は、Python 3.14で実行して得た結果です。最後の例が月末の扱いの要点で、30日締めの取引先の3月分は、2月の締日を28日とみなすので3月1日始まりになります。年を跨ぐ1月分も、期間の始まりは前年12月21日です。この2つを単体テストに入れておくと、締日計算の不具合はほぼ防げます。

前回請求額・入金額・繰越額・今回売上で請求額を出す繰越方式の計算

BtoBの締め請求では、前回の請求額から今回の入金を引いた残りを繰越として、今回の売上と合わせて請求する繰越方式が広く使われます。

項目	金額（円）
前回請求額	330,000
今回入金額	300,000
繰越額	30,000
今回売上（10%対象）	412,345
今回売上（8%対象）	58,760
消費税（10%・8%）	41,234／4,700
今回請求額	547,039

消費税は明細ごとではなく、請求書1枚につき税率ごとに合計してから1回だけ端数を処理しています（この例は切り捨て）。インボイス制度の端数処理の考え方は、国税庁のインボイス制度に関するQ&Aに問ごとにまとまっています。請求締めの結果テーブルには、この7項目を締めた時点の値のまま保存する設計です。後から伝票を集計し直して請求書を再発行する設計にすると、締め後の訂正が過去の請求書の金額まで変えてしまいます。入金と請求の消し込みは入金消込と売掛金照合の業務フローを解説した記事で扱っています。

締め済み期間のデータを守る実装：登録・修正・削除を拒否するトリガ

締め済みの期間をアプリの画面だけで守ると、データ移行のスクリプトや管理者向けの一括更新が素通りします。最後の防壁はデータベース側に置きます。

締め管理テーブルとPostgreSQLのトリガで締め済み期間の更新を拒否するSQL

次の例は、取引先ごとの締め結果をclosingに持ち、本締め済みの期間に入る売上明細の追加・変更・削除をトリガで止めます。PostgreSQL 18系（2026年10月時点の最新マイナーは18.6）を想定したもので、手元に実行環境が無いため動作は未確認です。

CREATE TABLE closing (
  customer_code text NOT NULL,
  period_end    date NOT NULL,
  status        text NOT NULL CHECK (status IN ('仮締め','本締め')),
  closed_by     text NOT NULL,
  closed_at     timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (customer_code, period_end)
);

CREATE FUNCTION is_closed(p_customer text, p_date date) RETURNS boolean AS $$
  SELECT EXISTS (SELECT 1 FROM closing
                  WHERE customer_code = p_customer
                    AND status = '本締め'
                    AND p_date <= period_end);
$$ LANGUAGE sql STABLE;

CREATE FUNCTION reject_closed_period() RETURNS trigger AS $$
BEGIN
  IF TG_OP IN ('UPDATE', 'DELETE') THEN
    IF is_closed(OLD.customer_code, OLD.sales_date) THEN
      RAISE EXCEPTION '締め済み期間の売上は変更できません: % %', OLD.customer_code, OLD.sales_date;
    END IF;
  END IF;
  IF TG_OP IN ('INSERT', 'UPDATE') THEN
    IF is_closed(NEW.customer_code, NEW.sales_date) THEN
      RAISE EXCEPTION '締め済み期間には登録できません: % %', NEW.customer_code, NEW.sales_date;
    END IF;
  END IF;
  IF TG_OP = 'DELETE' THEN RETURN OLD; END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER sales_line_closed_guard
  BEFORE INSERT OR UPDATE OR DELETE ON sales_line
  FOR EACH ROW EXECUTE FUNCTION reject_closed_period();

UPDATEで変更前と変更後の両方を見ているのは、締め済みの日付を未締めの日付へ書き換えて逃がす操作も止めるためです。PostgreSQLの公式文書41.10 Trigger Functionsは、行トリガがエラーを発生させれば操作全体を中止できること、TG_OPで操作の種類を、OLDとNEWで変更前後の行を参照できること、DELETEのBEFOREトリガではOLDを返すのが通例であることを説明しています。

仮締めと本締めの2段階と、締め取消を許す担当者の権限と条件の決め方

上の例でトリガが止めるのは本締めだけです。仮締めは請求書を作って社内確認する段階で、営業担当の入力は止めつつ、経理担当には修正を許します。この権限差はトリガでなくアプリの権限制御で持たせ、本締めで全員を止めます。

締め取消は、請求書を取引先へ送る前に限って許します。送付後の取消を許すと、相手の手元の請求書とシステムの数字がずれる、締め処理が防ぎたかった状態そのものに戻るからです。送付後に見つかった誤りは、次の章の赤黒処理で直します。取消を実行した人と理由は締め管理テーブルの履歴に残します。

締め後訂正の赤黒処理：元伝票を残して取消伝票と訂正伝票を起こす手順

締め後に数量や単価の誤りが見つかったとき、元の伝票は直しません。元伝票を打ち消す赤伝票と、正しい内容の黒伝票を、未締めの当期間の日付で追加します。

赤伝票と黒伝票の作り方と、元伝票とのひも付けに必要な明細の列

10月15日に計上したA部品100個（単価200円）とC部品100個（単価400円）が、実際にはA部品200個、C部品の単価300円だった例です。

-- 赤：元伝票を符号反転で打ち消す（計上日は未締めの当期間）
INSERT INTO sales_line (sales_no, sales_date, customer_code, item_code,
                        qty, unit_price, amount, line_type, origin_line_id)
SELECT 'S-1001-R', DATE '2026-10-25', customer_code, item_code,
       -qty, unit_price, -amount, '赤', line_id
  FROM sales_line
 WHERE sales_no = 'S-1001' AND line_type = '通常';

-- 黒：正しい内容で起こし直す
INSERT INTO sales_line (sales_no, sales_date, customer_code, item_code,
                        qty, unit_price, amount, line_type, origin_line_id)
VALUES ('S-1001-B', DATE '2026-10-25', 'C010', 'A-100', 200, 200, 40000, '黒', 1),
       ('S-1001-B', DATE '2026-10-25', 'C010', 'C-300', 100, 300, 30000, '黒', 2);

同じデータをSQLite 3.50.4で入れて集計すると、10月15日の元伝票は60,000円のまま残り、10月25日の赤黒で差額10,000円が加わって合計70,000円になります。赤黒の伝票にはorigin_line_idで元の明細を指させます。この列が無いと、どの訂正がどの請求の誤りを直したのかを監査で追えません。赤黒の計上日を当期間にしているので、前章のトリガにも止められません。

翌月請求で差額を調整する方式と国税庁Q&A問34の修正インボイスの扱い

請求書を送ったあとの誤りには、税法上の手当ても要ります。国税庁のインボイスQ&A問32は、交付した適格請求書の記載事項に誤りがあれば、修正した適格請求書を交付しなければならないとしています（消費税法57条の4第4項・第5項）。

月1回の締め請求なら、赤黒の差額を翌月の請求書に載せる方式で対応できます。問34（令和5年10月改訂）は、月ごとに請求書を出す卸売業者が、前月の過少請求や過大請求を翌月の請求書で継続的に加減算している場合、その調整を修正した適格請求書の交付とみなして差し支えないと回答しています。前節の例はこの問34の請求書例と同じ訂正内容で、翌月の請求書に並ぶのは、「前月修正」としてA部品＋20,000円、C部品−10,000円を示す行です。赤伝票と黒伝票をorigin_line_idで元の明細へひも付けておけば、この「前月修正」欄をそのまま出力できます。

返品・値引きは訂正伝票と分けて返還インボイスで扱う理由と1万円未満の免除

数量や単価の入力誤りと、返品や値引きは、同じマイナス伝票でも別の伝票種別にします。国税庁Q&A問27（令和6年4月改訂）によれば、返品や値引きなど売上げに係る対価の返還等には適格返還請求書の交付義務があり、税込1万円未満の返還等は交付義務が免除されます。

赤伝票と同じ種別で返品を入れると、返還インボイスを出すべき取引を抽出できず、1万円未満の判定もできません。伝票種別に「赤」「黒」「返品」「値引」を分けて持ち、返品と値引だけを返還インボイスの出力対象にします。

締日跨ぎの設計：計上日・出荷日・請求日のずれで起きる計上漏れの防止

締め処理の不具合で最も多いのは、締めた後に前の期間の日付で伝票が入ってくる締日跨ぎです。トリガで止めるだけでは、今度は入力できない伝票が現場に滞留します。

締め後に届いた前期間の売上を、当期間の計上日で受ける判断基準

20日に締めたあと、22日に「19日出荷分の納品書が現場から上がってきた」という形が典型です。この伝票を出荷日の19日で入れようとすると締め済み期間に当たります。取れる手は2つで、締めを取り消して入れ直すか、計上日を当期間の日付にして次回の請求に載せるかです。

請求書を送る前なら取消、送った後なら当期間計上と決めておきます。当期間で受ける伝票には、本来の出荷日を別の列に残す設計です。計上日と出荷日を1列で兼ねる設計だと、この区別ができず、出荷実績の集計まで1か月ずれます。

20日締めと末日締めの取引先が混在するときの月次締めとの関係

月次締めは会計月の末日で行うため、20日締めの取引先の10月21日〜31日の売上は、10月の売上として会計に入りますが、請求は11月20日締めの請求書に載ります。月次締めの売上合計と10月中に締めた請求の合計が一致しないのはこのためで、不具合ではありません。

この差を説明できるよう、月次締めの時点で「売上計上済み・未請求」の残高を取引先別に出すレポートを作っておきます。月次の締めを何営業日で終えるかという会計側の段取りは、月次決算を5営業日で締める手順の記事が扱っています。

会計連携の仕訳生成タイミング：売上計上時・請求締め時・月次締め時の比較

販売管理から会計システムへ売上の仕訳を送る時点は、締めの設計と一体で決めます。時点によって、締め後訂正の仕訳の出方が変わるためです。

仕訳を作る3つの時点の比較と、販売管理で採るべき標準の仕訳生成時点

生成時点	利点	弱点
売上計上の都度	会計が日次で最新	訂正のたびに仕訳が増える
請求締め時	請求書と仕訳が一致	月次の売上に未請求分が入らない
月次締め時	会計月と一致・件数が少ない	月中の売掛残高が見えない

標準にすべきは月次締め時の集約仕訳です。取引先・税率・部門ごとに1か月分を集約して送れば、赤黒の伝票は集約の中で相殺され、会計側に訂正の仕訳が並びません。20日締めの取引先の未請求分も会計月の売上に入ります。売上計上の都度の連携を選ぶのは、日次で売掛残高を見たい会社だけです。販売管理と会計の役割分担と仕訳の起点の違いは、経理システムと会計システムの違いを仕訳の起点で整理した記事で解説しています。

収益認識基準の出荷基準・検収基準と売上締めの計上日のそろえ方

仕訳の日付は売上の計上日から取るので、計上日を何で決めるかが会計処理と一致していなければなりません。出荷した日に売上を立てる出荷基準なのか、取引先が検収した日に立てる検収基準なのかは、収益認識基準に照らして会社ごとに決まります。

検収基準の取引先が混ざる場合、出荷済み・未検収の伝票は締めの集計から外し、検収日が入った時点で計上日を確定させます。計上基準の考え方と基幹システムの改修点は収益認識基準の5ステップと基幹システムの改修要件の記事にまとめています。

締め処理を作り込むべき業務と、パッケージ標準の締めで足りる業務の判断

締め処理は販売管理パッケージの標準機能です。作り込みが要るのは、標準の締めと業務の締めがずれる場合だけです。

個別開発で締め処理を作り込むべき条件：月2回締め・請求先の分離・送付後訂正

次のどれかに当てはまるなら、締め処理を個別に作り込む価値があります。月2回締めや五十日締めの取引先が全体の1割を超える業務、納品先と請求先が別で、本社一括請求と支店別請求が混在する業務、送付後の訂正が毎月数件以上あり、翌月請求での調整と元伝票への追跡が監査で求められる業務です。

この条件に当てはまり、パッケージの締め機能では締日の持ち方や訂正の残し方が合わない場合は、締め・請求・会計連携を1本の流れで設計する販売管理システム開発の検討に入る段階です。締日と訂正のルールを要件定義で先に決め、データモデルに落としてから画面を作ります。

パッケージ標準の締めで足りる条件と、締め取消を自由にして失敗する形

全取引先が末日締めか20日締めのどちらかで、締め後の訂正が月に1件あるかどうかなら、パッケージ標準の締めで足ります。取引先との締日を自社の締日へそろえてもらえる業務も、この範囲に収まります。

失敗するのは、締め取消を誰でも何度でも実行できる運用にした形です。訂正のたびに締めを取り消して元伝票を直すと、送付済みの請求書と再計算した請求額がずれ、前回請求額から始まる繰越がすべて狂います。取消の権限を経理責任者に絞り、送付後は赤黒処理だけを許す運用にできないなら、締め処理は入れていないのと同じです。

よくある質問

締め処理の実装と運用について、よく聞かれる質問に答えます。

締め処理と決算は何が違いますか？

締め処理は、販売管理や請求の期間の数字を確定させて変更を止める処理で、取引先ごと・月ごとに何度も行います。決算は、会計期間の終わりに財務諸表を作り、税務申告の基礎となる利益を確定させる会計上の手続きです。販売管理の月次締めで確定した売上の仕訳が会計システムに入り、その積み上げが月次決算・年次決算の材料になる、という前後関係にあります。

20日締めの場合、20日の売上は今回と次回のどちらに入りますか？

今回の請求に入ります。20日締めの請求期間は前月21日から当月20日までで、締日当日を含むのが一般的です。ただし取引先との契約で「20日までの出荷分」か「20日までの検収分」かが決まっていることがあり、計上日を出荷日と検収日のどちらで持つかで結果が変わります。取引先マスタに締日と計上基準を一緒に持たせると、この食い違いを防げます。

締め後に誤りが見つかったら締めを取り消すべきですか？

請求書を送る前なら取り消して直して構いません。送った後は取り消さず、赤伝票で元の伝票を打ち消し、黒伝票で正しい内容を当期間の日付で起こします。国税庁のインボイスQ&A問34は、月ごとの請求で前月の誤りを翌月の請求書で継続的に加減算する調整を、修正した適格請求書の交付とみなして差し支えないとしています。

赤黒処理とマイナス伝票の違いは何ですか？

赤黒処理は、元伝票の全量を打ち消す赤伝票と、正しい内容の黒伝票の2枚を起こす方法です。差額だけのマイナス伝票を1枚起こす方法と比べて伝票は増えますが、元の数量・単価と訂正後の値が両方残り、何を直したかが伝票だけで読めます。単価と数量が同時に変わる訂正や、元伝票へのひも付けを監査で求められる業務では赤黒処理を選びます。

Excelで締め処理を管理することはできますか？

取引先が数十社で締日が1種類なら管理できます。月ごとにシートを分け、締めたシートを保護すれば、変更の禁止も形の上では実現できる仕組みです。破綻するのは締日が複数あり、前回請求額と入金から繰越を出す計算を取引先ごとに手で引き継ぐ場合で、1か所の転記ミスが以後の請求すべてに残ります。締め後訂正の履歴を元の行にひも付けて残すこともExcelでは難しく、監査で説明できなくなります。