受発注システムは取適法の発注書面要件を満たすか｜記載事項・電子交付・書面請求への対応を確認する

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

B2B EC-COLUMN

受発注システムのデータは発注書面の代わりになるのか

受発注システムから注文データを送っているのに、取引先から「発注書はいただけますか」と聞かれて手が止まる。
あるいは導入の検討中に、法務から取適法の発注書面はどう扱うのかと差し戻される。
どちらの場面でも動かせるのは、システムが何を出力し、何を保存し、紙を求められたときに誰がどう動くかという運用の側です。
現行の取適法は、発注内容の明示を書面または電磁的方法で行うと並べて規定しているため、システム上のデータであっても法定の記載事項を満たしていれば明示の義務は果たせます²。
つまり争点は媒体ではなく、項目の欠け、コード表示の扱い、書面交付を求められたときの体制、記録の保存期間という運用側の条件に移ります。

「システムを入れたから書面は不要」がどこで崩れるか

受発注システムを導入すると、注文は画面で作られ、取引先のポータルかメールに届き、そのまま履歴として残ります。
紙を印刷して封入し、郵送するという一連の作業が消えるので、発注書という書類そのものが要らなくなったように感じます。
ただ、取適法が発注者に求めているのは、紙を渡すという行為ではなく、発注の内容を定められた項目で相手に明示することです。

運用基準は、委託事業者が中小受託事業者に製造委託等をした場合、直ちに明示規則で定める事項を書面又は電磁的方法により明示しなければならない、と定めています²。
書面と電磁的方法が並んで書かれているので、システムのデータで送ったこと自体が問題になるわけではありません。
ここは最初に押さえてよい点です。

裏を返すと、システムを入れても義務の中身は一つも減っていません。
減ったのは媒体と手間であって、何を明示するか、いつ明示するか、相手が別の形を求めたときにどう応じるかは、そのまま残ります。
たとえば「直ちに」という時点の指定も残ります。
電話やチャットで先に作業を始めてもらい、システムへの発注登録は稟議が下りた数日後、という運用は、媒体の議論ではなく時点の議論でつまずきます。

「3条書面」と「第4条の明示」という二つの呼び名

社内の古い手順書やベンダーの資料を開くと、発注書面が「3条書面」と書かれていることがあります。
これは旧下請法で第3条に置かれていた書面の通称で、現行の取適法の運用基準では第4条の明示として書かれています²。
指している中身は同じ、発注内容の明示です。

この呼び名の違いは、要件を調べるときに地味に効いてきます。
条文番号を手がかりに検索すると、旧下請法当時の規則のページと現行のページが混ざって表示され、どちらを基準に自社の様式を直せばよいのか迷う原因になります。
以下では現行の運用基準の表記に合わせ、発注書面のことを第4条の明示として扱い、旧規則を参照する場面ではその旨を添えて説明します。

発注書面に何を記載すべきか。対象となる取引の範囲は

記載すべき11項目

公正取引委員会が示す委託事業者の義務では、発注書面に必要な項目として、委託事業者及び中小受託事業者の名称、製造委託等をした日、給付の内容、給付を受領する期日と場所、検査を完了する期日、代金の額、支払期日、代金の支払方法など、11項目が挙げられています¹。
自社の発注画面を思い浮かべながら読むと、品名、数量、単価、納期、納入先あたりまでは、たいていのシステムで最初から入っています。

抜けやすいのは、その次の層です。
検査を完了する期日は、受領してから何日以内に検査を終えるかという期日で、納期とは別の項目です。
納品日だけを持っていて検査完了日の欄がないシステムでは、そもそも入れる場所がありません。
代金の支払方法も同じで、振込なのか、手形なのか、電子記録債権なのかまで書き分ける必要があります。
支払条件が取引先マスタ側にしかなく、発注データには出力されない作りだと、受け取った側の画面には支払方法が表示されないことになります。

当事者の名称も見落としが起きます。
社内の略称や事業所名だけが入った発注データは、業務上は通っても、明示事項としての名称を満たしているかは別の話になります。
ここは項目が「ある」かどうかではなく、出力された内容が当事者を特定できる書き方になっているかで見ます。

支払期日の欄には、別の規制がぶら下がっている

支払期日は明示事項の一つですが、この欄に入る日付そのものにも条件があります。
支払期日は、物品等を受領した日から起算して60日以内で、できる限り短い期間内に定めることとされています¹。
つまり「支払期日の欄が埋まっているか」だけでなく「埋まった日付が60日以内か」までがセットです。

