受注管理システムとは｜Excelで限界が来る条件と、在庫・出荷・請求までつなぐ選び方

受注管理システムとは、FAX・電話・メール・自社の受注サイト・EDI（電子データ交換）など複数の経路から入ってくる注文を一つのデータにまとめ、在庫の引き当てから出荷指示、売上・請求までを同じデータで流す仕組みです。注文を書き留める台帳ではなく、受けた注文が出荷と請求まで届くための通り道だと考えてください。

受注業務がつらくなる原因は、注文の件数そのものではありません。経路ごとに様式の違う注文を、人が社内の様式に転記して突き合わせていることです。転記が挟まっているかぎり、件数が増えるほど残業も誤出荷も増えていきます。

本記事では、受注管理システムが受け持つ範囲、Excelで限界が来る条件、注文データにかかる法令上の要件、SaaS（クラウドで提供されるソフトウェア）で足りるのか自社に合わせて作るのかの線引きまでを、開発を担う立場から整理します。

受注管理システムとは？受発注管理システムと何が違うのか#

受注管理システムとは、自社が受けた注文を起点に、受注の受け付けから売上・請求までを一本のデータで流す仕組みです。在庫の引き当てと出荷指示までつながっている点が、表計算での管理と決定的に違います。

受け持つ工程は次の5つです。

1. 1受注受付：経路ごとに届いた注文を受け取る
2. 2受注データ化：商品コード・数量・単価・納期を社内の項目にそろえる
3. 3在庫引当：出荷できる在庫を注文に割り当てて押さえる
4. 4出荷指示：出荷日・配送先・出荷単位を確定して倉庫へ渡す
5. 5売上・請求：出荷実績を売上に立て、締め日ごとに請求へ回す

この5工程のうち、どこか一つでも人の転記を挟むと、そこが全体の速度を決めます。受注を電子で受け取っていても、在庫の引き当てが別のExcelなら、引き当てが終わるまで出荷は動きません。

受発注管理システム・販売管理システムとの違いは？#

名前の似た言葉が3つあるので、先に整理します。

• 受発注管理システムは、発注する側と受注する側を電子的につなぐ「取引の仕組み」です。取引先とどうつながるかが主題で、方式ごとの違いは受発注管理システムの選び方｜EDI・Web受発注・自社開発を比較で扱っています。
• 受注管理システムは、受けた注文を社内でどう流すかが主題です。取引先とのつなぎ方は、5工程のうち最初の「受注受付」の部分にあたります。
• 販売管理システムは、見積から入金までを含む、より広い業務をまとめた呼び方です。受注管理はそのうち受注から出荷までを担う部分です。

つまり、取引先とのつなぎ方を決めたい段階なら受発注管理、社内の処理が詰まっている段階なら受注管理が検討の入口になります。

取引の電子化と、社内処理の電子化は別の話#

企業間取引そのものは電子化が進んでいます。令和6年度 電子商取引に関する市場調査 報告書｜経済産業省 商務情報政策局 情報経済課によると、2024年の日本国内のBtoB-EC市場規模は514兆4,069億円（前年比10.6%増）で、「その他」を除いたEC化率は前年から3.1ポイント増の43.1%でした。

ただし、これは取引が電子的に行われた割合であって、社内の受注処理まで電子化されたことを意味しません。**電子で受け取った注文を人がExcelに打ち直しているなら、電子化の効果はその一歩手前で止まっています。**受注管理システムの検討は、この落差を埋める作業だと考えると論点が定まります。

なぜ受注業務でミスと残業が起きるのか？#

経路ごとに様式が違う注文を、人が社内の様式へ転記して突き合わせているからです。注文が増えたからではなく、注文1件あたりに人の手が何回入るかが問題です。

受注はいくつもの経路から届く#

典型的には次の5つが並行して動いています。

• FAX・紙：取引先の注文書の様式のまま届く。手書きの追記や訂正が入る
• 電話：その場では記録が残らない。聞き取った内容を担当者がメモに起こす
• メール：本文に書かれる場合も、取引先ごとの様式のExcelが添付される場合もある
• 自社の受注サイト・ECやモール：データで届くが、商品コードや単位が自社マスタと一致するとは限らない
• EDI：項目が決まっているぶん扱いやすいが、取引先ごとに使う規約が異なる

