指値（指定単価）の受発注を要件定義に落とす方法｜価格の置き場所・承認・履歴の決め方

◆監修・編集責任者　小園 将隆　2026年11月12日

B2B EC-COLUMN

指値の注文が手作業になる場面と、要件定義で先に決める「価格の置き場所」

取引先から指定単価を書いた注文が届くたびに、標準価格の表と見比べ、合わない明細を電話やメールで差し戻していませんか。
指値の受発注をシステムに載せる要件定義では、まず照合に使う価格と、照合の条件を決めます。
指値を標準価格や取引先別の契約単価とは別の「相手が示す価格」として切り分け、どこに持たせるかを決めることが最初の一歩です。
そのうえで、食い違ったときの自動受付・承認・差し戻し、有効期間と数量条件、履歴と請求の整合を要件に分けて書きます。
どこまで自動化するかは、取引先数と改定頻度に応じて選びます。

価格確認・差し戻しが手作業になる典型の場面

たとえば、取引先から届いた注文書に、品目ごとの指定単価が書かれているとします。
受注担当者は自社の価格表を開き、標準価格や取引先ごとの単価と見比べます。
合わない明細があれば営業担当に確認し、了承が取れなければ取引先へ差し戻します。
了承が電話や口頭で済んだ場合は、その単価を受注データへ手で入力し直すことになります。

手作業が残る理由は、注文書に書かれた価格が、社内のどのマスタにも「受けてよい価格」として登録されていないことにあります。
判断の基準が担当者の記憶や手元のファイルに分かれていると、同じ取引先の同じ品目でも、人によって受けたり差し戻したりが変わります。
取引先別の単価や納品条件、締め日、掛売枠は取引先ごとに個別に存在し、Excelやメールで管理すると版の食い違いが起きやすいという指摘もあります⁴。
これは大企業向けの受発注管理システムを扱う開発会社の解説ですが、指定単価が加わると、照合しなければならない価格の版がさらに一つ増えることになります。

請求の段階で、注文時に了承した単価と、請求書を作るときに参照した単価が違っていたと気づくこともあります。
要件定義で最初に決めたいのは、この照合に使う価格を、どこに、どの区別で持たせるかです。

標準価格・取引先別単価・指定単価を分けて持つ

本記事では、指値を「取引先が注文ごと、または一定期間に対して示す、買い手側の希望単価」と整理して扱います。
商習慣として統一された定義があるわけではないため、自社と取引先の間でこの語が何を指しているかは、要件定義の最初に言葉をそろえておく必要があります。

この整理に沿うと、受注時に関わる価格は次のように分かれます。

• 標準価格：自社が取引先を問わず基準として定める価格
• 取引先別単価：契約や合意にもとづき、自社が取引先ごとに登録する単価
• 指定単価（指値）：取引先が注文書や価格通知で示し、自社が受けるかどうかを判断する単価

3つを分ける理由は、指定単価を受けるかどうかの判断に、残りの2つが基準として必要になるからです。
指定単価で取引先別単価を上書きしてしまうと、次の注文で「元の合意はいくらだったか」を確かめる手掛かりが消えます。
逆に指定単価を注文データの中にしか残さないと、同じ単価が一定期間続く取引でも、注文のたびに同じ判断を繰り返すことになります。
指定単価を独立した価格として持ち、取引先別単価や標準価格と並べて参照できるようにしておくことが、後の承認ルールや履歴の前提になります。

価格を複数の層で持つ要件は、指値に限った話ではありません。
工業用粘着テープなどを扱う日東電工CSシステムの法人向け通販サイトの事例では、卸価格と販売価格をシステムで別々に管理する必要があり、加盟店が価格を登録でき、卸価格に利益率を掛けて販売価格が自動計算される仕組みが構築されています³。
これは同社と販売加盟店との取引の事例で、取引先が単価を指定する指値の事例ではありません。
それでも、価格の層ごとに「誰が入力し、何から計算されるか」を要件として書き分けた具体例として参考になります。

マスタの正本をどこに置くか

