受発注システムは開発かパッケージか｜判断表と7つの選択肢を比較

電話とFAXで届く注文を、担当者が基幹システムや Excel に打ち直している。受発注システムを検討し始めると、比較サイトには数十の製品が並び、一方で開発会社のサイトには「パッケージでは業務に合わない」と書かれています。どちらを信じればよいのか、判断の物差しがないまま迷っている方も多いはずです。

結論から言うと、受発注システムは「パッケージで足りるか」を先に確かめ、足りない部分だけを作るのが基本です。確かめる場所は機能の数ではありません。返品・欠品・倉庫差異といった例外処理が、標準の流れに乗るかどうかです。

この記事では、受発注システムと周辺の選択肢7つを公式情報で比較したうえで、パッケージで足りる条件と個別開発が必要な条件を判断表にまとめます。料金はすべて2026年10月1日に各社の公式サイトで確認したものです。

結論：まず「パッケージで足りるか」を例外処理から確かめる

受発注システムは、取引条件と例外処理が標準機能の設定で回るならパッケージ、回らない部分があれば連携開発か個別開発を選びます。判断の順番は次のとおりです。

• 取引先ごとの価格・締め・納期のルールが、パッケージの設定で表せるかを確かめる。掛け率、締め時間、納品日の制限は、Bカート・CO-NECT・BtoBプラットフォーム 受発注などが機能として備えています
• 返品・欠品・倉庫差異などの例外が、標準の処理の流れに乗るかを確かめる。差が出るのはここです
• 乗らない部分があっても、CSV や API の連携で補えるなら、パッケージを使い続けたまま足りない部分だけを作る。受発注の画面そのものを作り直す必要はありません
• 連携でも補えず、しかもその例外処理が自社の強み（取引先に選ばれる理由）になっているときに、個別開発を検討する

最初から「うちは特殊だから個別開発」と決めるのも、「安いからパッケージ」と決めるのも、どちらも判断を飛ばしています。特殊かどうかは、例外処理を書き出してみるまで分かりません。

受発注システムとは：パッケージが標準で持っている範囲

受発注システムとは、取引先からの注文受付（受注）と仕入先への発注を、電話・FAX・メールではなく共通の画面とデータで管理する仕組みです。BtoB向けの製品は、一般的な通販サイトにはない「企業間取引の約束ごと」を標準で持っているのが特徴です。

公式の機能一覧から、主要製品が標準で備えている範囲を拾うと次のようになります。

• 取引先ごとの価格と表示: Bカートは「取引先ごとの掛け率管理や、会員制をはじめとした販路の管理」を標準対応としています（Bカート 機能一覧）
• 締め時間と納品日の制御: CO-NECT は「受注の締め時間を設定し、顧客毎に納期を制御」できる機能を標準搭載のオプションとして挙げています（CO-NECT 料金プラン）
• イレギュラーな受注の抑止: インフォマートの「BtoBプラットフォーム 受発注」は、取引不可日設定・リードタイム設定を受注側の機能として紹介しています（BtoBプラットフォーム 受発注 受注側）
• 掛売りと与信: Bカートは与信枠確認、締支払日設定、分納・同梱への対応を機能として掲載しています（Bカート BtoB専用機能）
• 基幹システムとの受け渡し: CO-NECT は CSV 出力の項目を任意に設定でき、会計・販売管理ソフトとの API 連携・CSV 連携の事例を公開しています（CO-NECT 外部システム連携）

受注側の製品か、発注側の製品か

受発注システムには、注文を受ける側（卸・メーカー・商社）が導入する製品と、注文を出す側（小売・飲食・宿泊、企業の購買部門）が導入する製品があります。CO-NECT はサイトの入口を「受注する方」と「発注する方」に分け、受注側に卸・商社・メーカー・物流、発注側に小売・飲食・宿泊・購買部門を挙げています（CO-NECT）。BtoBプラットフォーム 受発注も、料金を「発注企業様向け」と「受注企業様向け」に分けて案内しています（BtoBプラットフォーム 受発注の料金）。

