まずは卸売ECを小規模でスタートしたい方へ。リーズナブルなSaaS(ASP)版『EC-Rider Primo(プリモ)』誕生! 詳しくはこちら

BtoB EC 承認ルートの部門別設計|権限表の作り方

◆監修・編集責任者 小園 将隆 

B2B EC-COLUMN

この記事のポイント

  • 承認ルートは部門の数だけ増やすものではなく、共通のルートに「承認者の割当」と「金額閾値」を当てはめて設計します。
  • 承認権限マトリクス(権限表)に必要な列を明確にすれば、部門ごとの承認者・閾値・代理・期限を一枚で管理できます。
  • 2026年1月施行の取適法(旧下請法)や電子帳簿保存法など一次情報を踏まえ、承認完了と発注確定のタイミングで満たすべき要件を整理します。
承認のイメージ
▽ 写真の出典元

承認ルートは内部統制の実装 — 権限と職務分掌がすべての起点

BtoB ECの承認ルートとは、発注を確定させる前に、起票者とは別の権限者が発注内容・金額・取引条件を確認して許可する一連の手続です。この手続をEC上の分岐として定義したものが承認ルートです。承認ルートは、金融庁が定める内部統制の統制活動、つまり「権限及び職責の付与、職務の分掌等の広範な方針及び手続」に位置づけられます*1

図
部門別の承認ルートは、共通ルートに承認者割当と金額閾値の2軸を当てはめて設計します

統制活動=権限及び職責の付与・職務分掌(金融庁基準)

金融庁「財務報告に係る内部統制の評価及び監査の基準」は、内部統制の目的の一つに「資産の保全」を挙げています。資産の保全とは、資産の取得・使用・処分が正当な手続及び承認の下に行われるよう図ることです*1。承認ルートは単なる便利機能ではなく、この統制活動を業務プロセスに組み込んだものと理解できます。

したがって承認ルートの設計は、システムの機能選定ではなく、誰にどの権限を与え、どこで職務を分けるかという統制設計の一部として扱う必要があります。

部門別に分かれる理由は取引規模と責任範囲の違い

部門ごとに承認ルートを分けるのは、部門が扱う取引の種類・金額規模・責任範囲が異なるためです。購買部門は資材の継続発注を扱い、現場部門はスポットの消耗品発注を扱うといった具合に、判断すべき論点が違います。

ただし、この違いを「部門ごとに専用のルートを作る」ことで表現すると、後述するように保守できなくなります。見積という対象物そのものの承認フローを詳しく知りたい場合は別記事をご確認ください。本記事はルート構造の部門別設計に範囲を絞ります。

部門別設計で最初に決める3つのこと

部門別の承認ルートを検討する際は、最初に「対象取引」「承認者」「金額閾値」の3点を決めます。この3点が決まれば、後続のステップで共通ルートへ落とし込めます。

BtoB-EC市場514.4兆円・EC化率43.1%が示す電子化の進展

2024年の日本国内のBtoB-EC(企業間電子商取引)市場規模は514.4兆円で、前年の465.2兆円から10.6%増加しました*4。EC化率も43.1%となり、前年比3.1ポイントの増加です*4

2024年のBtoB-EC市場規模とEC化率(経済産業省調査)

経済産業省の令和6年度電子商取引に関する市場調査によれば、BtoB-EC市場は前々年420.2兆円、前年465.2兆円でした。2024年は514.4兆円となり、拡大を続けています*4。なお同調査のEC化率は、すべての商取引金額に対する電子商取引の割合を指し、BtoB-ECでは業種分類上「その他」以外とされた業種を算出対象としています*4。EC化率の上昇は、発注から承認までの業務がシステム上に乗る取引が増えていることを意味します。

電子化が進むほど承認の設計漏れが事故に直結する理由

取引の電子化が進むほど、承認ルートの設計に漏れがあると、その漏れがそのまま事故として現れやすくなります。紙の時代は担当者の目視や口頭確認が事後的な歯止めとして働いていましたが、EC化した業務ではその歯止めが働きません。

