# 購買申請・承認の標準業務フロー｜受付から変更・受入・支払まで状態で管理する

購買申請は、フォームを提出して上司が承認した時点では終わりません。申請後に仕様、数量、販売者、価格、納期が変わり、承認された内容と注文・納品・請求が一致しないことがあります。また、申請を急ぐために分割する、見積を後付けする、代理承認の権限が残るといった運用は、画面上の承認履歴があっても統制されていません。

本記事は、利用部門、購買、情報システム、セキュリティ、経理、法務、内部監査の担当者向けに、端末・IT製品の購買申請を受付から完了まで進める標準業務フローを示します。各工程の入力、担当、判断、出力、停止条件と、差戻し・保留・否認・取消・例外・変更の状態を明確にします。

工程と状態を先に定義する

「申請中」「承認済み」だけでは、誰の作業を待っているか分かりません。

標準状態

  • •下書き：申請者が編集可能
  • •受付待ち：提出済みで形式確認前
  • •差戻し：不足項目と期限を指定して修正待ち
  • •在庫・標準確認中：外部調達の必要性を審査
  • •専門審査中：仕様、セキュリティ、法務、会計等を審査
  • •見積・評価中：候補・条件・価格を比較
  • •承認待ち：承認対象版を固定
  • •承認済み：有効期限内に注文可能
  • •変更承認中：元承認との差分を審査
  • •発注済み、分納中、受入保留、受入完了
  • •請求照合中、支払承認済み、完了
  • •否認、取消、期限切れ

状態ごとに編集可能者、必要入力、SLA、通知、遷移条件を定めます。履歴を上書きせず、誰がいつ何を変更したか残します。

申請者が下書きで必要性と明細を作る

下書き項目

  • •利用目的、利用者・部門、開始・終了予定
  • •品目、数量、新規・更新・交換・予備の内訳
  • •必須仕様と標準品との差
  • •取扱情報、持出し、通信、管理方式
  • •既存在庫・回収・修理の確認状況
  • •希望納期と遅延時の業務影響
  • •概算価格、予算、費用部門、年度
  • •購入・リース等の候補と終了時処理

モデルURLだけでは提出できないようにし、業務要件と数量根拠を必須にします。添付には版・取得元・日付を付けます。

受付で形式・重複・分割を確認する

受付担当は内容を承認せず、必要項目と関連申請を確認します。

受付チェック

  • •申請者・利用責任者・費用責任者が有効である
  • •必須項目と添付がそろっている
  • •同一目的・品目・販売者・期間の申請がない
  • •承認閾値直下の連続申請でない
  • •取消・否認済み案件の再提出ではない
  • •予算年度・希望日・調達リードタイムが整合する
  • •禁止品・制限品・関連当事者に該当しない

関連案件は親案件IDで結び、集約金額・リスクで経路を再判定します。正当な拠点別・部門別申請は配賦根拠を残します。

既存在庫・標準品・契約カタログを確認する

外部見積の前に、保管在庫、回収予定、修理復帰、標準カタログ、既存契約を確認します。

判定分岐

  1. 再利用在庫が要件・期限を満たすなら再配布へ切り替える
  2. 標準品・既存契約で満たすなら簡易経路へ進める
  3. 標準品で不足するなら例外根拠を要求する
  4. 在庫不足なら必要数量から再利用可能数を差し引く
  5. 短期利用ならレンタル・再配布を比較する

在庫が使えない理由を性能不足、サポート終了、修理、回収遅延などに分類し、需要計画へ戻します。

リスク判定で審査経路を自動選択する

判定要素

  • •金額、台数、契約期間、予算超過
  • •標準外仕様、業務停止影響
  • •情報区分、管理権限、社外持出し
  • •中古・現状渡し、品質・所有権
  • •新規・海外販売者、再委託、前払
  • •単一供給元、随意、緊急、関連当事者
  • •外貨、自動更新、残価保証、解約制限

低リスクは必要な承認を減らし、高リスクは専門審査を追加します。判定ルールの版と入力値を案件へ保存し、後から同じ経路を再現できるようにします。

専門審査を並列化し、担当範囲を明示する

