本文へスキップ
株式会社オープンナレッジ
株式会社オープンナレッジ Open Knowledge Inc.
公的制度・受発注標準化ガイド 中小企業共通EDI / 全銀EDI(ZEDI) / JP PINT 図解7点収録(クリック拡大対応)

EDIサポーター・中小企業共通EDI・ZEDI(全銀EDI)実践ガイド FAX・多画面EDIの打ち直しと月末の入金消込をなくす、商流・金流一貫連携の設計図

得意先ごとに異なる発注画面(いわゆる「多画面問題」)や、電話回線(ISDN/INSネット)を用いた旧来のレガシーEDI、そして月末に「振込名義のカタカナ」と「請求書の金額」を目視で照らし合わせる入金消込作業は、日本の製造・卸売・物流の現場に大きな負担をかけてきました。 本ページでは、中小企業庁・ITコーディネータ協会が推進する「中小企業共通EDI」および「EDIサポーター(共通EDI推進サポータ)」の活用法から、銀行振込に請求書番号を添えて自動消込を実現する「全銀EDIシステム(ZEDI)」、2026年改正下請法(取適法)への対応、そしてISO 20022 XMLとRustによる自動照合の仕組みまでを4つのステップで詳しく解説します。

3秒でわかる本ページの要点

① 2028年末のISDN終了を見据え、共通EDI・流通BMS・物流情報標準ver.3.00(JSON API)で手入力をなくし、② 銀行振込にZEDI(請求番号・明細XML)を載せて入金消込を自動化し、③ 2026年取適法(特定運送委託・従業員基準300/100人・手形全面禁止・振込手数料差引禁止・60日現金払)と偽装口座詐欺対策を同時に満たします。

知りたい深さに合わせて章を切り替えられます(図表はクリックで拡大表示できます)

中小企業共通EDI標準(UN/CEFACT CII)と全銀EDIシステム(ZEDI / ISO 20022)による受発注・入金消込の自動化
1. 基本と全体像:FAX・電話・手入力をなくす共通EDIとZEDI

中小企業共通EDI標準(UN/CEFACT CII)と全銀EDIシステム(ZEDI / ISO 20022)による受発注・入金消込の自動化

1. 基本と全体像

なぜ「注文の打ち直し」と「月末の入金消込」で毎月何十時間も消えてしまうのか?

まずは専門用語を使わずに、「共通EDI」「ZEDI(全銀EDI)」「EDIサポーター」の3つが、日々の受発注と経理の現場をどう変えるのかを図解で確認しましょう。

要点 1:商流の共通化

「中小企業共通EDI」で多画面・FAX打ち直しを解消

発注側A社では「品番」、B社では「品目コード」と呼び方が違っても、国の標準辞書(共通EDI)を間に挟むことで、自社の販売管理へそのまま自動取り込みできます。

要点 2:金流の共通化

「全銀EDI(ZEDI)」で振込に請求書番号を添付

これまでの銀行振込は「カタカナ名義と合計金額」しか届きませんでした。ZEDIを使えば「どの請求書の、どの明細の支払いか(振込手数料や値引きはいくらか)」がデータで届き、消込が一瞬で終わります。

要点 3:伴走支援の活用

「EDIサポーター」が取引先との調整を橋渡し

自社だけで取引先にデータ形式の変更をお願いするのは大変です。公的研修を修了した「共通EDI推進サポータ」が、業務整理からデータ項目のマッピング、段階的移行までを中立の立場で支援します。

