基幹システムの刷新時期の見極め方｜老朽化した受発注・請求を止めずに延命か置き換えかを選ぶ基準

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

B2B EC-COLUMN

古いシステムで受発注・請求は回っている。それでも刷新を考えるべき状態とは

受注も請求も、今のところ基幹システムで回っています。
ただ、改修を頼める保守先が減った、取引先から新しい受注方法を求められた、請求の締め処理を一人しか触れない、といった状態が重なると、刷新の選択肢は気づかないうちに狭まります。
動く時期を決める物差しは、導入からの年数ではありません。
維持保守や機能改良をまだ続けられるか、外部の変更に期限内に対応できるか、属人化がどこまで進んでいるか、止まったときの影響はどこまで及ぶか、の4点で自社を見ます。
そのうえで延命・部分改修・置き換え・全面刷新を同じ軸で比べ、業務の棚卸しから範囲を絞り、締め日を避けた切替計画まで決めれば、決裁者に説明できる材料がそろいます。

「古い」と「レガシー」は違う

導入から十数年たったシステムを前にすると、「さすがにもう古い」という感覚が先に立ちます。
ただ、経済産業省とIPAのレガシーシステムモダン化委員会の総括レポートを解説したIPAの資料では、レガシーシステムは導入からの年数で決まるものではなく、ビジネスの変化に合わせた維持保守や機能改良をしたくてもできなくなった状態を指すと整理されています²。
メインフレームやCOBOLのような古い技術で動いていても、継続して改良できているなら該当しないという扱いです²。

この整理を受発注・請求に当てはめると、見るべきものが変わります。
たとえば15年使っている販売管理でも、新しい取引先の登録や単価改定、請求書の項目追加にベンダーが応じてくれているなら、急いで替える理由は年数からは出てきません。
反対に、導入して数年のパッケージでも、独自の改造を重ねた結果として製品の更新版を当てられず、改修の見積もりも断られているなら、状態としてはレガシーに近づいています。

社内で説明するときにも、この違いは効きます。
「古いから替えたい」という提案は、「まだ動いているのに」という反論で止まりがちです。
「この変更に応じられない」「この処理を扱える人が一人しかいない」と状態で示せば、何が困るのかが決裁者にも見えます。

判断に使う4つの兆候

状態を見る観点として、ここでは次の4つを使います。
年数の代わりに置く物差しとして編集部が整理したもので、どこからが危ないかという数値の基準があるわけではありません。

• 維持保守・機能改良：改修や設定変更を頼める相手がいて、実際に応じてもらえているか
• 外部の変更への対応：取引先の受注方法や請求書の扱い、制度、システムを動かしている基盤の変化に、期限内に応じられるか
• 手作業・属人化：システムの外で転記や計算をしている量と、特定の人しか扱えない処理の多さ
• 止まったときの影響：受注入力や請求発行が止まると、出荷・入金・取引先への連絡のどこに及ぶか

4つは互いにつながっています。
改修を頼める相手がいなくなると、外部の変更は手作業で埋めるしかなくなり、その手作業は慣れた担当者に集まります。
その担当者が休んだ日に請求が出せなければ、止まったときの影響はそのまま取引先に及びます。
どれか一つが「できない」側に寄っていれば、そこから連鎖が始まっていないかを確かめる、という読み方が実際的です。

中でも手作業・属人化は、本人が気づきにくい兆候です。
受注をシステムに入れた後、取引先別の掛率だけ表計算ソフトで計算して戻している、月末に特定の担当者だけが知る手順で請求データを直している、といった処理が仕様書に残っていないなら、それはシステムの外にある独自業務です。
IPAの資料も、ブラックボックス化した仕様を復元して文書化する作業を、進め方の初めの段階に置いています²。

自社の現状を確かめる棚卸しの入口

4つの兆候を判定するには、手元のシステムが何でできていて、どこにつながっているかが分かっている必要があります。
IPAの資料は、モダン化をIT資産とその相互関係の可視化から始め、その中で保守期限切れなどのリスクを特定するとしています²。
大企業を含む一般的な進め方として示されたものですが、数十名規模でも最初の一歩は変わりません。