価格を分けたら、次はそれぞれの正本、つまり「最新で正しい値はこのシステムのこの表にある」と決める場所を選びます。
商品・取引先・単価といったマスタを基幹システム側に合わせるか、受発注システム側に持たせるかで、後に続く連携の設計が変わると述べられています⁴。

指定単価は、注文や価格通知とともに届き、承認を経て使えるようになる価格です。
正本を基幹側に置くなら、受発注側は承認前の指定単価をどこで受け止め、承認後にどの経路で基幹へ登録するかを書く必要があります。
受発注側に置くなら、基幹側の売上計上や請求が、承認済みの指定単価を注文明細とともに受け取れることが条件になります。
どちらが正しいというより、指定単価の入力と承認を誰がどの画面で行うかによって、自然な置き場所が決まります。

要件定義書には、価格の層ごとに「正本のシステム」「登録・変更する担当」「もう一方のシステムへ渡す時点」を一行ずつ書いておくと、後の連携設計で判断が揺れにくくなります。

発注側の場合の違い

自社が買い手として仕入先に指値を出す場合は、価格の入力主体が逆になります。
指定単価を作るのは自社の購買担当で、承認は社内で発注前に済ませ、仕入先には承認済みの単価を発注内容として伝えます。
このとき食い違いの判定は「自社が受けるかどうか」ではなく、「社内の予算や過去の仕入単価から外れていないか」に置き換わります。

発注側の要件では、仕入先が指定単価を受諾したか、別の単価を再提示してきたかを、どう記録するかが加わります。
また、取引が後で触れる取適法の対象になる場合、発注内容の明示や記録の保存は発注する側の義務になるため、履歴の要件が重くなります。

現状の受け方・確認・承認・請求までの流れを洗い出す

受付から請求までの流れを一枚にする

価格の置き場所の見当がついたら、現在の指値対応が実際にどう流れているかを確かめます。
システムの画面を考える前に、一件の注文が受付から請求に至るまでに、誰がどの書類やファイルで価格を見て、どこで値が書き換わっているかを一枚にまとめます。

書き出す単位は、工程ごとに次の4点です。

• 工程で扱う書類やデータ（注文書、受注データ、出荷指示、請求書など）
• 価格を確認・入力する担当
• 参照している価格（標準価格・取引先別単価・指定単価のどれか）
• 値を書き換える場合の根拠

IPAの要件定義ガイドは、主要な成果物として、業務プロセスやデータ構造をモデルとして記述することや、一覧形式の成果物で要求の抜け漏れを防ぐことを扱っています¹。
指値の対応では、工程を図にするだけでなく、「どの工程でどの価格を参照しているか」を一覧にすると、同じ注文について受付時と請求時に別の価格を見ている箇所が見つかりやすくなります。

例外と口頭承認を拾う

流れを書くと、規程どおりの経路よりも、規程の外で処理されている例外のほうが要件に影響することに気づきます。
たとえば、営業担当が電話で取引先と合意し、受注事務には「今回だけこの単価で」とだけ伝えている場合です。
合意の根拠がどこにも残らないため、次回同じ単価の注文が来たとき、受けてよいのかを再び営業に聞くことになります。

拾い出したい例外には、次のようなものがあります。

• 口頭やチャットだけで了承した指定単価
• 差し戻した後、取引先が単価を直して再送してきた注文
• 受注時には了承したが、請求時に金額を修正したもの
• 担当者の手元のファイルにだけ残っている取引先ごとの特例

例外ごとに「誰が決めたか」「どこに記録したか」「次の注文で同じ判断を再利用できたか」を書き添えておくと、承認のルールを作るときの材料になります。
例外の件数を正確に数える必要はありませんが、どの取引先・品目で繰り返し起きているかは、自動化の範囲を決める手掛かりになります。

業務担当者が主体で進める

現状の流れを書くのは、開発会社やシステムの提供者ではなく、実際に注文を受けている業務担当者が適しています。
IPAの「ユーザのための要件定義ガイド 第2版」は、ITベンダ主導の要件定義から、業務部門のユーザが主体的に関わる要件定義への転換を支援する書籍で、問題ごとに128の勘どころを示しています¹。
一般的な情報システムの要件定義を対象にした資料で、指値や価格管理に固有の記述を扱うものではありません。
それでも、例外や口頭承認のように現場でしか知り得ない事情を要件に載せるという点で、業務担当者が主体になる考え方はそのまま当てはまります。
なお同書の販売は2024年1月に終了しており、概要はIPAのサイトのアーカイブで確認できます。

