受発注システムと基幹・会計の連携：仕訳を作る場所と計上日の決め方

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

B2B EC-COLUMN

受発注システムと会計の数字がずれる原因は、計上の起点が決まっていないこと

受注の内容を販売管理へ打ち直し、請求書を出したあとに会計へ仕訳を手入力している。
月末に請求額と売上の仕訳を突き合わせると合わず、締めが数日延びてしまう。
受発注システムを基幹・会計とつなげば転記は減らせますが、最初に決めるのは連携方式ではありません。
売上・仕入をどの日に計上するか（出荷・検収など）と、その日付を記録しているのがどのシステムかです。
計上日は法令で一律に決まっておらず、取引に照らして合理的な日を継続して使います¹。
起点が決まれば、渡す項目、仕訳を作る場所、例外取引、エラー時の戻し方、保存要件を順に決められます。

請求書と仕訳が合わない場面

数字が合わない原因をたどると、入力ミスではなく、同じ取引を部署ごとに別の日付で数えていることに行き当たる場合があります。
たとえば、ある取引先から月末に注文を受け、月末日に出荷し、取引先が翌月の初めに検収したとします。
営業は受注日で当月の実績に数え、物流は出荷日で当月の出荷に数えます。
請求書は取引先との締め日の決め方によって当月分にも翌月分にも入り得ますし、経理が請求書を見て仕訳を起こしていれば、仕訳の月は請求書の側に従います。
それぞれが自分の規則に沿って正しく処理しているのに、月の合計がそろわないわけです。

手で転記する運用では、転記する人がどの書類を見て、どの日付を入力するかを、その場で決めています。
担当者が替わったり、急ぎの処理で手元にあった別の書類を見たりすると、同じ種類の取引でも日付の取り方が揺れます。
連携によって転記の手間をなくしても、どの日付を計上日として渡すかが決まっていなければ、この揺れが人の判断からシステムの設定へ移るだけです。
設定に移った揺れは毎月同じ形で再現されるため、かえって原因が見えにくくなることもあります。

分割納品が入ると、ずれ方はさらに複雑になります。
一つの注文を二回に分けて出荷し、二回目が翌月にずれ込んだ場合、受注単位で金額を持つ受発注システムと、出荷単位で記録する在庫側とでは、月ごとの金額の分かれ方そのものが違ってきます。
経理が請求書と照合して差額の理由を探す作業は、こうした日付と単位の食い違いを一件ずつ解きほぐす作業になっています。

受注・出荷・検収・請求・入金のどこを起点にするか

物品の販売、税法の言葉でいう棚卸資産の販売では、収益は引渡しの日の属する事業年度に計上するとされています。
その引渡しの日は、出荷した日や相手方が検収した日など、資産の種類や契約の内容に応じて合理的な日を選び、継続して適用することになっています¹。
つまり計上日は一つに決められているわけではなく、会社が選び、その選び方を続けることが求められます。
なお、これは物品の販売についての定めで、保守や運用代行のような役務の提供には別の考え方があります。

候補を並べると、それぞれの日付の性格の違いが見えてきます。
受注日は、これから引き渡すという約束が成立した日で、まだ物は動いていません。
入金日は代金を受け取った日で、引渡しとは別の出来事です。
出荷日と検収日は、通達が合理的な日の例として挙げている引渡しの記録そのものです¹。
請求書の発行日は、請求という事務の日付であり、引渡しを示す記録そのものではありません。
現在、請求日で売上を計上している会社では、請求のタイミングが出荷や検収とどう対応しているのかを説明できるかどうかを、経理担当者や顧問の税理士と確かめておく必要があります。

