Web受発注システムの運用ルールの決め方：変更・取消・システム外注文を一本化して安定させる

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

B2B EC-COLUMN

注文は入っているはずなのに確認に追われる：どこで滞っているかを役割別に切り分ける

取引先からの注文はシステムに入っているのに、変更や取消、締め後の依頼は電話やメールで別に届く。
そのたびに画面と受信箱を見比べていませんか。
システムを入れても、例外の受け方が人ごとに違えば確認作業は減りません。
変えられるのは、このばらつきと例外の扱いです。
まず注文の流れを役割別に分けて、滞る場所を特定します。
次に、締め時刻、変更・取消の受付範囲、システム外で届いた依頼の入力ルールを決めます。
経路を一本化するには、取引先との双方の合意が欠かせません。
そのうえで権限・交代・障害時の手順を整え、件数と処理時間を見ながら原因別に直していきます。

受け取る人・確認する人・例外を判断する人に分ける

Web受発注システムの運用を整えようとすると、まず変更や取消のルールを作りたくなります。
しかし、どこで確認待ちが起きているかが分からないままルールを書くと、困っていない段階の決まりごとばかりが増え、肝心の滞りは残ります。
そこで先に、注文が届いてから出荷・請求までの流れを書き出し、各段階に誰が関わっているかを並べます。

段階は、多くの場合「注文を受け付ける」「内容を確かめる」「出荷できるかを判断する」「出荷を指示する」「請求する」といった並びになります。
ただし分け方は業種や取引先の数で変わります。
自社の実際の注文を一件たどりながら書くほうが確実です。
特定の製品の画面に合わせる必要はなく、紙に書いた流れで十分です。

各段階には、担当者の名前ではなく役割を置きます。
役割は大きく三つあります。
システムに届いた注文に気づいて受け付ける「受け取る人」、品目・数量・納期・単価などが自社の条件に合うかを確かめる「確認する人」、決まりで処理できない依頼に可否を出す「例外を判断する人」です。
小さな部署では一人が複数の役割を兼ねることもあります。
それでも役割を分けて書く意味はあります。
兼任していると、どの判断で手が止まっているのかが見えにくくなるからです。

たとえば、取引先から納期を前倒ししてほしいという依頼が届いた場面を考えます。
受け取る人は依頼に気づいても、前倒しできるかどうかは確認する人に聞くしかありません。
確認する人は在庫と出荷予定を見て、通常の範囲を超えると分かれば、誰かの了承を取りに行きます。
このとき例外を判断する人が決まっていないと、確認する人はそのつど上司や営業担当を探すことになります。
回答を待つ間、注文は保留のままです。
「システムに注文は入っているのに確認に追われる」という感覚の多くは、こうした判断者の不在から生まれます。

別経路で届いた件に印を付ける

役割を書き出したら、電話・メール・FAXなどシステムの外で届いた件が、流れのどこで発生しているかに印を付けます。
一定の期間を区切り、別経路で届いた依頼を一件ずつ記録していきます。
記録する項目は、届いた段階・内容・取引先・受けた人です。
表計算ソフトの簡単な表で構いません。

印が集まると、偏りが見えてきます。
新規の注文はシステムで届いているのに、変更だけが電話で来ているのか。
締め時刻を過ぎてからの依頼が多いのか。
特定の取引先がシステムをほとんど使っていないのか。
同じ「別経路の連絡」でも、どの段階で起きているかによって手を入れる先が変わります。

変更が電話に偏っていれば、変更・取消のルールが対象になります。
取引先ごとの偏りが強ければ、取引先との合意と周知の問題です。
受けた人によって処理の仕方が違うなら、入力ルールや権限の決め方を見直します。
この印は、運用が安定したかを後で測るときの比較の起点にもなります。
ルールを変える前の状態として、消さずに残しておきます。

変更・取消・締め後の依頼を、システム上のルールとして固める

通常の変更と取消の扱い

滞りの場所が見えたら、例外として扱われている依頼を性質ごとに分けます。
締め時刻より前に届く通常の変更、システム上で完結させたい取消、締め時刻を過ぎてから届く例外の三つです。
この三つは、判断に必要な情報も、決めるべき人も違います。
まとめて「例外」と呼んでいると、本来は決まりで処理できる変更まで、そのつど誰かの判断を仰ぐことになります。

