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

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

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

赤伝（あかでん）は、記録済みの仕訳を打ち消すために起こす、貸借が逆の伝票です。黒伝（くろでん）は、そのあとに起こす正しい伝票です。元の行を書き換えず、打ち消す行と正しい行を追加して直す。この直し方を赤黒処理と呼びます。

エンジニアの言葉にすると、仕訳テーブルを追記専用のログとして扱い、訂正も新しいレコードで表す設計です。ただし、これは法律が赤伝という形を命じているからではありません。法令が求めるのは条件つきの「訂正の履歴」で、赤伝はそれを満たす方法の一つです。

赤伝・黒伝・赤黒処理の意味

仕訳は、ひとつの取引を借方（左）と貸方（右）の2面で記録したものです。左右の合計は必ず一致します。詳しいテーブルの形は複式簿記のテーブル設計で扱います。

赤伝は、その仕訳の左右を入れ替えた仕訳です。同じ金額を反対側に記録するので、足し合わせるとゼロになります。この呼び名は実務のもので、国税庁の通達や一問一答は「いわゆる反対仕訳」と書いています。

用語を整理すると、次のとおりです。

3枚の伝票をテーブルで見る

例として、税抜100,000円の売上を計上したあとで、正しくは税抜80,000円だったと分かった場面を考えます。消費税率は10％です。

まず元の仕訳があります。

次に赤伝です。元の行には触らず、貸借を逆にした伝票を足します。reversal_of に元の伝票の番号を入れます。

最後に黒伝で正しい内容を起こします。

UPDATE なら1行で済むところが、3伝票になりました。代わりに、「いつ、いくらで計上し、いつ、なぜ直したか」がデータだけで追えます。

貸借はそのままで金額を負にする形もあります。

どちらを使うかは、製品の仕様と社内の決めによります。元帳を見たときの見え方が変わるので、経理の人に確認して決めます。マイナスの形なら売上の借方に数字が立たないので、月次の売上推移を貸方の合計で見ている場合に都合がよいことがあります。

なぜ UPDATE・DELETE を避けるのか

ここからは設計の話です。避ける理由は、大きく3つあります。

1つ目は、報告した数字を再現できることです。 月次の試算表や、経営会議に出した売上は、ある時点の仕訳の集計です。行を書き換えると、同じ条件で集計しても当時の数字が出なくなります。追記だけなら、created_at が一定時刻より前の行を集計すれば当時の状態に戻せます。

2つ目は、連携先とのずれを防げることです。 仕訳は、残高テーブル、補助元帳、BI、入金消込の土台です。行を書き換えても、連携先に変更は伝わりません。新しい行を足す形なら、通常の取り込みで同じように流れます。仕訳連携の設計も単純になります。

3つ目は、説明できることです。 税務調査や監査では、数字の変化を後から説明する場面があります。誰が、いつ、何を、なぜ変えたかを、データとして残せます。開発者や運用者の権限の話はITGC の記事で扱います。

法令が決めていること、決めていないこと

「赤伝を切らないと違法」と言われることがありますが、そのまま受け取ると不正確です。確認できる決まりを並べます。

帳簿そのものについて、法人税法施行規則は、青色申告法人に複式簿記の原則による記録を求めています（第53条）。仕訳帳には発生順に年月日、内容、勘定科目、金額を書くと定めています（第55条）。会社法は、適時に正確な会計帳簿を作ることを求めています（第432条）。どれも訂正の方法までは定めていません。

訂正の履歴が要件として出てくるのは、電子帳簿保存法の「優良な電子帳簿」です。電帳規則第5条は、訂正や削除の事実と内容を確認できるシステムを要件に挙げています（令和8年12月31日までは第5項、その後は第4項と、国税庁の一問一答が注記しています）。優良な電子帳簿は、届出をすると過少申告加算税が5％軽減される制度の前提です。一方、「優良以外の電子帳簿」の要件の一覧に、訂正削除履歴は入っていません。