図1:商流(中小企業共通EDI)と金流(全銀EDI:ZEDI)がつながる全体マップ
受発注(商流)と銀行決済(金流)を1本の「共通ID(注文番号・請求番号)」でつなぐ仕組み 発注側(得意先・親事業者) ① 購買・発注システム 注文番号: ORD-2026-081 ② 検収・買掛金確定 60日以内現金払(取適法遵守) ③ ネットバンキング振込 請求番号 INV-992 を添付 【商流】中小企業共通EDI / Peppol ・UN/CEFACT準拠の共通辞書で項目変換 ・見積/注文/出荷/検収/請求を連携 → FAX・多画面への手入力が 0回 に 【金流】全銀EDIシステム(ZEDI) ・銀行振込にXML(ISO 20022)を添付 ・請求書番号・相殺額・手数料を同時送信 → カタカナ名義の目視照合が不要に 受注側(中小製造・卸・物流) ① 販売・生産・出荷管理 注文データを無人で自動取込 ② 電子請求書発行 (INV-992) 適格請求書(インボイス)自動検証 ③ 売掛金の自動入金消込 INV-992 で100%自動一致・仕訳 伴走支援基盤:EDIサポーター(共通EDI推進サポータ)/ スマートSMEサポーター 取引先とのコード変換ルール策定・ISDN(JCA手順/全銀ベーシック手順)からの移行・会計ソフト連携を中立的に設計
図2:従来の受発注・入金消込の課題と、共通EDI×ZEDI導入後の比較
❌ 従来の課題(多画面・FAX・カナ名義照合) 1. 得意先5社のWeb EDI画面に毎朝ログイン 画面ごとに違うCSVやPDFをダウンロードし、 自社の販売管理ソフトへ手作業で打ち直し 2. ISDN終了後も残る古いモデム・専用端末 切替用アダプタで延命したものの通信速度が遅く、 担当者しか操作できない属人化リスクが継続 3. 月末の「振込金額不一致」パズル(月42時間) 複数請求の合算・振込手数料差引・協力会費控除で どの請求書の入金か分からず電話で確認 4. 偽装メールによる「振込先口座変更」詐欺リスク PDFやメール文面の口座番号書き換えに気づきにくい ⭕ 改善後の姿(共通EDI × ZEDI × 事前口座ロック) 1. 共通EDI辞書で全社の注文を1画面に自動集約 得意先ごとの項目名・単位の違いを自動変換し、 朝の転記作業・品番打ち間違いがゼロに 2. インターネット標準(HTTPS/API)へ完全移行 専用モデムや固定電話回線が不要になり、 通信費の削減と災害時の拠点外継続を両立 3. ZEDIのXML明細で月末消込が「月15分」に 複数請求の合算や手数料控除の内訳がXMLで届き、 会計ソフト(freee等)で自動消込・仕訳が完了 4. 適格請求書番号×登録口座の自動照合で詐欺遮断 未登録口座への変更指示はシステムが自動で保留・警告
図3:ZEDI入金消込画面のイメージと、月間経理・受発注工数の削減効果
ZEDI × 共通EDI 自動入金消込ビュー(イメージ) 銀行入金通知(camt.054):振込金額 1,479,450 円 振込人:カ)タカツキセイサクショ / 決済日:2026-10-30(検収後30日以内) ZEDI添付XML:請求2件合算 + 振込手数料差引 550円 を自動検出 自動突合された内訳(人間の手作業:0分) ① 請求番号 INV-2026-0912(9月分部品) 980,000 円 ② 請求番号 INV-2026-0945(追加工事分) 500,000 円 ③ 先方負担・当方負担区分(支払手数料科目) -550 円 差額:0 円(完全一致・仕訳承認済) 1,479,450 円 セキュリティ検証:適格請求書発行事業者番号 T1234567890123 一致 事前登録済の受取口座ハッシュと100%一致(偽装口座変更なし) 月間の受発注・消込作業時間 (取引先30社・月間300件規模の目安) 導入前:合計 約68時間 / 月 注文転記26h + 消込・照会42h 導入後:合計 約1.5時間 / 月 例外確認のみ(約97%削減) 2026年 法改正・取引適正化への効果 ・手形廃止/60日以内現金払の期日管理 ・振込手数料の不当減額(取適法違反)防止 ・電帳法(電子取引データ保存)の自動充足
取引先ごとにバラバラな注文書・請求書を共通フォーマットに揃え、振込データと自動照合する実務手順
2. 現場での進め方と対策:経理・受発注を楽にする段階的導入

取引先ごとにバラバラな注文書・請求書を共通フォーマットに揃え、振込データと自動照合する実務手順

2. 現場での進め方と対策

高額な専用システムを作らずに、既存ソフトを活かして段階移行する4つの手順

「EDIを入れるには数百万円のシステム改修が必要ではないか」と心配されることがありますが、中小企業共通EDIとZEDIは、今使っている販売管理ソフトやクラウド会計ソフト、ネットバンキングを活かして小さく始めることができます。