起点を選んだら、次はその日付を最初に記録しているのがどのシステムかを特定します。
ここが仕訳の出発点、つまりデータの持ち主になります。
出荷日であれば、出荷指示を出して出荷実績を入力する基幹システムや在庫・物流の仕組みが持ち主になることが多いでしょう。
検収日は取引先側の行為なので、受領の連絡がどこから届くかで持ち主が変わります。
取引先が受発注システム上で受領を確定する運用なら受発注システムが持ち主になり、紙やメールの受領書で届くなら、それを誰かが入力した場所が持ち主になります。
持ち主が決まらないまま連携を組むと、どのシステムの日付を正とするかで毎月同じ議論が起こります。

▼ 図の内容を文字で読む

1. 計上の起点が決まっていない
   • 受注日・出荷日・検収日・請求日のどれを使うか決まっていない
2. 部署ごとに別の日付で数える
   • 営業は受注日で当月の実績に数える
   • 物流は出荷日で当月の出荷に数える
   • 経理は請求書に従って仕訳の月を決める
3. 月の合計がそろわない
   • 月末に出荷し翌月に検収された取引
   • 分割納品の二回目が翌月にずれ込んだ注文

計上日（出荷・検収・請求）の選び方で、連携で渡すデータと仕訳の発生時点が変わる

継続適用が前提になる

計上日の考え方は、法人税と消費税で同じ形をとっています。
消費税で課税の時期となる資産の譲渡等の時期についても、出荷した日、相手方が検収した日などのうち、契約の内容に照らして合理的な日を継続して適用するとされています²。
法人税の引渡しの日の判定も、継続して適用していることが前提です¹。

この共通点から、連携の設計では、会計用と税務用に別々の日付項目を持たせるよりも、計上日として渡す日付を一本にそろえる整理が考えられます。
これは通達の考え方が同じ形をしていることを踏まえた編集部の提案で、個別の取引でどちらの税目でも必ず同じ判定になると保証するものではありません。
直送、委託販売、検収条件付きの契約など、取引の形によって合理的な日は変わり得ます。
自社の取引にどの日を当てるかの最終判断は、経理担当者や税理士と行ってください。

継続して適用するという条件は、システムの作り方にも関わります。
取引ごとに入力担当者が計上日を自由に選べる画面だと、なぜその日にしたのかを後から説明しにくくなります。
取引先や契約区分ごとに計上日の決め方を設定として固定し、変更するときは理由と切替日を記録しておけば、同じ基準を続けていることを示しやすくなります。

基準別に連携で必要な項目

出荷基準を選ぶと、起点は出荷実績になります。
連携で渡すのは受注の明細ではなく出荷の明細で、出荷日、出荷した数量、その数量に対応する金額、元になった受注番号が要ります。
出荷ごとに一件のデータとして渡せば、前の節で触れた分割納品も、一回目と二回目がそれぞれの出荷月に計上される形で自然に扱えます。
反対に、受注単位でしか金額を渡せない作りのままだと、未出荷の残りをどう扱うかを毎月手で決めることになります。

検収基準を選ぶと、検収日が必須の項目になります。
出荷してから検収されるまでの間、その取引は出荷済みで未検収という状態にあり、売上仕訳はまだ起こせません。
月末時点でこの状態の取引が一覧で見えないと、経理は取引先からの検収連絡を待ちながら、届いたものを手で拾っていくことになります。
検収の連絡をデータとして受け取る経路があるかどうかが、検収基準での連携の成否を分けます。

発注側も考え方は似ています。
仕入の仕訳を発注した日のデータから起こすのか、入荷して検品した記録から起こすのかで、受発注システムから渡すべき項目が変わります。
発注データだけでは、実際に何がいつ届いたかは分かりません。
仕入の計上時期は経理の方針として決め、それに合う記録を持つシステムを起点にします。

基準の違いは、仕訳が生まれる時点の違いにもなります。
出荷基準なら出荷実績が入った時点で売上仕訳を起こせるため、日次で連携すれば会計の数字はほぼ出荷と同時に動きます。
検収基準では検収データが届くまで仕訳を起こせないので、連携を日次にしても、月末近くに出荷した分は翌月まで仕訳にならないことがあります。
締め日にどの取引が未計上で残っているかを説明できるよう、未検収の一覧を会計側からも確認できるようにしておくと、締めの日の問い合わせが減ります。

