EDIとは?企業間の受発注をどう楽にするのか ── FAX・メール・手入力からデータ連携へ
· 小村 豪 · EDI, 企業間取引, 受発注, 業務効率化, システム連携, BtoB, DX
「取引先からFAXで注文書が届き、担当者が販売管理システムへ入力する」
「メールに添付されたExcelを開き、商品コードと数量を確認して転記する」
「納品後、請求書を作成し、相手先でもその内容を会計システムへ入力する」
企業間の取引では、同じ注文情報や請求情報を、複数の会社・複数の担当者が何度も入力していることがあります。
この重複入力を減らし、発注、受注、出荷、請求などのデータを企業間で直接やり取りする仕組みが、EDIです。
EDIというと、大企業が専用回線を使って導入する大がかりなシステムを想像するかもしれません。しかし、本質はもっと単純です。
EDIとは、取引先から届いた情報を人が読み直して入力するのではなく、コンピューターでそのまま処理できるデータとして交換する仕組みです。
この記事では、EDIとは何か、FAXやメールと何が違うのか、導入すると企業業務がどのように楽になるのかを、受発注業務を例に整理します。
1.まず結論
EDIは、Electronic Data Interchangeの略で、日本語では「電子データ交換」と呼ばれます。
企業同士が、注文書、出荷通知、請求書などの取引情報を、あらかじめ決めた形式の電子データとして交換する仕組みです。
JIPDECでは、EDIを、企業や行政機関などがコンピューターをネットワークで接続し、伝票や文書を電子データとして自動的に交換することと説明しています。
EDIを導入する目的は、単に紙をなくすことではありません。
主な目的は、次のような作業を減らすことです。
- FAXやPDFを見ながら行う手入力
- Excelから販売管理システムへの転記
- 入力内容の目視確認
- 注文書や請求書を探す作業
- 注文状況を確認する電話やメール
- 売上、在庫、請求データの再集計
一言で表すと、EDIは、会社と会社の間で止まっていたデータを、そのまま流れるようにする仕組みです。
2.EDIがない受発注業務では、何が起きているのか
まず、EDIを使っていない受発注業務を考えてみます。
発注側の会社では、購買担当者が自社のシステムやExcelで注文内容を作成します。その内容を注文書として印刷し、FAXやメールで取引先へ送ります。
受注側では、届いた注文書を担当者が確認し、自社の販売管理システムへ入力します。
その後、受注確認書、出荷通知、納品書、請求書などを作成し、発注側へ送り返します。発注側でも、それらの情報を在庫管理システムや会計システムへ入力します。
発注側で注文データを入力
↓
注文書を印刷・PDF化
↓
FAXまたはメールで送信
↓
受注側が内容を確認
↓
受注側のシステムへ再入力
↓
出荷・請求データを作成
↓
発注側が再び自社システムへ入力
この流れでは、同じ情報が何度も入力されます。
例えば、商品コード、商品名、数量、単価、納期、納品先などです。
最初の注文データはすでに発注側のコンピューターに入っています。それにもかかわらず、紙やPDFに変換されたことで、受注側では再び人が読み取り、コンピューターへ入力し直しています。
問題は、情報が電子化されていないことではありません。
一度データとして作られた情報が、人が読む文書へ変換され、相手側で再びデータに戻されていることです。
3.EDIを使うと、受発注はどう変わるのか
EDIを使うと、発注側のシステムで作成された注文データが、受注側のシステムで読み取れる形式に変換され、そのまま送信されます。
受注側では、担当者が注文書を見ながら入力するのではなく、受信したデータを販売管理システムへ取り込みます。
flowchart LR
A[発注側の購買システム] --> B[注文データ]
B --> C[EDIによる送信・変換]
C --> D[受注側の販売管理システム]
D --> E[受注確認]
D --> F[出荷通知]
D --> G[請求データ]
E --> C
F --> C
G --> C
C --> A
発注側から受注側へ注文データを送り、受注側から発注側へ受注確認、出荷、請求などのデータを返します。
人が文書を見ながら転記する工程を挟まず、システムからシステムへデータを渡すのがポイントです。
JIPDECでは、各企業が持つ固有形式のデータを標準形式へ変換し、受信側でも標準形式から自社形式へ変換する仕組みをEDIとして説明しています。
4.EDIとメール・PDF・Excelは何が違うのか
「注文書をPDFにしてメールで送っているので、すでに電子化できている」と考えることがあります。
確かに、紙を郵送するよりは速く、保管もしやすくなります。しかし、受け取った側がPDFを見ながらシステムへ入力しているなら、入力作業そのものは残っています。
違いを整理すると、次のようになります。
| 方法 | 相手への送信 | 相手側の処理 | 再入力 |
|---|---|---|---|
| 紙・郵送 | 紙を送る | 書類を見て入力 | 必要 |
| FAX | 画像として送る | FAXを見て入力 | 必要 |
| PDFをメール送付 | 電子文書として送る | PDFを見て入力 | 必要 |
| Excelをメール送付 | ファイルを送る | 内容確認、加工、取り込み | 方法による |
| EDI | 決められたデータ形式で送る | システムが直接取り込む | 原則として不要 |
JIPDECの説明では、伝票をスキャンした画像や、通常の文章として書かれたメールは、コンピューターで再処理できるEDIデータとは区別されています。また、Web画面へ人が手入力する方式も、厳密にはコンピューター間の自動交換とは異なります。
ただし、PDFやExcelを使うこと自体が悪いわけではありません。
重要なのは、受け取った情報がその後どのように処理されるかです。
- PDFを人が見て入力する
- Excelを開いてコピーする
- CSVをシステムへ直接取り込む
- APIで自動的に登録する
同じ「電子ファイル」でも、後工程の負担は大きく異なります。
EDIの効果を判断するときは、送信方法だけでなく、受信後に人が何をしているかを見る必要があります。
5.EDIで交換できる情報
EDIは、注文書だけの仕組みではありません。
企業間取引で発生する、さまざまな情報を交換できます。
| 業務の段階 | 交換するデータの例 |
|---|---|
| 見積もり | 見積依頼、見積回答 |
| 発注 | 注文、注文変更、注文取消 |
| 受注 | 受注確認、納期回答 |
| 出荷 | 出荷予定、出荷実績、送り状番号 |
| 入荷・検収 | 入荷実績、検収結果 |
| 請求 | 請求明細、請求訂正 |
| 支払い | 支払通知、振込明細 |
例えば、発注データを受け取った時点で、受注側のシステムが次の処理を行うこともできます。
- 注文番号の重複を確認する
- 商品コードが存在するか確認する
- 在庫を引き当てる
- 納期を計算する
- 倉庫へ出荷指示を送る
- 発注側へ受注確認を返す
さらに出荷後は、出荷実績から売上を計上し、請求データを作成できます。
つまりEDIは、単なる通信機能ではありません。
受発注を入口として、その後の在庫、出荷、売上、請求までをつなぐための土台になります。
6.EDIは企業業務をどう楽にするのか
6.1.手入力と転記を減らせる
最も分かりやすい効果は、手入力の削減です。
FAXで届いた注文書を見ながら、商品コード、数量、単価、納期を入力する作業が不要になります。
手入力を減らせば、担当者は入力そのものではなく、次のような例外対応に時間を使えます。
- 在庫が不足している注文
- 通常とは異なる納期の注文
- 商品コードが登録されていない注文
- 大口注文
- 単価や契約条件の確認が必要な注文
すべての注文を人が処理するのではなく、通常の注文は自動処理し、問題のある注文だけを人が確認する形へ変えられます。
6.2.入力ミスを減らせる
人が入力する作業には、一定の確率で間違いが発生します。
- 商品コードを一桁間違える
- 数量を10個ではなく100個と入力する
- 納品先を取り違える
- 希望納期を読み間違える
- 同じ注文を二重に登録する
EDIでも、元のデータ自体が間違っていれば問題は起きます。しかし、正しく作られたデータを相手側で再入力する必要がないため、転記時に発生するミスを減らせます。
中小企業庁も、受発注のデジタル化による効果として、作業効率の向上、人的ミスの軽減、取引記録の検索性向上を挙げています。
6.3.受注処理を早くできる
FAXやメールでは、担当者が受信に気づき、内容を確認し、入力を終えるまで、受注処理が始まりません。
注文が多い日には入力待ちが発生します。担当者が休んでいれば、処理が遅れることもあります。
EDIでは、受信したデータを自動的にシステムへ取り込めます。
注文を受け取った直後に、
- 注文の受付
- 在庫確認
- 納期計算
- 倉庫への出荷指示
- 受注確認の返信
といった処理を開始できます。
受注処理が早くなれば、出荷までの時間も短縮しやすくなります。JIPDECも、EDIの効果として事務作業の迅速化、リードタイム短縮、在庫圧縮などを挙げています。
6.4.注文状況を確認しやすくなる
紙、FAX、メール、Excelが混在していると、「その注文が現在どうなっているか」を調べるのに時間がかかります。
担当者のメールボックス、共有フォルダー、紙のファイル、販売管理システムなどを順番に確認することになります。
EDIでは、注文番号などを基準に、次の情報を関連付けて管理できます。
- いつ注文を受け取ったか
- 正常に取り込まれたか
- 受注確認を返したか
- 出荷済みか
- 検収されたか
- 請求済みか
- エラーや再送が発生したか
問い合わせを受けたときも、担当者の記憶や個人メールに頼らず、処理履歴から確認できます。
6.5.在庫・出荷・会計業務につなげられる
EDIの効果は、受注担当者の入力作業を減らすだけではありません。
受け取ったデータを社内システムと連携することで、後工程も自動化できます。
注文データ
↓
受注登録
↓
在庫引当
↓
出荷指示
↓
売上計上
↓
請求データ作成
↓
入金消込
逆に、EDIで注文データを受信しても、それを印刷し、人が販売管理システムへ入力しているなら、効果は限定的です。
JIPDECも、EDIで受け取ったデータを社内システムへ取り込まず、印刷して人手で処理すれば、FAXと大きく変わらないと説明しています。
EDIは、取引先との通信だけを導入するのではなく、受け取ったデータを社内業務のどこまで流すかが重要です。
6.6.取引データを経営判断に使える
紙やPDFで受け取った注文書は、保存されていても集計には使いにくいものです。
EDIでは、取引情報が構造化されたデータとして蓄積されます。
そのため、次のような分析へつなげられます。
- 商品別の受注量
- 取引先別の売上推移
- 曜日別・時間帯別の注文傾向
- 納期遅延の発生状況
- 欠品が多い商品
- 注文から出荷までの所要時間
- 返品や訂正が多い取引
JIPDECも、EDIデータを在庫引当、生産手配、入出荷検品、売掛計上などの日常業務に加え、売れ筋分析、需要予測などへ活用できるとしています。
EDIによってデータを集められる状態を作ることは、業務効率化だけでなく、将来の在庫最適化や需要予測の前提にもなります。
7.単純な例で考えるEDIの効果
例えば、ある卸売会社が、1日に100件の注文をFAXやメールで受け取っているとします。
1件の注文を販売管理システムへ入力し、内容を確認するのに平均3分かかるとします。
100件 × 3分 = 300分
1日あたり5時間を、注文入力と確認に使っている計算です。
EDI導入後、80件を自動的に取り込み、残り20件だけを人が確認する形になったとします。
20件 × 3分 = 60分
単純化した例ですが、入力作業は5時間から1時間になります。
実際には、これに加えて次の時間も減る可能性があります。
- 読みにくいFAXの確認
- 入力間違いの訂正
- 注文内容を確認する電話
- 注文書を探す作業
- 注文一覧の集計
- 担当者間の引き継ぎ
EDI導入の効果は、「紙代が減る」といった直接的なコストだけではありません。
毎日繰り返される小さな確認・入力・訂正を減らせることに大きな意味があります。
8.部門ごとに見るEDIのメリット
EDIによる業務改善は、受注部門だけに限定されません。
| 部門 | EDI導入前の作業 | EDI導入後に期待できる変化 |
|---|---|---|
| 営業・受注 | 注文内容を見て入力する | 通常注文は自動登録し、例外だけ確認する |
| 購買 | 発注書を作成して送付する | 購買システムから直接送信する |
| 倉庫 | 紙の出荷指示を受け取る | 受注データから出荷指示を作成する |
| 経理 | 請求明細を再入力する | 売上データから請求情報を作成する |
| 管理者 | Excelで実績を集計する | 蓄積された取引データから集計する |
| 問い合わせ窓口 | メールや紙を探す | 注文番号から処理状況を確認する |
EDIによって減らせるのは、単なる入力工数だけではありません。
情報の所在が明確になり、担当者以外でも状況を確認しやすくなるため、業務の属人化も軽減できます。
9.EDIを導入すれば、すべて自動化できるわけではない
EDIは便利な仕組みですが、導入するだけですべての作業が自動化されるわけではありません。
9.1.取引先との取り決めが必要
企業間でデータを交換するには、少なくとも次の事項を決める必要があります。
- どの情報を交換するか
- どのデータ形式を使うか
- いつ送受信するか
- 注文変更や取消をどう扱うか
- エラーが発生した場合にどうするか
- 同じデータを再送した場合にどう扱うか
- どの時点で正式な注文として成立するか
EDIでは、通信方法だけでなく、データ項目や業務運用のルールも重要です。JIPDECも、通信プロトコル、データ形式、メッセージ項目、エラー時の対応、取引基本規約などの取り決めが必要だと整理しています。
9.2.商品コードなどをそろえる必要がある
発注側と受注側で、同じ商品に異なるコードを使っていることがあります。
例えば、発注側では商品コードがA-001、受注側では100245となっているケースです。
この場合は、コードを変換するための対応表が必要です。
商品コード以外にも、次のような項目を整理します。
- 取引先コード
- 納品先コード
- 単位
- 入数
- 税区分
- 通貨
- 日付形式
- 文字コード
データを送受信できても、項目の意味が一致していなければ、正しい取引にはなりません。
9.3.例外処理は残る
通常の注文を自動処理できても、例外的な取引は残ります。
- 在庫不足
- 廃番商品
- 通常と異なる価格
- 緊急注文
- 注文変更
- 注文取消
- 分納
- 返品
- データ不備
重要なのは、すべてを無理に自動化することではありません。
通常処理と例外処理を分け、通常処理は自動化し、判断が必要なものだけを人へ回す設計が現実的です。
9.4.FAXやメールとの併用期間が発生する
すべての取引先が同時にEDIへ移行できるとは限りません。
そのため、導入初期には次のような複数の受付方法が並行することがあります。
- EDI
- Web画面
- CSVアップロード
- メール
- FAX
- 電話
この状態では、EDIを導入しても従来業務の担当者をすぐには減らせません。
EDIの効果を高めるには、取引量の多い取引先から順番に移行し、手作業で扱う件数を減らしていく必要があります。JIPDECも、FAXや電話などの人手処理が残ると、その対応要員が必要になり、効率化の効果を十分に得にくいと指摘しています。
10.EDIが向いている企業
EDIは、特に次のような企業で効果が出やすい仕組みです。
- 毎日または毎週、同じ取引先と受発注している
- 注文件数や明細数が多い
- FAXやメールからシステムへ転記している
- 入力間違いや二重登録が発生している
- 注文確認の電話やメールが多い
- 受注後に在庫、出荷、請求の処理が続く
- 担当者が休むと処理が滞る
- 注文履歴や取引状況の集計に時間がかかる
一方、年に数回しか取引がない相手や、注文内容が毎回大きく異なる取引では、EDIの構築・運用コストが効果を上回ることもあります。
EDIを導入するかどうかは、会社の規模だけで判断するものではありません。
中小企業庁も、中小企業向けに受発注業務を標準化する「中小企業共通EDI」を整備しており、専門端末や紙を減らし、伝票をデータとして一元管理することによる業務効率化を示しています。
見るべきなのは、従業員数ではなく、繰り返し発生している入力・確認・転記の量です。
11.EDI導入を検討するときの進め方
EDIを検討するとき、最初から製品や通信方式を選ぶ必要はありません。
まず、現在の業務を整理します。
11.1.現在の受発注方法を一覧にする
取引先ごとに、次の情報を整理します。
| 確認項目 | 内容 |
|---|---|
| 取引先 | どの会社と取引しているか |
| 注文件数 | 1日・1か月に何件あるか |
| 受注方法 | FAX、メール、Web、CSVなど |
| 入力先 | 販売管理、Excel、基幹システムなど |
| 入力時間 | 1件あたり何分かかるか |
| 間違い | どのような訂正が発生しているか |
| 後工程 | 在庫、出荷、請求へどうつないでいるか |
| 例外 | どのような注文で人の判断が必要か |
この整理をすると、EDI化による効果が大きい取引先や業務が見えてきます。
11.2.取引量の多い一社から始める
最初からすべての取引先を対象にすると、調整項目が増え、導入が長期化します。
まずは、次の条件に当てはまる取引先を一社選ぶのが現実的です。
- 取引件数が多い
- 定型的な注文が多い
- 担当者同士の連絡が取りやすい
- システム連携への理解がある
- 効果を測定しやすい
一社で運用方法を確立したあと、他の取引先へ広げます。
11.3.交換対象を絞る
最初から見積もり、受注、出荷、検収、請求、支払いのすべてを対象にする必要はありません。
例えば、最も入力負担の大きい注文データだけを先にEDI化する方法があります。
第1段階:注文データ
第2段階:受注確認・納期回答
第3段階:出荷通知
第4段階:請求データ
段階的に対象を増やすことで、現場への影響を抑えながら効果を確認できます。
11.4.社内システムへの接続を確認する
EDIサービスを導入しても、既存の販売管理システムへデータを取り込めなければ、手入力が残ります。
事前に次の点を確認します。
- CSVの入出力機能があるか
- APIを利用できるか
- データベースとの連携が可能か
- 商品コード変換をどこで行うか
- 受信データの重複をどう防ぐか
- エラーを誰に通知するか
- 処理履歴をどこに残すか
製品選定より先に、既存システムとの接続方法を確認することが重要です。
12.EDI導入後に測りたい指標
EDIを導入したら、「使えるようになった」で終わらせず、業務がどれだけ変わったかを確認します。
例えば、次の指標を導入前後で比較します。
- 受注入力にかかる時間
- 1件の注文を処理するまでの時間
- 入力訂正の件数
- 二重登録の件数
- 注文確認の問い合わせ件数
- 出荷遅延の件数
- EDIで処理できた注文の割合
- 人が確認した例外注文の割合
EDIで大切なのは、データを送信できることではありません。
手作業が実際に減り、処理が速くなり、間違いが減ったかで評価します。
まとめ
EDIとは、企業間で発生する注文、出荷、請求などの情報を、コンピューターでそのまま処理できる電子データとして交換する仕組みです。
FAXをメールへ変更するだけでは、紙は減っても手入力が残ることがあります。
EDIの本当の効果は、取引先から受け取ったデータを、販売管理、在庫、出荷、会計などの社内システムへ直接つなげられることにあります。
EDIによって期待できる主な変化は、次のとおりです。
- 注文書を見ながら行う手入力を減らす
- 転記による入力ミスを減らす
- 受注から出荷までの処理を早くする
- 注文や請求の処理状況を確認しやすくする
- 在庫、出荷、売上、請求を連携する
- 蓄積した取引データを集計や需要予測に使う
- 担当者個人に依存した業務を減らす
ただし、EDIサービスを契約するだけでは十分ではありません。
商品コードなどのデータを整理し、取引先と運用ルールを決め、既存の社内システムへデータを取り込めるようにする必要があります。
EDI導入の出発点は、「どの製品を使うか」ではなく、現在の業務で同じ情報を何回入力しているかを調べることです。
FAX、メール、Excel、Web画面、販売管理システムの間で人が情報を運んでいる箇所を見つけ、その中から件数が多く、定型的な業務を順番にデータ連携へ置き換えていくのが現実的です。
受発注業務のデータ連携をご検討の方へ
企業間の受発注を効率化したいものの、現在のFAX・メール・Excel運用をどこから見直せばよいか分からない場合は、まず業務の流れを整理する必要があります。
取引先からどの形式で情報を受け取り、社内のどのシステムへ入力し、その後の在庫・出荷・請求へどうつないでいるかを確認すると、自動化できる範囲が見えてきます。
合同会社小村ソフトでは、既存のWindows業務アプリ、CSV・固定長ファイル、データベース、Webシステムなどを含む業務連携について、現状整理や実現方法の検討をご相談いただけます。
全面刷新を前提にせず、現在の仕組みを残しながら手入力部分だけを減らす構成も検討できます。
関連する記事
同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。
デジタルインボイスとは? ── 「請求書のPDFをメールで送る」と何が違うのか
デジタルインボイスとは、請求情報を売り手のシステムから買い手のシステムへ、人を介さず直接データ連携する仕組みです。PDF請求書との違い、インボイス制度との関係、Peppol・JP PINTの仕組み、電子帳簿保存法との関係、中小企業の始め方を分かりやすく解説します。
FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務
FAX受注をWeb受注やCSV取込へ移行する実務を解説します。いきなりの全面Web化が失敗しやすい理由、FAXとWebの二重運用期間の設計、商品・取引先マスタの整備、CSV取込という中間形態、取引先の巻き込み方を段階移行の手順として整理します。
PowerShell実用コマンド集 ── 日常作業でよく使う小さな機能を増やす
PowerShellで日常作業に使う実用コマンドとして、Measure-Object、Group-Object、Select-String、Compare-Object、Tee-Object、Start-Transcriptなどの使いどころを整理します。
Windowsアプリのタスクトレイ常駐とトースト通知 ── NotifyIconの落とし穴とAppNotificationの選び方
業務Windowsアプリをタスクトレイに常駐させ、トースト通知でユーザーへ知らせる実装を整理します。NotifyIconの正しい使い方と「閉じるでトレイへ」の設計、Explorer再起動時の再登録、トーストAPI3種(Windows App SDK AppNotificat...
WordPressからMovable Typeへの移行 ── 「逆方向」だからこそ整理しておきたい実務手順
WordPressからMovable Type(MovableType.net)への移行手順を実務目線で解説します。移行が合理的になるケース、記事・固定ページ・画像のインポート、カスタム投稿タイプの扱い、URL設計と301リダイレクトによるSEO引き継ぎ、プラグイン機能の代...
関連トピック
このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。
Windows技術トピック
Windows 開発、不具合調査、既存資産活用の技術トピックをまとめた入口です。
このテーマがつながるサービス
この記事は次のサービスページにつながります。近い入口からご覧ください。
Windowsアプリ開発
既存のWindows業務アプリとCSV・固定長ファイル・データベース・Webシステムをつなぐ構成の検討や実装は、業務アプリ開発の相談範囲だからです。
既存Windowsソフトの改修・保守
全面刷新を前提にせず、既存システムを残しながら手入力や転記を段階的に減らす改修は、既存Windowsソフトの改修・保守に該当するためです。
技術相談・設計レビュー
取引先とのデータ形式・運用ルール・例外処理を整理し、どこまで自動化するかを決める作業は、設計レビューを伴う技術相談だからです。
著者プロフィール
記事の著者プロフィールページです。
小村 豪
合同会社小村ソフト 代表
Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。
公開リンク