◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 標準データ形式は受発注・請求・決済で住み分けており、一つの規格ですべての業務は賄えません。
- 消費財流通向けの標準は基本形の2.0版が2018年に公開され、業務ごとにメッセージが分かれています。
- 振込に情報を添える仕組みでは、固定長で20桁だった欄をXML電文へ広げ、消込の材料を送れます。
- 選定は取引先の採用状況、接続方式、対応業務の範囲の順に絞ると、後戻りが減ります。
- 電子取引のデータは電子のまま保存し、取引年月日・取引金額・取引先の3項目で検索できる状態が要ります。
目次

電子受発注の標準データ形式とは
電子受発注の標準データ形式とは、注文や出荷、請求のやり取りを電子データで交わすために、項目の並びと意味を共通化した取り決めです。取引先ごとの帳票や画面に個別で合わせるのではなく、業界や制度の側で定めた型へそろえる点が違いになります。国内では消費財流通向けの流通BMS3、中小企業の受発注に向けた中小企業共通EDI7、振込電文に情報を添えるZEDI5、請求を担うJP PINT1が代表格でしょう。どれか一つを選べば足りるものではなく、業務の範囲ごとに使い分ける前提で考えます。
標準データ形式が定めているのは、主に「何を送るか」の側です。発注番号や納品日、商品を表すコード、数量、単価といった項目の名前と意味、桁の取り方、必須か任意かの区分が仕様として並びます。加えて、発注・出荷・受領・請求といった業務の単位ごとに、メッセージと呼ばれる文書の型が用意されます*4。逆に、その文書をどの回線でどう運ぶかは別の取り決めであり、同じデータ形式のまま通信の方式だけを選び直すこともできます。
自社で定義したCSVやテキストとの違いは、変更が起きたときの波及範囲に表れます。独自定義では、項目を一つ増やすたびに、つないでいる取引先の数だけ改修と確認の作業が発生します。標準に寄せておけば、改版は仕様の側で管理され、対応の判断も仕様書を基準に進められます。取引先が増えるほど、この差は日々の運用の手間として積み上がっていきます。
効き目が出やすいのは、転記と照合が挟まる工程です。受注データを基幹システムへ手で打ち直す作業、納品書と請求書を突き合わせる作業、入金と請求を消し込む作業が該当します。振込にEDI情報を添える仕組みでは、従来の固定長の電文で20桁に限られていた情報欄をXML電文へ広げ、支払の明細を振込と一緒に送れるようにしています56。照合の材料がデータとして届けば、人手で探す作業そのものが減ります。
電子で受発注を交わすと、そのデータは保存の対象にもなります。電子取引でやり取りした注文書や請求書は、電子データのまま保存する扱いが2024年から本格的に求められています2。保存にあたっては、取引年月日・取引金額・取引先の3項目で検索できる状態にしておく必要があります2。データ形式の選定は、後工程の保存要件まで見て決めるものだと言えます。
標準へそろえても、自社の項目との対応付けは残ります。社内の商品コードと取引で使う識別コード、社内の得意先コードと取引先の事業所コードは、別の体系であることが普通です。両者を結ぶ対応表を誰が持ち、誰が更新するかを決めないまま接続すると、コードの不一致による受注エラーが日々の運用で起こります。標準は共通部分を減らす仕組みであって、自社側の整理を肩代わりするものではありません。
どの形式が自社に合うかは、業界と取引先、そして既存システムの構成で変わります。消費財の卸売や小売との取引が中心なら流通BMS3、規模の小さい取引先を数多く抱えるなら中小企業共通EDI7が候補に入ります。請求と支払まで電子で通したい場合は、JP PINT1やZEDI5を組み合わせる形になります。一つの規格ですべてを賄おうとすると、対象外の業務が手作業のまま残ります。
移行の検討で先に確定させる順に並べた5点(順位根拠:後の工程が前の決定に依存する着手順序)
- 回線と通信手順の期限を確認します。従来の接続方式は新規申込の受付終了日とサービス提供終了日が2024年に公表されており、ここから全体の日程を逆算します。
- 主要な取引先が採用している形式を確かめます。相手からの指定がある場合は、その形式に合わせる経路が接続の近道になります。
- 対象とする業務の範囲を決めます。受発注だけか、請求と決済まで通すかで、必要な標準の数と接続の本数が変わります。
- 自社の項目と標準の項目の対応表を作ります。基本形の2.0版が2018年に公開された標準では、業務ごとに必須項目と任意項目が分かれています。
- 保存の要件を設計に組み込みます。取引年月日・取引金額・取引先の3項目で検索できる状態を、本稼働の前に用意します。
標準データ形式が求められる背景
標準データ形式が求められる背景には、取引先ごとの個別対応が積み上がった現状と、通信回線そのものの切り替えがあります。FAXやメール、取引先ごとの専用画面が並ぶ運用では、担当者が同じ内容を何度も入力し直すことになります。さらに、従来のEDIを支えてきた回線については、新規申込の受付終了日とサービス提供終了日が2024年に公表されました*8。回線の見直しと同じ機会に、載せるデータの形もそろえ直す判断が求められています。
個別対応の負担は、接続の本数に比例して増えます。取引先が増えれば、項目の並びも締め時間も異なる手順を、その数だけ業務部門が覚えることになります。担当者が交代するたびに引き継ぎの資料を作り直し、繁忙期には確認の電話が増えます。作業量そのものよりも、例外処理を誰も一覧化できていない状態が痛手になります。
転記の過程で数量や納期を取り違えると、影響は自社の中では止まりません。誤った数量で出荷すれば返品と再配送が発生し、納期を取り違えれば取引先の生産計画や売場の計画に響きます。請求金額の誤りは、入金の保留と督促のやり取りを生み、月次の締めを遅らせます。受発注の入り口で形をそろえることは、こうした後戻りを抑える手当てでもあります。
回線の切り替えは、期限が外から決まる点で他の課題と性質が違います。ディジタル通信モードを前提にした従来型の接続は、終了の時期が2024年に公表済みであり、移行の検討を先送りできません*8。切り替え先はインターネット経由の接続が中心となり、暗号化や証明書の扱いなど運用の作法も変わります。回線を替える工事の機会に、データ形式の見直しを重ねる進め方が現実的でしょう。
受発注の話は、受発注だけでは完結しません。受発注のデータが確定し、出荷・検収の実績が返り、請求の内容が固まり、決済でお金が動きます。この一連の流れのどこかが紙や電話のままだと、その手前まで電子化しても照合の作業は残ります。商流から金流までを同じ識別で通すことが、標準へそろえる本来の狙いです。
制度の側からも、電子でやり取りする前提が広がっています。デジタルインボイスの標準仕様は、請求のデータを人手を介さずに相手の会計システムへ届けることを狙って整備されました1。電子取引のデータは電子のまま保存する扱いが2024年から定着し、紙に出力して保管する運用は見直しの対象です2。受発注の電子化は、経理と会計の側の要件とつながって進んでいます。
背景は、社内の負担、外部から来る期限、制度の三つが重なった状態だと整理できます。どれか一つだけを理由に投資の判断を通そうとすると、優先順位の説明が弱くなります。回線の期限を軸に据え、その機会に負担の削減と保存要件の充足をまとめて取りに行く組み立てが通りやすいでしょう。社内の合意を得る資料も、この三つを並べて書くと通りが良くなります。
自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。
国内の電子受発注で使われる主な標準データ形式
国内の電子受発注で使われる標準データ形式は、対象とする領域で住み分けています。消費財の流通では流通BMSが使われ、基本形の2.0版が2018年に公開されています34。中小企業の受発注には中小企業共通EDIがあり、標準の更新は2026年時点でも続いています7。請求のやり取りはJP PINT1、振込に添える情報はZEDI*5が受け持ちます。どれを見るかは、電子化したい工程で決まります。
消費財流通向けの標準では、業務ごとにメッセージの型が定められています。発注、出荷、受領、請求、支払といった単位で文書が分かれ、それぞれに必須項目と任意項目が並びます4。基本形は2.0版として整理され、2018年に公開された仕様が土台になっています3。小売と卸売、卸売とメーカーの間で同じ型を使える点が、この標準の効き所でしょう。
中小企業の受発注に向けた標準は、間口の広さを重視して作られています。業種を限定せず、見積から発注、納品、請求までの項目を共通の定義でそろえ、対応する製品やサービスを通じて接続する形を採ります7。標準そのものの更新は続いており、2026年時点でも最新版の情報が公開されています7。取引先の規模がばらつく場合に、相手側の負担を抑えられる選択肢になります。
請求と決済の領域は、受発注とは別の仕組みで標準化が進みました。振込にEDI情報を添えるZEDIでは、固定長の電文で20桁だった情報欄をXML電文に置き換え、支払の明細を振込と一緒に届けられます56。デジタルインボイスの標準仕様は、請求データを相手の会計システムへそのまま渡すことを狙って整備されています*1。入金消込の手作業を減らしたい場合、この二つが検討の対象に入ります。
受発注・請求・決済のどこを電子化したいかで、見るべき標準が変わります。対象とする領域と規定している範囲を並べて見ると、この住み分けがはっきりします。受発注だけを整えても請求書の突合は残り、請求だけを整えても入金の消込は残ります。自社の痛みがどの工程にあるかを先に決め、そこから対応する形式を引く順序が現実的です。
注意したいのは、どれか一つが上位互換になっているわけではない点です。仕様書に共通化を目指す旨が書かれていても、それを普及の実態と読み替えることはできません。取引先が採用していない形式を自社だけで採れば、結局は相手ごとの変換処理が挟まります。採用状況の確認が、比較の表を読むより先に来ます。
比較の材料をそろえる作業自体にも、相応の手間がかかります。仕様書は業務ごとに分冊で提供され、項目定義とコード体系、改版履歴を突き合わせて読む必要があります*4。社内に読み手がいない場合、要件定義の前段で時間を使い切ることになりかねません。読解と評価の工程を誰が担うかを、検討の開始時に決めておきます。
| 標準データ形式 | 対象とする領域 | 規定している範囲 |
|---|---|---|
| 流通BMS | 消費財流通の受発注 | 発注・出荷・受領・請求のメッセージと項目 |
| 中小企業共通EDI | 中小企業の受発注 | 見積から請求までの共通の項目定義 |
| ZEDI | 振込と入金消込 | 振込電文に添えるEDI情報の形式 |
| JP PINT | 請求のやり取り | デジタルインボイスの標準仕様 |

