受注管理システムの選定は「件数」でなく「明細数」で測る：上限・課金単位・種類の比べ方

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

B2B EC-COLUMN

受注管理システムの上限と比べるために、最初に数える3つの数字

注文書やFAXを見ながらExcelへ打ち込み、出荷指示や請求書へ書き写す作業が追いつかなくなると、「何件まで扱えるシステムなら上限に引っかからないのか」と考えたくなります。
ところが、料金表を確かめた販売管理の製品では、上限は注文の件数ではなく、品目ごとの行である「明細」の数で区切られていました。
受注件数に1件あたりの平均明細行数を掛けた月間・年間の明細数とピークを先に数えます。
そのうえで、課金の単位、超過したときの扱い、移行や連携の条件を製品ごとに聞いていけば、自社の規模に合う受注管理システムの選択肢は絞れます。

月間・年間の明細行数

得意先から届く注文書1枚を受注1件と数えても、品目が5つ並んでいれば、システムの中には5行の明細が記録されます。
受注管理や販売管理のシステムは、この行を単位に伝票を積み上げていきます。
同じ「月300件」でも、1件に1品目しか載らない会社と、1件に10品目以上が並ぶ会社とでは、システムに入るデータの量が大きく違います。

料金表を確かめた商奉行iクラウド（OBC）では、上限が件数ではなく「各伝票明細件数合計」で示されています。
Eシステムは50,000明細まで、Jシステムは100,000明細まで、Aシステムは400,000明細までという表記です¹。
この表と自社を比べるには、「受注件数」を「明細数」に置き直す必要があります。

置き直す作業そのものは難しくありません。
Excelの受注台帳や保管している注文書から、直近数か月分の受注件数と明細行数を拾い、明細行数を件数で割って1件あたりの平均行数を出します。
たとえば月300件、平均4行という仮の数字なら、受注の明細は月1,200行、年間で14,400行です。
FAXやメールで受けている会社でも、注文書の行数を数か月分だけ手で数えれば足ります。

ただし、この数字は最小値として持っておくのが安全です。
上限の表記は「各伝票」の明細の合計なので、受注伝票の1行が出荷や売上、請求の伝票にも引き継がれる運用なら、同じ品目が伝票ごとに数えられる可能性があります。
先の例で受注と売上の2種類の伝票が数えられるとすれば、年間は28,800明細になります。
どの伝票を合算するのか、上限が1年あたりの量なのか保存している明細の累計なのかは表の文言だけでは読み取れません。
自社の伝票の流れを並べたうえで提供者に数え方を聞くと、見積もりの幅が狭まります。

ピーク月と増加見込み

年間の合計だけでは、判断に必要な情報が半分しかありません。
決算前の駆け込み注文や季節商品の出荷期など、受注が集中する月の明細数を別に控えておきます。
上限が1年あたりの量で決まる仕組みなら、ピークは年間の合計に吸収されます。
月単位や保存件数で数える仕組みなら、繁忙月にだけ余裕がなくなる事態も起こり得ます。
数え方が分からない段階では、平常月とピーク月の両方の数字を持っておくと、どちらの説明を受けても自社に当てはめられます。

もう一つは、これから増える分です。
商奉行iクラウドの契約は法人単位の年間契約です¹。
月額で表示されていても契約の区切りは1年なので、契約した時点の明細数ではなく、次の更新までにどこまで増えるかで段階を選ぶことになります。
新しい得意先との取引開始が決まっている、取扱品目を増やす予定があるといった具体的な見込みがあれば、その分の件数と行数を足した数字を「1年後の見込み」として横に並べます。

取引先数と条件の種類

3つ目は量ではなく、取引条件の数です。
得意先の数、得意先ごとに違う単価表や掛け率（定価に掛けて卸価格を出す率）の種類、20日締め・末締めといった締め日の種類、一つの注文を何回かに分けて出荷する分納の頻度を書き出します。
明細数が少なくても、得意先ごとに単価の決め方が違えば、システムがその違いを持てるかどうかで入力の手間が大きく変わります。

明細数は「どの段階の契約に収まるか」を決める数字で、条件の種類は「その製品で手作業が残らないか」を決める数字です。
前者は料金表で比べられますが、後者は料金表に載らないことが多く、別の確かめ方が要ります。
まずは明細数の側から、料金表をどう読むかを見ていきます。

▼ 図の内容を文字で読む

1. 受注件数
   • 注文書1枚を受注1件と数える
