発注システムの取引先別指値設定が反映されない原因と確認手順

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

B2B EC-COLUMN

「取引先ごとに価格が違う」と感じたら最初に確認すること

同じ品目なのに、A社とB社で仕入単価が違う。
取り決めた単価を登録したはずなのに、発注入力の画面に出てきたのは別の金額だった。
こうしたとき、システムが壊れているわけでも、設定が消えてしまったわけでもないことがほとんどです。
多くの発注システムは、品目そのものに持たせた基準の価格と、取引先ごとの取り決めを表す価格条件を別々に持っていて、発注のたびにどちらを使うかを照合しています。
想定と違う金額が出るのは、その照合に自分の設定が乗っていないときで、原因は条件が登録されていない、条件はあるが有効期間の外にある、条件を変えても作成済みの伝票には反映されない、のいずれかに集まります。
この三つを順に確かめるのが、遠回りに見えて一番早い道筋です。

発注入力の画面で品目を選んだ瞬間に、単価の欄に数字が入ります。
その数字がどこから来ているかを、すぐに言えるでしょうか。
多くの発注システムでは、候補は二つです。
一つは品目そのものに登録してある基準の価格、もう一つは取引先との取り決めとして別に登録してある価格条件です。

弥生販売を例にすると、前者が商品台帳の価格、後者が商品価格表の価格にあたります。
商品価格表では仕入先ごとに商品の価格を設定でき、ここで設定した価格は伝票入力時に商品台帳の価格より優先して適用されます²。
逆に、商品価格表に単価を設定しないまま（0のまま）にしておくと、商品台帳の価格が使われます¹。
同じ品目でも仕入先ごとに違う単価が出てくるのは、この二段構えの照合が働いているからです。

ここまでを踏まえると、取引先ごとに価格が違うこと自体は、システムにとって異常ではありません。
むしろ、そう扱えるように作られています。
問題になるのは、自分が設定したつもりの条件が、その照合の対象になっていないときです。
設定が消えたのでも計算が間違っているのでもなく、照合に乗らない条件は最初から無いのと同じ扱いになります。

そこで最初にやることは、原因を推測することではなく、対象を特定することになります。
想定と違う金額が出た伝票を開き、そこに入っている仕入先と品目を控える。
その組み合わせで価格条件が登録されているかを、条件の一覧側から探す。
登録されていなければ、単価は基準価格です。
この場合、システムは仕様どおりに動いていて、足りないのは条件の行そのものということになります。

設定したはずなのに条件が見つからない、ということも起こります。
仕入先が複数のコードで登録されていて別のコードの方に入れていた、品目の枝番や入数違いの別コードに入れていた、得意先向けの価格表と仕入先向けの価格表を取り違えていた、といった形です。
どれも画面上はきちんと登録されたように見えるので、伝票に出ている値と条件側の値を文字どおり突き合わせないと気づけません。

画面の名前は製品によって違います。
商品価格表と呼ぶものもあれば、購買情報マスタ、仕入単価マスタといった名前のものもあります。
ただ、取引先と品目の組み合わせを単位に条件を持ち、条件が無ければ基準価格に戻るという構造は、今回確認した範囲では共通していました。
すべての製品がこの作りだと言い切れるわけではありませんが、自社の製品がこの構造になっているかどうかは、何を調べるにしても出発点になります。

指値はどの単位で設定し、何が優先されるのか

仕入先×品目を単位にした価格条件

条件を持てる単位の広さは、製品によって違います。
SAPの購買管理モジュールについて解説した技術記事では、購買情報マスタを仕入先×品目、仕入先×品目×購買組織、仕入先×品目×購買組織×プラントという単位で設定でき、設定する範囲を広げるほど細かい価格条件を持てるとされています⁴。
これはベンダーの一次資料そのものではなく第三者による解説で確認した内容なので、仕様の細部まで同じ重みで受け取るのではなく、こういう作り方があるという事例として読むのが安全です。