この違いは、取引先に何を求めるかに直結します。受注側が導入する製品では、取引先に新しい発注画面を使ってもらう必要があります。取引先（発注側）がすでに使っている仕組みに受注側として参加する形なら、取引先の負担は小さくなります。自社の取引先がどちらの立場で、どの仕組みをすでに使っているかは、製品の機能より先に確かめておきたい点です。

つまり「取引先によって価格が違う」「締め時間がある」「掛売りがある」といった条件だけでは、個別開発の理由になりません。これらはパッケージが最初から想定している業務です。自社の受発注を「特殊」と感じる理由が、この範囲に収まっていないかを最初に確かめてください。

受発注システムと周辺の選択肢7つを比較する

受発注システムは、提供範囲で大きく3つに分かれます。受発注に特化したクラウド（Bカート、CO-NECT、BtoBプラットフォーム 受発注、TS-BASE 受発注）、カスタマイズに対応したEC基盤（EBISUMART）、販売管理まで一体の基幹パッケージ（アラジンオフィス）です。加えて、専用製品ではないものの、受発注の周辺業務を自作する選択肢として kintone を並べます。

製品	形態	公開されている料金（2026年10月1日確認・税別）	標準で得意な範囲	導入前に確認したい点
Bカート	BtoB受発注・ECのクラウド	月額9,800円（商品数500・会員数50）〜79,800円（商品数30,000・会員数30,000）、初期費用80,000円。それ以上はエンタープライズで個別見積	取引先ごとの掛け率、会員制、掛売り、与信枠確認、分納・同梱、見積機能。注文承認機能（承認ルール）はオプション	プランは商品数と会員数で決まる。CSV注文機能はプラン30（月額29,800円）以上
CO-NECT	受注側向けの受発注クラウド	金額は非公開。基本料金は取引先数と月間受注数で変動。無料トライアルあり	締め時間・納品日制限、請求書発行、CSV出力項目の設定、会計・販売管理ソフトとの連携	契約期間は1年間・年間一括払い
BtoBプラットフォーム 受発注	受発注クラウド（発注側・受注側の両方）	受注企業向けは月次受領金額によって変動（金額は資料で確認）。発注企業向けはセットアップ費用と本部・店舗ごとの月額	取引不可日・リードタイムの設定、発送情報のアップロード。発注企業向けプランは飲食店・ホテル・給食施設などを対象としている	取引先（発注側）がすでに同じ仕組みを使っているか
TS-BASE 受発注	注文サイト・倉庫システム・管理システムの一体型	Aプラン（注文サイト・倉庫・管理）初期500,000円・月額140,000円。Bプラン（注文サイト・管理）初期470,000円・月額100,000円。Cプラン（倉庫・管理）初期290,000円・月額100,000円	受注から倉庫の出荷までを一続きで持つ	商品・取引先・配送先マスタの件数に応じて追加オプションが発生する場合がある
EBISUMART	カスタマイズ可能なクラウド型EC基盤	金額は非公開。アクセス数で変わる従量課金プラン、固定料金プラン、サイト売上に対する料率で払うレベニューシェアプランがある	BtoB向けECサイト、API を使った追加開発、既存システムとの連携	追加開発を誰が担うか（自社エンジニアか、提供会社か）
アラジンオフィス	販売・購買・在庫を一元管理する基幹業務パッケージ	金額は非公開	販売管理・在庫管理を中心に、生産・貿易などのオプション。導入実績6,000社以上と公表	取引先向けのWeb受発注は、連携する BtoB向けWeb受注システムと組み合わせる形か。基幹業務ごと入れ替える前提になるか
kintone	ノーコードの業務アプリ基盤（受発注専用ではない）	1ユーザー月額1,000円（ライト）・1,800円（スタンダード）・3,000円（ワイド）。最小10ユーザー（ワイドは1,000ユーザー）	社内の受注台帳・承認・進捗管理を自作する	取引先に発注画面を開放する用途には、別の仕組みとの組み合わせが必要か

※料金・プラン構成は各社の改定で変わります。表の金額は2026年10月1日時点の公式サイトの表示で、導入時は必ず公式の最新情報と見積りを確認してください。

公式情報から見た、それぞれが候補になりやすい会社の目安は次のとおりです。