2. 受注明細数
   • 平均明細行数を掛けて出す
   • 最小値として持っておく
3. 各伝票明細件数合計
   • 出荷や売上、請求の伝票にも数えられる可能性がある
   • 1年あたりか累計かは表の文言だけでは読み取れない
4. 上限と比べる
   • 数え方は提供者に聞く

上限と課金単位の読み方：明細・ユーザー・契約単位・超過時

明細上限の表の読み方

商奉行iクラウド（単体）の料金表では、段階ごとに月額、初期費用、明細上限が1行に並んでいます。
スモールスタート向けとされるEシステムは月額7,340円〜、初期費用0円で50,000明細まで。
小規模企業向けのJシステムは月額10,000円〜、初期費用50,000円で100,000明細まで。
「受注・請求・入金処理を効率化したい方」向けとされるAシステムは月額18,750円〜、初期費用50,000円で400,000明細までです¹。
いずれも2026年11月時点の表示です。

読むときに気を付けたいのは、金額に付いた「〜」です。
表示は最低価格で、見積の額そのものではありません¹。
EからJで上限は2倍、JからAで4倍になりますが、月額は同じ比率では増えていません。
ただし、これは表示上の最低額どうしの比較で、実際の見積額の差とは別のものです。

もう一つは、段階の説明が規模だけで書かれていない点です。
EとJは「スモールスタート」「小規模企業」と規模で説明されていますが、Aは「受注・請求・入金処理を効率化したい方」と業務の範囲で説明されています¹。
このため、段階の違いが明細上限だけとは限りません。
自社の明細数がJに収まっても、受注から請求、入金までを一つの仕組みで扱いたいなら、その処理がどの段階に含まれるかを確かめておかないと、上限だけで選んだ結果、必要な処理が上の段階にしかなかったということになりかねません。

同じ表には、蔵奉行と組み合わせた商蔵奉行iクラウド（セット）も載っています。
セットのJシステムは月額18,000円〜で、明細上限は単体のJと同じ100,000明細です¹。
製品を組み合わせても上限の数字は単体と同じ表記なので、2つの製品の伝票が同じ上限の中で数えられるのか、製品ごとに数えられるのかで、余裕の見え方が変わります。

ユーザー数と契約単位

明細の次に効いてくるのが、使う人の数です。
Eシステムの条件には利用者1・専門家1と表記されています¹。
受注の入力を1人で担っているうちは足りても、繁忙月に2人目が入力に加わる、出荷担当が受注の内容を照会するといった使い方を考えると、明細より先に利用者の枠が足りなくなることがあります。
料金表には2ライセンス以上の構成も用意されていると書かれています¹。
利用者を増やしたときに月額がいくら変わるかは、料金表から金額まで読み取れないため、見積で確かめる部分です。

契約単位にも目を向けておきます。
契約は法人単位の年間契約です¹。
営業所ごとに受注を受けていても同じ法人なら一つの契約にまとまると読めますが、グループ会社が別法人で受注している場合は、それぞれの扱いを確かめる必要があります。
年間契約なので、途中で段階を上げられるか、下げられるかも、明細数の見込みに自信がないときほど大事な条件です。

超過時は拡張パックで追加、価格は要問い合わせ

「上限を超えたらどうなるのか」は、選定で最も気になる点の一つです。
商奉行iクラウドの料金表では、明細数は拡張パックで追加できると書かれていますが、その価格は載っていません¹。
少なくともこの製品では、上限に達したら上の段階へ乗り換えるしか手がない、という仕組みではないことが読み取れます。
一方で、上限に達した時点で入力が止まるのか、自動で追加料金が発生するのか、事前に申し込む必要があるのかは、表からは分かりません。

ここから言えるのは、上限そのものより、超えたときの扱いのほうが費用を左右しうるということです。
拡張パックで明細を足し続ける場合と、上の段階へ移る場合のどちらが安くなるかは、拡張パックの価格が分からない限り比べられません。
見積を取るときは、想定する明細数に合う段階、その1つ上の段階、拡張パックで不足分を補う場合の3通りを並べて出してもらうと、超過したときに慌てずに済みます。
他社製品では、上限の単位が明細なのか、ユーザー数なのか、取引先数なのかが違い得ます。
同じ質問を各社に投げ、答えを同じ表に並べるのが比較の近道です。

▼ 図の内容を文字で読む