規模が小さい会社なら、表計算ソフトに1行1システムで書き出すところから始められます。

• システム名と担う業務（受注、在庫、出荷、請求、会計など）
• 動いている環境（パソコンかサーバーか、OS・データベース・パッケージの版）
• つながる先（会計ソフトへのデータ受け渡し、取引先からのFAX・メール・Web受注、出荷ラベルの発行など）
• 保守を頼んでいる相手と契約の期間
• 操作や設定変更ができる社内の人

この表を作ると、つながりの中に「この人がこのファイルを手で移している」という箇所が見つかることがあります。
そこが属人化の兆候であり、同時に刷新のときに必ず扱いを決めなければならない接点です。
保守期限も、この表の環境の欄に版が書いてあれば調べられます。

▼ 図の内容を文字で読む

1. 改修を頼める相手がいなくなる
2. 外部の変更を手作業で埋める
3. 手作業が慣れた担当者に集まる
4. 担当者が休んだ日に請求が出せない
5. 影響が取引先に及ぶ

保守終了・取引先や制度の変更は、自社の受発注・請求の期限になるのか

基盤の保守期限の確かめ方

外部の変化のうち、いちばん期限に近いのは、システムを動かしている基盤の保守期限です。
基盤といっても一つではありません。
OS、データベース、販売管理などのパッケージ本体、サーバーやパソコンの機器、そしてそれらを見てもらっているベンダーとの保守契約は、それぞれ別の期限を持っています。

どれが先に切れるかは構成によって違うため、一般論の日付では判断できません。
先ほど書き出した表の環境の欄をもとに、OSとデータベースは提供元が公開しているサポート期間、パッケージは販売元、機器と保守契約は契約書とベンダーへの問い合わせで、一つずつ確かめます。

問い合わせるときは「いつまで使えるか」ではなく、期限の後に何が受けられなくなるかを分けて聞くと判断に使えます。
不具合の修正、セキュリティの更新、操作の問い合わせ、機器の部品交換のどれが止まるのかは、製品や契約によって違います。
また、OSの期限が来て新しいOSに移ろうとしたとき、使っているパッケージの版がそのOSに対応していなければ、実際の期限はOSではなくパッケージ側で決まります。
部品同士の対応関係まで聞いておくと、期限の見落としが減ります。

取引先の要請と制度対応は「自社が対象か」から確認する

取引先からの要請は、ある日届く連絡で始まります。
主要な取引先が発注をWebの発注画面や電子データでの受け渡しに切り替える、請求書を電子で送るよう求める、商品コードの体系を変える、といった連絡です。
このとき最初に分けたいのは、対応しないと取引そのものに響くのか、対応したほうが便利になるだけなのか、という点です。
期日と、対応しない場合の扱いは、取引先に直接聞かないと分かりません。

制度への対応も同じ順で考えます。
請求書の記載内容や取引データの保存方法にかかわる制度は、自社が対象になるか、対象ならシステムの改修が必要か、運用の手順で足りるかによって、必要な作業が大きく変わります。
適用の時期や例外は見直されることがあるため、所管官庁の最新の資料と顧問税理士で自社の扱いを確かめてから、システム側の要否を判断します。

ここで大事なのは、外部の変化がそのまま刷新の期限になるわけではないということです。
期限として扱う必要があるのは、次の3つが重なったときです。

• 期日が取引先や制度の側で決まっている
• 今のシステムでは応じられない（出力形式を変えられない、項目を足せないなど）
• 手作業で埋めると、件数や締めの日程から見て回らない

たとえば取引先1社が電子データでの発注に切り替える場合、旧システムが受注データの取り込みに対応していなくても、件数が少なければ画面から入力し直して当面しのぐ選択はあります。
同じ要請が主要な取引先から同時期に重なれば、転記の量が担当者の手に余り、3つ目の条件が満たされます。
一つずつは改善候補でも、重なると期限に変わるという見方をしておくと、慌てて全面刷新を決めることも、気づかずに期日を越えることも避けやすくなります。