• Bカート: 商品数・取引先数に合わせて月額の小さいプランから始め、事業の伸びに応じてプランを上げたい卸・メーカー
• CO-NECT: 受注の窓口をWebにまとめ、受注データを会計・販売管理ソフトへ CSV や API で渡したい受注側の会社
• BtoBプラットフォーム 受発注: 取引先の飲食店・ホテル・給食施設などが、発注側として同じ仕組みを使っている卸・メーカー
• TS-BASE 受発注: 注文サイトから倉庫の出荷までを一続きの仕組みで持ちたい会社
• EBISUMART: 追加開発も含めて、BtoB向けのECサイトを自社の業務に合わせて作り込みたい会社
• アラジンオフィス: 受発注の窓口だけでなく、販売管理・在庫管理を含む基幹業務ごと入れ替えたい会社
• kintone: 取引先向けの画面は別に用意し、社内の受注台帳・承認・返品受付を小さく作りたい会社

表から読み取れるのは、製品の違いが「どこまでを1つの仕組みで持つか」にあるということです。受発注の窓口だけを置き換えたいなら Bカートや CO-NECT のような受発注特化のクラウド、倉庫の出荷まで一続きにしたいなら TS-BASE 受発注のような一体型、販売管理ごと入れ替えるならアラジンオフィスのような基幹パッケージ、と候補が変わります。

もう1つの違いは料金の決まり方です。Bカートは商品数と会員数、CO-NECT は取引先数と月間受注数、BtoBプラットフォーム 受発注の受注企業向けは月次受領金額で費用が変わります。自社の取引先数・商品数・受注数を数えておくと、見積りの比較が早く進みます。

パッケージで足りる条件、個別開発が必要な条件

パッケージで足りるかどうかは、「自社の受発注のルールを、製品の設定で表せるか」で決まります。設定で表せないルールが見つかっても、すぐに個別開発になるわけではありません。次の表で、項目ごとに判断してください。

確認する項目	パッケージで足りる	連携開発・個別開発を検討する
取引先ごとの価格	掛け率・取引先グループ別の単価で表せる	案件ごとの見積り価格、原材料の相場に連動する価格など、計算式そのものが取引先ごとに違う
締め時間・納期	締め時間と納品日の制限、取引不可日の設定で表せる	配送便・産地・製造ロットによって納期が注文の中身ごとに決まる
注文の受け方	取引先がWeb画面から品番と数量を入れる	取引先ごとに決まった形式のファイルや EDI で届き、変換が必要
返品・値引き	返品は少なく、担当者が手作業で赤伝票を切れば回る	返品が日常的に発生し、理由別に在庫・請求・取引先の評価を分けて扱う
欠品・分納	分納・同梱の標準機能で対応できる	代替品の提案、入荷予定からの引当、優先順位のある割り当てが必要
倉庫・在庫	在庫は1拠点、または倉庫システム側で完結している	複数倉庫の在庫を受注時点で引き当て、帳簿と実在庫の差異を日次で吸収する
基幹システム	CSV の出力・取込で基幹システムへ渡せる	受注の確定と同時に基幹側の在庫・与信を更新しなければ事故が起きる
取引先の数と入れ替わり	取引先の追加・変更が月に数件程度	取引先ごとの個別ルールが多く、増えるたびに設定が膨らむ

表の右列に当てはまる項目が1つでもあれば、次の順に考えます。

上の図のとおり、判断の問いは3つです。

• 取引先ごとの価格・締め・納期のルールは、標準機能の設定で表せるか
• 返品・欠品・倉庫差異などの例外は、標準の処理の流れに乗るか
• 足りない部分は、CSV や API の連携で補えるか

最初の2つを満たせば「パッケージで導入する」。どちらかを満たせなくても、3つめを満たせば「パッケージ＋連携開発」。3つめも満たせないときに初めて「個別開発を検討する」になります。個別開発は選択肢の最後にあり、しかも受発注全体ではなく、満たせなかった部分から検討が始まります。

さらに、3つめを満たせない処理でも、取引先に選ばれる理由になっていないなら、パッケージの標準に業務を合わせるか、その注文だけ手作業で残す選択肢もあります。個別開発に進むのは、その処理が自社の強みである場合です。