締め時刻は、変更を受け付ける期限であると同時に、出荷準備に入る合図でもあります。
何時に置くかは、一般的な目安から選ぶよりも、自社で出荷の準備や仕入れの手配が始まる時点から逆算するほうが筋が通ります。
締め時刻より前なら、注文データを直しても後工程に影響が出にくい。
過ぎると、手配の取り消しや作り直しが起こりうる。
締め時刻は、この境目に置きます。
締め時刻を変えると取引先の発注の段取りにも影響するため、決める段階で取引先と話し合っておく必要があります。

通常の変更で大切なのは、変更の内容を注文データそのものに反映させることです。
変更がメールの本文にだけ残り、システム上の注文が元のままになっていると、出荷する人は両方を見比べなければなりません。
取引先が自分で注文を修正できるようにするか、変更依頼を受けて受注側が修正するか。
選べる範囲は、使っているシステムの設定項目によって違います。
どちらを選んでも、最新の内容がシステム上の注文一件に集まっている状態を目指せば、見比べる作業が減ります。

取消も同じ考え方です。
システムで取消の状態を付けられるなら、取消はその操作で完結させ、メールでの連絡は補助にとどめます。
取消の受付設定や状態の項目がどこまであるかは、提供者の仕様によって異なります。
管理画面やマニュアルで自社のシステムに何があるかを確かめてから、ルールの文面を決めます。
機能がないまま「取消はシステムで」と決めても、取引先は結局電話をかけるしかないからです。

締め後の例外を判断する人と記録

人ごとのばらつきが最も出やすいのは、締め後の依頼です。
受けるか断るかが出荷準備の進み具合や取引先との関係で変わるため、受けた人が自分の感覚で答えてしまいやすいからです。
ここは決まりで一律に処理するより、判断する人を一人決め、不在時の代理も決めておくほうが安定します。

判断する人が見る材料も、あらかじめそろえておきます。
出荷準備に入っているか、受けると手配のやり直しや追加の費用が生じるか、その取引先とどんな取り決めがあるか。
この三つが分かれば、多くの場合は可否を出せます。
確認する人がこの三点を調べて判断する人に渡し、判断する人が可否と理由を返す。
こう分担すれば、確認する人が判断を抱え込まずに済みます。

記録として残すのは、次の項目です。
依頼を受けた日時、依頼してきた取引先の担当者、届いた経路、依頼の内容、判断の結果と理由、判断した人、取引先へ回答した日時。
できれば対象の注文データの備考欄や履歴に残します。
システムに置き場所がなければ、注文番号で引ける共有の台帳にまとめます。
記録の目的は二つあります。
後から「なぜあの注文だけ受けたのか」と聞かれたときに答えられること、そして同じ取引先から似た依頼が来たときに前例を参照できることです。

ルールが効いているかは、導入前後で例外の問い合わせ件数や締め後の依頼の件数を比べれば確かめられます。
件数が減らない場合でも、記録がそろっていれば、どこを直すべきかを後から切り分けられます。

▼ 図の内容を文字で読む

• 受け取る人
  • システムに届いた注文に気づいて受け付ける
• 確認する人
  • 品目・数量・納期・単価などが自社の条件に合うかを確かめる
• 例外を判断する人
  • 決まりで処理できない依頼に可否を出す

システム外で届く注文を一本化する：取引先との合意と周知

取引先ごとに現状の経路を分ける

締め時刻や変更・取消のルールは、自社の中で決めただけでは機能しません。
注文を出すのは取引先です。
取引先が電話で連絡してくれば、受注側は電話で受けるしかありません。
中小企業庁の情報サイトで中小企業共通EDIを解説したページは、「EDIは、1社だけが導入しても効果を得ることはできません。」と述べています。
そのうえで、導入には双方の合意と調整が必要で、取引先の状況も考慮して判断すべきだとしています¹。
これはEDI導入についての記述です。
ただ、取引先が使ってくれて初めて受注側の手間が減るという構造は、Web受発注システムの運用ルールにも当てはまります。

そこで、取引先を現在の注文の経路で分けます。
分け方の一例は次のとおりです。

<ul><li>新規の注文はシステムで届き、変更や取消だけが電話・メールで来る取引先</li><li>システムとメール・FAXを、担当者や時期によって使い分けている取引先</li><li>システムをほとんど使わず、電話・FAXで注文してくる取引先</li></ul>

