Web受発注システムの取引先別機能｜要件整理と選び方

◆監修・編集責任者　小園 将隆　2026年9月4日

B2B EC-COLUMN

Web受発注システムにおける取引先別機能とは

Web受発注システムの取引先別機能とは、取引先ごとに異なる価格・取扱商品・発注ルールを、システム上の設定として再現する仕組みです。判断の出発点は、自社の取引条件のうちどこまでを標準機能で吸収し、どこから個別開発に回すかという線引きです。設定粒度はグループ単位と個社単位の2層で考えると整理しやすくなります。電子取引データの保存や取引条件の明示といった制度要件も、機能選定の判断材料に含めておきたい項目でしょう。

取引先別機能が扱う範囲は、大きく7つの領域に分かれます。価格・掛率、商品表示、発注単位、取引条件、アカウント権限、納品先、承認フローです。このうち価格・掛率と商品表示は受注金額に直結するため、要件の詰め方が甘いと請求の訂正へ波及します。残る領域は運用の手数に影響し、設定を細かくするほど保守の手数が増えていきます。

電話・FAX・個別Excelでの運用は、価格の最新版がどれかを人の記憶に依存させます。取引先ごとの見積や掛率が担当者の手元ファイルに散り、受注センターは転記と確認に時間を割きます。受注のたびに単価を目で照合する手順が残るため、繁忙期には確認の抜けが起きやすい状態です。紙とメールが混在したままでは、日付・金額・取引先の3項目で電子取引データを検索できる状態にも届きません^*3。

企業間の電子商取引の規模は、国の市場調査で毎年公表されています¹。2025年8月に公表された令和6年度の調査では、2024年の国内BtoB-EC市場規模は514.4兆円、商取引全体に占めるEC化率は43.0%とされています1。中小企業のデジタル化とDXの動向についても、白書の中で節を設けて整理されており、2025年版では取組状況を段階1から段階4までの4段階に区分して分析されています^*4。受発注のWeb化は、この動向のうち取引先を巻き込む取り組みに当たります。取引先が使う画面と社内の受注処理の双方が変わるため、社内の合意だけでは進みません。

BtoB取引では、同じ商品でも取引先ごとに売価が変わります。得意先の規模や取引年数に応じた掛率、指定のロット、締日と支払サイトが個別に決まっている場面が実務では続きます。消費者向けのカートは単一価格と単一の決済を前提とするため、この差をそのまま持ち込めません。取引先別機能は、この前提の違いを埋めるための設定群だと言えます。

設定を誤った場合の影響は、注文1件では止まりません。価格グループの掛率を誤って登録すると、そのグループに属する取引先の受注全件へ誤った金額が適用されます。誤請求の訂正には、受注データの修正、請求書の再発行、取引先への説明が伴います。取引条件を明示する書面や電磁的記録の内容にも影響が及ぶため、確認手順の設計を後回しにできません^*2。

本節では取引先別機能の定義と、現行運用が抱える課題を扱いました。次節では、設定できる機能を領域ごとに並べ、粒度の選択肢と製品確認の観点を整理します。役割を分けることで、同じ論点を二度読む手間を省きます。

取引先別に設定できる機能の全体像

取引先別に設定できる機能は、価格・掛率、商品表示、発注単位という3つの軸を中心に、取引条件とアカウント権限を加えた5領域で捉えると比較しやすくなります。前節が課題の整理であるのに対し、本節は設定項目の並べ方を扱います。各領域には、全社共通・グループ単位・個社単位という粒度の選択肢があります。どの粒度で運用するかを先に決めておくと、製品比較で確認すべき点が絞れます。

3つの軸は、受注が成立する条件をそれぞれ別の側面から縛ります。価格・掛率は金額を、商品表示は買える対象を、発注単位は数量の刻みを決めます。3つのうち1つでも取引先の実態と合わないと、受注後に電話での修正が発生します。Web化の目的が受注業務の手数の削減であれば、この3軸の再現度が導入効果を左右します。

