受発注システムの費用は月額固定と従量課金どちらが得か|料金体系の内訳と見積もり比較の考え方

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

B2B EC-COLUMN

月額固定制と従量課金制はそれぞれ何に費用が発生するのか

見積書を並べたら、1社は月額いくら、もう1社は受注1件あたりいくらと数え方が違っていて、どちらが安いのか比べられない。
受発注システムの費用でつまずくのは、たいていこの場面です。
ここで先に決められるのは、自社で増えたり減ったりするのは何かという一点です。
月額固定制は使える機能の範囲に対して定額がかかり、従量課金制はアカウント数や受注件数といった処理量に応じて加算されます。
自社で動くのが人の数なのか注文の数なのか、その幅がどれくらいかが分かれば、どちらの体系で総額が読みやすいかは判断できます。
さらに初期費用と契約の条件も総額に効くため、料金表の月額だけを横に並べても比較は終わりません。

月額固定制の課金対象

月額固定制で毎月払っているのは、その月に処理した注文の数ではなく、使える機能の範囲そのものです。
受注データの取り込み、取引先ごとの価格の出し分け、注文書や納品書の出力といった機能のまとまりがプランとして区切られ、そのプランを使える状態に対して毎月同じ額がかかります。
ですから注文が集中した月も請求額は変わらず、反対にほとんど動きのなかった月も同じ額を払います。
予算を先に確定させたい、経理に毎月同じ数字で申請したいという事情があるなら、この読みやすさがそのまま利点になります。

ただし、定額であることと、制限がないことは別の話です。
料金表で確かめるのは、その段のプランに何が含まれていて、どこから上の段に移るのかという区切り方です。
機能の種類で段が分かれているのか、扱う規模で分かれているのかによって、同じ月額でも上がる条件がまったく違います。
EC-Rider B2B Ⅱの料金ページでも、月額料金はサーバー構成や各種要件の変更に伴って変動すると示されています³。
定額と書かれていても、その定額が成り立つ前提の構成があり、前提が変われば金額も動くということです。

この前提があるので、見積書の月額が同じ数字でも、そのまま比べたことにはなりません。
先に、自社が必ず使う機能を書き出してください。
取引先ごとに違う単価を出す、注文データを基幹システムへ渡す、担当者ごとに見える取引先を分けるといった具合に、業務で外せないものを並べます。
そのうえで、その機能が含まれる段はどれかを各社に指定してもらうと、ようやく同じ土俵の月額が並びます。

月額固定制が向きやすいのは、使う量が読めているというより、支出の形を先に決めておきたい場合です。
年度の予算として枠を取り、途中で増額の申請をしたくない。
複数の部署が同じ画面を使い、どの部署がどれだけ使ったかで費用を割り振る手間を増やしたくない。
こうした事情があるなら、多少の割高感があっても定額のほうが運用しやすいという判断は成り立ちます。
その代わり、契約した段のプランで業務が足りるかどうかは、稼働の前に機能の側で確かめておく必要があります。

従量課金制の課金対象(アカウント数・受注件数)

従量課金制は、処理した量に応じて金額が加算される仕組みです。
ここで比較がこじれるのは、その量の数え方が資料によっても製品によっても違うからです。
Webの受発注システム全般を扱った解説では、アカウント数に応じて月額料金が加算される従量課金制が採用されていることが一般的だとされています¹。
一方、主にECサイト運営者向けの受注管理システムを扱った資料では、受注1件ごとに5円〜35円程度が加算される仕組みが示されています²。
前者は人の数、後者は注文の数が加算の軸になっており、同じ従量課金という言葉でも増える条件が違います。

この違いは、そのまま自社の計画と結びつきます。
取引先を増やして発注をWebに寄せていく計画なら、取引先側の担当者アカウントが増えていきます。
アカウント数が軸の料金体系では、取引先の拡大がそのまま毎月の支出の増加として効いてきます。
反対に、取引先の数は当面変わらないけれど季節によって注文が数倍に振れるという事業なら、件数が軸の体系のほうが影響は大きく出ます。
どちらの体系が得かを考える前に、自社で先に動くのは人の数なのか注文の数なのかを確かめたほうが早いのは、このためです。

