卸売の月次締め・請求・突合｜合わない原因と設計

◆監修・編集責任者　小園 将隆　2026年8月26日

B2B EC-COLUMN

突合と消込は別物 — 作成主体の違いが照合を難しくする

卸売の月次締めにおける突合とは、締め日で確定した請求データを、作成主体や作成時点の異なるデータと突き合わせる作業です^*1。受注・出荷・受領・入金のデータと照合し、一致しない差異の原因を特定します。デジタル庁の消込データモデルは、この作業を「作成主体が異なる情報間での突合」と定義しています。

突合と消込の違い — 照合と債権債務の解消は別の作業である

突合とは、作成主体の異なるデータ間の照合、つまりデータ間の接続を指します^*1。一方の消込とは、決済の完了をもって債権債務の解消を確認することです^*1。両者を同じ意味で使うと、どこまでを機械で処理でき、どこからが人の判断かという線引きが曖昧になります。

本記事では、この2つの作業を区別したうえで、突合を成立させるためのキー項目の設計に絞って解説します。

なぜ卸売で突合が重くなるのか — 取引先ごとに異なる締め日と一対多の入金

卸売業では、取引先ごとに締め日が異なることが珍しくありません。1回の入金が複数の請求書に対応する、いわゆる一対多の消込も頻発します。

この商習慣のもとでは、請求書番号のような単一の項目だけで入金と請求を機械的に結びつけるのが難しくなります。どの項目をキーにするかという設計判断が、そのまま照合の手間に直結します。

合わない原因は運用ではなくキー設計にある — 確認の回数を増やしても終わらない

突合が毎月終わらない状態は、担当者の確認が足りないから起きているのではありません。突合対象を特定するキー項目があらかじめ決まっていないことが原因である場合が少なくありません。この点は、次章「突合キーをどう設計するか」で公的に定義されたキー項目とあわせて具体的に示します。

なお、締め日や支払期日をどう設定するかという取引条件そのものの検討は、本記事の対象外です。設定の考え方は、締め請求と支払サイトを扱う別記事で解説しています。

月次締めで発生する4つの突合 — 受注・請求・入金・保存の食い違い

月次締めの1サイクルのなかで、突合が必要になる箇所は大きく4つに分かれます。それぞれ突き合わせる相手のデータと、キーの候補が異なります。

① 受注⇄出荷・納品 — 欠品・分納・返品による数量差

受注データと出荷実績・納品データを突き合わせます。欠品や分納、返品が発生すると、受注時点の数量と出荷実績の数量が一致しません。

② 自社の請求⇄取引先の支払通知書・仕入明細書 — 控除と計上月のずれ

自社が発行した請求データと、取引先が作成する支払通知書や仕入明細書を突き合わせます。センターフィー等の控除や、値引の計上月がずれることで、金額が一致しないことがあります。

③ 請求⇄入金 — 一対多の消込と振込名義の相違

請求データと銀行口座の入金データを突き合わせます。一対多の消込、振込名義の相違、振込手数料の差引によって、請求額と入金額がそのままでは一致しません。

④ 帳簿⇄保存した電子取引データ — 電帳法の検索要件との対応

会計帳簿の記録と、電子帳簿保存法にもとづいて保存した電子取引データを突き合わせます。この論点は、後段の「突合したデータの保存要件」で扱います。

4か所のうち、③の請求⇄入金と④の帳簿⇄保存データは、次章で示すキー項目を整備すれば、機械的な照合に近づけられる範囲です。①と②は、出荷や控除といった業務上の事実確認が残るため、キー設計だけでは解消しきれません。

この見極めを自社の数字で確かめるには、無料相談で要件を整理するのが近道です。

突合キーをどう設計するか — 請求書番号だけでは特定できない

突合を機械的な照合に近づけるためには、何をキーにするかをあらかじめ決めておく必要があります。デジタル庁の消込データモデルは、この点を公的に整理しています^*1。

デジタル庁の消込データモデルの位置づけ — 参照モデルであり義務ではない

