受注管理システムと販売管理システムの連携で渡す項目とは？最低限必要な項目と対応の進め方

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

B2B EC-COLUMN

受注管理から販売管理へ渡す最低限の項目（識別項目＋明細項目）

受注管理システムの一覧を開いて、その横に販売管理システムの伝票入力画面を並べ、片方を見ながらもう片方へ打ち直す。
月末にこの作業をしていると、単価の桁がずれたり、どの注文の話か伝票を探し直したりする場面が出てきます。
この手間の正体は、二つのシステムの間で何を渡すかが決まっていないことにあります。
受注データは、伝票番号・顧客コード・受注日・納期・担当者といった「どの取引か」を示す識別項目と、商品コード・数量・単価といった「いくらになるか」を決める明細項目に分かれます。
この二種類が過不足なく渡っているかをまず確かめ、名称や粒度の違いはマスタの対応表で吸収し、連携方式は更新の頻度と自動化したい範囲から選ぶ、という順で考えると迷いが減ります。

伝票番号・顧客コード・受注日・納期・担当者が担う役割

受注管理システムの受注一覧と、販売管理システムの売上伝票入力画面を並べて転記するとき、最初に手が止まるのは金額そのものではないことが多いものです。
止まるのは、この注文は誰宛てで、どの伝票と結び付くのかを確かめる部分です。
商品名と数量が目に見えていても、販売管理側で伝票を起こすには、先に取引の相手と識別番号が決まっている必要があるからです。

受注データを扱うシステムが、この「どの取引か」をどう持っているかは、API仕様を見ると輪郭がはっきりします。
ネクストエンジンの受注伝票検索APIでは、伝票番号、顧客コード、受注日、出荷予定日、受注担当者名といった項目が、伝票（ヘッダー）の単位で定義されています¹。
項目の呼び名は製品ごとに違いますが、伝票そのものを指すID、相手を指すコード、時点を示す日付、責任の所在を示す担当者という四つの役割が、明細より一段上の階層にまとまっている点は読み取れます。

日付が二つある点は、渡す項目を決めるときに迷いやすいところです。
受注日は注文が成立した時点を指し、出荷予定日は納期に関わる見込みの日付です。
販売管理側で売上をどの日付の取引として扱うかは自社の運用で決まっているはずですが、その基準に使う日付が連携で渡っていなければ、結局は受注画面を開いて確認することになります。
月末にまたがる注文ほど影響が出やすいので、日付は一つあれば足りると削らずに、それぞれ何の日付なのかを揃えて渡しておくほうが後で困りません。

受注担当者名のような項目は、金額計算には直接効きません。
それでも渡す価値があるのは、後工程で疑問が出たときの戻り先になるからです。
請求書を出す段になって単価の根拠が分からない、納期の相談がどうなっていたか確認したい——そのたびに受注管理システムを検索し直すのか、販売管理側の伝票からすぐ担当者にたどり着けるのかで、月末の負荷は変わります。

商品コード・数量・単価がそろって初めて金額が決まる

ヘッダー側の項目がすべて揃っても、売上金額は出ません。
金額を決めるのは、何を、いくつ、いくらで売ったかという明細側の情報です。
ネクストエンジンのAPIでは、商品コード・受注数量・単価は受注伝票検索ではなく、受注明細検索という別のエンドポイントに定義されています²。
画面上では一つの受注として見えていても、データとしては取得の経路が分かれている、という構造です。

この分かれ方は、一枚の伝票に商品が複数行並ぶことを考えると自然です。
伝票の情報は一件につき一組ですが、明細は行の数だけ存在します。
そのため連携で渡すときも、ヘッダーの一件と明細の複数行をどう結び付けるかが必ず論点になります。
明細行の側に、どの伝票に属する行なのかを示す値が入っていなければ、受け取った販売管理システムは行をどの伝票にぶら下げればよいか判断できません。

単価についても、渡す前に確かめておきたい点があります。
税を含む金額なのか含まない金額なのか、値引きや送料を明細の一行として持っているのか伝票単位の調整額として持っているのかは、製品ごとの設計で異なります。
ここは一般論で決め打ちできる部分ではないので、自社が使う二つの製品の仕様書で、同じ単価という言葉が何を指しているかを突き合わせることになります。

ここで挙げた項目名は、確認できたベンダーのAPI仕様に基づく一例です¹²。
他の製品では呼び名も分け方も違います。
持ち帰って使えるのは個々の名前ではなく、受注データを取引を特定する情報と金額を計算する情報の二種類に分けて数える見方のほうです。
この見方があると、自社の連携仕様書を開いたときに、どちらの種類が薄いのかを見つけやすくなります。