経路を1つに統一できるなら話は簡単ですが、取引先の都合で決まる部分が大きく、現実には統一できません。経路を減らすのではなく、経路の違いを入口で吸収して社内では1つの様式にそろえる、という発想に切り替える必要があります。

転記が生むコストは3つある#

転記が残っているあいだ、次の3つが同時に発生します。

1. 1誤入力：数量の桁、単位（バラとケース）、納品先の枝番。1文字の違いが誤出荷になり、返品と再出荷の費用が二重にかかります
2. 2リードタイム：転記が終わるまで在庫は引き当たりません。締め時刻に間に合わなければ出荷は翌日にずれ、取引先から見れば納期が1日延びます
3. 3属人化：取引先ごとの例外（この取引先は単位がケース、この取引先は納品書を別送）が個人の記憶に残ります。引き継ぎができず、担当者が休めません

3つ目は見えにくいぶん、いちばん高くつきます。誤入力は件数で測れますが、属人化は担当者が辞めるまで表面化しません。**受注管理システムを入れる目的を「速くすること」だけに置くと、この3つ目が要件から抜け落ちます。**取引先ごとの例外条件をデータとして持てるかどうかを、選定の観点に入れてください。

受注データを一元化すると、この3つはそれぞれ次のように変わります。

• 入力は一度だけ：経路の違いは入口で吸収する
• 受注と同時に引き当たる：締め時刻まで受注を受けられる
• 例外が記録に残る：条件をデータとして持つ

Excel・無料ツールで足りなくなるのはどんなときか？#

次の5つの条件のうち、一つでも当てはまったら乗せ替えを検討する時期です。

• 同時に触る人が複数いる：上書きが起き、誰がいつ直したかを追えません
• 在庫の引き当てを別ファイルでやっている：受注表と在庫表が分かれていると、同じ在庫が二重に引き当たります
• 受注経路が3つ以上ある：経路が増えるほど転記の分岐が増え、例外が人に貯まります
• 取引先ごとに単価・単位・納品先が違う：条件をファイル内で管理しきれず、担当者の確認が前提の運用になります
• 注文書や注文請書を電子でやり取りしている：電子帳簿保存法の保存義務がかかります（次章）

はじめの4つは「Excelでは回らなくなる」条件です。5つ目だけは性質が違い、システムを替えれば自動的に解消するものではなく、乗せ替えのときに要件として明示しないと満たせない項目です。次章で詳しく扱います。

逆に言えば、受注担当が1人で、経路がメール1本で、在庫を持たない受託業であれば、Excelのままでも成立します。乗せ替えの判断は規模ではなく、この5条件のどれに当たっているかで決めてください。

選択肢は次の3段階です。

• Excel・無料ツール：初期費用がかからず、様式を自由に変えられます。5条件のどれにも当たっていない段階では合理的な選択です
• パッケージ・SaaS：受注から出荷・請求までの標準的な流れが最初から用意されています。自社の業務をその流れに寄せられるかが分かれ目です
• 自社に合わせた開発：業務ルールをそのまま形にできます。作る範囲が広いほど期間と費用が伸びるため、どこまでを対象にするかの線引きが要件定義の中心になります

なお、真ん中の「パッケージ・SaaS」には、標準の流れをそのまま使うやり方と、足りない部分だけを開発でつなぐやり方の2通りがあります。この分かれ目が実際の選択ではいちばん重要になるので、後の「SaaSで足りるか、自社に合わせて作るか？」で3つの進め方として並べ直します。

受注データは法令上どう扱う必要があるか？#

2つあります。電子帳簿保存法による保存義務と、2026年1月1日に改正法が施行された取適法です。どちらも「受注管理システムを入れたから対応済み」とは言えない性質のもので、要件として明示的に確認する必要があります。

電子でやり取りした注文書は、電子のまま保存する#

電子帳簿保存法一問一答【電子取引関係】令和8年7月｜国税庁は、電子取引を「取引情報の授受を電磁的方式により行う取引」と定義しています（問2）。メールへの添付、Webサイトからのダウンロード、EDI、クラウドサービスの利用は、いずれも電子取引に当たります（問5）。所得税（源泉徴収に係るものを除く）および法人税の保存義務者は、その取引情報を電磁的記録のまま保存する義務を負います（法第7条）。