取引条件は、受注を受け付けてよいかどうかの判定に関わります。与信枠、締日、支払方法、請求の宛先は取引先ごとに異なるのが通例で、システム側では受注時の判定条件として持つ形になります。与信残高を超えた注文を止めるのか、警告のうえ受け付けて社内承認へ回すのかは、運用方針として先に決める項目です。製造委託などの委託取引を含む場合は、代金の支払期日を給付の受領日から60日以内とする定めが締日と支払条件の設計に影響します²。2026年1月に施行された同法では、支払が遅れた場合に受領日から60日を経過した日から支払を行う日までの期間について年14.6%の遅延利息を支払う定めも置かれており、締日の取り方と検収日の記録が金額の問題に直結します2。

アカウント権限は、取引先の社内で誰が何をできるかの設定です。本社の購買担当が全店舗の発注を見られる状態にするのか、店舗ごとに自店の履歴だけを見せるのかで、必要な階層が変わります。承認フローを使う場合は、金額の上限で承認者を切り替えるのか、部署単位で固定するのかを取引先ごとに設定できるかを確かめます。取引先の組織が変わったときに、自社側で権限を付け替えられるかも運用の分かれ目です。

粒度の選択は、グループ単位への集約から始めるのが実務的です。同じ条件の取引先を1つのグループに束ね、例外だけを個社単位で持つと、マスタの件数を抑えられます。全件を個社設定にすると、価格改定のたびに取引先数と同じ回数の更新が必要になります。次の対応表は、5領域それぞれの粒度の選択肢と、製品確認時の観点を並べたものです。

表に挙げた観点は、製品ごとに設定できる範囲が分かれる部分です。公開されている機能情報では、会員（価格）グループごとに掛率を設定する機能を備えた製品があります^*6。同じ「取引先別」という言葉でも、グループ単位までなのか個社単位まで踏み込めるのかは製品差が出ます。機能名の一致だけで判断せず、自社の例外条件を持ち込んで挙動を確かめたい部分です。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。

取引先別の価格・掛率設計で押さえる論点

価格・掛率の設計では、グループ単位と個社単位の使い分け、設定が競合したときの参照順、改定時の履歴管理という3点を先に決めます。前節が領域の全体像であるのに対し、本節は金額の決まり方に絞って掘ります。参照順の扱いは製品ごとに違うため、公開情報と検証環境の双方で確かめる項目です。履歴が残らない設計にすると、過去の受注金額の根拠を後から示せなくなります。

グループ設定は、条件が同じ取引先をまとめて扱うための仕組みです。卸価格の階層が3段階なら、まず3つのグループを作り、そこへ取引先を割り当てます。個社単位の設定は、年間契約や特売で例外が生じた取引先だけに絞ると、更新の手数を抑えられます。例外の件数が全取引先の過半を占める場合は、グループの切り方そのものを見直す目安になります。

掛率の設定は商品側と取引先側の両方に置けるため、競合したときの参照順が論点になります。取引先別の個別価格、価格グループの掛率、商品別の掛率、標準売価という4つの層があり、どの層が先に適用されるかで請求金額が変わります。次の図は、この4層を確認する順序として並べたものです。順序は製品ごとに異なりますので、比較の段階で自社の例外条件を持ち込んで挙動を確かめます。

掛率で計算した売価には、端数処理の指定が付きます。円未満を切り捨てるのか四捨五入するのかで、1件あたりの差は小さくても、月次の請求では差額の説明が必要になります。単価が小数点以下を持つ商材では、明細行での丸めと合計での丸めのどちらを採るかも取り決めが要ります。税区分や送料の扱いを取引先別の条件として持てるかも、あわせて確かめます。

価格改定では、いつから新しい価格を適用するかの予約設定が効きます。改定日をまたぐ受注が発生する場面では、受注日基準か出荷日基準かで金額が変わります。期間限定の特価を扱う場合は、期間の終了後に自動で元の価格へ戻る動きを確かめておきたい部分です。改定作業を手作業の一括更新に頼ると、戻し忘れが残ります。