この広さの違いは、取り決めの形が複雑になったときに効いてきます。
同じ品目を同じ仕入先から買っていても、本社の購買部がまとめて契約した単価と、工場に直納するときの単価が別になっている、という取り決めは珍しくありません。
条件を仕入先×品目までしか持てない仕組みでは、この差は条件として表現できません。
結果として、品目コードを拠点別に分ける、発注のたびに手で単価を上書きする、といった回避策に逃げることになり、どちらも後から誰かが間違えます。

ですから、設定方法を調べる前に確認したいのは、自社の仕組みがどこまで条件を分けられるかです。
取引先までなのか、品目までなのか、拠点や購買組織まで分けられるのか。
ここが決まると、いま困っている取り決めがそもそも条件として表現できるものなのか、運用で吸収するしかないものなのかが見えてきます。

有効期間を持たせる設計

価格は、取引先が同じでも時期で変わります。
年度単位で結び直す取り決め、原材料の値動きに応じた改定、季節や数量に紐づく期間限定の特価。
こうした時間の軸を、条件そのものが持てるかどうかで、改定時の作業は大きく変わります。

先の解説では、購買情報マスタの条件に有効開始日と終了日を設定でき、契約に基づく期間限定の価格を表現できるとされています⁴。
条件が期間を持てるなら、改定後の単価をあらかじめ別の行として登録しておけば、改定日が来た時点で適用される単価が自動的に切り替わります。
人が当日に作業する必要がなくなるという意味で、これは運用の負荷に直結する違いです。

一方で、弥生販売の商品価格表については、今回確認したサポートページに有効期間の設定項目についての記載がなく、期間を持てるかどうかは分かりませんでした。
仮に期間を持てない仕組みであれば、改定日に人が値を入れ替えることになります。
入れ替える日と、実際に発注が走る日のずれが、そのまま誤った単価になります。
自社の製品がどちらの設計かは、改定のたびに誰が何をするかを決める前に確認しておきたいところです。

優先順位：個別設定が基準価格に勝つ

優先順位については、確認した資料の方向が揃っていました。
弥生販売では、商品価格表に登録した価格が商品台帳の価格より優先して伝票に適用されます¹²。
SAPの購買情報マスタについても、その設定値は品目マスタの値より優先されると解説されています⁴。
どちらも、全体に効く一般的な価格を基準に置き、取引先を特定した個別の条件でそれを上書きする、という考え方です。

この考え方自体は納得しやすいものです。
基準価格は、まだ取り決めのない相手や、新しく登録した品目にも何らかの金額を出すための受け皿であり、個別の条件はそこに実際の取り決めを重ねるためのものだからです。
条件を入れたのに基準価格が出るなら、上書きが働いていない理由を探せばよい、と考えの筋道が決まります。

ただし、個別の条件どうしが重なったときにどちらが勝つかは、まったく別の話です。
数量に応じた値引きと、期間限定の指値が、同じ仕入先と品目の組み合わせに同時に効いている場合。
あるいは、広い単位の条件と細かい単位の条件が両方残っている場合。
こうした重なりの厳密な上下は、今回確認した資料からは一般化できませんでした。
重なりが起こり得る取り決めを扱っているなら、条件の種類ごとの優先順位を自社の製品の仕様書やサポート窓口で確かめておくのが確実です。
ここを想像で決めると、金額が合わない理由を探し続けることになります。

設定した指値が発注時に反映されない原因と確認手順

原因①条件が未登録のまま

もっとも多いのは、条件そのものが照合に乗っていない状態です。
弥生販売では、商品価格表に単価を設定しない場合、つまり0のままにしておくと商品台帳の価格が適用されます¹。
注意したいのは、行だけがあって単価が入っていない状態も、結果としては未登録と同じ扱いになるという点です。
一覧に仕入先の名前が並んでいると登録済みに見えてしまうので、単価の欄まで見ないと判断できません。

