中小企業共通EDI標準(UN/CEFACT CII)と全銀EDIシステム(ZEDI / ISO 20022)による受発注・入金消込の自動化
なぜ「注文の打ち直し」と「月末の入金消込」で毎月何十時間も消えてしまうのか?
まずは専門用語を使わずに、「共通EDI」「ZEDI(全銀EDI)」「EDIサポーター」の3つが、日々の受発注と経理の現場をどう変えるのかを図解で確認しましょう。
「中小企業共通EDI」で多画面・FAX打ち直しを解消
発注側A社では「品番」、B社では「品目コード」と呼び方が違っても、国の標準辞書(共通EDI)を間に挟むことで、自社の販売管理へそのまま自動取り込みできます。
「全銀EDI(ZEDI)」で振込に請求書番号を添付
これまでの銀行振込は「カタカナ名義と合計金額」しか届きませんでした。ZEDIを使えば「どの請求書の、どの明細の支払いか(振込手数料や値引きはいくらか)」がデータで届き、消込が一瞬で終わります。
「EDIサポーター」が取引先との調整を橋渡し
自社だけで取引先にデータ形式の変更をお願いするのは大変です。公的研修を修了した「共通EDI推進サポータ」が、業務整理からデータ項目のマッピング、段階的移行までを中立の立場で支援します。
取引先ごとにバラバラな注文書・請求書を共通フォーマットに揃え、振込データと自動照合する実務手順
高額な専用システムを作らずに、既存ソフトを活かして段階移行する4つの手順
「EDIを入れるには数百万円のシステム改修が必要ではないか」と心配されることがありますが、中小企業共通EDIとZEDIは、今使っている販売管理ソフトやクラウド会計ソフト、ネットバンキングを活かして小さく始めることができます。
現場担当者が今日から確認できる「受発注・決済デジタル化」3つの実務チェックリスト
チェック1:固定電話回線・モデムの確認
社内の隅に「発注データ受信用」の古いパソコンやモデム、ターミナルアダプタ(TA)が残っていないか確認します。メタル回線の維持費や故障リスクを洗い出します。
チェック2:法人ネットバンキングのZEDI対応確認
現在契約している銀行(都市銀行・地方銀行・信用金庫)の法人インターネットバンキングでは、多くの場合わずかな設定追加または標準機能で「ZEDI(XMLファイル入出力)」が利用可能です。
チェック3:振込先口座変更の承認ルール
「メールやPDFで取引先から口座変更の連絡が来たら、必ず登録済みの電話番号へ折り返し確認する」および「適格請求書登録番号と口座名義の一致を確認する」手順を徹底します。
| 比較項目 | 従来の全銀固定長フォーマット(120バイト) | 全銀ZEDI(ISO 20022 XML電文・次世代) |
|---|---|---|
| 電文データ構造 | 固定長120バイト。半角カナと数字のみ。 | 国際規格 ISO 20022準拠のXMLフォーマット。拡張可能。 |
| EDI情報(請求明細) | わずか EDI情報20バイト。請求書番号1件すら入らない。 | タグ情報無制限。複数請求書番号、明細、相殺額を完全包含。 |
| 入金消込作業 | 通帳コピーと請求書を人間が手作業・目視で突き合わせ(月末の残業要因)。 | 請求書番号と金額が完全一致するため、会計システムが 1秒で自動消込。 |
| 多画面問題への耐性 | 取引先ごとに銀行やWeb画面が異なり、二重入力のヒューマンエラー多発。 | UN/CEFACT中小企業共通EDIと直結し、画面レス・手入力ゼロで連動。 |
| 2026年改正下請法(取適法) | 振込依頼書の手動保管では電磁的記録の監査ログ要件に適合困難。 | 取引明細の電磁的タイムスタンプと改ざん防止ログが 法的に完全準拠。 |
2028年末ISDN終了・全銀ZEDI・流通BMS・物流情報標準ver.3.00・2026年取適法の体系整理
受発注と決済のデジタル化は、単なる業務効率化にとどまらず、2028年末のISDN完全終了を見据えた次世代EDI(ZEDI・流通BMS・物流情報標準ガイドライン ver.3.00 JSON API)への移行、そして2026年施行の改正下請法(中小受託取引適正化法:通称「取適法」)などの法令遵守と直結しています。
受発注・経理システムに直結する5つの法定ポイント
- ・特定運送委託の追加:発荷主から実運送事業者への運送委託も新たに保護・書面交付義務の対象に。
- ・従業員基準(300人/100人)の新設:資本金が小さくても従業員300人超(製造・特定運送等)や100人超(役務等)の委託事業者は対象に。
- ・約束手形の全面禁止・60日以内現金払:手形および60日超サイトの電子記録債権・ファクタリングが禁止され、受領後60日以内の現金決済が原則に。
- ・振込手数料差引の禁止:合意なき振込手数料の差し引きは代金減額違反となるため、ZEDIでの先方/当方負担コード管理が不可欠。
電話回線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月施行「改正下請法(取適法)」技術仕様
ISO 20022 XML(pain.001 / camt.054)構造解析、BEC(偽装振込先詐欺)暗号ロック、およびRust×PostgreSQL 19決定論的消込エンジン
ここからは、システム設計者・セキュリティ技術者向けに、ZEDIのISO 20022 XMLスキーマの内部構造、ビジネスメール詐欺(BEC)による不正送金を数学的に遮断する口座ロック機構、そして db01.ok.st(PostgreSQL 19)とRust 2024を用いた決定論的消込アルゴリズムを解説します。
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>(構造化送金情報)タグ内に複数の請求明細と調整額を格納します。
<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の型安全な決定論的ロジックで実行します。
#![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往復で既存の消込結果を返却します。
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;
中小企業共通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ダウンロード機能等を提供することで、徐々にペーパーレス化を促せます。
あわせて読みたい関連ナレッジ・公的制度ガイド
DXサポーター・DX認定・デジタルガバナンス実践ガイド
経産省DX認定とスマートSMEサポーターを活用した段階的業務改善の手順。
現場業務改革(AX)プロンプト不要の現場AI(Zero-Prompt AX)実践ガイド
FAX注文書や紙の請求書を3項目確認だけで共通EDI・会計へつなぐ仕組み。
取引先信頼・セキュリティサプライチェーン強化に向けたセキュリティ対策評価制度(☆3・☆4)ガイド
取引先とのEDI連携や受発注データを守る☆3(26項目)/☆4(43項目)の実践対策。
2026年物流2大法改正・配車DX2026年4月『改正物流効率化法(CLO)』×『取適法(特定運送委託)』統合特集
特定荷主CLO・荷待ち2時間以内・実運送体制管理簿と0.8秒AI起票・Rust配車DX。
登録不要で確認できる画面見本(ZEDI消込・取適法60日・ISDN移行 3項目チェックサンプル)
ZEDI XML明細の自動突合
camt.054内の複数請求番号(INV-992等)と振込手数料区分を照合し、差額0円を自動判定
2026年取適法 適合チェック
受領後60日以内の現金決済・約束手形不使用・合意なき振込手数料差引なしを決定論検証
2028年末ISDN終了 移行診断
既存の電話回線EDI・多画面Web-EDIを共通EDI / 流通BMS / 物流標準v3.00 JSON APIへ整理
実際の60秒Web点検・学習演習の記録保存は「3秒1タップ簡易安全登録」で個別に保護されます
共用ゲスト利用によるデータ混線を防ぐため、実データの診断・保存時は Google / LINE / パスキー(Passkey) / メール確認コード(パスワード設定不要)にて、専用データベース(db01.ok.st:PostgreSQL 19 行レベル分離保護)上で安全にご利用いただけます。
親子・兄弟・深掘り見通しナビ(DX/AX・次世代EDI体系マップ)
親カテゴリ一覧、横並びの関連実務ガイド(兄弟ページ)、および技術仕様の深掘りページへ直接移動できます。
DX認定・デジタルガバナンス・コード3.0実践ガイド
経産省DGC 3.0・DX認定・SCS☆3(26項目)/☆4(43項目)・医療3省2GL第7.0版の証跡整備を整理します。
プロンプト不要の現場3項目AI業務自動化(AX)入門
指示文入力をなくし、メール・LINE・電話・FAX等13種以上の連絡から5大台帳へ自動起票する設計を図解します。
FAX・PDF注文書の自動構造化と電磁書面・在庫連携
手書きFAXやPDF注文書を0.8秒で構造化し、物効法12条・取適法4条の電磁書面交付とfreee連携までつなぎます。
受発注・倉庫(EDI/WMS)連鎖停止防止とオフライン縮退BCP
EDIゲートウェイと倉庫出荷のネットワーク分離およびOpenZFS 0.38秒不変復旧の構成を深掘りします。