デジタル社会推進実践ガイドブックDS-453-1「実装データモデル（金融）消込」は、参照すべきデータモデルを解説するガイドブックです^*1。企業間取引でやり取りされるデータを、システムに実装する際に用います。法令上の義務ではなく、参照モデルとして示されている点を踏まえたうえで、自社の請求書番号の採番規則やマスタ設計にどこまで反映するかを検討します。

突合キー5項目と項目仕様 — 請求書番号だけでは一意にならない

消込データモデルが示す突合キーは、次の5項目です^*1。

なぜ請求書番号だけでは足りないのか — 発行主体をまたぐと重複しうる

請求書番号は発行主体ごとに採番されるため、発行主体が異なれば同じ番号が重複する可能性があります。そのため原本では、発行主体の側で請求情報を一意に特定するための項目として、請求書番号に請求書発行日や発行先事業者識別子を組み合わせるケースが挙げられています^*1。

消込主体側では、この重複を解消するために受発注事業者識別子と請求書タイプ識別子を追加しています^*1。請求書番号だけをキーにすると、この重複によって一致しない請求が残り、消込作業が翌月以降に持ち越されやすくなります。

請求書タイプ識別子の値 — UNCL1001に準拠する

請求書タイプ識別子には、国際規格UNCL1001（国連が定める書類・メッセージ名の識別コード）のコードを用います。適格請求書は「380（Commercial invoice）」、仕入明細書は「389（Self-billed invoice）」です^*1。

自動化の射程はどこまでか — 明細単位はまだ標準の外

消込データモデルがスコープに含めているのは、請求書単位と決済行為を紐づけるLevel1です^*1。卸売業が日常的に行っている明細単位の突合（Level2）は、今後の検討事項にとどまります。

商習慣・業界慣行に特化した情報の紐づけ（Level3）も同様です^*1。現時点で「明細まで自動で合わせられる」とは言えません。

データ品質 — 項目仕様はJIS規格を踏まえて検討されている

5項目それぞれの文字数やフォーマットを定めているのは、連携データの品質を担保するためです。この項目仕様は、JIS X 25012:2013が規定する品質特性を踏まえて検討されています^*1。ソフトウェア製品の品質要求及び評価に関するデータ品質モデルの規格です。

締め請求書と納品書をどう結ぶか — 書類の設計が要件と突合キーを両立させる

キー項目を決めたあとは、請求書・納品書といった書類側の設計をどう組み立てるかが課題になります。

一定期間の取引をまとめた請求書 — 複数書類の全体で記載事項を満たせる

適格請求書は、一の書類のみで全ての記載事項を満たす必要はありません。交付された複数の書類相互の関連が明確で、取引内容を正確に認識できる方法で交付されていれば、複数書類の全体で適格請求書の記載事項を満たします^*3。例えば、請求書に納品書番号を記載する方法です。

この納品書番号が、インボイス要件と突合キーの両方を同時に満たす実務上の要点になります。

2通りの記載方式 — 請求書に集約するか、納品書で補完するか

記載方式は大きく2通りです。請求書側にすべての記載事項をまとめる方式と、請求書に不足する事項を納品書側で補う方式です^*3。どちらを選ぶかは、システムでどちらのデータを正として持つかという設計判断になります。

端数処理の単位が突合差を生む

納品書に「税率ごとに区分した消費税額等」を記載する場合、端数処理は納品書につき税率ごとに1回行います^*4。請求書側に税率ごとの消費税額等を記載する必要はありませんが、納品書に記載した消費税額等の合計額を請求書に記載しても差し支えありません。

ただし、この合計額は法令上の適格請求書の記載事項としての消費税額等にはなりません^*4。この端数処理の単位のずれが、請求合計と納品明細を突合したときの差の主な原因になります。

適格請求書の記載事項6項目

適格請求書の記載事項は次の6項目です^*2。

