受発注システムの開発を依頼するには｜受注・納品・請求のどこまで作るか

受発注システムの開発を頼むのは、変更・取消・分納・取引先ごとの単位違いが日常的に起きていて、既製品の画面では追いきれない場合です。その場合も、最初は「受注台帳・注文の状態・変更履歴」に絞って頼むのが安全です。取引先との取り決めが標準的なら、開発を頼む前に既製のクラウドサービスで足りるかを確かめてください。

この記事は、注文がFAX・メール・電話・Excel・販売管理に分かれ、「この注文は今どうなっているか」「今月いくつ請求してよいか」を人が追っている会社の経営者・営業事務責任者・受注管理者に向けたものです。

AI革命の受託開発の公開価格は、小規模な既存改修が30万円〜、PoC（本番前の検証開発）が300万円〜、本開発は個別見積です（すべて税別、クラウド利用料などの実費は別）。PoCの300万円は本番システム一式の価格ではありません。

開発を頼む前に、既製品で足りるかを確かめる

出典: Bカート 公式

受発注の仕組みには、作らなくても月額で使える既製品があります。下の表で「足りる」側に当てはまるなら、開発会社に頼む前に既製品を試す方が早く、安く済みます。

既製品の価格は次のとおりです（2026年10月に各社公式ページで確認。いずれも税別）。

CO-NECTやBtoBプラットフォーム 受発注など、受発注専用のサービスもあります。これらの料金はこの表では比べていないため、各社の公式サイトで確認してください。

既製品とオーダーメイドの一般的な選び方は既製品か個別開発かの判断で詳しく扱っています。この記事では、受発注に特有の判断に絞ります。

開発しない方がよい場合

• 困っているのがFAXや紙の注文を入力する手間だけの場合は、受注台帳を作り直す必要はありません。読み取りと入力の自動化で足ります（FAX受発注の自動化）
• 発注書・納品書・請求書の数字の突き合わせだけが問題なら、照合の仕組みを足す方が早く済みます（受発注の照合を自動化する方法）
• 取引先数・商品数が少なく、価格・単位・締めが共通なら、上の表の既製品を試してください
• 在庫の引き当て・倉庫の作業・配送計画までを一度に作り替えたい場合は、受発注システムではなく基幹システム全体の見直しになります。範囲と費用の桁が変わるため、この記事の対象外です

Excelとメールで追いきれなくなるのは「注文の状態」

受発注システムの機能一覧は、受注登録・出荷・請求と並びます。けれども現場で困るのは機能が無いことより、1件の注文が変更・取消・分納を経て「今どの状態か」を誰も一目で答えられないことです。

受注から請求までの状態の流れ（説明用）

この表は説明用に単純化したものです。実際の状態の数や名前は、会社ごとの業務に合わせて決めます。大事なのは次の3点を「注文1件ごとに」持つことです。

1. 最終合意した数量・納期・単価と、そこに至った変更の履歴
2. 注文数・取消数・納品数・残数の内訳
3. 請求してよい数量と、請求済みの数量

架空の注文で見る、Excelで管理しきれなくなる場面

下は架空データです。商品Xを10箱受注し、メールで2箱追加、欠品で2箱取消、3回に分けて納品したケースです。請求は納品した数量に対して月末締めで行う前提にしています。

残数は「注文数−取消数−納品数」、未請求は「納品数−請求済み」で計算しています。

1行に1注文を書くExcelで数量を上書きしていくと、次のような問題が起きます。

• 10/3の追加や10/8の取消で数量のセルを上書きすると、「最初から10箱だった」のか「変更と取消を経て10箱になった」のかを区別できなくなります
• 納品数を1つのセルに足し込むと、どの納品が10月分で、どれが11月分かが消えます。11/4の1箱を10月の請求に含めてしまう、または請求し忘れる原因になります
• 取引先が「120個」とFAXしてきた場合（架空の例）、1箱12個の換算を誰がどこで行ったかが残らないと、後で数量の食い違いを説明できません

システムにする目的は、この表の各行を消さずに積み上げ、残数と請求できる数量を自動で計算することです。

最初に作る範囲と、後から足す範囲