出典：ネクストエンジンAPI 受注伝票検索リファレンス／受注明細検索リファレンス（2026年確認時点、同社APIで定義されている項目の区分）

項目名・粒度の違いをどう対応づけるか（マスタ対応表・コード変換）

コードは各システムの内部の名前でしかない

前の節で見た商品コードや顧客コードは、そのシステムの中で通用する識別子です²。
受注管理システムがある商品をA-1024と呼んでいても、販売管理システムでは自社の採番規則にもとづく別の文字列で同じ商品を管理している、ということが普通に起こります。
つまり両方に商品コードという欄があっても、値をそのまま移せば、受け取った側では存在しないコードとして弾かれるか、別の商品として扱われます。
連携で必要なのは、渡すことだけでなく、渡す前に置き換えることです。

食い違いは名前だけでなく、一件の数え方にも現れます。
受注側ではセット商品を一行として受けているのに、販売管理側では構成品ごとに在庫と売上を持っている。
色とサイズを一つの商品のバリエーションとして持つか、別々の商品コードとして持つか。
数量の単位がバラなのかケースなのか。
こうした粒度の違いは、項目名だけを並べた対応表では解消しません。
受注側の一行が販売管理側の何行に相当するのかまで決めて、初めて移した後の数量と金額が合います。

実務的な受け皿になるのが、商品マスタと顧客マスタの対応表です。
受注側のコードと販売管理側のコードを並べ、照合の基準にします。
大切なのは、これを最初に一度作る資料ではなく、運用の中で更新し続ける台帳として置くことです。
商品が増えれば行が増え、取引先の統廃合があれば顧客側の行を直す必要が出ます。

下の表は、対応表にどんな列を持たせると運用が回るかを組み立てたものです。
確認した項目の構造から逆算した整理であって、どこかの製品の仕様として決められているものではありません。
自社の商品の持ち方に合わせて、列は増減させてかまいません。

どちらのコード体系を正とするかを先に決める

対応表を作り始める前に決めておくと後戻りが減るのが、どちらのコード体系を正とするかです。
新しい商品を扱うとき、受注管理側で先に採番して販売管理側へ配るのか、販売管理側で採番したものを受注側に登録するのか。
この向きが決まっていれば、対応表への追記も一方向の作業になります。

正が決まっていないと、両方のシステムでそれぞれ新規登録が起こります。
すると、対応表に載っていないコードを持つ受注データが流れてくる状態が生まれます。
取り込む側はその行を処理できませんから、エラーとして止まるか、どちらにも紐づかないデータとして残ります。
どちらにしても、気づいた人が手で調べて直す作業が発生します。

決めるのは技術というより手順です。
新しい商品を扱い始めるとき、誰が正の側に登録し、誰が対応表へ追記し、誰がもう一方のシステムへ反映するのか。
この順番が短い文書になっていれば、担当が替わっても同じ形で回ります。
逆に、対応表が個人の手元のファイルにしかない状態は、連携そのものより先に詰まりやすい部分です。

なお、ここで述べた対応表の持ち方や正の決め方は、確認した項目の構造から導いた運用上の考え方です。
特定のベンダーが公開している変換手順そのものではありません。
実際の変換をどこで行えるか——受注側の出力時なのか、間に入るアプリなのか、販売管理側の取込時なのか——は、次に見る連携方式によって選べる場所が変わります。

連携方式（API連携・CSV連携・手動）によって扱える項目や更新頻度はどう変わるか

CSV連携：ファイルの形でまとめて渡す

渡す項目が決まったら、次はそれをいつ、どうやって渡すかです。
もっとも身近なのはCSVでしょう。
ネクストエンジンの基幹システム連携の説明では、受注データや在庫情報などの各種データをダウンロードする形で外部システムへ受け渡す方式が案内されています³。
受注側から出したファイルを、販売管理側の取込機能で読み込む、という組み合わせです。

CSVと聞くと、毎回人がファイルを書き出して手でアップロードする姿を思い浮かべがちですが、そうとは限りません。
商蔵奉行クラウドの他システム連携では、指定のフォルダーにCSVファイルを保存しておけば、スケジュールに応じて自動で実行される仕組みが案内されています⁴。
ファイルを置く場所と実行の時刻を決めてしまえば、日々の操作から人の手を外せる範囲がある、ということです。