登録したつもりなのに見つからない場合は、前の節で挙げたコードの取り違えが候補になります。
ここで避けたいのは、差額の大きさから原因を当てにいくことです。
数パーセントのずれだから数量値引きだろう、大きく違うから基準価格だろう、といった見立ては当たることもありますが、外れたときに別の原因を疑う機会を失います。
伝票に出ている仕入先コードと品目コードを、条件側に登録されている値とそのまま突き合わせる。
遠回りに見えて、ここが一番早く済みます。

原因②有効期間外

条件はある、単価も取り決めどおり、それでも適用されない。
条件が期間を持つ仕組みであれば、発注の日付が有効期間の外にあるという可能性が残ります⁴。
この場合、条件の画面を開いても単価は正しく見えるので、期間の欄まで確認しないと原因にたどり着けません。

起きやすいのは切替のタイミングです。
旧条件の終了日と新条件の開始日が一日だけ空く、開始日を改定日の翌日にしてしまう、といったずれです。
空いた日に発注すると、その組み合わせには有効な条件が無いので基準価格が適用されます。
しかも金額そのものは出るためエラーにならず、誰も止まりません。
気づくのは、たいてい検収や請求の突合の段です。

もう一つ見落としやすいのが、どの日付で期間を判定しているかです。
発注日なのか、納期なのか、計上日なのか。
ここは製品によって違いますし、同じ製品でも伝票の種類で違うことがあります。
期間内のはずなのに外れている、という場合は、判定に使われる日付を確認する価値があります。

原因③既存伝票には遡及しない

条件を直したのに、過去の伝票の金額が変わらない。
これも設定ミスではなく、設計どおりである場合があります。
ロジレスのサポートFAQでは、受注伝票の販売単価が優先され、商品マスタの販売価格は手動で伝票を起こすときに明細行へ自動補完するためだけに使われると説明されています³。
そのため、商品マスタの販売価格を変更しても、登録済みの受注伝票明細行には影響しないとされています³。

これは受注側の伝票についての説明であり、発注側の伝票も同じ仕様だと決めつけることはできません。
ただ、マスタは伝票を作る瞬間に値を写すだけで、以後は伝票側の値が実体になる、という設計そのものは珍しいものではありません。
自社の発注システムで、価格条件の変更が作成済みの発注伝票に遡及するのかどうかは、確認しておく価値のある仕様です。

遡及しないのであれば、直す対象は条件だけではありません。
条件を修正して作業を終えると、すでに発注済みの分だけが旧単価のまま検収と支払に流れていきます。
条件の修正と、既に出ている伝票のうち修正が必要なものの洗い出しは、別の作業として扱う必要があります。
逆に遡及する仕組みであれば、条件を直した瞬間に過去の伝票の金額まで動くので、動いて困る伝票がないかを先に確かめることになります。
どちらの設計でも作業は発生しますが、中身がまったく違います。

確認の順番

ここまでの三つは、並列に並んでいるのではなく、確認する順番があります。
条件の有無、有効期間、伝票の作成タイミングの順です。
条件そのものが無ければ期間を見ても意味がありませんし、期間が外れているなら伝票の作成時刻を調べる必要もありません。
手前から潰していくと、無駄な調査をせずに済みます。

実際の手順に落とすと、まず対象の伝票から仕入先、品目、日付を控えます。
次にその組み合わせの価格条件を探し、見つかったら有効期間に伝票の日付が入っているかを見ます。
期間も問題なければ、伝票の作成日時と条件の更新日時を比べ、条件を直したのが伝票を作った後だったのかを確かめます。
ここまで辿れば、設定の問題なのか、仕様どおりの挙動なのかはほぼ切り分きます。

この順番で確認しておくと、ベンダーのサポートに問い合わせるときにも話が早くなります。
どの組み合わせで、どの日付の伝票で、条件はこう登録されていて、作成日時はこうだった、と事実を揃えて渡せるからです。
金額が合わないという一言だけで問い合わせると、結局この確認を往復しながらやり直すことになります。

取引先数が多い・条件変更が頻繁な場合の運用の考え方

件数が増えても壊れない設計

