購買申請と承認の実務ガイド｜抜け漏れを防ぐチェックリストと記録項目を整える

# 購買申請・承認チェックリスト｜権限・比較・例外・変更を証拠付きで確認する

購買申請に必須欄が埋まっていても、数量根拠が曖昧、候補比較が不公平、承認者の権限が失効、承認後に別の商品を注文していれば統制されていません。チェックリストは、申請時だけでなく、見積、評価、承認対象版、注文、受入、請求まで同じ条件を追跡する必要があります。

本記事は、購買、利用部門、情報システム、セキュリティ、経理、法務、内部監査の担当者向けに、端末・IT製品の購買申請と承認を点検する実務チェックリストを提供します。確認結果を、判定基準、証拠、実施者、承認者、期限、例外、変更履歴まで記録できる形にします。

チェック結果のデータ構造を決める

共通記録

•案件ID、親案件ID、申請版、承認版
•項目ID、工程、判定基準
•適合、不適合、条件付適合、対象外、未確認
•入力値、単位、基準日、使用マスター版
•根拠、証拠の保存場所・版・取得日
•実施者、確認者、承認者、各日時
•差異・例外、責任者、期限、処置
•注文、受入、請求、支払への参照

未確認を適合にせず、対象外には理由と承認を求めます。判定変更は旧値と理由を保存します。

必要性・数量・期間を確認する

需要チェック

•[ ] 利用目的、利用者、部門、場所が明確である
•[ ] 利用開始日と終了・更新予定日がある
•[ ] 数量を新規、更新、交換、予備に分けた
•[ ] 人員・案件・故障等の数量根拠がある
•[ ] 既存在庫、回収予定、修理復帰を確認した
•[ ] 短期利用で再配布・レンタルを比較した
•[ ] 希望納期と遅延時の業務影響がある
•[ ] 利用終了後の返却・再利用・処分予定がある
•[ ] 申請者と利用責任者・費用責任者が特定されている

「必要」「前回と同じ」だけでは適合にせず、元となる計画や一覧へ参照できるようにします。

標準・在庫・既存契約を確認する

事前選択チェック

•[ ] 標準端末・標準構成を参照した
•[ ] 承認済み販売者・契約カタログを確認した
•[ ] 利用可能在庫の個体・状態・利用可能日を確認した
•[ ] 標準品で満たせない業務要件を説明した
•[ ] 標準外の追加運用・修理・教育費を示した
•[ ] 既存契約を使わない理由を記録した
•[ ] 例外の対象期間と終了・再評価日がある
•[ ] 購入回避・再配布の実績を記録した

標準外を禁止するだけでなく、反復する例外は標準カタログの不足として見直します。

仕様・品質・受入条件を確認する

仕様チェック

•[ ] モデル名ではなく必須性能・機能を記載した
•[ ] OS、サポート期間、更新要件がある
•[ ] MDM・EDR・IdP・周辺機器との互換性を確認した
•[ ] 通信、SIM、地域仕様、ポートを定めた
•[ ] 新品・中古、外観、機能、バッテリー基準がある
•[ ] 所有権、ロック、修理、消去証跡の条件がある
•[ ] 付属品、設定、資産登録、保証を定めた
•[ ] 全数・抜取等の受入方法がある
•[ ] 保留、返品、交換、減額の条件・期限がある

仕様書と受入票を同時に作り、見積で約束した条件を納品時に測れるようにします。

セキュリティ審査を確認する

IPAのIT製品の調達におけるセキュリティ要件リストは、製品分野ごとの脅威と要件を調達仕様へ反映する材料を提供しています。

セキュリティチェック

•[ ] 取扱情報、権限、持出し、業務影響を分類した
•[ ] 暗号化、セキュアブート、認証、鍵保護を定めた
•[ ] MDM・EDR・ログ・遠隔管理を定めた
•[ ] OS・ファームウェア更新と終了予定を確認した
•[ ] 脆弱性・事故・リコールの通知を定めた
•[ ] クラウド接続、外部送信、保存場所を確認した
•[ ] 修理・交換時の端末・媒体・データを定めた
•[ ] 回収・売却時の解除・消去・証跡を定めた
•[ ] 適用・非適用理由と使用資料版を保存した