別経路の件に付けた印を取引先ごとに集計すれば、どこに当てはまるかはおおむね判断できます。
分ける理由は、取引先ごとに必要な働きかけが違うからです。
一つ目の取引先には、変更・取消のルールを伝え直せば足りることが多いでしょう。
二つ目には、先方の社内で誰がシステムを使うかを確認する必要があります。
三つ目は、システムで注文できる状態を整えるところから始まります。

合意と周知の進め方

一本化は、すべての取引先に一斉に求めるより、寄せやすい先から順に進めるほうが現実的です。
すでにシステムを使っている取引先は、変更・取消の連絡先を切り替えるだけで済む場合が多く、合意を取りやすい相手です。
ここで運用が回ることを確かめてから、混在している取引先、システムを使っていない取引先へと広げていきます。

合意を取るときは、何を変えてほしいのかを具体的に伝えます。
伝えるのは、注文と変更・取消をどこから出すか、締め時刻は何時か、締め後の依頼は誰あてにどう連絡するか、切り替えはいつからか、の四点です。
口頭で了承をもらうだけでなく、案内文として渡しておきます。
先方の担当者が替わったときにも引き継いでもらえるからです。

取引先の側にも、システムを使えない事情があるものと想定しておきます。
注文を出す担当者が少なく電話のほうが早いと考えている場合もあれば、先方の社内の決まりで紙の注文書が必要な場合もあります。
そうした取引先に無理に切り替えを迫ると、関係そのものを損ねかねません。
合意できない取引先には別経路を残し、受注側の中で確実にシステムへ寄せる仕組み、つまり次の入力ルールで受け止めます。

システム外で届いた依頼の入力ルール

システム外で届いた依頼は、受けた人が決められた項目でシステムに入力するのが基本の形です。
入力を「受けた人」に任せるのは、内容を一番よく知っているのがその人だからです。
伝言を挟むたびに、聞き違いが起こる余地が増えます。
また、入力を後回しにすると、その間はシステム上の注文と実際の依頼がずれたままになります。
受けた時点で入力することを原則にします。

最低限残す項目は、次のとおりです。
取引先名、依頼してきた担当者名、受けた日時、届いた経路、品目・数量・納期、変更や取消であれば元の注文番号、そしてメールやFAXの原本の保管場所。
加えて、システム外で受けた注文だと分かる印を付けておきます。
備考欄に決まった言葉を書く、受付経路の項目を選ぶなど、方法はシステムの設定によって違います。
後で件数を数えるときには、この印が手掛かりになります。

電話で受けた場合は、入力した内容を取引先に読み返して確かめる手順も決めておきます。
聞き違いがそのまま出荷まで進むのを防ぎやすくなります。
なお、メールで受け取った注文書の保存方法など、税務上の扱いはこの記事では判断していません。
国税庁の一次資料で確認するか顧問の税理士に相談し、その結果を保管場所の決め方に反映させてください。

▼ 図の内容を文字で読む

• 変更・取消だけ別経路
  • 変更・取消のルールを伝え直す
• システムとメール・FAXの使い分け
  • 先方の社内で誰がシステムを使うかを確認する
• 電話・FAXで注文
  • システムで注文できる状態を整える

取引先のシステムがまちまちな場合の選択肢：共通EDIという考え方

共通EDIが定めるもの

取引先との合意が進んでも、取引先ごとに注文の受け方が違えば受注側の負担は残ります。
ある取引先は自社のWeb受発注システムから注文し、別の取引先は先方が用意した発注システムに受注側がログインして注文を確認する。
こうした形が重なると、確認する画面がその数だけ増えていきます。
この入口が増える問題に対して、公的に示されている考え方の一つが中小企業共通EDIです。

EDIとは、企業間で注文などの取引データを、決まった形式で電子的にやり取りする仕組みのことです。
中小企業共通EDI標準は、中小企業庁の実証事業を基にNPO法人ITコーディネータ協会が公表しました。
国際的な標準化の枠組みであるUN/CEFACTの共通辞書に沿い、取引先ごとに別々の形式を用意する必要を減らすことを狙っています¹。
標準は、仕様書・メッセージガイドライン・導入ガイドラインで構成されます。
このうち仕様書が、サービスを提供するプロバイダーが扱うべき注文メッセージの項目と、業務アプリケーションが最低限備えるべき項目を定めています¹。

仕組みとしては、受注側と発注側がそれぞれ標準に対応したプロバイダーと契約すると、プロバイダーが必要な情報を変換して受け渡します¹。
発注側は既存の社内システムを使い続けられるとされています¹。
取引先に新しいシステムへの乗り換えを求めずに済むため、合意を取る際のハードルを下げる材料になります。