• 想定する明細数に合う段階
  • 月額の「〜」は最低価格で見積額ではない
  • 必要な処理がその段階に含まれるか確かめる
• その1つ上の段階
  • 段階の違いは明細上限だけとは限らない
• 拡張パックで不足分を補う場合
  • 明細数は拡張パックで追加できるが価格は載っていない
  • 入力が止まるのか、自動で追加料金が発生するのかは表から分からない

クラウド型の販売管理と、ERP連携のWeb受注では何が違うか

月額で始めるクラウド型

ここまで見てきた商奉行iクラウドは、受注を含む販売管理の製品です。
受注管理だけを切り出した製品ではなく、製品ページの業務一覧には請求締めや精算締めの処理も並んでいます²。
初期費用0円の段階があり¹、月額と年間契約で使い始められるのが、この種類の入り方です。

このとき、注文を入力するのは受注する側の社員です。
得意先からFAXやメールで届いた注文書を見て、担当者が品目と数量を画面に入れる流れは、システムを入れても残ります。
変わる余地があるのは、その後の転記です。
Excelで受けた注文を出荷指示書や請求書へ書き写していた作業は、受注のデータを請求まで同じ仕組みで扱えるなら減らせます。
どこまで引き継げるかは、前の節で見たように段階によって扱う業務の範囲が違い得るため、製品と段階ごとに確かめる部分です。
注文書から最初に打ち込む手間そのものは、この形のままでは減りません。

SAP連携のWeb受注テンプレート

重さのまったく違う選択肢として、日立システムズのWeb受注テンプレートがあります。
業種を問わず中堅・中小規模の顧客向けとされ、機能として見積、注文カート、受注確認、CSV取込・マッピングなどが挙げられています³。
注文カートという言葉のとおり、こちらは得意先の担当者がWeb上で品目と数量を選んで注文を入れ、受注側はその内容を確認して取り込む形です。

注文を入力する人が変わる点が、クラウド型の販売管理との一番の違いです。
受注側の社員が注文書を見て打ち込む作業が得意先の操作に置き換わるので、注文が増えても、打ち込みの手間がそのまま受注側に積み上がる構図から離れられます。
その代わり、得意先に新しい画面を使ってもらう必要があります。
FAXで注文し続けたい得意先が残れば、その分は従来どおり社内で入力することになります。

導入の重さも違います。
SAPとの連携を前提としたテンプレート単体の標準導入は、最短4カ月で構築できるとされています³。
これはカスタマイズを加えない場合の最短の期間で、カスタマイズがあれば別途プログラムの修正が必要になると説明されています³。
得意先ごとに注文画面の項目を変えたい、独自の単価計算を載せたいといった要望が増えるほど、最短の条件からは離れていきます。
SAP以外の販売管理システムを使っている場合でも導入できるとされているので³、基幹にSAPがないことだけで対象から外れるわけではありません。

2つの種類を同じ軸で並べる

観点	商奉行iクラウド（単体）	日立システムズ Web受注テンプレート
提供形態	クラウドの販売管理。 法人単位の年間契約1	Web受注のテンプレート。 SAP連携前提の標準導入3
注文の入口	受注側の担当者が入力	得意先が注文カートで入力3
初期費用	E 0円／J・A 50,000円1	提供者に確認
月額	E 7,340円〜／J 10,000円〜／A 18,750円〜（最低価格）1	提供者に確認
上限の単位	各伝票明細件数合計（E 50,000／J 100,000／A 400,000明細）。 超過分は拡張パック、価格は記載なし1	未確認
導入期間	記載なし／未確認	カスタマイズ無しで最短4カ月3
連携の前提	他社販売管理からのデータ移行、API・CSV連携の記載2	SAP連携前提。 SAP以外の販売管理でも導入可。 CSV取込・マッピング3

表で判断が分かれるのは、料金の列よりも「誰が注文を入力するか」と「既にある基幹とつなぐ前提があるか」の2つです。
月額と初期費用が公開されている側と、条件付きの導入期間が示されている側では、費用の比べ方そのものが違います。
年間の明細数が少なく、基幹もまだない会社が入力と転記を減らしたいなら、前者から検討を始めるのが自然です。
すでに基幹で受注後の処理が回っていて、困っているのが得意先からの注文を受け付けて打ち込む入口なら、後者を検討する意味が出てきます。
パッケージ型やEC一体型と呼ばれる受注システムもあり、同じ観点で提供者に聞けば、この表に行を足して比べられます。

