受注管理と販売管理の連携項目は何を渡すか：受注側で決める項目表の作り方

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

B2B EC-COLUMN

受注を販売管理へ手で写すと、どこでやり直しが出るのか

取引先から届いた注文を受注管理システムに登録し、同じ内容を販売管理システムへもう一度入力している。
この運用では、単価の税込・税抜の違い、単位の換算漏れ、変更の反映漏れが、出荷や請求の段階でやり直しとして表れます。
受注管理から販売管理へ渡す項目について、製品をまたいで使える標準の一覧は見当たりません。
そこで、項目を「受注時に確定するもの」「後から更新されるもの」「請求書の法定記載事項に直結するもの」の三つに分け、自社の項目表を作って照合します。
項目表ができれば、CSV・API・一体型のどれが合うかを注文件数や変更頻度から判断でき、導入前の試験連携で確かめられます。

出荷指示・請求書・売上で必要な項目は違う

受注管理システムに登録した注文を見ながら販売管理システムへ入力するとき、担当者が写しているのは一つの注文です。
ところが販売管理の側では、その注文が出荷指示、請求書、売上の計上という別々の用途に使われます。
用途ごとに必要な項目が違うため、ある用途では困らなかった入力が、次の用途に進んだところで初めて足りないと分かります。
写し間違いが出荷より後の工程で見つかることがあるのは、このためです。

出荷指示で倉庫が必要とするのは、何を、どれだけ、いつ、どこへ届けるかです。
商品、数量と単位、納期、納品先がそろえば、ピッキングと出荷の作業は進められます。
単価や税率の区分は、出荷作業そのものには使われません。
そのため、単価を写し間違えていても出荷は滞りなく終わり、誤りはそのまま請求の工程へ持ち越されます。

請求書では事情が変わります。
適格請求書には、交付先の名称、売手の名称と登録番号、取引年月日、取引内容（軽減税率の対象品目である旨を含む）、税率ごとに区分した対価の総額と適用税率、税率ごとの消費税額等を記載することになっています¹。
これは適格請求書発行事業者が交付する請求書の要件で、簡易インボイスには別の要件があります。
出荷や在庫の項目について定めたものでもありません。
それでも、受注した明細が最終的に請求書になる以上、請求書に載る情報の多くは受注の時点で決まっています。
品目ごとの税率区分や、単価が税込か税抜かが受注時に曖昧なままだと、出荷までは進んでも請求書を作る段階で止まります。

売上の計上では、どの時点の、どの金額を売上とするかが問題になります。
受注時の金額、実際に出荷した分の金額、値引きや返品を反映した後の金額は、同じ注文でも一致しないことがあります。
どの金額を確定額とするかは自社の会計の考え方で決まるため、一般論として一つに決めることはできません。
連携の設計で押さえておきたいのは、「確定した金額」という項目をどちらのシステムが持ち、もう一方がそれをどう受け取るかを決めておく必要がある、という点です。

転記の場面で起きる不整合の例（仮例）

ここからは説明のための仮の流れで、実際の事例ではありません。
業務用の食品と包材を卸している会社で、得意先から届いた注文を受注担当者が受注管理に登録し、同じ内容を販売管理へ入力しているとします。
注文には食品と包材が混ざっていて、食品は軽減税率、包材は標準税率の対象です。

受注管理では商品名で登録していた明細を、販売管理では商品コードで探して入力します。
似た名前で規格の違う商品が二つあり、別の方を選んでしまうと、出荷指示の段階で倉庫から問い合わせが来るか、気付かれないまま違う商品が出荷されます。

数量でもずれが起きます。
得意先はケースで注文し、受注管理にもケースで登録したのに、販売管理の単位がバラになっていれば、写す人が入数を掛けて換算しなければなりません。
換算を忘れると、出荷数量も請求金額も変わります。