CSVで進める場合に効いてくるのが、前の節で整理した対応表です。
ファイルの列は固定ですから、どの列に何のコードを入れるかを決めた時点で、変換をどこで行うかも決まります。
受注側から出す時点で販売管理側のコードに直しておくのか、受注側のコードのまま渡して取込時に変換するのか。
前者なら出力の仕組みを、後者なら取込の設定を触ることになるので、どちらが自社で手を入れやすいかで選びます。

もう一つ、ファイルで渡す方式は、その時点の断面を渡す方式でもあります。
出力してから取り込むまでの間に受注側で変更が入れば、その差分は次の回に持ち越されます。
キャンセルや数量変更が起きやすい商材では、どの時点のデータを正とするか、変更分を上書きするのか取り消し行を立てるのかを決めておかないと、販売管理側に古い金額が残ります。

API・アプリ連携：コネクタを介して反映される

もう一方の形が、専用のアプリやAPIを介して接続する方式です。
ネクストエンジンでは、アプリ連携としてECコネクターやつながるGatewayといった専用の連携アプリを介した接続方法が案内されています³。
商蔵奉行クラウドでは、API連携としてkintoneなど独自の業務アプリとの接続が案内され、外部システムの取引先データや仕訳伝票データの受け入れ・作成を自動化するとされています⁴。
いずれも、ファイルを介さずに、間に立つ仕組みがデータを受け渡す形です。

ここで項目の話に戻ると、API連携だからといって受注データのすべての項目が自動的に相手へ届くわけではありません。
間に立つアプリやコネクタが、どの項目を読み、相手側のどの欄に書き込むかをあらかじめ決めています。
渡したい項目がその範囲に入っていなければ、方式を変えても手で補う部分は残ります。
検討の順番としては、方式を先に選ぶより、渡したい項目を先に並べ、その項目を扱える接続があるかを確かめるほうが確実です。

方式ごとの速さや正確さを数値で比べられる公開資料は限られており、更新の間隔も契約しているプランや間に入るアプリの仕様によって変わります。
そのため、方式の違いは仕組みの違いとして押さえておき、実際にどのくらいの頻度で反映されるかは、自社が使う製品の条件として確認する形になります。
営業担当に尋ねるときも、速いですかではなく、この項目をどの間隔で渡せますかと聞くほうが答えが返ってきます。

手動入力のままにする場合に残るもの

すべてを自動にしなくても回っている会社はあります。
件数が少なければ、人が転記するほうが早い場面もあります。
ただし手動を続けるなら、残るのは入力の手間だけではありません。
どの伝票がまだ販売管理側に入っていないかを、人が覚えているか、別の一覧で管理することになります。

手動で残す部分を決めるときは、量が少ないからという理由だけでなく、間違えたときに気づける場所があるかも一緒に見ておくと判断しやすくなります。
たとえば、例外的な受注だけを手入力にするなら、その伝票に印を付けて月末に必ず突き合わせる、という確認の置き場所まで含めて決めておく、といった形です。
下の表は、ここまでに見た三つの方式を、受け渡しの形と決めておくことで並べたものです。

出典：商蔵奉行クラウド 他システム連携ページ（2026年確認時点、CSVファイル自動連携機能の説明）

項目が不足・不一致のまま連携するとどのような業務上の支障が生じるか

明細が欠けると、売上金額が確定しない

ここまでの項目の分け方が分かると、連携がうまくいかないときに何を疑えばよいかも絞れます。
まず、数量と単価が渡っていない場合です。
これらは明細側のエンドポイントで初めて取得できる項目でした²。
ヘッダーだけを連携していると、販売管理側には誰からいつ受けた注文かは入っているのに、いくらの売上なのかが空のまま伝票が並ぶことになります。

そうなると、結局は受注管理システムを開いて金額を確認する作業が残ります。
二重入力を減らすつもりで連携したのに、転記が確認に置き換わっただけ、という状態です。
しかもこの確認は、伝票の件数だけ発生します。
連携で何が減るのかを見積もるときは、入力の回数だけでなく、確認のために別画面を開く回数も一緒に数えておくと、期待とのずれが小さくなります。

金額が渡っていても、粒度が合っていないと別の形でずれます。
税込の単価を税抜の欄に入れてしまえば、一件ごとの差は小さくても、合計では無視できない差になります。
ここで気をつけたいのは、差額の大きさから原因を決めつけないことです。
少しのずれだから端数処理だろうと当たりを付けても、実際には値引きの行が渡っていなかった、ということがあります。
差がどこから来ているかは、伝票の明細を一件開いて、受注側の行と販売管理側の行を突き合わせないと分かりません。