• 適格請求書発行事業者の氏名または名称および登録番号
• 課税資産の譲渡等を行った年月日
• 取引内容（軽減税率対象品目である旨を含む）
• 税率ごとに区分して合計した対価の額および適用税率
• 税率ごとに区分した消費税額等
• 交付を受ける事業者の氏名または名称

分納・返品が締めをまたぐときの計上月

分納や返品が締め日をまたいだ場合、当月調整と翌月調整のどちらを取るかは、法令が定める要件ではなく、自社の運用として決める事項です。取引先との合意ルールをマスタに持たせておくと、突合時の差異を機械的に説明できるようになります。

請求レス（支払通知書）取引の突合 — 確認の取り方が締切を決める

請求レス取引とは — 発注者が仕入明細情報を渡す方式

請求レス取引とは、請求書を用いず、発注者から受注者へ仕入明細情報を渡す取引です。消込データモデルは、この仕入明細書についても参照モデルとして使用できるとしています^*1。卸売・小売間で行われる支払通知書方式に直接あたります。

仕入明細書は相手方の確認を受けたものに限られる

仕入税額控除の適用を受けるための請求書等に該当する仕入明細書等は、相手方の確認を受けたものに限られます^*5。確認を受けていない仕入明細書は、突合の起点として扱えません。

相手方の確認を受ける3つの方法

確認を受ける方法として、次の3つが示されています^*5。

1. 記載内容を通信回線等で相手方の端末機に出力し、確認の通信を受けた上で自己の端末機から出力する方法
2. 記載事項に係る電磁的記録をインターネットや電子メールで提供し、相手方から確認の通知等を受ける方法
3. 写しの交付または電磁的記録の提供後、一定期間内に誤りの連絡がない場合は確認があったものとする基本契約等を締結し、その期間を経る方法

「一定期間」について、具体的な日数の表示までは求められませんが、業務の内容や取引先との関係を踏まえて認識を合わせておくことが求められます^*5。この一定期間が、実務上の異議申立期限、つまり突合の締切になります。システム側でこの期間をタイマーとして持たせておくと、確認待ちの状態を可視化できます。

仕入明細書の記載事項6項目 — 適格請求書とは記載主体が逆になる

仕入明細書の記載事項は次の6項目です^*5。

• 書類の作成者の氏名または名称
• 課税仕入れの相手方の氏名または名称および登録番号
• 課税仕入れした年月日
• 課税仕入れに係る資産または役務の内容
• 税率ごとに合計した課税仕入れに係る支払対価の額および適用税率
• 税率ごとに区分した消費税額等

適格請求書では発行者側が自身の登録番号を記載しますが、仕入明細書では相手方（課税仕入れの相手方）の登録番号を記載します。この点で、記載主体が逆になります^*2。

デジタルインボイス側の対応 — JP PINTとJP BISが仕様を提供する

デジタルインボイス側では、適格請求書と仕入明細書のそれぞれに対応する仕様があります^*1。適格請求書にはPeppol BIS Standard Invoice JP PINTが対応します。欧州発の電子文書交換規格Peppolに準拠した、日本の適格請求書仕様です。

仕入明細書にはJP BIS Self Billing Invoiceが対応します。いずれも、2026年6月8日更新時点でVer.1.1.3が最新の仕様です^*9。

入金消込を自動化する経路 — ZEDIと流通BMSが前提を用意している

全銀EDIシステム（ZEDI） — 総合振込にXML形式の金融EDI情報を添付

全銀EDIシステム（ZEDI。全国銀行資金決済ネットワークが運営する金融EDI情報の伝送システム）は、総合振込にXML形式の金融EDI情報を添付する仕組みです^*6。このうちDI-ZEDIは、業界横断的な金融EDI情報標準として、デジタルインボイス標準仕様（JP PINT・JP BIS）に対応したフォーマットです^*6。

DI-ZEDIの8項目 — 消込データモデルの5項目と重なる

DI-ZEDIは8つの項目を持ちます^*6。

• 請求書タイプコード／請求書番号／請求書発行日
• 請求金額（税込）
• 売手（受注）企業の登録番号／買手（発注）企業の登録番号
• 振込手数料負担／備考