注意したいのは、「今のやり方」と「そうでなければならないやり方」を分けて考えることです。今の Excel 運用でたまたまそうしている手順は、パッケージに合わせて変えられるかもしれません。一方で、取引先がその対応を理由に取引してくれているなら、それは守るべき業務です。拠点ごとに違うやり方のどれを共通化し、どれを残すかの整理は、基幹システム刷新の進め方で詳しく扱っています。

差が出るのは例外処理：返品・欠品・倉庫差異・イレギュラー注文

製品のデモでは、正常な注文が入って、出荷されて、請求される流れが中心に見せられます。しかし受発注の担当者が時間を取られているのは、その流れから外れた注文です。パッケージの適否は、例外がどのくらいの頻度で起き、どのくらい種類があるかで決まります。

返品：件数よりも「返品のあとに何が動くか」

返品が発生すると、少なくとも在庫（戻すか、廃棄するか）、請求（返金か、次回請求からの相殺か）、記録（理由と責任の所在）の3つが動きます。

パッケージで足りるのは、返品が例外的で、担当者が請求の修正と在庫の戻しを手作業で行っても負担が小さい場合です。反対に、返品が日常業務になっていて、理由（不良・誤出荷・取引先都合）ごとに在庫の扱いと請求の扱いが変わるなら、その分岐をどこで持つかを製品選定の前に決める必要があります。

製品の説明会では、次のように聞いてください。

• 返品を受注データに紐づけて記録できるか。それとも別の台帳で管理することになるか
• 返品の理由ごとに、在庫を戻す・戻さないを変えられるか
• 返品による請求の修正は、受発注システム側と会計・販売管理側のどちらで行う想定か

欠品：分納で済むか、割り当てが必要か

注文された数量が揃わないとき、多くの製品は分納（揃った分から出荷）や同梱で対応します。Bカートのように分納・同梱への対応を機能として掲載している製品もあります（Bカート BtoB専用機能）。

個別の検討が必要になるのは、欠品のときに誰に、どれだけ、何を回すかを判断している場合です。たとえば、入荷予定の在庫を得意先の優先順位で割り当てる、代替品を提案して了承を得てから出荷する、といった運用です。この判断を担当者の頭の中で行っているなら、システム化の前にルールとして書き出してください。書き出したルールがパッケージの設定に乗るか、乗らないなら連携先（在庫管理システムや基幹システム）で持てるかを確かめます。

倉庫差異：受注と在庫の「正」をどちらに置くか

受注画面に表示される在庫と、倉庫の棚にある実際の在庫は、必ずずれます。入出荷の登録漏れ、破損、棚卸しのタイミングの違いが原因です。問題は、ずれたときにどちらを正とし、いつ、誰が合わせるかです。

倉庫が1か所で、在庫の管理が倉庫システム側で完結しているなら、受発注システムは倉庫システムから在庫数を受け取るだけで足ります。TS-BASE 受発注のように、注文サイト・倉庫システム・管理システムを一体で提供するプランを持つ製品もあります（TS-BASE 料金案内）。

複数の倉庫をまたいで受注時点で在庫を引き当てる、拠点間の移動中の在庫も数える、といった条件があると、パッケージの標準では扱いきれないことがあります。この場合は、受発注システムではなく在庫管理側でどこまで持てるかを先に確かめるのが近道です。受発注の画面と在庫の計算を同じ仕組みに詰め込むと、どちらかの改修のたびにもう一方も触ることになります。

イレギュラー注文：電話で届く「いつもと違う注文」

特急の注文、取引先の締め時間を過ぎた注文、規格外の数量、見積りを経由する注文。こうした注文が電話やFAXで届き続ける限り、Web受注の画面を用意しても担当者の手作業は残ります。

締め時間・取引不可日・リードタイムの制御は、CO-NECT や BtoBプラットフォーム 受発注が機能として挙げている範囲です（CO-NECT 料金プラン、BtoBプラットフォーム 受発注 受注側）。Bカートは見積機能や、一定金額以上で承認を求める承認ルールの設定を機能一覧に掲載しています（注文承認機能はオプション。Bカート 機能一覧）。まずはイレギュラー注文を種類別に数え、上位の種類がこれらの機能で吸収できるかを確かめてください。吸収できない注文が一部に残るなら、その注文だけは従来どおり担当者が受ける、という線引きも現実的な選択肢です。