データ形式と通信手順・識別コードの関係
電子受発注の検討では、データ形式、通信手順、識別コードを分けて考えると混乱が減ります。メッセージ仕様は「何を送るか」、通信仕様は「どう送るか」、識別コードは「誰と何を指すか」を受け持ちます。同じ標準を採用しても、通信仕様が合わなければつながりませんし、識別コードがそろわなければ照合できません。回線の終了時期が2024年に公表された以上*8、通信仕様の見直しは形式の議論と同時に進みます。
メッセージ仕様は、項目の名前・意味・桁・必須区分と、業務ごとの文書の型を定めます*4。通信仕様は、そのデータをどの手順で送受信し、どう暗号化し、どう到達を確認するかを定めます。両者は独立しているため、メッセージ仕様を変えずに通信手順だけを差し替える移行も成り立ちます。回線の切り替えを先に済ませ、データ形式の統一を後から進める段取りが取れるのは、この切り分けがあるからです。
通信側の検討は、期限のある課題として扱う必要があります。従来の接続方式については、新規申込の受付終了日とサービス提供終了日が2024年に公表されました*8。切り替え先はインターネット経由の手順が中心で、証明書の管理や接続先の限定など、運用の作法が変わります。ここを社内で賄えるかどうかが、内製と委託の分かれ目になります。
識別コードは、取引の相手と対象物を一意に指すための番号です。事業所を指すコードと商品を指すコードが標準として整備され、受発注のメッセージの中でも使われます*3。自社の得意先コードや社内品番のままでは、相手のシステムで解釈できません。コードの付番と維持を担う担当を決めておくことが、接続後の安定につながります。
実務で時間を取られるのは、変換・マッピングの設計です。基幹システムの項目と標準の項目は一対一で対応せず、片方にしかない項目や、桁の合わない項目が必ず出ます。既定値を埋めるのか、運用で入力を足すのか、取引先に確認するのかを項目ごとに決めます。この判断を飛ばして接続すると、稼働後にエラーの調査が続きます。
内製で進める場合に要る知識は、狭くありません。仕様書の読解、基幹システムの項目設計、通信の証明書運用、コード体系の管理、そして取引先との調整が並びます。これらを兼務で回すと、繁忙期に確認の工程が止まります。担当の人数と期間を先に見積もり、埋まらない領域を外部に委ねる判断が要ります。
やり取りしたデータの保存も、接続の設計に含めます。電子取引のデータは電子のまま保存し、取引年月日・取引金額・取引先の3項目で検索できる状態にしておく必要があります*2。連携の記録だけを残しても、この要件は満たせません。どこに、どの形で、どれだけの期間残すかを、形式と通信の設計と同時に決めます。
自社に合う標準データ形式の選び方
自社に合う標準データ形式は、取引先の採用状況、自社システムとの接続方式、対応業務の範囲という三つの軸で絞れます。順番も効いてきます。取引先が使っていない形式を先に決めても、採用は進みません。消費財の流通が中心なら基本形の2.0版が2018年に公開された流通BMS3、規模の小さい取引先が多いなら中小企業共通EDI7が入口です。請求と入金まで通すなら、JP PINT1とZEDI5の併用を前提に考えます。
最初に確かめるのは、売上の大きい取引先が何を使っているかです。相手が指定する形式があるなら、その形式に合わせるのが接続の近道になります。指定がない取引先については、業界で整備が進んでいる形式を選び、こちらから提案する形を取ります。取引先ごとに違う形式を許すほど、社内の変換処理は膨らみます。
次に、基幹システム側の受け口を確認します。連携用の接続口が用意されているか、ファイル連携しかできないか、改修に開発が要るかで、選べる形式は絞られます。パッケージを使っている場合、対応済みの標準が製品側の資料に記されていることがあります*7。この確認を飛ばすと、形式を決めた後に接続部の作り込みが膨らみます。
三つ目の軸は、どの業務まで電子で通すかです。発注と出荷だけで足りるのか、請求と支払まで含めるのかで、必要な形式の数が変わります。請求の電子化まで見るなら、デジタルインボイスの標準仕様が対象に入ります*1。将来の取引先追加を見込むなら、拡張の余地がある形式を選んでおくほうが後で楽になります。
三つの軸を自社だけで評価するのは、軽い作業ではありません。仕様書の読解、取引先への照会、基幹システムの改修見積もりが同時に走ります。外部の担い手に委ねた場合との違いは、判断の速さと抜けの少なさに表れます。他社の接続で起きた項目の食い違いを知っていれば、同じ落とし穴を先回りで潰せます。
選定を誤ると、費用は接続の作り直しという形で戻ってきます。取引先が使っていない形式で構築すれば、相手ごとの変換処理を追加で抱えることになります。回線の終了時期が2024年に公表されている中で作り直しが起きると、切り替えの期日と重なります*8。選定の段階で採用状況を確かめる作業は、後戻りの費用を抑える手当てです。
どの形式にも、向く場面と向かない場面があります。一つの規格を全社の答えとして決め打ちするより、業務の範囲ごとに使う形式を割り当てる考え方が現実的でしょう。そのうえで、社内の変換処理を一箇所に集め、形式の増減を吸収できる作りにしておきます。判断の根拠を文書に残せば、取引先が増えたときの再検討も短く済みます。
標準データ形式へ移行する進め方
標準データ形式への移行は、現行データの棚卸し、取引先との調整、並行稼働、本稼働の順で進めます。全取引先を一度に切り替えるのではなく、対象を絞って一本目を通し、そこで得た知見を横展開する組み立てが安全です。回線の終了時期が2024年に公表されている以上8、期日から逆算した日程を最初に引く必要があります。保存の要件2まで設計に含めるのも、この段階です。
最初の段階は、現行の受発注データの棚卸しです。取引先の一覧化から始め、相手ごとの受発注の手段、件数、締め時間、使っている帳票を並べます。次に、自社の項目と標準の項目の突き合わせに進み、対応しない項目を洗い出します。ここで作った一覧が、後の工程すべての判断材料になります。
二段目は、取引先との調整です。項目の確認を書面で交わし、どの項目を必須にするか、任意項目に何を入れるかを決めます*4。あわせて締め時間の取り決めを更新し、受信が遅れたときの連絡経路も文書に残します。口頭で合意した内容は、担当者が替わった時点で失われます。
三段目の並行稼働では、従来の手段と新しい形式を同時に流します。両方の結果を突き合わせる差異の確認を毎日続け、件数と金額が一致するかを見ます。差異が出た場合は、項目の対応表と入力の運用のどちらに原因があるかを切り分けます。期間を短く切り上げると、月次でしか現れない例外を拾えません。
四段目の本稼働では、従来の手段を止め、新しい形式へ一本化します。切り替えの前に社内と取引先へ周知し、問い合わせの窓口と復旧の手順を決めておきます。稼働後は監視と保守の体制へ移り、送受信の失敗を検知して再送する運用を回します。ここまでを一つの計画として引くのが、移行の全体像です。
進め方が決まっても、動かす人が要ります。仕様の読み手、基幹システムの改修担当、取引先との窓口、稼働後の監視を担う人が、それぞれ必要になります。兼務で走らせると、並行稼働の差異の確認が後回しになり、切り替えの判断が鈍ります。社内で埋まらない役割を外部に委ねるほうが、期日には忠実でいられるでしょう。
取引先の数が多い場合には、対象を段階的に増やす進め方が取られます。件数の大きい相手から順に接続すれば、削減できる作業量が早く見えます。逆に、例外の多い相手を最初に選ぶと、標準では吸収しきれない要件の議論に時間を取られます。どちらを先に置くかは、効果の早期確認と難所の把握のどちらを優先するかで決まります。
電子取引データの保存で押さえる要件
電子でやり取りした受発注のデータは、電子のまま保存する扱いが求められます2。紙に出力して保管するだけの運用は、電子取引の記録としては足りません。保存にあたっては、訂正や削除に備えた手当てと、取引年月日・取引金額・取引先の3項目で検索できる状態が要ります2。この要件が固まったのは2024年からの運用であり、データ形式や連携の仕組みを選ぶ段階から条件に含めておく必要があります。
考え方の軸は、やり取りの手段が電子であれば記録も電子で残す、という点にあります。受発注のシステムを通した注文書、メールに添付した請求書、取引先の画面から取得した明細が対象に入ります2。標準データ形式で交わしたメッセージも、取引の記録である以上は同じ扱いです4。どこに残すかは選べても、要件を満たす形にする責任は自社に残ります。
対象になるのは、注文書や請求書だけではありません。見積書、納品書、支払通知、契約に関する書面のうち、電子でやり取りしたものが含まれます*2。連携の仕組みの中に一時的に置いただけでは、保存したことになりません。どの書類がどこに残るかを、取引の流れに沿って一覧にしておきます。
検索の要件は、担当者以外でも取り出せる状態を求めるものです。取引年月日・取引金額・取引先の3項目で絞り込めることが基本になります*2。ファイル名に情報を持たせる方法も、一覧表と組み合わせる方法も取り得ますが、運用が続くかどうかが分かれ目でしょう。件数が増えるほど、手作業の索引は破綻します。
訂正や削除への手当ても要ります。履歴が残る仕組みを使う方法と、事務処理の規程を定めて運用で担保する方法があります*2。標準に沿って受け取ったデータをそのまま保存できれば、後から加工する場面自体を減らせます。保存の要件は、受発注の仕組みの選び方にそのまま跳ね返ります。
仕組みを選ぶときは、保存側の確認項目を持って臨みます。検索の3項目に対応しているか、履歴が残るか、保存期間を設定できるか、外部へ書き出せるかを見ます2。請求のデータを標準仕様でやり取りする場合は、受け取った電子インボイスをそのまま保存できるかも確認します1。受発注と会計、どちらの担当も選定の場に加わるのが望ましい形です。
保存の要件は、受発注の電子化と切り離せません。形式の選定、通信の切り替え、保存の設計を別々の担当が別々の時期に決めると、後から辻褄合わせの作業が生まれます。三つを一つの計画として引き、要件の抜けを潰す進め方が、結局は費用を抑えます。社内で見切れない部分は、早い段階で外部の知見を入れるほうが安全でしょう。

