Web受発注システムと請求業務の連携はどこまで進むか｜ズレの原因と発注・受注別の確認点

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

B2B EC-COLUMN

注文内容と請求金額がずれる場面と、その背景にある構造

注文した数量と届いた請求書の金額が合わない、締め日のたびに注文の控えを見ながら請求書を作り直している——Web受発注システムを入れると、こうした手間はどこまで減るのでしょうか。
注文データをもとに請求金額を確定させる仕組み自体は多くのシステムが備えていますが、入金の消込まで自動でつなぐには、取引銀行が全銀EDIシステムに対応しているかといった決済インフラ側の条件も関わります¹。
しかも、自社が発注する側か受注する側かで、先に確認すべき機能は変わります。
請求金額の確定までと、入金の消込までを分けて考えると、自社の場合にどこまでが一続きになるのかが見えてきます。

ズレは請求書を作る瞬間に生まれているわけではない

たとえば、取引先から12個の注文が入り、担当者が受注の一覧へ転記したとします。
出荷の日に在庫が10個しかなく、先方と相談して10個で出荷し、残りの2個は次回に回しました。
ここまでは現場のやりとりで問題なく収まっています。
問題が出るのは月末です。
請求書を作る担当者の手元にあるのが注文の控えだけなら、12個分の金額で請求書が出ます。
取引先は納品書の10個で確認しているので、金額が違うという連絡が入ります。

この場面でズレが生まれたのは、請求書を作った瞬間ではありません。
出荷の時点で数量が変わったのに、その変更が請求の根拠になるデータへ戻っていなかったところです。
注文・出荷・請求がそれぞれ別の帳票や画面で管理されていると、どれが最新なのかは人の記憶と連絡に委ねられます。
原因を担当者の確認不足として片付けてしまうと、同じことが翌月も起こります。

二重入力の手間も、同じ構造から出てきます。
受注の内容をメールから基幹システムへ入力し、出荷指示のために別の表へ書き写し、請求書を作るときにもう一度会計ソフトへ入れる。
入力する人が工程ごとに違えば、それぞれが自分の画面にある情報を正しいものとして作業します。
どの画面が正なのかを決めていないと、直すべき場所も毎回変わります。

締め処理が遅れる理由も、たどれば同じところにあります。
月末に注文の控え、出荷伝票、納品書の控えを集めて突き合わせてから請求書を作るなら、資料がそろうまで作業は始められません。
取引先からの問い合わせが一件入れば、その確認のために発行がさらに一日遅れます。
請求書の到着が遅れれば相手の支払いサイクルに間に合わず、入金の確認も後ろへずれていきます。
金額のズレ、二重入力、締めの遅れという別々の症状に見えても、行き着く先は同じ分断であることが少なくありません。

受発注のデータと請求・入金のデータは別の流れになっている

もう少し引いて見ると、企業間のやりとりは二つの流れに分かれています。
注文書・注文請書・納品書のように、何をいくつ取引するかを伝える商流の情報と、請求書・支払通知・振込のように、いくらをどう払うかを扱う決済の情報です。
紙やメールでやりとりしているうちは、どちらも同じ担当者が扱うため一続きの仕事に見えます。
しかし電子化は、この二つで別々に進みます。

中小企業庁が紹介している中小企業共通EDIも、現状は受発注データの連携が中心で、全銀EDIシステムと連携して決済まで一気通貫につなぐ構想は実証事業として進められている段階だと位置づけられています²。
企業間のデータ連携を標準化する取り組みそのものは進んでいますが、受発注を電子化すれば請求と入金まで自動的に一体になる、という関係ではないということです。

そう考えると、導入を検討するときに立てるべき問いも変わってきます。
「請求業務は自動化されますか」ではなく、注文のデータはどこまで一つのまま流れ、どの工程で人が別の画面へ移し替えるのか。
この境目が自社のどこに来るかで、減る手間も残る確認も決まります。

Web受発注システムは注文データをどこまで自動で請求につなげるのか

受発注データの連携で自動化される範囲

受発注システムの中では、注文明細に品番・数量・単価が入っています。
出荷や検収の実績をその明細へ書き戻す運用ができていれば、締め日に期間内の明細を集計して請求金額を出す処理は、システムの中で完結します。
先ほどの12個と10個の例でいえば、出荷実績の10個が注文明細に反映された時点で、請求の根拠は自動的に10個分になります。
ここで消えるのは、注文の控えを見ながら金額を作り直す作業と、その転記です。

