卸価格の管理を仕組み化する要件定義：小規模事業者が先に決めること

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

B2B EC-COLUMN

卸価格のどの場面で困っているかを、業務の流れで切り分ける

取引先ごとの掛率や特価を表計算で持ち、改定のたびにメールで価格表を送り直していると、見積・受注・請求のどこかで卸価格が食い違い、確認の手間が増えていきます。
卸価格の管理を仕組み化する要件定義で先に決めるのは、システムの機能名ではありません。
誰がどの根拠で価格を決め、何で取引先に渡し、どこでずれるかという業務の流れと、価格ルール、見せ方です。
それらを必須とあれば良いに分けると、表計算の改善、既存システムの設定変更、新規導入のどれが合うかを比べられます。
小規模でも、担当、移行データ、試験、改定の運用までは決めておきます。

価格を決める人と根拠

卸価格がずれる原因を探すときは、価格表の作り方より先に、価格が決まってから請求されるまでの道のりを見ます。
同じ表計算の価格表を使っていても、決める人、渡す手段、受注で使う表、請求で使う表がそれぞれ違えば、ずれる箇所も違うからです。

最初に、価格を決めている人と、その根拠を書き出します。
定価に取引先ごとの掛率（定価に対する割合）を掛けて決めているのか、原価に利益を積んで決めているのか、商談で個別に決めた特価なのかによって、後で仕組みに持たせるルールが変わります。
たとえば、営業担当が商談で単価を決めて代表者が口頭で承認し、根拠がメールにしか残っていない場合、その担当者が不在のときに誰も価格の理由を説明できません。

• 誰が価格を決めるか
• 何を根拠に決めるか（掛率、原価、個別の商談）
• 誰が承認するか
• 決めた価格と根拠をどこに記録するか

なお、ここで整理しているのは、価格を決めて取引先に提示し、注文を受ける売り手の流れです。
仕入先から受け取った価格を確認するのが目的なら、見積と請求の照合が中心になり、決める項目も変わります。

取引先に渡す書類・データ

次に、決めた価格を取引先へ何で渡しているかを並べます。
取引先別の価格表を表計算ファイルやPDFで送る、見積書を個別に出す、メール本文に単価を書く、注文書の様式に単価を印字しておく、といった手段が混ざっていることがあります。

これらはどれも、送った時点の価格を写したものです。
改定後も取引先の手元には古いファイルが残り、取引先はそれを見て注文書を作ります。
売り手の社内で価格表を直しても、取引先が見ている価格は自動では変わりません。
受注でのずれが、この写しが複数あることから始まっていないかを見ておきます。

渡す手段を並べると、要件定義で何を決めるかも見えてきます。
取引先が最新の価格を自分で見られる形にするのか、売り手が改定のたびに送り直す運用を続けるのかで、必要な機能も運用の手間も変わるからです。

受注・請求でずれる箇所

注文を受けた後は、受注を記録する表やシステムに単価を入力し、出荷し、請求書を作ります。
このとき、受注で使う単価と請求で使う単価が別の表から転記されていると、片方だけ改定が反映された状態が生まれます。
請求書を受け取った取引先からの指摘で初めて気づく、という流れになりやすい箇所です。

ずれは、意味の違う価格が増えたときにも起きます。
販売加盟店が卸価格にマージンを上乗せして販売する取引では、卸価格と販売価格を別々に管理する必要があったという導入事例があります⁶。
これは1社の事例で一般的な傾向を示すものではありませんが、一つの表に卸価格と販売価格の列が並んでいると、転記の際に列を取り違えるおそれがあることを考える手掛かりになります。
自社の表でも、意味の違う価格が隣り合っていないかを見ておきます。

原因を確かめるときは、実際の受注と請求の明細を数件選び、単価がどの表から来たのかをたどるのが確実です。
差額の大きさだけで原因を決めつけず、適用した掛率、改定日、個別特価の有無を明細ごとに照らし合わせます。

