受注管理システムの選び方：件数の目安と「上限」の読み方、取引先の注文方法まで

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

B2B EC-COLUMN

注文が増えて入力・確認が追いつかないとき、件数よりどんな負荷を先に数えるか

取引先からの注文が増えると、FAXの読み取り、メールからの転記、締め時間前の確認が追いつかなくなります。
そうなると、受注管理システムを入れるべきか、今のやり方で何件まで回せるのかが気になってきます。
ただ、何件を超えたら導入すべきという共通の目安は示されていません。
見直す時期は、件数の合計よりも、取引先ごとの注文経路、1注文あたりの明細数、締め時間への集中、出荷や請求への転記の多さで判断できます。
製品の「上限」については、何を数えるのか（例：伝票の明細件数の合計）と、超えたときの追加手段と費用を契約前に確かめることが判断の中心になります。

取引先別の注文経路を並べる

月に何件の注文があるかという数字は分かりやすいものの、受注入力の重さをそのまま表してはいません。
同じ件数でも、ほとんどがEDIで届く会社と、多くがFAXで届く会社とでは、担当者が毎日していることがまったく違います。
EDIとは、企業間で取り決めた形式の注文データを電子的にやり取りする仕組みです。
データのまま届く注文は確認が中心になりますが、紙や画像で届く注文は、読み取って打ち込むところから始まります。

そこで最初に作りたいのは、月間の合計件数ではなく、取引先ごとの一覧です。
一行に一社を置き、次のような項目を並べます。

• 注文が届く経路（EDI、Web発注、メールの添付ファイル、メール本文、FAX）
• 月あたりのおおよその注文件数
• 注文書の書式が取引先のものか、自社が渡したものか
• 経路や書式の変更を相談できる関係かどうか

取引先ごとに分けるのは、経路を変える相談が一社ずつの話になるからです。
合計だけを見ていると、FAXで届く注文がどの取引先に偏っているのか、誰に何を頼めば入力が減るのかが分かりません。
同じ取引先がFAXとメールを使い分けている場合もあるので、経路は取引先の中でも分けて書いておくと、後で受け方を決めるときに迷いません。

発注側の都合は、この一覧にいちばんはっきり出ます。
取引先が自社の購買の仕組みに合わせて経路を決めているなら、受注側はそれに合わせて受けるしかありません。
反対に、慣れで続いているFAXなら、相談の余地があります。
どちらに当たるかを一覧に残しておくことが、次の節で受け方を決める材料になります。

1注文あたりの明細数と締め時間を数える

明細とは、1枚の注文の中にある商品ごとの行のことです。
1注文に商品が1行だけなら入力も照合もすぐ終わりますが、1注文に数十行あると、商品コード、数量、単価、納期を行ごとに確かめる必要があります。
注文件数が増えていなくても、1注文あたりの明細が増えれば、入力と確認の手間は増えます。

明細数は、手間の物差しであると同時に、製品の上限を読むときの物差しにもなります。
後で触れるように、製品によっては上限を注文の数ではなく明細の件数で数えているためです。
取引先一覧に、1注文あたりのおおよその明細数を書き足しておくと、入力の負荷と上限の見積もりを同じ表から出せます。

もう一つ数えたいのが、締め時間への集中です。
当日出荷の締めが決まっていると、その直前に届く注文が確認漏れや出荷遅れの原因になりやすくなります。
1日の平均件数では余裕があるように見えても、締めの前の時間帯に注文が重なれば、その時間だけは人手が足りません。

集中の度合いは、注文を受け付けた時刻を時間帯ごとに分けて数えると見えてきます。
繁忙期を含めて数えると、平常時の数字だけでは見落とす山が分かります。
この山の高さは、システムを入れた後に同時に何人が入力できる必要があるか、という確認にもつながります。

出荷・請求への連携の手間を見る

受注の仕事は、注文を受けて入力したところで終わりません。
その内容をもとに出荷指示を出し、出荷が済んだら請求の準備をします。
受注の表計算、出荷指示の書類、請求の仕組みがそれぞれ別になっていると、同じ取引先名、商品、数量を何度も書き写すことになります。