開発側に求めるのは、業務担当者が書いた流れを読み、システムで表せる部分と表せない部分を指摘してもらうことです。
最初から画面案や製品の機能一覧に合わせて流れを書くと、製品が想定していない例外処理が初めから抜け落ちてしまいます。

▼ 図の内容を文字で読む

1. 注文受付
   • 注文書やメールから指定単価を読み取る
2. 単価照合
   • 標準価格・取引先別単価と比べる
   • 合わない明細を抜き出す
3. 確認・承認
   • 営業や管理者が受けるかを判断する
   • 受けられなければ取引先へ差し戻す
4. 受注確定・出荷
   • 確定した単価で受注データを作る
   • 分割出荷では明細ごとに単価を引き継ぐ
5. 請求
   • 出荷実績と単価から請求書を作る
   • 注文時の単価と食い違えば修正する

指定単価が標準価格・下限と食い違うときの自動受付・承認・差し戻し

食い違いの条件を決める

洗い出した例外の多くは、注文の指定単価が社内の基準と合わないときに起きています。
ここで「合わない」の中身を分けておくと、どれを自動で受け、どれを人が判断するかを書きやすくなります。

食い違いには、たとえば次の種類があります。

• 標準価格や取引先別単価より低い、または高い
• 自社で決めた下限価格を下回る
• 承認済みの指定単価が、有効期間の外で使われている
• 承認済みの指定単価の数量条件から外れている
• 単位や税込・税抜の扱いが登録と違う

下限価格は、自社の粗利や取引条件から自社で決める値で、外部に参照できる相場があるわけではありません。
品目ごとに持つのか、商品分類ごとに持つのかも、価格改定の運用に合わせて決めます。

差額の大きさは判断の手掛かりにはなりますが、それだけで受けてよいかは決まりません。
ケース単位の単価を個数単位の欄に書いていたり、税込の価格を税抜の欄に書いていたりするだけでも、差額は大きく見えます。
差額が出た明細は、単位・税区分・適用期間を照らし合わせたうえで「本当に価格が違うのか」を判断する、という手順を要件に含めておくと、誤った差し戻しを避けやすくなります。

自動・承認・差し戻しの3分岐

食い違いの種類を分けたら、それぞれを自動受付・承認・差し戻しのどれで扱うかを決めます。
以下は編集部の整理による一例で、分岐の条件や値は自社の取引条件で置き換える前提です。

• 自動受付：承認済みの指定単価と一致し、有効期間・数量条件の内側にある。
  または取引先別単価と一致する
• 承認：下限価格以上だが、標準価格や取引先別単価と差がある。
  または新しい指定単価が初めて示された
• 差し戻し：下限価格を下回り、例外承認の対象にもならない。
  または単位や品目が特定できない

承認に回す場合は、承認者を差額の大きさや取引先の区分で変えるのか、誰が承認しても同じなのかを書きます。
承認された指定単価を、その注文だけに使うのか、有効期間を付けて次の注文でも自動受付の対象にするのかもあわせて決めます。
この選択で、承認の手間が注文ごとに続くのか、最初の一度で済むのかが変わります。

差し戻しは、取引先に単価を直してもらい、注文がもう一度受付に戻ってくる往復です。
差し戻しの理由を「下限割れ」「単位不明」などの区分で記録しておくと、取引先への説明がそろい、再提示された注文を前回の理由と照らして判定できます。
同じ取引先で同じ理由の差し戻しが続くなら、注文のたびに単価をやり取りするのではなく、期間単価として事前に合意する話し合いへ切り替える判断材料にもなります。

標準機能で表現できない承認の確認

承認のルールを書き出すと、製品の標準機能で表せるかどうかが気になります。
複雑な単価体系や多段階承認など、自社固有の商習慣を標準機能で表現できない場合は、カスタマイズや受託開発が検討対象になるという見解があります⁴。
これは開発会社の解説で、個別製品の機能の有無を示したものではありません。