紙・電話・FAXの承認をそのままEC化すると起きること

紙・電話・FAXでの承認運用をそのままEC化すると、承認者が誰かを画面上で特定できない、承認履歴が残らないといった問題が起こります。電話・FAXからの移行そのものの進め方は別記事で詳しく扱っています。

組合せ爆発・承認者不在・職務分掌の破れ — 部門別設計を誤ると起きる3つの失敗

権限のイメージ
▽ 写真の出典元

部門別の承認ルート設計を誤ると、運用が破綻する典型的な失敗が3つあります。いずれも設計段階の見落としが原因であり、稼働後の修正コストは大きくなります。

部門×取引種別のルート増殖で保守できなくなる

部門の数だけルートを個別に作ると、部門×取引種別の組み合わせでルート数が増え続けます。担当者が入れ替わるたびに全ルートを見直す必要が生じ、権限表そのものが管理不能になります。

代理承認・期限が未設計だと発注が止まる

承認者が休暇や出張で不在になったときの代理承認者や、承認の期限を決めていないと、発注そのものが止まります。取引先への支払期日を守れなくなる要因の一つは、この承認段階での滞留です。

起票者が自分の発注を承認できると統制が破れる

起票者と承認者を分けずに運用すると、統制活動に含まれる「権限及び職責の付与、職務の分掌」が機能しません*1。同一人物が起票と承認を兼ねる設計は、職務分掌の原則そのものに反します。

内部不正・なりすましは10大脅威で第7位・第10位

IPA(独立行政法人情報処理推進機構)の「情報セキュリティ10大脅威 2026」の組織編では、内部不正による情報漏えい等が第7位です。ビジネスメール詐欺(BEC、取引先や経営層を装ったメールで金銭を詐取する攻撃)は第10位に選出されています*5。ビジネスメール詐欺は9年連続9回目の選出であり、承認権限を狙う攻撃が継続的な脅威であることを示しています*5

部門別承認ルートを設計する5ステップ

部門別の承認ルートは、次の5ステップで設計します。部門ごとにルートを新設するのではなく、共通テンプレートに部門差を当てはめる考え方が中心です。

ステップ1:対象取引を洗い出して分類する

まず購買種別・金額規模・継続取引かスポット取引かで対象取引を分類します。この分類が後続の閾値設計の土台になります。

ステップ2:職務分掌を先に決める

起票・承認・支払の3役割を同一人物に集めないことを先に決めます。ここを後回しにすると、後のステップで矛盾が発生します。

ステップ3:共通ルートテンプレートを1〜2本に絞る

部門別にルートを増やさず、共通のテンプレートを1本または2本に絞り込みます。テンプレートの分岐条件は、次のステップで扱う2軸だけに限定します。

ステップ4:部門差は「承認者の割当」と「金額閾値」の2軸だけで表現する

部門ごとの違いは、ルート構造ではなく「誰を承認者に割り当てるか」と「どの金額で段数が変わるか」の2軸だけで表現します。この2軸に絞ることで、部門が増えてもルート自体は増やさずに済みます。

ステップ5:例外・代理・期限・エスカレーションを明文化する

最後に、承認者不在時の代理承認者、承認の期限、期限超過時のエスカレーション先を明文化します。口約束の例外運用を残すと、証跡が残らず内部統制の弱点になります。代理承認者を権限表の列として置くところまでが本記事の範囲であり、代理注文・権限委譲そのものの設計論は別記事に譲ります。

承認権限マトリクス(権限表)に持たせる10列

取適法のイメージ
▽ 写真の出典元

承認権限マトリクス(権限表)とは、「誰が・何を・いくらまで」承認するかを1枚の表で整理したものです。部門・対象取引・承認者・金額閾値・代理承認者などを列として持たせます。

権限表に欠かせない列 優先順6点(順位根拠:重要度)

  1. 部門:対象取引を担う組織を特定する列です。
  2. 一次承認者・二次承認者:承認段数と、各段の承認者ロールを定める列です。
  3. 金額閾値:承認段数が切り替わる基準額を定める列です。自社の決裁規程の値をそのまま転記します。
  4. 代理承認者:承認者不在時の受け皿を定める列です。
  5. 承認期限:発注を止めないための上限日数を定める列です。
  6. 根拠規程:どの社内規程に基づく承認かを参照できるようにする列です。