例外処理を書き出すときのコツ

例外処理は、担当者に「困っていることは何ですか」と聞いても出てきません。本人にとっては当たり前になっているからです。直近1〜2か月の注文から、担当者が手で修正した注文、電話で確認し直した注文、上長に判断を仰いだ注文を拾い出し、1件ずつ「なぜ手が入ったか」を聞くほうが確実です。

拾い出した例外は、種類・月あたりの件数・1件あたりの手間・判断している人の4項目で表にします。件数が多く手間が大きいものから順に、パッケージの設定で吸収できるか、連携で補えるか、作る必要があるかを判定していきます。

第三の選択肢：パッケージを使い、足りない部分だけ作る

パッケージか個別開発かの二択で考えると、判断を誤りやすくなります。例外処理の一部だけが標準に乗らない場合に現実的なのは、取引先が触る注文の画面と標準的な流れはパッケージに任せ、自社固有の判断だけを連携先で作る形です。

連携の方式を先に確かめる

パッケージの外で処理を作るには、データの出入り口が必要です。主な方式は次の2つです。

• CSV 連携: 受注データをファイルで出力し、基幹システムや自作の仕組みに取り込む。日次・時間ごとの一括処理に向きます。CO-NECT は CSV 出力の項目を任意に設定でき、販売管理ソフトとの CSV 連携の事例を公開しています（CO-NECT 外部システム連携）
• API 連携: 受注が入った時点でデータを受け渡す。在庫や与信を即座に反映したい場合に向きます。EBISUMART は、API を使った自社エンジニアによる開発と、提供会社のエンジニアによる開発の両方でカスタマイズできると案内しています（EBISUMART）

どちらの方式でも、どの時点で、どのデータが、どちら向きに流れるかを図にしておくと、作る範囲が明確になります。「受注の確定は受発注システム、在庫の引当は在庫管理システム、請求は会計ソフト」のように、データごとに正となる仕組みを1つに決めることが大切です。

社内の業務はノーコードで補う手もある

取引先に見せる必要のない社内業務、たとえば返品の受付台帳、欠品時の割り当て判断の記録、特急注文の承認などは、kintone のような業務アプリ基盤で自作する方法もあります。料金は1ユーザー月額1,000円から（最小10ユーザー、税別、kintone 料金）と公開されており、個別開発より小さく始められます。

ただし、自作したアプリにも保守の担い手が必要です。作った担当者が異動したあと誰も直せない、という状態は Excel のマクロと変わりません。誰が直すのかを決めてから作ってください。

作る部分の境界を決める

部分的に開発する場合は、境界を次の3点で決めます。

1. 作る部分が担う判断は何か（例: 欠品時の割り当て、返品理由ごとの在庫の扱い）
2. パッケージから受け取るデータと、パッケージへ返すデータは何か
3. パッケージ側の仕様変更やバージョンアップがあったとき、誰が影響を確かめるか

この3点が決まっていれば、開発会社への相談も「受発注システムを作ってほしい」ではなく「この判断をこのデータで自動化したい」という具体的な依頼になり、見積りの幅も小さくなります。

パッケージと個別開発、それぞれのつまずきやすい点

どちらを選んでも、つまずきやすい点はある程度決まっています。選ぶ前に知っておけば、多くは避けられます。

パッケージでつまずきやすい点

1つめは、標準機能に合わせきれない部分を、画面の外の手作業で埋め続けることです。パッケージで受注したあと、例外の注文だけを Excel に書き写して処理していると、導入前より確認箇所が増えることさえあります。導入前に例外処理を書き出し、どれを手作業で残すかを決めておけば、この状態は計画の範囲に収まります。

2つめは、取引先が発注画面を使ってくれないことです。受注側の都合で導入した仕組みは、取引先にとっては操作が1つ増えるだけに見えることがあります。締め時間の延長や、注文履歴からの再発注など、取引先にとっての利点を用意し、主要な取引先から順に切り替えてもらう計画が必要です。

3つめは、料金の条件が事業の伸びと連動していることです。商品数・会員数・受注数・受領金額などで料金が変わる製品では、取引が増えると費用も増えます。3年後の商品数や取引先数を置いて、料金表のどの段階に入るかを確かめておくと、あとで慌てずに済みます。