要件定義書には、承認のルールを製品の画面の言葉ではなく、「条件」「承認者」「結果」の表で書いておくと、提供者ごとの回答を比べやすくなります。
たとえば「下限価格以上で取引先別単価より低い場合は営業管理者が承認し、承認後は有効期間付きで登録する」のように一行で書けば、標準機能で満たせるのか、設定で対応するのか、開発が必要なのかを提供者に答えてもらえます。
回答が開発になった条件は、その分岐を人の判断に残す案と並べて検討する対象になります。

▼ 図の内容を文字で読む

1. 注文受付
   • 指定単価を読み取る
2. 条件照合
   • 期間・数量・下限価格・単位を照らす
3. 判定
   • 自動受付・承認・差し戻しに振り分ける
4. 差し戻し理由の通知
   • 下限割れ・単位不明などの区分で伝える
5. 取引先の再提示
   • 単価や条件を直して注文を送り直す

有効期間・数量条件・改定履歴を注文・出荷・請求とずらさない

有効期間と数量区分の持たせ方

承認した指定単価を次の注文でも使うなら、いつからいつまで、どの数量で有効かを価格と一緒に持たせます。
持たせる項目の例は次のとおりです。

• 取引先・品目・単位
• 指定単価と税区分
• 有効開始日・有効終了日
• 数量区分（何個以上・何個未満で適用するか）
• 承認者・承認日と、根拠になった注文書や価格通知

新しい指定単価を登録するときに、同じ取引先・品目・数量区分で期間が重なる単価がないかを確かめる仕組みも要件に入れます。
期間が重なると、どちらの単価で受けたのかが注文ごとに違ってしまい、請求の段階で説明がつかなくなります。
有効終了日を空欄のまま登録できるかどうかも、改定の運用に合わせて決めておきたい点です。

注文時点の単価を明細に固定する

指定単価が改定されるとき、すでに受けた注文の単価が変わってしまわないかが問題になります。
請求書を作るたびに価格マスタを参照する作りだと、受注後に単価を改定した場合、改定前に受けた注文まで新しい単価で計算されるおそれがあります。
分割出荷で、最初の出荷と後の出荷の間に改定日がまたがる場合も同じです。

そこで、注文を受けた時点（または承認した時点）の単価を、どの価格の層のどの登録から取ったかとあわせて注文明細へ写して保存し、出荷と請求はその明細の単価を使う、という書き方を編集部として提案します。
改定日をまたぐ出荷で、注文日の単価と出荷日の単価のどちらを使うかは、システムが決めることではなく取引先との取り決めで決まります。
要件には、その取り決めの内容をそのまま条件として書きます。

取適法の明示・保存義務との関係

単価の履歴をどれだけ残すかは、社内の都合だけでなく、取引の種類によっては法令とも関わります。
取適法では、委託事業者は発注の際に直ちに発注内容等を書面または電磁的方法で明示し（第4条）、取引の内容を記載した書面または電磁的記録を作成して2年間保存する（第7条）義務を負います²。
同法は資本金の区分や取引の類型によって対象が決まる委託取引に適用されるもので、すべての受発注に一律にかかるものではありません。

義務を負うのは、発注する側の委託事業者です。
自社が発注側で対象取引に当たるなら、指定単価を含む発注内容を明示した記録と、その単価に至った経緯を注文単位で残し、少なくとも2年間保存できることを要件に書く根拠になります。
受注側の場合、明示や保存の義務は取引先の側にありますが、受け取った発注内容と自社が受けた単価を注文単位で残しておけば、取引先の記録と突き合わせる場面で役に立ちます。

ここで示したのは、法令の義務と要件定義で扱う項目を組み合わせた編集部の提案で、法令に適合することを保証するものではありません。
自社の取引が対象に当たるか、ほかに保存期間を定めた社内規程がないかは、公正取引委員会の解説や社内の法務・経理と照らしたうえで、保存期間を決めます。

▼ 図の内容を文字で読む

• 明細に単価を写して保存
  • 注文を受けた時点の単価を参照元とあわせて保存する
  • 出荷と請求はその明細の単価を使う