▼ 図の内容を文字で読む

• 出荷基準
  • 出荷日・出荷数量・対応する金額・元の受注番号を出荷単位で渡す
  • 出荷実績が入った時点で売上仕訳を起こせる
• 検収基準
  • 検収日が必須の項目になる
  • 出荷済みで未検収の取引は、検収データが届くまで仕訳にならない
  • 未検収の一覧を会計側からも確認できるようにする
• 発注・仕入側
  • 発注日のデータか、入荷・検品の記録かを経理の方針で決める
  • その記録を持つシステムを起点にする

仕訳をどこで作るか：基幹・受発注・連携基盤・ファイルを同じ軸で比べる

比較の軸（データの持ち主・戻し方・締めの負担・導入条件）

起点の日付とその持ち主が決まると、仕訳をどこで組み立てるかを比べられるようになります。
候補は、基幹システムで作る形、受発注システムで作る形、間に置いた連携基盤で作る形、ファイル（CSVなど）にして会計ソフトへ取り込む形の四つです。
どれが優れているかは一般論では決まらず、自社のデータの置き場所と締めの進め方によって合う形が変わります。

比べる軸は四つに絞れます。
一つ目はデータの持ち主との距離で、起点の記録と同じ場所で仕訳を作るほど、ある仕訳がどの出荷や検収から生まれたのかを追いやすくなります。
二つ目は誤りを直すときの戻し方で、元のデータを直して仕訳を作り直すのか、会計側で直接直すのかが分かれます。
三つ目は締めの負担で、仕訳が都度できるのか、月末にまとめて作るのか、作る前に誰の確認が要るのかが関わります。
四つ目は既存システムの制約で、基幹に仕訳を出力する機能があるか、会計ソフトが外部からのデータをどの形で受け付けるかといった前提条件です。

この比較で判断が最も分かれやすいのは、戻し方の列です。
会計側で仕訳を直接直せば、その場は早く片付きます。
しかし元のデータは誤ったまま残るため、次に同じ取引を再連携したときに修正が上書きされたり、二重に計上されたりするおそれが生じます。
どの形を選ぶ場合でも、修正は元データの側で行い、会計へは訂正の結果を流すという原則を決めておくと、仕訳と元データの食い違いを持ち越さずに済みます。

自社の状況別の選び方

基幹システムで在庫と原価を管理していて、売上だけでなく売上原価まで仕訳にしたい場合は、基幹で作る形が候補になります。
原価の情報は基幹の中にあり、受発注システムへ持ち出して計算し直すより、記録のある場所で仕訳にしたほうが追いやすいためです。
この場合、受発注システムの役割は、受注や検収の情報を基幹へ正しく渡すことに絞られます。

基幹システムがなく、受発注システムと会計ソフトだけで業務を回している場合は、受発注システムから会計へ直接つなぐ形が候補になります。
このとき問題になるのは、受発注システムの側で勘定科目や税区分を会計ソフトに登録されている値で持てるかどうかです。
持てなければ、どこかで値の読み替えが必要になり、その読み替えを誰が保守するかという次の節の論点が前に出てきます。

受発注システムのほかにも、ネット通販、店舗、別の販売管理など売上の入口が複数ある場合は、連携基盤で変換を一箇所にまとめる形が候補になります。
入口ごとに会計への変換を作ると、科目や税区分の変更があるたびに複数箇所を直すことになるためです。
ただし、基盤の変換規則とエラーを見る担当者が社内にいないと、問題の切り分けがどこでも止まってしまいます。