識別項目が欠けると、そもそも突合ができない

逆に、明細は渡っているのに伝票番号や顧客コードが欠けている場合はどうなるか。
金額は入っていても、それがどの取引に対応するのかを機械的に判断できません。
同じ取引先から近い日付で似た注文が入っていれば、人の目でも見分けがつかなくなります。
伝票番号は、後から二つのシステムを突き合わせるための共通の手がかりですから、金額に関係しないという理由で落とすと、確認のたびに費用がかかります。

困るのは、取引先から先月の請求のこの一行は何かと問い合わせが来たときです。
販売管理側の伝票に受注側の伝票番号が入っていれば、受注管理システムで検索して、いつ誰が受けた注文かをすぐ示せます。
入っていなければ、日付と金額を頼りに候補を絞る作業から始めることになります。
この差は普段は表に出ませんが、問い合わせや監査の場面でまとめて効いてきます。

こうした支障がどのくらいの頻度で起き、どの程度の負担になるかを示す統計までは示せません。
ここで言えるのは、確認した項目の構造から導けるところまでです。
金額を決める項目が明細側にあり、取引を特定する項目がヘッダー側にある以上、どちらかが欠ければ、欠けた側の判断を人がやり直すことになります。
自社の連携で何が残っているかを見るときも、いま人が何を確認しているかを先に書き出すと、どちらの種類が足りないのかが見えてきます。

自社のシステム構成を検討する際に項目面で確認すべきポイント

自社が使う製品の仕様書で、項目名と単位を突き合わせる

ここまでの整理を自社に当てはめるとき、最初に開くのは製品の連携仕様書やAPIドキュメントです。
見るのは機能一覧ではなく、項目の一覧です。
受注側が出せる項目、販売管理側が受け取れる項目を並べ、同じ行に置けるものを結んでいきます。
この作業は地味ですが、営業資料を何社分読むより早く、連携できるかどうかの見当がつきます。

突き合わせで拾いたいのは、両方にあって意味が違う項目です。
単価が税込か税抜か、日付が受注日か出荷予定日か、数量の単位が販売単位か入数か。
名前が同じだと見落としやすく、しかも取り込んだ後に金額のずれとして出てくるので、確認の価値が高い部分です。

片方にしかない項目が見つかったときは、扱いを決めておきます。
渡さないと決めるか、備考欄などの自由記入項目に入れて残すか、システムの外で管理するか。
この三つのどれを選んだかを記録しておくと、後から誰かが同じ項目を探したときに、抜けたのか意図的に外したのかが分かります。

対応表と更新の手順を、誰が持つかまで決める

仕様の確認と同じくらい後で効いてくるのが、対応表を誰が持つかです。
商品を登録する担当と、売上を計上する担当が別の部署にいる会社は珍しくありません。
新商品が増えるたびに対応表を更新する必要があるのに、更新の起点がどちらにあるかが決まっていないと、どちらも手を付けないまま連携だけが先に止まります。
担当者の名前ではなく、新商品登録や取引先の追加といった出来事ごとに誰が動くかを決めておくほうが、異動があっても崩れません。

連携が動き始めた後も、項目の仕様は変わります。
受注側に新しい属性が増える、販売管理側でコードの桁数が変わる、間に入るアプリが対応項目を追加する。
変更の知らせが届く先が決まっていないと、月末の締めで数字が合わなくなってから気づくことになります。
仕様変更の案内をどこで受け取り、誰が対応表と設定を見直すかまで含めて、連携の運用と考えておくと安全側に倒せます。

項目の話は、システム選定の中では目立ちません。
それでも、受注時に入れた情報がそのまま売上と請求まで流れるかどうかは、結局この部分で決まります。
渡す項目を識別と明細に分けて数え、コードは対応表で置き換え、方式は渡したい項目に合わせて選ぶ。
この順で自社の状況を書き出しておけば、製品を比べるときにも、どこを質問すればよいかがはっきりします。

自社の仕様書と突き合わせる前に、具体的な項目名がどう定義されているかを一度見ておくと、抜けを見つけやすくなります。

渡す項目の分け方までは整理できても、自社の受注管理と販売管理が実際にどの項目をやり取りできるかは、使っている製品の組み合わせごとに違います。