単価の幅も見落としやすいところです。
同じ受注1件あたりの加算でも、5円と35円では、同じ件数に対する加算額が数倍変わります²。
件数が多いほど、この差は総額で効いてきます。
あわせて、基本料金があってその上に加算されるのか、加算だけで構成されているのかも確認してください。
基本料金と従量分が分かれている場合、注文が少なかった月でも下限の金額は発生します。

なお、ここで引いた二つの資料は、一方が企業間の取引を扱う受発注システム全般の解説、もう一方が主にECサイト運営者向けの受注管理システムの解説で、対象とするシステムの範囲がやや異なります。
課金対象の数え方には二通りの軸があるという整理として読み、単価や金額をそのまま自社の見積もりの基準に置き換えないほうが安全です。

同じ受発注システムでも月額費用に数千円〜数十万円の幅があるのはなぜか

小規模〜中規模の月額費用の目安

課金の仕組みが分かると、次に気になるのは金額の水準です。
受注管理システムの月額費用は、3,000円〜20,000円前後が目安として示されています²。
これは2025年12月時点の税別の金額で、主にECサイト運営者向けのシステムを対象にしたものです。
一方、SaaS型の受発注システムのランニングコストは10〜20万円が目安とされています¹。
数千円台と十数万円台では、同じ受発注という言葉が付いていても桁が違います。

この差は値付けの良し悪しではなく、対象にしている業務の違いから出ています。
前者は自社に入ってきた注文を一か所に集めて処理することが中心で、画面を使うのは基本的に自社の担当者です。
後者は取引先が自分のアカウントで発注する仕組みを含み、取引先ごとの単価や権限の設計、基幹システムとのやり取りまで抱えます。
同じカテゴリの中でも、月額費用は月間の出荷件数や使える機能によって大きく変わるとされており²、扱う範囲が広がるほど帯は上へ動きます。

だから見積書の高い安いを判断する前に、自社がどちらの帯を見るべきかを決める必要があります。
自社の担当者だけが使い、注文の受け口をまとめたいのか。
それとも取引先に画面を開放し、注文から出荷の指示までを取引ごとに回したいのか。
後者を想定しながら数千円台の目安を基準にしてしまうと、届いた見積もりがすべて高く見えて、要件のほうを削る判断につながりかねません。

ここで示した二つの目安を足して平均を取ることにも、あまり意味はありません。
調査の時点も対象も違う数字で、片方は2025年12月時点の税別の相場、もう片方は2026年に示された目安です。
自社に近いほうを基準に置き、もう一方はこの帯は自社の話ではないと切り分けておくほうが、見積もりを受け取ったときの判断は早くなります。

システム連携・負荷分散を伴う構成の月額費用の目安

取引先に画面を開放し、基幹システムとつなぐ構成では、月額の帯はさらに上がります。
EC-Rider B2B ⅡのASP利用料金は月額170,000円からで³、負荷分散とシステム連携用の構成を採ったモデルケースでは月額260,000円が示されています³。
これは当社が公開している自社サービスの料金であり、業界の平均値ではありません。
同じサービスの中でも、基本の下限と構成を厚くした場合とで月額がどう動くかという一例として見てください。

この差を生むのは、画面に見える機能だけではありません。
月額料金はサーバー構成や各種要件の変更に伴って変動するとされています³。
取引先が朝の同じ時間帯にいっせいに発注してくるのか、基幹システムとどの頻度でデータをやり取りするのかといった裏側の条件が構成を決め、その構成が月額を決めます。
問い合わせて月額だけを尋ねても即答が返らず、先に要件を聞かれるのはこのためです。

自社がどの帯にいるのか迷うときは、取引先の側に何をしてもらうかで切ると分かりやすくなります。
注文は今まで通りメールやFAXで受け、自社側の入力と処理だけを効率化したいのか。
取引先に画面を開いてもらい、単価や在庫を見ながら自分で発注してもらうのか。
後者になると、取引先ごとの設定、権限の管理、問い合わせへの対応が増え、それを支える構成の費用が月額に乗ってきます。