• 請求時にマスタを参照
  • 受注後に改定すると改定前の注文も新しい単価で計算されるおそれがある
  • 分割出荷で改定日をまたぐ場合も同じ問題が起きる
• 改定日をまたぐ出荷
  • 注文日と出荷日のどちらの単価を使うかは取引先との取り決めで決まる
  • 要件にはその取り決めの内容をそのまま条件として書く

取引先数・改定頻度で、自動化する範囲と人の判断に残す範囲を決める

3軸で振り分ける

ここまでに挙げた要件を、すべて最初からシステムで自動化する必要はありません。
どこまでをシステムに任せ、どこを人の判断に残すかは、取引先の数、指定単価が改定される頻度、承認の複雑さの3つで見当をつけられます。
この3つの軸による振り分けは編集部の整理で、どの軸が重いかは会社ごとに違います。

• 取引先の数：指定単価を示してくる取引先が多いほど、取引先ごとに価格を登録し、照合を自動で行う意味が大きくなる
• 改定の頻度：改定が多いほど、登録の手間と期間の重なりの確認が負担になり、一括での登録や期限の管理を要件に入れる意味が増す
• 承認の複雑さ：承認者が条件で変わる、多段階になるといった場合ほど、標準機能で表せるかの確認が必要になる

たとえば受注側で、指定単価を示す取引先が多く、改定も頻繁という状況を考えます。
この場合、照合と自動受付をシステムに任せることで減る確認作業は大きい一方で、価格の登録そのものが新たな作業として重くなります。
照合を自動化しても登録が追いつかなければ、承認済みの単価がマスタにないまま注文が届き、結局は手作業の確認に戻ります。

標準機能・設定・カスタマイズの目安

要件を、製品の標準機能で足りそうなもの、設定で対応できそうなもの、カスタマイズを検討するものの3段に仮置きすると、提供者への確認が絞れます。
以下は確認の出発点としての目安で、実際の振り分けは各製品の資料と回答で決まります。

• 標準機能で足りるか確認する候補：取引先別の単価の保持、注文明細への単価の保存
• 設定で対応できるか確認する候補：有効期間・数量区分、承認者の割り当て
• カスタマイズを検討する候補：差額や取引先区分による多段階承認、基幹システムとの価格の双方向の受け渡し

システムに載せない判断も、要件として書いておきます。
新しい取引先が初めて示した指定単価を受けるか、下限を割る単価を取引全体の事情から受けるか、取引先と単価を交渉し直すか、といった判断は、条件で一律に決めにくいものです。
こうした判断については、システムは注文を「承認待ち」として止め、人が決めた結果と理由を記録するところまでを担う、と書いておけば、自動化の範囲と人の役割の境目がはっきりします。

価格更新の運用負荷

自動化の範囲を広げるほど、価格を正しく登録し続ける作業の重みが増します。
先に触れた日東電工CSシステムの事例でも、運用で最も手間がかかるのは価格設定と情報の継続的な更新だと説明されています³。
1社の運用についての説明で、ほかの会社でも同じことが起きると言えるものではありませんが、価格を層に分けて持つ仕組みでは、更新を誰が担うかが運用の中心になりうることを示しています。

要件定義では、指定単価を登録する担当、取引先の価格通知を受け取ってから登録するまでの手順、有効終了日が近づいた単価をどう扱うかを書いておきます。
取引先数が多く改定が頻繁な状況では、一件ずつ画面で入力するのか、取引先から受け取った一覧を取り込むのかで、日々の作業量が大きく変わります。
取り込みを選ぶなら、取引先ごとに異なる一覧の形式をどこでそろえるかも要件になります。

▼ 図の内容を文字で読む

• 標準機能で足りるか確認する候補
  • 取引先別の単価の保持
  • 注文明細への単価の保存
• 設定で対応できるか確認する候補
  • 有効期間・数量区分
  • 承認者の割り当て
• カスタマイズを検討する候補
  • 差額や取引先区分による多段階承認
  • 基幹システムとの価格の双方向の受け渡し

要件定義書に書く項目と、製品・開発側への確認リスト

要件項目の一覧