仕入先ごとに商品の価格を設定できる仕組みは²、取引先が増えれば条件の行が増えるだけで、仕組みそのものが破綻するわけではありません。
設定の考え方も、取引先が数社でも数百社でも変わりません。
その意味では、件数は本質的な問題ではないと言えます。

実際に増えて困るのは、行の数ではなく、経緯の分からない行です。
誰がいつ、どういう取り決めに基づいて入れたのかが分からない条件が残り、改定のときに触ってよいのか判断できなくなる。
そうなると、既存の条件を残したまま新しい条件を足す、という選択に流れがちで、重なりがさらに増えます。
件数の問題は、設定の難しさではなく、探せるかどうかと、記録が残っているかどうかの問題として現れます。

変更時に競合しやすい点

改定のたびに起きやすい食い違いは、いくつか型があります。
一つ目は、期間の重複と空白です。
同じ組み合わせに期間の重なる条件が二つあると、どちらが採用されるかは製品の仕様によりますし、意図と違う方が採られていても画面上は何事もなく金額が出ます。
空白の方は前の節で触れたとおり、基準価格に落ちます。

二つ目は、単位の取り違えです。
拠点や購買組織まで条件を分けられる仕組みでは⁴、広い単位の条件を直したつもりでいても、細かい単位に古い条件が残っていてそちらが効き続ける、ということが起こります。
優先の方向は、より特定された条件が勝つ設計が一般的ですが、どの階層までが特定扱いになるかは製品の仕様です。
自社で複数の階層を使っているなら、改定時に見る範囲をあらかじめ決めておかないと、毎回取りこぼします。

三つ目は、一括更新の扱いです。
表計算で条件を作って取り込む運用は件数が多いほど現実的ですが、一行のずれが全取引先に及びます。
取り込み前のファイルと、取り込み後の条件を別の人が突き合わせる余地を残しておくと、戻し作業の規模が変わります。

運用の3ステップ

ここまで確認できた仕組み、つまり個別の条件が基準価格に優先すること、条件が有効期間を持ち得ること、変更が既存の伝票に自動では及ばない場合があることを踏まえると、改定時にやることは三つに整理できます。
以下は特定の製品が推奨する手順ではなく、確認した仕組みから導いた整理です。

一つ目は、対象の洗い出しです。
改定の対象になる仕入先と品目の組み合わせを、条件側の一覧から抜き出して並べます。
取り決めの文書に載っている品目と、システムに登録されている条件の行が一対一で対応しているかを、この段で見ておきます。
文書にあるのに条件が無い組み合わせは、改定ではなく新規登録になります。

二つ目は、期間の接続です。
条件が有効期間を持てる仕組みなら、旧条件の終了日と新条件の開始日を隙間なく繋ぎます。
期間を持てない仕組みなら、いつ誰が値を入れ替えるかを決め、入れ替えより前に発注が走らないようにします。
どちらにしても、改定日の前後一日が最も事故の起きやすい区間です。

三つ目は、検算です。
変更を終えたら、対象の組み合わせで発注伝票を一件作り、画面に出てくる単価を見ます。
保存せずに破棄して構いません。
条件の画面で正しく見えることと、発注入力で正しい単価が出ることは別の確認であり、照合に乗っているかを確かめられるのは後者だけです。

この三つで事故が起きなくなる、ということではありません。
減らせるのは、検収や請求の突合で差額に気づいて、伝票を直し、仕入先に連絡し、場合によっては支払を止めるという手戻りです。
気づく場所を支払の後ろから発注の前に移す、という程度の効果だと考えておくと、どこに手間をかけるかの判断がぶれません。

指値を変更する際、誤反映を防ぐ確認・承認の考え方

発注金額の承認とは別物

購買管理システムには、承認ワークフローの機能を備えたものがあります。
購買金額に応じて、課長まで、課長から部長へ、さらに経理部長や役員へ、というように承認の段数が増えていく流れを自動化できるという説明がされています⁵。
金額が大きいほど多くの目が通る仕組みで、発注の統制としては理にかなっています。