権限表の10列:起票者ロールから根拠規程まで

権限表には「部門/対象取引/起票者ロール/一次承認/二次承認/金額閾値/代理承認者/承認期限/エスカレーション先/根拠規程」の10列を持たせます。金額閾値に公的な相場は存在しないため、具体的な金額の例示は避け、自社の決裁規程の値を転記する手順として扱います。

購買・製造/現場・情報システム・経理4部門の記入例

次の表は、購買・製造/現場・情報システム・経理の4部門で、対象取引と承認段数がどう変わるかを整理した記入例です。金額の欄は各社の決裁規程を転記する前提で、具体額はあえて記載していません。

部門 対象取引 起票者ロール 承認段数 代理承認者
購買部門 資材・原材料の継続発注 購買担当 2段階(担当→購買責任者)。
閾値は自社の決裁規程を転記します。
購買責任者代理
製造/現場部門 消耗品・治工具のスポット発注 現場責任者 1段階(現場責任者のみ、上限額あり)。
上限を超えたら購買部門へ回します。
現場副責任者
情報システム部門 ソフトウェア・クラウド利用料 システム担当 2段階(担当→情報システム部門長)。
継続契約は年次で見直します。
情報システム部門長代理
経理部門 支払実行前の最終確認 経理担当 1段階(経理責任者による支払前確認)。
他部門の承認履歴を参照します。
経理責任者代理

権限表をシステム設定へ落とすときの注意

権限表をシステムの承認ルート設定へ反映する際は、承認者を個人名ではなくロール(役職・職務)で持たせます。権限そのものやアカウントの管理方法を詳しく知りたい場合は、別記事の権限・アカウント管理の解説をご確認ください。本記事は、権限を前提にした承認の連鎖の設計に範囲を絞ります。

個人名で持たせると、異動や退職のたびに設定変更が発生し、変更漏れが統制上の弱点になります。ロールで持たせれば、異動時の変更は担当者の入れ替えだけで済みます。

2026年1月施行の取適法が承認ルートに課す4つの義務

2026年1月1日、下請代金支払遅延等防止法(下請法)は名称と規制内容が変わります。改正後の名称は「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」(取適法)です*2。委託事業者には4つの義務が課されます*2

下請法から取適法へ:2026年1月1日施行

取適法では、資本金基準に加えて従業員基準(300人、100人)が追加され、規制及び保護の対象が拡充されます*2。ただし対象取引の内容によって基準は異なるため、「従業員が何人以下なら対象」と単純に言い切ることはできません。

発注内容等を明示する義務を承認完了の瞬間にどう満たすか

委託事業者は、発注に当たって発注内容(給付の内容、代金の額、支払期日、支払方法)等を書面又は電磁的方法により明示する義務を負います*2。承認ルートを設計する際は、承認完了=発注確定のタイミングで、この4項目をEC上のどの画面・データで明示するかを決める必要があります。

電磁的方法は中小受託事業者の承諾なしで可能になった

改正前は電磁的方法による書面交付に相手方の承諾が必要でしたが、取適法では中小受託事業者の承諾の有無にかかわらず、電子メールなどの電磁的方法が可能になります*2。これにより、EC上での発注明示だけで義務を満たせる設計余地が広がります。ただし、書面での提供を求められた場合の対応は別途必要です。

60日以内の支払期日と承認段数が競合する

取適法は、発注した物品等を受領した日から起算して60日以内のできる限り短い期間内で支払期日を定める義務を課しています*2。支払遅延や減額を行った場合は、遅延した日数や減じた額に応じて年率14.6%の遅延利息を支払う義務も生じます*2。承認段数を増やしすぎると、この60日という期日そのものを圧迫し、支払遅延として遅延利息を求められるリスクにつながります。

