検収書とは？書き方・記載項目と納品書・受領書との違い

納品物を受け取った直後に、取引先から検収書の発行を求められることがあります。しかし、特にWebサービスやスマホアプリの開発では、ファイルやアカウントを受領した事実と、契約・仕様どおりに利用できることを確認した事実は同じではありません。

この記事では、検収書の役割、関連帳票との違い、記載項目、開発成果物の確認方法、不具合がある場合の対応を整理します。受領と検収を区別し、検収書を発行してよい時点を判断できるようになることが目的です。

受領は納品物が届いた記録、検収は契約・仕様・受入基準に照らした確認結果です。検収書は、受入確認と承認を終え、契約で定めた方法で結果を通知できる段階で扱います。

01Section検収書とは？受領後すぐに発行する書類ではない

検収書は、納品物・役務・開発成果物について、発注者側が契約、発注内容、仕様書、受入基準などに照らして確認した検収結果を記録するための帳票です。単に物品、データ、成果物を受け取った事実を残す書類とは限りません。

一般的には、「納品→受領→契約・仕様・受入基準に照らした確認→検収結果の承認・通知→請求手続き→支払い」という順で進みます。ただし、検収書の発行主体、検収の期限、通知方法、請求可能な時点は、契約、取引先指定の書式、社内規程によって異なります。

受領と検収は記録する事実が異なる

受領は納品物が届いたことの確認、検収は契約や仕様、受入基準への適合を確認した結果です。

たとえば、Webアプリのソースコード、管理画面のURL、管理者アカウント、操作マニュアルを受け取っても、ログイン、主要機能、権限、外部連携、データ移行などの受入テストが終わっていなければ、検収完了とは扱えないことがあります。情報システムの受入確認では、要件・品質、テスト、合否判定基準をあらかじめ整理する考え方が参考になります。デジタル社会推進標準ガイドラインは政府情報システム向けの資料ですが、民間取引でも受入基準や証跡を設計する際の参考になります。

検収書を発行する前の判断フロー

納品物を受領したことだけを理由に、検収完了の通知や検収書の発行を進めるのは避けます。次の順で確認すると、未確認事項を残したままの発行を防ぎやすくなります。

発行前に確認したい契約条件

検収期限や通知期限は、受入テストが終わってから確認すると対応が難しくなることがあります。納品直後に、少なくとも次の項目を契約書、発注書、個別合意で照合します。

検収期限やみなし検収を含む、契約書全体で確認しておきたい条項は、システム開発の契約書で確認すべきチェックポイントで整理しています。契約締結前の段階であれば、あわせて確認してください。

02Section納品書・受領書・検収書・請求書の違い

帳票名だけではなく、何を記録する書類かで区別します。受領記録があっても、仕様や受入基準への適合確認まで完了したとは限りません。

帳票を使い分ける際は、書類名ではなく「どの事実を記録したいのか」で考えることが重要です。発行主体、帳票名、兼用の可否は、契約、取引先指定、購買・経理の運用により異なります。

受領書があっても検収完了とは限らない理由

受領書や受領記録だけでは、受入テストの実施状況、仕様との照合結果、残課題の有無まで示せないことがあります。特に開発案件では、納品されたファイルや利用環境を受け取った後に、利用部門や技術担当が確認する工程が必要です。

したがって、受領時の記録には「受領した」事実を、検収書には「どの資料・基準に照らして、どの結果になったか」を残すと、両者を混同しにくくなります。

帳票を統合する前に確認すること

納品書、受領書、検収書、請求書を一つの帳票にまとめる運用もあります。その場合も、次の点を満たせるかを確認してください。

1. 1納品・受領・検収・請求のうち、どの事実を記録する帳票かを識別できるか
2. 2検収対象、判定基準、検収日、判定、承認者、残課題を記載できるか
3. 3契約で定めた検収通知の書式、送付先、方法、期限に適合するか
4. 4購買・経理・承認者が、請求や保存に必要な情報を確認できるか

適格請求書は、一定の事項を記載した請求書、納品書その他これらに類する書類として説明されています。国税庁の適格請求書等保存方式の案内を確認しつつ、検収書という帳票名だけで制度上の扱いを決めず、実際の記載事項と取引内容を経理・税務担当へ確認します。

03Section検収書の書き方｜記載項目とテンプレート

検収書には統一された書式が常にあるとは限りません。重要なのは、契約・発注・納品・受入テストに関する資料と照合でき、対象と判定根拠、結果、承認状況を後から追跡できることです。

記載項目は「対象・根拠・結果・承認」で整理する

記載漏れを防ぐには、項目を次の4つの観点で整理します。

• 対象：案件名、契約番号・発注番号、納品物・役務、納品日、検収日
• 根拠：契約書、要件定義書、仕様書、受入基準、テスト仕様書とそれぞれの版数
• 結果：合格・保留・不合格などの判定、判定対象範囲、残課題、別紙課題一覧への参照
• 承認：発行者、技術確認者、案件責任者、承認権限者、承認日、送付記録

品目、数量、型番が中心となる取引では、その情報を対象欄に追加します。開発案件では、対象機能、対象環境、引渡しアカウント、テスト結果報告書などを明記すると、後から検収範囲を確認しやすくなります。

開発案件向けの記載テンプレート

契約書、社内規程、取引先指定書式がある場合はそれらを優先します。以下は、検収対象と判定根拠の抜け漏れを確認するための汎用例です。

検収印・電子承認・保存の確認点