ここまでの判断を要件定義書にまとめるときは、次の項目に分けると抜け漏れを確かめやすくなります。

• 価格マスタ：価格の層（標準価格・取引先別単価・指定単価）と、それぞれの正本・登録担当・連携の時点
• 食い違い時のルール：食い違いの種類、自動受付・承認・差し戻しの条件、差し戻し理由の区分
• 期間・数量条件：有効開始日・終了日、数量区分、期間の重なりの扱い
• 履歴・請求の整合：明細へ保存する単価と参照元、改定日をまたぐ出荷の取り決め、保存期間
• 承認権限：承認者と代理、承認の記録、人の判断に残す範囲

IPAのガイドは、要件定義の主要な成果物として、機能とデータの整合性の検証も扱っています¹。
指値の要件に当てはめると、受付・承認・出荷・請求の各機能が、それぞれどの価格のデータを読み、どのデータを書き換えるかを表にして、読む側と書く側が食い違っていないかを確かめる作業になります。
たとえば請求機能が明細の単価ではなくマスタを読む設計になっていれば、「注文時点の単価を明細に固定する」要件と矛盾していることが、この段階で分かります。

非機能・運用・移行の要求

同じガイドでは、非機能要求や、運用・移行・総合テストの要求の定義も主要な成果物として扱われています¹。
指値の要件では、機能の一覧に比べて見落とされやすいのがこの部分です。

移行では、現在Excelや手元のファイルに分かれている取引先別単価や指定単価のうち、どれを有効な値として新しいシステムへ移すかを決めます。
版の違うファイルが複数あるなら、移行前にどれを正とするかを業務担当者が判断しておかないと、古い単価がそのまま自動受付の基準になってしまいます。

運用では、価格の登録と承認を担う人が不在のときの代理や、有効期間が切れた単価の扱いを決めます。
総合テストでは、通常の注文だけでなく、改定日をまたぐ分割出荷、差し戻し後に再提示された注文、期間が重なる単価の登録といった、現状の流れで例外として拾った場面を試験の場面に入れます。
そうしておけば、本番で初めて例外に出会うことを避けやすくなります。

製品・開発側への確認質問

製品の提供者や開発会社に聞くときは、機能の有無を「できる・できない」で聞くより、要件の一行ごとに、標準機能・設定・開発のどれで満たすのかを答えてもらうほうが、比較がしやすくなります。
主な質問は下の一覧にまとめました。

回答を受け取ったら、可能な範囲で実際の画面や操作で確かめます。
同じ「対応可能」でも、設定で済むのか、追加開発を前提にしているのかで、費用も導入後の変更のしやすさも変わります。
開発が必要と答えられた項目は、人の判断に残す案と並べて、どちらを選ぶかを決めます。

価格の層や承認の分岐を書き出しても、それが製品の標準機能・設定・開発のどこに当たるかは、要件と仕組みの両方を見比べないと判断しにくいためです。

取引先ごとに価格を分けて持つ仕組みを構築した経験をもとに、書き出した価格の層と承認ルールのうち、どこが設定で済み、どこに検討が要るかを確かめられます。無料相談で要件を整理する

製品・開発側に聞く確認質問

要件定義書の項目の並び（価格の層、食い違いの判定、承認、履歴と請求、連携、保存）に沿って並べた。

• 標準価格・取引先別単価・指定単価を別々の価格として保持し、受注時に並べて参照できるか

• 指定単価に有効期間と数量区分を持たせ、期間の重なりを登録時に検知できるか

• 食い違いの条件ごとに自動受付・承認・差し戻しを分ける仕組みは、標準機能・設定・開発のどれで実現するか

• 承認者を差額や取引先区分で変える、多段階にするといった承認を表現できるか

• 注文明細に単価とその参照元を保存し、請求はその単価で作られるか

• 基幹システムとの間で、どの価格をどちらが正本として、どの時点で受け渡すか

• 差し戻し理由や承認の記録を、注文単位でどれだけの期間保存できるか

回答が「開発で対応」になった項目は、その判断を人に残す案と並べて比べる。

要点の整理