いまどの画面からどの画面へ何を転記しているかを一緒に洗い出せば、不足している項目と、連携を入れても残る確認作業の範囲が具体的に見えてきます。無料相談で要件を整理する

受注伝票のヘッダーで定義されている識別項目

ネクストエンジンの受注伝票検索APIで定義されている項目のうち、伝票の単位でどの取引かを特定するために使うものを集めた。

• 伝票番号（receive_order_id）：その受注伝票を一意に指す値

• 顧客コード（receive_order_customer_id）：誰への売上かを指す値

• 受注日（receive_order_date）：注文が成立した時点を示す日付

• 出荷予定日（receive_order_send_plan_date）：納期に関わる見込みの日付

• 受注担当者名（receive_order_pic_name）：後から確認するときの戻り先

商品コード（receive_order_row_goods_id）・受注数量（receive_order_row_quantity）・単価（receive_order_row_unit_price）は、同じ受注でもこのヘッダーには含まれず、受注明細検索という別のエンドポイントで定義されている²。

要点の整理

確認する軸	判断の基準
渡す項目	伝票単位の識別項目と明細単位の金額項目が両方そろっているか
コードの扱い	対応表で相手側のコードへ置き換えてから渡せているか
正の決め方	新規登録をどちらのシステムで採番し、誰が対応表を更新するか
連携方式	渡したい項目を扱えるか、必要な更新の頻度に合うか
ずれの切り分け	金額が出ないのか、取引を特定できないのか、粒度が違うのか

対応表の持ち方や正とするコード体系の決め方は、担当の分かれ方や商品の増え方によって現実的な形が変わります。 自社の受注から請求までの流れに沿って、どの項目をどの順で渡すか、更新を誰が担うかまで詰めて確かめられます。

よくある質問

受注管理システムと販売管理システムを連携する際、既存の基幹システムを入れ替える必要はありますか

必ず入れ替えになるとは限りません。
確認した範囲でも、受注データなどをファイルで受け渡すCSV連携や、専用の連携アプリを介した接続が案内されている製品があります³⁴。
判断の材料になるのは製品の新しさより項目です。
渡したい識別項目と明細項目を、いま使っている受注側が出力でき、販売管理側が受け入れられるかを仕様書で確かめ、足りない項目が出たときに備考欄などで代替できるかを見てから、入れ替えの要否を考える順番になります。

項目の対応表（マスタ変換表）は誰が管理するのが望ましいですか

決まった正解はありませんが、更新のきっかけを持つ側が起点になると回りやすくなります。
商品マスタの対応表なら新商品を登録する担当、顧客マスタの対応表なら取引先を登録する担当です。
重要なのは個人名ではなく、新商品の追加や取引先の統廃合といった出来事ごとに、誰が追記し、誰がもう一方のシステムへ反映するかを順番として決めておくことです。
手元のファイルに閉じず、両方の担当が見られる場所に置いておくと、担当が替わっても形が崩れません。

APIとCSVを併用して連携することは可能ですか

製品の対応によります。
CSVでの受け渡しと、コネクタや業務アプリを介した接続の両方を案内している製品もあります³⁴ので、自社の組み合わせで併用できるかは各製品のドキュメントで確認してください。
併用する場合に決めておきたいのは、同じデータを二つの経路で渡さないことです。
受注データはコネクタ経由、マスタの更新はCSVといった具合に、どのデータをどちらで渡すかを分けておかないと、どちらの値が新しいのか判断できなくなります。

連携後に項目の仕様が変わった場合、どこを確認すればよいですか

確認先は三つに整理できます。
受注側と販売管理側それぞれの連携仕様書やAPIドキュメントの更新内容、間に入っているコネクタやアプリの提供元からの案内、そして自社で持っている対応表です。
桁数や単位の変更は、エラーにならずに値だけがずれることがあるため、変更の案内を受け取ったら、実際の伝票を数件取り込んで受注側の明細と突き合わせるところまでを一連の作業にしておくと、月末になって気づく事態を避けやすくなります。

1. 1　出典：株式会社ネクストエンジン「ネクストエンジンAPI 受注伝票検索リファレンス」（2026年）
2. 2　出典：株式会社ネクストエンジン「ネクストエンジンAPI 受注明細検索リファレンス」（2026年）
3. 3　出典：株式会社ネクストエンジン「基幹システム連携」（2026年）
4. 4　出典：株式会社オービック「商蔵奉行クラウド 他システム連携」（2026年）