審査担当

  • •情報システム：標準、互換性、運用、サポート
  • •セキュリティ：暗号化、管理、更新、データ、供給網
  • •購買：販売者、競争性、契約、納期、価格条件
  • •経理・財務：予算、会計、税、支払、期間
  • •法務：責任、保証、再委託、データ、終了
  • •利用責任者：必要性、数量、業務優先度

独立して進められる審査は並列化し、依存関係がある項目だけ順序を付けます。各審査は適合、条件付適合、不適合、対象外で回答し、条件・根拠・期限を記録します。

IPAのIT製品の調達におけるセキュリティ要件リストを参照する場合は、製品分野・利用環境へ必要要件を対応付けます。チェック済みという結論だけでなく、使用した版と適用・非適用理由を保存します。

不備は差戻し、外部待ちは保留、不可は否認にする

状態の使い分け

  • •差戻し：申請者が修正できる不足や矛盾
  • •保留：予算決定、販売者回答、技術検証など外部条件待ち
  • •条件付適合：指定条件を満たせば次工程へ進める
  • •否認：必要性・法令・必須要件等により案件を終了
  • •取消：申請者側の需要消失・計画変更で終了

差戻しには不足項目、担当、期限を付けます。否認・取消案件を同じ承認のまま復活させず、再申請時に変更点を示します。保留には次回確認日を設け、無期限に滞留させません。

RFI・RFQで比較可能な条件を集める

市場情報が不足する場合はRFIで供給可能性を確認し、その後RFQで価格・条件をそろえます。

RFQ項目

  • •モデル、仕様、品質、数量、個体条件
  • •本体・付属品・送料・税・設定の内訳
  • •納期、分納、最低数量、価格有効期限
  • •保証、修理、代替機、返品・取消
  • •所有権、仕入経路、消去・品質証跡
  • •支払、前払、為替、価格改定
  • •回収、返却、売却、終了時条件

全候補へ同じ締切・様式・質疑回答を提供します。候補追加や重要仕様変更があれば、公平性を保つため必要に応じて期限を延長します。

必須適合・TCO・リスクを分けて評価する

評価手順

  1. 必須仕様・セキュリティ・所有権の適合を判定する
  2. 見積範囲を同じ数量・期間・サービスへ補正する
  3. 取得・設定・保守・停止・終了を含むTCOを計算する
  4. 品質、納期、販売者、供給網、循環性を採点する
  5. 利益相反申告と評価者の独立性を確認する
  6. 推奨、次点、除外理由と感度分析を保存する

評価者が採点後に重みを変えないよう、基準と重みを見積開封前に固定します。変更が必要なら理由と全候補への影響を承認します。

承認パッケージを固定して回付する

承認画面

  • •必要性、数量、在庫を使えない理由
  • •リスク区分と専門審査結果
  • •候補比較、TCO、推奨・除外理由
  • •予算、契約期間、支払、残存価値
  • •利益相反、随意・単一供給元、例外
  • •残存リスク、条件、責任者、期限
  • •承認後に再審査となる変更条件

承認対象の明細・資料版をスナップショットとして固定します。承認者は編集せず、修正は差戻して新しい版を作ります。

金融庁の財務報告に係る内部統制の評価及び監査の基準が示す業務の有効性・効率性、財務報告の信頼性、法令等遵守、資産保全の観点を踏まえ、承認が資金・資産・記録を守る統制として機能するようにします。

順次・並列・合議の承認を使い分ける

承認方式

  • •順次：下位承認を前提に上位者が全体を受容する
  • •並列：専門領域を独立審査し、すべて完了後に最終承認する
  • •合議：高リスク・関連当事者等を会議体で判断する
  • •自動：標準品・既存契約・低リスク等の厳格な条件下に限定する

代理承認は対象・期間・上限を明記し、委任者本人への通知と事後確認を行います。自分が申請・評価した案件を最終承認できないよう権限を制御します。

承認結果と有効期限を通知する

承認済み通知には、注文可能期間、承認上限、対象販売者・仕様・数量、残存条件を含めます。否認・差戻しには理由と再申請条件を伝えます。