与信限度額を超えた発注を承認フローへ回す設計も一般的ですが、与信超過時の運用詳細は本記事の範囲を超えるため、別記事で扱っています。

承認履歴を電子取引データとして保存する

よくある質問のイメージ
▽ 写真の出典元

取適法は、取引完了時に給付内容・代金の額など取引の記録を書類又は電磁的記録として作成し、2年間保存する義務を課しています*2。承認履歴は、この記録の一部として扱う必要があります。

電子取引データの保存が必要になる範囲

発注・受注・請求のデータは、電子取引データとして保存が必要になる代表的な範囲です。保管期間の設計そのものは別記事で詳しく扱っています。

承認履歴に残す項目:誰が・いつ・どの権限で

承認履歴には、誰が、いつ、どの権限で承認したかを記録します。この3点が欠けると、内部統制の証跡としても取適法の記録保存義務としても不十分になります。電子帳簿保存法対応の詳細は別記事をご確認ください。

最新の解釈は国税庁「電子帳簿保存法一問一答」で確認する

電子取引データの保存に関する最新の解釈は、国税庁「電子帳簿保存法一問一答【電子取引関係】」(令和8年7月)で確認できます*3。この一問一答は改訂が続くため、承認履歴の設計を固定する前に最新版の有無を確認しておく必要があります。

設計レビュー10項目と段階的な進め方

権限表を確定させる前に、次のチェックリストで設計をレビューします。すべてを一度に完璧にする必要はありませんが、抜けている項目は運用開始後の障害要因になります。

設計レビュー用チェックリスト(10項目)

  1. 起票者と承認者が同一人物にならないか(職務分掌)
  2. 金額閾値は自社の決裁規程と一致しているか
  3. 代理承認者が全承認段に設定されているか
  4. 承認期限が定められているか
  5. 期限超過時のエスカレーション先が明確か
  6. 承認履歴(誰が・いつ・どの権限で)が記録されるか
  7. 発注内容(給付の内容・代金の額・支払期日・支払方法)が承認完了時に明示されるか
  8. 承認者はロールで設定され、個人名に依存していないか
  9. 部門別の例外が口頭運用ではなく権限表に明文化されているか
  10. 承認段数が支払期日(60日以内)を圧迫しない設計か

一度に全部門をやらない

権限表は、対象取引の多い1部門で先行して確定させ、そのあとで他部門へ横展開する進め方が現実的です。全部門を同時に設計しようとすると、部門間の調整に時間がかかり、どの部門の要件も固まらないまま停滞します。

稼働後に見直すトリガー

組織改編、社内規程の改定、法改正(取適法・電子帳簿保存法の解釈変更など)が起きたタイミングは、権限表を見直すべき節目です。見直しを定例化せず放置すると、規程と実際の承認ルートがずれていきます。

権限表を内製で確定させるには、自社の決裁規程の読み込み、情報システム部門との設定調整、部門ごとの合意形成という3種類の作業が同時に必要になります。対象取引の種類が多い企業ほど、閾値と例外の組み合わせが増え、部門間の調整に時間がかかります。権限表を要件定義へ落とし込む具体的な進め方は、別記事もご確認ください。

自社だけで権限表を確定させる場合と、外部の設計支援を受ける場合の違いは、部門横断の調整に要する時間と、取引先ごとの商習慣を反映できるかどうかに表れます。取引先企業ごとに商習慣や組織構造が異なるため、汎用パッケージの標準機能だけでは収まらない場合が少なくありません。それを自社の数字で確かめるには、無料相談で要件を整理するのが近道です。

まとめ:部門別承認ルート設計の3つの判断軸

承認のイメージ
▽ 写真の出典元

本稿では、BtoB ECの承認ルートを部門別に設計する考え方を整理しました。要点を3つに集約すると次の通りです。第一に、承認ルートは内部統制の統制活動として位置づけ、部門の数だけルートを増やさないこと。第二に、部門差は「承認者の割当」と「金額閾値」の2軸だけで表現し、権限表としてロールで管理すること。第三に、2026年施行の取適法や電子帳簿保存法など一次情報に沿って、承認完了と発注確定のタイミングで満たすべき要件と証跡を明確にすることです。