▼ 図の内容を文字で読む

• 注文を入力する人
  • クラウド型の販売管理は、受注側の担当者が品目と数量を入力する
  • Web受注は、得意先が注文カートで入力する
• 受注側に残る作業
  • クラウド型は、最初に打ち込む手間は減らず、その後の転記を減らす余地がある
  • Web受注は、受注確認と取り込みが残り、Webを使わない得意先の分は社内入力が残る
• 検討の入口になる状況
  • クラウド型は、明細数が少なく基幹もまだない会社が入力と転記を減らしたいとき
  • Web受注は、基幹で受注後の処理が回っていて、困っているのが注文の入口のとき

取引先別単価・掛け率・締め日が複雑なとき、確認すべき質問

製品ページで読み取れる締め処理

件数が少なくても選び間違えやすいのが、取引条件が込み入っている場合です。
商奉行iクラウドの製品ページでは、業務一覧に請求締め処理と精算締め処理が挙がっています²。
締め日で請求をまとめる処理があることは、ページから読み取れます。
一方、得意先ごとの単価、掛け率、分納については、同じページに説明が見当たりません²。
載っていないことは機能がないことを意味しないので、ここは「ない」とも「ある」とも決めず、質問として持っていく部分です。

標準かオプションかを聞く

たとえば、得意先Aには定価に掛け率を掛けた価格、得意先Bには商品ごとに取り決めた個別単価、得意先Cには期間限定の特別単価で出している、という仮の状況を考えます。
システムがこの3通りを持てなければ、受注担当者は注文のたびに単価表を開き、画面の単価を手で直すことになります。
入力は電子化されても、単価を確かめて直す作業と、その誤りが請求書まで流れる心配は残ります。

だから聞くべきなのは「得意先別単価に対応していますか」という一言ではなく、次のような粒度の質問です。

• 単価を「得意先×商品」の組み合わせで登録できるか、掛け率での計算と混在させられるか
• 特別単価に適用期間を付けられるか
• その機能は標準か、オプションか、カスタマイズか
• 単価表をCSVなどで一括登録・更新できるか
• 分納のとき、残りの数量を受注の上で追えるか

標準か、オプションか、カスタマイズかの違いは、費用と導入期間に直結します。
Web受注テンプレートはカスタマイズがあれば別途プログラムの修正が必要とされているため³、単価の扱いがカスタマイズに当たるかどうかで、最短4カ月という前提が変わります。
クラウド型でも、標準で持てない条件を運用で補うなら、その補う作業が誰の手に残るかまで考えておくと、導入後の手間を見誤りにくくなります。

請求連携の範囲

単価と並んで確かめたいのが、受注から請求までのどこで金額が確定するかです。
締め日が得意先ごとに違う、分納した分だけ先に請求する、締めた後に返品や単価訂正が出る、といった場面で、受注の明細が請求にどう引き継がれるかによって、締めの作業で手で照合する量が変わります。
質問としては、得意先ごとに締め日を設定できるか、分納した分を出荷ごとに請求へ載せられるか、締めた後の訂正をどう扱うかの3点に絞ると、提供者の回答を比べやすくなります。

これらの答えは、最初に数えた明細数にも跳ね返ります。
分納で受注1行が出荷の伝票で何行にも分かれるなら、明細の数え方次第で、上限に対する余裕が見込みより小さくなる可能性があるからです。
取引条件の質問と明細上限の質問は、別々に聞くより、同じ注文を例にして一緒に聞くほうが答えがつながります。

伸びたときの拡張と乗り換えの負担：確認できること・できないこと

データ移行の説明

システムを選ぶ時点で、1年後、3年後に伸びたときのことまで正確に見通すのは難しいものです。
だからこそ、伸びたときに何を持ち込めて、何を持ち出せるかを、最初の選定で聞いておく意味があります。
商奉行iクラウドは、他社の販売管理システムから、商品、取引先、受発注、売上仕入、入金支払のデータを移行できると説明しています²。

この説明はOBC自身によるもので、移行にかかる費用や期間までは示されていません。
また、移行元として想定されているのは他社の販売管理システムです。
Excelの受注台帳やFAXの注文書で回している会社の場合、まず商品と取引先の一覧を整え、コードの振り方をそろえる作業が先に来ます。
過去の受注明細をどこまで持ち込むかも、移行した分が明細上限に数えられるかどうかで判断が変わるため、確かめておきたい点です。