図4:レガシー電話回線EDI(JCA手順・全銀ベーシック手順)およびFAXからの4段階移行ロードマップ
現場を止めずに進める「商流・金流デジタル化」4ステップ実践手順 手順 1:現状の棚卸し 取引先を3区分に整理 ① 電話回線・モデム型 ② 個別Web EDI(多画面) ③ FAX・メールPDF 現場のチェック点: 上位5社の注文・消込だけで 全体の何割の時間が かかっているかを計測 手順 2:共通辞書マッピング 項目名の変換表を作成 ・「共通EDI標準項目」を  中間フォーマットに設定 ・単位(個/箱/kg)を統一 EDIサポーターの役割: 社内システムを改造せず、 入口の変換テーブルだけで 吸収する設計を支援 手順 3:電子請求・JP PINT 注文番号を請求書へ継承 ・受注時の「注文番号」を  出荷・請求データへ引継 ・インボイス登録番号検証 現場のメリット: 発注側も「どの注文に対す る請求か」が1秒で分かり、 支払承認が迅速化 手順 4:ZEDI・自動消込 銀行XML連携で完全消込 ・メインバンクの法人IBで  ZEDI(XML入出金)有効化 ・会計ソフトとAPI連携 経理のゴール: 着金と同時に売掛金が消込 まれ、未回収や差額発生時 のみアラート通知 ポイント:全取引先を一度に変える必要はありません。まずは取引量の多い1〜3社、または自社の銀行入金消込から着手できます。
図5:中小企業共通EDIの6大標準メッセージと「照合キー(注文番号・請求番号)」のバトンリレー
なぜ月末に消込ができるのか? ── 6つの業務メッセージを通じた「番号のバトンリレー」 ① 見積依頼・回答 単価・納期・ 価格転嫁条件の 事前合意記録 [見積番号] ② 注文(発注) 発注側が発番した 注文番号・明細行 番号を確定 [注文番号・行番号] ③ 注文請(回答) 分納や納期調整が ある場合も注文 番号を保持 [注文番号を維持] ④ 出荷案内 出荷番号・ロット 番号に注文番号を 紐づけて通知 [出荷番号+注文番号] ⑤ 受領・検収 受領日・検収番号 を確定(60日支払 起算日の明確化) [検収番号+注文番号] ⑥ 請求・ZEDI決済 請求書番号を発番 し、銀行振込XML のRmtInfへ格納 [請求番号→ZEDI] 実務で失敗しないための黄金ルール:「番号を途中で捨てない」 ・FAXや手入力では、受注側が納品書・請求書を作る際に「発注側が付けた注文番号」を省略してしまいがちです。 ・共通EDIでは、②の「注文番号」が④出荷→⑤検収→⑥請求→ZEDI銀行振込まで一度も途切れずにリレーされます。 ・その結果、一部納品・分納・返品・値引きがあっても、1円単位でどの注文の決済かが自動で一致します。

現場担当者が今日から確認できる「受発注・決済デジタル化」3つの実務チェックリスト

チェック1:固定電話回線・モデムの確認

社内の隅に「発注データ受信用」の古いパソコンやモデム、ターミナルアダプタ(TA)が残っていないか確認します。メタル回線の維持費や故障リスクを洗い出します。

チェック2:法人ネットバンキングのZEDI対応確認

現在契約している銀行(都市銀行・地方銀行・信用金庫)の法人インターネットバンキングでは、多くの場合わずかな設定追加または標準機能で「ZEDI(XMLファイル入出力)」が利用可能です。

チェック3:振込先口座変更の承認ルール

「メールやPDFで取引先から口座変更の連絡が来たら、必ず登録済みの電話番号へ折り返し確認する」および「適格請求書登録番号と口座名義の一致を確認する」手順を徹底します。

EDI電文規格の比較 従来の全銀固定長120バイト vs 全銀ZEDI(ISO 20022 XML電文)の技術・実務対比表
比較項目 従来の全銀固定長フォーマット(120バイト) 全銀ZEDI(ISO 20022 XML電文・次世代)
電文データ構造 固定長120バイト。半角カナと数字のみ。 国際規格 ISO 20022準拠のXMLフォーマット。拡張可能。
EDI情報(請求明細) わずか EDI情報20バイト。請求書番号1件すら入らない。 タグ情報無制限。複数請求書番号、明細、相殺額を完全包含。
入金消込作業 通帳コピーと請求書を人間が手作業・目視で突き合わせ(月末の残業要因)。 請求書番号と金額が完全一致するため、会計システムが 1秒で自動消込。
多画面問題への耐性 取引先ごとに銀行やWeb画面が異なり、二重入力のヒューマンエラー多発。 UN/CEFACT中小企業共通EDIと直結し、画面レス・手入力ゼロで連動。
2026年改正下請法(取適法) 振込依頼書の手動保管では電磁的記録の監査ログ要件に適合困難。 取引明細の電磁的タイムスタンプと改ざん防止ログが 法的に完全準拠。
3. 関連する制度とルール

2028年末ISDN終了・全銀ZEDI・流通BMS・物流情報標準ver.3.00・2026年取適法の体系整理

受発注と決済のデジタル化は、単なる業務効率化にとどまらず、2028年末のISDN完全終了を見据えた次世代EDI(ZEDI・流通BMS・物流情報標準ガイドライン ver.3.00 JSON API)への移行、そして2026年施行の改正下請法(中小受託取引適正化法:通称「取適法」)などの法令遵守と直結しています。