見積もりを集める段階では、この順序を逆にしないことが効きます。
要件を出さないまま各社の最も安い月額だけを集めると、数字はきれいに並びますが、後から構成の追加として差が出ます。
取引先の数、ピーク時に同時に使う人数、つなぎたい基幹システムの名前とやり取りしたいデータを先に一枚にまとめ、同じ条件で各社に出してもらってください。
そろえた条件で返ってきた月額なら、帯の違いも構成の違いとして説明がつきます。

注文件数やアカウント数が変わると総費用はどう動くか

件数が少なく変動する場合の考え方

ここまでで、何に課金されるのかと、自社が見るべき価格の帯が決まりました。
残るのは、自社の件数を当てはめたときに総額がどう動くかです。
注文の件数が少なく、月ごとの振れが大きい事業では、従量課金制は使わなかった分を払わずに済みます。
受注1件ごとに5円〜35円程度という単価²であれば、動きの少ない月の加算は小さく収まります。
始めたばかりで、Webに乗る注文がどこまで伸びるか読めない時期も、支出が実際の量に連動するぶん踏み出しやすい形です。

ただし、加算が小さいことと、支払いが小さいことは同じではありません。
基本料金の上に加算される形なら、注文がほとんどなかった月でも基本料金は発生します。
料金表や見積書で、基本料金と加算分が分けて書かれているかを確かめてください。
分かれていれば、閑散期の最低の支払額がその場で計算できます。

振れの大きい事業の試算では、平均の月だけを使わないほうが実態に近づきます。
一番忙しい月と一番静かな月の両方で計算し、月額の上限と下限を出します。
そのうえで、実際に近い一年の件数の並びで12か月分を足すと、平均を12倍した数字とはずれることが分かります。
そのずれの幅が、従量課金制を選んだときに引き受ける変動の大きさです。

従量課金制で引き受けるのは、金額の変動だけではありません。
毎月の請求額が変わるため、想定より件数が伸びた月には、気づかないうちに予算を超えることがあります。
当月の件数や加算額を途中で確認できるか、上限や通知の仕組みがあるかは、契約の前に聞いておくと運用の負担が変わります。
確認する手段がなければ、請求が届いてから初めて分かることになります。

件数が多く安定している場合の考え方

反対に、月の件数が多く、月ごとの振れが小さい場合は話が変わります。
件数が多いほど加算は積み上がり、しかも毎月ほぼ同じ額になります。
月額固定制は件数が増えても金額が変わらないので、ある件数を超えたところで総額は逆転します。
ただしその分岐点は各社の単価とプランの月額によって変わるため、何件を超えたら固定制が得だと一般的な数字で言うことはできません。

そこで、自社の件数を両方の式に当てはめます。
従量課金制は基本料金に、単価と件数を掛けたものを足します。
月額固定制は、該当する段のプランの月額をそのまま置きます。
このとき使う単価と月額は、必ず自社宛の見積書の数字にしてください。
公開資料の目安、たとえば3,000円〜20,000円前後²や10〜20万円¹といった数字は、届いた見積もりが自社の要件に対して妥当な帯にあるかを見るためのもので、試算に入れる値ではありません。

月額固定制を選ぶ場合も、件数と無関係とは限りません。
プランの段が扱う規模で切られていれば、件数が増えたときに上の段へ移ることになります。
その場合に確かめたいのは、段が変わる基準と、変わったときの月額の差です。
基準が示されていれば、何件までは今の月額で回せるかが分かり、固定制でも件数の見通しを持って比べられます。

変動する要因がアカウント数の場合は、もうひとつ考えることがあります。
アカウントは業務の都合で増えていく一方、使われなくなっても登録は残りがちです。
担当者が異動した、取引が止まったといった変化を誰がいつ棚卸しするかを先に決めておくと、使っていない分の加算が積み上がったまま気づかない状態は避けられます。
これで請求が必ず下がると約束できるものではありませんが、増えた理由を説明できない加算は減らせます。

もう一点、比べる時点をいつに置くかも結論を変えます。
取引先を増やす計画や、紙とFAXで受けている注文をWebに寄せる計画があるなら、今月の件数ではなく、計画が進んだ後の件数で比べてください。
導入の直後だけを見て体系を決め、一年後にもう一方のほうが安かったと分かる順序は、試算の時点を変えるだけで避けられます。

見積もり比較で料金表以外に確認すべきこと

初期費用に含まれる費目

