◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 検収は納入物を受け取る作業ではなく、合否を決める判断の工程です。合格の通知が支払期日と計上時期の起点になります。
- 支払期日は、給付を受領した日から起算して60日以内で、かつできる限り短い期間内に定めることが求められています。
- 初期費用は要件定義・設計・開発・データ移行・環境構築・教育の6区分で読み解き、月額費用との境目を契約書の別表で線引きします。
- ソフトウエアの耐用年数は用途により3年と5年に分かれ、導入時の設定の費用が取得価額へ含まれる場合があります。
目次

検収とは何か、費用が確定する仕組み
検収は、納入されたシステムが契約で定めた要件を満たしているかを発注側が確かめ、合否を決める工程です。合格を通知した時点で引き渡しが完了し、支払期日の起算とソフトウエアの計上時期が同時に動きます。初期費用の総額を見比べるより先に、どの状態を合格とするかを文書へ落としてください。そうすれば、後の追加請求や支払いの行き違いを抑えられます。検収は受け取る作業ではありません。発注側が判断する作業だと捉え直すところから、費用の管理が始まるのです。
検収と受入テストは重ねて語られますが、役割は別です。受入テストは、要件定義書に書いた機能や性能が満たされているかを確かめ、判断の材料を集める作業を指します。検収はその材料を突き合わせ、発注側の責任者が合否を決める意思決定にあたります。では、材料を集める人と決める人を同じにしてよいのでしょうか。両者を分けておけば、合否の理由が記録として残ります。
実務の並びは、納入物の受領から始まります。受け取った時点では、契約書と注文書に列挙した成果物が揃っているかを照合するにとどめてください。ここで動作まで確かめようとすると、受領と合格の境目が曖昧になり、後から範囲の言い分が食い違います。受領の記録と合格の記録は、別の書面へ分けるのが安全です。書面が分かれていれば、費用の確定時期を後から追えます。
受入テストの実施では、要件定義書の項目に番号を振り、1項目ずつ結果を残します。合否の判断は、あらかじめ決めた基準に照らして発注側が下します。基準が「問題なく動くこと」といった書き方だと、判断する側が根拠を持てません。項目ごとに、確認する操作と期待する結果を1行で書いておきましょう。書いてあれば、判断が速く進みます。
検収書の発行は、合格を相手方へ伝える書面であり、支払いの起点になります。受発注の取引には、支払期日の上限が置かれています。給付を受領した日から起算して60日以内で、かつできる限り短い期間内に定めることが求められています1。この規律のもとになった法律は、下請代金支払遅延等防止法(下請法)です。同法は中小受託取引の適正化等に関する法律へ名称と内容が改められ、2026年1月1日に施行されました2。手形による支払いの扱いも見直されました。支払条件の条項は、現行の内容へ合わせて見直してください。
検収書で確定する範囲は、納入物の一覧と、合格の根拠とした基準の版に限られます。合格した後に見つかった不具合をどの条項でどこまで直すのかは、契約不適合責任の期間として別に定めます。合格の判断と不具合の是正を1つの書面で処理しようとすると、支払いが止まり、稼働の日程も後ろへずれます。2つを分けて書くほうが、双方の作業が止まりません。
公表されているモデル契約書には、検査の期間、合格の通知、不適合が見つかった場合の再納入の扱いが条項として並んでいます*3。ここで参照したのは第二版(2020年公表)です。自社の契約書に検収の条項が無い場合は、この並びと見比べて欠けている項目を洗い出せます。実際の取り扱いは個別の契約内容や事実関係によって変わりますので、条項の文言は法務の確認を経て決めてください。
検収で先に決める5点(順位は着手の順序)
- 検収の対象となる成果物の一覧を、契約書と注文書の2つの書面で一致させます。一覧に無いものは検収の対象になりません。
- 要件定義書の項目に番号を振り、検収基準の1行と1対1で対応づけます。対応の無い項目は合否を判断できません。
- 受入テストに充てる期間と、合否を通知する期日を日数で定めます。期間内に通知しなかった場合の扱いも同じ条項に書きます。
- 不合格と判断する条件と、再検収を何回まで行うかを決めます。条件付きで合格とする扱いを認めるかも併せて定めます。
- 検収の合格から支払期日までの日数を、給付を受領した日から起算して60日以内という上限の中で定めます。
初期費用に含まれる項目と内訳
初期費用は、稼働までに1回だけ発生する作業の対価です。要件定義・設計・開発・データ移行・環境構築・教育という6区分に整理できます。見積書の項目名は取引先ごとに違いますので、金額の大小を比べる前に、どの作業がどの区分へ入っているかを確かめます。相場を探すより、費用が動く要因を押さえるほうが、社内への説明も進めやすくなるでしょう。内訳の整理は、検収の合否基準を書くときの土台にもなるのです。
1つ目の区分は、要件定義です。現行の業務手順を洗い出し、システムで扱う範囲と扱わない範囲を線引きします。詳しい進め方は<a href="/column/requirements-definition/">要件定義の手順をまとめた記事</a>でも整理しました。ここで決めた範囲がそのまま検収の対象になりますので、費用の根拠としても働きます。範囲を曖昧にしたまま次の工程へ進めば、稼働の直前に追加費用の相談が持ち込まれるでしょう。
2つ目の区分は、設計です。画面の構成、帳票の様式、データの持ち方、外部システムとの受け渡しの方式を決めていきます。要件の数が同じでも、既存の業務へ合わせ込む度合いが大きいほど、設計の工数は積み上がります。標準の機能で足りる部分と、作り込みが要る部分を早い段階で分けてください。
3つ目の区分は、開発です。設計で決めた内容を実装し、単体の確認まで進める作業がここに入ります。標準機能の設定だけで済む範囲と、追加のプログラムを書く範囲では、単価も期間も違います。見積書では、この2つが同じ行にまとめられていないかを確かめましょう。
4つ目の区分は、データ移行とマスタ整備です。取引先マスタや商品マスタは部署ごとに表記が揺れており、名寄せの作業量が読みにくい部分になります。移行の対象を全期間とするか直近の数年に絞るかで、作業量も確認の手間も変わります。移行後の突き合わせを誰が何件確認するのかまで、初期費用の見積りに含まれているかを確かめてください。
5つ目の区分は、環境構築です。本番環境と検証環境の2つを用意するのか、権限を何段階に分けるのかで作業量が変わります。外部システムとの接続を何本つなぐのかも、金額を左右します。接続の本数は、初期費用が動く要因の中でも見落とされやすい項目です。既存の基幹システムや会計システムとの連携が3本あれば、それぞれに設計と確認の工数が積み上がります。
6つ目の区分は、教育・マニュアル整備・初期サポートです。受発注の画面を使う担当者が何人いて、何拠点に分かれているかで、説明会の回数が決まります。マニュアルを取引先向けにも用意する場合は、その制作費が別に積まれます。稼働の直後に発生する問い合わせ対応を何か月まで初期費用へ含めるのかは、契約書で線を引いておく部分です。
見積書に「一式」とだけ書かれた行があれば、内訳の提示を求めてください。人月単価と工数の掛け算で組まれている場合は、役割ごとの人数と期間が示されているかを見ます。金額の妥当性は、単価そのものより、想定している作業量が自社の実態と合っているかで判断できます。同じ機能でも、既存データの状態によって工数が変わるからです。
内訳の確認を省くと、稼働の直前に費用の相談が持ち込まれます。移行できないデータが見つかれば、手作業での入力に人手を割くことになり、稼働の時期そのものが後ろへずれます。受発注が止まれば、その間の売上と取引先からの信用に影響が及びます。だからこそ、内訳の確認は前倒しで進めるべきです。見積書を自社だけで読み解くには、業務・データ・会計の3方向の知識が要ります。