個別開発でつまずきやすい点

1つめは、今の業務をそのまま画面にしてしまうことです。Excel と電話で回している手順を、見直さずにすべて作り込むと、開発費が膨らむうえに、例外が増えるたびに改修が必要になります。作る前に、守るべき業務と変えてよい手順を分けてください。

2つめは、パッケージなら提供会社が引き受けている仕事を見落とすことです。たとえば Bカートは、サーバー・サブドメイン・SSL の利用料が月額に含まれると明記しています。CO-NECT のように、インボイス制度・電子帳簿保存法への対応を掲げる製品もあります（月額に含まれる範囲は見積りで確認してください）。個別開発では、こうしたサーバーの運用、セキュリティの更新、法令変更への対応が開発後も続き、社内か開発会社の誰かが引き受けることになります。見積りを取るときは、開発費と一緒に、これらを誰がいくらで担うかを確かめます。

3つめは、開発を依頼した会社以外が直せない状態になることです。設計書やソースコードの扱い、引き継ぎの方法を契約前に決めておかないと、改修のたびに同じ会社に頼むしかなくなります。この点は開発会社を比べるときの確認項目にもなります。

一部の取引先から切り替える

製品を決めたら、すべての取引先を一度に切り替えるのではなく、注文の多い取引先や協力的な取引先の一部から始めるのが安全です。TS-BASE 受発注は、切り替えには移行期間が発生するとして、テスト環境を立ち上げてから本稼働に進む流れを案内しています（TS-BASE 料金案内）。

一部の取引先で運用してみると、書き出した例外処理の漏れや、取引先側の操作でつまずく箇所が見えてきます。そのうえで、残りの取引先へ広げるか、足りない部分を連携で補うかを判断すれば、判断の材料が机上の比較より確かになります。

費用は5年総額で比べる

受発注システムの費用は、パッケージの月額と開発費を同じ期間で並べないと比べられません。パッケージは初期費用が小さく月額が続き、個別開発は初期費用が大きく保守費が続く、という構造の違いがあるためです。

公開されている料金から、5年間（60か月）の利用料を計算すると次のようになります（税別、オプション・導入支援・連携開発は含まない）。

例	計算	5年間の利用料
Bカート プラン10（商品数1,000・会員数1,000）	初期80,000円＋月額19,800円×60か月	1,268,000円
TS-BASE 受発注 Aプラン（注文サイト・倉庫・管理）	初期500,000円＋月額140,000円×60か月	8,900,000円
kintone スタンダード 10ユーザー（社内の受注台帳・承認のみ。取引先向けの発注画面は含まない）	月額1,800円×10ユーザー×60か月	1,080,000円

出典: Bカート 料金プラン、TS-BASE 料金案内、kintone 料金（いずれも2026年10月1日確認）。kintone は初期費用なしの料金表示です。

同じ「受発注システム」でも、窓口だけを置き換える製品と倉庫まで一体で持つ製品とでは、5年間の費用が大きく違います。金額の差は、製品の良し悪しではなく引き受ける範囲の差です。比較するときは、範囲をそろえてから金額を見てください。

個別開発の見積りと並べる場合は、次の費用を含めて5年分で比べます。

• 初期の開発費（要件定義・設計・開発・テスト・データ移行）
• 保守費（不具合対応、サーバー・クラウドの利用料、セキュリティ更新）
• 法令の変更に伴う改修（パッケージでは、提供会社がどこまで対応するかを確認する）
• 取引条件の変更に伴う設定の変更や改修
• 取引先の追加・商品の追加に伴う設定や改修

パッケージの月額に何が含まれるかも確認してください。Bカートは、サーバー・サブドメイン・SSL の利用料が月額に含まれると明記しています（Bカート 料金プラン）。法令への対応では、CO-NECT がインボイス制度・電子帳簿保存法への対応を掲げています（CO-NECT）。どこまでが月額の範囲で、どこから別料金になるかは、各社の見積りで確かめてください。開発費の考え方と、段階ごとに投資判断を区切る見積りの取り方は、MVP開発の費用と相場の考え方でも解説しています。