逆方向、つまり将来ほかの仕組みへ移るときにデータをどこまで持ち出せるかは、移行の説明とは別の話です。
契約前に、出力できるデータの範囲と形式を聞いておくと、乗り換えの負担を見積もる手掛かりになります。

API/CSV連携

製品ページには、APIやCSVによる連携が可能とも書かれています²。
APIはシステム同士が決められた形式で直接データをやり取りする仕組み、CSVは表形式のファイルでデータを受け渡す方法です。
どちらも、受注の入口を別の仕組みに任せ、受注後の処理を販売管理で引き受けるといった分担を考えるときの前提になります。

日立システムズのWeb受注テンプレートにもCSV取込・マッピングの機能があり、SAP以外の販売管理システムを使う場合でも導入できるとされています³。
マッピングとは、Web受注で受けた注文の項目を、受け取る側のシステムの項目に対応付けることです。
2つの記載を並べると、まず販売管理を入れ、得意先からの入力を減らしたくなった段階で入口を足す、という段階的な広げ方も考えられます。
ただし、これは両者の記載から考えられる組み合わせの一例です。
特定の製品どうしが実際につながるか、どの項目まで受け渡せるかは、双方の提供者に確かめるまで分かりません。

契約前に聞く項目

ここまでの話を、契約前に提供者へ聞く項目にまとめると次のとおりです。
費用や期間は製品と条件で変わるため、数字を想定するより、各社から同じ形式で答えをもらうほうが比べやすくなります。

• 明細上限は、どの伝票を合算し、1年あたりか累計か
• 上限を超えたとき、入力が止まるのか、自動で追加料金がかかるのか
• 拡張パックなど追加分の単価と申込方法
• 年間契約の途中で段階を上げ下げできるか、その際に初期費用がかかるか
• 利用者を増やしたときの料金
• 移行できるデータの範囲と、移行した分が上限に数えられるか
• APIやCSVで受け渡せる項目と、出力できるデータの形式

自社の規模別に、どこから検討を始めるか

軸別の入口

ここまでに数えた年間の明細数、取引条件の複雑さ、既にある基幹やERPとの連携の前提という3つの軸で、検討を始める入口を整理します。
どれが優れているという順番ではなく、自社の状況に近いところから見始めるための目安です。

• 伝票の数え方を加えても明細数が小さい段階の上限に収まりそうで、取引条件が比較的単純、基幹もまだない場合：月額で始められるクラウド型の小さい段階から見ます。
  商奉行iクラウドならEシステムが50,000明細まで、初期費用0円の表示です¹。
  利用者の枠が足りるかも合わせて確かめます。
• 明細数は少ないが、得意先別単価・掛け率・締め日が込み入っている場合：上限で段階を選ぶ前に、取引条件の質問への回答で候補を絞ります。
• 明細数が上の段階に近い、または1年後の見込みで超えそうな場合：Aシステムのような400,000明細までの段階¹、拡張パック、上の段階への変更条件を並べて見積を取ります。
• 基幹やERPで受注後の処理がすでに回っており、困っているのが得意先からの注文の入力という場合：Web受注型が入口になります。
  日立システムズのテンプレートはSAP以外の販売管理でも導入できるとされ、標準導入は最短4カ月ですが、カスタマイズ無しという条件付きです³。

どの入口から入っても、最後に効くのは、数えた明細数と条件を料金表と回答に照らすことです。
明細数が少ないという理由だけで最も小さい段階を選ぶと、利用者の枠や必要な処理の範囲で上の段階が要ることがあります。
反対に、条件が複雑だという理由だけで重い仕組みを選ぶと、標準の範囲で足りたはずの導入に時間をかけることになります。

確かめ方

候補が2つ、3つに絞れたら、上限と超過時の扱いを書面でもらいます。
口頭の説明だけでは、契約の更新時や明細が増えたときに、どの条件が約束だったのかが分からなくなるからです。

そのうえで、いきなり全部の得意先を移すのではなく、取引の多い得意先数社分など小さな範囲で使い始め、1か月分の明細がシステム上でいくつと数えられるかを見ます。
最初に数えた見込みとシステムが実際に数えた明細数がずれていれば、そのずれが伝票の数え方によるものか、分納や訂正によるものかを見て、次の更新の前に段階を見直します。
試用や小さな範囲での開始ができるかどうかも、提供者に聞く項目に含めておくと、契約後の見直しがしやすくなります。