ご不明な点はお問い合わせフォームからもご連絡いただけます。

BtoB通販システムのご相談

貴社の商習慣に合わせたご提案をいたします。

無料相談はこちら

よくある質問

承認ルートは部門ごとに作るべきですか。

ルートそのものを部門ごとに作る必要はありません。共通ルートに「承認者の割当」と「金額閾値」の2軸を当てはめれば部門差を表現でき、金融庁の内部統制基準が示す職務分掌の原則にも合致します*1。部門数だけルートを増やすと組み合わせが爆発し、保守できなくなります。

承認は何段階までにすべきですか。

段数についての公的な相場は存在しないため、一般論では答えられません。取適法が受領日から60日以内の支払期日を義務化している点を踏まえる必要があります*2。承認段数を増やすほど法定期日を圧迫するため、自社の決裁規程と業務量から段数を決めます。

承認者が不在のときはどうしますか。

代理承認者は個人名ではなく役職・職務のロールで権限表に登録し、承認期限を過ぎた案件がエスカレーション先へ回る状態にしておきます。個人名で登録すると異動や退職のたびに設定変更が発生し、その変更漏れがそのまま承認の空白になります。取適法は受領日から起算して60日以内の支払期日を義務づけているため、不在による滞留は法定期日を直接圧迫します*2

社内の稟議システムとBtoB ECのどちらで承認すべきですか。

発注の確定に直結する承認はEC上で完結させ、導入そのものに関する社内の意思決定手続き(稟議)は別の階層として扱う整理が実務的です。導入時の社内稟議と、発注ごとの承認は目的が異なるため混同しないようにしてください。

承認履歴はどのくらい保存する必要がありますか。

取適法は取引完了時の記録を2年間保存する義務を課しています*2。電子取引データとしての保存範囲は、国税庁「電子帳簿保存法一問一答【電子取引関係】」(令和8年7月)で確認できます*3

◆監修・編集責任者

小園 将隆

株式会社フライトソリューションズ ECサービス部 マネージャー

BtoB通販のパッケージシステム「EC-Rider B2B Ⅱ」の導入支援をはじめ、製造業、卸売業をはじめとした法人向け通販サイト構築を多数手掛ける。卸売領域の専門知識をもとに、日本の商習慣に固有の課題をパッケージシステムの機能追加によって解決。BtoB流通の販路拡大を支援する。

  1. *1 出典:金融庁 企業会計審議会「財務報告に係る内部統制の評価及び監査の基準」(令和5年4月7日)
  2. *2 出典:公正取引委員会「取適法リーフレットNo.01」(令和7年8月)
  3. *3 出典:国税庁「電子帳簿保存法一問一答【電子取引関係】」(令和8年7月)
  4. *4 出典:経済産業省「令和6年度電子商取引に関する市場調査の結果を取りまとめました」(2025年8月26日)
  5. *5 出典:独立行政法人情報処理推進機構(IPA)「情報セキュリティ10大脅威 2026」(2026年1月29日)

画像の出典元

  1. 承認のイメージ/Photo by Aaron Burden on Unsplash
  2. 権限のイメージ/Photo by Vagaro on Unsplash
  3. 取適法のイメージ/Photo by 2H Media on Unsplash
  4. よくある質問のイメージ/Photo by Stephen Harlan on Unsplash
  5. 承認のイメージ/Photo by Lewis Keegan on Unsplash

◆この記事について

独自調査以外の一次情報は、省庁・公的機関を中心とした信頼性の高い情報源から引用し、出典を明記しています。
年次更新される統計については、引用元の最新版を確認したうえで掲載しています。

※この記事は上記の監修・編集責任者がAIの協力を得て制作しています。

監修確認日:

記事内容に関するお問い合わせ:お問い合わせフォーム

BtoB EC(受発注)サイト構築システム「EC-Rider B2B Ⅱ」への
各種お問い合わせ

ページTOPへ戻る
無料相談を予約 お見積
平日10:00~18:00
page
top