製品認証や要件表だけで安全と断定せず、実際の利用環境と設定を審査します。

予算・会計・支払条件を確認する

財務チェック

•[ ] 予算部門、科目、年度、利用可能残を確認した
•[ ] 本体、付属品、送料、設定、保証、保守を分けた
•[ ] 取得・導入・運用・終了のTCOを示した
•[ ] 購入・リース等を同じ期間で比較した
•[ ] 支払、前払、外貨、価格改定条件を確認した
•[ ] 予算とキャッシュ・費用発生時期を区別した
•[ ] 売却・下取り見込を費用と別表示した
•[ ] 予算超過・年度またぎの追加承認を確認した
•[ ] 承認、発注、受入、請求、支払残を段階管理した

予算内であることだけで妥当とせず、需要とTCOを確認します。

重複・分割・閾値回避を確認する

販売者・振込先・供給網を確認する

販売者チェック

•[ ] 法人名、所在地、代表・契約責任者を照合した
•[ ] 振込先名義を登録済み情報と確認した
•[ ] 振込先変更を既知の連絡先へ別経路確認した
•[ ] 許認可、仕入経路、正規流通、所有権を確認した
•[ ] 品質、個体、消去、返品・保証体制を確認した
•[ ] 物流、修理、消去等の再委託先を把握した
•[ ] セキュリティ事故・脆弱性対応を確認した
•[ ] 財務・供給能力・事業継続を評価した
•[ ] 審査有効期限と変更・事故時の再審査がある

案件の安さと販売者の適格性を別々に判断し、重大な所有権・口座不備を点数で相殺しません。

見積の公平性と比較可能性を確認する

RFQチェック

•[ ] 全候補へ同じ仕様・数量・納期を提示した
•[ ] 同じ締切・回答様式・質疑情報を提供した
•[ ] 税、送料、設定、保証、返品条件をそろえた
•[ ] 見積有効期限、分納、価格変更を確認した
•[ ] 必須条件と加点条件を事前に分けた
•[ ] 候補を意図的に有利・不利にする情報差がない
•[ ] 候補追加・仕様変更時に公平性を再確認した
•[ ] 単一供給元・随意契約の根拠と代替調査がある

社数だけで競争性を判定せず、有効な見積かを確認します。

評価・交渉・利益相反を確認する

評価チェック

•[ ] 必須適合を加点評価の前に判定した
•[ ] 重み・尺度・証拠を見積開封前に固定した
•[ ] 見積範囲を同じ期間・条件へ正規化した
•[ ] TCO、品質、納期、セキュリティ、供給網を比較した
•[ ] 評価者が販売者との関係・贈答を申告した
•[ ] 関係者を評価・承認から外した
•[ ] 交渉前後の条件と変更理由を保存した
•[ ] 推奨・次点・除外理由を説明できる
•[ ] 異常価格を仕様・所有権・保証まで追加確認した

評価後に推奨候補へ合わせて重みを変えた場合は無効とし、再評価の承認を求めます。

承認権限・代理・職務分離を確認する

金融庁の財務報告に係る内部統制の評価及び監査の基準が示す資産保全や財務報告の信頼性等の観点を踏まえ、権限を役職名だけでなく対象・期間・上限へ落とします。

権限チェック

•[ ] 承認者の会社・部門・費用科目・金額上限が有効である
•[ ] 金額と質的リスクの双方で経路を選んだ
•[ ] 代理承認の対象、期間、上限、委任元がある
•[ ] 退職・異動・期限切れ権限が失効している
•[ ] 申請者が自分の案件を最終承認していない
•[ ] 評価・販売者登録・発注・受入・支払を分離した
•[ ] 兼任時の上位レビュー・ログ等の代替統制がある
•[ ] 承認時の権限版と判定結果を保存した

