受発注業務を効率化する方法｜ワークフローと基幹システム連携

注文はWebフォームで受けられるようになったのに、その内容を営業事務が基幹システムへ手入力している。受発注業務の効率化に着手したBtoB企業から、よく聞く話です。

前の工程だけをデジタル化すると、転記作業が最後の1か所に凝縮されます。件数が減るわけではないため、現場の負荷は変わりません。原因は、ワークフローの作り込み不足ではなく、基幹システムとの接続点が設計されていないことにあります。

この記事では、受発注ワークフローと基幹システムの役割分担、連携方式4つの比較、着手前に決めるマスタ設計、稼働までの4ステップを扱います。

読み終えたときに、情報システム部門や保守ベンダーへ投げる質問が固まっている状態を目指します。

受発注業務の効率化が止まるのは、最後の転記工程

受発注業務の効率化は、注文の受け方を変えただけでは完了しません。受け取ったデータが基幹システムへ流れるまで設計して、初めて工数が落ちます。

Webフォームで置き換えやすいのは、見積依頼の受付と注文の受領までです。その先、基幹システム（＝販売管理や在庫を扱う社内の中核システム。ERPとも）への受注登録が手作業だと、次のことが起こります。

• FAXの読み取りが、画面のコピー＆ペーストに変わっただけになる
• 受注データの正が2か所に分かれ、どちらが最新か分からなくなる
• 締め直前に登録が集中し、繁忙期の残業が減らない

商取引の電子化自体は進んでいます。経済産業省の調査では、2024年の国内BtoB-ECのEC化率は43.1%と、前年から3.1ポイント上昇しました（令和6年度電子商取引に関する市場調査）。一方で中小企業庁は、電子受発注に対応する受注側企業を48.5%としています（中小企業の受発注デジタル化）。

窓口の電子化と、社内までデータを通し切ることは別の課題です。移行そのものは受発注業務のデジタル化｜FAX・電話からの脱却ステップで扱っています。

ワークフローと基幹システムの役割分担

先に決めるべきは連携方式ではありません。どちらのシステムが何の「正」を持つかです。

曖昧なまま接続すると、同じ項目を両側で更新でき、数字が合わなくなります。窓口と社内承認はワークフロー側、マスタと確定実績は基幹側が原則です。

ワークフロー側が担う「受付」と「承認」

ワークフロー（＝申請から承認、後続処理までを定型化した業務の流れ）が得意なのは、非定型な入力の構造化です。

FAXで届く注文書は、書式も項目名も取引先ごとに違います。申請フォームに置き換えれば、品番・数量・希望納期・届け先が同じ形で揃います。基幹へ渡せるのはこの時点です。

承認も同じ側です。特価の適用や与信枠を超える受注には、担当者の判断が要ります。tovira のワークフロー機能では、申請フォームと多段階の社内承認、外部APIによる連携アクションを組み合わせます。

基幹システム側に残す「マスタ」と「実績」

逆に、基幹から動かしてはいけないものもあります。

• 得意先マスタと単価マスタ：契約に基づく数字のため、営業が直接書き換えられる場所に置かない
• 在庫数：出荷・入庫・棚卸と連動するため、ポータル側で持つとずれる
• 受注番号：採番を二重化すると、後続の請求処理から取引をたどれない

ポータル側は参照に留めます。表示は最新に近づけたいが、更新はしない。全体像は見積・受発注をワークフロー化する方法で扱っています。

連携方式は4つ｜手動CSV・ファイル連携・API・EDIを比較する

役割分担が決まったら方式を選びます。4方式が「どの速さで、どんな場面に向くか」を横並びにしました。

初期費用は、方式よりも「基幹システム側に受け口があるか」で決まります。標準機能で受けられれば中程度、アドオン開発が必要なら跳ね上がります。

方式は1つに絞らなくて構いません。受注はAPI、出荷実績の返しは夜間のファイル連携という併用も成り立ちます。

「API連携に対応しています」で判断しない

確認すべきは対応の有無ではなく中身です。要件確認の場で次の5点を聞いてください。

1. 連携できる項目はどこまでか。受注ヘッダのみか、明細行・納期・届け先まで含むか
2. 呼び出しの方向はどちらか。ポータルから基幹を呼ぶのか、基幹から取りに来るのか
3. 失敗時の再送の仕組みと、エラー通知の宛先はあるか
4. 開発は誰が担うのか。提供側の標準機能か、自社開発か、外部発注か
5. バージョンアップ時に、連携部分の改修費が発生するか

4つ目と5つ目は費用に直結します。連携開発が別見積になると、比較表の金額は判断材料になりません。

中小企業共通EDIという選択肢

中小企業庁は、ITに不慣れな企業でも低コストで受発注のIT化を進められる仕組みとして「中小企業共通EDI」を紹介しています（中小企業の受発注デジタル化）。

取引先からEDIを指定されていても、ポータルと競合しません。EDI対応先はEDI、それ以外はポータルの二本立てが実務的です。

連携要件を社内でまとめる段階の方へ。tovira では、カスタマーポータルの機能一覧と、受発注をポータルで受ける際の考え方をまとめた資料をご用意しています。資料をダウンロードする

連携前に決めるマスタ設計

連携がうまくいかない原因の多くは、通信技術ではなくデータの中身です。つなぐ前に、3つのマスタの方針を固めます。

得意先コードの突合：基幹は取引先を数字のコード、ポータルはログインIDで管理します。両者を紐づける対応表をどちらに持たせるかを決めます。1社から複数名がログインするなら、「ユーザー」と「取引先」を別階層で扱う設計が要ります。