承認後の管理

  • •価格・見積有効期限
  • •予算年度・利用可能期限
  • •販売者審査・契約の有効期限
  • •セキュリティ検証・標準認定の版
  • •未完了の条件付承認事項
  • •再承認トリガー

期限切れの承認を注文へ転用できないようにします。発注前に全条件が完了したことをシステムで確認します。

発注前ゲートで最終条件を照合する

注文照合

  • •申請・承認の販売者、品目、数量、単価
  • •税、送料、設定、保証、支払条件
  • •納期、分納、納品場所、付属品
  • •所有権、返品、交換、変更、取消
  • •個体一覧、検査、消去等の提出物
  • •予算残、承認期限、条件付事項

一致すれば承認IDから注文を生成します。差異があれば変更承認へ戻し、注文担当が口頭で修正しません。

変更要求を差分承認へ戻す

変更フロー

  1. 販売者または社内担当が変更要求を登録する
  2. 旧条件・新条件・理由・発効希望日を示す
  3. 金額、仕様、セキュリティ、予算、納期への影響を算定する
  4. 再審査トリガーに該当する専門部門へ回付する
  5. 差分を承認・否認し、変更注文を発行する
  6. 受入基準・予算・台帳を更新する

モデル・販売者・振込先・所有権・データ条件の変更は、金額が下がっても再審査します。承認前の代替品を受け入れません。

緊急経路は最低統制と事後補完で進める

緊急フロー

  • •緊急性と停止影響を記録する
  • •対象・数量・仕様・販売者・上限額を確定する
  • •所有権、振込先、標準・セキュリティを最低限確認する
  • •権限者が期限付きで承認する
  • •注文・受入・三点照合は通常経路と同じにする
  • •省略した販売者・価格・契約審査を期限内に補完する
  • •事後レビューで原因・再発防止を決める

緊急経路の利用回数、理由、販売者、補完期限を月次確認します。反復する場合は在庫・契約・承認SLAを改善します。

受入・請求・支払を承認済み条件と照合する

実行フロー

  1. 納品を注文番号へ紐付ける
  2. 数量、モデル、個体、品質、証跡を検査する
  3. 合格、保留、不合格、返品を記録する
  4. 分納済み・未納残を更新する
  5. 注文・合格受入・請求を三点照合する
  6. 振込先・税・値引き・前払を確認する
  7. 別担当が支払を承認する

承認上限まで自動的に支払わず、合格受入れた実績を上限にします。請求書番号の重複と販売者口座変更を独立確認します。

完了・取消・期限切れを閉じて実績へ戻す

完了条件

  • •全数量が合格、返品、取消のいずれかで確定した
  • •未納、交換、減額、返金が解決した
  • •注文・受入・請求・支払が一致した
  • •予算残を解放し、資産・個体台帳を登録した
  • •条件付承認・例外・事後レビューが完了した
  • •証拠と変更履歴が保存された

否認・取消・期限切れも終了理由、未使用予算、再申請関係を記録して閉じます。処理時間、差戻し、例外、変更、品質を次の標準・権限・フォーム改善へ戻します。

SLAとエスカレーション

工程ごとに単一の期限を置くのではなく、標準・例外・高リスクで目安を分けます。申請者の修正待ち、販売者回答待ち、社内審査中を別の時計で測り、購買担当の遅延へ混ぜません。

  • •受付：提出から形式確認まで
  • •在庫確認：在庫照会から利用可否回答まで
  • •専門審査：必要資料がそろってから判定まで
  • •見積：RFQ発行から有効回答まで
  • •承認：対象版固定から承認・否認まで
  • •発注：承認条件完了から注文発行まで
  • •変更：変更要求から差分判断まで
  • •受入保留：不一致発見から交換・減額合意まで

期限が近づいたら担当者へ、超過したら上位責任者へ通知します。ただし上位者が内容を見ず代理承認する経路にはせず、応援担当の割当て、資料不足の解消、優先順位変更を促します。期限停止は保留理由と再開条件がある場合に限り、担当者が手動で時計を止め続けられないようにします。

実例で状態遷移を確認する

標準PC20台の申請で既存在庫5台が使える場合、申請数量を15台へ変更し、再利用5台は別の配布タスクへ紐付けます。申請者が20台のまま進めたい場合は、予備・将来採用など追加根拠を出し、数量承認を受けます。在庫確認結果をコメントだけで残さず、利用可能個体と必要日を証拠化します。