月額の比較が終わっても、総額はまだ決まっていません。
SaaS型の受発注システムでは、初期費用の目安として30〜50万円が示されています¹。
初期の設定、既存データの移行、取引先への案内や操作の説明といった、稼働までに一度発生する作業がここに入ります。
月額の安い見積もりでも、この部分が厚ければ最初の一年の総額は逆転します。

さらに注意したいのは、初期費用という名前の中身です。
EC-Rider B2B Ⅱの料金ページでは、初期費用がカスタマイズ開発費用(一括)とカスタマイズ年間保守費用で構成されると示されています³。
つまり、一度だけ払う分と、毎年かかる分が、同じ初期費用という欄にまとめられている場合があるということです。
ここを分けずに初期費用の合計額だけを控えると、二年目以降の総額が見積もりからずれます。

ですから見積書を受け取ったら、初期費用を費目ごとに分けて出してもらってください。
一括で終わる分はいくらで、毎年続く分はいくらか。
この二つに分けたうえで月額と加算分を足し、契約する期間の単位で年額に直します。
数え方の違う見積書を同じ表に並べられるのは、この形にしてからです。

内訳を出してもらうことには、もうひとつ実務上の意味があります。
初期費用が一式いくらという形でしか出ていないと、社内で金額の妥当性を説明できず、削れる部分も見えません。
設定の代行と、自社に合わせた作り込みと、稼働後の保守が分かれていれば、どれを自社で引き受けてどれを頼むかという相談ができます。
金額そのものを下げてほしいと頼む前に、範囲を動かせる形にしておくほうが、結果として社内での説明もしやすくなります。

最低契約期間・解約条件は個別確認が必要

総額を組み立てる最後の欄が、契約の条件です。
今回確認した各社の公開されている料金ページでは、月額や初期費用までは読み取れましたが、最低の契約期間や解約したときの扱いについての記載は見当たりませんでした。
期間の長さや違約金の水準をここで示すことはできないので、見積もりのときに個別に聞く項目として扱います。

なぜここが総額に効くのかは、比べる単位を考えると分かります。
月額が同じ二社でも、一方が期間の定めのない契約で、もう一方が一定期間の継続を前提にした契約なら、比べるべきなのは月額ではなく、その期間分の総額です。
加えて、合わなかったときに止められるかどうかで、導入の進め方そのものが変わります。
一部の取引先から小さく始めて様子を見たい場合と、全取引先を数年かけて移す前提の場合とでは、有利な契約条件が違うからです。

見積もりを依頼するときに、料金表と一緒に書き添えてもらうと後で比べやすい項目があります。
契約期間の単位と更新の仕方、期間の途中で解約した場合の扱い、料金体系や段の変更ができるかとその適用の時期、料金の改定があるときの知らせ方です。
いずれも料金表には載らないことが多く、担当者の口頭の説明だけでは、社内で共有した時点で抜け落ちます。
見積書の欄として残してもらえば、月額と初期費用と契約条件を一枚で見比べられます。

料金体系は、どちらかが優れているという話ではありません。
自社で動くのが人の数か注文の数か、その幅はどれくらいか、初期費用のうち毎年かかる分はいくらか、契約の期間はどうなっているか。
この四つを同じ表に置けば、数え方の違う見積書でも同じ土俵に並びます。

公開されている料金ページから読み取れるのは月額と初期費用の範囲までで、取引先の数やつなぎたい基幹システムを当てはめた実際の月額は、構成が決まらないと出ないためです。

月間の注文件数、Webで発注してもらう取引先の数、連携したい基幹システムをお伝えいただければ、どの構成でいくらになるのか、初期費用のうち一括の分と毎年かかる分がどう分かれるのかを確かめられます。無料相談で要件を整理する

見積もりを依頼する前に自社側で確定させておく数字

見積書の金額を組み立てるのに必要な順で、自社だけで確定できるものから並べています。

• 直近12か月の月間受注件数のうち、最も多い月と最も少ない月

• Webで発注してもらう取引先の数と、取引先側で使う担当者アカウントの数

• 自社で画面を使う担当者の数と、扱う部署の範囲

• つなぎたい基幹システムと、やり取りしたいデータの種類

• 稼働させたい時期と、契約期間として想定できる長さ