商品コードの表記ゆれ：実データを開くと、同じ商品が「ABC-100」「ABC100」「abc-100」で登録されていることがあります。連携以前に、基幹側のマスタを整える作業が要ります。

単価をどちらが持つか：卸売業では取引先ごとに単価が異なります。基幹の単価マスタを正とし、ポータルは表示を切り替えるだけの構成が扱いやすい形です。詳細は卸売業のBtoB取引をデジタル化とユーザーロール機能で扱っています。

3つのうち最も時間を食うのは2つ目です。難易度は低いのに、判断できる人が社内に少ないためです。

設計から稼働までの4ステップ

進め方には順番があります。全項目を一度に双方向でつなごうとすると、テストが終わりません。

1. STEP1｜業務フローの棚卸し（営業事務＋情報システム／2〜4週間）どの取引先から、どの経路で月に何件来ているかを数えます。「8割が上位20社から」という偏りが見えれば対象を絞れます。
2. STEP2｜連携項目のマッピング表を作る（情報システム＋ベンダー／2〜3週間）両システムの項目名を1対1で並べ、桁数、必須か任意か、コード変換ルールまで書きます。この表が受入テストの仕様書です。
3. STEP3｜片方向・一部の取引先から始める（情報システム＋営業／4〜8週間）ポータルから基幹への一方向に限定し、対象も数社に絞ります。在庫や進捗を返すのは次の段階です。
4. STEP4｜並行稼働してから切り替える（営業事務／1〜2か月）従来の手入力と連携を並走させ、登録結果を突き合わせます。差分が出なくなってから手作業を止めます。

期間は目安です。基幹システムの改修が必要な場合や、マスタ整備が多い場合は、STEP2とSTEP3が延びます。

つまずきやすい5つのポイント

稼働から数か月後に表面化しやすい問題です。

1. 締め時間の設計が抜けている：ファイル連携では、何時までを当日扱いにするかを明示しないと、納期の問い合わせが増えます
2. エラー時の受け皿がない：失敗した注文を誰が復旧するかを決めないと、取引先からは注文が消えたように見えます
3. 取引先が使ってくれない：ポータルを用意してもFAXを受け続ければ、窓口が二重になります
4. マスタ更新の担当が決まっていない：新商品の追加や単価改定を、誰がいつ反映するかを運用ルールにします
5. 監査への説明ができない：電子で受け取った注文書や見積書は電子帳簿保存法の対象です。国税庁は保存に真実性と可視性の確保を求めています（電子帳簿保存法の概要）

5つ目は、情報システム部門だけで進めると抜け落ちます。

費用と体制

費用は「ポータルの利用料」と「連携部分の構築費」を分けて見積もります。前者は月額または年額で、機能とユーザー数によって決まるのが一般的です。後者は原則として一度きりの費用で、連携項目の数と基幹システム側の改修範囲に比例します。

体制で押さえるべき点は1つだけです。

基幹システムの仕様を答えられる人を、プロジェクトの最初から入れること。

ベンダー任せにすると、要件確認のたびに社内照会が発生し、その待ち時間が工期の大半を占めます。保守を別の会社に委託している場合は、そちらの見積も早めに取ってください。

よくある質問

基幹システムにAPIがない場合、連携はできませんか

ファイル連携という選択肢が残ります。所定のフォルダにCSVを出力し、基幹側の取り込み機能で読ませる方式です。即時性は落ちますが、締めが1日1回なら実用に耐えます。

EDIがあれば、受発注ポータルは不要ですか

取引先の構成によります。EDIは相手側にも対応環境が必要で、中小の取引先まで広げにくい面があります。EDI対応先はEDI、それ以外はポータルの併用が現実的です。

連携の開発期間はどのくらいですか

一方向で項目を絞れば数週間、双方向でマスタ連携まで含めると数か月が目安です。期間を左右するのは開発より、項目定義の合意とマスタ整備です。

受注データの正はどちらに置くべきですか

確定した受注は基幹システムを正とする構成が扱いやすい形です。ポータル側は申請中や承認待ちの状態を持ち、確定時点で基幹へ渡します。両方で更新できると突合作業が増えます。

まとめ｜連携は目的ではなく、転記をなくす手段

受発注業務の効率化は、注文の受け方を変える工程と、そのデータを基幹システムへ流す工程で成り立ちます。後者を設計せず前者だけ進めると、転記が1か所に集まるだけです。

要点を整理します。

• ワークフローは受付と承認、基幹システムはマスタと確定実績。正を持つ側を先に決める
• 連携方式は手動CSV・定期ファイル連携・API・EDIの4つ。組み合わせてよい
• 着手前に、得意先コード・商品コード・単価の3点の方針を固める
• 片方向・少数社から始め、並行稼働で差分を潰してから切り替える

次にやることは、月間の受注件数を経路別に数えることです。この数字がないと、どこから手を付けるかも判断できません。

tovira のカスタマーポータルは、申請フォームと承認フローの構築、外部APIによる連携アクションを1つの基盤で扱えます。自社の受発注フローを再現できるかは、実際の画面でご確認ください。デモを依頼する

出典

• 経済産業省『令和6年度電子商取引に関する市場調査の結果を取りまとめました』 meti.go.jp（参照：2026-07-26）
• 中小企業庁『中小企業の受発注デジタル化』 chusho.meti.go.jp（参照：2026-07-26）
• 国税庁『電子帳簿保存法の概要』 nta.go.jp（参照：2026-07-26）
• tovira『ワークフロー機能｜顧客からの申請・承認を一元管理』 tovira.jp（参照：2026-07-26）