ここで数えるのは、1件の注文がいくつの画面やファイルを通り、そのうち何回人の手で書き写されているかです。
たとえば、受注の表から出荷指示書へ数量を写し、出荷後に請求の表へもう一度写しているなら、転記は2回です。
転記の回数が多いほど、写し間違いを探す確認も増えます。

受注から出荷指示、請求までが一つの仕組みでつながると、こうした転記の一部は要らなくなります。
ただし、取引先が頼んだ商品と数量を正しく受け取れているかという確認は、つながった後も残ります。
システムを入れて減るのは書き写しとその照合で、注文内容そのものの確認がなくなるわけではありません。
この区別をしておくと、導入後に期待する効果を現実に合わせて見積もれます。

ここまでの四つ、つまり経路、明細数、締め時間への集中、後続への転記をそろえると、どこで困り事が起きているのかが件数の合計よりはっきりします。

▼ 図の内容を文字で読む

1. 取引先別の注文経路
   • FAXやメールは受注入力の手作業に出る
   • 経路の数だけ受け付けの確認先が増える
2. 1注文あたりの明細数
   • 入力と照合の時間に出る
   • 製品の明細上限の消費に出る
3. 締め時間への集中
   • 確認漏れや出荷遅れに出る
   • 同時に入力する人数に出る
4. 出荷・請求への連携
   • 同じ内容の転記回数に出る

取引先の注文方法（EDI・Web発注・メール・FAX）がばらばらなとき、受注側の選定条件はどう変わるか

経路ごとの受け方（自動取込・取込補助・手入力）

取引先一覧ができると、経路ごとに注文をどう受けるかを決められます。
受け方は大きく三つに分けられます。

• 自動取込：取引先から届いたデータを、人が打ち直さずにシステムへ入れる受け方
• 取込補助：届いたファイルの列とシステムの項目を対応させて読み込み、ずれた所を人が直す受け方
• 手入力：紙や画像の注文を人が読み、画面に打ち込む受け方

EDIやWeb発注のように、注文がはじめからデータで届く経路は、自動取込の候補になります。
メールに表計算のファイルが添付されている場合は、取引先ごとに書式が違うことが多く、取込補助で項目を合わせる形になりやすいところです。
メール本文に書かれた注文やFAXは、多くの場合、手入力で受けることになります。

どの受け方でも、受け取った後の確認は残ります。
自動取込では、取引先の商品コードと自社の商品コードの対応、単価の一致を確かめます。
取込補助では、書式の違いを吸収できているか、項目の照合が要ります。
手入力では、読み違いと打ち間違いの照合が中心です。
経路によって残る確認の種類が違うので、どこに人手を残すかも経路ごとに決まります。

製品を選ぶときに気を付けたいのは、どの伝票を扱えるかと、どの経路から注文を取り込めるかが別の情報だという点です。
たとえば商奉行iクラウド・蔵奉行iクラウドの料金ページでは、商奉行iクラウドが受注・売上・債権・入金の各伝票、蔵奉行iクラウドが発注・仕入・債務・支払・入荷・出荷・倉庫振替などの伝票を対象とすると記されています¹。
これは製品が扱う業務の範囲を示すもので、EDIやメールの添付ファイルをどう取り込めるかまでは、この記載からは分かりません。
経路ごとの取込方法は、自社の経路一覧を見せたうえで、製品ごとに確かめる必要があります。

取引先に変更を頼める経路と頼めない経路

経路の中には、受注側が変えられないものがあります。
取引先が自社の購買の仕組みで発注していて、EDIの形式や発注画面を指定している場合、受注側はその形式に合わせて受けることになります。
こうした経路は、受注側が選ぶシステムがその形式を受けられるかどうかが、そのまま選定の条件になります。

一方で、FAXやメール本文の注文は、取引先の担当者の慣れで続いていることもあります。
こちらは、自社が用意したWeb発注の画面や決まった書式のファイルに切り替えてもらえる余地があります。
ただし、切り替えるかどうかを決めるのは取引先です。
頼めば必ず変わるものとして選定の前提にすると、変わらなかったときに手入力が残ります。

