--- title: "受発注システムを取引先に展開する方法｜ID設計と移行率の上げ方" url: "https://www.issoh.co.jp/column/details/17090/" published: 2026-08-28 updated: 2026-08-29 categories: ["DX"] publisher: "株式会社一創" --- # 受発注システムを取引先に展開する方法｜ID設計と移行率の上げ方 受発注システムを入れたあとに残る仕事は、製品の設定ではなく取引先への展開です。相手が画面を開いてくれなければFAXと電話の受付はそのまま残り、二重の運用と月額費用だけが増える一方です。この記事では、ID発行と権限の設計、取引先マスタの棚卸し、FAXとの併用を終わらせる手順、移行率の測り方、それでも移行しない相手への打ち手までを判断の順序で整理します。2026年1月に施行された取適法によって、取引先への求め方の線引きが変わった点にも触れます。製品そのものの選び方は[受発注システムの比較](https://www.issoh.co.jp/column/details/17083/)を、仕組みの定義と機能の全体像は[受発注システムとは](https://www.issoh.co.jp/column/details/15256/)を参照してください。 ## まとめ：取引先への展開で先に決める4つの判断 結論から示します。展開の成否は説得の巧拙ではなく、次の4点をいつ決めたかで大きく変わります。 - **誰にIDを配るか**：企業単位・拠点単位・担当者単位のどれを基準にするかで、担当交代のたびに発生する作業量と、こちら側に来る問い合わせの本数が変わります。 - **費用を誰が持つか**：取引先にアカウント費用や機器の購入を求める形は、取適法の禁止項目に近づきます。相手の持ち出しをゼロにする構成が交渉を短くします。 - **何を測るか**：移行率は取引先の社数ではなく受注件数の比率で見ます。社数で数えると、月に1、2件しか発注しない相手が達成率を押し下げ、打ち手を見誤ります。 - **どこで線を引くか**：全社の移行を目標に置きません。受注件数の8割を覆う社数まで進んだら、残りはこちら側の入力を自動化して閉じるほうが総コストは下がります。 ## 受発注システムを導入しても取引先が使わない状態が起きる3つの原因 展開が進まないとき、原因を「取引先のIT理解が足りない」に置くと打ち手が説明会の追加しか出てきません。実際に止まっている箇所は、業務時間との噛み合わせ、アカウントの持ち主、そして相手側に発生する持ち出しの3つに分かれます。 ### 案内は届いているのに使われない理由は発注する時間帯とのずれにある 発注は取引先の業務の終盤に出ます。日中は店頭や現場に人が出ていて、在庫を確認して発注量を決めるのは閉店後や夜間という業種が少なくありません。ここで自社側の締め時間が17時に設定されていると、相手は「間に合わないから電話で伝える」という判断を毎日繰り返すことになります。案内文を作り直しても、この時間差は動きません。 確認するのは3点です。相手が発注量を決める時刻はいつか、そのときに手元にある端末は何か、締め時間を後ろへ動かす余地が自社の出荷作業にあるか。スマートフォンから発注できない画面設計のまま、閉店後に発注する相手へ展開しても定着しません。アプリとして配る場合の脱落要因とスマホ画面の入力要件は[受発注管理システムのアプリとは？スマホ発注のUI要件とWeb版との使い分け](https://www.issoh.co.jp/column/details/17122/)にまとめています。 ### IDが担当者個人に紐づく設計では担当交代のたびに利用が止まる メールアドレスをそのままIDにする設計は、発行が楽な代わりに担当者の異動や退職で利用が途切れます。取引先の側には自社のような管理画面がなく、パスワードの再発行も自分では完結しません。結果として「ログインできないので今日は電話で」という連絡が自社の営業担当に入り、そのまま元の運用へ戻ります。 止まる箇所は技術ではなく運用の持ち主です。新しい担当者のIDを誰が発行し、退職者のIDを誰が止めるのか。取引先に管理者権限を渡して自社で発行させるのか、自社の営業窓口が申請を受けて発行するのか。この分担を展開前に決めていないと、発行依頼が営業へ流れ込み、対応の遅れがそのまま利用率の低下になります。 ### 取引先側に費用や機器の購入が発生する構成は断る理由が正当になる 取引先が負担する形の月額費用、専用端末やICカードリーダーの購入、EDI接続の初期費用。いずれも相手にとっては自社の売上に直結しない支出で、断る理由としては正当です。しかもこの負担は自社の稟議に載らないため、社内では「無料で使えるはず」という前提のまま話が進み、展開の現場で初めて表面化します。 取引先の持ち出しをゼロにできるかは、製品の料金体系で決まります。発注側のアカウント数で課金する体系なら相手の負担はありませんが、受注側・発注側の双方が契約する体系だと交渉が長引く構造です。無料で始められるツールを検討している場合の限界は[受発注システムを無料で始める前に](https://www.issoh.co.jp/column/details/15605/)で整理しています。次の章で見るとおり、この持ち出しをどう扱うかは商習慣の問題であると同時に、法律の線引きにも関わります。 ## 2026年1月施行の取適法が変えた取引先への利用要請の線引き 2026年1月1日、下請代金支払遅延等防止法の改正法が施行され、法律名が「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」（通称：取適法）へ変わりました。展開の実務に直接効いてくる変更が2つあり、片方は追い風、もう片方は歯止めとして働きます。 ### 発注内容の明示は相手の承諾なしで電磁的方法へ切り替えられる法改正 改正前は、発注書面を電子データで交付するには相手方の承諾が必要でした。改正後は、書面交付義務について中小受託事業者の承諾の有無にかかわらず、電子メールなどの電磁的方法によることが可能になっています（公正取引委員会 取適法リーフレットNo.01・令和7年8月）。つまり発注内容を紙で送るか電子で送るかの選択は、相手の同意に依存しなくなりました。 展開の設計としては、ここが起点になります。取引先が画面を使ってくれるかどうかとは切り離して、自社から出す発注データの電子化だけは先に進められるからです。明示する内容は給付の内容・代金の額・支払期日・支払方法で、システムの通知メールにこれらを含めた発注書を添付する運用でも義務は満たせます。ただし相手が開けない形式で送れば実質的に明示になりませんから、受け取り方は事前に確認してください。取引記録は2年間の保存が求められ、こちらも電磁的記録で構いません。 ### 購入や利用の強制と不当な経済上の利益の提供要請に触れる求め方 歯止めのほうは禁止項目です。取適法の禁止項目には「購入・利用強制（正当な理由がないのに、指定する物品や役務を強制して購入、利用させること）」と「不当な経済上の利益の提供要請（自己のために、中小受託事業者に金銭や役務等を不当に提供させること）」が並びます。取引先に有料アカウントの契約を求める、専用端末を買わせる、システム利用料を相手負担で徴収するといった形は、この2項目に近づきます。 実務上の線引きはこう考えてください。自社が費用を持ち、相手はブラウザだけで使える構成なら問題になりにくい一方、相手に支出を求めるほど正当な理由の説明責任が重くなります。「使わないなら取引量を減らす」といった伝え方は、取引条件と絡めた要請そのものになるため避けます。取引先が中小受託事業者に当たるかどうかは、次のとおり基準が広がった点にも注意が必要です。 ### 適用対象に従業員基準が加わり自社が委託事業者に入る場合がある 今回の改正では、従来の資本金基準に従業員基準が追加されました。製造委託・修理委託・特定運送委託と、プログラム作成や運送・保管・情報処理に関する委託では従業員300人超が委託事業者側、300人以下が中小受託事業者側です。それ以外の情報成果物作成委託・役務提供委託では100人超と100人以下で区切られます。資本金基準と従業員基準はいずれかに該当すれば適用対象となる建て付けです。 資本金1,000万円以下で従業員が400人という企業は、従来の基準では対象外でしたが、改正後は委託事業者の側に入ります。受発注システムの展開は発注側が主導する場面が多く、その相手は取適法が守る対象である可能性が上がりました。適用対象の判定を法務と共有してから展開の案内文を作ると、あとから表現を直す手間がなくなります。 | 区分 | 委託事業者側 | 中小受託事業者側 | | ------- | ----------------- | ------------------- | | 製造委託等 | 資本金3億円超／従業員300人超 | 資本金3億円以下／従業員300人以下 | | 役務提供委託等 | 資本金5千万円超／従業員100人超 | 資本金5千万円以下／従業員100人以下 | ## 展開の前に決める実務設計：ID発行の単位と権限と取引先マスタ 案内を出す前に固めるのが、IDの単位・権限・マスタの3点です。展開を始めてから変更すると、発行済みのアカウントを作り直すことになり、取引先へ二度手間を強いることになります。 ### ID発行の単位を企業・拠点・担当者のどこに置くかで運用が変わる IDの単位には3つの選択肢があります。企業単位の共有IDは発行が1回で済み、担当交代の影響を受けませんが、誰が発注したかを追えず、退職者が発注できる状態が残る設計です。拠点単位は多店舗の小売や複数工場を持つ製造業に噛み合い、納品先と発注元を一致させられます。担当者単位は操作の記録が個人まで残る代わりに、発行と停止の運用が継続的に発生します。 | 発行単位 | 向く取引先 | 運用上の負担 | | ----- | ------------ | ----------- | | 企業単位 | 発注担当が1人の小規模先 | 操作の記録を追えない | | 拠点単位 | 多店舗・複数工場の取引先 | 拠点の開閉に追随が必要 | | 担当者単位 | 承認者が別にいる大口先 | 発行と停止が継続発生 | 迷う場合は、取引先ごとに単位を変えられる製品かどうかで判断してください。上位の大口先だけ担当者単位、残りは企業単位という混在運用ができれば、統制と手離れを両立できます。 ### 権限は発注と承認と単価参照の3つに分けて取引先の社内統制を残す 取引先の側にも決裁の仕組みがあります。現場が数量を入力し、店長や購買責任者が承認してから発注が確定するという流れを、システム上で再現できないと、相手は結局その部分を紙やメールで回すことになります。承認を通さず即時に発注が飛ぶ設計は、一見すると手数が少ない代わりに、相手の社内統制を壊す形になりかねません。 分ける単位は、発注の入力・発注の承認・単価の参照の3つが実務的な線です。とくに単価の参照は扱いが分かれます。取引先の全担当者に単価が見えると困る場面があり、数量だけ入力させて金額は承認者にのみ表示する構成が求められることがあります。取引先別単価や商品コードの読み替えにマスタ設計が耐えるかどうかは、製品選定の段階で確認しておく評価軸です。 ### 取引先マスタの名寄せと取引先コードの棚卸しを展開前に済ませる 展開でつまずく地味な原因が、自社の取引先マスタの重複です。同じ会社が旧社名と現社名で二重に登録されている、支店ごとに別コードが振られていて請求先だけ本社という状態は、長く続けている取引ほど起きています。この状態でアカウントを発行すると、発注は支店コードで入り、請求は本社コードで出るという不整合が初回から発生します。 棚卸しの順序は、法人番号や住所での名寄せ、休眠先の除外、コードの統廃合、そして発注元と請求先と納品先の対応表の作成です。ここまでを終えてから展開の対象社数を数えると、想定より1割から2割少ない数字が出ることがあります。実在する取引の数を先に確定させるほうが、あとの移行率の分母が動かずに済みます。 ## FAXや電話との併用から受注件数ベースの移行率を上げる展開の順序と測り方 展開は一斉に切り替わりません。必ず併用の期間が生まれ、その期間をどう設計するかで最終的な移行率が決まります。ここで効くのが、測る指標の定義と、対象を並べる順序です。 ### 移行率は取引先の社数ではなく全受注件数に占める電子受注の比率で測る 移行率を「電子化した取引先数 ÷ 全取引先数」で測ると、数字が伸びません。年に数回しか発注しない相手が分母に大量に残るためで、達成率が3割で止まったまま、現場の負担は半分以下に減っているという食い違いが起きます。この数字を見た経営層が展開の失敗と判断し、途中で予算が止まるのが最悪の流れです。 指標は「電子で受けた受注件数 ÷ 全受注件数」に置き換えてください。分母を件数にすると、上位10社を移行させただけで比率が跳ね、投入した工数と効果の関係が見えるようになります。あわせて「FAXの受信枚数」と「電話での受注件数」を月次で並べると、併用がどこまで縮んだかが確認できます。 ### 取引量とIT対応力の2軸で取引先を4群に分けて展開順序を決める 対象を選ぶときは、月あたりの受注件数と、相手の情報システム対応力の2軸で並べます。件数が多くて対応力もある相手は最初の展開先で、ここが動くと件数ベースの移行率が一気に上がります。件数は多いが対応力が低い相手は、伴走の工数を集中させる群です。件数が少なく対応力がある相手は案内だけで移り、件数も対応力も低い相手は最後まで残ります。 | 群 | 特徴 | 打ち手 | | -------- | --------- | ------------ | | 件数多・対応力高 | 移行効果が最大 | 最初に着手しEDIも検討 | | 件数多・対応力低 | 工数はかかるが効く | 訪問して初回に伴走する | | 件数少・対応力高 | 案内だけで移る | メール案内と動画で完結 | | 件数少・対応力低 | 最後まで残る層 | 入力の自動化で吸収する | 件数が多く対応力も高い相手には、画面での発注ではなくシステム間の直接接続が向く場合があります。相手の基幹システムから発注データを送ってもらう方式で、日次の明細が数百行を超えるなら検討の対象です。接続の流れは[EDI取引とは](https://www.issoh.co.jp/column/details/16435/)で整理しています。製造業のように内示や納入指示が絡む取引では、[製造業向け受発注システムの選び方](https://www.issoh.co.jp/column/details/15596/)で扱う商習慣の制約が先に効いてきます。 ### 併用期間には群ごとの終了日を置きFAXが残り続ける状態を防ぐ 「当面はFAXでも受け付けます」という案内を出した瞬間に、移行率の上限が決まります。相手にとって慣れた方法が使えるなら、新しい画面を覚える動機が消えるからです。終了日のない併用は数か月後にそのまま固定され、電子とFAXの二重チェックという、導入前より手間の増えた運用が残ります。 置き方は、全社一律の停止日ではなく、群ごとの終了日にします。件数の多い群には移行完了から3か月後、少ない群には翌年度の期初、といった形です。停止の連絡は少なくとも2か月前に文書で出し、停止後もこちら側で入力を代行する受け皿を用意しておきます。代行の受け皿を持たずに停止だけ通知すると、受注そのものを失う可能性があります。 他社事例に出てくる移行率の数字は、取引先への説明とサポートに人を割いた結果です。事例の移行率をどう読み、自社の想定幅をどこに置くかは[受発注管理システムの導入事例の読み方｜効果指標の前提条件と自社での再現判定](https://www.issoh.co.jp/column/details/17117/)で整理しています。 ## 取引先への説明とサポート体制をどこまで自社で持つかの判断基準 展開の工数の大半は、製品の設定ではなく人への説明に消えます。どこまでを自社が持ち、どこからを製品ベンダーに任せるかを決めておかないと、営業担当が問い合わせ対応に時間を取られ、本来の商談が止まります。 ### マニュアルの配布より初回の実発注に伴走する支援が定着につながる PDFのマニュアルを送って読んでもらう方式は、送るまでの工数が小さい代わりに、読まれないまま終わります。実際に効くのは、相手が実際に発注する時間帯に電話をつなぎ、画面を見ながら1回だけ一緒に入力する伴走です。初回さえ通れば2回目からは自走する取引先が多く、逆に初回でつまずくと、その後に何度案内を出しても戻ってきません。 伴走する範囲は、件数の多い上位の群に絞ります。全社に伴走しようとすると工数が破綻するため、少件数の相手には操作の録画を3分程度に切って送り、質問だけ受ける形にします。 ### 問い合わせ窓口を営業担当に持たせるか専任部署に集約するかの判断基準 窓口の置き方は2つに分かれます。営業担当が受ける形は、相手との関係があるぶん連絡が来やすく、初期の展開では有利です。ただし問い合わせが増えると営業の稼働を圧迫し、担当ごとに回答が食い違います。専任窓口へ集約する形は、回答の統一と履歴の蓄積ができる代わりに、窓口を知らせる手間と、相手が電話しづらいという心理的な壁が生まれます。 分岐の基準は展開する社数です。おおむね50社を超えるなら専任窓口を置き、それ未満なら営業が受けて、よくある質問だけを社内で共有する形が現実的です。どちらの形でも、パスワード再発行とアカウント発行の依頼だけは手順を文書化しておいてください。この2つが問い合わせの大半を占め、対応の速さがそのまま利用率に効きます。 ## それでも移行しない取引先に残された打ち手と線引きに関する実務上の判断基準 ここまでの手を尽くしても、必ず一定数は残ります。残った相手をどう扱うかを決めておくことが、展開を終わらせるための最後の設計です。 ### 全取引先の完全移行を目標に置かず受注件数の8割を達成点にする 完全移行を目標に置くと、最後の1割の説得に展開全体の半分以上の工数が吸われます。年に数回しか発注しない先を口説くために営業が何度も訪問する状態は、削減した工数を自ら食い潰す形です。線を引く位置としては、受注件数の8割を電子で受けられる状態を達成点に置き、そこで説得の工数を止める判断をおすすめします。 残る2割は、説得の対象から運用でカバーする対象へ切り替えます。ここで初めて、自社側の入力をどう減らすかという問題に変わります。線を引いた時点で、展開プロジェクトとしては完了させ、以降は年1回の棚卸しで新規の取引先に案内を出す定常運用へ移してください。 ### FAXの受信をAI-OCRで取り込み自社側の入力だけを電子化する 相手が紙のままでも、自社側の入力は自動化できます。FAXを複合機で受けずにサーバーで受信して画像化し、OCRで発注番号・商品コード・数量を読み取って受注データへ流す構成です。読み取りの精度が完全ではないため、確信度が低い項目だけ人が確認する画面を挟むのが実務的な形になります。注文書の様式が取引先ごとに違う場合は、様式ごとに読み取り位置を定義するか、様式に依存しない項目抽出に対応した製品を選びます。 この方式は、相手に一切の変更を求めずに済むのが利点で、取適法の観点でも安全側です。読み取りの対象や電子帳簿保存法との関係は[AI-OCRで契約書をデータ化する判断基準](https://www.issoh.co.jp/column/details/16227/)で扱っています。電子取引で受け取ったデータは電子のまま保存する扱いになるため、紙のFAXとデータの取引が混在する期間は、保存の経路を分けて設計してください。 ### 標準機能で取引先の運用に合わせられない3要件で受託開発へ切り替える 展開が止まる原因が製品側にある場合もあります。締め時間を取引先ごとに変えられない、承認の階層が固定で相手の決裁に合わない、発注単位がケースと本数の両方に対応しないといった制約は、設定では動かせません。こうした要件が3つ以上重なり、いずれも取引の中核に関わるなら、パッケージの範囲で粘るより、自社の商習慣に合わせて作るほうが早く着地します。 全面的な作り直しに限らず、既存のパッケージを土台に、取引先向けの発注画面と連携部分だけを作る構成も選べます。提供形態ごとの違いは[Web受発注システムとは](https://www.issoh.co.jp/column/details/15601/)、費用の内訳は[受発注システム開発の費用相場](https://www.issoh.co.jp/column/details/15594/)で整理しました。取引先の運用に合わせた画面や連携を含めて相談したい場合は、[受発注システム開発](https://www.issoh.co.jp/service/business%5Fsystem/order-management/)で対応しています。現行の受注件数と取引先の分布を共有いただければ、どこまでを既製品で賄い、どこから作るかの線引きから一緒に検討できます。 ## よくある質問 ### 取引先に受発注システムの利用を義務づけてもよいですか？ 利用をお願いすること自体は問題ありませんが、取引の継続や取引量と結び付けた伝え方は避けてください。取適法の禁止項目には購入・利用強制と不当な経済上の利益の提供要請が含まれ、相手が中小受託事業者に当たる場合は該当する可能性があります。相手の持ち出しがゼロで、紙での発注も受け付ける経路を残したうえで案内するのが安全な形です。 ### 取引先のアカウント費用はどちらが負担するのが一般的ですか？ 展開を主導する側、多くの場合は発注側または受注側の導入企業が負担する形が一般的です。取引先に月額費用を求める構成は、交渉が長引くうえに法律上の説明責任も生じます。製品を選ぶ段階で、取引先アカウントが無償で発行できる料金体系かどうかを確認しておくと、展開の工数が大きく変わります。 ### 展開は何社くらいから始めるとよいですか？ 社数ではなく受注件数の上位から選び、まず5社から10社で試すのが進めやすい形です。上位数社だけで全受注件数の3割から4割を占める分布は珍しくなく、少数の移行でも効果が数字に出ます。 ### 取引先が既に別の受発注システムを使っている場合はどうしますか？ 相手のシステムから発注データを出してもらい、自社側で取り込む方式を検討します。相手にとっては既存の運用を変えずに済み、こちらは手入力を減らせるためです。 ### 移行率が上がらないとき、システムを入れ替えるべきですか？ 入れ替えの前に、止まっている原因が製品にあるのか運用にあるのかを切り分けてください。締め時間や承認階層のように設定で動かせない制約が原因なら製品の問題ですが、案内不足やID発行の遅れが原因なら、入れ替えても同じ状態が再現します。制約が取引の中核に3つ以上重なっている場合に限り、乗り換えや受託開発の検討に進むのが順序です。 ## 関連記事 - [受発注システムとは？機能・種類・選び方とパッケージか自社開発かの判断基準](https://www.issoh.co.jp/column/details/15256/)：仕組みの定義と機能の全体像、種類ごとの違いの整理です。 - [受発注システムの比較｜4タイプの選定軸と2028年の期限から逆算する判断](https://www.issoh.co.jp/column/details/17083/)：EDI型やWeb受発注型など、型を絞り込む比較の軸です。 - [Web受発注システムとは？ASP・クラウド型・パッケージ・自社開発の提供形態と選び方](https://www.issoh.co.jp/column/details/15601/)：提供形態ごとの費用と導入期間の違いです。 - [受発注システムを無料で始める前に｜フリーツールの限界とカスタム開発の判断基準](https://www.issoh.co.jp/column/details/15605/)：無料ツールで足りる範囲と超える条件です。 - [AI-OCRで契約書をデータ化する判断基準｜抽出できる項目と電帳法スキャナ保存の要件](https://www.issoh.co.jp/column/details/16227/)：紙で届く書類を読み取る際の要件です。 --- 出典: [受発注システムを取引先に展開する方法｜ID設計と移行率の上げ方]()（株式会社一創）