権限変更後も過去の承認が当時有効だったことを説明できるよう履歴を残します。

承認対象版・条件・有効期限を確認する

承認チェック

•[ ] 必要性、審査、評価、予算、例外が一画面で確認できる
•[ ] 明細・添付・評価の対象版を固定した
•[ ] 承認者が対象版を直接編集していない
•[ ] 条件付承認の条件、責任者、期限がある
•[ ] 残存リスクと受容責任者がある
•[ ] 承認日時、コメント、権限、経路を保存した
•[ ] 価格・予算・販売者審査の有効期限がある
•[ ] 再承認となる変更条件を明記した
•[ ] 一括・自動承認の対象条件と結果を記録した

古い承認を別の明細へ流用しません。承認後の画面表示と発注データを同じ版へ結びます。

緊急・少額・随意の例外を確認する

例外チェック

•[ ] 緊急性・業務影響・省略理由を記録した
•[ ] 対象、数量、仕様、販売者、上限額を確定した
•[ ] 所有権、振込先、標準・セキュリティを最低確認した
•[ ] 代替案・市場情報・選定理由を確認した
•[ ] 期限付き承認と失効日がある
•[ ] 省略審査の補完内容、責任者、期限がある
•[ ] 通常と同じ受入・請求照合を行った
•[ ] 事後レビューと再発防止を完了した
•[ ] 同じ理由・販売者・部門の反復を確認した

少額を例外理由にする場合も、同一目的の累計と質的リスクを確認します。

発注・変更注文を確認する

実行チェック

•[ ] 承認済み案件・有効期限から注文を生成した
•[ ] 販売者、明細、数量、単価、税が承認と一致する
•[ ] 納期、分納、支払、保証、返品が一致する
•[ ] 条件付承認が注文前に完了している
•[ ] 注文番号を納品書・請求書へ要求した
•[ ] 変更要求に旧・新条件、理由、影響がある
•[ ] 金額・仕様・販売者等の再審査を行った
•[ ] 変更承認後に変更注文・予算・受入基準を更新した
•[ ] 重複送信で注文を二重生成していない

発注担当が承認済み明細を直接書き換えず、差分承認へ戻します。

受入・請求・支払を確認する

三点照合チェック

•[ ] 納品を注文番号へ紐付けた
•[ ] 数量、モデル、個体、品質、付属品を確認した
•[ ] 合格、保留、不合格、返品を分けた
•[ ] 分納済み数量と未納残を更新した
•[ ] 注文・合格受入・請求の明細が一致する
•[ ] 未納・保留・返品分を支払対象から除いた
•[ ] 請求書番号の重複と振込先変更を確認した
•[ ] 受入担当と支払承認担当を分けた
•[ ] 未使用予算・取消額を解放した

承認上限は支払額ではなく、実際の合格受入を支払上限にします。

システム・API・監査ログを確認する

技術統制チェック

•[ ] 画面だけでなくAPIで権限・状態・上限を検証する
•[ ] 承認対象版と発注明細の版番号を照合する
•[ ] 同時更新で承認後明細を上書きできない
•[ ] 二重送信を一意キーで拒否する
•[ ] 失効・否認・取消済み承認から発注できない
•[ ] 権限変更・代理期間を実行時に再確認する
•[ ] 変更前後、実施者、時刻、理由をログに残す
•[ ] 通知失敗で業務状態・期限を失わない
•[ ] ログへのアクセス・保存・改変防止を定めた

自動承認ルールの変更には、テスト、承認、発効日、適用結果の監視を求めます。

完了・月次レビューを確認する

完了チェック

•[ ] 全数量が合格、返品、取消で確定した
•[ ] 未納、交換、減額、返金が解決した
•[ ] 注文・受入・請求・支払が一致した
•[ ] 条件付承認・例外・事後レビューが完了した
•[ ] 資産・個体台帳を登録した
•[ ] 予算残を解放した
•[ ] 証拠・対象版・変更履歴を保存した
•[ ] 否認・取消・期限切れも理由付きで閉じた

