受発注システムと基幹・会計の連携：渡すデータと取込条件の決め方

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

B2B EC-COLUMN

受発注システムの注文を基幹システム・会計へ転記し続けるとき、まず何を整理するか

受発注システムに入った注文を、基幹システムの受注画面へ打ち直す。
月末には売上や仕入を会計ソフトへもう一度入力し、金額が合っているかを見比べる。
こうした転記を減らそうとするとき、最初に決めるのは連携方式ではありません。
注文・請求・仕訳・入金のどのデータを、どの単位で、どちら向きに渡すかです。
そこが決まれば、CSVの取込仕様、取引先の対応状況、入金消込に使う番号を確かめる順番が見え、手作業を残す箇所を自分たちで絞れます。
修正・取消・締め後の扱いは製品ごとに差が出るため、導入前の質問として持っていきます。

転記・照合が起きている箇所の書き出し方

電話やFAXで注文を受けていた頃は、受けた内容を経理システムへ手で入力する必要がありました。
これが入力ミスや書類紛失の原因になると指摘されています¹。
受発注システムを入れて注文がデータで届くようになっても、その先で基幹システムや会計ソフトへ同じ内容を打ち直しているなら、手入力の場所が一つ後ろへずれただけです。

書き出すときは、システム名ではなく「誰が、どの画面の何を見て、どの画面へ何を入れているか」を一行ずつ記録します。
たとえば、営業事務の担当者が受発注システムの注文一覧を見ながら、基幹システムの受注入力画面へ品番と数量を入れる。
出荷後には、経理担当者が基幹の売上一覧を出力して、会計ソフトへ売上を入力する。
月末には、請求書の控えと銀行の入金明細を突き合わせる。
この例では、同じ注文が三回、形を変えて人の手を通っています。

書き出した作業は、転記と照合に分けておきます。
転記は、ある画面の内容を別の画面へ移す作業で、データ連携で置き換えやすい部分です。
照合は、二つの記録が合っているかを見比べる作業で、連携してもすぐには消えません。
連携後は「自動で入った内容が正しいか」を確かめる照合が、形を変えて残ります。
最初に両者を分けておけば、連携で減らせる作業と残る作業を区別したまま、後の方式選びへ進めます。

渡すデータと向きの整理表

書き出した行を業務の段階ごとに並べ直すと、整理表になります。
列は次のように取ると、後の方式選びや製品への質問にそのまま使えます。

• 業務の段階：注文、出荷、請求、仕入、仕訳、入金
• 渡すデータ：注文明細、売上、請求書、仕訳、入金明細など
• 送り手と受け手：どのシステムから、どのシステムへ渡すか
• 渡す単位：注文一件ごとか、一日分や一か月分の集計か
• 頻度とタイミング：随時、日次、締めのときだけ
• いまの手段：手入力、CSV、紙の帳票
• 修正・取消が出たとき、いま誰が何をしているか

向きの列は、思ったより重要です。
注文は受発注システムから基幹へ流れる一方向に見えます。
けれども、商品や単価、取引先の情報は、基幹で登録したものを受発注側でも使っていることが少なくありません。
同じ情報が両方向に動くのに、どちらの登録を正とするかが決まっていなければ、片方で直した内容がもう片方からの受け渡しで上書きされるおそれがあります。
向きを一行ずつ書くと、どのデータの「正本」をどのシステムに置くかを決める必要がある箇所が浮かびます。

最後の列、修正・取消の扱いは、いまは担当者の判断で処理していて空欄になりがちです。
ただ、連携方式や製品で最も差が出るのはこの部分です。
いまの手作業を書き出しておけば、連携後に誰が代わりに何をするのかを製品に尋ねる材料になります。

この整理表は、判断を進めるための編集部の提案です。
作れば効果が保証されるものではありません。
ただ、手入力の箇所と、渡すデータの単位・向きが一枚に並びます。
そのため、どの行から連携すれば転記が減るのか、どの行は照合として残るのかを、社内の担当者どうしで同じ前提で話せるようになります。

▼ 図の内容を文字で読む

• 受発注システム
  • 注文明細を基幹システムへ渡す
  • 商品・単価・取引先の情報を基幹から受け取る場合がある
  • 登録を正とするシステムを決めておく