改定のたびに増える作業

価格改定は、ずれが一度に表に出る場面です。
元の価格表を直し、取引先別の価格表を作り直して送り、受け取られたかを確かめ、いつの注文から新価格を使うかを決めます。
改定日の前後に届いた注文に旧価格と新価格のどちらを当てるかが曖昧だと、受注担当と請求担当が別々に判断してしまいます。

取引先が増えるほど、作り直す価格表と確認の連絡も増えます。
改定の手順が書き残されず特定の担当者の頭の中にあるなら、その人がいない時期には改定を進められないという問題も残ります。

図の5つの工程のうち、自社で手作業の転記や送り直しが発生している工程に印を付けると、要件定義で優先して扱う箇所が絞れます。

▼ 図の内容を文字で読む

1. 価格を決める（担当・根拠・承認）
2. 取引先へ渡す（価格表・見積書・メール）
3. 受注を記録する（単価の転記）
4. 請求する（請求用の単価）
5. 改定する（作り直し・送り直し・適用日）

要件定義で決める項目：価格ルールと見せ方を、業務の要求として先に書く

業務の要求：誰に何をどう提示するか

困っている箇所が見えたら、それを要件として書きます。
IPAの要件定義ガイドは、要件を定義する責任はシステムを使って事業に貢献するユーザ側にあるという考え方を示し、業務部門のユーザが主体的に関わる進め方への変革が必要だとしています¹。
卸価格でいえば、価格を決め、取引先とやり取りしている売り手の担当者が、要件の中身を決める立場です。

同ガイドは、要件定義を、業務として何を実現したいかを扱うビジネス要求定義と、それをシステムの仕様に落とすシステム化要求定義に分けて構成しています。
主要なドキュメントとして、データ構造、ビジネスプロセス、非機能要求、運用・移行・総合テストの要求などが挙げられています¹。
このガイドは情報システム全般を対象にしたもので、卸価格に固有の必須項目を定めたものではありません。
次の図は、この枠に卸価格の業務を当てはめた編集部の整理です。

最初に書くのは業務の要求です。
「取引先が自社向けの最新価格を見て注文できる」「改定日以降の注文には新価格が当たる」「受注と請求で同じ単価を使う」のように、困り事が解消された状態を業務の言葉で書きます。
この段階で製品名や画面の形を決める必要はありません。
手段を先に決めると、その製品でできることに業務の要求が引きずられ、本当に必要だった条件が抜け落ちることがあります。

価格ルール：取引先区分・掛率・数量別・期間・履歴

業務の要求を支えるのが価格ルールです。
価格ルールとは、ある取引先がある商品を、ある数量で、ある日に注文したとき、どの単価を当てるかを決める規則のことで、システムではデータ構造として表されます。
卸価格の要件では、次のような項目を検討します。

• 取引先区分：取引先をグループに分けて共通の掛率を当てるか、取引先ごとに決めるか
• 掛率：定価に掛ける割合を、取引先や区分、商品群ごとに持つか
• 個別の特価：特定の取引先・商品だけ別の単価にするか
• 数量別の単価：注文数量によって単価を変えるか
• 期間：適用開始日と終了日を持たせるか
• 改定履歴：過去の価格と適用期間をどこまで残すか
• 税込・税抜：どちらを基準に持ち、端数をどの段階で処理するか

これらは自社の取引に必要かどうかで選ぶ項目で、すべてを備える必要はありません。
数量別の単価を使っていない売り手が将来のために要件へ入れると、設定と試験の手間だけが増えます。

項目を並べたら、複数のルールが重なったときにどれを優先するかも決めます。
同じ商品に取引先区分の掛率と個別の特価の両方が設定されていたら、どちらを使うのか。
期間を区切った価格が終わったら、何に戻るのか。
表計算で管理している間は担当者が都度判断していた部分を、規則として書き出す作業です。

