◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 検収書にサインする前に、契約書の検査期間・合格基準・みなし合格・通知方法と、支払の起算点を確かめる。
- 物品は現物と注文書の照合、システムは検査仕様書に沿った受入テストが中心で、期間の置き方も変わる。
- AWS EC2のSLAは稼働率とクレジットを扱い検収の合否には触れていないため、稼働の安定を条件にするなら検収基準として契約に書く。
- 不合格や条件付き合格は、事象・再現手順・該当する基準・対応期限・再検査の条件を、契約の方法と宛先で期限内に通知する。
- 取適法の対象取引では、検収の有無にかかわらず受領後60日以内に定めた支払期日が来るため、受領日を経理・購買へ渡しておく。
目次

検収書にサインする前に、契約書で何を確かめるか
納品物やシステムを受け取り、仕入先から検収書の返送を求められたのに、確認が終わらず合格にしてよいか決めかねている。
このとき最初に見るのは、契約書の検収条項(検査期間・合格基準・みなし合格・通知方法)と、支払期日がどこから数えられるかです。
物品とシステムでは、確認の対象も期間の置き方も違います。
SLAの稼働率保証は、検収の合否とは別の仕組みです。
不合格や保留にするなら、契約の期限と方法に沿って、不具合・基準・対応期限・再検査の条件を書面で返します。
検収条項で見る4点(期間・基準・みなし合格・通知方法)
検収書へのサインは、受け取った納品物が契約で決めた基準を満たしたと、買い手が仕入先へ認める意思表示です。
契約によっては、この合格日が支払条件や保証期間の起点に置かれています。
その場合、サインした時点で後戻りしにくい事柄がいくつか確定します。
迷ったときに手元の検収書の様式から考え始めると、仕入先が用意した文面に判断が引っ張られます。
先に開くのは契約書です。
情報処理推進機構(IPA)が公開している情報システムのモデル取引・契約書の案内は、契約時に仕様やプロジェクト管理方法とあわせて、検収方法などについて共通の理解を持つことを挙げています3。
検収は、本来は届いてから考える作業ではなく、契約の段階で決めておく事柄です。
その決めごとが契約書のどこに、どこまで書かれているかを読みます。
検収条項で見るのは、次の4点です。
- 検査期間:納品から何日以内に検査を終えるか。
起算点が納品日・受領日・設置完了日のどれか - 合格基準:注文書、仕様書、検査仕様書のどれと照らし合わせるか
- みなし合格:期間内に通知しなければ合格とみなす定めがあるか
- 通知方法:不合格や保留を、誰に、どの様式・手段で伝えるか
4点のうち判断を大きく分けるのは、みなし合格と通知方法です。
みなし合格の定めがある契約では、確認が終わらないまま期限を過ぎると、サインしていなくても合格として扱われるおそれがあります。
また、契約が書面での通知を求めているのに不合格を電話で伝えただけでは、通知をしたと後から示しにくくなります。
検査期間の起算点も読み違えやすいところです。
システムの場合、「納品日」が成果物の引渡日なのか、本番環境への設置が終わった日なのかで、残りの日数が変わります。
合格基準の欄に「別途協議」や「買い手の検査に合格したもの」とだけ書かれている場合は、基準そのものがまだ決まっていません。
この場合は、サインの前に、何を確認したら合格とするかを仕入先と書面で合わせておきます。
そうしておくと、後で「仕様どおりだ」「仕様に足りない」と言い合う余地が狭まります。
支払の起算点と、取適法の対象取引での受領日基準
もう一つ確かめるのが、支払がどこから数えられるかです。
社内では「検収が終わったら支払の手続きに回す」と運用していても、契約や法律の上で支払期日の起点が検収日とは限りません。
たとえば支払条件が「検収月の翌月末」なのか「納品月の翌月末」なのかで、検収の遅れが支払に響くかどうかが変わります。
注意したいのが、中小受託取引適正化法(取適法)の対象となる取引です。
取適法は、製造委託や情報成果物作成委託など同法が定める委託取引で、資本金などの要件を満たす場合に適用されます。
すべての企業間取引に当てはまるわけではありません。
ただ、システム開発やソフトウェアの作成を中小の事業者へ委託している場合は、対象になるかを確かめておく必要があります。
公正取引委員会のQ&Aは、情報成果物の委託取引について、検査をするかどうかにかかわらず、受領後60日以内に定めた支払期日までに代金を支払う必要があるとしています1。
同じQ&Aは、一定の水準を満たしたことを確認した時点を受領とする旨をあらかじめ合意している場合には、その確認時点が起算日になるとも説明しています1。
つまり対象取引では、検収が長引いても、支払期日は受領日(または合意した確認時点)から進みます。
受入担当者が「まだ検収していないから支払は先」と考えて経理へ何も伝えずにいると、経理側は支払期日が近づいていることに気付けません。
検収の判断とは別に、受領日を記録し、取適法の対象取引かどうかとあわせて経理・購買へ渡しておきます。
それが、サインを急がずに確認を続けるための前提になります。
▼ 図の内容を文字で読む
- 受領日
- 支払期日を数える起点になる
- 受領後60日以内に定めた支払期日まで支払う
- 検査(検収)
- 実施したかどうかは起点を動かさない
- 検収が長引いても支払期日は進む
- 事前に合意した確認時点
- 一定水準を満たした確認時点を受領とする合意があれば、その時点が起算日になる
物品の受入検査とシステム・サービスの検収は、何がどう違うか
確認対象・確認方法・期間の置き方の比較
契約書で検収条項の枠を確かめても、その中身をどう埋めるかは、受け取ったものが物品かシステム・サービスかで変わります。
同じ「検収」という言葉でも、何を見るか、どう確かめるか、どれだけの期間を置くかの三つで違いが出ます。
次の比較は取引の性質から整理した考え方で、標準的な日数を示すものではありません。
物品の受入検査は、届いた現物を注文書や納品書と照らし合わせる作業が中心です。
数量、型番、外観の傷、付属品の有無など、見れば分かる項目が多く、照合の基準もほとんどが注文の時点で決まっています。
迷いが生じるのは、使ってみないと分からない性能や、梱包を解かないと分からない中身の状態です。
こうした項目を検査期間内にどこまで確かめるかは、物品の性質と契約の定めで決まります。
システムやサービスでは、届いたものを眺めても合否は分かりません。
仕様書に書いた機能が動くか、データが正しく移っているか、想定した件数を処理できるかを、実際に操作して確かめる受入テストが検収の中心です。
そのため、どの手順で何を試し、どんな結果なら合格とするかを書いた検査仕様書が要ります。
検査仕様書がないまま検収期間に入ると、担当者が思い付いた操作を試して終わり、どこまで確認したのかを仕入先にも社内にも説明できなくなります。
期間の置き方にも差があります。
物品は現物がそろえば照合を始められますが、システムはテスト環境、テスト用のデータ、テストを担う担当者がそろうまで検査に着手できません。
納品日から検収期間を数える契約で、テスト環境の準備に日数を取られると、実際に確認できる日数が短くなります。
契約の段階で、起算点を「テストできる状態になった日」とするのか、期間そのものを長く取るのかを決めておく意味はここにあります。
ただし取適法の対象取引では、検収期間の起算点を後ろに置いても、支払期日の起点である受領日は動きません1。
システムの検収で混同しやすいのが、仕様どおりに動くかという問題と、現場の利用者が操作に慣れているかという問題です。
受入テストを担うのは導入を担当する組織の担当者で、見るべきは仕様との一致です。
現場の担当者がまだ画面に慣れていないことは教育や運用の課題で、それだけでは不合格の理由になりません。
反対に、操作説明書や研修の実施が納品物に含まれている契約なら、それがそろっているかは検収の対象です。
取引形態に応じた契約書(SaaS・保守運用)の見方
システムの取引といっても、個別に開発してもらう場合、既製のパッケージやクラウドサービスを使う場合、稼働後の保守・運用を委託する場合では、検収の対象がそもそも違います。
IPAのモデル取引・契約書には、第二版のほかに、パッケージ、SaaS/ASP活用、保守・運用向けの追補版があり、取引形態ごとに契約の整理が分かれています3。
手元の契約がどの形態に近いかを見てから検収の対象を考えると、何にサインするのかを取り違えにくくなります。
SaaSのようにソフトウェアそのものを受け取らない取引では、検収で確かめられるのは、自社向けの初期設定、データの移行、他のシステムとの接続など、仕入先が自社のために行った作業の結果です。
サービス本体の機能は、契約前に評価した内容と利用規約で決まっており、検収で合否を付ける対象にはなりにくい部分です。
何を受け入れて合格とするのかを作業の範囲ごとに書き出しておくと、検収書が何へのサインを求めているのかがはっきりします。

