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

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

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

仕訳連携は、業務システムで起きた取引を、仕訳データにして会計システムへ渡す仕組みです。設計で決めることは主に4つあります。どの単位で渡すか、どこで集約するか、差分か洗い替えか、失敗したときにどう再実行するかです。

いちばん大事なのは、同じ取引が2回計上されず、1回も漏れないことです。そのために、連携の各行が元の業務イベントを必ず指すようにします。集約する場合も、元の取引までたどれる情報を残します。これは調査の便宜だけでなく、電子帳簿保存法の保存の話にも関わります。

連携の全体像

業務システムのイベントを仕訳に変える層を、どこに置くかがまず問題です。

どのイベントで仕訳を出すかは、受注から入金までの流れと計上基準によります。科目を決めるルールの置き場所は、次のように分けて考えます。

設計の例としては、業務側は「何が起きたか」を会計イベントとして出し、科目の割り当ては連携層の表で持つ形があります。科目コードを業務のコードに書かないので、科目の改定で業務システムを直さずに済みます。

連携の単位と集約

連携の単位は、明細単位、伝票単位、集約の順に粗くなります。集約は「日次×部門×科目×税区分」のように、キーを決めて金額を合計することです。

集約には、法令の面から確認しておく点があります。

国税庁の電子帳簿保存法一問一答の問19は、業務システムに個別取引、会計システムに集計データを持つ構成を取り上げています。仕訳帳と総勘定元帳を電磁的記録で保存する場合、原則として会計システムのデータと業務システムの個別取引データの両方を残すよう求めています。会計側の集計だけでは全取引を記録した帳簿にならず、法人税法施行規則第54条の規定に反することになると説明しています。

書面の売上帳などで代える方法も認められていますが、その場合は優良な電子帳簿の過少申告加算税の軽減は受けられません。業務システムの保存期間を短く設定している、または業務システムの入れ替えで過去データを捨てる計画がある場合は、ここを確認します。

優良な電子帳簿を目指す場合は、帳簿間の関連性も要件になります。取扱通達 8-12 は、集計して転記するときは、どの記録を集計したのかが分かる情報を残すことを例に挙げています。設計では、集約の対応表にあたります。

金額の集約で注意したいのは消費税です。税額を業務側の請求書単位で端数処理した値と、集約後の金額から計算し直した値はずれることがあります。計算し直さず、業務側で確定した税額を合計して渡します。消費税の端数処理の記事も見てください。

差分と洗い替え

連携の方式は大きく2つです。

洗い替えが危ないのは、確定した仕訳を消す点です。取扱通達 8-8 の考え方では、記録事項を削除すれば、優良な電子帳簿では訂正削除の履歴の話になります。優良でなくても、月次で報告した数字が変わる問題は同じです。

使い分けの例を示します。

• 会計に計上する前の中間テーブル（当月の見積もりなど）は、洗い替えでよい
• 計上した仕訳は、差分だけを送る。訂正は赤伝にあたる打ち消しのイベントとして送る

業務側で請求金額を直したときの流れは次のようになります。

差分方式では、取りこぼしの検知を別に用意します。業務側の当日イベントの件数と金額の合計を、会計側で取り込んだ合計と毎日突き合わせます。この合計（コントロールトータル）はファイルのトレーラーや連携の管理テーブルに持たせます。

重複を防ぐ：冪等な取り込み

バッチは途中で止まります。API はタイムアウトしても、向こうでは処理が終わっていることがあります。再送しても二重にならないよう、受け側で一意制約をかけます。

CREATE TABLE gl_import_lines (
  source_system  text    NOT NULL,
  event_id       text    NOT NULL,
  line_no        integer NOT NULL,
  entry_date     date    NOT NULL,
  account_code   text    NOT NULL,
  side           char(1) NOT NULL CHECK (side IN ('D', 'C')),
  amount         numeric(15, 0) NOT NULL,
  status         text    NOT NULL DEFAULT 'received',
  PRIMARY KEY (source_system, event_id, line_no)
);

-- 同じイベントが再送されても増えない
INSERT INTO gl_import_lines (source_system, event_id, line_no, entry_date, account_code, side, amount)
VALUES ('sales', 'E-901', 1, '2026-10-15', '1130', 'D', 55000)
ON CONFLICT (source_system, event_id, line_no) DO NOTHING;

ON CONFLICT DO NOTHING だけでは、同じ ID で内容が違うデータも黙って捨ててしまいます。内容のハッシュを持ち、差があればエラーにすると安全です。

順序にも注意します。取り消しのイベントが元のイベントより先に届くことがあります。reverses が指す相手がないときは保留し、相手が届いてから処理します。

エラーと再実行

取り込みで検査する項目を決めておきます。

全件を1トランザクションで処理して全部止めるか、伝票ごとに通して失敗分だけ保留するかは、取引の性質で決めます。売上のように1件ずつ独立していれば、伝票単位の保留が運用しやすくなります。給与のように全部そろって1つの意味になるものは、全件止める判断もあります。

保留の行は状態を持たせます。

業務が止まらないよう、保留があることは翌朝に通知し、月次の締めの前に保留ゼロを確認します。月次の締めとロックの記事の確認項目と組み合わせます。

連携のタイミングと遅延

リアルタイムにするか、日次や月次のバッチにするかは、会計側でいつ数字が必要かで決めます。経理が月次でしか見ないなら、日次バッチで足ります。

電子帳簿保存法の優良な電子帳簿では、通常の期間を過ぎた入力の事実を確認できることも要件です。一問一答の問29は、通常の期間を日次、週次、月次の業務処理サイクルと説明し、バッチ処理などを念頭に、最長2か月までのサイクルなら通常の期間として取り扱うとしています。取扱通達 8-11 は、入力日や一連番号が自動で付き、修正できないシステムを例に挙げています。

設計では、取り込み日時を会計側が自動で付け、取引日（entry_date）とは別の列で持ちます。連携が遅れて月をまたいだときに、どちらの日付で判断するかが明確になります。

判断の練習