• 基幹システム
  • 売上・仕入を会計ソフトへ渡す
  • 請求書を発行する
• 会計ソフト
  • 売上・仕入を仕訳として取り込む
  • 入金を売掛金と照合して消し込む

手入力・CSV・API・連携ツール・個別開発は何で選び分けるか

比較軸の一覧

方式の名前から選び始めると、たいてい迷います。
候補は、手入力、CSV、API（システム同士がプログラムを通じてデータを直接やり取りする窓口）、連携ツール（複数のシステムの間に入り、受け渡しを設定で組む製品）、個別開発です。
どれが安いか、どれが早いかは、製品と既存システムの組み合わせで大きく変わります。
一般的な順位は付けられません。

そこで、方式を比べる代わりに、整理表の各行へ同じ問いを当てます。
軸は下の比較の整理に挙げたとおりで、判断が分かれやすいのは次のような場面です。

データの流れでは、整理表の行ごとに答えが変わります。
月末に会計へ一度渡せば足りる行なら、CSVを出力して取り込む運用で十分なこともあります。
一方、注文が入るたびに基幹の在庫や出荷指示へ反映したい行では、ファイルを出力して取り込むたびに人の操作が挟まります。
その操作自体が新しい手作業になります。

既存システム側の対応条件は、選べる方式の上限を決めます。
受発注システムがAPIを持っていても、会計ソフトがCSV取込しか受け付けないなら、最後の受け渡しはCSVになります。
方式は、つなぐ両端のうち入口の狭い側に合わせて決まる、と考えると整理しやすくなります。

費用は軸として持ちますが、金額の目安を比べるためではありません。
初期の設定、月々の利用、仕様変更のときの改修のどこに費用がかかるのかを、見積もりで分けて出してもらうための軸です。
個別開発や連携ツールでは、つないだ後に受発注側や会計側の仕様が変わったとき、誰が設定を直すのかという保守負担も同じ見積もりの中で確かめます。

CSV取込で確認する仕様

CSVは手軽に見えますが、取り込む側の仕様の細部で結果が変わります。
たとえば、マネーフォワード クラウド会計Plusの仕訳帳形式CSVでは、取引Noの欄が空のときの取り込み方が2020年に変更されています²。
仕訳のまとまりにどう影響するかは、会計への渡し方の節で詳しく見ます。

ここで押さえておきたいのは、列の並びと文字コードが合っていれば同じ結果になる、とは限らないことです。
空欄の行がどう扱われるか、必須の列は何か、番号の列がどんな意味を持つのか。
こうした点は、仕様書を読まないと分かりません。
この例からは、取込仕様が後から変わることもあると分かります。
CSVで連携するなら、仕様の変更をどこで知るかも決めておく必要があります。

共通EDIという考え方

社外の取引先とつなぐ場面では、別の悩みが出ます。
取引先ごとに注文データの形式が違うと、相手の数だけ取込の設定が必要になります。

中小企業共通EDIは、取引先ごとに異なっていたデータ形式を共通化し、導入の手間とコストを減らすことを目指して2018年に策定された仕様です¹。
EDIは、企業間で注文などの取引情報を決まった形式のデータでやり取りする仕組みを指します。
対象は受発注の注文メッセージです。
会計システムへの渡し方までを定めたものとしては説明されていません¹。
共通EDIは、取引先との間の形式差を減らす考え方です。
社内で基幹から会計へどう渡すかは、別に決める必要があります。

自社の受発注・基幹・会計で使える連携方式は、何で決まるか

自社側の条件

自社の中で使える方式を決めるのは、整理表の行ごとの送り手と受け手が、どんな入口と出口を持っているかです。
基幹システムが受注や売上をCSVなどで出力できるか。
会計ソフトがどの形式の取込を受け付け、外部から書き込む窓口を持っているか。
これらは、契約している製品の仕様書や管理画面で確かめる事柄です。

もう一つの条件は、社内で設定と保守を担える人がいるかどうかです。
CSVの受け渡しなら、経理や営業事務の担当者が出力と取込の手順を覚えれば回せる場合があります。
連携ツールや個別開発では、つないだ後に取込が止まったとき、原因を調べて直す人が必要です。
その役割を社内に置くのか、ベンダーに頼むのかで、選べる方式が変わります。

取引先側の条件