よくある質問
標準データ形式を採用すれば、取引先ごとの個別対応はなくなりますか。
完全にはなくなりません。標準は項目の名前や意味を共通化しますが、自社の商品コードや得意先コードとの対応付けは自社側に残ります。任意項目の使い方も取引先ごとに違いが出るため、書面での確認が要ります。個別対応の量を減らす仕組みだと捉えるのが実情に近いでしょう。
取引先が小規模で電子化に対応できない場合、どうすればよいですか。
相手の負担が軽い形式から検討します。中小企業の受発注に向けた標準は業種を限定せず、見積から請求までの項目を共通の定義でそろえており、2026年時点でも更新が続いています*7。相手に専用の設備を求めない接続手段を選び、当面はFAXやメールと併存させる運用も現実的です。
移行にはどのくらいの期間を見ておけばよいですか。
取引先の数と基幹システムの改修範囲で変わるため、一律には決められません。日程の起点になるのは、従来の接続方式について新規申込の受付終了日とサービス提供終了日が2024年に公表されている点です*8。並行稼働は月次でしか現れない例外を拾える長さを確保し、そこから逆算して計画を引きます。
電子で受け取った注文データは、印刷して保管してもよいですか。
電子取引でやり取りしたデータは、電子のまま保存する扱いが2024年から求められています*2。印刷した紙を併せて保管することは妨げませんが、それだけでは要件を満たしません。取引年月日・取引金額・取引先の3項目で検索できる状態を、稼働の前に用意してください。
請求や支払まで電子にすると、何が変わりますか。
入金消込の材料がデータで届くようになります。振込にEDI情報を添える仕組みでは、固定長の電文で20桁だった情報欄をXML電文に置き換え、支払の明細を振込と一緒に送れます*5*6。請求側もデジタルインボイスの標準仕様で受け渡せば、会計システムへの再入力を省けます*1。
- *1 出典:デジタル庁「JP PINT(日本におけるデジタルインボイスの標準仕様)」(2026) 経路
- *2 出典:国税庁「電子取引に係るデータの保存方法等に関するサイト(電子帳簿保存法関係)」(2026年時点で掲載を確認) 経路
- *3 出典:GS1 Japan(一般財団法人流通システム開発センター)「流通BMS(EDI・標準化活動)」(2018) 経路
- *4 出典:流通システム標準普及推進協議会「流通BMS標準仕様」(2018) 経路
- *5 出典:一般社団法人全国銀行協会「ZEDI(全銀EDIシステム)」(2025) 経路
- *6 出典:一般社団法人全国銀行資金決済ネットワーク「全銀EDIシステムとは」(公表年の記載なし) 経路
- *7 出典:特定非営利活動法人ITコーディネータ協会「中小企業共通EDIとは(中小企業共通EDI標準)」(2026) 経路
- *8 出典:東日本電信電話株式会社「INSネットの新規申込受付終了日とサービス提供終了日について」(2024) 経路
画像の出典元
- Close-up of hand holding a house key with a wallet and coins/Photo by Jakub Zerdzicki on Pexels
- Miniature shopping carts in bright colors with dollar bills/Photo by Sora Shimazaki on Pexels
- A luminous blue tunnel with digital numbers creating a futur/Photo by Oktay Köseoğlu on Pexels