図の順序は一つの仮の例です。
期間を区切った価格を個別特価より優先する売り手もあり得ます。
大切なのは順序の正解を探すことではなく、担当者が変わっても同じ単価が出るように、自社の順序を文章で残すことです。

改定履歴は、過去の注文を後から説明できるかどうかに関わります。
単価を上書きして管理していると、取引先から以前の請求について問い合わせがあったとき、当時の単価の根拠をたどれません。
旧価格と新価格を適用期間付きで残す形にしておけば、注文日から当時の単価を引き当てられます。

税込と税抜も、受注と請求のずれにつながる項目です。
価格表は税抜で持ち、請求書は税込で出している場合、税額をどの段階で計算し、端数をどう処理するかが受注の記録と請求書で違うと、合計が合いません。
どちらを基準に持ち、どこで計算するかを、請求書の作り方と合わせて決めておきます。

見せ方：取引先ごとに何を見せるか

価格ルールと分けて決めるのが見せ方です。
同じ価格データを持っていても、誰が何を見られるかは別の要件になります。
取引先には自社向けの単価だけを見せ、他の取引先の単価や、社内の原価、掛率そのものは見せない、という分け方が基本の形です。

社内の見せ方も決めます。
受注担当は単価が見られれば足りるのか、原価や利益まで見る必要があるのか。
価格を変更できる人と、見るだけの人を分けるのか。
小規模で全員がすべてを見られる状態から始める場合でも、変更できる人を限っておくと、誰がいつ価格を変えたのかを追いやすくなります。

見せ方を価格ルールと混ぜて書くと、「取引先ごとの価格を持てる」ことと「取引先ごとに見せ分けられる」ことが一つの要件に見えてしまいます。
前者はデータを持てるかどうか、後者はそのデータを取引先ごとに分けて表示・出力できるかどうかで、確かめるべき点が違います。
取引先に販売価格の参考を示す表示を加えたい場合は、次に説明する法的な条件にも関わってきます。

▼ 図の内容を文字で読む

• ビジネス要求
  • 誰がどの根拠で価格を決めるか
  • 取引先に何をどう提示するか
• システム化要求
  • 価格ルールのデータ構造
  • 取引先別の見せ方と権限
• 運用・移行・試験
  • 現行価格表の移行
  • 改定の手順と担当
  • 試験で確かめる注文

▼ 図の内容を文字で読む

1. 取引先・商品ごとの個別特価
2. 期間を区切った価格
3. 数量別の単価
4. 取引先区分の掛率
5. 定価

価格の指示・提示で注意する法的な条件

自社の卸価格と、取引先の販売価格を分けて考える

自社が取引先へ売り渡す卸価格を決め、取引先ごとに変えることは、売り手として自社の販売価格を決める行為です。
注意が必要なのは、取引先が仕入れた商品を次の買い手へ販売する価格、つまり再販売価格を売り手が指定し、守らせようとする場合です。

公正取引委員会は、再販売価格維持行為は競争手段の重要な要素である価格を拘束するものであり、独占禁止法上、原則として違法になるとしています²。
例外として通常違法とならない場合の考え方は「流通・取引慣行に関する独占禁止法上の指針」で示されており、2026年の改正では、その該当する場合と具体例が追加されました²。

要件に入れる前に確かめること

要件定義でこの区別が問題になるのは、取引先の販売価格に関わる機能や運用を加えようとするときです。
販売価格をデータとして持つことと、その価格で売るよう取引先に求めることは別の事柄です。
最初の節で触れた事例のように卸価格と販売価格を別々に管理する場合も、そのデータを何に使うのかを要件として明確にしておくと、法的な確認が必要な範囲が分かりやすくなります。

例外に当たるかどうかの具体的な条件は指針の本文で確認する必要があり、この記事では判断の基準までは示しません。
取引先の販売価格を指定したり守らせたりする運用を仕組みに組み込む計画がある場合は、要件を確定する前に指針の内容を確かめ、公正取引委員会の相談窓口や専門家に相談してください。
自社の卸価格を取引先ごとに設計する部分は、この確認とは切り分けて進められます。