補助金を使える場合の条件

受発注や請求の仕組みを替える場合、国の補助金が選択肢に入ることがあります。
中小企業基盤整備機構が案内するデジタル化・AI導入補助金2026のインボイス枠（インボイス対応類型）では、会計・受発注・決済のうち1機能以上を持つインボイス対応のソフトが対象とされ、50万円超〜350万円以下の区分では2機能以上が必要です⁴。
導入コンサル、導入設定、研修、保守サポートといった役務も対象経費に挙がっています⁴。

裏返すと、補助の対象は要件に合うソフトとそれに付く役務であり、独自の作り込みを含む刷新費用の全体を補う仕組みとして見込むことはできません。
要件は公募回ごとに変わることがあり、申請しても採択されるとは限りません。
補助金ありきで時期を決めるのではなく、選んだ方式の中で対象になる部分があれば負担を下げる手段として扱い、細かな要件は公募要領で確かめます。
補助率は会社の区分で変わるため、区分の定義とあわせて着手の順序の中で確かめます。

▼ 図の内容を文字で読む

• 外部の変化
  • 基盤の保守期限
  • 取引先の要請
  • 制度対応
• 期限として扱う3つの条件
  • 期日が取引先や制度の側で決まっている
  • 今のシステムでは応じられない
  • 手作業で埋めると回らない
• 自社の期限
  • 3つが重なったとき期限に変わる

延命・部分改修・置き換え・全面刷新をどう選び分けるか

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

ここまでで、自社の兆候と外部の期限が見えてきました。
次は、どう手を打つかです。
選択肢は大きく4つに分けられます。

• 延命：今のシステムを使い続け、保守契約の更新や基盤の入れ替えなど、動かし続けるための手当てに絞る
• 部分改修：今のシステムを残したまま、困っている機能だけを直すか、周辺に別の仕組みを足す
• 置き換え：受発注・請求など範囲を決めて、パッケージやクラウドサービスへ段階的に移す
• 全面刷新：基幹システム全体を一度に作り直す、または入れ替える

比べる軸は、4つの兆候をそのまま使います。
選択肢ごとに別の物差しを当てると、延命は「費用が安い」、全面刷新は「すっきりする」と、比べているようで比べていない状態になるためです。
費用は規模や範囲で大きく変わり、見積もりを取る前に相場の数字で埋めると判断を誤らせるので、見積もり取得後に埋める欄として残しています。

表の中で判断が分かれるのは、保守の欄と独自業務の欄です。
延命と部分改修は、どちらも今のシステムを直せる人が残っていることが前提で、その前提が崩れていれば選べません。
置き換えと全面刷新の違いは、独自業務をどこまで新しい仕組みに持ち込むかにあり、持ち込むほど全面刷新に近づき、作り込みの量も増えます。

状況別の選び方

表を自社に当てはめると、選択肢はかなり絞られます。
いくつかの組み合わせで考えてみます。

保守先がまだ応じてくれていて、期限のある外部の変更が1か所だけなら、部分改修が第一候補です。
たとえば取引先1社の請求書様式の変更なら、その出力だけを直すか、旧システムから出したデータを別の仕組みで整形する方法が考えられます。
ただし同じ箇所に次の変更が来るたびに改修が必要になるなら、改修費が積み重なる構図になっていないかを見ておく必要があります。

保守先が撤退を予定している、あるいは基盤の期限が迫っていて改修そのものを頼めない場合、延命は期限までのつなぎにしかなりません。
延命で得た時間を、置き換えの準備に充てるという位置づけで計画します。
保守契約を一時的に延ばせる場合も、延ばした期間の終わりが本当の期限になります。