単価は、得意先との取り決めが税抜なのか税込なのかで写し方が変わります。
受注管理に税込で入っている単価を、税抜を前提にした販売管理の欄へそのまま入れると、請求書の対価の額と消費税額が両方ずれます。
食品と包材が混ざる注文では、税率区分を品目ごとに正しく付けないと、税率ごとの合計そのものが成り立ちません。

受注の後で得意先から「包材は来週に回してほしい」と連絡が来た場合も同じです。
受注管理だけ直して販売管理を直さなければ、販売管理は元の納期のまま出荷指示を出し、請求書にも包材が載ります。

商品の取り違えはコードの対応づけ、単位や単価のずれは変換のルール、変更の反映漏れは更新の向きとタイミングの問題です。
どれも、「どの項目を、どちらのシステムが、どの形で持つか」が決まっていないところから起きています。
連携の仕組みを入れても、この決めごとがないままだと、人が気付いて直していたずれが、気付かれないまま流れるようになります。

連携する項目の分け方：受注時に決まる項目、後から更新される項目、請求の法定項目

受注時に確定する項目

受注管理から販売管理へ渡す項目について、公的機関や製品の提供元が共通の標準として示した一覧は、確かめられる資料の中に見当たりません。
製品ごとに項目の名前も持ち方も違うため、他社の一覧を借りるより、自社の受注で実際に扱っている項目を洗い出して表にする方が、抜けや食い違いに気付きやすくなります。
その表を作るとき、項目を性質で三つに分けておくと、どちらのシステムに持たせるかを決めやすくなります。
受注時に確定する項目、出荷・請求・入金で更新される項目、請求書の法定記載事項に直結する項目の三つです。
この分け方は製品の仕様ではなく、編集部が項目表を整理するために提案する考え方です。

受注時に確定する項目は、得意先、商品、数量と単位、単価、納期、納品先、支払条件などです。
受注担当者が注文を受けた時点で値が決まり、受注管理で入力されます。
値が生まれる場所が受注側なので、持ち主を受注側に置き、販売管理へは受注の登録や確定のたびに渡す、という形が考えやすい群です。

判断が分かれるのは、販売管理側にもマスタを持たせている項目です。
得意先と商品を販売管理のマスタで管理している場合、受注側は名称で渡すのか、コードで渡すのかを決める必要があります。
名称は表記の揺れや改称で一致しなくなるため、受注側でコードを引き当ててから渡す方が、販売管理で取り違えが起きにくくなります。
先の仮例で起きた規格違いの商品の選び間違いは、ここで防ぐ話です。

販売管理に対応する欄がない項目もあります。
得意先が付けた発注番号、指定の納品書の様式、配送時の注意事項などです。
これらを無理に販売管理の備考欄へ押し込むと、検索も集計もできない情報になりがちです。
受注側に残し、販売管理には受注番号を渡して、必要なときに受注側へたどれるようにしておくと、どちらにも欠けのない状態を保てます。

出荷・請求・入金で更新される項目

二つ目の群は、受注の状態（ステータス）、出荷日、出荷済みの数量、請求済みかどうか、入金の状況、確定した売上金額などです。
受注の時点では空か仮の値で、後工程の作業が終わるたびに書き換わります。

受注側のデータにこうした状態を持たせている製品もあります。
たとえば、EC向けのカート製品であるらくうるカートの受注明細CSVには、ステータス、出荷日、売上確定額、税率区分といった項目が並んでいます³。
これはEC向け製品の受注データの例で、企業間取引の受注管理や販売管理に共通する標準項目ではありません。
ただ、受注のデータが状態や確定額まで持ちうること、そしてその場合に販売管理の持つ値と二重になりうることは、この例からも読み取れます。

更新される項目は、その出来事が起きるシステムを持ち主にすると、食い違いが起きにくくなります。
出荷を販売管理で記録しているなら出荷日の持ち主は販売管理で、受注側はそれを受け取って表示するだけにします。
同じ項目を両方のシステムで書き換えられるようにすると、どちらの値が正しいのかを人が判断する場面が生まれ、転記をなくしたつもりでも照合の手間が残ります。