受発注の仕組みを一度に全部作ろうとすると、費用も期間も膨らみ、使い始めるまでに業務が変わってしまいます。最初は注文の状態を正しく持つ部分に絞り、困りごとの大きい順に足していく方が失敗しにくくなります。

最後の行の「取引先が自分で注文する画面」は、社内の受注管理とは利用者も守るべき範囲も違います。取引先Aに取引先Bの価格や注文が見えない設計と、その確認試験が必要になるため、社内の受注台帳とは分けて範囲と費用を見積もります。

販売管理を残して、受注の入口と状態管理だけ作る場合

販売管理や会計のシステムを入れ替えずに、受注の受付と状態管理だけを新しく作る方法もあります。この場合、費用を左右するのは画面よりシステム同士の受け渡しです。開発を頼む前に、次の点を販売管理の提供元の資料や担当窓口で確認しておくと見積の精度が上がります。

• 販売管理がCSVやAPIでの受注の取り込みに対応しているか。取り込める項目と件数の上限
• 受け渡しの向き（受注システム→販売管理だけか、出荷・請求の結果を受注システムに戻すか）と頻度
• 取り込みでエラーになった注文を、誰がどこで直すか
• 販売管理の側に手を入れる必要がある場合、その改修を誰が引き受けるか

基幹システムのデータベースに直接書き込む方法は、提供元の保守条件に触れることがあるため、最初の前提にはしません。CSVでつなぐ場合の範囲と限界はCSV連携の開発で詳しく扱っています。

作った後に確かめる項目（検収の確認例）

受発注システムの検収では、画面が動くかよりも、例外の注文で数字が正しく残るかを確かめます。下は確認項目の例です。期待する結果を並べたもので、実際に試験した結果ではありません。実際の項目は業務に合わせて作ります。

2026年に見直しておきたい受発注の前提

受発注の仕組みを作り直すなら、次の3点は最初から要件に入れておくと後から作り直さずに済みます。いずれも適用されるか・どう対応するかは会社ごとに違うため、判断は公式資料と専門家の確認に基づいて行ってください。

自社でAIを使って進められること、開発会社に頼むこと

出典: Claude 公式

今はChatGPTやClaudeなどの生成AIで、受発注の画面の試作やデータ処理のプログラムまで社内で作れます。開発会社に頼む前に自社で進めておくと、相談の質が上がり、外注する範囲も小さくできます。

AIで作った試作は、そのまま本番に使えるものもあれば、権限・データの持ち方・テストを足す必要があるものもあります。どこを残してどこを直すかを分けたうえで、社内でAIを使った開発を続けながら一部だけを任せる進め方も選べます。

費用の目安

AI革命の受託開発の公開価格は次のとおりです（すべて税別。クラウドの利用料、外部サービスのAPI利用料、ソフトウェアのライセンス料などの実費は別）。

PoCの300万円は検証段階の開始価格で、本番システムの完成価格ではありません。本開発の金額は、上の「最初に作る範囲と後から足す範囲」の表のどこまでを含めるかと、移すデータの量、つなぐシステムの数で決まります。業務システムの費用の内訳は業務システム開発の費用でも整理しています。

開発会社によって見積に含む範囲は違います。比べるときは、データ移行、例外の注文の確認試験、販売管理側の改修、公開後の問い合わせ対応が含まれているかを揃えてから比べてください。

今の受注から請求までの流れを相談する

初回相談は無料・30分（オンライン）です。要件が決まっていなくても大丈夫です。今の受注の流れと困っている操作を伺い、相談後に依頼範囲の候補と費用の目安を相談メモでお返しします。

公開できる関連事例（受発注の事例ではありません）

AI革命が公開している受託開発の事例に、受発注システムそのものはありません。ただし、受発注の開発で問題になる論点と同じものを扱った事例が2つあります。

• 通信事業の請求データの取り込み・集計・確認画面：数万件の請求情報を取り込んで集計し、確認できる画面を作った案件です。受発注でいえば、締め日に「請求してよい数量」を集めて確認する部分に近い作業です
• 薬局の複数店舗・数千人分の記録管理：権限と確認の工程を持つ記録管理です。受発注でいえば、店舗や担当者ごとに見てよい範囲を分け、変更を確定する人を決める部分に近い設計です