取引先別の特殊な処理が多い場合は、置き換えか全面刷新かで迷いやすくなります。
ここでは、すべてを新しい仕組みで再現しようとせず、標準の機能で回る部分と、自社にしかない部分を分けることが先です。
独自部分が受発注のごく一部に集まっているなら、本体はパッケージやクラウドサービスへ置き換え、独自部分だけを周辺で扱う形が取れます。

全面刷新は範囲が最も広い分、計画と移行の負担も最も大きくなります。
IPAの資料は、大規模システムのモダン化は計画に数年を要し、途中で遅延しやすいと指摘しています²。
数十名規模の会社のシステムはそこまでの規模ではないにしても、一度に切り替える範囲が広がるほど、受発注・請求が不安定になる期間と、影響を受ける取引先が増えるという構図は同じです。
全面刷新を選ぶのは、どの部分を残しても次の外部変更に応じられないなど、範囲を区切る意味がないときに限るのが現実的です。

現行踏襲にこだわらない考え方

置き換えを選んだとき、つまずきやすいのが「今と同じ画面、同じ帳票」を求めることです。
IPAの資料は、パッケージやSaaS（インターネット経由で使うソフト）、標準的なシステムの採用を、現行踏襲にこだわらず検討し、ゼロから作り込むスクラッチ開発は避けて、標準部分と付加価値部分を分けるという方向を示しています²。
中小企業向けに要件定義の進め方をまとめたIPAの小冊子も、作り込みを避け、パッケージやクラウドを活用しながら段階的に試すことを要点に挙げています³。
この小冊子は2019年に公開された要件定義全般の手引きで、基幹システムの刷新に限ったものではありませんが、作り込みを抑えるという考え方は共通しています。

では、どこまでが標準で、どこからが付加価値なのか。
判断の手掛かりは、その独自処理をやめたときに何が起きるかです。
取引先ごとに請求書の並び順が違う、という処理は、取引先に相談して標準の様式に寄せられるなら慣習にすぎません。
一方、取引先との契約で決まった独自の掛率体系や、自社の強みになっている納期回答の仕組みは、やめれば取引条件や売上に響く付加価値かもしれません。

標準に合わせる方向をとるのは、数十名規模の会社では、作り込んだ部分を直し続ける人手を確保しにくいからでもあります。
ただし、この方向が費用や期間の面で必ず有利になるとは言えません。
独自部分を残す仕組みとの組み合わせ方によっては見積もりが逆転することもあるため、最終的には同じ範囲で取った見積もりで比べます。

▼ 図の内容を文字で読む

• 部分改修
  • 保守先がまだ応じてくれる
  • 期限のある外部の変更が1か所だけ
• 延命
  • 保守先の撤退や基盤の期限で改修を頼めない
  • 期限までのつなぎとして置き換えの準備に充てる
• 置き換え
  • 取引先別の特殊な処理が多い
  • 標準で回る部分と自社にしかない部分を分ける
• 全面刷新
  • どの部分を残しても次の外部変更に応じられない
  • 範囲を区切る意味がないときに限る

小規模の会社は、何から着手し、どの順で進めるか

業務・帳票・取引先別ルールの棚卸し

選択肢がまだ決まっていなくても、先に進められる作業があります。
業務・帳票・取引先別ルールの棚卸しです。
延命を選んでも置き換えを選んでも、この結果は使います。

最初に書き出したのはシステムの側の一覧でした。
ここで書き出すのは業務の側で、受注から入金までの流れに沿って、誰が何を受け取り、何を入力し、何を出しているかを並べます。

• 業務の流れ：受注の受付、在庫の引当、出荷指示、納品、請求、入金の消込、仕入先への発注
• 帳票：納品書、請求書、発注書、出荷ラベルなどの様式と送付方法（郵送、FAX、メール、電子データ）
• 取引先別ルール：締め日、単価や掛率の決め方、請求書の様式の指定、発注を受ける手段