ここはシステム運用とぶつかりやすいところです。
多くの受発注システムは、取引先マスタに登録した支払サイト、たとえば月末締めの翌々月払いといった条件から支払期日を自動計算します。
締め日基準の計算は、締めた直後に納品した分ほど日数が長くなるため、同じ設定でも納品日によって受領日から60日を超える結果が出ることがあります。
自動計算の設定を入れた時点で全件が安全になるわけではなく、月初納品のような条件の悪い日付でも収まるかを見ておく必要があります。

支払が遅れた場合は、遅延した日数に応じて未払金額に年率14.6%を乗じた額の遅延利息を支払う義務があります¹。
発注書面の話としては欄を埋めるだけに見えますが、そこに書いた日付は支払の実務側で効いてきます。

手形・電子記録債権・有償支給材がある場合は項目が増える

より細かい内訳は、旧下請法の第3条書面の記載事項規則が号建てで定めていました。
当事者の名称や番号等、委託日と給付の内容、受領の期日と場所、検査完了期日、代金額と支払期日に加えて、手形を交付する場合の金額と満期、債権譲渡担保方式などを用いる場合の金融機関に関する情報、電子記録債権を用いる場合の額と支払期日、原材料等を有償で支給する場合の品目・数量・対価などが並びます⁵。

これは旧下請法当時の規則の建て付けで、現行の明示規則の条文番号がそのまま対応するかまではここでは踏み込めません。
ただ、条件付きの項目が別立てになっているという構造は、自社の様式を点検するときの手がかりになります。
手形も有償支給もない取引だけなら基本の項目で足りますが、支給材を出す取引が一件でもあれば、その品目や対価を書く欄が必要になるということです。

受発注システムの標準の発注様式は、物品を買って振込で払うという最も多い形を想定して作られていることが少なくありません。
有償支給や手形をまだ使っている取引がある会社ほど、標準様式のままでは欄が足りない側に寄ります。
項目を追加できるか、追加した項目が相手側の画面や帳票にも出るかは、様式を決める前に見るところです。

交付義務がかかる取引の種類

発注書面の交付義務がかかるのは、製造委託、修理委託、情報成果物作成委託、役務提供委託、特定運送委託とされています¹。
自社の取引がこのどれかに当たるなら、その発注はシステム経由であっても明示事項を満たす必要があります。

注意が要るのは、一つのシステムに複数の性格の取引が流れている場合です。
たとえば同じ購買システムで、図面を渡して作ってもらう加工品の発注と、カタログから選んで買う消耗品の発注が並んでいることがあります。
前者は製造委託として挙げられている類型に当たりますが、後者のような単純な物品の購入は、列挙された委託の類型には挙げられていません。
対象外の取引にまで同じ様式を使う分には支障はありませんが、対象になる取引が、項目の少ない簡易な発注様式のほうに流れていると要件を欠くことになります。
様式を分けているなら、どちらの様式が使われるかを決めている条件が、取引の性格と合っているかを見ることになります。

もう一つ、委託事業者に当たるかどうかには資本金の区分による線引きがあります。
この区分の具体的な金額はここでは扱えないため、自社と取引先がその区分のどちら側に入るかは、公正取引委員会の資料で直接確認してください¹。
同じ取引先でも、相手の資本金が変われば扱いが変わるという性質の条件なので、取引先マスタの情報をいつの時点のもので持っているかも関わってきます。

電磁的方法による交付は認められるか。事前の承諾は必要か

電子で送ること自体は認められている

電磁的方法の中身については、公正取引委員会が下請法当時に示した留意事項が具体的です。
そこでは、電子メールやEDI等による一括送信、ウェブサイト等での閲覧提供、記録媒体の交付という3類型が認められています⁴。
これは令和5年12月25日改正時点の留意事項で、下請法当時の整理ですが、電子的な手段としてどういう形が想定されているかを知るには使えます。

自社の受発注システムがどれに当たるかは、提供の形で変わります。
取引先が自社ポータルにログインして注文書を見る形なら閲覧提供に近く、基幹システムから取引先の受信側へデータを流す形なら一括送信に近くなります。
メールで通知だけを送り、本体はポータルで見てもらう形のように、二つにまたがる作りもあります。
どちらに当たるかで承諾の取り方や説明すべきことが変わってくるので、提供事業者に自社の契約している形態がどの方式にあたるかを聞いておくと、以降の判断が早くなります。