月次には、差戻し、期限超過、分割疑義、例外、承認後変更、受入不一致、権限違反を一覧化し、責任者と是正期限を付けます。

サンプル案件でチェック結果を再計算する

チェックリストを導入したら、完了案件を無作為に選び、画面の「適合」から原資料へ遡ります。申請数量30台の根拠が人員計画へ戻れるか、比較した三社が同じ仕様・納期へ回答したか、承認時の評価表と注文したモデルが一致するか、受入個体30台と請求・支払が一致するかを再計算します。

例えば、最安候補が一台4万8千円、次点が5万円でも、最安候補だけ送料、保証、初期設定が別料金なら、単価列だけで選んだ評価は不適合です。全候補を同じ費用・期間へ補正し、必須条件を満たすことを確認します。差額が小さくても、返品不可や短い保証によるTCO・リスクを承認者へ示します。

承認後に50台から60台へ増えた案件では、最終注文が承認上限内かだけでなく、追加10台の需要、予算、販売者の供給、受入能力を再確認します。増額率が再承認閾値未満でも、総額が上位権限へ到達する場合は経路を再判定します。追加分を別注文へ分けて閾値を回避していないか、親案件で集約します。

緊急購入では、通常の見積社数を満たさないこと自体を欠陥とせず、最低確認、期限付き承認、補完審査、事後レビューが証拠化されているかを確認します。障害復旧後も例外が未完了なら、案件を完了にしません。同じ部門が同じ理由で繰り返す場合は、例外ごとの承認ではなく安全在庫・保守契約・予算計画を見直します。

チェック項目そのものを保守する

規程、権限、標準品、セキュリティ要件、販売者、会計・税務の変更に応じ、チェック項目へ版と有効期間を持たせます。進行中案件に新しい版を遡及適用するか、旧版で完了させるかを変更ごとに決めます。重大なリスク変更は進行中案件も再審査します。

•項目追加・削除の理由と承認者
•旧版・新版の適用開始日
•進行中・承認済み案件への移行方針
•フォーム、API、権限、帳票への反映確認
•テスト案件と期待される判定
•利用者への説明・教育・問い合わせ先
•適用後の誤判定・差戻し・例外の監視

チェック項目を増やすだけでなく、使われない重複項目、判断できない曖昧項目、後工程で再入力される項目を削減します。ただし監査証跡として必要な旧データは保持します。

月次レビューの例外一覧

•承認者権限・代理期限が不一致の案件
•申請者と最終承認者が同一の案件
•親案件未設定の類似・分割疑義
•単一見積・随意で根拠がない案件
•利益相反申告が未完了の評価
•承認後に販売者・モデル・振込先を変更した案件
•条件付承認・例外の期限超過
•受入前支払、請求重複、未納分支払
•完了後も予算・資産・注文が未閉鎖の案件

例外一覧は件数だけでなく、金額、台数、経過日数、情報リスクを表示します。重大度に応じて即時停止、是正、追加監査へ分け、完了証拠を確認して閉じます。

まとめ：承認前後で同じ条件を追跡する

購買申請・承認チェックリストは、提出時の入力確認だけではありません。必要性、在庫、仕様、販売者、見積、評価、権限、対象版、例外を承認前に確認し、その条件が注文、納品、請求、支払まで維持されたか追跡します。未確認・対象外・例外を区別し、証拠と期限を持たせることで監査と改善に使えます。

価格妥当性を検証するときは、同じモデル・容量・品質・数量・時点で[中古端末の販売相場を確認する](/market-search)と有効見積・成約実績を比較し、税、送料、保証、設定、返品条件を補正します。まず直近十件を点検し、承認対象版と注文が一致しない案件、期限切れ例外、受入前支払を優先して是正してください。