保守・運用の委託には、一度きりの納品がありません。
毎月の作業報告や対応記録を確認して承認する手続きを、検収に当たるものとして契約に置くかどうかで、買い手側の確認の仕方が変わります。
承認の手続きが定められているなら、報告を受け取ってから何日以内に承認または差し戻しをするかも、物品の検査期間と同じように確かめておく項目です。
| 観点 | 物品の受入検査 | システム・サービスの検収 |
|---|---|---|
| 確認対象 | 数量・型番・外観・付属品など届いた現物 | 仕様書に定めた機能・データ・設定が動くか |
| 確認方法 | 注文書・納品書との照合 | 検査仕様書の手順に沿った受入テスト |
| 期間の置き方 | 現物がそろえば照合を始められる | テスト環境・データ・担当者がそろうまで着手できない |
SLAや稼働状況ページの記録は、検収の基準になるのか
SLAの稼働率保証とサービスクレジットが定めていること
システムやクラウドを使うサービスの検収では、稼働が安定しているかが判断の分かれ目になりがちです。
そこで手掛かりにしたくなるのが、サービス事業者のSLA(サービスの品質水準を約束する取り決め)や、公開されている稼働状況のページです。
ここでは、Amazon Web Services(AWS)のAmazon EC2のSLAを例に、SLAが何を定めているかを見ます。
以下はこのSLAの内容であり、他の事業者のSLAが同じ作りだという意味ではありません。
AWS EC2のSLAは、月間稼働率(Monthly Uptime Percentage)を、その月に利用できなかった時間の割合を100%から差し引いて算出します2。
「利用できない」の定義は、リージョン単位とインスタンス単位で異なります2。
稼働率が約束の水準に届かなかったときに受けられるのはサービスクレジットで、返金や他の支払いではなく、将来のEC2利用料への充当に限られます2。
除外事項もあります。
利用者側の作為・不作為や、AWSの合理的な管理の外にある要因による障害などは、対象から外れます2。
クレジットは自動では付かず、AWS Support Centerでケースを開き、期限内に障害の日時や対象のリソースなどを記載して申請する必要があります2。
このSLAが扱っているのは稼働率とクレジットで、納品物の合否や受入(検収)には触れていません2。
少なくともこのSLAは、稼働後に約束の水準を下回ったときの救済の仕組みであり、検収とは役割が違います。
たとえば、開発会社がクラウド上に受発注システムを構築して納品し、稼働直後に停止が続いたとします。
この場合も、クラウド側のSLAでクレジットが出るかどうかと、受け取ったシステムを合格にするかどうかは、別々に判断することになります。
しかもクレジットはクラウドの契約者が申請する仕組みなので、クラウドの契約を開発会社が持っていれば、買い手が直接受け取るものでもありません。
稼働の記録を検収基準にするための書き方
それでも、稼働の安定を合格の条件に入れたい場面はあります。
その場合は、SLAや稼働状況のページを借りるのではなく、検収の基準として契約書や検査仕様書に書き込みます。
書く項目は、SLAが稼働率を定義するときの作りが参考になります。
書いておきたいのは、次の4項目です。
- 観測期間:いつからいつまでの稼働を見るか
- 測定方法:どの監視の記録やログで停止を数えるか、何を「停止」とみなすか
- 合格ライン:停止の回数や時間がどこまでなら合格か
- 除外条件:計画停止や、自社側の操作・設定が原因の停止を含めるか
公開の稼働状況ページは、そのサービスの利用者全体に向けた情報で、自社の環境で起きた停止をすべて記録しているとは限りません。
検収の根拠にするなら、自社の環境で何を測るかを先に決め、その記録を誰が取り、仕入先とどう共有するかまで合わせておきます。
観測期間を長く取るほど判断材料は増えます。
ただ、取適法の対象取引では、観測を続けている間も受領日からの支払期日は進みます1。
| 観点 | SLA(AWS EC2の例) | 検収 |
|---|---|---|
| 扱うこと | 稼働率とサービスクレジット | 納品物が契約の基準を満たすかの合否 |
| 基準 | 月間の利用できなかった時間の割合を100%から差し引いた稼働率 | 仕様書・検査仕様書に定めた合格条件 |
| 満たさないとき | 申請により将来のEC2利用料へ充当するクレジット | 不合格の通知と修正・再検査 |
| 手続き | Support Centerでケースを開き期限内に申請 | 契約で定めた期限・方法で仕入先へ通知 |
▼ 図の内容を文字で読む
- SLA(クラウドの一事例)
- 稼働率とサービスクレジットを定める
- 満たさないときは申請により将来の利用料へ充当される
- 契約者がSupport Centerへ期限内に申請する
- 検収
- 納品物が契約の基準を満たすかの合否を扱う
- 満たさないときは不合格の通知と修正・再検査
- 契約で定めた期限・方法で仕入先へ通知する
- 稼働を合格条件にするなら
- 観測期間と測定方法を決める
- 合格ラインと除外条件を決める
- 契約書や検査仕様書に書き込む
検収条項がない契約や、期限を過ぎてしまった場合はどう動くか
定めの探し方(基本契約・個別契約・注文書)
ここまでの基準づくりが済まないまま、すでに納品物が届いている。
あるいは、契約書を開いたら検収期間の定めが見当たらない。
そういう場合でも、まず探す場所があります。
検収の定めは、契約書本体だけに書かれているとは限らないからです。
次の順に見ていきます。
- 基本契約:取引全体に共通する検査・検収、通知、保証の条項
- 個別契約:今回の案件だけの検収期間や合格基準、基本契約との優先関係
- 注文書・仕様書:検査方法や納品条件を書き込んだ欄、添付の検査仕様書
それぞれを読むときは、検収期間だけでなく、みなし合格の定めがあるか、不合格や保留の通知を誰あてにどの方法で出すかも拾います。
基本契約に一般的な検査条項があり、個別契約に別の期間が書かれている場合は、どちらが優先するかの定めも確かめます。
どこにも定めがなければ、期間も方法も当事者間で決まっていない状態だと分かります。
それ自体が、次の動き方を決める材料です。
期限を過ぎてしまった場合は、みなし合格の定めがあるかどうかで状況が変わります。
定めがある契約で期限を過ぎていれば、合格として扱われている可能性があります。
それでも不具合があるなら、その記録を取り、保証や契約不適合の条項に沿って通知することは、別の手続きとして残ります。
みなし合格の扱いが争いになりそうなときは、自社だけで結論を出さず、法務へ経緯を渡します。
見込み日の書面連絡と法務への確認
定めがない場合や、期限内に確認が終わりそうにない場合に避けたいのは、何も返さないまま時間が過ぎることです。
仕入先から見ると、返事がないのは合格なのか、確認中なのか、問題が見つかったのかが分かりません。
受領日、確認が済んだ範囲、残っている確認項目、検収の見込み日を、書面またはメールで仕入先へ伝えておきます。
遅れの理由が自社側の準備(テスト環境や担当者の都合)なのか、納品物の不具合なのかも分けて書くと、後から経緯を説明しやすくなります。
法務へ確かめるのは、契約に定めがない場合の、法律上の検査や通知の扱いです。
物品の売買か、ソフトウェアの開発委託かといった取引の形によって、関係する定めや期間の考え方が変わり得ます。
一律の日数で片付けられる事柄ではないため、契約書一式と取引の形、受領日と現在までの経緯を添えて相談します。
取適法の対象取引では、もう一つ押さえておく点があります。
公正取引委員会のQ&Aは、納期前に成果物を一時的に自社の支配下に置いて確認することについて、それは検査の終了後に受領することを認める趣旨ではないと説明しています1。
検収が遅れたからといって、検査が終わった日を受領日として扱い、支払期日を後ろへずらすことはできない、という読み方になります。
確認時点を受領とする扱いにしたいなら、最初の節で触れたとおり、あらかじめ合意しておくことが前提です1。
▼ 図の内容を文字で読む
- 基本契約
- 取引全体に共通する検査・検収、通知、保証の条項
- 個別契約
- 今回の案件の検収期間・合格基準、基本契約との優先関係
- 注文書・仕様書
- 検査方法や納品条件の欄、添付の検査仕様書
- どこにも定めがない
- 受領日・確認済みの範囲・見込み日を書面で伝える
- 法律上の扱いは契約書一式を添えて法務へ確認する
不合格・条件付き合格は、いつ・どの形で通知し、何を残すか
通知文に入れる項目
確認の結果、合格にできないと判断したら、契約で定めた期限内に、定められた方法と宛先で仕入先へ通知します。
電話や打ち合わせで伝えていても文書を別に残すのは、期限内に通知したことと、何を理由に合格にしなかったかを後から示すためです。
メールで送る場合は送信の記録を保存し、仕入先から受領の返信をもらっておきます。
通知文には、次の7項目を入れておくと、仕入先が受け取ってすぐ修正に着手できます。
- 対象:注文番号、契約名、納品物の名称や版
- 判定:不合格か、条件付き合格か
- 事象:何が起きたか、いつ確認したか
- 再現手順:どの操作・条件で起きるか
- 該当する基準:仕様書や検査仕様書のどの項目に合わないか
- 対応期限:修正や再納品をいつまでに求めるか
- 再検査の条件:再提出後に何を、どれだけの期間で確かめるか
このうち書き方で差が出るのは、再現手順と該当する基準です。
再現手順がないと、仕入先の環境で同じ事象を起こせず、確認のやり取りが何往復も続きます。
該当する基準を示さないと、仕入先は不具合ではなく「仕様にない追加の要望」と受け取るかもしれません。
受入テストで検査仕様書を使っていれば、項目番号をそのまま書けるので、この二つは書きやすくなります。
再検査の条件まで書いておくのにも理由があります。
修正版が届いたとき、全項目を試し直すのか、指摘した項目だけを試すのか、何日で判断するのかが決まっていないと、再検査で同じ迷いが繰り返されます。
不合格の通知、修正、再検査は、基準を満たすまで何度か回ることがあります。
一回ごとの手順を先に決めておけば、二回目以降の通知は変わった点だけを書けば済みます。
条件付き合格の残課題と支払の扱い
主要な機能は動いていて業務には使えるが、軽微な不具合や未対応の項目が残っている。
こうした場面で、条件を付けて合格を返す判断を考えることがあるはずです。
ただし契約にその区分がなければ、条件付きで返した通知が合格と不合格のどちらとして扱われるかは、文面と契約の読み方次第になります。
使う前に、契約にこの区分があるかを確かめ、なければ文言を法務と相談します。
条件付き合格にするなら、同じ文面に次の内容をそろえておくと、後で条件の中身を探し回らずに済みます。
- 残課題の一覧(項目ごとに事象と該当する基準)
- 課題ごとの対応期限
- 対応が済んだことを誰が、どう確認するか
- 対応が済むまでの支払の扱い
支払の扱いは、書いておかないと双方の理解が分かれる部分です。
残課題の完了まで一部の支払を待ってもらうのか、合格として通常どおり支払うのかを、文面で明らかにします。
なお取適法の対象取引では、検査をするかどうかにかかわらず、受領後60日以内に定めた支払期日までに支払う必要があります1。
残課題の完了を待つ扱いを書いても、その期日を後ろへ動かすことにはならない点を前提に、文面を組み立てます。
▼ 図の内容を文字で読む
- 検査
- 検査仕様書の項目に沿って確認する
- 不合格の通知
- 事象・再現手順・該当する基準・対応期限・再検査の条件を書く
- 仕入先の修正
- 通知の再現手順と基準をもとに対応する
- 再検査
- 通知に書いた条件で確認し、基準を満たせば合格になる
検収後に不具合が見つかったとき、支払と社内承認をどう進めるか
不具合の記録と仕入先への通知
合格を返した後に不具合が見つかることもあります。
このとき最初に残すのは、不具合を見つけた日と、見つけた経緯です。
いつ、誰が、どの操作をしていて気付いたのか、影響が出た注文やデータはどれかを、気付いた時点で記録します。
発見日は契約上の通知期限を数える起点になり得るため、後から思い出して書くと、日付そのものが争いの種になります。
記録がまとまったら、仕入先へ通知します。
中身は不合格の通知とほぼ同じで、事象、再現手順、該当する基準、対応を求める期限を書きます。
違うのは、根拠にする条項が検収条項ではなく、保証や契約不適合(引き渡されたものが契約の内容に合っていないこと)の条項になる点です。
求められる対応の範囲や通知の期限は、この条項の書き方で決まります。
サインした後に何が請求できて、何ができなくなるかは、検収条項と保証・契約不適合の条項の組み合わせで決まります。
サインの前にこの二つをあわせて読んでおくと、合格を返すことで手放すものが見えてきます。
法律上の通知期間の扱いは、取引の形や契約の定め方で変わり得ます。
期限が近い、または過ぎていそうな場合は、契約書と不具合の記録を添えて法務に確かめます。
経理・購買の承認フローへ渡す項目
受入担当者が持っている情報は、そのままでは経理・購買の承認フローに乗りません。
検収書には合否と日付が書かれていても、支払期日がいつか、別に申請が必要なものがあるか、保証の期限がいつまでかは、そこから読み取れないからです。
受入の結果を承認者へ渡すときは、次の項目を一緒に並べておくと、承認者が別の書類を探しに行く手間が減ります。
- 受領日:取適法の対象取引では、支払期日を数える起点になる
- 検収の結果と日付:合格・条件付き合格・不合格の別、条件付きなら残課題の一覧
- 支払期日:契約の支払条件による期日と、取適法の対象取引かどうか
- 不具合の通知状況:通知日、仕入先の回答、対応期限
- サービスクレジットの申請期限:クラウドのSLAで申請できるものがあれば、その期限と申請する側
- 保証・通知の期限:契約の保証期間と、不具合を通知できる期限
このうち支払期日とクレジットの申請期限は、どちらも検収とは別の時計で進みます。
取適法の対象取引では、検査をしたかどうかにかかわらず、受領後60日以内に定めた支払期日が来ます1。
AWS EC2のSLAのクレジットも申請しなければ受けられず、請求サイクルに基づく申請期限があります2。
検収の記録だけを回していると、この二つの期限は見落とされやすくなります。
取適法の対象になるかどうか、クラウドの契約を自社と仕入先のどちらが持っているかは、案件ごとに違います。
承認フローへ渡す様式に、この二つを確かめた結果を書く欄を設けておくと、案件のたびに同じ確認を思い出しながら行う必要がなくなります。
期限の管理を受入担当者一人に任せず、経理・購買と同じ一覧で見られる状態にしておけば、サインを急がずに確認を続けながら、支払や申請の期限も追えるようになります。
検収条項、支払条件、注文書の記載が別々の書類に分かれていると、どこで期限が動くのかを受入担当者だけで突き合わせるのは手間がかかります。
手元の契約書や注文書の並びをもとに、検収・通知・支払の期限をどの書類で確かめ、誰がどこで管理するかを整理できます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| サイン前に見る条項 | 検査期間・合格基準・みなし合格・通知方法と、支払の起算点 |
| 物品とシステムの違い | 物品は現物と注文書の照合、システムは検査仕様書に沿った受入テスト |
| SLAの位置づけ | 稼働後の救済の仕組み。検収基準にするなら観測期間・測定方法・合格ライン・除外条件を契約に書く |
| 定めがない・期限経過 | 基本契約・個別契約・注文書の順に探し、見込み日を書面で伝え、法律上の扱いは法務へ |
| 不合格・条件付き合格 | 事象・再現手順・該当する基準・対応期限・再検査の条件を、契約の方法と宛先で期限内に通知 |
| 取適法の対象取引 | 検収の有無にかかわらず、受領後60日以内に定めた支払期日が来る |