保存にあたって満たす要件は次のとおりです（問18）。

• 電子計算機処理システムの概要を記載した書類の備付け（自社開発のプログラムを使用する場合に限る）
• 見読可能装置の備付け等
• 検索機能の確保
• 訂正削除の防止に関する措置、いわゆる改ざん防止措置（タイムスタンプの付与、訂正削除の記録が残るシステムでの授受・保存、事務処理規程の備付けのいずれか）

1つ目に括弧書きが付いている点に注意してください。**市販のパッケージやクラウドサービスを使う場合、この書類の備付けは求められません。**要件は4つとも同じ条件でかかるわけではありません。

検索機能には緩和があります。判定期間に係る基準期間の売上高が5,000万円以下で、税務職員によるダウンロードの求めに応じることができる場合は、検索機能の確保が不要とされています（問51）。また、要件に従って保存できなかったことについて相当の理由があると所轄税務署長が認め、電磁的記録と出力書面の双方を提示・提出できる場合の猶予措置もあります（問93以降）。

要点は、**この要件を誰が満たすのかを決めることです。**受注管理システム側で電子取引データを保存するのか、別の文書管理の仕組みに渡すのか。選定時に確認しないまま進めると、注文データは残っているのに検索要件を満たしていない、という状態になります。

取適法で、発注内容の明示に相手方の承諾が要らなくなった#

下請法を改正する法律が2026年1月1日に施行され、法律の名称が「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」（略称：中小受託取引適正化法、通称：取適法）に変わりました。2026年1月施行！～下請法は取適法へ～ 改正ポイント説明会｜公正取引委員会・中小企業庁から、受注管理に関わる点を挙げます。

• 発注内容等の明示は書面または電磁的方法により行い、中小受託事業者の承諾の有無にかかわらず電磁的方法で提供できます。ただし中小受託事業者から書面の交付を求められた場合は、遅滞なく書面を交付します
• 取引の記録を記載した書類等を作成し、2年間保存します
• 支払期日は、物品等を受領した日から起算して60日以内のできる限り短い期間内で定めます
• 受領した日から起算して60日を経過した日から実際に支払が行われる日までの期間について、**年率14.6%**の遅延利息を支払います

改正前も相手方の承諾を得れば電磁的方法による提供はできました。変わったのは承諾を取る手続きが要らなくなったことです。

自社が受注する側なら、発注内容が電子で届く前提でシステムを組めばよいことになります。承諾の手続きが不要になったぶん、取引先から電子で受け取る経路は今後増えると考えておくのが自然です。一方、自社が一部を外注していて委託事業者に当たる場合は、発注データの控えを2年間残せる形にしておく必要があります。どの取引類型・どの事業者区分が対象になるかは取引の種類ごとに分かれているため、自社が該当するかは上記の資料で確認してください。

社内確認に使えるチェック項目#

要件定義の前に、次の6点を社内で確認しておくと議論が具体的になります。

• 注文書・注文請書・見積書のうち、電子でやり取りしているものはどれか
• そのデータを電磁的記録のまま保存しているか、印刷して紙で保管していないか
• 取引年月日・取引金額・取引先で検索できる状態にあるか
• 改ざん防止措置を、タイムスタンプ・訂正削除記録・事務処理規程のどれで満たすか
• 基準期間の売上高が5,000万円以下か（検索機能の確保が不要になる条件に当たるか）
• 自社が委託事業者に当たる取引があるか。ある場合、発注内容の控えを2年間残せるか

SaaSで足りるか、自社に合わせて作るか？#

多くの会社にとっての現実解は、受注管理の本体はパッケージやSaaSを使い、自社固有の部分と他システムとのつなぎ込みだけを開発するやり方です。全部を作る必要も、全部を既製品に寄せる必要もありません。

判断するときは、次の5つの観点で並べると差がはっきりします。

パッケージ・SaaSは、受注から出荷・請求までの標準的な流れが用意されています。自社の業務をその流れに寄せられるなら、これがいちばん速く安定します。逆に、寄せられない条件がいくつも出てくるなら、運用でカバーする負担が毎日続くことになります。