履歴管理は、受注時点の価格を注文データ側に残す設計かどうかで差が出ます。マスタの値を参照するだけの設計では、改定後に過去の注文を開いたときに現在の価格が表示されます。電子取引データには、日付・金額・取引先の3項目で検索できる状態と、訂正や削除の履歴を追える措置が求められます³。令和7年6月時点の一問一答では、電子取引データの保存期間は国税関係書類と同じ原則7年間、欠損金額が生じた事業年度については10年間とされていますので、価格改定を挟んだ受注の記録も同じ期間残る前提で設計します3。価格の履歴と注文データの保存を合わせて設計すると、後の確認作業が軽くなります。

掛率の設定ミスは、1件の登録で多数の取引先へ波及します。グループの掛率を1桁誤れば、そのグループの受注が誤った金額で成立し、訂正と再請求の作業が発生します。内製で設計する場合は、価格体系の整理、マスタ設計、端数処理の税務上の扱いという3方面の知識が必要です。設定の検証手順まで含めて設計できるかどうかが、内製と外部委託の分かれ目になります。

取引先別の商品表示と発注ルールの作り分け

商品表示と発注ルールは、取引先が買える対象と買える数量を決める設定です。前節の金額に対し、本節は対象と数量の制御を扱います。表示制御は非公開の徹底度、発注ルールは入数と最低発注数量の持ち方、配送は納品先の複数登録が確認点です。ここを詰めておくと、受注後の電話確認と出荷側の差し戻しを減らせます。

取扱可否の制御は、取引先ごとに見せる商品を切り替える仕組みです。特定チェーン向けの専用商品や、販路が限られる商品を扱う場面では、この制御が前提になります。確かめたいのは、商品一覧から消えるだけでなく、検索結果や商品URLの直接入力でも表示されないかという点です。カートに入れた後の在庫確認画面や、過去の注文履歴からの再注文でも制御が効くかを併せて見ます。

ログイン前の表示範囲も、取引先別の設計に含まれます。卸価格を会員限定にする場合、未ログイン時は商品名と画像だけを出す構成が採れるかを確認します。検索エンジンに卸価格が載ることを避けたい商材では、この設定が販路の管理に直結します。取引先の担当者が変わった際のアカウント発行手順も、あわせて決めておきます。

数量の制御は、入数、ロット、最低発注数量の3つを分けて考えます。入数は1ケースあたりの本数、ロットは発注できる数量の刻み、最低発注数量は1回の注文で満たすべき下限です。取引先別に下限を変える運用では、商品側の設定と取引先側の設定のどちらが優先されるかを確かめます。金額ベースの下限を併用する場合は、送料の無料条件との関係も整理が要ります。

納品先の複数登録は、店舗や倉庫を持つ取引先で必要になります。本社が発注し、商品は各店舗へ直送する運用では、1つの注文に複数の納品先を指定できるかが分かれ目です。配送日の指定、時間帯、着荷指定日の締切時刻も取引先ごとに条件が異なります。出荷側の締切と受注画面の締切がずれると、当日出荷の約束が守れなくなります。

表示制御の設定漏れは、販路の取り決めに関わる問題へ発展します。専用商品が別の取引先の画面に出れば、価格の開示と併せて説明が必要になります。数量の設定漏れでは、ロットに合わない注文が通り、出荷側での数量修正と再確認を招きます。修正のたびに受注センターと物流の双方へ手作業が戻りますので、設定の確認手順を運用へ組み込みます。

法令・業界標準への対応から見た要件

制度面の要件は、電子取引データの保存、取引条件の明示、業界標準との接続という3つに整理できます。前節までが自社の商習慣の再現であるのに対し、本節は外部から求められる要件を扱います。保存要件は改ざん防止措置と検索性、明示の要件は注文内容の記録、接続要件はEDI（電子データ交換。企業間で取引データを電子的にやり取りする仕組み）と基幹システムとの受け渡しが論点です。いずれも後付けが効きにくいため、選定の段階で確かめます。