取引件数が限られていて月次の連携で足り、会計ソフトに外部から登録する手段がない場合は、ファイルでの取込が現実的です。
手作業が一部残る代わりに、取り込む前に人が中身を確認できます。
同じファイルを二度取り込む事故を防ぐため、取込済みのファイルを分けて保管するなどの手順を決めておきます。

どの形でも、製品ごとの仕様は各社の公式資料で確かめる必要があります。
確認したいのは、外部から登録できるのが取引単位か仕訳単位か、勘定科目や税区分を何で指定するのか、登録済みのデータを取消・更新できるのか、重複登録を防ぐための識別番号を持たせられるのか、という点です。
これらは比較表の戻し方と締めの負担の列に直接響くため、製品選定の段階で確かめておくと後の設計が楽になります。

税率・値引・返品・分割納品・前受などの例外取引を連携にどう載せるか

端数処理の単位を確認する

例外取引の中でも、一円単位のずれとして現れやすいのが消費税の端数です。
受発注システムが明細の一行ごとに税額を計算して端数を処理し、請求書は一枚の合計を税率ごとにまとめて計算している、という組み合わせを考えてみてください。
この場合、明細ごとの税額を足し上げた値と、請求書に記載された税額が一致しないことがあります。
仕訳を明細データの合計から作ると、請求書と仕訳が一円や数円単位でずれ、その理由を締めの日に探すことになります。

適格請求書でどの単位の端数処理が認められるかは、国税庁のインボイス制度に関するQ&Aで示されているので、自社の請求書の作り方と合わせて確認してください。
適格請求書についての扱いを、納品書など他の書類にそのまま当てはめないことも大切です。
請求書を作るシステムの設定と、受発注システムの税額計算の設定が別々に決められていると、このずれは気付かれないまま続きます。

連携の設計としては、請求書で確定した税率ごとの税額を、明細とは別の項目として持たせ、仕訳の税額はその値を使う形が考えられます。
会計側で明細から税額を計算し直させないことで、請求書と仕訳の税額が同じ値から作られるようになります。

例外を項目として持たせる判断

値引、返品、分割納品、前受といった取引は、件数が少ないからと手入力に戻されがちです。
しかし手入力に戻した分だけ、元の取引とのつながりが切れます。
月末の突合で差額が出たとき、その差額が手で入れた返品なのか、連携の欠落なのかを見分ける手掛かりがなくなるのです。

返品や値引を連携に載せるなら、元になった受注番号や出荷番号、理由の区分、元の取引の税率を引き継げる項目が要ります。
元の取引を参照できれば、どの売上を減らした仕訳なのかを会計側からも追えます。

分割納品は、前の節で触れた出荷単位の連携ができていれば、特別な扱いはあまり要りません。
受注単位でしか連携できない場合は、未出荷の残りをどの時点でどう計上するかを、例外ではなく通常の規則として決めておく必要があります。

前受は、入金が引渡しより先に来る取引です。
前受金をどう計上し、いつ売上に振り替えるかは経理の方針で決まります。
連携の側で解く課題は、その入金がどの受注に対するものかを紐付けられるかどうかです。
受注番号と入金の対応が取れていれば、引渡しの記録が届いた時点で振替の対象を特定できます。

どの例外を項目として持たせるかは、頻度と金額で判断するのが現実的です。
月に数件で金額も小さい例外なら、手入力のまま残し、その代わりに元の取引番号をメモ欄に必ず残すといった決めごとで足りる場合もあります。
毎月一定の件数がある例外や、一件の金額が大きい例外は、項目として持たせて連携に載せたほうが、締めの確認作業が減ります。

マスタ整合とエラー時の戻し方は、運用開始前に決めておく

コード対応表の保守担当

受発注システム、基幹システム、会計ソフトは、それぞれ独自のコードで取引先や品目を管理しています。
受発注システムには注文を受けるための取引先コードがあり、会計ソフトには売掛金を管理するための取引先や補助科目が登録されています。
品目は受発注側では商品コードで持ち、会計側では売上の区分や勘定科目に読み替えます。
税区分も同様で、受発注側の税率の持ち方と会計側の税区分の登録を対応させる必要があります。
連携とは、これらの対応表を介してデータを受け渡すことでもあります。