書き出した項目には、標準と付加価値を分ける考え方で「標準でよい」「独自が必要」「やめられる」の印を付けます。
IPAの資料も、システムを仕分けて優先度を付け、本当に必要な範囲を見極めることを進め方として挙げています²。
印を付ける途中で担当者にしか分からない処理が出てきたら、その担当者に実際の操作を見せてもらい、手順を文章に残します。
この記録は、刷新しない場合でも属人化を一つ減らします。

要件を絞ってベンダーを早く巻き込む

棚卸しで「独自が必要」の印が付いた項目と、外部の期限に関わる項目が、新しい仕組みに必ず求める要件の候補になります。
ここで要件を広げすぎないことが、範囲を絞るいちばん確かな手段です。

IPAの中小企業向け小冊子は、要件定義の要点として、対話による小さな改善の積み上げ、業務改善と経営全体の変化、段階的な試行とパッケージ・クラウドの活用、RFP（提案依頼書）によるベンダー企業の早期巻き込みの4つを挙げています³。
社内で完璧な仕様書を作ってから業者を探すのではなく、絞った要件をRFPにまとめ、早い段階から複数のベンダーと対話して、標準の機能で足りる部分を確かめていく進め方です。

人手の面では、担当者が受注や請求の通常業務と並行して刷新に関わることになります。
IPAの資料は、ベンダーと共同でロードマップを作り、人的リソースを平準化することを挙げています²。
月末の締めや繁忙期に棚卸しや確認作業が重ならないよう、作業の山をベンダーと一緒に月ごとに並べておくと、通常業務を崩さずに進めやすくなります。

ここまでの作業を順に並べると、次のようになります。

1. システムとつながりを書き出し、4つの兆候を判定する
2. 基盤の保守期限と、取引先・制度の期日を確かめる
3. 業務・帳票・取引先別ルールを棚卸しし、標準・独自・やめられるに仕分ける
4. 必須の要件を絞ってRFPにまとめる
5. 複数のベンダーと対話し、範囲と作業の時期をロードマップにする
6. 小さな範囲で試し、切替の計画を立てる

「小規模」の制度上の定義と補助率の違い

「うちは小規模だから」という言い方は社内でよく使われますが、制度上の「小規模」は別の基準で決まります。
中小企業基本法上の区分では、小規模企業者は卸売業などの商業で常時使用する従業員5人以下、製造業などその他の業種で20人以下とされています¹。
中小企業者は、卸売業で資本金1億円以下または従業員100人以下、製造業などで資本金3億円以下または従業員300人以下で、どちらか一方に当てはまれば該当します¹。

これを当てはめると、従業員が数十名の卸・商社は小規模企業者ではなく中小企業者に当たります。
製造業なら従業員20人以下で小規模企業者に入るため、「数十名」という感覚でも、常時使用する従業員を数え直すと区分が変わる場合があります。

この区分は補助率に効きます。
インボイス枠では、ソフトウェアの補助率は中小企業が3/4以内、小規模事業者が4/5以内で、50万円を超える部分は2/3以内です⁴。
補助金での区分の判定は公募要領に従うため、申請を考えるなら、自社の業種と従業員数を公募要領の定義で確かめてから自己負担の見込みを出します。

切り替え時に受発注・請求を止めない移行時期と並行稼働の決め方

切替日の置き方

方式と範囲が決まったら、旧システムから新しい仕組みへいつ切り替えるかを決めます。
ここから先は、締め日や取引先の事情で答えが変わる部分なので、考え方と確かめ方を中心に説明します。

切替日を決める出発点は、自社の締めと請求の日程です。
月末締めで翌月初めに請求書を出している会社なら、請求の発行を終えた直後に切り替えると、次の締めまでの間に新しい仕組みで受注や出荷を処理しながら、問題を見つけて直す時間が取れます。
反対に、締めの直前や請求の発行日、決算や棚卸の時期、繁忙期に切り替えると、問題が出たときに直す時間がなく、請求の遅れがそのまま取引先と入金に及びます。