軸	基準
価格の置き場所	標準価格・取引先別単価・指定単価を分け、層ごとに正本・登録担当・連携の時点を決める
現状の把握	受付から請求までの各工程で、誰がどの価格を見て、どこで書き換えているかと、口頭承認などの例外を書き出す
食い違い時	単位・税区分・期間を照らしてから、自動受付・承認・差し戻しへ振り分ける
履歴と請求	注文時の単価を参照元とともに明細へ保存し、出荷と請求はその単価を使う
保存期間	取適法の対象取引で自社が委託事業者なら2年間の保存義務。それ以外は社内規程で決める
自動化の範囲	取引先数・改定頻度・承認の複雑さで、標準機能・設定・カスタマイズと人の判断に振り分ける

移行する単価の整理や、改定日をまたぐ出荷・請求の扱いは、自社の取引条件と現行の価格ファイルを見ながらでないと決めにくい部分です。 要件定義書の項目表と現行の価格ファイルをもとに、移行時に正とする単価の選び方や、明細への単価保存の要件に抜けがないかを一緒に確かめられます。

よくある質問

指値と取引先別の契約単価は、システム上どう区別して持てばよいですか。

別々の価格として持つのが基本です。
取引先別の契約単価は、合意にもとづいて自社が登録する単価で、受注時の照合の基準になります。
指値は取引先が注文や価格通知で示し、自社が受けるかどうかを判断する対象です。
指値で契約単価を上書きすると元の合意をたどれなくなるため、指値は承認の記録と一緒に持ち、その注文限りで使うか、有効期間を付けて次の注文でも使うかを要件で決めます。

指定単価が標準価格より低いとき、自動で受けてよい条件はどう決めますか。

自社の粗利や取引条件から下限価格を決め、その範囲で条件を組み立てます。
外部の相場値があるわけではありません。
一例として、承認済みの指定単価と一致し、有効期間と数量条件の内側にある注文を自動受付にし、初めて示された単価や基準との差がある単価は承認に回す、という分け方があります。
差額が大きく見えても、単位や税込・税抜の違いが原因のことがあるため、差額だけで判定せず明細の条件を照らす手順を入れておきます。

指定単価の履歴は、注文・請求とあわせてどのくらい保持すべきですか。

取適法の対象となる委託取引で、自社が委託事業者に当たる場合は、取引内容を記載した書面または電磁的記録を作成して2年間保存する義務があります²。
この場合は、指定単価と決定の経緯を注文単位で残し、少なくとも2年間保存できることを要件にします。
対象外の取引や、ほかの保存要件については、社内の文書管理規程や法務・経理と照らして期間を決めてください。

発注側（買い手）が指値を出す場合、要件定義は何が変わりますか。

価格の入力主体と承認の位置が逆になります。
指定単価は自社の購買担当が作り、社内で承認してから仕入先へ伝えるため、判定の基準は社内の予算や過去の仕入単価になります。
仕入先が受諾したか、別の単価を再提示したかの記録も必要です。
取適法の対象取引であれば、発注内容の明示や記録の保存、支払期日を給付の受領後60日以内のできる限り短い期間内に定めることが自社の義務になるため²、発注と支払の要件にも関わります。

取適法の対象になる取引かどうかは、どう確認すればよいですか。

取適法は、資本金の区分や取引の類型によって対象が決まる委託取引に適用される法律で、すべての受発注に一律にかかるものではありません。
自社の取引がどの類型に当たり、資本金の区分がどうなるかを、公正取引委員会の解説で照らしたうえで、判断がつかない場合は法務担当や専門家に相談してください。
要件定義では、対象取引とそれ以外で記録や保存の要件を分けて書けるようにしておくと、判断が後から変わっても対応しやすくなります。

1. 1　出典：独立行政法人情報処理推進機構（IPA）社会基盤センター「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年）
2. 2　出典：公正取引委員会「委託事業者の義務（取適法）」（2026年）
3. 3　出典：株式会社フライトソリューションズ「導入事例 日東電工CSシステム株式会社様」（事例掲載時点）
4. 4　出典：株式会社一創「受発注管理システムを大企業で導入するには？基幹連携・多拠点・権限統制の要件」（2026年）