この群を整理すると、連携の向きも見えてきます。
仮例の受注担当者は、得意先から「もう出荷されたか」と聞かれたとき、受注管理の画面で答えたいはずです。
その画面に出荷日が戻ってこなければ、販売管理を開いて調べ直すことになります。
受注側から販売管理へ渡すだけでよいのか、販売管理から受注側へ戻す向きも要るのかは、この群の項目ごとに決まります。

請求書の法定記載事項に直結する項目

三つ目の群は、前の二つと重なります。
得意先の名称や商品、単価は受注時に確定する項目でもあり、取引年月日は出荷や納品の記録から決まることもあります。
それでも別に印を付けておくのは、この群の項目が一つでも欠けたり誤ったりすると、適格請求書として必要な記載がそろわなくなるからです¹。

記載事項を受注データの項目へ対応させると、次のように整理できます。

• 交付先の名称：得意先マスタの請求先名
• 売手の名称と登録番号：注文ごとではなく、販売管理側の自社設定に持たせることが考えられる
• 取引年月日：どの日付を記載するかを自社の取引条件と国税庁の案内に沿って決め、その日付の項目を対応させる
• 取引内容と軽減税率の対象である旨：商品名と、品目ごとの税率区分
• 税率ごとに区分した対価の総額と適用税率：明細の金額と税率区分から集計する
• 税率ごとの消費税額等：計算をどちらのシステムで行うかを決める

この対応づけで分かるのは、請求書に必要な情報の出どころが、受注側と販売管理側に散らばっていることです。
受注側で正しく持っていても、販売管理側に届かなければ請求書には載りません。
項目表に「請求書を作る時点で販売管理側にそろっているか」を確かめる欄を設けておくと、請求の段階で止まる原因を、連携を作る前に見つけやすくなります。

単価・税・単位・コードの対応づけで、ずれが出やすい箇所

コード体系と単位

項目表で群と持ち主を決めても、同じ名前の項目が両方のシステムで同じ意味を持つとは限りません。
ずれが出やすいのは、コード、単位、単価、税率区分、端数処理の位置です。

受注管理と販売管理で得意先コードや商品コードの体系が違う場合、両者を結び付ける対応表が要ります。
問題になりやすいのは、対応表を作ることより、その後の保守です。
新しい商品を販売管理に登録したのに受注側の対応表へ追加し忘れると、その商品を含む注文だけが連携で止まるか、似たコードの別商品へ結び付きます。
対応表を誰がいつ更新するかまで項目表の備考に書いておくと、連携が止まったときに原因を探す範囲が狭まります。

単位も同じ構図です。
仮例の会社のように得意先がケースで注文し、販売管理がバラで在庫を持つ場合、どこかで入数を掛ける換算が必要になります。
換算を受注側で行って販売管理へバラで渡すのか、ケースのまま渡して販売管理で換算するのかで、入数の情報を持つべき場所が変わります。
どちらでも成り立ちますが、両方で換算すると数量が二重に掛かり、どちらでもしないと単位違いのまま渡ります。
項目表には、数量の行に単位と換算する場所を一緒に書いておきます。

単価と税率区分

単価は、得意先との取り決めが税抜か税込かで意味が変わります。
受注管理では得意先の注文書どおり税込で入力し、販売管理は税抜単価を前提にしている、という組み合わせを考えてみます。
手で写していれば、入力する人が金額の違和感に気付いて直せることもあります。
連携で自動的に渡すと、その気付きの機会がなくなり、税込の値が税抜の欄に入ったまま請求書まで進みます。
項目表の単価の行には、名前だけでなく「税込か税抜か」を必ず書いておきたいところです。