取引先ごとに締め日が15日、20日、末日と分かれている場合は、どの日に切り替えてもどこかの締めにかかります。
この場合は、締め日の集まりが少ない時期を選ぶか、締め日ごとに取引先をまとめて段階的に新しい仕組みへ移す方法が考えられます。
段階的に移すと、しばらくは旧と新の両方を使うことになるため、どの取引先がどちらで処理されているかを一覧で管理しておくことが前提になります。

切替の前日までに、旧システムでの売掛残高、在庫数量、まだ出荷していない受注を確定させておきます。
この3つが新しい仕組みの出発点になり、ずれていると切替後の請求と在庫がすべて食い違うためです。

並行稼働で突き合わせる項目

並行稼働とは、一定の期間、同じ取引を旧システムと新しい仕組みの両方で処理し、結果を比べることです。
新しい仕組みの計算や設定の誤りを、請求書が取引先に届く前に見つけられるのが利点で、代わりに入力の手間が一時的に倍になります。

突き合わせる項目は、間違えると取引先に影響が出るものに絞ります。

• 取引先別の請求額と消費税額
• 商品別の在庫数量
• 未出荷の受注の件数と内容
• 取引先別の売掛残高

進め方は一度で終わりではありません。
同じ取引を新旧両方で処理し、締めで請求額と在庫を出し、新旧の結果を突き合わせて差異があれば原因を特定して新しい仕組みの設定やデータを直し、次の締めでまた同じことを繰り返します。
差異が出なくなるか、出た差異の理由がすべて説明できるようになるまで回すため、何回の締めで差異が説明できれば並行稼働を終えるかを、始める前に決めておきます。
終わりの条件がないと、二重入力が続いて現場が疲弊します。

取引件数が多く二重入力の負担が重い場合は、並行稼働をしない選択もあります。
その代わり、旧システムを参照用に残し、切替後最初の締めで、新しい仕組みが出した請求額を旧システムでの計算方法と取引先ごとに照らし合わせます。
単価改定や掛率の例外がある取引先から優先して照合すると、差異の出やすいところを先に押さえられます。

データ移行の範囲

旧システムのデータをどこまで移すかも、切替の負担を左右します。
新しい仕組みで処理を続けるために必要なのは、取引先・商品・単価などのマスタ、売掛残高や在庫数量、まだ完了していない受注です。
過去の取引履歴は、移さずに旧システムやそこから出したファイルを参照用に残す選択もあります。

どちらを選べるかは、旧システムの出力機能で決まります。
マスタや履歴をCSVなどの形式で書き出せるか、書き出せる項目に取引先別の単価や掛率まで含まれるかは、早い段階でベンダーか操作できる担当者に確かめておきます。
書き出せない項目は手で入力し直すことになり、その量がそのまま移行の作業量になります。

過去データを参照用に残す場合は、旧システムをいつまで動かせるかが問題になります。
基盤の保守期限が切れた後も参照のために動かし続けるのか、必要な期間分をファイルにして旧システムは止めるのかを決めます。
帳簿や取引の記録として保存が求められるデータに当たるかどうかは税理士に確かめたうえで、保存の方法を選びます。

移す範囲を広げるほど、移行後に突き合わせる範囲も広がります。
範囲を区切るほど確認の負担が小さくなるのは、方式を選んだときと同じ構図です。

▼ 図の内容を文字で読む

1. 同じ取引を新旧両方で処理
2. 締めで請求額と在庫を出す
3. 新旧の結果を突き合わせる
4. 差異の原因を特定して直す

決裁者に説明する材料をどうそろえるか

説明の1枚にまとめる項目

ここまでの作業で、刷新の可否と時期を説明する材料はほぼそろっています。
残るのは、それを決裁者が判断できる形にまとめることです。
IPAの資料は、モダン化を経営課題と捉え、経営層が関与してトップダウンで決断し、継続的に取り組むことを求めています²。
担当者の提案で終わらせず、経営として決める事柄だと位置づけてもらうには、判断に必要なことが1枚で見える資料が役立ちます。

1枚にまとめる項目は次のとおりです。