社外とのやり取りについては、自社の都合だけでは決まりません。
共通EDIの解説では、2018年時点の説明として、受注側は対応プロバイダーと業務アプリを使えば大きな費用はかからないとされています。
発注側は、対応プロバイダーと契約すれば既存の独自システムを続けられ、プロバイダーが共通辞書に従って注文情報を変換する仕組みだと説明されています¹。
ただし、現在の対応プロバイダーや費用、補助制度は当時から変わっている可能性があります。

同じ解説は、EDIは1社だけでは効果が得られず、取引先と共通認識を持って導入を判断する必要があるとも述べています¹。
この構造から、社外とつなぐ方式は、自社のシステムよりも取引先がどの形式で送れるか、受け取れるかで決まる、と整理できます。

受注側の担当者なら、主要な取引先がどの形式で注文を送れるのかを聞くところから始まります。
発注側なら、仕入先が自社の注文データを受け取れるかを確かめます。

対応しない取引先が残る場合は、二本立てになります。
その取引先とは従来の手段でやり取りを続けます。
社内に入った後は整理表の形に注文をそろえ、基幹へは他の取引先と同じ流れで渡します。
社外の形式がばらばらでも社内の受け渡しを一本にしておけば、取引先の対応が進むたびに、その取引先の分だけ手入力を減らしていけます。

会計へ渡す単位と仕訳のまとまりは、どう決まるか

伝票単位と集計の違い

基幹から会計へ売上や仕入を渡すとき、まず決めるのは単位です。
注文や伝票の一件ごとに仕訳を作る方法と、一日分や一か月分を合計して仕訳にする方法があります。

一件ごとに渡せば、会計の画面から個々の取引までたどれます。
入金を請求単位の売掛金と合わせるときにも、対応する行を見つけやすくなります。
その代わり行数が増え、元の注文が修正されるたびに、対応する仕訳を直す必要が出ます。

集計して渡せば行数は少なく、会計側の入力や確認は軽くなります。
ただ、会計の数字が合わないとき、内訳を調べるには受発注や基幹の明細へ戻ることになります。

どちらが正しいということはありません。
会計で何を見たいのか、たとえば取引先ごとの売掛金の残高を会計ソフトで追うのか、基幹で追うのかによって決まります。
経理の担当者や顧問の税理士と相談して決める事柄です。

取引Noの扱い

単位を決めても、取込の仕様しだいで、仕訳が意図とは違うまとまりで入ることがあります。
仕訳帳形式のCSVでは、借方と貸方が複数行にわたる複合仕訳を、どの行同士で一つにまとめるかを示す列が必要になります。
マネーフォワード クラウド会計Plusでは、その役目を取引Noが担っています。

同社のお知らせによると、取引Noが空欄の場合、以前は取引日が同じ行がすべて一つの複合仕訳として取り込まれていました。
現在は、取引日を元に取引Noを補完して取り込まれます。
そのうえで、意図しない仕訳を避けるため、取引Noには任意の値を入れることが推奨されています²。

以前の動作を当てはめると、同じ日に出荷した別々の注文が、取引Noを空けたまま渡されれば一つの仕訳にまとまっていたことになります。
後から特定の注文だけを取り消したくても、どの行がどの注文なのかを会計側だけでは見分けにくくなります。

ここから、受発注側や基幹側の伝票番号を取引Noに対応させるかどうかを、連携前に決めておくことを提案します。
対応させれば、会計の仕訳から元の注文へ戻れます。
修正や取消の際に、直す行を特定しやすくなります。

ただし、これはこの製品の仕訳帳形式CSVの話で、他の会計ソフトや他の取込形式が同じ動きをするとは限りません。
自社の会計ソフトでは、仕訳のまとまりを決める列がどれで、空欄のときにどう扱われるかを、仕様書とテスト取込で確かめます。

マスタ整合の確認項目

仕訳のまとまりと並んで取込で詰まりやすいのが、マスタ（勘定科目や取引先など、システムに登録しておく基本情報）の食い違いです。
受発注や基幹で使っている取引先名、商品の区分、税の区分が、会計ソフトに登録された勘定科目・税区分・取引先と一致していなければ、そのまま取り込める保証はありません。

確かめておきたいのは、次の点です。