税率区分は、請求書の記載と直接つながります。
請求書には税率ごとの対価の総額と適用税率、税率ごとの消費税額等を記載するため¹、明細ごとにどの税率の対象かが分かっていなければ集計できません。
受注側のデータに税率区分を持たせる製品もあり、先のらくうるカートの受注明細CSVには、税率区分の項目に加えて標準税率・軽減税率別の合計の項目があります³。
受注側で税率区分を持てる場合、明細ごとに区分を付けて販売管理へ渡すのか、販売管理の商品マスタから区分を引くのかを決めることになります。

両方のシステムに税率区分を持たせる場合は、どちらを正とするかを決めておきます。
商品マスタの区分を見直したとき、片方だけが直っていると、受注確認の段階と請求書の段階で税率が違って見えます。
一方を正とし、もう一方はそれを参照するだけにしておけば、直す場所が一つで済みます。
仮例の食品と包材が混ざる注文は、この取り決めが機能しているかを確かめる明細として、後の試験連携で通しておきたい注文です。

端数処理の位置

消費税額の計算で生じる端数を、明細ごとに処理するのか、請求書の単位でまとめて処理するのかで、税額がわずかに変わることがあります。
適格請求書での端数処理には国税庁の定めがあり、具体的なルールは国税庁の最新の案内で確かめる必要があります。

連携の設計で決めるのは、その計算をどこで行うかです。
受注側で税額を計算して渡し、販売管理側でも同じ注文の税額を計算し直すと、端数を処理する位置が違えば両者の税額が合わなくなります。
得意先へ税額入りの受注確認書を送っているなら、請求書の税額との食い違いが問い合わせのきっかけになります。
税額を計算するシステムを一つに決め、もう一方は受け取った値を使う、という形にすると、この食い違いは起きにくくなります。

製品の仕様書で端数処理の方法がすぐに見つかるとは限りません。
らくうるカートの受注明細CSVのページでも、消費税の計算方法や小数点以下の処理を示す項目は確認できませんでした³。
項目の一覧に載っていない設定は、システムの設定画面や提供元への問い合わせで確かめるか、税額に端数が出る注文を試験連携で通して、両方の税額を見比べることで確かめられます。

分納・変更・キャンセルなど、受注後の変更はどの項目で連携するか

取得だけの連携と、更新まで含む連携

ここまでの項目表は、注文が受注時のまま変わらない前提でも作れます。
実際の受注では、数量の変更、納期の変更、分納、キャンセルが後から入ります。
受注後の変更を販売管理へ伝えられるかどうかは、連携が受注データを取りにいくだけなのか、変更や状態の書き換えまで行えるのかで変わります。

具体例として、EC向けカートのfutureshopが公開している受注検索APIを見てみます。
このAPIは受注情報を取得するためのもので、受注コード、購入者と配送先、商品の名称・価格・数量の一覧、金額、発送状況などを取り出せます²。
一度に取得できる一覧の件数には上限があり、ステータスの変更のような更新は別のAPIで行う仕組みです²。

これはEC向け製品の一例で、企業間取引の受注管理や販売管理の連携がこうなっている、という証拠ではありません。
それでも、同じ「APIで連携できる」という説明の中に、取得だけの機能と更新の機能が別々に用意されている場合があることは分かります。
候補製品の説明に「API連携対応」とあっても、それが受注を取り出す方向だけなのか、変更やキャンセルを書き込む方向まで含むのかは、仕様を読まなければ判断できません。

前の節で決めた持ち主と合わせると、連携の向きは項目ごとに定まります。
受注側から販売管理へは、新規の受注と、その後の変更やキャンセルを渡します。
販売管理から受注側へは、出荷済み、請求済みといった状態を戻します。
候補の製品や方式が片方の向きしか扱えない場合、扱えない向きの変更は人が両方の画面で直す運用として残ります。
どこに手作業が残るのかを、導入前に項目表の上で把握しておけるということです。

分納・変更・キャンセルを項目表の確認行にする