• 4つの兆候の判定：どの観点が「できない」側に寄っているか、その根拠となった出来事
• 外部の期限：基盤の保守期限、取引先の要請、制度対応のそれぞれについて、期日と確認した相手
• 選択肢の比較と推奨：4つの選択肢を同じ軸で比べた表と、推奨する選択肢の理由
• 範囲と時期：置き換える業務の範囲、切替予定の時期、避ける締めや繁忙期
• 社内の体制：担当者と、棚卸しや並行稼働にかかる社内の作業時間の見込み
• 費用：見積もりの内訳と、補助金を使う場合の見込み
• 手を打たない場合：期限を越えたときに止まる業務と、手作業で代替できる範囲

決裁の場で見落とされやすいのが、最後の「手を打たない場合」です。
刷新の利点を並べるより、期限を越えたときに請求が出せなくなるのか、手作業でしのげるのかを具体的に示すほうが、時期を決める理由がはっきりします。

提案する人と決める人が同じ場合、つまり経営者自身が情報システムを兼ねている場合も、この1枚は役に立ちます。
判断の根拠を残しておけば、刷新を見送ったときも、どの条件が変わったら見直すかが後から分かります。

費用欄の埋め方

費用欄は、ベンダーから見積もりを取ってから埋めます。
相場の数字を先に入れると、見積もりが出たときに高い・安いの話になり、範囲や方式の比較が抜け落ちるためです。

見積もりを比べやすくするには、内訳の欄をあらかじめ決めて、各社に同じ形で出してもらいます。

• 初期にかかるもの：ソフトの利用料や購入費、導入設定、データ移行、研修
• 継続してかかるもの：月額や年額の利用料、保守サポート
• 社内でかかるもの：棚卸し、要件の整理、並行稼働の二重入力にかかる担当者の時間

延命を選ぶ場合の費用も、同じ欄で並べます。
保守契約の更新、基盤の入れ替え、外部の変更を手作業で埋めている時間は、刷新しない場合にもかかり続ける費用です。
延命の欄が空のままだと、刷新の費用だけが目立ち、比較になりません。

補助金を使う場合は、対象になる部分を見積もりの中で分けておきます。
インボイス枠では導入設定や研修、保守サポートといった役務も対象経費に挙がっているため⁴、ソフト本体と役務を分けた見積もりにしておくと、公募要領と照らし合わせやすくなります。
採択が決まるまでは、補助がない場合の自己負担でも判断できるようにしておくのが安全です。

兆候の判定や外部期限の確認までは社内で進められても、取引先別のルールのどこまでを標準に合わせられるかは、受発注の実務を見てきた相手と話すほうが判断しやすくなります。

棚卸しした受発注・請求の流れと取引先別ルールをもとに、標準で回せる部分と独自に残す部分の切り分けを一緒に確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
刷新の時期	年数ではなく、維持保守・機能改良の可否、外部変更への対応、手作業・属人化、止まったときの影響で見る
外部の変化が期限になるとき	期日が外で決まり、今のシステムで応じられず、手作業で埋めると回らない
選択肢の比べ方	延命・部分改修・置き換え・全面刷新を同じ軸で比べ、費用は見積もり取得後に埋める
置き換えの方向	現行踏襲にこだわらず、標準部分に業務を合わせ、独自部分を絞る
最初の作業	システムとつながり、業務・帳票・取引先別ルールの棚卸し
補助金	インボイス枠は対象ソフトと役務。ソフトの補助率は中小企業3/4以内、小規模事業者4/5以内
切替	締め・請求発行・繁忙期を避け、請求額・在庫を突き合わせる終わりの条件を先に決める

切替日や並行稼働の終わりの条件は、締め日や取引先の数、旧システムの出力機能で変わり、記事だけでは自社の答えを決めきれません。 自社の締めの日程と取引先の構成をもとに、切り替える範囲と順序、突き合わせる項目の候補を整理できます。

よくある質問