対応表が崩れる典型は、新しい取引先の登録順です。
営業が受発注システムに新規取引先を登録して初回の注文を受けたものの、会計ソフトにはまだその取引先が登録されていない、という状況を考えてみてください。
連携はエラーで止まるか、製品によっては仮の取引先や「その他」のような区分に入ってしまいます。
前者なら締めの日にエラーの山を片付けることになり、後者なら気付かないまま売掛金の残高が取引先ごとに合わなくなります。

こうした事態を避けるには、対応表の保守を新規登録の手順そのものに組み込むことです。
受発注システムへ取引先を登録する部署と、会計ソフトへ登録する経理との間で、どちらが先に登録し、誰が対応表に追記するかを決めておきます。
税率の改定や勘定科目の見直しのように、対応表をまとめて書き換える場面についても、変更日と担当者を決めておくと、変更前後の取引が混ざる月の確認がしやすくなります。

再送か取消仕訳か

連携のエラーは、大きく二つに分かれます。
一つは、データが会計側に届かなかった、あるいは会計側が受け付けなかったという失敗です。
もう一つは、データは届いて仕訳になったものの、内容が誤っていたという失敗です。
戻し方は、この二つで異なります。

届かなかった場合は、原因を直して再送するのが基本です。
ここで注意したいのは、再送によって同じ取引が二重に計上されないようにすることです。
連携するデータごとに一意の番号を持たせ、同じ番号のデータが二度届いたときに会計側で受け付けない、または受け付けたことを検知できる仕組みがあるかを確認しておきます。
再送時の動作は製品ごとに異なるため、導入前に公式資料や提供元に確かめておきたい点です。

届いたものの内容が誤っていた場合は、会計側で仕訳を書き換えるより、元のデータを訂正し、取消の仕訳と正しい仕訳を連携で流す形のほうが、後から経緯を追いやすくなります。
締めた月の仕訳を書き換えられない設定にしている会社では、訂正をどの月に入れるかという判断も要ります。
これは経理の方針として決めておき、連携の側はその方針どおりに取消と再計上を作れるようにしておきます。

気付き方も事前に決めておきます。
送った側の件数と金額の合計を、会計側で取り込まれた件数と金額の合計と、送信ごとや日次で突き合わせる方法が分かりやすいでしょう。
差額がある一件の取引金額と同じなら、その取引が欠落したか二重になった可能性が考えられますが、それだけで原因は確定しません。
実際の明細を照合して、どの取引がどちらにあり、どちらにないかを確かめてから戻し方を選びます。

▼ 図の内容を文字で読む

1. 連携番号を付けて送信する
2. 会計側の取込結果を受け取る
3. 件数と金額を突き合わせる
4. 差異がある明細を特定する
   • 届いていない取引
   • 二重に取り込まれた取引
   • 届いたが内容が誤っている取引
5. 原因に応じて戻す
   • 届いていなければ原因を直して同じ番号で再送する
   • 内容の誤りは元データを訂正し、取消と再計上を流す

電子取引の保存：受発注システムのデータは連携後も保存要件の対象になる

保存対象のデータ

連携が整い、受発注のデータが仕訳として会計に入ったあとも、受発注システムでやり取りしたデータそのものの保存は別に求められます。
電子帳簿保存法の電子取引にあたる取引情報として、見積依頼書、見積回答書、確定注文書、注文請書、納品書などが挙げられています³。
受発注システム上で取引先と交わした注文や納品の記録は、まさにこの対象になり得るデータです。