ただし、何を請求の根拠にするかまでシステムが決めてくれるわけではありません。
注文数で請求するのか、出荷数なのか、取引先の検収数なのか。
取引先との間に「検収が上がった分だけ」という取り決めがあるなら、検収の情報を受け取る手段がなければ金額は確定しません。
この取り決めが曖昧なままシステムを入れると、自動で計算された金額が取引先の認識と合わず、結局は月末に突き合わせる作業が残ります。

請求書としての発行・送付までを含むかどうかも、製品によって差が出るところです。
請求金額を計算できることと、取引先が受け取れる形式の帳票として出力し、送付や保存まで扱えることは別の機能です。
検討しているシステムについては、請求データが画面上に集計される段階までなのか、帳票として出せるのか、会計側へ渡せるのかを分けて見ておくと、導入後に残る作業量の見積もりがぶれません。

入金消込まで自動化するために必要な条件

請求書を出したあとに残るのが入金の消込です。
口座に入った振込を見て、どの請求に対する支払いかを特定し、売掛金を消していく作業になります。
振込の情報として分かるのが振込人名と金額だけだと、複数の請求をまとめて払われたとき、振込手数料が差し引かれていたとき、一部だけ入金されたときに、どの請求へ当てるかを人が判断することになります。
請求側のデータがどれだけ整っていても、この工程は銀行から来る情報の中身に左右されます。

ここを解く仕組みが金融EDIです。
全銀EDIシステムでは、振込の際に支払通知番号や請求書番号といった金融EDI情報を自由かつ大量に添付でき、受け取った企業は入金額がどの取引・どの請求に基づくものかをデータとして把握して、売掛金の自動消込を実現できるとされています¹。
支払う側が「この振込はこの請求に対するものだ」という情報を振込データに載せてくれれば、受け取る側の突合は機械で処理できる形になる、という考え方です。

条件は、この仕組みが全銀EDIシステムに接続した金融機関を経由する振込に限られることです¹。
サービスが始まった2018年12月の時点で接続していたのは321金融機関で、内訳は銀行等91行、信用金庫230庫とされています¹。
自社の口座の銀行だけでなく、支払ってくれる取引先側の銀行と利用しているサービスも関わるため、入金消込の自動化は受発注システムを選べば手に入る機能ではありません。
中小企業共通EDIと全銀EDIシステムをつないで受発注から決済までを一続きにする取り組みも、実証事業として進められている段階にあります²。

検討の順序としては、請求金額の確定までと、入金消込までを分けておくのが現実的です。
前者は受発注システムと会計・請求システムの間の話で、自社の判断と取引先との取り決めで進められます。
後者は取引銀行を巻き込む話になり、相手の銀行の対応状況にも左右されます。
両方を一度に満たそうとすると製品選びの条件が一気に重くなりますが、分けて考えれば、まず前者だけでも締め処理の遅れは短くできます。

発注側か受注側かで、請求まわりに必要な機能は変わる

発注側が確認すべき点

ここまでは、注文から入金までの流れを一本の線として見てきました。
実際に検討を始めると、自社がその線のどちら側に立っているかで、見るべき機能が変わります。
発注する側、つまり支払う側の中心業務は、届いた請求書が自社の注文と納品の記録に合っているかを確かめることです。

仕入先が10社あれば、締め日も請求書の様式も10通りです。
月末に届いた請求書を一枚ずつ開き、自社の注文控えや検収記録と照らし、合わなければ問い合わせる。
この作業を軽くするために発注側が確認するのは、自社が出した注文のデータを、請求書の明細と同じ粒度で後から取り出せるかどうかです。
注文番号や品番の単位で突き合わせられれば、疑問が出たときに人が見る範囲は、金額の合わない明細だけに絞られます。

仕入先が多い発注側では、支払データを作る工程も負担になります。
締め日の異なる請求書を受け取り、支払日ごとにまとめ、振込のデータを作る。
この一連の作業で請求書番号などの識別情報が落ちると、受け取った側は振込金額だけを見て消込をすることになります。
金融EDI情報を振込データに載せるのは支払う側の処理ですから¹、取引先の入金確認まで含めて改善したいなら、自社の支払処理が識別情報を保持したまま振込データまで届くかが論点になります。

受注側が確認すべき点