• 受発注・基幹側のどの値を、会計側のどの勘定科目・税区分・取引先に対応させるか
• 対応表をどこに置き、取引先や商品が増えたときに誰が更新するか
• 一致しない値が来たとき、取込がエラーで止まるのか、別の値で入るのか

最後の点は製品ごとの仕様です。
わざと一致しない値を混ぜてテスト取込をすると、本番で同じことが起きたときの見つけ方まで含めて分かります。

▼ 図の内容を文字で読む

• 空欄（変更前）
  • 取引日が同じ行がすべて一つの複合仕訳になる
  • 別々の注文でも一つにまとまり、取り消す行を見分けにくい
• 空欄（変更後）
  • 取引日を元に取引Noが補完されて取り込まれる
• 任意の値を入れる
  • 意図しない仕訳を避けるために推奨されている
  • 伝票番号を対応させれば、仕訳から元の注文へ戻れる

入金の消込は、振込データでどこまで助けられるか

EDI情報に載せられる番号

会計へ売上が入った後に残るのが、入金の消込（入金を、対応する売掛金と結び付けて消していく作業）です。
振込名義と金額だけを手掛かりに、どの請求に対する入金かを判断している場面では、請求書の控えと入金明細を見比べる照合が毎月残ります。

全銀EDIシステム（ZEDI）は、総合振込・入出金明細照会・振込入金明細照会をXML形式で行う仕組みです。
振込データに支払通知番号や請求書番号などの取引情報をEDI情報として添付でき、売掛金の自動消込などに活用できる、とりそな銀行は案内しています³。
一方で、給与振込・賞与振込・口座振替（結果照会）などは対象外とされています³。

注意したいのは、番号を付けるのは支払う側だという点です。
受け取る側がZEDIで明細を受け取れても、取引先が番号を添付して振り込まなければ、名義と金額で照合する状態は変わりません。
利用できるかどうかや手数料も金融機関ごとに異なるため、自社と取引先の両方の取引銀行で確かめる必要があります。

受発注と決済のつながりについては、2018年時点の共通EDIの解説で、全銀EDIシステムとの連携が検討されていると書かれていました。
実現すれば受発注から決済までの情報がつながり、売掛金の自動消込などが可能になるとされています¹。
これは当時の検討事項の記述です。
現在どこまで実現しているかは、この解説からは判断できません。

請求書番号の採番をそろえる

振込に請求書番号が付いてきても、その番号が自社の中でつながっていなければ、消込の手掛かりになりません。
たとえば、基幹で発行する請求書の番号と、会計へ渡す仕訳の取引Noが別々の体系だとします。
振込に載った請求書番号から会計の売掛金へたどるには、二つの番号を結ぶ対応表が必要になります。
その対応表を人が引いている限り、照合の手間は残ります。

会計への取込で仕訳のまとまりが番号で決まることと、振込に請求書番号を載せて消込に使えること。
この二つを合わせると、伝票番号や請求書番号をどこで採番し、会計と銀行の両方へどう渡すかを連携前に決めておく必要がある、と考えられます。
これは編集部の分析です。
他の会計ソフトや銀行でも同じように動くこと、自動消込が必ずうまくいくことまでは言えません。

実務では、請求書番号を採番するシステムを一つに決め、他のシステムはその番号を受け取るだけにする、という形を提案します。
請求書にその番号を目立つように記載し、振込の際にEDI情報として添付してもらえるよう取引先に依頼します。
一回の振込で複数の請求をまとめて支払う取引先もあるため、番号の載せ方は事前に取引先と合意しておきます。

▼ 図の内容を文字で読む

1. 自社で請求書番号を採番
   • 採番するシステムを一つに決める
2. 請求書と仕訳に番号を載せる
   • 請求書に番号を目立つように記載する
   • 会計へ渡す仕訳の番号と対応させる
3. 支払側が振込に番号を添付
   • 振込データにEDI情報として請求書番号を付ける
   • 付け方を事前に取引先と合意する
4. 会計の売掛金を消し込む
   • 入金明細の番号と同じ売掛金を照合する

修正・取消・締め後の変更に備える確認と、始める範囲

製品に確認する質問項目

連携を始めると、いずれ必ず出てくるのが、注文の修正や取消です。
手入力の間は、担当者が基幹と会計の該当箇所をそれぞれ直していました。
連携後は、その作業をシステムが代わるのか、人が別の手順で行うのかを決めなければなりません。
この扱いは製品や方式ごとに差が大きく、一般的な答えはありません。