パッケージ＋連携開発は、本体を既製品に任せ、足りない部分だけを個別に作ります。たとえばFAXで届く注文を読み取って受注データに変換する部分、取引先ごとの単価テーブルを持つ部分、在庫管理システムや会計システムとつなぐ部分です。**「どこまでが既製品の範囲で、どこからが開発か」を要件定義で線引きできれば、費用と期間の見通しが立ちます。**在庫側の設計、とくに複数チャネルで在庫を共有する場合の考え方は店舗在庫とECの在庫一元管理｜OMS・API連携の仕組みと選び方で扱っています。

自社に合わせた開発が向くのは、受注の処理そのものが競争力になっている場合です。特殊な出荷単位、複雑な価格体系、受注と同時に生産計画が動く業態などが当てはまります。判断の目安は、業務ルールを既製品に合わせて変えたときに、その変更を取引先や現場に説明できるかどうかです。変更を説明できないルールなら、それは自社固有の価値である可能性が高いといえます。

なお、費用は選択肢そのものより「作る範囲」で決まります。初期費用・月額・連携開発・保守という4つの内訳のうち、どこが自社で大きくなるのかを見積もりの段階で分けて確認してください。金額そのものは要件しだいですが、内訳の重心には傾向があります。パッケージ・SaaSは初期が軽く月額が続く形になり、自社に合わせた開発は初期が厚いかわりに月額の固定費は小さくなります。連携開発は本数がそのまま保守の対象になるため、つなぎ先を1つ増やすかどうかは初期費用だけでなく毎年の保守費の判断でもあると考えてください。

導入はどの順で進める？#

受注経路の棚卸しから始め、データ項目をそろえ、つなぎ先を決め、一部の取引先で試してから広げます。システムの選定を先にしないことが、失敗を避けるいちばんの近道です。

1. 1受注経路の棚卸し：どの経路から何件届くかを数える
2. 2データ項目の標準化：商品コード・単位・単価の持ち方をそろえる
3. 3連携設計：在庫・出荷・会計のどこまでつなぐかを決める
4. 4試行：一部の取引先で流してみる
5. 5展開と定着：残りの取引先と経路へ広げる

最初の2つが土台です。経路ごとの件数を数えないまま製品を比較すると、件数のごく少ない経路のために要件が引っ張られる、ということが起こります。まず1か月分でよいので、経路別の件数と、1件あたりに何分かけているかを実測してください。

よくある落とし穴は次の4つです。

• マスタを直さないまま乗せ替える：商品コードの重複や単位の混在は、システムを変えても解決しません
• 例外を全部システムに入れようとする：取引先ごとの例外をすべて作り込むと、期間も費用も見積もりを超えます。件数の多い例外から順に入れ、残りは運用で持つ判断も必要です
• 取引先に様式変更を一斉に求める：相手の都合で決まる部分なので、こちら側で吸収する設計を先に考えます
• 出荷・配送側の都合を後回しにする：受注の締め時刻は、出荷と配送の制約から逆算して決まります。この観点は食品・宅配/物流のシステム化｜受注・在庫・配送を効率化する基幹＆現場DXでも扱っています

試行の段階では、処理が速くなったかよりも、例外がどこで止まったかを記録できているかを確認してください。止まった場所が分かれば、次に作るべき範囲が決まります。

弊社（株式会社TryWith）の受注管理システム開発について#

弊社では、受注業務のシステム化を、開発を担う立場からご支援しています。受注経路の棚卸しと件数の実測、商品コードや単位のマスタ整備、在庫・出荷・会計とのつなぎ込みの設計、そして一部取引先での試行から全体への展開まで、優先順位を付けて一緒に進めます。電子帳簿保存法の保存要件をどの仕組みで満たすかも、要件定義の段階で整理します。

パッケージやクラウドサービスで足りる部分はそれを活かし、自社の商流に固有の部分だけを個別に作る——過不足のない落としどころを、運用とコストの両面から検討します。要件定義から設計・開発・運用までをワンストップでお引き受けする体制はシステム開発にまとめています。

よくある質問（FAQ）#

Q. 受注管理システムと販売管理システムは何が違いますか？

A. 販売管理システムは見積から入金までを含む広い呼び方で、受注管理はそのうち受注から出荷までを担う部分です。製品として一体になっていることも多いので、検討の際は「自社で詰まっているのはどの工程か」を先に決めると要件が噛み合います。