項目表には、項目の行とは別に、受注後の変更ごとの行を加えます。
行ごとに、変更が起きたときにどの項目が変わるか、どちらのシステムからどちらへ渡すか、いつ渡すか、販売管理側で何の処理が要るかを書きます。
分納や返品の扱いは製品ごとに違いうるため、まず自社の業務で実際に起きる変更を書き出すところから始めます。

仮例の「包材だけ来週に回してほしい」という連絡は、分納にあたります。
受注の明細を出荷済みの数量と残りの数量で管理するのか、元の受注を分けて残りを新しい受注にするのかで、販売管理へ渡す項目が変わります。
前者なら、出荷済みの数量を販売管理から受注側へ戻す連携が要ります。
後者なら、枝番などで元の注文とのつながりを残す項目が要り、得意先の発注番号との対応もそこで保つことになります。

キャンセルは、どの段階で起きたかで重さが違います。
出荷前であれば、受注の取消を販売管理へ伝えれば済む場合があります。
請求書を発行した後は、請求や売上の記録を残したまま取り消す処理が販売管理側で必要になり、受注側でデータを消すだけでは両者の記録が食い違います。
受注の状態がどこまで進んだら受注側だけでは取り消せないようにするかを、状態の項目と結び付けて決めておくと、取消の手順が担当者ごとにばらつきにくくなります。

数量や納期の変更は、受注時に確定する群の値が後から変わる場面です。
群の名前は値が最初に決まる時点を表しているだけで、変わらないという意味ではありません。
得意先からの変更連絡を受けるのは受注担当者なので、変更の記録は受注側に残し、販売管理には最新の値を渡すという分担が考えられます。
このとき、変更を受け付ける期限を過ぎた注文、たとえば出荷指示が出た後の注文については、誰が判断して販売管理側を直すのかも行に書いておきます。

連携方式の選び方と、項目表で導入前に検証する手順

CSV・API・一体型を選ぶ基準

連携の方式は、大きくCSV、API、一体型に分けて考えられます。
CSV連携は、受注管理から書き出したファイルを販売管理へ取り込む方法です。
API連携は、システム同士がプログラムを通じて直接データをやり取りする方法です。
一体型は、受注管理と販売管理が一つの製品の中で同じデータを持つ形です。
どれが合うかは、ここまでに作った項目表と、受注の量や変わり方で判断します。

判断が分かれやすいのは、変更の扱いです。
一定の間隔でファイルを取り込む方式では、取り込みと取り込みの間に起きた変更が、次の取り込みまで販売管理に反映されません。
出荷前に数量や納期が何度も変わる業務で、その時間差のあいだに出荷指示が出るなら、変更を人が両方の画面で直す運用が残ります。
反対に、注文件数が少なく変更もまれであれば、定時にCSVを取り込み、変更だけ担当者が確認する運用でも、新規受注を二度入力する作業はなくせます。
どちらが合うかは件数の多さだけでは決まらず、変更が起きてから出荷指示が出るまでの間隔との兼ね合いで決まります。

一体型では、受注と販売が同じデータを持つため、二つのシステムの間で項目を渡す必要そのものがなくなります。
ただし、項目の意味をそろえる作業がなくなるわけではありません。
単価が税込か税抜か、単位をどう扱うか、状態を誰が更新するかといった決めごとは一体型でも残ります。
入れ替えの際には、今の受注管理と販売管理の両方のデータを一つの項目表へ寄せることになるので、項目表を作る作業はむしろ移行の準備として役立ちます。

注文の入口が複数ある受注側では、もう一つ考えることがあります。
中小企業庁のミラサポplusの記事は、発注側企業がそれぞれ独自のシステムを使っているため、受注側企業は発注側ごとに対応するシステムを導入しなければならず、多画面問題が生じることを挙げています⁴。
これは企業間のデータ連携の課題で、社内の受注管理と販売管理の連携そのものではありません。
ただ、取引先ごとの画面や形式から注文を受けているなら、その形の違いを受注管理でそろえてから販売管理へ渡すことになります。
入口が増えるほど、受注管理で吸収するコードや単位の変換が項目表に増えるため、方式を選ぶときには販売管理との連携だけでなく、受注管理へ注文が入ってくる経路も同じ表に並べておくと、見落としが減ります。