図6:EDI・デジタルインボイス・金融決済・取引適正化をめぐる公的制度と国際標準の全体相関図
1. 中小企業共通EDI・流通BMS・物流標準v3.00 ・所管・推進:中小企業庁 / 国交省 / ITCA ・2028年末のISDN完全終了に向け、UN/CEFACT準拠の共通EDI、  小売・卸向けの流通BMS、物流情報標準ver.3.00(JSON API)へ統合。 ・「共通EDI推進サポータ」は、商流改革・コード統一・クラウド  ツール導入を伴走支援する専門人材として認定・登録。 → 「DXサポーター(スマートSMEサポーター)」と連携し支援 2. 全銀EDIシステム(ZEDI:ISO 20022準拠) ・運営:全国銀行資金決済ネットワーク(全銀ネット) ・従来の固定長20バイトしか送れなかったEDI情報欄を刷新し、  国際標準「ISO 20022 XML」による大容量の支払通知を実現。 ・振込依頼(pain.001)と入出金明細(camt.054)に、複数の  請求書番号・注文番号・値引き・手数料内訳を構造化格納。 → 総合振込・売掛金消込の完全自動化インフラとして稼働 3. デジタルインボイス(Peppol / JP PINT)& 電帳法 ・所管:デジタル庁(日本Peppolオーソリティ) / 国税庁 ・国際ネットワーク「Peppol」上の日本標準仕様「JP PINT」に  より、適格請求書(インボイス)を構造化データで送受信。 ・電子帳簿保存法第7条(電子取引データ保存)の真実性・可視性  要件(日付・金額・取引先の検索要件)を無人で充足。 → 2026年10月のインボイス経過措置見直し(80%→70%控除)にも対応 4. 2026年取適法(特定運送委託・従業員基準・60日現金) ・所管:公正取引委員会 / 中小企業庁(2026年1月施行) ・特定運送委託の追加、従業員基準(300人/100人超)の新設、  約束手形の全面禁止と受領後60日以内の現金払が徹底。 ・発注時の電磁的記録交付義務、振込手数料の一方的な差引禁止、  価格転嫁協議の記録保存を共通EDI×ZEDIで確実に証明。 → 発注・受領日・決済日のタイムスタンプ証跡が法的防御に
2026年1月施行|中小受託取引適正化法(取適法)

受発注・経理システムに直結する5つの法定ポイント

  • ・特定運送委託の追加:発荷主から実運送事業者への運送委託も新たに保護・書面交付義務の対象に。
  • ・従業員基準(300人/100人)の新設:資本金が小さくても従業員300人超(製造・特定運送等)や100人超(役務等)の委託事業者は対象に。
  • ・約束手形の全面禁止・60日以内現金払:手形および60日超サイトの電子記録債権・ファクタリングが禁止され、受領後60日以内の現金決済が原則に。
  • ・振込手数料差引の禁止:合意なき振込手数料の差し引きは代金減額違反となるため、ZEDIでの先方/当方負担コード管理が不可欠。
2028年末期限|ISDN(メタル回線補完策)完全終了

電話回線EDIからインターネット標準APIへの移行先

  • ・商流(製造・卸・小売):JCA手順や全銀ベーシック手順から、中小企業共通EDI(UN/CEFACT CII)または流通BMS(JX手順)へ移行。
  • ・金流(銀行決済・入金消込):固定長120バイト電文から、請求明細を無制限に添付できる全銀ZEDI(ISO 20022 XML)へ移行。
  • ・物流(配車・出荷・荷待ち記録):FAX配車表から、国交省・経産省推進の物流情報標準ガイドライン ver.3.00(JSON API)へ接続し、改正物効法のCLO報告・荷待ち実測データと連動。
規格・制度の名称 カバーする領域 主な対象データ・役割 実務上のメリット
中小企業共通EDI / 流通BMS 商流(見積〜請求) 見積・注文・注文請・出荷・検収・請求の標準メッセージ(UN/CEFACT・流通BMS) 2028年末ISDN終了に対応し、取引先ごとの項目名の違いを吸収して手入力をなくす。
全銀EDIシステム(ZEDI) 金流(銀行振込・消込) 総合振込(pain.001)・入出金明細(camt.054)のISO 20022 XML金融情報 請求書番号や手数料内訳を同梱し、取適法(手数料差引禁止・60日現金)と自動消込を両立。
物流情報標準 ver.3.00 物流(運送委託・倉庫) 運送依頼・出荷予定・入出荷実績・荷待ち時刻を結ぶ標準JSON API仕様 特定運送委託の電磁書面交付と、改正物効法(CLO・荷待ち2時間以内)の実測証跡を自動化。
Peppol(JP PINT) 請求(インボイス) デジタル庁が策定した国際標準ベースの適格請求書(デジタルインボイス)仕様 T番号照合・2026年10月70%控除経過措置の税額計算と電帳法保存を自動化する。
共通EDI推進サポータ 人材・伴走支援 ITCA等が認定する、中小企業の商流・EDI改革の専門アドバイザー 取引先とのデータ連携調整や業務フロー見直し(BPR)を中立的な立場で支援。
UN/CEFACT CII XML × ISO 20022 (pain.001 / camt.054) × 2026年1月施行「改正下請法(取適法)」技術仕様
4. 詳しい技術仕様としくみ:UN/CEFACT CII & ISO 20022 ZEDI

