Web受発注システムで取引先別の掛率を管理する方法|設定単位・変更履歴・データ移行

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

B2B EC-COLUMN

取引先ごとに掛率が違う商慣行が、なぜExcel・紙管理で回らなくなるのか

取引先Aは65掛け、Bは70掛け、長年の付き合いのC社だけ特定カテゴリを別単価で——こうした取り決めを、担当者のExcelと記憶で回している卸売の現場は珍しくありません。
取引先が増えるほど、単価の取り違えや引き継ぎ漏れが起きやすくなります。
Web受発注システムには、卸価格と取引先ごとの販売価格を別個に持ち、取引先ごと・グループごと・商品ごとに掛率を設定できる機能があります。
ただし設定できる粒度は製品によって異なり、掛率を変えたときの履歴の残し方や、いまのExcelからどう移行するかは、導入前に確かめておく必要があります。

掛率は、定価や上代に対して取引先へいくらで卸すかを示す比率です。
同じ商品でも、取引量の多い取引先には65掛け、取引の浅い取引先には70掛け、長年の関係がある一社だけ特定カテゴリを別扱い——といった具合に、取引先ごとに違う数字が並びます。
この取り決め自体は商慣行として理にかなっていて、なくす必要はありません。
問題になるのは、その数字をどこに置いて、誰がどう参照しているかです。

多くの現場では、掛率は一枚のExcelに集約されています。
FAXやメールで受注票が届いたら、そのファイルを開き、取引先名の行を探し、商品に掛率を当てて単価を計算し、受注伝票へ転記する。
取引先が十数社のうちは、この流れで十分に回ります。
崩れ始めるのは、取引先が数十社を超え、さらに「この取引先のこのカテゴリだけ別掛率」という例外が混ざってきたときです。
探す対象が行から行の中の条件に変わり、一件あたりの判断に時間がかかるようになります。

Excelそのものの扱いにも、取引先が増えるほど負荷がかかります。
複数人が同じファイルを触れば、どれが最新版か分からなくなり、手元に控えを取った人はその控えを見続けます。
改定の連絡が全員に届いたかどうかも、ファイルからは分かりません。
掛率が一人の頭と一つのファイルに依存している状態では、確認の手間は取引先数に比例して増えていきます。

もうひとつの崩れ方が、担当者の交代です。
掛率表には数字は書いてあっても、なぜその掛率になったのか、いつから適用しているのか、誰が決めたのかまでは残っていないことが多い。
前任者に聞けば分かった背景が、引き継ぎ後は誰にも分からなくなります。
次の価格改定を交渉するときに、そもそもの根拠が手元にない状態で臨むことになります。

こうした手作業中心の受発注は、決して例外的なやり方ではありません。
中小商業・サービス業を対象にした調査では、電子文書での商取引や受発注情報管理の導入率は18.5%で、2割を下回っていました⁵。
2018年時点の、卸売業に限らない中小商業・サービス業全般を対象にした数字ですが、大半が電話やFAXなど従来の方法に依存している状況がうかがえます。
電話やFAXで受けた内容を手で入力する以上、単価の取り違えや書類の紛失は個人の注意力とは別のところで起こりうる、というのがこの調査から読み取れることです。

つまり掛率の属人管理は、担当者が不注意だから起きているというより、掛率という取り決めがシステムの外側に置かれていることから来ています。
だとすれば確認すべきは、Web受発注システムが取引先ごとの掛率をデータとして持てるのか、そして持ったうえでどう運用できるのかです。

Web受発注システムは取引先別の掛率をどう管理するのか

取引先別の掛率をシステムで扱うときの土台になるのは、価格を一本で持たないという設計です。
自社が取引先に売る卸価格と、その取引先が自分の顧客に売る販売価格を、同じ商品に対して別々に保持します。
この二つを分けて持てると、取引先がログインしたときに画面へ表示される価格を、その取引先向けの掛率で計算した金額にできます。