▼ 図の内容を文字で読む

1. 最初に数えた明細数
   • 見込みとして持つ
2. 書面でもらう条件
   • 上限と超過時の扱い
3. 小さな範囲で使い始める
   • 1か月分の明細がいくつと数えられるかを見る
4. 更新の前に段階を見直す
   • 伝票の数え方、分納、訂正によるずれを見る
   • 見直したあと、再び明細数を数える

明細の数え方は伝票の流れや分納・訂正の扱いで変わり、自社の台帳だけでは上限に対する余裕を見積もりにくいため。

自社の受注データから月間・年間の明細数とピークを数え、提供者へ出す質問をそろえられるかを確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
上限の単位	件数ではなく明細数（各伝票明細件数合計）で比べる
数える数字	月間・年間の明細行数、ピーク月と1年後の見込み、取引先と条件の種類
超過時	拡張パックの有無と単価、止まるか自動課金かを書面で確かめる
契約単位	法人単位の年間契約か、途中で段階を変えられるか、利用者の枠
取引条件	得意先別単価・掛け率・締め日・分納を標準／オプション／カスタマイズで聞く
種類	社内で入力するクラウド型の販売管理か、得意先が入力するWeb受注か
乗り換え	移行できるデータ、出力できる形式、API・CSVで受け渡せる項目

取引先別単価や締め日、移行の範囲は製品ごとに回答の形が違い、各社の答えを同じ観点で並べるのに手間がかかるため。 契約前に聞く項目を自社の取引条件に合わせて整え、提供者の回答を比べる観点を確かめられます。

よくある質問

受注件数ではなく明細数で数えるのはなぜですか。

システムは注文書1枚ではなく、品目ごとの行を単位に伝票を記録するからです。
料金表を確かめた商奉行iクラウドでも、上限は各伝票明細件数合計で示されていました¹。
同じ件数でも1件あたりの行数で量が大きく変わるため、件数に平均明細行数を掛けて比べます。

明細上限を超えたら、システムは止まるのですか。追加費用で済むのですか。

商奉行iクラウドでは、明細数を拡張パックで追加できると書かれていますが、価格は載っていません¹。
上限に達した時点で入力が止まるのか、自動で追加料金がかかるのかは料金表から分からないため、契約前に書面で確かめてください。
他の製品では上限の単位そのものが違い得るので、同じ質問を各社に投げて比べます。

取引先ごとに単価や掛け率が違う場合、契約前に何を確認すればよいですか。

「得意先×商品」で単価を持てるか、掛け率での計算と混在できるか、特別単価に期間を付けられるか、それが標準・オプション・カスタマイズのどれかを聞きます。
締め日を得意先ごとに設定できるか、分納した分を出荷ごとに請求できるかも合わせて確かめると、締めの作業で手作業が残るかどうかが見えます。

クラウド型から、後でERP連携型へ移るときには何を移せますか。

商奉行iクラウドは、他社の販売管理から商品・取引先・受発注・売上仕入・入金支払のデータを移行できると説明しています²が、これは持ち込む方向の説明です。
将来持ち出すときに出力できる範囲と形式は、別に聞く必要があります。
Web受注テンプレートのようにSAP以外の販売管理でも導入できるとされる仕組みもあり³、乗り換えずに入口を足す形も考えられますが、つながるかどうかは双方への確認が前提です。

ユーザー数を増やすと、料金はどう変わりますか。

商奉行iクラウドのEシステムは利用者1・専門家1の表記で、2ライセンス以上の構成も用意されています¹。
追加したときの金額は料金表から読み取れないため、入力する人と照会する人の人数を数えたうえで見積を取ってください。

Excel・FAX運用のままですが、まず何から数えればよいですか。

直近数か月分の受注件数と明細行数、繁忙月の明細数、得意先ごとの単価・締め日・分納の種類の3つです。
注文書の行数を手で数えるだけでも、料金表の明細上限と比べられる数字になります。
その数字は受注伝票分の最小値として持ち、伝票ごとの数え方を提供者に聞いて補います。

1. 1　出典：株式会社オービックビジネスコンサルタント「商奉行iクラウド・商蔵奉行iクラウド 料金ページ」（2026年）
2. 2　出典：株式会社オービックビジネスコンサルタント「商奉行iクラウド 製品ページ」（2026年）
3. 3　出典：株式会社日立システムズ「Web受注テンプレート（SAPソリューション）」（2026年）