ここで区別しておきたいのは、この承認が何を見ているかです。
承認されているのは、この金額の発注をしてよいかという判断であって、この単価が取り決めどおりかという判断ではありません。
むしろ、単価が誤って低く設定されていれば発注金額も小さくなり、承認の段数は減って通りやすくなります。
金額の承認が通ったことは、価格条件が正しいことの裏付けにはなりません。

マスタ変更権限を絞る

では、価格条件の変更そのものを承認の対象にできるかというと、そうした機能を備えているかは製品によって異なり、今回確認した資料の中には、その仕組みを説明したものはありませんでした。
自社の製品に条件変更の申請と承認の機能があるなら、それを使うのが最も確実です。
無い前提で考えると、手当てできるのは権限と記録になります。

まず、誰が条件を変えられるかを絞ります。
発注業務に関わる全員が条件を触れる状態だと、発注のたびに「この相手は安いはずだ」と条件側を直してしまう人が出てきます。
一時的な事情で単価が変わるときは、条件を直すのではなく伝票側で対応する、という線引きを決めておくと、条件が実際の取り決めを表した状態に保たれます。

次に、変更の根拠と条件を結び付けます。
取り決めの文書、見積書、改定の通知といった元になるものと、いつどの条件を変えたかを対応させておく。
これは機能ではなく記録の習慣ですが、前の節で触れた「経緯の分からない行」を増やさないための、ほぼ唯一の手段です。
件数が多い場合ほど、後から効いてきます。

変更後に検算する

検算については前の節で手順として触れましたが、ここでは誰がやるかという観点を補います。
条件を入れた本人が検算すると、自分が入れた数字を自分で見ることになり、取り決めの文書と照らすという作業が形だけになりがちです。
入れた人とは別の人が、発注入力の画面を開いて出てくる単価を見る。
これだけで、読み違いや入力ミスの多くは発注の前に止まります。

見るのは単価の金額だけではありません。
どの条件が当たってその単価になったのかも、合わせて確認したいところです。
たまたま同じ金額でも、意図した条件とは別の条件が当たっているなら、その条件の期間が切れた時点で単価が変わります。
金額が合っているうちは誰も疑わないので、見つけるならこの場しかありません。

単価の差に検収や支払の段で気づくと、影響は伝票の訂正だけに収まりません。
仕入先への連絡、差額の扱いの取り決め、場合によっては支払の保留まで広がり、関わる人も増えます。
条件を変えた直後に一件だけ発注画面を開く、という小さな作業で、その連鎖に入らずに済む場面があります。
どこまで仕組みで守り、どこから運用で補うかは製品の作り次第ですが、見るべきものが単価と条件の二つだという点は、どの製品でも変わりません。

価格条件をどの単位まで分けられるか、有効期間を持てるか、変更が既存の伝票に及ぶかは製品ごとに違い、仕様書を読むだけでは自社の取り決めを表現しきれるかまでは判断しにくいためです。

いまの取り決めが条件として表現できる形になっているか、改定のたびに手作業として残るのはどこかを、現在の発注の流れに沿って確認できます。無料相談で要件を整理する

要点の整理

単価の出どころ	取引先×品目の価格条件がなければ品目の基準価格が使われる
優先順位	取引先を特定した個別の条件が基準価格に優先する
有効期間	期間外の条件は適用されない。改定時は旧条件の終了日と新条件の開始日を接続する
既存伝票	条件の変更が作成済みの伝票に及ぶかは仕様次第。遡及しないなら伝票側の洗い出しが別途必要
確認の順番	条件の有無→有効期間→伝票の作成タイミング
承認との関係	発注金額の承認は、単価が取り決めどおりかの裏付けにはならない

取引先が増え改定の頻度も上がると、価格条件の管理は設定の話から、誰が変えて誰が確かめるかという運用の話に変わるためです。 条件の持ち方と変更の流れを棚卸しして、仕組みで吸収できる範囲と、権限や検算のルールで補う範囲の線引きを相談できます。