実際の運用例として、各種工業用粘着テープやテープ貼り機器を中心に約3,800品種の提案・販売を手掛ける日東電工CSシステム株式会社では、全国約3,000社の販売店が同社製品を取り扱っています¹。
販売加盟店が卸価格にマージンを加えて販売するモデルのため、ECシステム側で卸価格と販売価格を別個に管理する仕組みを導入しています¹。
これは同社の販売加盟店向け卸売モデルでの実装で、業種や商流が違えば同じ構成がそのまま当てはまるわけではありません。
ただ、取引先ごとに価格が変わる商慣行をシステム側で受け止めた形としては、自社の商流を当てはめて考える材料になります。

この仕組みが効くのは、価格を計算する場所が移るからです。
掛率がシステム側にあれば、注文を受けてから営業事務が掛率表を開いて単価を当てる工程が、取引先が画面を見た時点で済んでいることになります。
なくなるのは掛率表の参照と単価の転記で、残るのは新しい取引先の掛率をマスタへ登録する作業と、改定した掛率が意図どおり反映されているかの確認です。

取引先の側から見ると、変化はもっと単純です。
これまでは自社向けの価格が分からないまま品番と数量を書いて送り、返ってきた注文請書で金額を知る、という順番でした。
掛率が適用された価格が画面に出ていれば、発注する前に金額が分かります。
金額を確かめるためだけの電話やメールが、そもそも起きにくくなります。

ここまでは「持てる」という話です。
実務でつまずきやすいのは、その一段先にあります。
自社の掛率が取引先ごとに一律なのか、商品カテゴリごとに例外を抱えているのか、あるいは代理店の本部と傘下店舗で分けたいのか。
どの単位で設定できるかは製品によって異なり、ここが合わないと、システムを入れてもExcelの補助表が横に残ることになります。

掛率の設定単位(個社別・グループ別・商品別)をどう選ぶか

実装方式の主な分類

掛率をシステム上でどう持つかには、いくつかの方式があります。
卸売の仕切価格に関する解説では、価格グループと掛率の組み合わせ、取引先ごとの個別単価、基幹システムの単価を参照する方式、数量帯で変わる階段価格といった複数の実装方式が挙げられています²。
これは卸売業における掛率運用の一般的な整理であって、特定製品の仕様書ではありません。
それでも、自社の取り決めがどの方式に乗るのかを考える下敷きにはなります。

価格グループと掛率の組み合わせは、取引先をいくつかの区分にまとめ、区分ごとに掛率を当てる方式です。
取引先が増えても設定件数が増えにくい反面、区分に収まらない取引先が出るたびに例外の置き場所が必要になります。
個別単価は、取引先と商品の組み合わせで金額そのものを持つ方式です。
どんな取り決めでも表現できますが、件数が増えるほど改定時に更新する対象も増えます。

基幹システムを参照する方式は、単価の正本を既存の販売管理側に置いたまま、受発注画面で読み出す形です。
同じ数字を二か所で管理する状態は避けられる一方、参照先の応答や連携の作り込みに依存します。
階段価格は、まとめ買いで掛率が変わる取り決めがある場合に必要になる方式です。

製品側の設定名として見ると、EC-Rider B2B IIの機能一覧には、会員ランク別下代設定、会員別商品別下代設定という名称の設定機能が挙げられています³。
下代は仕入側から見た価格の呼び方で、取引先に対する卸値にあたります。
前者は取引先を区分にまとめて下代を決める使い方、後者は取引先と商品の組み合わせで下代を決める使い方に対応します。
同じ一覧では、個店・代理店・チェーン店などバイヤー毎の組織階層管理も可能とされています³。
これは同製品の機能一覧上の記載であり、ほかの製品がどの粒度まで対応するかは、それぞれ個別に確かめる必要があります。

自社の商流に当てはめる目安

方式が分かっても、自社がどれを選ぶべきかはすぐには決まりません。
判断の材料になるのは、いま使っている掛率表そのものです。
取引先の一覧を開いて、全商品に同じ掛率を当てている取引先と、商品やカテゴリによって掛率が変わる取引先を分けて数えてみます。
前者が大半なら、区分にまとめる方式を基本にして無理がありません。
後者が一定数を占めるなら、区分だけでは足りず、取引先と商品の組み合わせで持てる仕組みが要ります。

運用として落ち着きやすいのは、区分を基本にして例外だけ個別に持つ組み合わせです。
ただしこの形にするなら、例外がどこまで増えても耐えられるかを先に見ておきたいところです。
例外が全取引先の過半に及ぶようなら、それはもう例外ではなく、区分の切り方そのものが商流と合っていないことになります。