導入前に、ベンダーや会計ソフトのサポートへ次の点を尋ねておくと、運用の穴を見つけやすくなります。

• 受発注側で注文を修正・取消したとき、基幹や会計へは差分が送られるのか、全件を送り直すのか、手で直すのか
• 同じデータを二度送ったとき、重複を防ぐ仕組みがあるか。
  重複を判定するときに何の番号を見るのか
• 会計の締め後に元の注文が変わったとき、締め済みの期間の仕訳をどう扱うのか
• 取込や送信が失敗した行を、誰がどこで知り、どう再送するのか
• 取込仕様が変わるとき、利用者へどう知らせるのか
• つないだ相手のシステムが更新されたとき、設定の直しを誰が担うのか

回答が「対応できます」だけでは、判断材料になりません。
整理表の修正・取消の列に書いた、いまの手作業を一件例に挙げ、その場合の画面と手順で説明してもらいます。
重複の判定や締め後の扱いに番号が関わるなら、前の節で決めた伝票番号や請求書番号の体系が、その仕組みに合うかも同時に確かめられます。

小さく始める順序と確かめ方

最初からすべての流れをつなぐと、どこでずれが生じたのかを追いにくくなります。
整理表のうち、転記の回数が多く、修正・取消の少ない行から始めるのが一つの考え方です。

進め方の例として、次の順序を提案します。

1. 社外とつなぐ部分は、取引先と形式や番号の扱いについて共通認識を作ってから着手する
2. 社内では、受発注システムから基幹への注文のように、一方向の流れを一つ選ぶ
3. 普段の注文に加えて、修正・取消、同じ日の複数注文、新しい取引先を含めたデータでテスト取込をする
4. しばらくは従来の手入力も並行し、連携の結果と見比べて差を探す
5. 差が出たら、整理表の該当行に戻って単位・番号・マスタの対応を直す
6. 差が出なくなってから、会計への仕訳や入金消込へ範囲を広げる

一つ目の順序は、共通EDIの解説にある、EDIは1社だけでは効果が得られず取引先と共通認識を持って判断する必要がある、という指摘に沿ったものです¹。
社内の連携は自社だけで進められますが、取引先とのやり取りは、相手の準備がそろわないまま始めても手入力が残ります。

並行して手入力を続ける期間は、手間が一時的に増えます。
ただ、連携の結果と見比べる相手がいなければ、取込が正しいかどうかを確かめる手段がありません。
どの行で差が出たかを記録しておけば、それがそのまま、製品に追加で尋ねる質問や、整理表を直す箇所の一覧になります。

▼ 図の内容を文字で読む

1. 一方向の流れを一つ選ぶ
   • 受発注から基幹への注文など、転記が多く修正・取消が少ない行
2. テスト取込をする
   • 修正・取消、同じ日の複数注文、新しい取引先を含める
3. 手入力と並行して見比べる
   • 差が出たら整理表の該当行へ戻り、単位・番号・マスタの対応を直す
4. 差が出なくなるまで続ける
   • どの行で差が出たかを記録しておく
5. 会計の仕訳と入金消込へ広げる
   • 社外とつなぐ部分は取引先と共通認識を作ってから着手する

整理表を作っても、受発注・基幹・会計のどの行から先につなぐかは、取引先の対応状況や会計ソフトの取込仕様と照らし合わせないと決めにくいところです。

相談では、書き出した転記・照合の流れをもとに、最初に連携する範囲と、製品やベンダーへ持っていく質問の優先順位を一緒に整理できます。無料相談で要件を整理する

連携方式を比べるときの軸

整理表の各行に当てる問いとして、連携方式を選ぶときに確かめる観点を並べた。

• データの流れ：向き・単位・頻度。月末の片方向の受け渡しか、随時の双方向か

• 修正・取消時の扱い：差分で送るか、送り直すか、手で直すか

• 保守負担：仕様変更や取引先の追加のとき、誰が設定を直すか

• 費用：初期の設定・月々の利用・改修のどこに費用がかかるか

• 既存システム側の対応条件：基幹や会計が受け付ける入口（CSV取込、外部から書き込む窓口など）