そこで、取引先一覧の「変更を相談できるか」の欄を使って、経路を二つに分けます。
変えられない経路は、導入するシステムで受けられなければならない条件です。
変えられるかもしれない経路は、当面は今の受け方で受けつつ、導入後に相談していく対象です。
この分け方をしておくと、すべての経路に対応した製品を探す必要がなくなり、選定の条件が絞られます。

相談の順番を決めるときは、FAXやメールで届く注文のうち、件数が多い取引先や、1注文あたりの明細が多い取引先から考えると、切り替わったときに減る入力が大きくなります。
明細が多い注文は打ち込みにも照合にも時間がかかるので、件数が少なくても優先度が上がることがあります。

受注管理システムの「件数の上限」は何を数えていて、超えるとどうなるか

上限の単位を確認する（明細件数・注文数・ユーザー数・データ量・API回数）

製品の料金表に「上限」と書かれていても、何を数えているかは製品ごとに違う可能性があります。
注文1件を1と数えるのか、注文の中の明細を1行ずつ数えるのかで、同じ業務量でも消費の仕方が大きく変わります。

例として商奉行iクラウド・蔵奉行iクラウドでは、プランごとに明細上限が定められていて、これは各伝票の明細件数の合計に対する上限とされています¹。
注文の件数ではなく明細の件数で数え、しかも受注伝票だけでなく複数の種類の伝票の明細を合計する考え方です。
これはこの製品の仕様であり、他社の製品が同じ数え方をしているとは限りません。

上限の単位として確かめたいものは、次のとおりです。

• 明細件数：注文の中の商品行を数えるか、どの伝票の明細が合計に入るか
• 注文数・伝票数：注文1件や伝票1枚を単位にするか
• ユーザー数：同時に、または合計で何人が使えるか
• データ量：保存できる容量に制限があるか
• API回数：他の仕組みとデータをやり取りする回数に制限があるか

ユーザー数は、件数の上限とは別の制限です。
商奉行iクラウド・蔵奉行iクラウドの各プランは、標準構成が利用者1ライセンスと専門家1ライセンスとされ、2ライセンス以上の用意もあると記されていますが、超えたときの料金や扱いは料金ページには書かれていません¹。
前の節で数えた締め時間への集中が大きく、締めの前に複数の担当者が同時に入力する必要があるなら、明細の上限に余裕があっても、ライセンスの数が足りるかを別に確かめることになります。

超過時の追加手段と費用を確認する

上限を超えそうなときにどうなるかも、製品ごとに確かめる項目です。
商奉行iクラウド（単体）では、Eシステムが50,000明細、Jシステムが100,000明細、Aシステムが400,000明細と、プランによって明細上限が段階的に分かれています¹。
上限を超える場合は拡張パックで明細数を追加できるとされていますが、拡張パックの料金は記載がなく、問い合わせが必要です¹。

この例から分かるのは、上限に近づいたときの手段が少なくとも二つあり得るということです。
一つは上の段階のプランへ移ること、もう一つは今のプランのまま拡張で明細数を足すことです。
どちらが自社に合うかは、拡張の料金とプラン変更の料金を並べないと決められません。
拡張の料金が公開されていない以上、見積もりを取ってから比べるしかありません。

もう一つ、料金ページからは読み取れない点があります。
この明細上限が年間、月間、契約期間の累計のどれに適用されるのかは、ページ上で確認できません。
年間や月間であれば、期間が変わるたびに数え直しになります。
累計であれば、過去に入力した明細も上限の中に積み上がっていきます。
どちらかで、同じ業務量でも上限に当たる時期が大きく変わるため、契約前にベンダーへ確かめたい点です。

自社の年間の明細件数を概算する

上限と比べるには、自社の明細件数を製品の数え方に合わせて概算する必要があります。
最初の節で作った取引先一覧に、月あたりの注文件数と1注文あたりの明細数があれば、次の式で見当を付けられます。

月間の注文件数 × 1注文あたりの平均明細数 × 12か月 ＝ 年間の受注明細件数