電子取引データの保存を誰が引き受けるか

受発注のデータを電子でやり取りする場合、そのデータの保存にも法令上のルールがあります。国税庁は電子帳簿保存法について、「取引に関する書類に通常記載される情報（取引情報）を含む電子データをやり取りした場合の、当該データに関する保存義務やその保存方法等」も同法で定められているとし、所得税法・法人税法上の保存義務者に「電子取引」の確認を求めています（国税庁 電子帳簿等保存制度特設サイト）。

パッケージを選ぶ場合は、提供会社が電子帳簿保存法への対応をどう説明しているかを確認します。CO-NECT はインボイス制度・電子帳簿保存法への対応を掲げています（CO-NECT）。BtoBプラットフォーム 受発注も、受注側のページで電子帳簿保存法への対応を案内しています（BtoBプラットフォーム 受発注 受注側）。個別開発や部分開発を選ぶ場合は、保存の要件を満たす設計を自社（と開発会社）で引き受けることになります。国税庁の特設サイトには、自社開発システムの要件定義に悩んでいる場合の相談先も案内されています。

具体的な保存要件や自社の取引が対象になるかどうかは、税理士や国税庁の窓口で確認してください。ここで押さえておきたいのは、法令対応を誰が引き受けるかが、パッケージと開発の費用差に含まれることがあるという点です。見積りを比べるときは、その範囲も確かめてください。

製品選定・開発会社への相談前に確認する質問

製品の比較や開発会社への相談の前に、社内で次の項目に答えを用意しておくと、判断が早くなります。

• 取引先の数、商品数（SKU ではなく商品の数）、月あたりの受注件数
• 注文が届く経路の内訳（Web・電話・FAX・メール・EDI）
• 取引先ごとに違うルール（価格、締め時間、納期、支払条件）の一覧
• 直近1〜2か月の例外処理（返品・欠品・倉庫差異・イレギュラー注文）の種類と件数
• 受注データを渡す先（基幹システム、在庫管理、会計ソフト）と、今の渡し方
• 在庫の「正」をどの仕組みに置くか
• 導入後に設定変更や改修を担う社内の担当者

製品の提供会社には、次のように聞いてください。

• 自社の例外処理のうち、標準機能の設定で対応できるものと、できないものはどれか
• 対応できないものについて、CSV や API で外部に出し、戻すことはできるか
• 料金が変わる条件（商品数、取引先数、受注数、受領金額など）は何か
• 製品の仕様変更やバージョンアップの頻度と、事前の告知方法
• 取引先からの操作の問い合わせを、提供会社と自社のどちらが受けるか

開発会社に相談する場合は、「受発注システムを作ってほしい」ではなく、パッケージで対応できなかった部分と、その理由を伝えます。開発会社の比べ方そのものは、受託開発の会社選びで7つの観点に整理しています。

状況別の読み分け早見表

当てはまる状況	次に読むセクション・アクション
まだどの製品があるかも分からない	「受発注システムと周辺の選択肢7つを比較する」の表で、形態の違いをつかむ
候補の製品はあるが、自社に合うか分からない	「パッケージで足りる条件、個別開発が必要な条件」の判断表で右列に当てはまる項目を数える
返品や欠品の処理に手間がかかっている	「差が出るのは例外処理」を読み、例外を種類・件数・手間で書き出す
パッケージの見積りと開発の見積りの両方がある	「費用は5年総額で比べる」の方法で範囲をそろえて比較する
パッケージに足りない部分がはっきりしている	「第三の選択肢」で作る部分の境界を決め、開発会社に相談する

よくある質問

受発注システムはパッケージと個別開発のどちらがよいですか

取引先ごとのルールと例外処理が標準機能の設定で回るならパッケージが適しています。回らない部分があっても、CSV や API の連携で補えるならパッケージを使い続け、足りない部分だけを作るのが現実的です。連携でも補えず、その処理が自社の強みになっている場合に個別開発を検討します。

受発注システムの費用はどのくらいかかりますか

公開価格の例では、Bカートは月額9,800円〜79,800円（初期費用80,000円、税別）、TS-BASE 受発注は注文サイトを含むA・Bプランで月額100,000円〜140,000円（初期費用470,000円〜500,000円、税別）です（2026年10月1日確認）。CO-NECT などは料金を公開しておらず、取引先数や受注数で変わります。開発と比べるときは5年総額で比べてください。