事前の承諾をどう考えるか

留意事項では、書面の交付に代えて電磁的記録を提供する場合、事前に相手方の承諾を得ることが必要とされ、その際に用いる電磁的方法の種類と内容、費用の負担、提供を受けない旨を申し出られることを示す必要があるとされています⁴。
手続としてはかなり具体的です。

一方で、現行の取適法について公正取引委員会が示している委託事業者の義務のページには、書面または電磁的方法により明示することとは書かれているものの、電磁的方法を使う際の相手方の承諾についての具体的な要件は書かれていません¹。
この状態から「承諾はもう要らなくなった」と読むのは早く、逆に旧留意事項の手続がそのまま現行法に引き継がれていると読むのも、ページの記載だけからは確かめられません。

そこで実務の軸に置けるのは、現行の運用基準にはっきり書かれているほうの義務です。
運用基準は、中小受託事業者から明示事項を記載した書面の交付を求められたときは、遅滞なく当該書面を交付しなければならないと定めています²。
つまり、承諾を取っていようといまいと、相手が紙を求める権利はそこに残ります。
承諾の書面を一度取ったから電子だけで完結できる、という理解にはならないということです。

取引開始時の基本契約や覚書に、電子で明示する旨と用いる方法、そして書面の交付を求められた場合は応じる旨を書いておくのは、この二層構造に対する素直な備え方です。
これは確認済みの条文そのものではなく、確実な部分から組んだ運用の考え方として読んでください。
少なくとも、承諾の記録と書面交付の窓口がどこにも無い状態よりは、後から照会が来たときに説明しやすくなります。

受け手が書面を作れる形になっているか

もう一つ、技術面の条件があります。
電磁的方法で提供する場合、受け取った側がファイルへの記録を出力することによって書面を作成できるものでなければならない、とされています⁵。
データが届いていればよいのではなく、相手の手元で紙にできる形かどうかが問われます。

この観点で引っかかりやすいのは、画面での表示に寄った作りです。
注文内容が画面上にしか表示されず、印刷もファイル保存もできない設計、取引先側のプランによって帳票のダウンロードができない設計、一定期間が過ぎると過去の注文が画面から消える設計などは、自社側では気づきにくい一方で、受け取る側にとっては書面を作れない状態になります。
自社の管理者権限で見えている画面と、取引先が実際に使っている権限で見えている画面は違うことがあるので、確認するなら取引先側の見え方で確かめることになります。

出典：公正取引委員会「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律の運用基準」「下請代金支払遅延等防止法第3条の書面の記載事項等に関する規則」（後者は令和5年12月25日改正時点）

受発注システムで見落としやすい点：記号化・書面請求・記録保存

コード表示時の説明義務

受発注システムやEDIでは、項目を文字で書かずコードで送ることがよくあります。
納入場所を三桁の拠点コードで、検査の区分を記号で、支払条件をコードで持っているような形です。
これについて公正取引委員会は、EDIにより発注する場合に記号を用いるときは、各記号の意味をあらかじめ書面又は電磁的方法で中小受託事業者に明示しておけば、記号による通知も可能としています³。

条件は「あらかじめ」と「明示してある」の二つです。
説明資料そのものの形式は問われていないので、紙のコード表でも、データで渡した一覧でも構いません。
問題になりやすいのは、その一覧が最初に一度だけ渡されて、その後の改定が追いついていない場合です。

コードは運用の中で増えます。
新しい倉庫を開けば納入場所コードが増え、検査の基準を分ければ検査区分が増えます。
自社のマスタは即日反映されるのに、取引先に渡したコード表は数年前のままという状態は、実際に起きます。
この場合、新しく増えたコードで発注した分については、意味があらかじめ明示されていたとは言えなくなります。
コードを増やす作業とコード表を配り直す作業を、誰の仕事としてつないでおくかという話になります。

書面交付請求への対応体制

書面の交付を求められたら遅滞なく交付する²、という義務は、システムの機能というより社内の段取りの問題として現れます。

まず、その請求がどこに来るか読みにくい。
取引先の経理が営業担当に電話で言うかもしれませんし、購買の窓口にメールが来るかもしれませんし、システムの問い合わせフォームに入るかもしれません。
受けた人が「うちは電子化したので紙は出していません」と答えてしまうと、そこで要件を欠きます。
請求が来たらどこへ回すかを、受け口になりうる部署に知らせておく必要があります。