電子取引データは、電子のまま保存する取り扱いが原則です。一問一答では、改ざん防止の措置、ディスプレイやプリンタでの見読可能性、日付・金額・取引先による検索という3つの要件が示されています³。改ざん防止は、タイムスタンプの付与、訂正や削除の記録が残るシステムの利用、事務処理規程の備付けといった方法から選びます。令和7年6月時点の一問一答では、タイムスタンプを使う場合の付与期限は取引情報の授受後おおむね7営業日以内、業務の処理に係る通常の期間（最長2か月）を定めているときはその期間の経過後おおむね7営業日以内とされています3。Web受発注システムを使う場合は、注文データがこの要件を満たす形で残るかを確かめます。

検索の要件には、事業者の規模に応じた緩和が置かれています。基準期間の売上高が5,000万円以下の事業者などは、税務職員のダウンロードの求めに応じられるときに検索機能の確保が不要とされています^*3。緩和の対象に当たるかどうかは各年度の売上高で変わるため、恒久的な前提にはしません。システム側で3項目の検索ができるなら、緩和の可否に左右されずに運用できます。

委託取引では、取引条件を書面または電磁的方法で明示する定めがあります。製造委託などを含む取引では、代金の支払期日を給付の受領日から60日以内とする上限が置かれています²。関係する法令は名称と内容が改められ、2026年1月1日に施行されました2。同法の対象になるかどうかは資本金の区分で判定し、製造委託等では資本金3億円超と3億円以下、資本金1,000万円超3億円以下と1,000万円以下という2組の組み合わせが基準になります^*2。自社の取引がこの対象を含む場合は、注文と条件の記録をシステム上で追える状態にしておきます。

業界標準との接続は、取引先から指定される場合があります。流通BMS（流通ビジネスメッセージ標準。流通業の企業間取引で使うメッセージの標準仕様）では、発注、出荷、受領、返品、請求、支払という6つの業務についてメッセージが標準化されています⁵。2026年時点で公開されている情報では、通信手順としてebXML MS、AS2、JX手順の3方式が定められており、導入の手引きも併せて公開されています5。どの手順で接続するかを含め、対応の可否は取引先との取り決めで決まります^*5。Web受発注システムとEDIを併用する運用では、同じ注文が二重に取り込まれない設計が要ります。

基幹システムとの連携方式は、CSVの受け渡し、API、EDIの3通りに大別されます。CSVは導入が早い代わりに、取り込みの時刻まで在庫と与信の情報が古いままです。APIで在庫と与信を都度参照する方式なら、受注時点の判定に精度が出ます。どの方式でも、取引先別価格をどちらのシステムが正とするかを決めておかないと、金額の食い違いが起きます。

制度と標準への対応は、法令の読み取りとシステム設計の両方にまたがります。保存要件は経理と情報システムの担当が分かれて見るため、要件の抜けが生じやすい部分です。中小企業向けには、電子受発注システムの普及促進に向けた実証調査事業の報告書が公開されており、検討の材料として参照できます^*7。社内に法令対応の経験が薄い場合は、要件定義の段階で外部の設計支援を入れるほうが手戻りを抑えられます。

取引先別機能の要件定義と選定の進め方

進め方は、取引条件の棚卸し、設定粒度の線引き、移行データの整備という3段階で組みます。前節が外部要件の確認であるのに対し、本節は自社側の作業の順序を扱います。棚卸しで現行の例外条件を洗い出し、線引きで標準機能に収める範囲を決め、整備で移行前のデータを揃えます。この順序を逆にすると、決めきれていない条件をシステムの都合へ合わせる形になります。

取引条件の棚卸しは、取引先マスタの整理と価格表の突き合わせから始めます。営業担当の手元にある見積、基幹システムの単価、請求書の実績値という3つを並べると、実際に適用されている条件が見えます。3つが一致しない取引先が出た場合は、どれを正とするかを営業部門と決めます。棚卸しの結果は、後の設定粒度の判断へそのまま使います。