▼ 図の内容を文字で読む

• 自社の卸価格
  • 自社が取引先へ売り渡す価格
  • 価格ルールとして設計する
• 取引先の販売価格
  • 取引先が次の買い手へ売る価格
  • 拘束につながる仕組みは入れる前に確認する
• 確認先
  • 指針の本文
  • 相談窓口
  • 専門家

表計算の改善・既存の受発注設定・新規導入をどう選ぶか

必須と、あれば良いの分け方

ここまでで、業務の要求、価格ルール、見せ方を書き出しました。
手段を比べる前に、それぞれを「必須」と「あれば良い」に分けます。
IPAのガイドが業務の要求とシステム化の要求を分けて扱っているのにならい、手段の比較は要件を書き出して優先度を付けた後に行います。

必須かどうかは、それが無いと今の困り事が解消しないかで判断します。
たとえば、改定のたびに取引先へ価格表を送り直す手間が一番の負担なら、取引先が自社向けの最新価格を見られることは必須です。
一方、数量別の単価を今の取引で使っていなければ、あれば良いに回せます。
あれば良いを多く抱えたまま比べると、どの手段も足りないように見えたり、必要以上に大きな導入を選んだりしがちです。

必須の項目は、確かめられる形の文で書きます。
「取引先ごとの価格に対応」では、製品の説明と照らし合わせても判断できません。
「取引先区分の掛率と、取引先・商品ごとの個別特価が重なったとき、個別特価を優先して単価を出す」のように、前の節で決めた優先順位まで含めると、比較の際にそのまま質問できる文になります。

3択の比較表

必須の項目が決まったら、3つの手段を同じ軸で並べます。
表の各欄は、手段ごとに確かめるべき点を示した編集部の判断軸で、特定の製品を比べたものではありません。

判断が分かれるのは、主に二つの点です。

一つは、取引先が自分で最新価格を見られることが必須かどうかです。
必須でなければ、表計算の改善として価格の元データを一つにまとめ、取引先別の価格表はそこから出力する形にするだけでも、改定時の作り直しの手間や列の取り違えは減らせます。
必須であれば、表計算では送り直しの運用が残るため、既存の仕組みの設定変更か新規導入を比べることになります。

もう一つは、今使っている受発注や販売管理の仕組みが、必須の価格ルールをどこまで表せるかです。
既存の仕組みで個別特価の優先順位や適用期間を設定できるなら、データの置き場所を増やさずに済みます。
設定できない項目が必須に含まれていれば、運用で補う手間を続けるのか、新規導入で解消するのかを比べます。
この確認には、前の節で書いた要件の文をそのまま使えます。

表計算の改善を選ぶ場合も、改定の手順と担当を決めておかないと、作った人が異動した後に誰も直せない表になります。
どの手段を選んでも、運用担当の欄だけは空けたままにしないことが大切です。

BtoC向けパッケージで起きる論点の例

新規導入を考えるときに見落としやすいのが、一般消費者向けの通販を前提にした仕組みと、事業者間の取引の違いです。
工業用粘着テープなどを中心に約3,800品種を扱う日東電工CSシステム株式会社の導入事例では、当初検討した一般消費者向けのパッケージで、事業者間の商取引に必要な機能がカスタマイズでの対応となり、分納の納期回答などに追加費用が必要だったと紹介されています⁶。

これは導入した製品の提供元が掲載した1社の事例で、他の売り手の費用や期間に当てはまるものではありません。
それでも、取引先ごとの価格のような事業者間取引に固有の要件が、製品の標準機能に含まれているとは限らないことを考える材料になります。
選定の場面では、必須の要件ごとに、標準の設定で実現するのか個別の対応になるのかを質問し、回答を記録しておくと、候補を後で比べやすくなります。

▼ 図の内容を文字で読む