次に、出せるかどうか。
直近の発注はすぐ出せても、半年前の一件を求められたときに同じ体裁で出せるかは別です。
さらに、発注後に数量や納期を変更した取引では、どの時点の内容を書面にするのかという判断が要ります。
変更のたびに新しい発注データを起こす運用なら素直ですが、同じレコードを上書きする運用だと、変更前の内容を書面として再現できない場合があります。
この差は、書面請求が来たときに初めて表面化します。

取引記録2年保存への対応

取引に関する記録は2年間保存する義務があります¹。
紙の時代なら書庫の話でしたが、システム運用では保存期間の設定とサービスの仕様の話になります。

見るところは三つあります。
一つは自社側の保持期間で、ログや履歴の自動削除が2年より短い期間で動いていないか。
二つ目はサービス側の仕様で、契約プランによって履歴の保持期間が決まっている場合や、解約後にデータがどう扱われるかという点。
三つ目は取引先側の閲覧期間で、これは自社の保存義務とは別の問題ですが、相手が過去分を見られない状態は書面交付請求が増える要因になります。

何を残すかも決めておくことになります。
発注データそのものに加えて、コードの意味を記した一覧の版と配布した記録、電子で明示することについてのやり取りの記録、書面を交付した場合はその記録。
これらは明示事項そのものではありませんが、後から「あらかじめ明示していたか」「請求に応じたか」を説明するときに必要になる材料です。
どこまで残すかは自社の判断になるので、保存義務の範囲と、説明のために自主的に残す範囲を分けて決めておくと迷いにくくなります。

導入・運用時に発注者が確認すべきこと

導入前に提供事業者へ確認すること

ここまでの内容を、導入の判断や設定の場面に落とすと、確認の相手が二種類に分かれます。
システムの仕様に属することは提供事業者にしか分かりませんし、運用に属することは自社でしか決められません。

提供事業者に聞く側に入るのは、明示事項の項目を発注データとして出力できるか、検査完了期日や支払方法のように標準様式に無いことのある欄を追加できるか、追加した欄が取引先の画面と帳票にも反映されるか、取引先側が注文内容を出力して書面にできるか、履歴の保持期間がどう決まっていて解約後にどうなるか、といった点です。
これらは契約プランで変わることがあるため、製品全体の説明ではなく、自社が契約しようとしているプランでどうなるかとして聞くほうが確実です。

できない機能が見つかった場合でも、すぐに製品を外す判断にはなりません。
たとえば取引先側で出力ができないなら、自社から帳票を送る運用で補えるかという話になります。
機能で満たすのか運用で満たすのかを分けて考えると、選択肢が残ります。

運用に移ってからの確認

運用中に効いてくるのは、最初の設定が正しいかどうかよりも、変わったものが追いかけられているかどうかです。
コードを追加したとき、支払条件を見直したとき、新しい取引先を登録したとき、新しい種類の委託を同じシステムに乗せたとき。
どれも発注画面の操作としては小さな変更ですが、明示事項の充足や事前の説明という側に影響します。

現実的な持ち方としては、マスタを変更する作業の中に、取引先への周知が要るかどうかを判断する一手を入れておくことです。
また、新しい類型の取引をシステムに乗せるときは、その取引がどの様式で流れるかを確認する。
これらは前の節までに見てきた要件から組んだ運用の考え方であって、こうしておけば指摘を受けないという保証ではありません。
ただ、変更のたびに何を見るかが決まっていれば、後から古いコード表や足りない欄をまとめて探し直す作業は減ります。

自社の取引が対象の委託に当たるか、資本金の区分でどちら側に入るかといった根本の部分は、システムの設定では解決しません。
この判断だけは公正取引委員会の資料で自社の位置を確かめたうえで、システム側の設定に落としていく順序になります¹。

確認の抜けは、発注データが作られてから保存期間を終えるまでのどこかで起きます。

明示事項が満たせるかどうかは、法令の条文よりも、自社が契約しているプランで発注データがどこまで出力され、取引先の画面でどう見えるかという仕様側で決まる部分が大きく、社内の資料だけでは確かめきれないことがあります。

現在の発注様式と出力項目を見ながら、どの欄が足りず、どこは運用で補えるのかを一緒に切り分けられます。無料相談で要件を整理する

発注1件を追いかけて確認する

発注データが作られてから保存期間を終えるまでの時間の流れで並べています。

• 発注を入力した時点で、当事者の名称、委託日、給付の内容、受領の期日と場所、検査完了期日、代金の額、支払期日、支払方法まで埋まるか