もうひとつ見落としやすいのが、取引先が単独の会社とは限らない点です。
本部と契約し、実際の発注は傘下の各店舗から来るという商流では、契約条件は本部単位、発注と納品は店舗単位になります。
この場合、掛率を店舗ごとに個別登録していくと、本部との条件改定のたびに全店舗分を更新することになりかねません。
階層でまとめて価格を当てられるかどうかは、傘下の店舗数が多いほど効いてきます。

数量によって掛率が変わる取り決めがあるかどうかも、早めに整理しておくと後が楽です。
「10ケース以上で掛率を下げる」といった条件は、電話や紙での運用なら柔軟に見えます。
しかしシステム側で表現できないと、結局は受注後に担当者が手で単価を直すことになり、その一件だけ確認の工程が元に戻ります。

掛率を変更したとき、履歴と承認をどう残すか

設定単位が決まると、次に効いてくるのが変更のしかたです。
期中に一社だけ掛率を下げることになった、という場面を考えてみます。
営業がメールで合意を取り、担当者がマスタの数字を書き換える。
作業としてはこれで終わりですが、書き換えた瞬間に、いくつかの情報が消えます。

消えるのは、いつから下げたのか、なぜ下げたのか、誰が決めたのか、前はいくつだったのか、です。
改定日をまたいだ注文の単価を後から検証したいとき、書き換え後のマスタしか残っていなければ、当時いくらで受けたのかをシステムから説明できません。
卸売の仕切価格運用に関する解説では、掛率マスタに適用開始日・根拠・承認者・版の4項目を持たせることが運用の最低要件とされています²。
この4項目は、いま挙げた四つの消える情報とそのまま対応しています。

適用開始日があると、どの注文にどの掛率が当たるかが日付で決まります。
根拠は、次の改定交渉に臨むときの前提になります。
承認者は、営業担当の判断だったのか上長の承認を経たのかを区別します。
版は、過去に遡って当時の条件で金額を再計算できる状態を残します。

改定には、全取引先へ一斉に反映するものと、一社だけに適用するものがあります。
上代の改定に合わせて掛率はそのままに卸値が動く場合と、特定の取引先の掛率だけを動かす場合とでは、影響範囲も決裁する人も違います。
前者は適用開始日をそろえて登録しておけば済みますが、後者は誰が承認したかを残さないと、後から「なぜこの一社だけ条件が違うのか」を説明できなくなります。

同じ解説では、特定取引先向けの例外的な掛率も、口頭やメールだけで済ませず承認フローに載せる必要があるとされています²。
例外はもともと件数が少なく、急ぎで決まることが多いため、記録から漏れやすい。
そして漏れたものほど、担当者が代わったときに理由の分からない数字として残ります。
これは卸売における掛率運用の一般的な管理要件としての整理であり、個別の製品がこの形を画面として備えていることを保証するものではありません。

製品側を見るときは、掛率を「書き換えられるか」ではなく「書き換えた記録が残るか」で確かめると、違いが見えやすくなります。
変更が上書きになるのか、適用開始日を指定して将来の掛率を先に登録できるのか、誰がいつ変更したかを後から追えるのか。
ここが揃っていれば、改定日の前後で受けた注文を一件ずつ手で突き合わせる作業を減らせます。
一方で、合意した内容をマスタへ入力する作業と、入力後に意図どおりの価格が出ているかの確認は、どの仕組みを選んでも残ります。

既存の掛率データ(Excel等)をシステム導入時にどう移行するか

移行対象期間の目安

最後に残るのが、いまExcelや既存システムにある掛率をどう持ち込むかです。
移行の話になると期間や工数に目が行きがちですが、先に整理したいのは対象の切り分けです。
現在有効な掛率、過去の掛率の履歴、そして取引実績は、それぞれ必要とされる理由が違います。
現在有効な掛率は運用開始に欠かせませんが、履歴や実績はどこまで遡って見たいかで判断が変わります。

移行の前に一度やっておくと効くのが、掛率表の棚卸しです。
何年も発注のない取引先の行、統合や屋号変更で実体が変わった取引先、同じ取引先が別コードで二重に登録されている行。
こうしたものは、そのまま移せば新しいシステムの中にも残ります。
件数が多いほど後の確認作業も重くなるため、現在も有効な取り決めだけを持ち込むと決めておくと、移行後に突き合わせる対象も絞れます。