仕訳は、取引の結果を会計の言葉に置き換えた記録です。
どの品目をいくつ、いくらで、いつまでに納めるという取引先とのやり取りそのものは、仕訳には含まれていません。
そのため、会計ソフトに仕訳を送ったことをもって、取引データを保存したことにはなりません。

保存場所には、受発注システム自体を保存場所として使う形と、データを別の保存の仕組みへ移す形があります。
どちらの場合も、次に述べる要件を満たした状態で残っているかが問われます。

システム選定時の確認項目

電子取引データの保存では、真実性と可視性の二つを確保することが求められます³。
真実性は、データが改ざんされていないことを示すための措置で、タイムスタンプの付与、訂正や削除の履歴が残る（または訂正や削除ができない）システムでのやり取りや保存、訂正削除の防止に関する事務処理規程の備付けといった方法のいずれかで確保します³。
可視性は、必要なときに目的のデータを探し出せることで、取引年月日・取引金額・取引先で検索できること、日付や金額の範囲を指定して検索できること、二つ以上の項目を組み合わせて検索できることが示されています³。

受発注システムを選ぶ、または見直す場面では、この要件を連携の確認項目と並べて扱うと漏れが減ります。
具体的には、注文の数量や単価を訂正したときに訂正前の版が残るか、取引先が入力したデータも自社の側で日付・金額・取引先から検索できるか、という点です。
受発注システムを入れ替えたり契約を終えたりするときに、それまでのデータを要件を満たす形で移せるかどうかも、選定時に確かめておきたい点です。
連携の設計で決めた元データでの訂正という原則は、ここでも訂正の履歴を残す方向に働きます。

検索の要件などには事業の規模や状況によって扱いが変わる部分もあり得るため、自社がどの要件を満たす必要があるかは、国税庁の電子帳簿保存法一問一答の該当箇所で確かめてください³。

▼ 図の内容を文字で読む

• 会計へ渡す仕訳データ
  • 日付・勘定科目・金額・税区分などの会計の記録
  • 取消と再計上で経緯を残す
• 受発注でやり取りした取引データ
  • 品目・数量・単価・納期など、取引先と交わした注文や納品の内容
  • 仕訳を送っても保存の代わりにはならない
• 取引データの保存で確保する要件
  • 真実性：タイムスタンプ、訂正削除の履歴が残るシステム、事務処理規程のいずれかで確保する
  • 可視性：取引年月日・取引金額・取引先などで検索できる

計上日の決め方や仕訳を作る場所は、受注から請求までの業務の流れと、今使っているシステムの組み合わせによって答えが変わり、社内だけでは前提の洗い出しに時間がかかりがちです。

現在の受注・出荷・検収・請求の流れと、それぞれの日付をどのシステムが記録しているかを一緒に整理し、自社の締め方に合う連携の形を検討する材料を確かめられます。無料相談で要件を整理する

計上の起点ごとに、連携で渡す日付と仕訳を起こせる時点

計上の起点に選ぶ記録の種類で並べ、それぞれで連携に必要な日付と仕訳を起こせる時点を添えた

• 出荷基準：出荷実績が起点。出荷日・出荷数量・対応する金額・元の受注番号を出荷単位で渡し、出荷実績が入った時点で売上仕訳を起こせる

• 検収基準：取引先の検収が起点。検収日と検収数量が必須になり、出荷済みで未検収の取引は検収データが届くまで仕訳にならない

• 請求日で計上している場合：請求書の発行日は引渡しの記録そのものではないため、出荷や検収との対応を説明できるかを経理・税理士と確かめる

• 発注・仕入側：発注日ではなく入荷・検品の記録を起点にするかを経理の方針で決め、その記録を持つシステムから渡す

取引先や契約によって出荷基準と検収基準が混在する場合は、計上日の決め方を取引先・契約区分の設定として持たせ、変更時は理由と切替日を記録します

要点の整理