随時の反映や修正の自動反映が必要な行が増えたら、ファイルの受け渡しから、システム同士を直接つなぐ方式の検討へ移る。

要点の整理

整理の出発点	誰がどの画面から何を移しているかを、転記と照合に分けて書き出す
方式の選び方	データの流れ・修正取消・保守負担・費用の内訳・既存システムの入口で比べる
取引先との連携	取引先の対応と共通認識が前提。非対応の取引先分は社内で形をそろえる
会計への取込	仕訳のまとまりを決める列と空欄時の扱い、マスタの対応を仕様書とテストで確かめる
入金消込	請求書番号の採番元を一つに決め、振込に載せてもらう
導入前の確認	修正・取消・重複・締め後の扱いを、実例を示して手順で答えてもらう

修正・取消・締め後の扱いは製品ごとに差があり、各社の回答を比べるには、自社の業務の流れに当てはめて読む必要があります。 相談では、受け取った回答を自社の整理表に当てはめ、連携後も手作業が残る箇所と、まだ確認が足りない点を洗い出せます。

よくある質問

会計ソフトにCSVで仕訳を取り込むとき、受発注側の伝票番号はどう扱えばよいですか。

仕訳のまとまりを決める列に、受発注側や基幹側の伝票番号を対応させるかどうかを先に決めます。
マネーフォワード クラウド会計Plusの仕訳帳形式CSVでは、その役目を取引Noが担っています。
空欄の場合は取引日を元に補完して取り込まれ、意図しない仕訳を避けるため任意の値を入れることが推奨されています²。
伝票番号を入れておけば、会計の仕訳から元の注文へたどれます。
他の会計ソフトでは列の名前や空欄時の動きが違う場合があるため、仕様書とテスト取込で確かめます。

取引先が受発注システムや共通EDIに対応していない場合、連携はどう進めますか。

社外とのデータ連携は、取引先が対応して初めて効果が出ます¹。
対応しない取引先とは従来の手段でやり取りを続け、社内に入った後の注文を同じ形にそろえて基幹へ渡す、という二本立てにすると、社内の受け渡しは一本にできます。
2018年時点の解説では、発注側は対応プロバイダーと契約すれば既存の独自システムを続けられると説明されていました¹。
現在の対応状況は、プロバイダーの案内で確かめます。

請求書番号を振込データに付けて入金消込につなげるには、何を先にそろえておけばよいですか。

まず、請求書番号を採番するシステムを一つに決め、その番号を請求書と会計の仕訳の両方で使えるようにします。
そのうえで、取引先に、振込の際にEDI情報として請求書番号を添付してもらえるよう依頼します。
ZEDIでは振込データに請求書番号などを添付でき、売掛金の自動消込などに活用できると案内されています。
ただし、給与振込・賞与振込・口座振替（結果照会）などは対象外です³。
利用できるかどうかや手数料は金融機関ごとに異なるため、自社と取引先の両方の取引銀行で確かめます。

修正・取消が出たときに備えて、連携ベンダーや会計ソフトに何を質問すべきですか。

修正・取消を差分で送るのか送り直すのか、重複をどの番号で防ぐのか、締め後の変更をどう扱うのか、失敗した行を誰がどう再送するのか、を尋ねます。
回答は「対応できます」で終わらせず、自社でいま起きている修正の一例を示して、その場合の画面と手順で説明してもらうと、運用に残る作業が見えます。

最初の連携は、注文データだけにするか、会計の仕訳まで含めるか、どちらがよいですか。

整理表で、転記の回数が多く修正の少ない行から始めるのが一つの考え方です。
受発注システムから基幹への注文は一方向の流れで、照合もしやすいため、最初の範囲にしやすい行です。
月末の会計入力の負担が最も大きい場合は、会計から始める選択もあります。
その場合は、渡す単位と仕訳のまとまりを決める番号、マスタの対応を先に決めてから着手します。

1. 1　出典：中小企業庁（ミラサポplus）「中小企業共通EDI（受発注のデータ連携）の解説」（2018年）
2. 2　出典：株式会社マネーフォワード「マネーフォワード クラウド会計Plus お知らせ（仕訳帳形式CSVインポートの取引No補完）」（2020年）
3. 3　出典：株式会社りそな銀行「全銀EDIシステム（ZEDI）の案内」