UN/CEFACT CII XML × ISO 20022 (pain.001 / camt.054) × 2026年1月施行「改正下請法(取適法)」技術仕様

4. 詳しい技術仕様としくみ

ISO 20022 XML(pain.001 / camt.054)構造解析、BEC(偽装振込先詐欺)暗号ロック、およびRust×PostgreSQL 19決定論的消込エンジン

ここからは、システム設計者・セキュリティ技術者向けに、ZEDIのISO 20022 XMLスキーマの内部構造、ビジネスメール詐欺(BEC)による不正送金を数学的に遮断する口座ロック機構、そして db01.ok.st(PostgreSQL 19)とRust 2024を用いた決定論的消込アルゴリズムを解説します。

図7:ZEDI ISO 20022 XML(<RmtInf><Strd>)検証パイプラインとBEC(偽装口座変更)遮断アーキテクチャ
ISO 20022 XML <RmtInf> 構造化解析 × BEC口座改ざん検知 × PostgreSQL 19 決定論的消込 1. ZEDI XML Ingress (camt.054) <NtryDtls><TxDtls> <RmtInf><Strd> <RfrdDocInf>INV-992 <RfrdDocAmt> DuePyblAmt / DscntApldAmt XXE無効化・厳格XSD型検証 2. BEC(偽装口座詐欺)防止ゲート ・適格請求書T番号(Modulo-9検査) ・全銀金融機関コード+支店+口座 ・BLAKE3(T番号 || 口座情報 || 承認鍵) → メールやPDFで振込先口座が  書き換えられても送金生成を遮断 3. Rust 2024 決定論的消込エンジン ・Tier 1: RfrdDocInf (請求番号) 完全一致 ・Tier 2: 注文番号 + 検収番号 一致 ・Tier 3: 複数請求の部分和 + 手数料  定数セット(0, 110..880)円探索 ・貸借一致不変条件 (Debit == Credit) 4. データベース基盤(db01.ok.st:FreeBSD 15.1 + OpenZFS + PostgreSQL 19)での冪等永続化 • uuidv7() 時系列主キー + B-tree Skip Scan による高速な未消込売掛金スキャン • INSERT INTO zedi_settlements ... ON CONFLICT (acct_svcr_ref) DO SELECT RETURNING *  (銀行APIの重複ポーリング時も不要なWAL書き込み・ZFS CoW断片化を0バイトに抑えて既存消込結果を返却) • FORCE ROW LEVEL SECURITY + InitPlan (SELECT sovereign_auth.current_tenant_id()) でテナント間完全隔離

1. ZEDIが用いる ISO 20022 XML(pain.001 / camt.054)の構造解剖

従来の全銀ベーシック手順・TCP/IP手順における総合振込フォーマットは、1件あたり120バイトの固定長レコードであり、顧客任意のEDI情報欄はわずか20文字(半角カナ・英数字)しかありませんでした。そのため、複数枚の請求書を合算して振り込む場合や、振込手数料・協力会費・返品相殺を差し引いた場合に、内訳を伝達することが原理的に不可能でした。 ZEDIでは、国際標準 ISO 20022 の pain.001.001.03(総合振込依頼)および camt.054.001.02(入出金取引明細通知)を採用し、<RmtInf><Strd>(構造化送金情報)タグ内に複数の請求明細と調整額を格納します。