検収印、社印、署名、電子承認のどれを使うかは、慣行だけで決めず、契約と社内ルールを確認します。押印の有無だけでは、誰が、いつ、何を、どの根拠で承認したかを追跡できない場合があるためです。

電子取引で授受した取引情報の保存については、国税庁の電子取引関係の案内が確認先になります。実際にどのデータをどのように保存するかは、授受方法、保存対象、社内の文書管理・経理運用を踏まえて判断します。

04Sectionシステム開発で検収書を発行する前の確認項目

開発成果物の検収では、契約上の検収期限、通知方法、みなし検収、再検収、請求・支払い条件を最初に確認します。そのうえで、何を誰が確認し、どの証跡を残すかを決めます。

デジタル庁の標準ガイドライン解説書は、受入テストと合否判定基準を整理する考え方の参考になります。ただし、政府情報システム向けの資料であり、民間取引の検収条件を一律に定めるものではありません。

5分類で行う検収前チェック

開発成果物は機能だけでなく、契約上の対象範囲、データ・連携、運用引継ぎ、承認記録まで確認し、判定根拠をそろえます。確認対象は契約・仕様に応じて定めます。

可用性、性能・拡張性、運用・保守性、移行性、セキュリティなどの非機能要件は、契約・仕様に該当する場合の確認対象です。項目を検討する際は、IPAの非機能要求グレードを確認軸の参考にできます。

確認から承認・保管までの順序例

確認担当を一人に集中させず、次の順で根拠を集めると判断がしやすくなります。

契約条件の確認 → 利用部門の業務受入 → 技術担当の機能・データ・連携・運用確認 → 案件責任者の判定整理 → 購買・経理の請求・支払い条件照合 → 承認権限者の承認 → 通知・保管

検収そのものの進め方や受入テストの段取りは、検収の進め方で確認できます。本記事の検収書テンプレートとあわせて、判定根拠と通知期限をそろえてください。

05Section不具合や未達がある場合の判断と対応

検収完了が請求や支払い、案件完了の認識と連動する契約では、確認不足のまま検収書を発行すると、修正範囲、費用負担、対応期限の協議が複雑になるおそれがあります。判定は、納期だけでなく、契約・仕様・受入基準と証跡に基づいて行います。

判定別に残す証跡と次の対応

判定ごとに根拠と対応を記録します。保留・不合格時の再検収や請求・支払いの扱いは、契約、取引先運用、社内規程を確認します。

合格・保留・不合格は、実務上の整理のための区分です。条件付き合格、一部検収、保留の定義や請求・支払いへの効果は、契約、取引先運用、社内規程により異なります。

残課題を例外的に扱う場合の記録

軽微な残課題を例外的に扱える余地がある場合も、口頭合意だけで検収を進めず、次の内容を記録します。

• 残課題の内容、発生条件、業務・利用者・データ・セキュリティへの影響範囲
• 例外的な扱いを検討する根拠と、対応内容・対応期限・責任者
• 費用負担、追加作業の扱い、関係者間で確認した内容
• 再確認の方法、再判定者、未対応の場合の扱い
• 検収期限、通知期限、請求・支払い条件との関係

情報システム取引の条件設計やトラブル低減の参考として、経済産業省の情報システム・モデル取引・契約書を確認できます。契約不適合、通知、追完などの法的論点が関係し得る場合は、e-Gov法令検索の民法も確認先になります。ただし、具体的な権利義務、通知の有効性、費用負担などは、契約書、取引経緯、事案によって変わるため、法務または専門家へ相談します。

06Section検収書の運用で社内確認・相談が必要な場面

検収書の作成は、帳票を作る担当だけで完結しません。利用部門・技術担当は受入結果を確認し、案件責任者は根拠を集約して判定を整理し、購買・経理は請求・支払い・保存条件を照合し、承認権限者が社内規程に沿って承認する、といった役割分担が考えられます。

相談先を切り分ける目安

次のような場面では、判断を一人で抱えず、論点に応じて関係部署や専門家へ確認します。

• 技術的な受入確認が難しい場合：受入基準が未整理、データ移行・外部連携・セキュリティ・運用引継ぎが複雑な場合は、利用部門、情報システム部門、技術担当と確認する。
• 電子保存・帳票統合・支払い連携を変更する場合：購買、経理、文書管理、情報システム部門で、保存対象、承認記録、アクセス権、関連帳票との紐付けを確認する。
• 通知期限や契約解釈に懸念がある場合：検収期限、みなし検収、再検収、費用負担、条件付きの扱いに争点がある場合は、購買・法務へ相談する。
• 不具合後の対応で見解が対立する場合：契約書、仕様書、テスト結果、課題一覧、取引先とのやりとりをそろえ、必要に応じて法務または外部の専門家へ確認する。

定型取引で、検収対象、受入基準、承認者、保管場所が標準化されている場合は、既存の運用に沿って確認を進めやすくなります。一方、個別開発や連携が多い案件では、技術的な確認と契約・経理上の確認を分け、通知期限より前に判定材料をそろえることが重要です。

受入基準の整理や受入テストを利用部門・情報システム部門で担えるなら、この記事のチェックリストとテンプレートを社内運用に組み込むことで対応できます。受入テストの設計や技術的な確認を担える人員が社内にいない場合や、第三者の視点で品質を確認したい場合は、外部のQA・検証支援へ依頼する選択肢を検討してください。

受入テストや検収前の確認体制を整えたい場合

受入基準の整理、テスト設計、第三者による確認が必要な場合は、案件の契約条件、対象範囲、残課題の扱いをそろえたうえで、支援内容を比較できます。

QA・第三者検証670社掲載

QA・第三者検証の支援を探す