では、優良な電子帳簿ではどう作ればよいのでしょうか。取扱通達は要件を満たす例を2つ挙げ、短期間の例外も定めています。

押さえたい点は3つです。

• 通達は「訂正又は削除」に反対仕訳の追加も含むとしています。つまり反対仕訳でも、履歴の要件から外れるわけではありません
• 反対仕訳が要件を満たすには、当初の仕訳を特定する情報が必要です。reversal_of 列がないと、この例に当てはまりません
• 反対仕訳の例である通達 8-9（2）は「直接修正できないシステム」が前提です。赤伝の機能があっても、別の画面で UPDATE できるなら、8-9（1）の自動履歴の側で要件を考える必要があります

また、問27は、履歴の対象を法令上の記載事項に係る記録と説明しています。それ以外の項目の履歴は望ましいものの、残っていないだけで優良でないとは判断されないとしています。

保存期間も確認しておきます。法人税法施行規則第59条は帳簿の保存を起算日から7年、会社法第432条は閉鎖の時から10年と定めています。物理削除の設計は、この期間を前提に考えます。

実装の例：反転の自動生成と制約

ここからは設計の例です。PostgreSQL で書きます。テーブル名と列名は説明用です。

取り消しは、人に手で入力させず、元の伝票から自動で作ります。科目の打ち間違いを防げるからです。

-- J-101（id=101）を取り消す伝票を作る
WITH h AS (
  INSERT INTO journal_headers (entry_date, source, reversal_of, reason, created_by)
  VALUES ('2026-09-27', 'manual', 101, '金額の誤り', 'keiri01')
  RETURNING id
)
INSERT INTO journal_lines (journal_id, side, account_code, tax_code, amount)
SELECT h.id,
       CASE l.side WHEN 'D' THEN 'C' ELSE 'D' END,  -- 貸借を逆にする
       l.account_code, l.tax_code, l.amount
FROM journal_lines l CROSS JOIN h
WHERE l.journal_id = 101;

二重の取り消しと、アプリからの書き換えは、DB 側でも止めます。

-- 同じ伝票を2回取り消せないようにする
CREATE UNIQUE INDEX ux_reversal_once
  ON journal_headers (reversal_of)
  WHERE reversal_of IS NOT NULL;

-- アプリのロールから更新と削除の権限を外す
REVOKE UPDATE, DELETE ON journal_headers, journal_lines FROM app_role;

設計で迷いやすい点を挙げます。

• 「取り消し済み」の状態を元の行に持たせない。 status を UPDATE すると、追記のみの原則が崩れます。reversal_of で参照されているかどうかで判定します
• 税区分と補助の情報も反転する。 部門、取引先、税区分を落とすと、部門別損益や消費税の集計がずれます
• 取り消しの取り消し。 赤伝自体が誤りのときは、赤伝に対してもう一度赤伝を切れるようにします
• 差額だけ直す方法。 全額を赤黒にせず、差額20,000円分だけ打ち消す運用もあります。一問一答の問26は、仕訳の方法を総額方式や純額方式などと挙げたうえで、特に限定していないとしています。どちらにするかは社内の決めです
• 日付。 赤伝の entry_date を元の月にするか訂正した月にするかは、締めの状態で変わります。月次の締めとロックで扱います

請求書や業務データはどう直すか

仕訳を赤黒で直しても、取引先に送った請求書は直りません。ここは別の話として考えます。

適格請求書の記載に誤りがあった場合、売手は内容を直した適格請求書を交付し直す必要があります。インボイスQ&Aの問33は、全項目を書き直す方法と、元の請求書との関連を示して修正点を明示する方法を例に挙げています。返品や値引きなら、適格返還請求書の話になります。詳しくは返還インボイスの記事を見てください。

業務側の請求テーブルも、同じ考え方で作れます。

業務テーブルは「いまの状態」を持ち、仕訳は「起きたことの列」を持つ、と分けると整理しやすくなります。ただし、仕訳の根拠になる個別の取引データには保存の話が残ります。仕訳連携の記事で触れます。

判断の練習