注意したいのは、同ページで確認できる標準化の対象が注文のメッセージだという点です。
注文の変更や取消をどう扱うかは、同ページには書かれていません。
共通EDIで入口をそろえても、締め時刻や締め後の依頼の判断は、社内ルールと取引先との取り決めで補う必要があります。

双方の対応が要る点

受注側にとっての利点として、同ページは二つを挙げています。
注文書などを取引先ごとの専用システムなしに一元管理できること、そして過去の取引データを検索しやすくなることです¹。
実証に参加した中小企業で作業時間が減ったという記述もあります。
ただしこれは参加企業の条件での結果であり、業種や取引の形が違う会社にそのまま当てはまるものではありません。

共通EDIも、1社だけでは成り立たない点は変わりません。
受注側と発注側の双方が標準に対応したプロバイダーと契約することが前提で¹、取引先の側にも契約と設定の手間がかかります。
また、共通EDIは標準の一つにすぎず、いま使っているWeb受発注システムが対応しているとは限りません。
対応状況は、システムの提供者に確認する必要があります。

すぐに導入しない場合でも、この考え方は運用ルールづくりの参考になります。
取引先の数だけ入口を増やさず、受け取る側でデータの形をそろえ、確認する場所を一つにする。
この方向性は、システム外の注文の一本化と同じ向きです。
同ページでは、導入の相談先として「つなぐITコンソーシアム」が紹介されています。
無料相談、取引先との調整、対応プロバイダーの紹介、導入後の支援を行うとされています¹。
これは掲載時点の紹介なので、現在の受付状況は窓口に問い合わせて確かめてください。

▼ 図の内容を文字で読む

1. 確認する人が三点を調べて渡す
2. 判断する人が可否と理由を返す
3. 判断を記録し取引先へ回答する

担当交代・不在・障害時にも止まらない権限と代替手順を決める

役割ごとの権限と交代時の付け替え

ここまでのルールは、決めた人がいるうちは回ります。
問題は、担当者が異動したり、休んだり、退職したりしたときです。
締め後の判断が一人の頭の中にしかないと、その人がいない日は受けた人がそれぞれの判断で答え、元のばらつきに戻ってしまいます。
人に依存しないためには、役割と権限を結び付け、担当者が替わっても役割が空かない形にしておきます。

受け取る人・確認する人・例外を判断する人の役割ごとに、システム上で何ができればよいかを決めます。
受け取る人は注文を閲覧して受け付けられればよい。
確認する人は内容の修正までできる。
例外を判断する人は締め後の変更や取消を確定できる。
たとえばこのような分け方です。
権限をどこまで細かく分けられるかは、使っているシステムの設定項目で変わります。
細かく分けられない場合でも、誰がどの役割かを一覧にしておけば、操作できる人と判断してよい人のずれに気づけます。

ログイン用のIDは、一人に一つが原則です。
複数人で一つのIDを使い回すと、締め後の依頼の記録に残す「誰が判断したか」が意味を持たなくなるからです。
そのうえで、役割・担当者・代理・IDを並べた一覧を作っておきます。
交代のときは、次の順で進めます。

<ol><li>後任者に役割と権限を付ける</li><li>代理を見直し、締め後の判断者が空かないようにする</li><li>前任者のIDを止める</li><li>取引先へ窓口の変更を知らせる</li></ol>

前任者のIDを止めるのを、後任への付け替えの後に置くのには理由があります。
引き継ぎの途中で、誰も操作できない時間を作らないためです。
反対に、止めるのを忘れると、もう担当していない人のIDで操作できる状態が残ります。
一覧の更新も手順の一部に含めておくと、次の交代のときに現状を探し回らずに済みます。

障害時の暫定経路と復旧後の入力し直し

もう一つ、止まりやすいのがシステム障害のときです。
システムに入れなくなると、取引先はそれぞれ電話やメールで連絡してきます。
このときの受け方を決めていないと、障害中に受けた注文が担当者ごとの手元に散らばり、復旧後に集めきれなくなります。

事前に決めておくのは、取引先へ障害を知らせる人、暫定で注文を受ける窓口、受けたときに残す記録の三つです。
暫定の窓口は、電話番号やメールアドレスを一つに絞っておきます。
受けた件が一か所に集まるからです。
残す記録は、システム外の依頼の入力ルールと同じ項目にしておけば、障害時のためだけに別の様式を覚える必要がありません。
障害中に受けた件には仮の受付番号を振っておくと、復旧後の照合がしやすくなります。