• 最新価格の閲覧が必須でない場合
  • 価格の元データを一つにまとめる
  • 取引先別の価格表をそこから出力する
• 最新価格の閲覧が必須の場合
  • 表計算では送り直しの運用が残る
  • 既存の仕組みの設定変更か新規導入を比べる
• 既存の仕組みで必須の価格ルールを表せるか
  • 設定できればデータの置き場所を増やさずに済む
  • 設定できなければ運用で補うか新規導入で解消するかを比べる

小規模事業者の体制と費用面の条件（補助制度の対象・要件）

小規模企業者の定義の確認

補助制度などを調べると、「小規模」という言葉に定義があることに気づきます。
中小企業基本法では、小規模企業者を、おおむね常時使用する従業員の数が20人以下、商業又はサービス業を主たる事業とする者は5人以下の事業者としています³。
中小企業基盤整備機構も、卸売業・小売業を含む商業などの小規模企業者を、常時使用する従業員が5人以下としています⁴。

卸価格を扱う売り手でも、主たる事業がメーカーとしての製造なのか、卸売なのかで当てはまる区分が変わります。
製造業が主であれば20人以下、卸売業が主であれば5人以下が目安になります。
ただし、法律の定義は「おおむね」とされた目安で、補助制度はそれぞれ対象の要件を定めています。
制度を使う場合は、その制度の案内で自社が対象に入るかを確かめる必要があります。

少人数で決める役割

小規模な売り手では、価格を決める人、受注を処理する人、請求を出す人が同じ人であることもあります。
それでも要件定義では、役割を分けて書きます。
価格を決めて承認する役割、価格データを登録・変更する役割、受注と請求で単価を確かめる役割、取引先からの問い合わせに答える役割です。
同じ人が兼ねる場合でも、役割ごとに何をするかを書いておくと、担当が増えたときや休んだときに引き継げます。

外部の支援者や製品の提供元に作業を頼む場合も、要件の中身を決めるのは自社です。
先に触れたとおり、IPAのガイドは要件を定義する責任をユーザ側に置いています¹。
掛率と特価の優先順位や、取引先ごとの見せ方は、取引先との関係を知っている売り手でなければ決められません。
外部に頼めるのは、書き出した要件を仕様に落とす作業や、候補の仕組みで実現できるかの確認です。

補助制度で確認する条件

費用の一部に補助制度を使う場合、2026年のデジタル化・AI導入補助金のインボイス枠（インボイス対応類型）では、インボイス制度に対応し、会計・受発注・決済の機能を1種類以上持つソフトウェアが対象とされています⁵。
導入・活用コンサルティング、導入設定・マニュアル設定・導入研修、保守サポートといった役務も対象経費に含まれます⁵。
補助率は、ソフトウェアの50万円以下の部分について、中小企業は3/4以内、小規模事業者は4/5以内です⁵。

卸価格の管理に使う仕組みでこの類型を検討するなら、その仕組みが受発注などの対象機能を持ち、インボイス制度に対応しているかが最初の確認点です。
価格表の管理だけを行う道具では、この要件に合わないことも考えられます。
また、この類型は受発注や販売管理に特化したものではないため、要件定義で必須とした価格ルールを満たすかどうかは、補助の対象かどうかとは別に確かめます。

補助の要件や受付の時期は、検討する時点の案内で確かめる必要があります。
補助を受けられることを前提に手段を決めると、対象外だったときに計画が崩れます。
手段は要件に照らして選び、その手段が対象になるなら補助を使う、という順番で考えるほうが判断がぶれません。

移行データ・試験・価格改定の運用を決める

現行価格表の移行

どの手段を選んでも、今の価格表を新しい置き場所へ移す作業があります。
IPAのガイドも、主要なドキュメントに運用・移行・総合テストの要求を含めています¹。
卸価格では、移す前に現行の価格表を整理し直す作業が中心になります。