掛率そのものの移行で難しいのは、取り決めが単純な比率で済んでいない場合です。
販売管理システムのデータ移行に関する解説では、取引先別単価のうち特別単価・期間限定割引・ロット別段階単価は業務ルールに直結する複雑性があり、新旧システムの構造が合わない場合は変換ロジックの開発が必要になるとされています⁴。
期間限定の割引や数量帯の段階単価を抱えているなら、移行作業は単純な転記ではなく、条件をどう表現し直すかの設計を含むことになります。
設定単位を早い段階で確かめておきたい理由もここにあり、受け側の構造が決まらないと移行の見積もりも定まりません。

過去実績については、同じ解説で、直近1〜2年分の月次集計データ（取引先別売上、商品別売上）を新システムに移行するのがよいとされています⁴。
取引先別の売上が1〜2年分あれば、前年同月との比較や取引先ごとの推移は追えます。
それ以前のデータは旧システムやファイルで参照できる形にしておく、という切り分けです。
これは販売管理システム全般の移行手法として一社が示した目安であり、業界共通の標準手順というわけではありません。
自社の決算や与信の運用でそれ以上の期間が要るなら、目安より長く取る判断もあり得ます。

並行稼働で検算する

移行したデータが正しいかどうかは、登録が終わった時点では分かりません。
実際の注文を通して、旧来の方法で出した単価と新しいシステムが出した単価が一致するかを見る必要があります。
同じ解説では、6〜8週間の並行稼働期間を設けることが多いとされています⁴。
この期間は、新旧の値を突き合わせ、差が出たものを一件ずつ潰すための時間だと考えると分かりやすくなります。

突き合わせの順番は、取引先名の並び順ではなく、例外の多さで決めると効率が上がります。
全商品一律の掛率で取引している取引先は、一件合えばほかも合う可能性が高い。
一方、商品ごとに掛率が違う取引先や、数量帯で条件が変わる取引先は、条件の組み合わせごとに確かめる価値があります。
月初や月末にしか発生しない取引がある場合は、並行稼働の期間のうちに、その締めを一度は通しておきたいところです。

Excelで管理してきた掛率表をそのまま取り込めるかどうかは、製品ごとに異なります。
一括登録に対応していても、受け付ける項目の並びや、取引先コード・商品コードの体系が現在のファイルと同じとは限りません。
移行の相談をするときに掛率表を数行分でも見てもらうと、どこが変換の対象になるかが具体的に分かります。

掛率の設定単位、変更時の記録、移行時の変換——難易度を決めるのは製品の機能一覧よりも、いまの掛率表がどれだけ例外を抱えているかです。

掛率の設定単位は、機能一覧の項目名を読むだけでは自社の取り決めに合うかどうか判断しにくい部分です。取引先ごと・商品ごと・組織階層ごとに卸値を設定する仕組みを実際に構築してきた開発元であれば、いまの掛率表を見ながら、どの単位で持てば例外が減るかを具体的に検討できます。

現在お使いの掛率表と、商品別・数量別といった例外的な取り決めの件数を共有いただければ、それをどの設定単位で表現できるか、変換が必要になるのはどこかを確認できます。無料相談で要件を整理する

掛率設定の実装パターンと選定時の確認軸

掛率をシステムのどこに、どの単位で持たせるかという保持のしかたの違いで並べています。

• 全商品に同じ掛率を当てている取引先と、商品ごとに例外がある取引先はそれぞれ何社か（区分でまとめる方式で足りるかの判断材料）

• 同じ掛率で束ねられる取引先グループが実際に作れるか、毎回例外が入り込まないか（価格グループと掛率の組み合わせ）

• 取引先と商品の組み合わせで金額を固定したい取り決めがどれだけあるか（個別単価）

• 掛率の正本を基幹システム側に置いたまま参照するのか、受発注システム側に持たせるのか（基幹システム参照）

• 数量帯によって掛率が変わる取り決めがあるか（階段価格）

• 本部と店舗のように、階層で価格を分けて管理する必要があるか

要点の整理