そして、復旧後に必ずシステムへ入力し直すことを手順に含めます。
暫定の経路で受けた注文がメールや台帳に残ったままだと、システムの外にもう一つの受注記録ができ、二重管理に逆戻りします。
入力し直すときは、障害の前後に取引先がシステムからも同じ注文を出していないかを確かめ、重複を取り除きます。
最後に、通常の経路に戻ったことを取引先へ知らせて、暫定の窓口を閉じます。

障害時に使える手段は、取引先との取り決めによっても変わります。
暫定の窓口や連絡方法は、平常時の合意の中で一緒に伝えておきます。
そうしておけば、いざというときに取引先が迷わずに済みます。

▼ 図の内容を文字で読む

1. 後任者に役割と権限を付ける
2. 代理を見直し、締め後の判断者が空かないようにする
3. 前任者のIDを止める
4. 取引先へ窓口の変更を知らせる

安定しているかを件数と処理時間で見て、原因別に直す

数える項目

ルールや手順を整えたら、運用が落ち着いてきたかを数字で確かめます。
感覚で「前より楽になった」と判断すると、特定の担当者だけが負担を抱えている状態を見落としやすいからです。
数える対象は、これまで印や記録を残してきたものです。

<ul><li>例外の件数：通常の変更、取消、締め後の依頼のそれぞれ</li><li>システム外で届いた件数：経路別、取引先別</li><li>確認にかかった時間：注文が届いてから内容が確定するまで</li><li>問い合わせや差し戻しの件数：取引先からの「注文は届いているか」といった確認を含む</li></ul>

これらの数字には、どこまで下がれば十分という一律の基準を当てはめるより、自社のルール変更前の記録と比べて判断するほうが確かです。
見直しの頻度は、最初は短い間隔で始め、数字が落ち着いてきたら間隔を延ばしていけば無理がありません。
新しいルールを始めた直後は取引先も慣れていないため、思わぬつまずきを早めに拾えるからです。

原因をルール・設定・取引先の使い方に切り分ける

数字が減らないときは、原因がどこにあるかを考えます。
ルールが曖昧なのか、システムの設定や画面が使いにくいのか、取引先の使い方や合意が行き届いていないのか。
この三つに分けて考えると、直す先を選びやすくなります。

手掛かりになるのは、例外がどこに偏っているかです。
同じ種類の依頼なのに受けた人によって対応が違うなら、ルールの書き方に解釈の余地が残っています。
担当者を問わず同じ操作の場面でつまずいているなら、システムの設定や画面の分かりにくさを疑います。
特定の取引先に例外やシステム外の注文が集中しているなら、その取引先との合意や案内が足りていない可能性があります。

ただし、偏りは原因の手掛かりにすぎず、それだけで原因が確定するわけではありません。
たとえば特定の取引先から締め後の依頼が多い場合でも、案内が届いていないのか、先方の発注の段取りが自社の締め時刻と合っていないのかで、取るべき対応は変わります。
前者なら案内をし直せば済みます。
後者なら、締め時刻そのものを取引先と話し合う必要があります。
記録に残した依頼の日時や内容を読み返し、先方の担当者にも事情を聞いてから打ち手を選びます。

直した後は、同じ項目を同じ数え方で数え直します。
前後で数え方を変えると、比べた結果が何を示しているのか分からなくなるからです。
書き出す、決める、合意する、数える、直す。
これを繰り返すうちに、例外の扱いは人の判断から、決まりと記録へと移っていきます。

▼ 図の内容を文字で読む

1. 障害を取引先へ知らせる
2. 一つに絞った暫定窓口で受け、仮の受付番号を振って記録する
3. 復旧後にシステムへ入力し直す
4. 重複がないか確かめて取り除く
5. 通常の経路に戻ったことを知らせ、暫定窓口を閉じる

役割の書き出しや例外の分類は自社内でもできます。ただ、取引先ごとの事情を踏まえて締め時刻や合意の順序を決める段階では、外の視点で整理すると判断の材料がそろいやすくなります。

相談では、自社の注文の流れと取引先ごとの経路を一緒に整理し、どこから手を付ければ確認作業を減らしやすいかを確かめられます。無料相談で要件を整理する

自社で決められることと、取引先との合意が要ること