項目表を作って少数の注文で試験する手順

方式と製品を決める前に、項目表を使って次の手順で確かめます。

1. 項目を三つの群に分けて一覧にする
2. 候補製品の公式仕様と照合する
3. 少数の実注文で試験連携し、出荷と請求の結果を確かめる

一覧にする段階では、今の受注管理の入力画面、得意先へ送る受注確認書、販売管理の入力画面、請求書を並べて、そこに現れる項目を拾います。
拾った項目それぞれに、群、持ち主、連携の向き、変換のルールを書き、前の節で挙げた受注後の変更の行も加えます。
この段階では製品の項目名が分からなくても構いません。
自社で呼んでいる名前と、その意味（税込か税抜か、どの単位かなど）を書いておけば、次の照合で使えます。

照合の段階では、候補製品の項目一覧、CSVのレイアウト、APIの説明と、項目表の一行ずつを突き合わせます。
見るのは名前の一致ではなく、意味と形式、そして更新できるかどうかです。
futureshopの受注検索APIのように、取得と更新が別の機能になっている例もあるため²、変更やキャンセルの行は特に、どの機能でどちらの向きに扱えるかを確かめます。
仕様で答えが見つからなかった行は、そのまま提供元への質問の一覧になります。

試験連携では、件数を絞った実際の注文を使います。
選ぶのは、手で写していたときにずれが出やすかった明細を含む注文です。
仮例でいえば、食品と包材が混ざる注文、ケースとバラの換算がある注文、得意先別の単価がある注文、分納になった注文、出荷前にキャンセルされた注文、税額に端数が出る注文が候補になります。
連携した結果について、出荷指示の内容、請求書に必要な記載がそろっているか、税率ごとの合計と税額、受注側に戻ってくる状態を、手で処理した場合の結果と見比べます。
一致しなかった項目は項目表へ戻し、持ち主や変換のルールを見直します。

試験で一致しても、項目表の仕事は終わりません。
連携で減るのは、同じ注文を二つの画面へ入力する作業と、その写し間違いを確かめる作業です。
新しい商品や得意先の登録、マスタの見直し、項目の追加のたびに対応表と項目表を更新する作業と、例外的な変更をどう扱うかの判断は残ります。
項目表を導入後も更新し続ける資料として扱うと、連携が止まったときにどの行を見ればよいかがすぐに分かります。

項目の群や持ち主、連携の向きは自社の業務の流れで決まるため、今使っている受注管理と販売管理の画面や帳票と突き合わせないと、どこが未決なのかが見えにくいことがあります。

相談では、作りかけの項目表と実際の注文の明細をもとに、持ち主や連携の向きが決まっていない項目を一緒に洗い出せます。無料相談で要件を整理する

項目表の一行に書く欄

項目表の一行を左から埋めていくときの欄を、記入していく順に並べた。

• 受注側の項目名と意味（税込・税抜、単位などの前提を含める）

• 販売管理側の対応する項目名（候補製品の仕様で確認した名前）

• 群（受注時に確定／後から更新／請求書の法定記載事項に直結）

• 持ち主（値を書き換えてよいシステム）

• 連携の向きと渡す時点

• 変換のルール（コード対応表、単位換算、税額を計算する場所）

• 請求書を作る時点で販売管理側にそろっているか

• 仕様で確認できなかった点（提供元への質問）

受注後の変更を書く行では、項目名の欄に変更の種類を書き、変わる項目を列挙する。

要点の整理