表計算で長く管理してきた価格表には、取引の無くなった取引先の行、改定前の単価を残した列、担当者だけが意味を知るメモ欄が混ざっていることがあります。
移行の要件として、どの取引先・商品の価格を移すか、掛率と個別特価をどう分けて登録するか、過去の価格をどこまで移すかを決めます。

掛率から計算した単価を確定値として移すのか、掛率そのものを移して単価を計算させるのかでも、移行後の改定の手間が変わります。
掛率を持たせておけば、定価を改定したときに取引先ごとの単価を一つずつ直さずに済みます。
反対に、掛率では説明できない単価が多い場合は、それを個別特価として登録し直すことになります。

試験で確かめること

移した価格が正しく当たるかは、実際の注文に近い形で試します。
試験には、過去の受注と請求の明細から、価格ルールが重なる注文を選ぶと確かめやすくなります。
個別特価のある取引先の注文、改定日をまたいだ注文、取引先区分の掛率だけで決まる注文など、価格ルールの項目ごとに一件以上を選び、新しい仕組みで出た単価と当時の請求の単価を照らし合わせます。

単価が合わなかった場合は、設定の誤りなのか、当時の請求の単価が手作業で調整されていたのかを切り分けます。
後者であれば、その調整を規則として要件に加えるのか、例外として運用で扱うのかを決め直します。
見せ方の試験としては、取引先から見える画面や出力した価格表に、他の取引先の価格や社内の原価が含まれていないことも確かめます。

価格改定の運用担当と手順

導入後に続くのは、価格改定と取引先の追加です。
改定は一度決めて終わりではなく、次の改定でも同じ手順へ戻ってくる作業なので、流れとして書き残しておきます。

取引先を追加するときも同じ流れで、どの区分に入れ、どの掛率を当てるかを承認してから登録します。
手順と担当が書かれていれば、価格を決めた人の記憶に頼らずに改定を進められ、改定日前後の注文にどちらの価格を当てるかで受注担当と請求担当の判断が分かれることも減ります。
確認の作業が無くなるわけではありませんが、どの段階で何を見るかが決まるので、確認の漏れに気づきやすくなります。

期間の見通しは自社の作業量から積み上げる

導入にかかる期間は、移す価格表の量、価格ルールの複雑さ、試験の範囲によって変わります。
先に挙げた日東電工CSシステム株式会社の事例では、要件定義からテストサイト開設までが約10カ月だったと紹介されています⁶。
これは約3,800品種を扱う1社の値で、小規模な売り手の標準の期間ではありません。

自社の見通しは、移行する価格表の行数、必須とした価格ルールの数、試験に使う注文の件数を数え、それぞれにかかる作業から積み上げるほうが実態に近づきます。
改定の時期が近いなら、移行と試験を改定の前に終えるのか、改定後の価格で移行するのかも、あわせて決めておきます。

▼ 図の内容を文字で読む

• 改定案を作る
  • 対象の商品と取引先
  • 新しい単価や掛率
• 承認して登録する
  • 承認者の確認
  • 適用開始日を付けて登録
• 取引先へ知らせる
  • 知らせる手段と時期
  • 改定日前後の注文の扱い
• 適用後に確かめる
  • 受注と請求の単価
  • 問い合わせの記録

価格ルールと見せ方を書き出しても、それが事業者間取引の受発注の仕組みで標準の設定として表せるのか、個別の対応になるのかは、社内だけでは判断しにくいところです。

書き出した必須の要件と受注・請求の明細を基に、どの項目が設定で済みそうか、どこに追加の検討が要るかを確かめられます。無料相談で要件を整理する

要点の整理

業務の流れ	価格を決める・渡す・受注・請求・改定のどこで転記や送り直しが起きているか
価格ルール	取引先区分・掛率・個別特価・数量別・期間・履歴・税込税抜のうち、自社の取引で使うものと優先順位
見せ方	取引先ごと、社内の役割ごとに、見られる価格と変更できる人
法的な確認	取引先の販売価格を指定・拘束する仕組みや運用を入れるかどうか
手段の選択	取引先が最新価格を見る必要があるか、既存の仕組みで必須の価格ルールを表せるか
補助制度	対象機能とインボイス対応、自社が対象に入るかを、要件とは別に確認
運用	移行する範囲、試験に使う注文、改定の手順と担当