設定粒度の線引きでは、グループ単位への集約と個社設定の限定を並行して決めます。全取引先を個社設定にすると、価格改定の作業量が取引先数に比例して増えます。逆にグループだけで運用すると、例外条件を持つ取引先で受注後の手直しが残ります。集約後のグループ数と、個社設定として残す取引先の件数を、運用体制の人数と照らして決めます。

標準機能で吸収できない条件が残った場合の選択肢は、業務側の見直し、個別開発、運用での代替という3つです。業務側の見直しは費用が小さい代わりに、営業部門と取引先の合意が必要になります。個別開発は要件へ合わせられる代わりに、以後の製品更新のたびに影響範囲の確認が伴います。どの条件を開発の対象にするかは、対象の取引先数と受注件数で優先順位を付けます。

移行データの整備は、名寄せと重複の解消、そして動作検証の2つで進めます。取引先コードが基幹システムと販売管理で別に振られている場合は、対応表を作ってから移行します。移行後の帳票や注文データは、令和7年6月時点の一問一答で示された原則7年間の保存期間にわたって参照できる形で残す必要がありますので、旧システムの履歴をどこまで移すかも同じ段階で決めます^*3。次の図は、ここまでの3段階と、各段階に入る作業を並べたものです。

検証では、取引先ごとにログインして表示と金額を確かめる手順を組みます。見たいのは、非公開商品が出ないか、掛率が想定どおりか、発注単位の下限が効くか、納品先が選べるかという4点です。内製で進める場合は、業務要件の整理、マスタ設計、連携方式の選定、検証計画の作成という役割が必要になります。これらを兼任で回すと、検証が最後に圧縮され、公開後の手直しが増えます。

外部の支援を使う判断は、難しさの回避ではなく手戻りの抑制で考えます。要件定義の段階で設定粒度と連携方式を固めておけば、開発後の仕様変更を減らせます。自社に受発注の業務知識があるなら、条件の棚卸しは社内で進め、設計と検証の枠組みづくりを外部と分担する形も採れます。分担の線を先に決めておくと、判断の待ち時間が減ります。

導入後の運用体制とつまずきやすい点

導入後は、マスタ更新の分担、取引先への案内、設定変更の確認手順という3点を決めておくと安定します。前節が公開までの作業であるのに対し、本節は公開後に回り続ける体制を扱います。更新の担当を営業と業務で分けるか一本化するか、変更の点検を誰が担うかで、設定ミスの起きやすさが変わります。操作ログを残す設定にしておけば、金額の問い合わせに履歴で答えられます。

取引先マスタと価格マスタは、更新の頻度と責任者が異なります。取引先マスタは新規開設や住所変更で動き、価格マスタは改定と特価で動きます。営業部門が価格を、業務部門が取引先情報を持つ分担にすると、更新の依頼待ちが減ります。権限を分ける場合は、誰がどの項目を変更できるかを一覧にして共有します。

取引先への案内は、切り替えの前後で内容を分けます。事前には、開始日、ログイン方法、従来のFAXをいつまで受けるかを伝えます。開始後は、初回発注の完了状況を取引先ごとに追い、未利用の先へは電話で操作の確認を添えます。全先を同時に切り替えるより、発注件数の多い取引先から段階的に移すほうが、受注センターの負荷が平準化します。

つまずきやすいのは、例外条件を個社設定で積み増していく運用です。特価の依頼が入るたびに個社設定を追加すると、やがて全体像を把握できる担当がいなくなります。四半期ごとに個社設定の件数を数え、グループへ戻せるものを整理する手順を決めておきます。設定の棚卸しを運用の定例へ組み込むと、増え方を抑えられます。