// ZEDI ISO 20022 (camt.054.001.02) 構造化送金情報 <RmtInf><Strd> の抜粋例
<NtryDtls>
  <TxDtls>
    <Refs>
      <AcctSvcrRef>ZEDI-20261030-0098124</AcctSvcrRef>
      <EndToEndId>E2E-ORD-2026-081-992</EndToEndId>
    </Refs>
    <Amt Ccy="JPY">1479450</Amt>
    <CdtDbtInd>CRDT</CdtDbtInd>
    <RmtInf>
      <!-- 1件目の請求書(INV-2026-0912:980,000円) -->
      <Strd>
        <RfrdDocInf>
          <Tp><CdOrPrtry><Cd>CINV</Cd></CdOrPrtry></Tp>
          <Nb>INV-2026-0912</Nb>
          <RltdDt>2026-09-30</RltdDt>
        </RfrdDocInf>
        <RfrdDocAmt>
          <DuePyblAmt Ccy="JPY">980000</DuePyblAmt>
          <RmtdAmt Ccy="JPY">980000</RmtdAmt>
        </RfrdDocAmt>
      </Strd>
      <!-- 2件目の請求書(INV-2026-0945:500,000円、振込手数料550円調整) -->
      <Strd>
        <RfrdDocInf>
          <Tp><CdOrPrtry><Cd>CINV</Cd></CdOrPrtry></Tp>
          <Nb>INV-2026-0945</Nb>
          <RltdDt>2026-09-30</RltdDt>
        </RfrdDocInf>
        <RfrdDocAmt>
          <DuePyblAmt Ccy="JPY">500000</DuePyblAmt>
          <AdjstmntAmtAndRsn>
            <Amt Ccy="JPY">550</Amt>
            <CdtDbtInd>DBIT</CdtDbtInd>
            <Rsn>FEE</Rsn>
          </AdjstmntAmtAndRsn>
          <RmtdAmt Ccy="JPY">499450</RmtdAmt>
        </RfrdDocAmt>
      </Strd>
    </RmtInf>
  </TxDtls>
</NtryDtls>

2. Rust 2024による決定論的入金消込・振込先改ざん(BEC)検知・改正下請法60日サイト検証

消込や支払データ生成に確率的な生成AI(LLM)を直接使うと、1円の端数誤差や口座番号のハルシネーションが起きるリスクがあります。 そのため、書類の読み取り補助にはAIを使いつつも、最終的な金額の一致検証・振込手数料の仕訳生成・受取口座の真正性チェック・改正下請法(取適法)の60日支払期日検査は、すべてRustの型安全な決定論的ロジックで実行します。