移行する価格表や試験に使う注文を選ぶ段階では、自社の掛率や個別特価が仕組みの中でどのデータとして扱われるかを知っておく必要があります。 現行の価格表と改定の手順を基に、移行の前に整理すべき項目や、試験で確かめておきたい注文の組み合わせを確認できます。

よくある質問

取引先ごとの掛率と個別の特価は、どう分けて要件に書けばよいですか。

掛率は、取引先や取引先区分、商品群ごとに定価へ掛ける割合を決める規則です。
個別の特価は、特定の取引先・商品について単価を直接決める例外です。
別の項目として書き、両方が設定されたときにどちらを優先するか、特価に適用期間を持たせるかを同じ箇所に書いておくと、単価の出し方が一つに定まります。

仕入側として価格を確認したい場合も、同じ要件定義でよいですか。

扱う範囲が変わります。
仕入側では、仕入先から受け取った見積や価格表と、届いた請求の単価を照合することが中心になり、取引先ごとの見せ方や掛率の設計は要件に入りません。
価格を適用期間付きで記録し、過去の取引の単価をたどれるようにするという考え方は共通して使えます。

要件定義は社内だけで進められますか。ベンダーにどこまで任せられますか。

業務の流れ、価格ルール、見せ方といった要件の中身は、社内で決める事柄です。
IPAのガイドも、要件を定義する責任はユーザ側にあるとしています¹。
外部に任せられるのは、書き出した要件を仕様に落とす作業や、候補の仕組みで標準の設定として実現できるかの確認です。
社内で書き切れない部分があれば、業務の流れと実際の受注・請求の明細を持って相談すると、話が具体的になります。

価格改定の履歴は、どの粒度で残すべきですか。

過去の注文の単価を後から説明できる粒度が目安です。
取引先または取引先区分、商品または商品群、単価または掛率、適用開始日と終了日、承認した人を一組で残しておけば、注文日から当時の単価と根拠をたどれます。
どこまで遡って残すかは、問い合わせや請求の確認で必要になる期間を基に自社で決めます。

補助制度を使う場合、要件定義はいつ終えておくべきですか。

補助を使うかどうかを判断するには、導入する仕組みが補助の対象になるかを確かめる必要があり、そのためには導入する仕組みの候補が決まっていなければなりません。
少なくとも必須の要件と、それを満たす手段の比較は、申請を検討する前に終えておくと判断しやすくなります。
申請の受付時期や手続きは、検討する時点の制度の案内で確かめてください。

取引先に見せる価格と、社内の原価・掛率はどう分けて管理しますか。

見せ方の要件として、価格ルールとは別に書きます。
取引先には自社向けの単価だけを見せ、原価や掛率、他の取引先の単価は社内の限られた人だけが見られるようにするのが基本の形です。
表計算で運用する場合も、元データは一つにして、取引先に出力する項目を固定しておくと、送る価格表に社内の情報が混ざるおそれを減らせます。

1. 1　出典：情報処理推進機構「ユーザのための要件定義ガイド 第2版」（2019年）
2. 2　出典：公正取引委員会「「流通・取引慣行に関する独占禁止法上の指針」の改正について」（2026年）
3. 3　出典：e-Gov法令検索「中小企業基本法 第2条第5項」（現行法令）
4. 4　出典：中小企業基盤整備機構「中小企業・小規模企業者の定義」（2026年）
5. 5　出典：中小企業基盤整備機構「デジタル化・AI導入補助金2026 インボイス枠（インボイス対応類型）」（2026年）
6. 6　出典：フライトソリューションズ「導入事例 日東電工CSシステム株式会社様」（事例掲載時点）