ここで注意したいのは、上限が複数の伝票の明細の合計で数えられる場合です。
受注した明細が出荷後に売上伝票にも計上されるなら、同じ商品行が受注と売上の二つの伝票に現れます。
その場合、受注明細だけで見積もると、実際の消費は少なく見えてしまいます。
受注から売上へ伝票を引き継いだとき、明細が何件分として数えられるかは、ベンダーに確かめる点です。

仮の数字で考えてみます。
月に400件の注文があり、1注文の明細が平均5行だとすると、受注伝票の明細は月2,000件、年24,000件です。
同じ明細が売上伝票にも計上されると、合計は年48,000件になります。
上限が年単位で数えられる場合、Eシステムの50,000明細にかなり近い数字です。
入金などほかの伝票の明細も合計に入るなら、さらに上に積み上がります。

この例で見たいのは、注文件数の印象と明細件数の合計が大きく離れることがある、という点です。
概算するときは、平常月だけでなく繁忙月の件数も使い、増え方の見通しを足して、上限までの余裕を見ます。
取引先が新たに加わる予定や、明細の多い取引先が増えそうな事情があれば、その分も見込んでおくと、契約した後で上限に当たる心配を減らせます。

出典：株式会社オービックビジネスコンサルタント（OBC）「商奉行iクラウド・蔵奉行iクラウド 料金ページ」（2026-10-29取得・商奉行iクラウド（単体）。2026年10月閲覧。）

自社の件数と増え方に合うのは、表計算の改善・小規模向け・拡張性重視のどれか

3つの選択肢を同じ軸で比べる

ここまでで、取引先ごとの経路、明細数、締め時間への集中、転記の回数、そして製品の上限の読み方がそろいました。
これを使うと、表計算のやり方を改善する、小規模向けのシステムを入れる、拡張性を重視したシステムを入れる、という三つの選択肢を同じ軸で比べられます。
比べる軸は次の四つです。

• 取込経路への対応：変えられない経路を受けられるか
• 上限の単位と拡張手段：自社の明細概算に対して余裕があるか、超えたときに足せるか
• 連携の範囲：受注から出荷指示、請求までの転記がどこまで減るか
• 移行の手間：今の入力の仕方や取引先の経路をどこまで変える必要があるか

表計算の改善は、取引先ごとの入力書式をそろえる、入力できる値を絞る、出荷指示への転記を減らす工夫をする、といった方向です。
経路の多くを取引先と相談して変えられ、明細も多くなく、締めの前に何人もが同時に入力する必要がない場合は、検討の余地があります。
一方で、受注から請求までの転記がすべてなくなるわけではなく、複数人の同時編集や入力履歴の管理をどこまで続けられるかは、自社の使い方で見極めることになります。

小規模向けのシステムは、受注から後の伝票まで一つの仕組みでつなぎ、転記を減らしたいときの選択肢です。
例として商奉行iクラウドでは、Eシステムがスモールスタート向け、Jシステムが小規模企業向けと明記され、単体の月額料金はEシステムが7,340円〜、Jシステムが10,000円〜とされています¹。
これは一つの製品の価格であり、受注管理システム全体の相場を示すものではありません。
この製品の場合、前の節の概算で見たように、明細の数え方によっては小規模向けの段階でも上限に近づくことがある点を、選ぶ前に照らしておきたいところです。

拡張性を重視したシステムは、明細の上限が大きい段階や、取込経路や連携の範囲が広い構成を選ぶ方向です。
同じ商奉行iクラウドでも、A〜Sシステムは対象規模の明記がありません¹。
規模の名前で選ぶのではなく、自社の明細概算と増え方の見通しから、どの段階の上限が要るかで選ぶことになります。
契約は法人単位の年間契約とされているので¹、選んだ段階が1年間の前提になる点も比較に入れておきます。

三つの選択肢には、それぞれが合う条件があり、どれが優れているという順位はありません。
判断が分かれるのは、変えられない経路が多いか、明細の概算が上限に近いか、転記がどこで発生しているかです。

増え方の見通しとプラン変更の余地

今の件数で選んだシステムが、1年後、2年後も合うとは限りません。
注文の増え方が緩やかなら、上限の段階を一つずつ上げていけば足りるかもしれません。
大きな取引先が新たに加わる予定があるなら、件数だけでなく、その取引先の経路を受けられるかどうかという条件が変わります。