軸	基準
掛率の持ち方	全商品一律の取引先と商品ごとに例外がある取引先を、現在の掛率表で分けて数える
設定単位	個社別・グループ別・商品別に加え、本部と店舗の階層、数量帯の有無まで含めて選ぶ
変更時の記録	適用開始日・根拠・承認者・版が残るか。例外的な掛率も承認フローに載せる
データ移行	過去実績は直近1〜2年分が目安。特別単価や期間限定割引は条件の表現を設計し直す
稼働後の確認	6〜8週間の並行稼働で、例外の多い取引先から新旧の単価を突き合わせる

掛率の移行は、現在有効な数字だけでなく、変更履歴や過去実績をどこまで持ち込むかで作業量が変わります。取引先数の多い卸売モデルでの構築経験をもとに、自社の条件がどこで引っかかりそうかを事前に洗い出せます。 掛率の設定単位、改定時の履歴の残し方、既存データの移行範囲について、自社の取り決めに当てはめた場合の進め方と確認すべき順番を相談できます。

よくある質問

掛率と値引率・単価の違いは何か

掛率は上代（定価）に対して取引先へいくらで卸すかを示す比率で、6.5掛け＝上代の65%という形で表します。
値引率は基準価格からいくら引くかを示すもので、65掛けは35%値引きと同じ金額になりますが、社内で値引きとして扱うと、恒常的な取引条件なのかその都度の交渉なのかが混ざります。
単価は条件を適用した後の金額そのものです。
システムで持つときは、比率で持つか金額で持つかで改定時の作業が変わり、上代の改定に連動させたいなら価格グループと掛率の組み合わせ、取引先ごとに金額を固定したいなら個別単価といった方式が対応します²。

取引先ごとの与信管理と掛率管理は別の機能として設定するのか

確認できた資料の範囲では、製品ごとの扱いまで断定できません。
性質としては、掛率はその取引先にいくらで売るかという価格条件、与信は取引を続けてよいか・未回収をいくらまで許容するかという取引可否の条件で、更新の頻度も決裁する人も異なります。
同じ取引先マスタの中で別々の項目として持つ構成が考えられますが、受注時にそれぞれがどう働くか（与信超過で受注を止めるのか、警告に留めるのか）は製品によって違うため、自社の運用と突き合わせて確認する部分になります。

本部一括契約の代理店でも、傘下の店舗ごとに掛率を変えられるか

EC-Rider B2B IIの機能一覧では、個店・代理店・チェーン店などバイヤー毎の組織階層管理が可能とされ、会員ランク別下代設定と会員別商品別下代設定という設定機能が挙げられています³。
これは同製品の機能一覧上の記載であり、ほかの製品で同じ構成が取れるかは個別確認が必要です。
検討するときは、本部と合意した条件を階層の上位に置いて店舗ごとの差だけを例外として持てるのか、それとも店舗ごとに全件登録する必要があるのかを見てください。
前者と後者では、条件改定のたびに発生する更新作業の量が大きく変わります。

掛率データはCSVなどで一括登録・一括変更できるか

一括登録の可否と対応形式は製品ごとに異なり、確認済みの資料からは一般的な対応状況を断定できません。
確認するときは、取り込めるかどうかだけでなく、取引先コードと商品コードが現在のファイルとそろっているか、適用開始日のような項目も含めて取り込めるか、更新なのか全件置換なのかまで見ておくと実態がつかめます。
取引先別単価は新旧システムの構造が合わない場合に変換ロジックの開発が必要になるとされており⁴、期間限定割引や段階単価を含むなら、ファイル形式以前に条件の表現方法を確かめることが先になります。

1. 1　出典：株式会社フライトソリューションズ「EC-Rider B2B 導入事例（日東電工CSシステム株式会社様）」（事例掲載時点）
2. 2　出典：株式会社フライトソリューションズ「卸売の仕切価格・掛率の決め方と改定手順」（2026年）
3. 3　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱの機能一覧」（確認時点）
4. 4　出典：株式会社ripla「販売管理システムのデータ移行を成功させる5ステップ」（2026年）
5. 5　出典：中小企業庁（引用元：日本政策金融公庫総合研究所）「企業間のデータ連携で、受発注の業務コストを削減する!」（2018年）