よくある質問

弥生販売の「商品価格表」と「商品台帳」で価格が違う場合、伝票にはどちらが反映されますか

商品価格表に登録した価格が、商品台帳に登録した価格より優先して伝票に適用されます¹²。
ただし、商品価格表の単価を設定しないまま（0のまま）にしている場合は、商品台帳の価格が適用されます¹。
一覧に行があるだけでは登録済みとは限らないので、単価の欄に値が入っているかまで確認してください。

指値の有効期間が切れた後、自動的にどの価格に戻りますか

条件に有効開始日と終了日を設定できる仕組みでは、期間の外にある条件は適用の対象になりません⁴。
その組み合わせに他の有効な条件が無ければ、品目側の基準価格が使われることになります。
ただし「切れたら必ず基準価格」と一律に言えるわけではなく、同じ組み合わせに別の期間の条件が登録されていれば、そちらが使われます。
改定時に旧条件の終了日と新条件の開始日が離れていると、その間だけ基準価格に落ちるので、接続を確認するのが実務上の要点です。

発注伝票を作成した後に価格条件（マスタ）を修正したら、その伝票の金額も変わりますか

遡及するかどうかは製品の仕様によります。
ロジレスのサポートFAQでは、受注伝票の販売単価が優先され、商品マスタの販売価格は手動で伝票を起こすときに明細行へ自動補完するためだけに使われるため、商品マスタの価格を変更しても登録済みの受注伝票明細行には影響しないと説明されています³。
これは受注側の伝票についての説明なので、発注側でも同じとは限りませんが、マスタは伝票作成時に値を写すだけという設計は珍しくありません。
遡及しない仕組みであれば、条件の修正とは別に、既に出ている伝票のうち直す必要があるものを洗い出す作業が残ります。

取引先が購買組織や拠点（プラント）単位で複数に分かれている場合、指値の優先順位はどう変わりますか

SAPの購買情報マスタについての解説では、仕入先×品目、仕入先×品目×購買組織、仕入先×品目×購買組織×プラントという単位で条件を設定でき、設定する範囲を広げるほど細かい価格条件を持てるとされています⁴。
また、購買情報マスタの設定値は品目マスタの値より優先されるとされています⁴。
一方、細かい単位の条件と広い単位の条件が同時に存在する場合の厳密な優先順位は、今回確認した資料からは一般化できませんでした。
複数の階層を使い分けているなら、自社の製品の仕様書やサポート窓口で、どの単位が優先されるかを個別に確認することをおすすめします。

条件を入れたはずなのに基準価格が出ます。どこから見ればよいですか

条件の有無、有効期間、伝票の作成タイミングの順に見るのが効率的です。
まず対象の伝票から仕入先、品目、日付を控え、その組み合わせで条件が登録されているかを条件側の一覧から探します。
見つかれば有効期間に伝票の日付が入っているかを確認し、それも問題なければ、伝票の作成日時と条件の更新日時を比べます。
このとき、差額の大きさから原因を推測せず、伝票に出ている仕入先コードと品目コードを条件側の値とそのまま突き合わせてください。
仕入先が複数のコードで登録されている、品目の枝番が違う、といった取り違えは、画面上は正しく登録されたように見えます。

1. 1　出典：弥生株式会社「弥生販売 サポート情報『取引先や商品ごとに価格を細かく設定したい』」（2026年確認）
2. 2　出典：弥生株式会社「弥生販売 サポート情報『商品価格表の概要』」（2026年確認）
3. 3　出典：株式会社ロジレス「logiless サポートFAQ『商品マスタの商品名／販売価格と、受注伝票明細行の商品名／販売単価はどちらが優先して登録されますか』」（2026年確認）
4. 4　出典：tokulog「【SAP】購買情報マスタ設定方法について徹底解説！」（2026年確認）
5. 5　出典：ビズネット株式会社「購買ワークフローで何が変わる？承認遅延・属人化を防ぐ仕組み」（2026年確認）