検収の記録と支払期日、クレジットの申請期限が別々に管理されていると、受入から支払承認までの間で期限を見落としやすくなります。 受入から経理・購買の承認までの流れを見ながら、承認フローへ渡す項目と、案件ごとに確認する点をどうまとめるかを一緒に確かめられます。
よくある質問
検収書にサインした後でも、不具合を理由に仕入先へ対応を求められますか。
求められるかどうかと、その範囲や期限は、契約の保証・契約不適合の条項で決まります。
サイン後に不具合を見つけたら、発見日と経緯を記録し、事象・再現手順・該当する基準を書いて仕入先へ通知します。
法律上の通知期間の扱いは取引の形や契約の定め方で変わり得るため、期限が気になる場合は契約書と記録を添えて法務に確かめてください。
検収の期限を過ぎてもサインしていなければ、合格にはならないのですか。
サインの有無だけでは決まりません。
契約に「期間内に通知しなければ合格とみなす」というみなし合格の定めがあれば、サインしていなくても合格として扱われる可能性があります。
まず基本契約・個別契約・注文書の順に定めを探し、定めがなければ仕入先へ確認状況と見込み日を書面で伝えたうえで、法律上の扱いを法務に確認します。
SLAの稼働率が未達のとき、サービスクレジットを受ければ検収を拒否できますか。
別の仕組みとして考えます。
AWS EC2のSLAは稼働率とサービスクレジットを定めたもので、クレジットは将来の利用料への充当に限られ、納品物の合否や検収には触れていません2。
検収で不合格にできるかどうかは、契約や検査仕様書に定めた合格基準で判断します。
稼働の安定を合格条件にしたいなら、観測期間・測定方法・合格ライン・除外条件を検収基準として書いておく必要があります。
取適法の対象取引では、検収が終わっていなくても支払期日は進むのですか。
進みます。
公正取引委員会のQ&Aは、情報成果物の委託取引について、検査をするかどうかにかかわらず受領後60日以内に定めた支払期日までに支払う必要があるとしています1。
一定水準の確認時点を受領とする事前の合意があれば、その時点が起算日になります1。
取適法は同法が定める委託取引で資本金などの要件を満たす場合に適用されるもので、すべての企業間取引に当てはまるわけではありません。
条件付き合格にするときは、どんな文面を残せばよいですか。
残課題の一覧(事象と該当する基準)、課題ごとの対応期限、対応完了を誰がどう確認するか、完了までの支払の扱いを同じ文面にまとめます。
契約に条件付き合格の区分がない場合、その通知が合格・不合格のどちらとして扱われるかは文面と契約の読み方次第になるため、文言を法務と確かめてから使います。
取適法の対象取引では、支払の扱いをどう書いても受領日からの支払期日は動きません1。
試験稼働の期間を、検収期間として使ってよいですか。
契約で試験稼働と検収の関係をどう定めているかによります。
試験稼働で何を確かめ、どんな結果なら合格とするかを検査仕様書に書いておけば、その記録を検収の根拠にできます。
ただし取適法の対象取引では、支払期日は受領日から数えられ、納期前に成果物を一時的に支配下に置いて確認することも、検査終了後の受領を認める趣旨ではないとされています1。
試験稼働の開始がいつの受領に当たるかは、事前の合意の有無とあわせて確認が必要です。
- 1 出典:公正取引委員会「中小受託取引適正化法(取適法)よくある質問コーナー」(2026年)
- 2 出典:Amazon Web Services「Amazon Compute Service Level Agreement」(2026年閲覧時点)
- 3 出典:IPA(情報処理推進機構)「情報システム・モデル取引・契約書」(第二版 2020年公開)
画像の出典元