中古スマートフォン50台の見積で最安候補だけがバッテリー基準と返品条件を回答しない場合、その候補を条件付のまま価格首位にせず、回答期限を付けて保留します。期限内に必須条件を確認できなければ不適合として除外し、次点候補を推奨します。安さを理由に必須条件を承認者へ丸投げしません。

承認後に販売者が30台を先に、20台を翌月納品すると提案した場合、分納日、受入・請求上限、利用開始影響、予算年度を差分審査します。先行30台だけを合格受入・支払対象とし、未納20台を完了扱いしません。翌月の価格・仕様が変わるなら変更注文を発行します。

システム実装上の統制

申請・承認システムでは、画面のボタン制御だけでなくAPI側でも権限、状態、版、金額を検証します。承認済み版のハッシュまたは不変スナップショットを保持し、発注APIはその版と最終明細が一致する場合だけ処理します。同時更新では、承認直後に別担当が明細を変えられないよう版番号を比較します。

  • •申請者自身の最終承認を拒否する
  • •権限上限を案件・累計金額の双方で確認する
  • •関連申請を親案件単位で集約する
  • •承認済み版への直接編集を拒否する
  • •重複クリック・再送で注文を二重生成しない
  • •失効・取消・否認済み承認から発注しない
  • •代理権限の開始・終了・対象範囲を確認する
  • •監査ログへ変更前後・実施者・時刻を保存する

通知送信の成功を業務処理成功と混同せず、画面・タスク一覧でも未処理を確認できるようにします。通知が失敗しても申請状態と期限は失われず、再送で承認を重複実行しない設計にします。

フロー改善のレビュー

月次には、工程別中央値・90パーセンタイル、差戻し理由、期限超過、例外、承認後変更、受入不一致を確認します。短縮だけを目標にせず、後工程の返品・請求差異・監査指摘と対にします。特定部門で同じ入力不備が続くならフォームの説明・既定値・マスターを直し、特定製品で同じ例外が続くなら標準カタログを更新します。

自動承認率を上げる場合は、対象条件、誤承認、後続不一致を確認します。手動承認を自動へ移す前に、入力の真正性、販売者・価格マスターの更新、職務分離、監査ログが機能していることを検証します。

標準フローのチェックリスト

  • •[ ] 工程・状態・遷移条件を定義した
  • •[ ] 申請に必要性・数量・期間・終了を含めた
  • •[ ] 受付で重複・分割・予算を確認した
  • •[ ] 在庫・標準・既存契約を先に確認した
  • •[ ] 金額と質的リスクで経路を選んだ
  • •[ ] 専門審査を責任範囲付きで並列化した
  • •[ ] 差戻し・保留・否認・取消を区別した
  • •[ ] 全候補へ同じRFQ条件を示した
  • •[ ] 必須適合・TCO・リスクを分けて評価した
  • •[ ] 承認対象版と残存条件を固定した
  • •[ ] 代理・自動承認の条件と期限を制御した
  • •[ ] 発注前に最終条件と承認を照合した
  • •[ ] 変更を差分審査・変更注文へ戻した
  • •[ ] 緊急経路に最低統制と補完期限がある
  • •[ ] 受入・請求・支払を三点照合した
  • •[ ] 完了条件と証拠を実績改善へ戻した

まとめ：承認を一回のクリックではなく状態遷移として管理する

購買申請と承認は、提出・押印だけでは統制できません。受付、在庫、リスク、専門審査、見積、評価、承認、発注、変更、受入、支払、完了を状態としてつなぎ、各工程の入力と停止条件を明確にします。標準・低リスクを速くし、高リスクと例外へ審査を集中すれば、速度と統制を両立できます。

端末価格の妥当性を評価するときは、同じモデル・容量・品質・数量・観測時点で[中古端末の販売相場を確認する](/market-search)と有効見積・成約実績を比較し、税、送料、保証、設定、返品条件を補正します。まず一件を申請から支払まで時系列に並べ、状態不明、口頭変更、古い承認、証拠欠落を特定してください。