自社内だけで決められる事柄から、取引先との合意や周知が必要な事柄の順に並べた

• 役割分担（受け取る人・確認する人・例外を判断する人）と代理

• 締め後の例外の判断材料と記録項目

• システム外で受けた依頼の入力ルール

• 交代時の権限の付け替え手順

• 締め時刻と変更・取消の受付範囲（取引先との話し合いが要る）

• 注文経路の一本化と切り替えの時期（取引先との合意が要る）

• 障害時の暫定窓口（取引先への周知が要る）

取引先の注文の出し方や連絡先が変わる事柄からは、取引先との合意が必要になる

▼ 図の内容を文字で読む

• ルール
  • 同じ種類の依頼なのに受けた人で対応が違う
• システムの設定や画面
  • 担当者を問わず同じ操作でつまずく
• 取引先の使い方や合意
  • 特定の取引先に例外やシステム外の注文が集中する

要点の整理

軸	基準
滞りの特定	注文の流れを役割別に書き出し、別経路の件に印を付ける
変更・取消	最新の内容を注文データ一件に集める
締め後の依頼	判断する人と代理を決め、判断と理由を記録する
システム外の注文	寄せやすい取引先から合意し、残る経路は受けた人が入力する
交代・障害	役割と権限を一覧にし、障害中に受けた注文は復旧後にシステムへ入力し直す
見直し	変更前の記録と同じ数え方で比べ、偏りから原因を切り分ける

ルールを決めた後も、件数が減らない原因がルール・設定・取引先の使い方のどれにあるかは、記録を読み比べないと見えにくいものです。 相談では、残している記録をもとに偏りを整理し、次に直す対象の候補を確かめられます。

よくある質問

締め後に届いた変更依頼は受けるべきか、断るべきか。判断の分け方は

一律に受ける・断るを決めるより、判断する人を決め、材料をそろえて可否を出す形にします。
見る材料は、出荷準備に入っているか、受けると手配のやり直しや追加の費用が生じるか、その取引先とどんな取り決めがあるか、の三つです。
受けた場合も断った場合も、判断と理由を記録しておくと、次に同じ依頼が来たときに対応がぶれにくくなります。

電話で届いた注文をシステムに入力するとき、最低限残す記録は何か

取引先名、依頼してきた担当者名、受けた日時、届いた経路、品目・数量・納期、変更や取消であれば元の注文番号です。
あわせて、システム外で受けた注文だと分かる印を付けておくと、後で件数を数えられます。
入力した内容を取引先に読み返して確かめる手順も決めておくと、聞き違いに気づきやすくなります。

取引先が電子受発注に対応してくれない場合、どこから合意を取ればよいか

すべての取引先に一斉に求めるより、すでに一部でもシステムを使っている取引先から始めるほうが進めやすくなります。
中小企業共通EDIの公的な解説でも、EDIは1社だけが導入しても効果が出ず、双方の合意と調整が必要とされています¹。
どうしても切り替えられない取引先には別経路を残し、受けた人が決めた項目でシステムに入力するルールで受け止めます。

担当者が退職したとき、受発注システムの権限はどう付け替えるか

後任者に役割と権限を付け、代理を見直したうえで、前任者のIDを止め、取引先へ窓口の変更を知らせる順で進めます。
付け替えの後にIDを止めるのは、誰も操作できない時間を作らないためです。
役割・担当者・代理・IDの一覧を日頃から更新しておくと、交代のたびに現状を探し回らずに済みます。

システム障害で一時的にメールで注文を受けた後、どう戻すか

復旧後、暫定窓口で受けた注文を入力ルールと同じ項目でシステムへ入力し直します。
その際、障害の前後に取引先がシステムからも同じ注文を出していないかを確かめ、重複を取り除きます。
最後に通常の経路に戻ったことを取引先へ知らせ、暫定の窓口を閉じます。
メールで受けた注文書の保存方法など税務上の扱いは、国税庁の一次資料か顧問の税理士に確認してください。

例外が減らないとき、ルール・設定・取引先の使い方のどれが原因かどう見分けるか

例外がどこに偏っているかを見ます。
受けた人によって対応が違えばルール、担当者を問わず同じ操作でつまずくなら設定や画面、特定の取引先に集中するなら合意や案内を疑います。
ただし偏りだけで原因は確定しないため、記録を読み返し、取引先の事情も聞いてから打ち手を選びます。

1. 1　出典：中小企業庁（ミラサポplus）「中小企業共通EDI」