受注する側、つまり請求する側では、入口のばらつきが課題になりやすいところです。
ある取引先はFAX、別の取引先はメールの添付ファイル、大口の取引先は先方が指定するWebの画面へログインして注文を確認する。
受け取り方が違えば、自社のシステムへ入れる作業も取引先ごとに別々になります。
受発注システムに期待するのは、この入口を自社の一つの画面へ束ねられるかどうかです。

請求まわりで見ると、取引先ごとの条件をデータとして持てるかが分かれ目になります。
取引先別の単価や掛け率、20日締めと末日締めの混在、月に2回請求する取引先。
これらをシステムの設定として持てれば、締め日ごとに条件を思い出しながら請求書を組み立てる必要はなくなります。
逆に、条件の一部しか設定できず残りを手作業で調整するなら、請求書の作成にかかる時間はあまり変わりません。

電子受発注への対応は、発注する側と受注する側で進み方に差が出ています。
中小企業庁の令和3年度取引条件改善状況調査では、受注側企業のほうが対応率は高く出ています³。
この調査は差が生まれた理由まで示していませんが、受注側は取引先から指定された方式に合わせる形で対応が始まることがあり、発注側は自社で課題を立てないと着手しにくい、という読み方はできます。
自社が発注側なら、取引先からの要請を待つのではなく、請求書の照合に毎月どれだけ時間をかけているかを数えるところが出発点になります。

返品・数量訂正・掛け率といった例外は請求データにどう表現されるか

例外を区分するデータ項目の考え方

通常の注文がきれいに流れるようになると、次に残るのが例外の処理です。
10個納品したうち2個が破損していて返品になった、単価の改定が月の途中に入った、年間の取引量に応じて値引きが発生した。
こうした取引を請求のデータ上でどう表すかは、製品を選ぶ段階では見落とされやすい一方、運用が始まると毎月のように出てきます。

考え方の手がかりとして、業界のEDI標準がどう設計されているかが参考になります。
家電製品協会のEDI標準化仕様では、請求・支払データに「01通常出荷」「04返品」「08割戻し（値引）」といった伝票区分と、支払データと照合するための支払マッチ区分の項目が定義されています⁴。
これは家電流通業界向けの仕様の一例であり、あらゆるWeb受発注システムが同じ区分や粒度で例外を扱うわけではありません。

それでも、この設計から読み取れる考え方は自社の確認に使えます。
返品や値引きを、元の請求金額を上書きして見えなくするのではなく、通常の出荷とは別の区分を持つ行として残す。
そうしておけば、請求金額がいくら減ったのかだけでなく、なぜ減ったのかを後からたどれます。
取引先から「この金額は何ですか」と問い合わせが来たときに、区分と元の伝票をさかのぼって答えられるかどうかで、対応にかかる時間は変わります。

数量の訂正は、出荷の前か後かで扱いが分かれます。
出荷前なら注文明細そのものを直せば請求の根拠も直ります。
出荷後に減った分は、返品として別の行を立てるのか、次回の請求で調整するのか、取引先との取り決め次第です。
どちらの運用を取るかを先に決めておかないと、同じ事象が担当者によって違う形でデータに入り、月次の突合が合わなくなります。

掛け率や取引先別単価も、請求金額の根拠になるという意味では同じ系統の話です。
単価を取引先マスタで持つのか、注文の明細ごとに入れるのか。
マスタで持つなら、改定した単価がいつ出された注文から適用されるのかという設定が必要になります。
締め日をまたいで改定が入ったときに、どちらの単価で請求されているかを説明できる状態にしておけば、価格改定のたびに取引先と金額を確かめ直す手間は減ります。

確認のときに気をつけたいのは、データ項目が用意されていることと、その区分どおりに請求書や会計データが出ることは別だという点です。
返品の区分を入力できても、請求書の帳票にはその行が出てこなかったり、会計システムへ渡すデータでは通常の売上と同じ扱いになったりすることがあります。
デモや試用の段階で、自社で実際に起きた返品や値引きを一件そのまま流してみて、請求書と連携データの両方に期待した形で現れるかを見ておくと、運用開始後の手直しを減らせます。

既存の会計・請求システムと接続する前に確認すべきこと

連携方式（CSV・API・業界標準）の確認