自社の商流に合わせた要件整理を進めたい場合は、無料相談で要件を整理するのが近道です。
初期費用と月額費用の切り分け方
初期費用と月額費用の切り分けは、1回だけ支払うものか、使い続ける間ずっと支払うものかで分けます。クラウド型では利用料に含まれる範囲が製品ごとに異なり、同じ保守という言葉でも中身が変わります。3年や5年の総額で比べないと、初期費用の低さが月額の高さで相殺される場合があります。見積書を受け取ったら、まず2つの費用の境目を項目ごとに引き直してください。
一括で支払う費用は、要件定義・設計・開発・データ移行・環境構築のように、稼働までに終わる作業が中心です。継続して支払う費用は、利用料・保守・監視・問い合わせ対応のように、使う間ずっと発生します。境目が曖昧になりやすいのは、稼働の直後に発生する調整の作業です。初期費用の範囲に含めるのか、月額の保守で受けるのかを、契約書の別表で決めておきましょう。
項目ごとに2つの費用の入り方を並べると、見積書の読み違いを減らせます。環境構築、データ移行、保守、機能追加の4項目は、初期費用と月額費用の両方に関わる部分があり、確認の優先度が高い項目です。
クラウド利用料に含まれる範囲は、製品ごとに違います。基盤の維持、バージョンの更新、稼働の監視、データの取得と保管のうち、どこまでが利用料の中なのかを1項目ずつ確かめます。含まれない部分は、月額の保守として別に見積られるか、都度の作業として請求されます。利用者数や取引の件数で料金が変わる方式なら、事業が伸びたときの金額も同時に試算しておきましょう。
保守という項目は、中身を開かないと比べられません。障害が起きたときの受付の時間帯、連絡してから着手するまでの目安、問い合わせの件数に上限があるかを確認します。上限を超えた分が都度の請求になる方式であれば、稼働の初年度に費用が膨らむ場合があります。稼働の直後は問い合わせが増えますので、初期サポートの期間と保守の開始時期の重なりも見ておいてください。
追加開発やカスタマイズは、契約時に決めた範囲の外で発生します。取引先ごとの帳票の様式、掛け率の計算、承認の段階が増えるといった変更は、稼働の後に持ち上がりやすい部分です。都度の見積りとする方式と、月あたりの作業量を確保しておく方式があり、年間の見通しが立つかどうかで選び方が変わります。どちらの方式でも、追加分の検収をどう扱うかを先に決めておきましょう。
総額で比べるときは、初期費用に加えて、月額費用を3年分と5年分の2通りで並べます。ソフトウエアの耐用年数は、その他のものについて5年と定められています*4。同じ期間で並べれば、社内の説明とも合わせやすくなるでしょう。金額だけでなく、追加開発の発生しやすさや、利用者が増えたときの料金の動き方も同じ表に載せます。比べる軸を先に決めておくと、提案の受け取り方が担当者によって変わりません。
| 項目 | 初期費用 | 月額費用 |
|---|---|---|
| 環境構築 | 本番環境と検証環境の初期設定 | 利用するサーバーの継続利用料 |
| データ移行 | 移行作業と移行後の突き合わせ | 保管するデータ量に応じた追加分 |
| 保守 | 稼働直後の初期サポート | 障害対応と問い合わせの受付 |
| 機能追加 | 契約時に決めた開発の範囲 | 範囲外の追加開発は都度の見積り |
検収の進め方と合否基準の決め方
検収の進め方は、検収基準の作成、受入テストの実施、不合格の扱いという3つの段階で設計します。基準を先に作り、要件定義書の項目と1対1で結んでおけば、判断する人が迷いません。合否の線引きを文書へ残しておくと、追加費用の相談が持ち込まれたときにも、契約で決めた範囲の中で話し合えます。段階の設計は、開発が始まる前の要件定義の時期に着手してください。
要件定義書との対応づけは、準備の中で最初に取りかかる作業です。要件の項目に番号を振り、検収基準の1行を1つの番号へ結びつけます。番号の結びつかない基準や、基準の無い要件が残っていれば、その部分は合否を判断できません。対応表は開発の途中で更新されますので、版を管理し、最新の版で判断しましょう。
合否の線引きでは、合格と認める状態を具体的な言葉で書きます。「正しく動くこと」ではなく、「受注データを取り込んだ後に、在庫の引き当てが同じ画面で確認できること」のように書いてください。件数や時間で示せる項目は数値で書いておくと、判断が人によって分かれません。線引きが書けない要件があれば、要件そのものが曖昧であるという合図です。
受入テストの実施では、確認の観点を機能・データ・運用の3方向で組み立てます。機能は画面の操作、データは移行した後の突き合わせ、運用は月次の締めや例外の手順を確かめます。実施の体制は、受発注・在庫・経理の担当が自分の業務の範囲を確認する形にしましょう。情報システム部門だけで進めると、現場の例外処理が抜け落ちたまま合格の通知を出すことになります。
確認に割く期間と人数は、契約の段階で見込んでおきます。担当者は通常の業務を抱えていますので、確認だけに1日を充てられる日は限られます。1つの業務で20項目を確かめるなら、担当と日程を先に押さえておく必要があるでしょう。期間を確保しないまま進めると、中身を見ずに合格としてしまい、稼働の後に不具合が表に出ます。
不合格の扱いは、基準を作る段階で決めておきます。不適合の記録には、起きた事象、該当する要件の番号、再現する手順の3点を残してください。書き方が揃っていないと是正の範囲が読み取れず、やり取りが往復して日程が延びます。軽微な不適合は条件付きで合格とし、期日を決めて是正する扱いも定められます。
再検収の手順では、是正した部分だけを確かめるのか、関連する範囲まで見直すのかを先に決めます。範囲を決めずに再検収へ入ると、確認が終わらず、支払いの時期も定まりません。再検収を何回まで行うか、回数を超えた場合にどう扱うかも、条項として書いておけます。取り扱いは契約の内容によって変わりますので、条文の表現は法務と確かめましょう。
検収の時期が費用の会計処理に与える影響
検収の合格時期は、費用の会計処理の起点にもなります。設定作業やカスタマイズの費用は、ソフトウエアの取得価額へ含まれる場合があり、耐用年数にわたって配分されます。合格が年度をまたぐと、その年度の損益と資産の額が動きます。決算の日程と検収の日程は、早い時期に突き合わせてください。判断は個別の事実関係で変わりますので、区分は税務の専門家と確かめます。
税務の取扱いを示す公表資料では、ソフトウエアの取得に要した費用が取得価額に含まれるとされています4。自社で利用するために取得した場合、導入にあたっての設定の費用も、その範囲に入るものとして扱われます。取得価額の考え方は<a href="/column/system-cost-accounting/">システム導入費用の会計処理を解説した記事</a>でも詳しく整理しました。製作のために要した間接費や付随費用には、取得価額へ算入しないことができる範囲が定められています4。その合計が製作原価のおおむね3%以内の少額なものなどが、これにあたります。実際の判断は契約の内容と作業の実態によって変わります。
耐用年数は用途によって分かれます。複写して販売するための原本と研究開発用のものは3年、その他のものは5年と定められています*4。5年で配分する場合、支出した年度に全額が費用となるのではなく、5年に分けて計上される形になります。初期費用が資産として計上されるか当期の費用となるかで、稼働の初年度の損益の見え方が変わるのです。
初期費用のすべてが資産になるわけではありません。導入の可否を検討する段階の調査や、稼働の後に続く教育にかかる費用は、支出した年度の費用として扱われる場合があります。区分が曖昧なまま見積書を受け取ると、経理の担当が判断できず、決算の直前に確認の手間が生じます。見積書の段階で、作業の内容が読み取れる粒度の内訳を求めておきましょう。
受注側の会計にも、検収の時期が関わります。収益認識に関する会計基準は第29号として定められ、2020年に改正が公表されました*5。2021年度に始まる事業年度から適用されており、履行義務を充足した時点で収益を認識する考え方が採られています。発注側としては、相手方が検収の合格をもって収益を計上する場合があると理解しておけば足ります。自社の処理は、顧問の税理士や会計士と個別に確かめてください。
支払いの側にも、日程の設計が要ります。支払期日の起算が検収の合格から始まる点は、前述のとおりです。検収の合格が月末に集中すると、支払いの資金も同じ時期へ寄ります。分割の払いを何本も抱える月では、手元の資金が一時的に薄くなるでしょう。稼働の判定を業務の単位で分け、合格の日程を複数の月へ散らす組み方も検討してください。日程の分散は、資金繰りの計画と合わせて決めます。
検収の合格が年度をまたぐと、当年度の投資として見込んでいた金額が翌年度へ動きます。予算の説明を経営へ済ませている場合は、時期の見直しを早めに共有しましょう。稼働の遅れが1か月であっても、決算の期末を挟めば処理の年度が変わります。日程の管理は、開発の進み方と決算の日程の2つを同時に見ながら進めます。