いずれも業種と業務が異なるため、受発注システムの実績として扱わないでください。受発注については「対応できる範囲」として、受注台帳・画面・帳票の新規開発、既存の販売管理への画面追加、CSVやAPIでの連携、過去データの移行、利用者ごとの権限設計を引き受けられます。どのシステムとどの方法でつなぐかは、相談の中で一緒に決めます。2つの事例の公開範囲と対応範囲はAI革命の受託開発ページで確認できます。

相談の前に揃えておくと早いもの

全部揃っていなくても相談できます。手元にあるものだけで構いません。

• 今の受注の流れ（FAX・メール・電話・Webなど、注文がどこから入り、誰が何に入力しているか）
• 使っているシステムやツールの名前（販売管理、会計、Excelの台帳など）
• 困っている操作の例（変更の確定、分納の残数、取引先ごとの単位、請求の数字が合わない等）
• 変更・取消・分納が起きた注文の例（取引先名や金額を伏せた形で十分です）
• 販売管理のCSVの項目一覧や仕様書があれば、その有無
• AIで作った試作やExcelのマクロがあれば、その有無

初回の相談で、取引先の実名入りの注文データ、システムのパスワードなどの本番の認証情報、その他の秘密情報は送らないでください。

よくある質問

今のExcelの受注データは新しいシステムに移せますか？

移せます。ただし、そのまま移すと残数や請求済み数量が合わない注文が出ることがあります。上書きで管理してきたExcelには変更や取消の履歴が残っていないためです。移す期間（例：受注残がある注文だけ）と、数字が合わない注文を誰がどう確定するかを、移行の前に決めておくのが現実的です。

取引先がFAXをやめてくれなくても、受発注システムを作る意味はありますか？

あります。受発注システムで管理するのは注文が入った後の状態です。入口がFAXのままでも、受け付けた注文を台帳に登録してからの変更・分納・請求をシステムで追えれば、「今どうなっているか」には答えられるようになります。FAXの読み取りと入力の手間も減らしたい場合は、入口の自動化を別に足します。

EDIを導入するのと、受発注システムを作るのは何が違いますか？

EDIは取引先とのあいだで注文データを決まった形式でやり取りする仕組みで、社内でその注文の変更・分納・請求をどう管理するかまでは決めてくれません。EDIで受けた注文も、社内の受注台帳に入った後の管理は別に必要です。大手の取引先からEDIを指定されている場合は、そのEDIからの取り込みを受発注システムの入口の1つとして扱います。

取引先が自分で注文できるWeb画面も、同時に作るべきですか？

同時に作る必要はありません。取引先向けの画面は社外の人が使うため、取引先ごとに見える価格や商品を分ける設計と試験が別に要ります。先に社内の受注台帳と状態管理を作り、注文データの持ち方が固まってから取引先向けの画面を足すと、作り直しが少なくなります。取引先の注文の入口を変えることが一番の目的なら、Bカートのような既製の発注サイトで足りるかを先に確かめてください。

最初は小さく作って、後から機能を足せますか？

足せます。ただし、後から足すときに作り直しになりやすいのは機能ではなくデータの持ち方です。たとえば「1注文に納品は1回」という前提で作ると、後から分納に対応するときに台帳の作りから変える必要があります。最初に作らない機能でも、分納・取消・変更が起きうるかどうかだけは開発前に伝えてください。

公開後の修正や保守の費用はどう決まりますか？

公開後に何を誰が引き受けるか（障害時の調査、データの修正依頼、取引先追加や帳票変更などの改修、クラウドの管理）で決まります。開発費の何割といった一律の決め方ではなく、引き受ける範囲を一覧にしてから金額を合わせるのが確実です。社内でAIを使って軽い修正を続け、大きな改修だけを頼む分け方もできます。

まず、今の受注から請求までの流れを書き出してください

受発注システムで何を作るべきかは、機能の一覧より、変更・取消・分納が起きた実際の注文1件をたどると見えてきます。最近困った注文を1件選び、受付から請求まで「誰が・どこに・何を書いたか」を書き出してみてください。書き出した内容が、そのまま開発の範囲を決める材料になります。

今の受注から請求までの流れを相談する

初回相談は無料・30分（オンライン）です。要件が決まっていなくても大丈夫です。自社でAIを使って進める部分と任せる部分を一緒に切り分け、相談後に依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。