数十名規模の卸売業は、制度上「小規模事業者」として補助金の高い補助率を受けられますか。

中小企業基本法上の区分では、卸売業などの商業で小規模企業者に当たるのは常時使用する従業員5人以下です¹。
数十名の卸売業は、従業員100人以下または資本金1億円以下の中小企業者に当たります¹。
インボイス枠のソフトウェアの補助率は、中小企業が3/4以内、小規模事業者が4/5以内です⁴。
補助金での区分の判定は公募要領に従うため、申請前に定義を確かめてください。

基幹システムの保守期限が切れたら、すぐ使えなくなりますか。

期限の日にシステムが止まるとは限りません。
ただ、不具合の修正やセキュリティの更新、問い合わせ対応、機器の部品交換のどれが受けられなくなるかは製品と契約によって違い、問題が起きたときに受発注・請求が止まる期間が読めなくなります。
期限は「使えなくなる日」ではなく、手を打つかどうかを決める区切りとして扱うのが実際的です。

部分改修と置き換えは、どの時点で切り替えるべきですか。

同じ箇所に外部の変更が来るたびに改修が必要になっている、改修できる人が今後残らない見込みである、独自の改修が重なってほかの変更にも応じにくくなっている、のいずれかが見えた時点が見直しの目安です。
部分改修は今のシステムを直せる人がいることが前提なので、その前提が崩れる前に置き換えの準備を始めると、期限に追われずに範囲を選べます。

並行稼働は必ずしなければなりませんか。しない場合はどう確かめますか。

必須ではありません。
二重入力の負担が重い場合は、旧システムを参照用に残し、切替後最初の締めで、新しい仕組みが出した取引先別の請求額や在庫数量を旧システムでの計算と照らし合わせる方法があります。
単価改定や掛率の例外がある取引先から優先して照合すると、差異の出やすいところを先に押さえられます。

旧システムの過去データは、全部新システムへ移す必要がありますか。

処理を続けるのに必要なのは、取引先・商品・単価などのマスタ、売掛残高や在庫数量、まだ完了していない受注です。
過去の取引履歴は、旧システムやそこから書き出したファイルを参照用に残す選択もあります。
どちらにするかは旧システムの出力機能で決まり、保存が求められるデータに当たるかは税理士に確かめたうえで保存方法を選びます。

担当者が1人しかいない場合、刷新の要件定義はどう進めればよいですか。

一人で完璧な仕様書を作ろうとせず、受注・出荷・請求の各担当者との短い対話で業務と取引先別ルールを書き出し、「独自が必要」な項目だけを要件に絞ります。
IPAの中小企業向け小冊子は、対話による小さな改善の積み上げや、RFPによるベンダー企業の早期巻き込みを要点に挙げており、中小企業とITコーディネータなどの支援者に向けて作られています³。
絞った要件をRFPにまとめ、早い段階から複数のベンダーや外部の支援者と対話すると、一人で抱える作業を減らせます。

補助金を使う場合、基幹システム全体の刷新も対象になりますか。

インボイス枠（インボイス対応類型）の対象は、会計・受発注・決済のうち1機能以上を持つインボイス対応のソフトと、導入コンサル、導入設定、研修、保守サポートなどの役務です⁴。
独自の作り込みを含む刷新費用の全体を補う制度として見込むことはできません。
要件は公募回ごとに変わることがあり採択も保証されないため、対象になる部分を見積もりの中で分け、公募要領と照らし合わせてください。

1. 1　出典：独立行政法人中小企業基盤整備機構「中小企業・小規模企業者の定義」（2026年）
2. 2　出典：IPA DX SQUARE「ITシステムのモダン化とは？ レガシーシステムモダン化委員会総括レポートのポイント解説」（2025年）
3. 3　出典：IPA「ストーリーで学ぶ要件定義実践入門」（2019年）
4. 4　出典：独立行政法人中小企業基盤整備機構「デジタル化・AI導入補助金2026 インボイス枠（インボイス対応類型）」（2026年）