このうち請求書タイプコード・請求書番号・請求書発行日・両者の登録番号は、消込データモデルの5項目と重なります^*1。同じキーが請求側と決済側の両方に通っていれば、突合のロジックを一本化できます。

流通BMS — 卸売・小売間では相手側のメッセージが既に標準化されている

流通BMS協議会が策定する流通ビジネスメッセージ標準（流通BMS。日本の卸売・小売業界向けEDIメッセージの標準規格）は、基本形Ver2.2の標準メッセージを定めています^*8。このなかに、受領・請求・請求鏡（請求内容の総括を示す帳票）・支払を含む複数のメッセージが含まれます。なお項目一覧は2025年7月15日公開のver2.2.2が最新で、請求鏡メッセージには項目の追加が入っています^*8。

卸売・小売間の取引では、突合の相手側データがすでに標準メッセージとして定義されている場合があります。自社フォーマットを起こす前に、取引先がこの標準に対応しているかを確認してください。

経路の選び方 — 自社だけでは完結しない

どの経路を使えるかは、取引先がどの経路に対応しているかによって決まります。デジタルインボイスとZEDIの組み合わせ、流通BMS、請求レスの仕入明細書、自社EDIや帳票のいずれかを、取引先ごとに割り当てることになります。

突合したデータの保存要件 — 電子帳簿保存法の検索要件と重なる

電子取引データの保存義務 — 送った場合も対象

申告所得税・法人税に関して帳簿・書類を保存する義務のある方は、電子取引データを保存しなければなりません^*7。対象は、注文書・契約書・送り状・領収書・見積書・請求書などに相当する電子データをやり取りした場合です。受け取った場合だけでなく、送った場合も対象です^*7。

3つの要件 — 検索要件は突合キーとほぼ重なる

要件は3つです。改ざん防止のための措置、「日付・金額・取引先」で検索できること、ディスプレイやプリンタ等の備え付けです^*7。

この検索要件の3項目は、突合キーの構成とほぼ重なります。突合キーを整備しておけば、保存要件も同時に満たしやすくなります。

検索の詳細要件

具体的には、日付または金額について範囲を指定した検索ができること、「日付・金額・取引先」のうち2つ以上の任意項目を組み合わせて検索できることが求められます^*7。

簡易な方法 — 索引簿とファイル名の規則化

専用システムを導入していなくても、表計算ソフト等で索引簿を作成する方法や、規則的なファイル名を付す方法で対応できます^*7。ファイル名の例として、日付・金額・取引先を規則性をもって入力する方法が示されています。「20240331_110000_(株)霞商店.pdf」のように名付け、特定フォルダに集約します^*7。

猶予措置の限界 — 対応しなくてよいわけではない

検索要件については、緩和の道が2つ用意されています。基準期間（2年（期）前）の売上高が5,000万円以下である場合と、電子取引データをプリントアウトした書面を日付および取引先ごとに整理された状態で提示・提出できるようにしている場合です^*7。いずれかに当てはまり、かつ税務職員からのダウンロードの求めに応じられる状態であれば、原則的なルールに従った保存として扱われます^*7。

これとは別に、原則的なルールに従った保存ができなかったことについて相当の理由がある場合には、猶予措置の対象となります^*7。ただし、システム等の整備が整っているにもかかわらず保存していない場合は別です。資金繰りや人手不足等の特段の事情がなければ、相当の理由があるとは認められません^*7。猶予措置を受ける場合も、書面の提示・提出とデータのダウンロードの求めへの対応は必要です^*7。

月次締めの突合をECに実装する5ステップ

ここまでの内容を、実装の順序に沿って整理します。順位の根拠は着手順序、つまり後工程が前工程に依存する関係です。

この設計を内製で完了するには、複数の担当が連携する必要があります。請求書番号の採番規則やマスタ設計を扱う経理・法務、取引先ごとの接続方式を扱う情報システム、取引先との合意事項を把握する営業です。関係する部門をまたぐ調整が、内製時の負荷になりやすい部分です。