そのため、選ぶときには、いまの上限だけでなく、上の段階に移れるか、年間契約の途中でも移れるのか、移ったときに入力済みのデータはどう扱われるのかを確かめておきます。
年間契約であることは料金ページに記されていますが¹、契約期間の途中でプランを変えられるかどうかは、そこからは分かりません。

上限との付き合い方は、一度決めて終わりではなく、繰り返し見直すものです。
実際の明細件数を数え、製品の上限の単位と期間に換算し、上限までの余裕と増え方を比べ、必要ならプラン変更か拡張かを決めます。
そして次の契約更新の前に、もう一度数えます。
年間契約であれば、更新の前が見直しの区切りになります。

▼ 図の内容を文字で読む

1. 実際の明細件数を数える
2. 上限の単位と期間に換算する
3. 上限までの余裕と増え方を比べる
4. プラン変更か拡張かを決める
5. 契約更新の前に再び数える

上限に当たりそうな製品かを導入前にどう確認し、移行時に取引先へ何を頼むか

ベンダーへ確認する質問リスト

候補の製品がしぼれたら、取引先一覧と明細の概算を手元に置いて、ベンダーへ質問します。
料金ページに書かれていないことは、聞かなければ分かりません。
実際に、商奉行iクラウド・蔵奉行iクラウドの料金ページでも、拡張パックの料金とユーザー数を超えたときの扱いは記載がなく、問い合わせが必要です¹。

質問は、上限の単位、超えたときの手段と料金、プラン変更の条件、取込に対応する経路の四つに分けておくと、複数の製品の回答を並べて比べやすくなります。

• 上限は何を単位に数えるか（明細、伝票、注文）。
  明細なら、どの種類の伝票の明細が合計に入るか
• 受注から売上へ伝票を引き継いだとき、明細は何件分として数えられるか
• 上限は年間、月間、累計のどれに適用されるか
• 上限を超えたときの手段は何か（拡張、上のプランへの変更）。
  それぞれの料金はいくらか
• 契約期間の途中でプランを変えられるか。
  変えたときにデータはどう扱われるか
• ユーザー数、データ量、API回数に別の制限はあるか。
  超えたときの扱いはどうなるか
• 自社の経路一覧にあるEDI、Web発注、メールの添付ファイルを、それぞれどの方法で取り込めるか

質問のときに自社の数字を見せると、回答が具体的になります。
年間の明細概算、繁忙月の件数、締めの前に同時に入力する人数、変えられない経路の形式を伝えたうえで、その条件でどのプランが合うか、拡張が要りそうかを聞くと、料金の見積もりも同じ条件で比べられます。

取引先への依頼の順序と確かめ方

新しいシステムへ移るとき、取引先にお願いすることが出てくる場合があります。
ただ、受注側の都合で発注側の手順を変えてもらうことになるので、一度にすべての取引先へ頼むより、順序を決めて進めるほうが、混乱を抑えやすくなります。
次の順序は、そのための一つの進め方です。

1. 変えられない経路は、そのままの形式で受けられることを先に確かめる
2. FAXやメールで届く取引先のうち、切り替わったときに減る入力が大きい相手から、経路の変更を相談する
3. 応じてもらえた取引先と、切り替え前に試しの注文を送ってもらい、内容が正しく取り込めるかを確かめる
4. 切り替える日を決めて伝え、切り替えた後もしばらくは以前の経路で届いた注文も受け付けられるようにしておく
5. 以前の経路で注文が届かなくなったことを確かめてから、その経路の受け付けをやめる

試しの注文で確かめたいのは、商品コードの対応、数量や単価、納期が正しく入るかです。
ここで食い違いが見つかれば、本番の注文が流れ始める前に直せます。
以前の経路を一定期間残すのは、取引先の担当者が変わっていたり、切り替えの連絡が社内で行き渡っていなかったりして、古い経路で注文が届くことがあり得るためです。

取引先が経路の変更に応じない場合もあります。
その場合は、その取引先の注文を当面は今の受け方で受け続けると決め、受け取った後の確認を手順として残しておけば足ります。
最初の節で作った取引先一覧に、切り替えた日と、残している経路を書き足しておくと、次の見直しのときにどこで手入力が残っているかがすぐに分かります。