取引先がシステムを使ってくれるか不安です

取引先側の操作が増えると、電話やFAXでの注文が残りやすくなります。候補の製品で、取引先が使う発注画面を実際に試せるかを確認してください。CO-NECT は無料トライアルを案内しています。BtoBプラットフォーム 受発注のように、取引先がすでに同じ仕組みを使っているかどうかも判断材料になります。

在庫管理システムも一緒に入れるべきですか

在庫の「正」をどこに置くかで決まります。倉庫が1か所で在庫の管理が倉庫システム側で完結しているなら、受発注システムは在庫数を受け取るだけで足ります。複数倉庫の引当が必要な場合は、受発注システムに詰め込まず、在庫管理側でどこまで持てるかを先に確かめるほうが改修の影響を小さくできます。

kintone で受発注システムを作れますか

社内の受注台帳、承認、返品受付などは kintone で作れます。一方、取引先に発注画面を開放する用途には、受発注専用の製品や別の仕組みとの組み合わせが必要か、導入前に確認してください。作ったアプリを誰が保守するかも、先に決めておく必要があります。

今使っている Excel の運用をそのままシステムにしたいです

Excel の運用には、守るべき業務知識と、たまたま続いている手順が混ざっています。そのままシステムにすると、後者まで作り込むことになり、費用も保守の負担も大きくなります。まず例外処理を書き出し、取引先に選ばれている理由になっている業務だけを守る対象として残してください。

パッケージを入れたあとで、個別開発に切り替えられますか

切り替えられます。パッケージで運用した期間の受注データと例外処理の記録は、個別開発の要件を決めるうえで最も確かな材料になります。切り替えに備えて、受注データを CSV などで取り出せるか、契約期間と解約の条件はどうなっているかを、導入前に確認しておいてください。

相談すべきケースと、まだ相談しなくてよいケース

株式会社隼は、業務システムの個別開発と、既存システムやパッケージとの連携開発を行っています。ただし、すべての受発注の課題に開発が必要なわけではありません。

次のような場合は、開発会社に相談する価値があります。

• 判断表の右列に当てはまる項目があり、パッケージの提供会社から「標準では対応できない」と回答された
• 受発注・在庫・基幹システムの間で、データの正をどこに置くかが決まらない
• パッケージを入れたが、例外処理のために Excel と手入力が残っている
• 返品・欠品・割り当ての判断が特定の担当者に依存していて、その判断を仕組みにしたい

反対に、次の場合はまだ相談しなくて大丈夫です。

• 取引先ごとのルールが、比較表の製品の標準機能で表せそうだ
• 例外処理の件数が少なく、担当者の手作業で無理なく回っている
• まだ製品の無料トライアルやデモを試していない

この場合は、まず比較表の製品を2〜3つ試し、自社の例外処理が標準で回るかを確かめてください。それで足りれば、個別開発は不要です。

パッケージで足りない部分が見えてきた段階、あるいは「パッケージで足りるのか判断がつかない」段階でも、ご相談いただけます。RFP や固まった要件は必要ありません。初回のご相談と概算のご提示は無償で、お問い合わせフォームから2営業日以内にご返信します。業務システムの支援内容はサービスでご確認いただけます。

まとめ

受発注システムを開発するかパッケージにするかは、機能の数ではなく、自社の取引ルールと例外処理が標準の設定に乗るかで決まります。

1. 取引先ごとの価格・締め・納期が設定で表せるかを確かめる
2. 返品・欠品・倉庫差異・イレギュラー注文を種類と件数で書き出し、標準の流れに乗るかを確かめる
3. 乗らない部分は、CSV や API の連携で補えるかを確かめる
4. 連携でも補えず、自社の強みになっている処理だけを個別開発で作る
5. 費用は5年総額で、引き受ける範囲をそろえて比べる

取引先ごとのルールが標準機能で表せるなら、受発注の窓口はパッケージに任せ、作る対象を例外処理の一部に絞れます。その一部を見極めることが、受発注システムの導入でいちばん費用対効果の大きい作業になります。