検収と初期費用でつまずかないための契約の整え方
契約の整え方は、モデル契約書の確認、検収基準の対応づけ、中間検収の設計、対象経費の確認という4つの順序で進めます。公表されている条項の並びを土台にすれば、自社の契約書で欠けている項目が見えます。支払いを段階に分けておくと、1回の支払いに載る金額と、そのときに確かめる範囲が対応します。条項の文言は、法務と税務の確認を経て確定させてください。
モデル契約書の確認では、検査の期間、合格の通知、不適合が見つかった場合の再納入という条項の並びを見ます3。一覧の中には、アジャイル開発に向けた版も置かれています6。開発の進め方が段階を踏む形か、反復して作り込む形かで、検収の当て方が変わります。自社の進め方に近い版を選び、条項の抜けを1つずつ埋めましょう。なお、公表から年数が経っている版もありますので、引用する前に最新の改訂状況を確かめてください。
検収基準の対応づけは、契約書の別表として付けると管理しやすくなります。要件の番号と検収の基準を並べた表を、契約の一部として双方が持ちます。開発の途中で要件が変われば、別表の版も同時に更新し、変更の記録を残してください。表が契約の外に置かれていると、合格の根拠として使えず、判断が担当者の記憶に頼る形になります。
中間検収の設計は、支払いの分割と合わせて考えます。要件定義の完了、設計の完了、開発の完了という段階ごとに、確かめる範囲と支払う割合を決めます。段階ごとに確認しておけば、最後に大きな手戻りが出る場面を減らせるでしょう。分割した支払いにも同じ60日の上限が及びますので、各段階の合格から起算して期日を定めます*1。
対象経費の確認は、補助の制度を使う場合に欠かせません。補助率、補助の上限額、対象となる経費の区分は年度ごとに変わりますので、公募要領の最新版で確かめます*7。制度の選び方は<a href="/column/subsidy-system-introduction/">システム導入で使える補助金をまとめた記事</a>でも整理しました。交付の決定より前に契約や発注をした費用が対象外となる場合もあり、日程の組み方が結果を左右します。制度の要件と検収の時期を並べて確認し、社内の稟議の日程も同じ表に載せてください。
ここまでの作業を自社だけで進めるには、要件定義、契約条項の読み解き、会計と税務の区分という3方向の知識が要ります。受入テストの期間には、業務ごとの担当が通常の仕事と並行して確認に当たる必要もあります。人手を割けないまま進めると、確認しないまま合格の通知を出す形になり、稼働の後に費用の相談が戻ってきます。関わる担当の顔ぶれは、契約の前に決めておきましょう。
外部の支援を受ける場合と自社だけで進める場合の違いは、判断の材料が揃う速さに表れます。条項の型と検収基準の書き方を持っている相手と進めれば、別表の作成にかかる往復が減ります。自社だけで進める場合は、公表されている資料を読み解く時間を日程へ組み込みます。どちらを選ぶ場合も、合否を決めるのは発注側であるという点は変わりません。
本文で用いた出典を、記事の末尾にまとめます。*1と*2は、中小受託取引の適正化等に関する法律の条文と、公正取引委員会および中小企業庁が公表した施行関連の資料です。*3と*6は、情報処理推進機構が公表した「情報システム・モデル取引・契約書」の第二版(2020年公表)と、そのアジャイル開発版にあたります。
*4は、国税庁が示すソフトウエアの取得価額と耐用年数の取扱いに関する公表資料です。*5は、企業会計基準第29号「収益認識に関する会計基準」の2020年改正を指します。*7は、利用を検討する補助金の公募要領のうち、最新の年度版です。法律名と資料名の表記は、法務の確認を経て確定させてください。
よくある質問
検収書と納品書は何が違いますか
納品書は納入した側が成果物を引き渡したことを示す書面で、検収書は発注側が合否を判断した結果を示す書面です。2つを同じ日付でまとめて処理すると、受領と合格の境目が記録に残りません。支払期日は給付を受領した日から起算して定めますので*1、受領と合格の記録は分けて残します。
検収の期限を過ぎても合否の連絡がない場合はどうなりますか
契約書に定めた期間内に通知しなかった場合の扱いは、条項の書き方によって変わります。公表されているモデル契約書には、検査の期間と合格の通知に関する条項が置かれていますので、自社の契約書と並べて確認します*3。期間を過ぎた扱いが書かれていない場合は、条項を補う相談を契約の前に済ませておきます。
検収に合格した後で不具合が見つかった場合、費用は誰が負担しますか
合格の後に判明した不具合は、契約不適合責任の条項に沿って扱われます。責任を負う期間、対象となる範囲、是正の方法の3点が書かれているかを確かめます。合格の判断と是正の作業を1つの書面で処理しようとすると支払いが止まりますので、条項を分けて設けます。取り扱いは契約の内容によって変わります。
初期費用を分割して支払うことはできますか
要件定義の完了、設計の完了、開発の完了といった段階ごとに中間検収を置き、支払いを分ける方式があります。段階ごとに確かめる範囲と支払う割合を決めておくと、最後の手戻りが小さくなります。分割した支払いにも期限の定めが及び、各段階の合格から起算して60日以内という上限の中で期日を決めます*1。
補助の制度を使う場合、検収の時期は関係しますか
関係します。補助率、補助の上限額、対象となる経費の区分は年度ごとに変わりますので、公募要領の最新版で確かめます*6。交付の決定より前に契約や発注をした費用が対象外となる場合もあり、検収と支払いの日程を制度の要件と並べて組み立てます。社内の稟議に要する期間も同じ表に載せておきます。
- *1 出典:公正取引委員会「中小受託取引適正化法(取適法)関係」(2026) 経路
- *2 出典:中小企業庁「ミラサポplus 受注者を守る法『取適法』がもたらす変化」(2025) 経路
- *3 出典:独立行政法人情報処理推進機構「情報システム・モデル取引・契約書(第二版)」(2020) 経路
- *4 出典:国税庁「タックスアンサー No.5461 ソフトウエアの取得価額と耐用年数」(2026) 経路
- *5 出典:企業会計基準委員会「改正企業会計基準第29号『収益認識に関する会計基準』等の公表」(2020) 経路
- *6 出典:独立行政法人中小企業基盤整備機構・中小企業庁「中小企業デジタル化・AI導入支援事業(デジタル化・AI導入補助金2026)制度概要」(2026) 経路
- *7 出典:独立行政法人情報処理推進機構「情報システム・モデル取引・契約書(一覧・アジャイル開発版を含む)」(2020) 経路
画像の出典元
- Group of professionals working together on a project with do/Photo by Yan Krukau on Pexels
- Hands using a calculator with real estate documents on a des/Photo by RDNE Stock project on Pexels
- Students engaged in learning mathematics using calculators i/Photo by https://kaboompics.com/ on Pexels