Q. Excelのままで問題ない会社はありますか？

A. あります。受注担当が1人で、受注経路が1つで、在庫の引き当てを伴わない業態であれば、Excelのままでも成立します。同時編集・在庫引当・経路の数・取引先ごとの条件・電子取引データの保存という5つの条件のどれにも当たっていないかを確認してください。

Q. FAXで届く注文も取り込めますか？

A. 取り込む仕組みは作れますが、読み取りの精度は注文書の様式と記入のされ方に左右されます。件数を実測したうえで、自動で読み取る範囲と人が確認する範囲を分けて設計するのが現実的です。全件を自動化しようとすると費用が跳ね上がります。

Q. 受注管理システムを入れれば電子帳簿保存法の対応は済みますか？

A. 済むとは限りません。電子取引データの保存要件（見読可能装置の備付け等、検索機能の確保、訂正削除の防止に関する措置、および自社開発のプログラムを使う場合のシステム概要書類の備付け）を、そのシステムが満たすのか、別の仕組みに渡すのかを個別に確認する必要があります。判定期間に係る基準期間の売上高が5,000万円以下でダウンロードの求めに応じられる場合は、検索機能の確保が不要とされています。

Q. パッケージ・SaaSと自社に合わせた開発は、どちらを選べばよいですか？

A. 多くの会社では、本体をパッケージ・SaaSに任せ、足りない部分だけを開発でつなぐ「パッケージ＋連携開発」が現実的です。自社に合わせた開発が向くのは、特殊な出荷単位や複雑な価格体系など、受注の処理そのものが競争力になっている場合に限られます。業務ルールを既製品に合わせて変えたとき、その変更を取引先や現場に説明できるかどうかが分かれ目です。

Q. 取引先ごとに注文の様式が違っても使えますか？

A. 使えますが、そのための設計が要ります。取引先ごとの商品コード・単位・単価・納品先を対応表として持ち、入口で自社の様式に変換する形にします。この変換をシステムに持たせるか担当者の確認に任せるかが、属人化するかどうかの分かれ目です。

Q. 在庫管理システムがあれば受注管理は要りませんか？

A. 在庫管理システムは在庫数を保つ仕組みで、受注の受け付けと出荷指示までは守備範囲に含まないものもあります。両方を兼ねる製品もあるので、受注から出荷までの工程がその製品でつながるかを確認してください。

まとめ#

受注管理システムは、複数の経路から届く注文を一つのデータにまとめ、受注受付・受注データ化・在庫引当・出荷指示・売上と請求までを一本で流す仕組みです。業務がつらくなる原因は件数ではなく、経路ごとに様式の違う注文を人が転記していることにあります。転記は誤入力・リードタイム・属人化という3つのコストを同時に生み、なかでも属人化は担当者が辞めるまで表面化しません。

乗せ替えの判断は規模ではなく条件で決めてください。同時に触る人が複数いる、在庫引当が別ファイル、受注経路が3つ以上、取引先ごとに条件が違う、注文書を電子でやり取りしている——このどれかに当たっていれば検討の時期です。注文データには電子帳簿保存法の保存義務がかかるため、保存要件を誰が満たすのかを選定時に決めてください。2026年1月1日に改正法が施行された取適法では、発注内容等の明示を中小受託事業者の承諾の有無にかかわらず電磁的方法で提供できるようになりました。

進め方は、受注経路の棚卸し・データ項目の標準化・連携設計・試行・展開と定着の順です。製品の比較より先に、経路別の件数と1件あたりの所要時間を実測してください。多くの会社にとっての落としどころは、本体を既製品に任せ、自社固有の部分とつなぎ込みだけを開発する形になります。

出典：令和6年度 電子商取引に関する市場調査 報告書｜経済産業省 商務情報政策局 情報経済課／電子帳簿保存法一問一答【電子取引関係】令和8年7月｜国税庁／2026年1月施行！～下請法は取適法へ～ 改正ポイント説明会｜公正取引委員会・中小企業庁

「受注のたびに転記が発生している」「在庫の引き当てが追いつかない」という段階からご相談いただけます。まずはお問い合わせはこちらからお気軽にご相談ください。