計上の起点	出荷・検収など合理的な日を選んで継続適用し、その日付を最初に記録するシステムを持ち主とする
税と会計の日付	通達の考え方は共通なので、連携で渡す計上日は一本にそろえる整理が考えられる
仕訳を作る場所	データの持ち主との距離、戻し方、締めの負担、既存システムの制約で比べる
例外取引	頻度と金額で、項目として持たせるか、元取引番号を残して手入力にするかを決める
エラーと訂正	届かなければ同じ番号で再送、誤りは元データを直して取消と再計上を流す
保存	仕訳とは別に、受発注でやり取りした取引データを真実性・可視性の要件に沿って保存する

コード対応表の保守担当やエラー時の戻し方、保存要件の確認は、運用を始めてから決めると締めの負担として表に出やすいため、導入や見直しの前に整理しておく意味があります。 例外取引の扱いや訂正の流し方、保存の確認項目を自社の取引に当てはめ、導入前に決めておくべき事項を確かめられます。

よくある質問

出荷基準から検収基準に変えるとき、連携や仕訳で何を見直しますか？

計上日は合理的な日を継続して適用することが前提なので¹、変更には理由と切替日を決めておく必要があります。
連携の側では、検収日を受け取る項目と、出荷済みで未検収の状態を管理できるかを見直します。
切替月には、旧基準で出荷時に計上済みの取引が検収時に再び計上されたり、逆にどちらの基準でも計上されなかったりしないよう、切替日をまたぐ取引の一覧を作って確認します。
変更の可否や切替の扱いは、経理担当者や税理士と決めてください。

仕訳は基幹と受発注システムのどちらで作るほうが修正しやすいですか？

一般論では決まらず、修正の起点になる元データがどちらにあるかで変わります。
出荷・在庫・原価を基幹で管理しているなら基幹で、受注と検収の記録が受発注システムに集まっているならそちらで作るほうが、元データを直して仕訳を作り直す流れを組みやすくなります。
どちらを選ぶ場合も、会計側で直接直さず、元データの訂正から取消と再計上を流す原則を決めておくことが、修正しやすさを左右します。

納品書と請求書で消費税の端数処理の単位が違う場合、連携側でどう持たせればよいですか？

明細ごとの税額とは別に、請求書で確定した税率ごとの税額を項目として持たせ、仕訳の税額はその値を使う形が考えられます。
会計側で明細から税額を計算し直させないことで、請求書と仕訳の税額が同じ値から作られます。
適格請求書で認められる端数処理の単位は国税庁のインボイス制度に関するQ&Aで確認し、納品書など他の書類の扱いと同一視しないようにしてください。

連携エラーで仕訳が重複・欠落したとき、どう気付き、どう戻せばよいですか？

送信ごとや日次で、送った側と会計側の件数・金額の合計を突き合わせると気付きやすくなります。
差額がある一件の金額と同じでも原因は確定しないため、明細を照合してどの取引が欠落・重複しているかを特定します。
欠落なら原因を直して同じ連携番号で再送し、重複や内容の誤りなら取消の仕訳と正しい仕訳を流して戻します。
再送時に重複を防げるかは製品ごとに異なるので、導入前に確かめておきます。

受発注システムのデータは電子帳簿保存法のどの書類にあたり、会計側に移すだけで足りますか？

電子取引の取引情報として、見積依頼書、見積回答書、確定注文書、注文請書、納品書などが挙げられています³。
会計へ送る仕訳は取引の内容そのものではないため、仕訳を残しただけでは取引データの保存の代わりになりません。
受発注でやり取りしたデータ自体を、真実性と可視性の要件を満たす形で保存する必要があります³。

1. 1　出典：国税庁「法人税基本通達 2-1-2（棚卸資産の引渡しの日の判定）」（2026年閲覧）
2. 2　出典：国税庁「消費税法基本通達 9-1-2（棚卸資産の引渡しの日の判定）」（2026年閲覧）
3. 3　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】／適用要件【基本的事項】」（2026年閲覧）