受発注システムを入れるときに、会計や請求の仕組みまで同時に入れ替える企業ばかりではありません。
すでに使っている会計システムを残すなら、二つの間をどうつなぐかが最後の論点になります。
つなぎ方は大きく、ファイルを書き出して取り込む形、システム同士が直接やりとりする形、取引先も含めた業界の標準仕様に合わせる形に分けられます。
どれを選ぶかで、月末に人が操作する回数が変わります。

ファイルの受け渡しは、受発注システムから請求データを書き出し、会計システムへ取り込む形です。
書き出しと取り込みが月に一度なら負担は小さく済みますが、締め後に訂正が出るたびに同じ操作が発生します。
システム同士が直接つながる形にできれば、この操作自体がなくなります。
ただし双方が対応している必要があり、接続の設定と検証の工数は最初にまとまって発生します。

取引先と直接データをやりとりする場面では、標準仕様への対応が関わります。
中小企業共通EDIのように、異なる企業間・システム間でのデータ連携を可能にするための標準化された基盤を整備する取り組みも進められています²。
取引先がすでに業界の標準仕様で注文を送ってきているなら、その形式を受け取れるかどうかが、自社側の選択肢を絞る条件になります。

確認の進め方としては、会計・請求システム側の受け入れ条件を先に取り出すのが早道です。
取り込めるファイルの項目、桁数、文字コード、一度に扱える件数。
この一覧を持ったうえで受発注システム側に「この形で出せますか」と尋ねると、できる・できないがその場ではっきりします。
逆の順序で進めると、契約したあとに変換のための作業が残っていたと分かることがあります。

締め日・請求書番号など対応関係の確認

つなぎ方が決まったら、次は両側のデータで同じものを同じものとして扱えるかです。
取引先コード、品番、注文番号、請求書番号。
これらの採番ルールや桁数が二つのシステムで違えば、どちらかに合わせるか、変換表を持つことになります。
変換表は作れば動きますが、取引先が増えるたびに更新する担当が必要になる点は、最初から見込んでおいたほうがいいところです。

請求書番号は、入金の確認まで見通すと特に効いてきます。
金融EDI情報として振込データに載せられるのは、支払通知番号や請求書番号といった識別情報でした¹。
自社が発行する請求書の番号が会計システム側でも同じ形で保持されていなければ、入金と請求を機械で突き合わせる余地がそもそも生まれません。
いまは手作業で消込をしていても、番号の持ち方をそろえておくことは、あとから仕組みを足すときの前提になります。

締め日も確認の対象です。
取引先ごとに締め日が違う、同じ取引先でも商品群によって締めが分かれる、月に複数回請求する。
こうした運用があるなら、受発注システム側で締めのパターンをいくつ持てるのか、締めたあとに訂正が入ったときに当月で直すのか翌月の調整として入れるのかを決められるかを見ます。
締め後の訂正の扱いは会計側の処理にも影響するので、受発注の担当と経理の担当が同じ場で確認しておくと、運用が始まってからの差し戻しが減ります。

ここまでの確認を済ませても、作業がすべてなくなるわけではありません。
減るのは、注文の内容を請求のために書き写す作業と、請求書の金額を一件ずつ検算する作業です。
残るのは、例外として入力された伝票が正しい区分で入っているかの確認、単価を改定した最初の月の照合、接続してしばらくの間、出力されたデータが想定どおりかを目で見る作業です。
どこまでが自動で、どこからが自分たちの確認なのかを導入前に線引きしておけば、月末に慌てる範囲はかなり狭くできます。

請求金額の確定までなら自社の判断と取引先との取り決めで進められ、入金の消込まで含めるなら銀行側の条件が加わります。
この切り分けを先に決めておくと、製品を比べるときの基準がぶれません。

自社の受発注が発注する側と受注する側のどちらの動きで回っていて、請求のどの工程に手作業が残っているかは、注文の受け方から請求書の作り方までを一度書き出さないと見えにくいためです。

現在の注文の受け取り方と請求書の作り方を伺ったうえで、請求金額の確定までで解決できる範囲と、取引先や銀行の対応が必要になる範囲を切り分けてお伝えできます。無料相談で要件を整理する

発注側・受注側の電子受発注対応率（令和3年度取引条件改善状況調査）

2021年までに電子受発注へ対応したと回答した企業の割合を、発注側・受注側という立場別に並べています。

• 発注側企業（全体）：40.9％が2021年までに電子受発注へ対応と回答

• 受注側企業（全体）：48.5％が2021年までに電子受発注へ対応と回答

• 数値は中小企業庁の同調査を引用した民間企業の記事で確認したもので、業種別の内訳や母数は本記事では扱っていない