• 支払期日の自動計算が、月初納品のような条件でも受領日から60日以内に収まるか

• コードで表示している項目があるなら、その意味を記した一覧が最新の版で相手先に渡っているか

• 送信した内容を、取引先が自分の権限で出力して書面にできるか

• 紙の交付を求められたとき、誰が受けてどこから出すか、過去分や変更後の内容も出せるか

• その発注データと関連する記録が、2年経つまで消えない設定になっているか

取引先ごとに送信の方式や使うコードが違う場合は、この順序ではなく取引先単位で並べ直したほうが、抜けのある相手を見つけやすくなります。

要点の整理

軸	基準
媒体	書面でも電磁的方法でも、明示事項を満たせば明示義務は果たせる
項目	名称・委託日・給付の内容・受領の期日と場所・検査完了期日・代金の額・支払期日・支払方法など11項目
対象取引	製造委託・修理委託・情報成果物作成委託・役務提供委託・特定運送委託
支払期日	受領日から起算して60日以内、できる限り短い期間
コード表示	各記号の意味をあらかじめ書面又は電磁的方法で明示していること
書面交付請求	求められたら遅滞なく交付する（電子で明示していても残る）
記録の保存	2年間

コードの意味の周知、書面交付請求の受け口、履歴の保持期間は、それぞれ担当する部署が違うため、一人の担当者がまとめて確認しにくい部分です。 どの確認を誰の作業の中に組み込めば運用として続くのか、既存の業務の流れに合わせて整理できます。

よくある質問

受発注システムを使っていれば、紙の発注書は一切作らなくてよいのか

日常のやり取りを電子で完結させること自体は、明示事項を満たしていれば問題になりません²。
ただし、中小受託事業者から明示事項を記載した書面の交付を求められたときは、遅滞なく交付する義務が残ります²。
そのため「紙を作らない」ではなく「普段は作らないが、求められたら出せる道を一つ持っている」という状態が必要になります。

下請事業者から紙の発注書を求められたら、その都度対応しなければならないのか

運用基準は、求められたときは遅滞なく書面を交付すると定めており、回数の上限や条件は示されていません²。
実務としては、毎回求めてくる取引先については最初から書面を併用する運用に切り替えたほうが、都度の対応より手間が少なくなることがあります。
これは義務の解釈ではなく段取りの選び方なので、相手先の事情を聞いて決める部分です。

取引記録の2年保存は、システムのログが残っていれば足りるのか

取引に関する記録は2年間保存する義務があります¹。
どの形式で残せば足りるかまでは概要の記載からは読み取れないため、ログという形なら十分だと断じることはできません。
判断の起点に置けるのは、明示した内容を後から再現できるかどうかです。
操作の履歴だけが残り、発注内容そのものが期間経過で画面から消える設定なら、再現できるかを確かめておく必要があります。

支払期日60日のルールは、システムの支払日設定にどう反映すればよいのか

支払期日は、物品等を受領した日から起算して60日以内で、できる限り短い期間内に定めることとされています¹。
締め日と支払日で設定する方式は、締めた直後の納品ほど日数が伸びるため、同じ設定でも納品日によって60日を超えることがあります。
設定を入れた時点で確認するなら、最も不利な納品日を当てはめて計算し、収まるかを見ます。
支払が遅れた場合は、遅延した日数に応じて未払金額に年率14.6%を乗じた遅延利息を支払う義務が生じます¹。

EDIでコード表示している項目は、別途説明資料を用意しなければならないのか

記号を用いる場合、各記号の意味をあらかじめ書面又は電磁的方法で中小受託事業者に明示しておけば、記号による通知も可能とされています³。
資料の形式は限定されていないので、紙の一覧でもデータで渡す一覧でも構いません。
条件になるのは、発注より前に相手に渡っていることです。
コードを追加したときに渡し直す段取りがないと、新しいコードの分だけ条件を満たさない状態になります。

1. 1　出典：公正取引委員会「委託事業者の義務（取適法の概要）」（2026年）
2. 2　出典：公正取引委員会「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律の運用基準」（2026年）
3. 3　出典：公正取引委員会「よくある質問コーナー（取適法）」（2026年）
4. 4　出典：公正取引委員会「下請取引における電磁的記録の提供に関する留意事項」（令和5年12月25日改正）
5. 5　出典：公正取引委員会「下請代金支払遅延等防止法第3条の書面の記載事項等に関する規則」（令和5年12月25日改正）