軸	基準
項目の分け方	受注時に確定・後から更新・請求書の法定記載事項に直結の三群で整理する
持ち主	値が生まれる、または出来事が起きるシステムを持ち主にし、一つの項目を両側で書き換えない
税と単価	税込・税抜、税率区分、税額を計算する場所をそれぞれ一つに決める
受注後の変更	変更の種類ごとに、変わる項目・向き・時点を確認行として書く
方式の選択	件数・変更頻度・項目の持ち主・既存の出力機能・注文の入口で判断する
導入前の確認	税率の混在や分納を含む少数の実注文で、出荷と請求の結果を確かめる

候補製品の仕様で答えが見つからない行や、試験連携で結果が一致しなかった項目は、受注側だけでは原因を切り分けにくい場合があります。 相談では、仕様で確認できなかった点を提供元への質問の形に整理し、試験連携に使う注文の選び方を確かめられます。

よくある質問

受注管理と販売管理を一体型にすれば、項目の連携は考えなくてよいですか。

二つのシステムの間で項目を渡す作業はなくなりますが、項目の意味を決める作業は残ります。
単価を税込と税抜のどちらで持つか、単位をどう換算するか、状態を誰が更新するかは一体型でも決める必要があります。
入れ替えの際は、今の受注管理と販売管理のデータを一つの項目表へ寄せることになるため、項目表は移行の準備としても使えます。

販売管理側の項目が受注側より少ない場合、足りない情報はどこで持てばよいですか。

得意先の発注番号や配送時の注意事項のように、請求書や売上の計上に使わない情報は受注側に残し、販売管理には受注番号を渡してたどれるようにする方法があります。
備考欄へまとめて押し込むと、検索や集計に使えなくなりがちです。
ただし、請求書の記載に必要な項目が販売管理側にない場合は、受注側に置いても請求書には載りません。
その項目を販売管理側で持てるかを、候補製品の仕様で確かめる必要があります。

取引先ごとに単価や税の扱いが違う場合、項目表のどこで扱いますか。

取引先ごとに違う単価は、得意先別の単価をどちらのシステムが持つかを、単価の行の持ち主として決めます。
両方に持たせると、改定時に片方だけが直る食い違いが起きます。
税率区分は品目に付く情報として扱い、取引先ごとに違うのは単価や税込・税抜の取り決めの方として分けて書くと整理しやすくなります。
取引先によって同じ商品の税の扱いを変えたい事情がある場合は、取引内容に即した扱いを税理士や国税庁の案内で確かめてから項目表に反映します。

連携を始めた後に項目を追加するとき、既存の注文データへの影響を確かめる方法はありますか。

追加した項目は、すでに登録済みの注文では空のままになります。
連携の処理がその空欄をどう扱うか、たとえばエラーで止まるのか、空のまま販売管理へ渡るのかを確かめることが中心になります。
試験では新しい注文だけでなく、受注済みで未出荷の注文や、出荷済みで未請求の注文のように、途中の状態にある注文も通しておくと、切り替えの時期に起きる食い違いを見つけやすくなります。

CSV連携で文字コードや桁数が合わないとき、何を確認すればよいですか。

書き出す側と取り込む側で、文字コード、区切り文字と囲み文字、改行の形式の指定がそろっているかを見ます。
次に、項目ごとの桁数の上限です。
住所や商品名が取り込む側の上限を超えると、途中で切れたり取り込みが止まったりします。
先頭がゼロのコードが数値として扱われて欠ける、日付や金額の書式が違う、といったずれもこの段階で起きます。
項目表の各行に形式と桁数を書き添えておくと、どの項目が原因かを絞り込めます。

1. 1　出典：国税庁「適格請求書等保存方式（インボイス制度）：適格請求書の記載事項」（2026年閲覧）
2. 2　出典：futureshop「受注検索API オンラインマニュアル」（2026年閲覧）
3. 3　出典：らくうるカート「受注明細CSV レイアウト（マニュアル）」（2026年閲覧）
4. 4　出典：中小企業庁（ミラサポplus）「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）