自社が発注側か受注側かで、請求まわりの出発点と優先して確認する機能が変わるという前提で読む

要点の整理

軸	基準
請求金額の確定	出荷・検収の実績が注文明細へ戻る運用になっているか、何を請求の根拠にするか取引先と決まっているか
入金消込	取引銀行が全銀EDIシステムに接続しているか、請求書番号を受発注側と会計側で同じ形に保てるか
自社の立場	発注側は請求書と自社の注文・検収記録の照合、受注側は注文経路の集約と取引先別の単価・締め日設定
例外処理	返品・値引きが別区分の行として残り、請求書と会計連携データの両方に反映されるか
既存システム連携	会計・請求側の受け入れ項目と桁・文字コード、締め日のパターン数、締め後の訂正の扱い

既存の会計・請求システムとの接続条件や例外処理の扱いは製品ごとに異なり、機能一覧だけでは自社の締め日や返品の運用に耐えるかを判断しにくいためです。 お使いの会計システムの受け入れ条件と、実際に起きている返品や値引きの例をお持ちいただければ、どの転記がなくなり、どの確認が残るのかを具体的に確認できます。

よくある質問

請求書の電子発行だけでも受発注システムを導入する意味はあるか

請求書を電子で出すこと自体は、請求書の発行に特化した仕組みでもできます。
受発注システムを介する利点は、請求の根拠になる注文・出荷のデータが同じ場所に残ることです。
取引先から金額の問い合わせが来たときに、どの注文のどの明細から来た金額かを画面でたどれます。
逆に、注文の受け取り方が紙やメールのままで、入力もこれまでどおり人が行うなら、本文で見たズレの原因そのものは残ります。
自社の困りごとが発行と送付の手間なのか、根拠データの分断なのかで、必要な打ち手は変わります。

銀行と連携した自動消込まで実現したい場合は何を確認すればよいか

全銀EDIシステムによる自動消込は、同システムに接続した金融機関を経由する振込に限られます¹。
サービス開始時点の2018年12月で接続していたのは321金融機関（銀行等91行、信用金庫230庫）とされています¹。
確認する先は、自社の入金口座の金融機関、支払ってくれる取引先側の金融機関と利用しているサービス、そして受け取った金融EDI情報を取り込める会計・販売管理の仕組みがあるかどうかです。
あわせて、自社の請求書番号が会計側でも同じ形で保持されているかを見ておく必要があります。
受発注システムの機能だけで決まる話ではない、という点が出発点になります。

受注側だけ先に電子化を進めても効果はあるか

注文の受け取り方は取引先の都合で決まる部分が大きいため、入口をすべて一本化できるとは限りません。
ただし、受け取ったあとのデータが注文から出荷、請求まで一つのまま流れる形にすることは、取引先の対応状況と関係なく自社の判断で進められます。
FAXやメールで来た注文を一度入力すれば、その先の転記と検算が減るという効果は取引先を待たずに出ます。
実際、電子受発注への対応率は受注側企業のほうが高く出ています³。
取引先ごとに指定された形式が残る前提で、社内の流れをどこまで一続きにできるかを見るのが現実的です。

業界標準のEDIフォーマットに対応していない会計・請求システムとはどう連携すればよいか

間に変換の工程を挟む形が一般的です。
受発注側で標準の形式を受け取り、会計システムが取り込める項目構成へ変換して渡します。
確認したいのは三点で、会計側が受け入れられる項目と桁・文字コード、変換で落ちる情報がないか、そして変換を誰がいつ実行するかです。
特に返品や値引きの区分のような例外の情報が変換で落ちると、会計側では金額の増減だけが残り、理由をたどれなくなります。
企業間・システム間のデータ連携を可能にする標準化の取り組みは進められていますが²、自社の組み合わせで成立するかは製品ごとの個別確認になります。

1. 1　出典：中小企業庁「金融EDIの導入で、経理業務を効率化する！」（2020年）
2. 2　出典：中小企業庁「企業間のデータ連携で、受発注の業務コストを削減する！」（2020年）
3. 3　出典：オリックス・レンテック株式会社「受発注のデジタル化は製造業にどんなメリットをもたらすか」（中小企業庁「令和3年度取引条件改善状況調査」を引用）
4. 4　出典：一般財団法人家電製品協会「EDI標準化仕様 第2章 7.請求・支払データ」