パッケージの標準機能が持てる範囲は、突合キーのマスタ保持、締め処理と請求書発行までです。明細単位の突合や、取引先固有の控除・値引ルールへの対応は、個社ごとの追加開発が必要になる範囲です。どこまでを標準機能に任せ、どこから個社対応にするかを切り分けることが、内製するか外部に依頼するかを判断する軸になります。

突合設計の判断軸は3つ — キー設計・書類設計・自動化の射程

本稿では、卸売業の月次締めで発生する突合を、受注・出荷から入金・保存までの4か所に分けて整理しました。要点を3つに集約すると次のとおりです。

第一に、突合が合わないのは確認不足ではなく、キー項目が設計されていないことが原因である場合が少なくありません。第二に、デジタル庁の消込データモデルは、5つのキー項目を参照モデルとして示しています^*1。請求書番号・請求書発行日・受注者識別子・発注者識別子・請求書タイプ識別子です。

第三に、自動化の射程は請求書単位（Level1）にとどまり、明細単位の突合は今後の検討課題です^*1。

この3点を踏まえてキー設計を進めれば、月次の照合作業を、担当者個人の経験に頼らない形に近づけられます。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

突合と消込は同じ意味ですか。

同じではありません。突合は作成主体の異なるデータ間の照合を指し、消込は決済の完了をもって債権債務の解消を確認することを指します^*1。

突合のキーは請求書番号だけでよいですか。

請求書番号だけでは足りません。デジタル庁の消込データモデルは、請求書番号・請求書発行日・受注者識別子・発注者識別子・請求書タイプ識別子の5項目を参照モデルとして示しています^*1。

明細単位の突合は自動化できますか。

標準側でスコープに入っているのは請求書単位の紐づけ（Level1）であり、明細単位の紐づけ（Level2）は今後の検討事項です^*1。現時点で、明細まで自動で突合できるとは言えません。

締め請求書と納品書に分けても適格請求書として認められますか。

認められます^*3。交付された複数の書類相互の関連が明確で、取引内容を正確に認識できる方法であれば構いません。複数書類の全体で適格請求書の記載事項を満たします。

支払通知書で処理する場合、相手方の確認はどう取りますか。

確認を受ける方法は3つあります^*5。通信回線等での確認、電磁的記録提供後の確認通知、一定期間内に誤りの連絡がない場合に確認があったとみなす基本契約等の締結、のいずれかです。

1. *1　出典：デジタル庁「デジタル社会推進実践ガイドブック DS-453-1 実装データモデル（金融）消込」（2025年9月30日）
2. *2　出典：国税庁「タックスアンサー No.6625 適格請求書等の記載事項」（令和7年4月1日現在法令等）
3. *3　出典：国税庁「消費税の仕入税額控除制度における適格請求書等保存方式に関するQ&A 問65（一定期間の取引をまとめた請求書の交付）」（令和5年10月改訂）
4. *4　出典：国税庁「同Q&A 問67（複数書類で適格請求書の記載事項を満たす場合の消費税額等の端数処理）」（令和5年10月改訂）
5. *5　出典：国税庁「同Q&A 問86（仕入明細書の相手方への確認）」（令和6年4月改訂）
6. *6　出典：全国銀行資金決済ネットワーク「全銀EDIシステム（ZEDI）とは」
7. *7　出典：国税庁「電子取引データの保存方法をご確認ください【令和6年1月以降用】」（令和5年7月）
8. *8　出典：流通BMS協議会「流通ビジネスメッセージ標準（流通BMS）標準仕様」（基本形Ver2.2／メッセージ別項目一覧ver2.2.2・2025年7月15日）。「流通ビジネスメッセージ標準」「流通BMS」は一般財団法人流通システム開発センターの登録商標です。
9. *9　出典：デジタル庁「デジタルインボイス（JP PINT）」（JP PINT Specifications 最終更新日2026年6月8日／2026年8月26日確認）