取引先の数や件数が今後大きく動く見込みなら、現在の実績ではなく計画が進んだ後の数字を上限として置き、上限と下限の二通りで出してもらってください。

要点の整理

軸	基準
課金の対象	月額固定制は使える機能の範囲、従量課金制はアカウント数か受注件数といった処理量
体系の選び方	自社で増減するのが人の数か注文の数か、その幅がどれくらいか
月額の帯	対象とする業務の範囲で目安が変わるため、自社に近い帯で妥当性を見る
試算の入力値	公開資料の目安ではなく、自社宛の見積書の単価と月額を使う
初期費用	一括で終わる分と毎年かかる分に分け、月額と足して年額に直す
契約の条件	期間・解約・体系の変更は料金表に載らないことが多く、見積もり時に確認する

最低の契約期間や解約したときの扱い、料金体系を後から変えられるかどうかは料金表に載らないことが多く、自社だけで見積書を並べても差が見えないためです。 想定する件数とアカウント数で年額を試算したうえで、契約の期間や見直しの条件まで含めて、いま手元にある見積もりと同じ表に並べられる形でお渡しします。

よくある質問

受発注システムの初期費用は分割払いや値引き交渉ができるのか

分割にできるかどうかは契約の条件によるもので、今回確認した公開されている料金ページからは読み取れませんでした。
可否はそのまま質問する項目になります。
そのうえで交渉の材料になるのは、初期費用の内訳です。
初期費用がカスタマイズ開発費用(一括)とカスタマイズ年間保守費用で構成される場合があるように³、性質の違う費目がひとつの欄にまとめられていることがあります。
設定の代行、データの移行、自社向けの作り込み、稼働後の保守と分けて出してもらえば、どの範囲を今回は見送るかという話ができます。
金額を一律に下げてほしいと頼むより、範囲を動かすほうが相手も答えやすく、社内でも説明しやすくなります。

小規模な取引件数でも従量課金制を選ぶメリットはあるのか

件数が少なければ加算も小さく収まります。
受注1件ごとに5円〜35円程度という単価²で考えると、動きの少ない月の負担は限られます。
件数がこれからどう伸びるか読めない段階で、支出が実際の量に連動する形は取りやすい選択です。
ただし確かめるべきは、基本料金が別にあるかどうかです。
基本料金の上に加算される形なら、注文がほとんどなかった月でも下限の金額は発生します。
加算だけの構成なのか、下限があるのか。
この一点で、件数の少ない時期の実際の支払額は大きく変わります。

月額固定制から従量課金制への途中変更はできるのか

できるかどうかは各社の契約条件で決まり、今回確認した公開されている料金ページには記載がありませんでした。
断定できないぶん、見積もりの段階で聞いておくと選び方そのものが変わります。
途中で変えられるなら、件数が読めない時期は動きに合わせた体系で始め、安定してから固定制へ移すという進め方ができます。
変えられないなら、最初から計画が進んだ後の件数で比べる必要があります。
あわせて、変更を申し出てからいつの請求分に反映されるのか、段の上下と体系の変更で扱いが違うのかも確認しておくと、切り替えの時期を業務の繁忙と重ねずに済みます。

無料トライアルは費用比較の判断材料になるのか

操作のしやすさや、自社の運用に必要な機能が揃っているかを見るには役立ちます。
ただし費用の判断材料としては、期間中の件数がそのまま請求の目安にはならない点に注意してください。
試用の期間は扱う注文が限られ、取引先も全部は入っていないことが多いので、従量課金制の加算額は本番より小さく出ます。
費用を判断したいなら、試用で確かめるのは機能と運用の手間に絞り、金額のほうは繁忙期の件数と取引先の数を見積書の単価に当てはめて計算するほうが確実です。
加えて、試用で使えている機能が契約後のどの段に当たるのかも聞いておくと、想定していた月額と違ったという食い違いを防げます。

1. 1　出典：株式会社竹田印刷（TS-BASE運営）「Webの受発注システムの選び方とコストの目安」（2026年）
2. 2　出典：GoQSystem「受注管理システムの料金相場に関する解説記事」（2025年）
3. 3　出典：株式会社フライトソリューションズ「EC-Rider B2B Ⅱ 料金プラン・費用ページ」（2026年）