取引先ごとの経路や明細数を社内だけで洗い出すと、今の書式や慣れに引っ張られ、変えられる経路と変えられない経路の区別があいまいになりがちです。

取引先一覧と年間の明細概算をもとに、どの経路をそのまま受ける必要があるか、候補の製品に何を質問すべきかを一緒に整理できます。無料相談で要件を整理する

要点の整理

見直しの合図	件数の合計ではなく、経路・明細数・締め時間への集中・転記の回数で判断する
経路	取引先が変えられない経路を受けられるかを先に確かめる
上限の単位	明細・伝票・注文・ユーザー数・データ量・API回数のどれで数えるか
上限の期間	年間・月間・累計のどれに適用されるか
超過時	プラン変更と拡張の手段と料金を、同じ条件の見積もりで比べる
移行	経路の変更は減る入力が大きい取引先から、試しの注文で確かめて進める

上限の期間や拡張の料金は見積もりを取らないと分からず、複数の製品を同じ条件で比べにくいところです。 自社の明細概算と経路の条件でベンダーへの質問をそろえ、返ってきた回答をどの観点で比べればよいかを確かめられます。

よくある質問

表計算のまま受注を続けられるかどうかは、何で判断すればよいですか。

件数の合計よりも、取引先ごとの注文経路、1注文あたりの明細数、締め時間への集中、出荷や請求への転記の回数で判断します。
経路の多くを取引先と相談して変えられ、明細が少なく、同時に何人も入力する必要がなければ、書式の統一や転記の削減で続ける余地があります。
変えられない経路が多い、締め前に入力が重なる、受注から請求まで何度も書き写している、といった状態なら、システムを検討する理由になります。

件数上限が「明細件数」の場合、自社の年間の明細数はどう概算しますか。

月間の注文件数に1注文あたりの平均明細数を掛け、12か月分にします。
上限が複数の伝票の明細の合計で数えられる場合は、受注の明細が売上伝票などにも計上される分を足します。
繁忙月の件数と増え方の見通しも入れ、上限が年間・月間・累計のどれに適用されるかを確かめてから比べます。

上限を超えたときに、プラン変更と拡張オプションのどちらを選べばよいですか。

両方の料金を同じ条件で並べてから決めます。
例として商奉行iクラウド・蔵奉行iクラウドでは、拡張パックで明細数を追加できますが、料金は問い合わせとされています¹。
増え方が続きそうなら上の段階への変更、一時的な山なら拡張、という考え方もありますが、契約期間の途中で変えられるかどうかも含めてベンダーに確かめてから判断します。

取引先がFAXやメールをやめてくれない場合、受注側の取込運用はどうしますか。

その取引先の注文は、当面は手入力や取込補助で受け続けると決めます。
そのうえで、受け取った後に読み違いや項目のずれを照合する手順を残しておきます。
経路を変えるかどうかは取引先が決めることなので、変わる前提で選定しないことが大切です。

移行中に旧運用と新システムを並べる期間を設けるべきですか。

切り替えた後もしばらくは以前の経路で届いた注文を受け付けられるようにしておくと、連絡が行き渡らずに古い経路で届いた注文を取りこぼしにくくなります。
どのくらいの期間を置くかは、取引先の数や切り替えの進み方によって変わります。
以前の経路で注文が届かなくなったことを確かめてから、受け付けをやめると判断しやすくなります。

ユーザー数やAPI回数の制限は、件数上限とは別に確認すべきですか。

別に確認します。
明細の上限に余裕があっても、締め前に同時に入力する人数がライセンス数を超えれば作業が滞ります。
例として商奉行iクラウド・蔵奉行iクラウドの標準構成は利用者1ライセンスと専門家1ライセンスで、超えたときの料金や扱いは料金ページに記載がありません¹。
他の仕組みとデータをやり取りするなら、API回数の制限の有無も質問に入れておきます。

1. 1　出典：株式会社オービックビジネスコンサルタント（OBC）「商奉行iクラウド・蔵奉行iクラウド 料金ページ」（2026年閲覧）