設定変更の確認手順は、登録から記録までを固定します。設定内容の登録、第三者による点検、取引先画面での確認、操作ログの記録という4段階で回すと、単独の作業ミスが本番へ出にくくなります。委託取引を含む場合は、2026年1月に施行された法令で代金の支払期日が給付の受領日から60日以内と定められ、期日を過ぎた分には年14.6%の遅延利息が生じますので、締日や支払条件の変更は点検の対象から外せません^*2。次の図は、この順序を並べたものです。

操作ログは、問い合わせへの回答と原因の切り分けに使います。受注金額の相違を指摘された場面では、受注時点の価格と設定の変更履歴を突き合わせて説明します。電子取引データの保存では、訂正や削除の履歴を追える措置が求められます^*3。ログの保存期間と、閲覧できる担当者の範囲を導入時に決めておきます。

運用の負荷は、設定の細かさと担当者の人数で決まります。個社設定を増やすほど点検の対象が広がり、確認の手数が積み上がります。中小企業のデジタル化は2025年版の白書で段階1から段階4までの4段階に整理されており、受発注のWeb化を次の段階へ進めるには、設定を維持する体制がそのまま前提になります^*4。社内の担当が兼任で点検まで手が回らない体制なら、設定変更の枠組みと確認手順の設計を外部と分担する選択もあります。分担の目的は作業の丸投げではなく、設定ミスが本番の受注へ出る確率を下げることにあります。

よくある質問

個社単位の価格設定は何社くらいまで運用できますか

件数の上限は製品ごとに異なりますので、公開情報と検証環境で確かめる項目です。判断の目安になるのは、価格改定の頻度と更新を担う人数です。改定のたびに個社設定の件数と同じ回数の更新が発生しますので、担当者が対応できる件数を先に見積もり、それを超える分はグループ単位へ集約する設計にします。

従来のFAX受注と併用しながら段階的に移行できますか

併用しながらの移行は選べますが、同じ注文が二重に取り込まれない手順を先に決めます。受付経路ごとに担当と登録先を分け、FAXの受付を続ける期間と終了の予定を取引先へ事前に伝えます。発注件数の多い取引先から順に移すと、受注センターの負荷が一度に集中せずに済みます。

取引先別の条件は標準機能でどこまで吸収できますか

吸収できる範囲は製品と条件の内容で変わりますので、棚卸しした例外条件を持ち込んで確かめる進め方が確実に近づきます。標準機能に収まらない条件が残った場合の選択肢は、業務側の見直し、個別開発、運用での代替という3つです。対象の取引先数と受注件数で優先順位を付けて振り分けます。

Web受発注システムを導入すれば電子帳簿保存法への対応は完了しますか

完了とは言えません。保存の要件は電子取引データ全般に及びますので、メールに添付された注文書や請求書も対象に含まれます。要件は改ざん防止の措置、見読可能性、日付・金額・取引先による検索の3つで示されており^*3、システムの外でやり取りするデータの扱いも併せて決める必要があります。

取引先別価格は基幹システムとWeb側のどちらで持つべきですか

どちらを正とするかを決めることが先で、置き場所の議論はその後です。基幹システムを正とする場合は、Web側へ配信する頻度と、配信が遅れたときの表示の扱いを決めます。連携方式はCSVの受け渡し、API、EDIの3通りに大別され、在庫と与信を受注時点で判定したい場合はAPIでの都度参照が向きます。

1. *1　出典：経済産業省「令和6年度 電子商取引に関する市場調査（結果公表資料）」（2025）　経路
2. *2　出典：公正取引委員会「中小受託取引適正化法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律）関係」（2025）　経路
3. *3　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】（令和7年6月）」（2025）　経路
4. *4　出典：中小企業庁「2025年版 中小企業白書 第1部第1章第5節 デジタル化・DX」（2025）　経路
5. *5　出典：一般財団法人流通システム開発センター「流通BMS（流通ビジネスメッセージ標準）公式情報」（2026）　経路
6. *6　出典：株式会社Dai「Bカート 機能詳細 会員（価格）グループ別の掛率設定」（2026）　経路
7. *7　出典：中小企業庁「電子受発注システム普及促進に向けた実証調査事業 報告書」（2023）　経路