// Rust 2024: ZEDI構造化消込・BEC口座ロック・改正下請法60日サイト検証エンジン
#![forbid(unsafe_code)]

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct OpenReceivable {
    pub invoice_no: String,
    pub order_no: String,
    pub acceptance_date_epoch_days: u32,
    pub billed_yen: i64,
    pub registered_account_hash: [u8; 32],
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct ZediStructuredItem {
    pub referred_invoice_no: String,
    pub due_payable_yen: i64,
    pub fee_adjustment_yen: i64,
    pub remitted_yen: i64,
}

#[derive(Debug, Clone, PartialEq, Eq)]
pub enum ReconciliationVerdict {
    ExactZediMatch {
        matched_invoices: Vec<String>,
        total_billed_yen: i64,
        bank_fee_yen: i64,
        net_settled_yen: i64,
    },
    BlockedByBecAccountMismatch {
        invoice_no: String,
    },
    BlockedBySubcontractAct60DayLimit {
        invoice_no: String,
        elapsed_days: u32,
    },
    UnreconciledResidual {
        residual_yen: i64,
    },
}

/// ZEDI XML明細と売掛金台帳を突合し、1円単位の貸借一致と法令・BEC防壁を検証する
pub fn verify_zedi_settlement(
    receivables: &[OpenReceivable],
    zedi_items: &[ZediStructuredItem],
    actual_bank_credit_yen: i64,
    settlement_date_epoch_days: u32,
    presented_account_hash: &[u8; 32],
) -> ReconciliationVerdict {
    let mut matched_ids = Vec::with_capacity(zedi_items.len());
    let mut sum_billed: i64 = 0;
    let mut sum_fee: i64 = 0;
    let mut sum_remitted: i64 = 0;

    for item in zedi_items {
        let Some(rec) = receivables
            .iter()
            .find(|r| r.invoice_no == item.referred_invoice_no)
        else {
            return ReconciliationVerdict::UnreconciledResidual {
                residual_yen: actual_bank_credit_yen,
            };
        };

        // 1. BEC(偽装請求書による振込先口座書き換え詐欺)の暗号学的ロック検証
        if &rec.registered_account_hash != presented_account_hash {
            return ReconciliationVerdict::BlockedByBecAccountMismatch {
                invoice_no: rec.invoice_no.clone(),
            };
        }

        // 2. 2026年改正下請法(取適法)受領後60日以内支払ルールの検証
        let elapsed_days = settlement_date_epoch_days.saturating_sub(rec.acceptance_date_epoch_days);
        if elapsed_days > 60 {
            return ReconciliationVerdict::BlockedBySubcontractAct60DayLimit {
                invoice_no: rec.invoice_no.clone(),
                elapsed_days,
            };
        }

        // 3. 明細単位の金額不変条件(請求額 - 調整手数料 == 送金額)
        if rec.billed_yen != item.due_payable_yen
            || (item.due_payable_yen - item.fee_adjustment_yen) != item.remitted_yen
        {
            return ReconciliationVerdict::UnreconciledResidual {
                residual_yen: actual_bank_credit_yen - sum_remitted,
            };
        }

        matched_ids.push(rec.invoice_no.clone());
        sum_billed = sum_billed.saturating_add(rec.billed_yen);
        sum_fee = sum_fee.saturating_add(item.fee_adjustment_yen);
        sum_remitted = sum_remitted.saturating_add(item.remitted_yen);
    }

    // 4. 着金総額と明細合計の完全一致(複式簿記の貸借一致保証)
    if sum_remitted == actual_bank_credit_yen && (sum_billed - sum_fee) == actual_bank_credit_yen {
        ReconciliationVerdict::ExactZediMatch {
            matched_invoices: matched_ids,
            total_billed_yen: sum_billed,
            bank_fee_yen: sum_fee,
            net_settled_yen: actual_bank_credit_yen,
        }
    } else {
        ReconciliationVerdict::UnreconciledResidual {
            residual_yen: actual_bank_credit_yen - sum_remitted,
        }
    }
}

3. db01.ok.st(PostgreSQL 19)における冪等ZEDI消込スキーマ

銀行APIやZEDIゲートウェイから入出金明細(camt.054)を定期取得する際、ネットワーク再試行によって同じ取引通知が複数回届くことがあります。 db01.ok.st の PostgreSQL 19 では、uuidv7() による時系列クラスタリング主キーと、新構文 INSERT ... ON CONFLICT DO SELECT を組み合わせることで、重複受信時に不要なダミー更新(WAL発生・OpenZFS CoW汚染)を一切起こさず、1往復で既存の消込結果を返却します。

-- PostgreSQL 19 (db01.ok.st): ZEDI決済・共通EDI突合テーブルと冪等登録クエリ
CREATE TABLE IF NOT EXISTS common_edi_zedi_settlements (
    settlement_id      UUID PRIMARY KEY DEFAULT uuidv7(),
    tenant_id          UUID NOT NULL,
    acct_svcr_ref      TEXT NOT NULL, -- 銀行ZEDI一意参照番号
    end_to_end_id      TEXT NOT NULL, -- 共通EDI注文・請求リレーID
    settled_yen        BIGINT NOT NULL CHECK (settled_yen >= 0),
    bank_fee_yen       BIGINT NOT NULL DEFAULT 0 CHECK (bank_fee_yen >= 0),
    remittance_jsonb   JSONB NOT NULL,
    settled_at         TIMESTAMPTZ NOT NULL DEFAULT clock_timestamp(),
    UNIQUE (tenant_id, acct_svcr_ref)
);

ALTER TABLE common_edi_zedi_settlements ENABLE ROW LEVEL SECURITY;
ALTER TABLE common_edi_zedi_settlements FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation_zedi_policy ON common_edi_zedi_settlements
    USING (tenant_id = (SELECT sovereign_auth.current_tenant_id()));

-- PostgreSQL 19 INSERT ... ON CONFLICT DO SELECT によるゼロWAL冪等取得
INSERT INTO common_edi_zedi_settlements (
    tenant_id, acct_svcr_ref, end_to_end_id, settled_yen, bank_fee_yen, remittance_jsonb
) VALUES (
    (SELECT sovereign_auth.current_tenant_id()),
    'ZEDI-20261030-0098124',
    'E2E-ORD-2026-081-992',
    1479450,
    550,
    '{"invoices":["INV-2026-0912","INV-2026-0945"]}'::jsonb
)
ON CONFLICT (tenant_id, acct_svcr_ref) DO SELECT
RETURNING settlement_id, acct_svcr_ref, settled_yen, bank_fee_yen, settled_at;
よくあるご質問(FAQ) 実務でよく寄せられる質問と回答

中小企業共通EDI・全銀ZEDI・改正下請法に関するよくあるご質問

Q1 ITCA認定「中小企業共通EDI推進サポータ」とは何ですか? ▼

経済産業省推進資格ITコーディネータ協会(ITCA)が認定する、中小企業共通EDI(国際標準規格UN/CEFACT CII準拠)の普及・導入を支援する専門資格です。受発注業務における多画面問題や手作業の二重入力を根絶し、商流(受発注・納品・請求)と金流(銀行決済・入金消込)のシームレスな自動連携を指導します。

Q2 取引先ごとに異なるWeb-EDI画面に手入力する「多画面問題」はなぜ起き、どう解消できますか? ▼

発注元の大手企業がそれぞれ独自のWeb-EDIシステムを構築し、下請・協力会社に個別ログインを強要したために発生しています。担当者が毎日10社以上の別々の画面を開いて注文書を印刷し、自社の基幹ソフトへ再入力する膨大な工数浪費が生じています。国際標準メッセージ(UN/CEFACT)に基づく「中小企業共通EDI」を採用することで、画面を開くことなく社内システム間で直接データ送受信が完結します。

Q3 中小企業共通EDIの国際標準規格「UN/CEFACT CII」とは何ですか? ▼

国連の専門機関(UN/CEFACT)が策定した電子インボイス・商取引メッセージのグローバル標準規格(Cross Industry Invoice)です。取引先ごとに異なる商品コードや単位の揺らぎを標準データ辞書で吸収し、異なるベンダーのERPや受発注システム同士でもマッピングの齟齬なく完全自動連携できます。

Q4 全銀EDIシステム「ZEDI」とは何ですか?従来の固定長120バイト電文と何が違いますか? ▼

一般社団法人全国銀行協会が運営する、企業間決済のための次世代金融EDIシステムです。従来の全銀システムは「カナ20文字の振込依頼人名」や「固定長120バイト」という極めて短い情報しか送れず、どの請求書の入金なのか判別不能でした。ZEDIは国際規格「ISO 20022 XML電文」に対応し、請求書番号や明細データを無制限に添付して送金できます。

Q5 ZEDIの「ISO 20022 XML電文」を活用すると、なぜ売掛金の入金消込作業が完全自動化できるのですか? ▼

送金電文の中に「どの請求書に対する支払いか(請求書番号・消費税額・相殺額)」が構造化XMLデータとして直接含まれるためです。経理担当者が通帳やネットバンキングを目視確認してExcelで突き合わせる作業が不要になり、会計システムがXML電文を読み取って売掛金を1秒で自動照合・消込仕訳まで完了します。

Q6 2026年施行の「改正下請法(中小受託取引適正化法:取適法)」で変わる対象範囲と電磁的記録の要件とは何ですか? ▼

2026年1月施行の取適法では、従来の資本金基準に加えて「従業員数基準(300人超・100人超)」が新設され、荷主から運送事業者への「特定運送委託」も規制対象に追加されました。さらに約束手形の利用禁止、振込手数料の一方的な差し引き禁止、受領後60日以内の現金払、発注時の電磁的記録(取適法第4条)交付と監査ログ保管が求められます。

Q7 2028年末のISDN(メタル回線補完策)完全終了に向け、レガシーEDIやFAX受注からどう移行すべきですか? ▼

2028年末のISDN完全終了を見据え、①商流は「中小企業共通EDI(UN/CEFACT CII)」や「流通BMS」、②金流は銀行の「全銀ZEDI(ISO 20022 XML)」、③物流連携は「物流情報標準ガイドライン ver.3.00(JSON API)」へ段階的に切り替えるのが確実です。FAX注文書が残る取引先はAI自動読取で共通EDI形式へ変換し、社内システムへの手入力をなくせます。

Q8 取引先が共通EDIに対応していない場合でも、自社側で先行してメリットを享受する方法はありますか? ▼

あります。自社の請求管理システムから全銀ZEDI(ISO 20022 XML)形式で総合振込データを出力できるようにしておけば、自社の買掛金支払い業務や仕訳処理が大幅に省力化されます。また、取引先に対しても共通EDI形式でのCSVダウンロード機能等を提供することで、徐々にペーパーレス化を促せます。

あわせて読みたい関連ナレッジ・公的制度ガイド

体験サンプル公開中・個別環境の安全な分離

登録不要で確認できる画面見本(ZEDI消込・取適法60日・ISDN移行 3項目チェックサンプル)

※この静的見本表示では通信やデータ保存は行われません
項目 01 自動消込見本

ZEDI XML明細の自動突合

camt.054内の複数請求番号(INV-992等)と振込手数料区分を照合し、差額0円を自動判定

項目 02 法令検証見本

2026年取適法 適合チェック

受領後60日以内の現金決済・約束手形不使用・合意なき振込手数料差引なしを決定論検証

項目 03 移行判定見本

2028年末ISDN終了 移行診断

既存の電話回線EDI・多画面Web-EDIを共通EDI / 流通BMS / 物流標準v3.00 JSON APIへ整理

実際の60秒Web点検・学習演習の記録保存は「3秒1タップ簡易安全登録」で個別に保護されます

共用ゲスト利用によるデータ混線を防ぐため、実データの診断・保存時は Google / LINE / パスキー(Passkey) / メール確認コード(パスワード設定不要)にて、専用データベース(db01.ok.st:PostgreSQL 19 行レベル分離保護)上で安全にご利用いただけます。

図解・ビジュアルの拡大表示

図表内のテキストもそのまま選択・検索可能です(ベクターSVG描画) 枠外クリックまたは ESC キーで閉じます