BtoB受発注ポータルとは、取引先向けのオンライン受発注システムです。法人顧客はいつでも商品コードを使って自社向けの契約単価で発注でき、関連書類も1か所で確認できます。卸売業者や商社、メーカーがこの卸売ポータルを構築するのは、電話対応の人員を増やさずにより多くの取引先に対応し、メールで届く注文の手入力をなくすためです。

本記事では、一般的なECサイトと比べてBtoB受発注ポータルに求められる機能、ERPや倉庫との連携方法、チェコおよびEUの付加価値税（VAT）に関する注意点、営業担当者の業務の変化、そして段階的な導入手順を解説します。

取引先がオンライン発注を求める理由

取引先がオンライン発注を求めるのは、手間と発注ミスを減らせるからです。購買担当者や建設現場の職長は、普段使っている個人向けECサイトと同じように、価格や在庫をその場で確認し、夜間に発注して配送状況を追跡することに慣れています。しかし法人取引では、電話がつながらなかったり、回答が翌日になったりすることが少なくありません。

オンライン発注には、取引先にとって明確な利点があります。

• 必要なときにいつでも、自社単価と実際の在庫状況を見ながら発注できます。
• 使い慣れた商品コードで注文できるため、規格やバリエーションの間違いが起きません。
• 担当者が不在でも、請求書や納品書、注文履歴を1か所で確認できます。

一方、卸売側にとっても、手作業での転記や入力ミス、在庫・配送状況の問い合わせ対応がなくなります。営業担当者は既存顧客のフォローや提案に時間を割けるようになります。

たとえば、数百社の工務店や職人に締結部品を卸している架空の商社を考えてみましょう。数十点のコードが並ぶ注文の大半がメールや電話で届き、事務スタッフが手作業でシステムへ転記しながら契約単価を確認していれば、どうしてもミスが生じます。BtoBポータルの効果が最も早く表れるのは、まさにこうした現場です。ただし対面や電話の営業がなくなるわけではありません。大口案件や条件交渉は営業担当者が担い、定型業務をポータルが引き受けます。

BtoB受発注ポータルとBtoC ECサイトの違い

BtoB受発注ポータルが一般的なECサイトと大きく異なるのは、取引先ごとに取引条件が違う点です。消費者向けECサイトは全員に同じ価格を表示して前払いで決済しますが、BtoBポータルは企業ごとの契約内容、割引率、支払サイト、与信限度額を反映しなければなりません。主な違いは以下のとおりです。

実務上、ポータルは価格表や未払請求書、与信限度額をERPから直接取得する必要があります。また、1社で複数アカウントを使えるようにすれば、倉庫担当者が注文を作成し、上長が承認するといった運用が可能になります。

商品カタログの作りも異なります。取引先は商品コード、技術仕様、メーカー型番で検索します。販売単位もパック、カートン、パレット単位となり、最小発注量や数量割引が設定されます。そのためポータル側で単位換算を行い、倉庫が実際に出荷できる単位と整合させる仕組みが欠かせません。

つまり、一般的なECサイトの価格をログイン後に表示するだけでは不十分です。BtoBポータルは、自社のERPの上に構築する顧客専用システムといえます。なお、既存のECプラットフォームのなかにもBtoB向けモジュールを備えたものがあります。選定のポイントはECサイトのプラットフォーム選びで詳しく解説しています。

BtoBポータルの機能：必須項目と後回しにできる項目

最初からすべての機能を備える必要はありません。初期リリースに不可欠な機能、あると便利な機能、第2フェーズ以降に回せる機能に切り分けましょう。

どの機能が本当に必須かを最もよく知っているのは、実際の取引先です。まずは主要顧客5社ほどに、普段の発注で何に一番手間取っているかを聞いてみてください。

最も工数を削減できるのは、表計算ソフトからコピーした一覧をそのまま貼り付けられる商品コード発注と、ワンクリックでの再発注機能です。現場監督やフィールドエンジニアが外出先から注文することも多いため、荷物追跡とあわせてスマートフォンでも快適に操作できる設計が求められます。

書類管理も軽視できません。取引先の経理担当者がポータル上で請求書、納品書、未払残高をすぐに確認できれば、電話での問い合わせや督促の手間が大幅に減ります。

ERPおよび倉庫との連携

価格、与信枠、在庫、書類に関する唯一の情報源（シングル・ソース・オブ・トゥルース）は、あくまでERP（在庫管理を含む基幹・会計システム）です。BtoBポータルはERPからデータを読み取り、受けた注文をERPへ返します。ポータル側に独自の価格表や在庫データを持たせると、すぐにERPとのズレが生じ、ポータル上の表示価格と請求書の金額が食い違う原因になります。

データ同期の頻度は、情報の変化スピードに応じて設計します。

• 注文データは倉庫ですぐに出荷準備に入れるよう、即時ERPへ送信します。
• 在庫状況は回転の速い商材なら数分おき、動きの緩やかな商材ならより長い間隔で更新します。
• 価格表と割引率はERP側で変更があったタイミング、遅くとも1日1回は同期します。
• 与信限度額と未払請求書は限度額超過の注文を防ぐため、注文確定時にリアルタイムで照会します。
• 請求書と納品書はERPで発行され次第、速やかにポータルへ取り込みます。
• 配送状況は配送業者のシステムから自動で取得します。

チェコで広く使われているPohoda、Money、ABRAといった基幹システムには、データ連携用のインターフェースが用意されています。たとえばPohodaでは、ファイル経由またはHTTPインターフェースmServerを通じて、注文・請求・在庫データをXML形式でやり取りできます（Stormware、XMLドキュメント）。連携インターフェースの仕様と処理速度は設計や開発費用に直結するため、プロジェクト初期に必ず確認してください。詳しくはECサイトと会計システムの連携でも解説しています。

お使いのERPに連携インターフェースがない場合は、次の3つの選択肢があります（費用やリスクが異なるため、初期要件定義の段階で方針を決めます）。

• ファイルの定期エクスポート・インポートによる連携、
• ポータル向けにデータを変換する中間層（ミドルウェア）の構築、
• 老朽化したERP自体の刷新。

ERPのアップデートやサーバー障害、未登録の商品コードなどが原因で通信エラーが起きることもあります。優れたポータルは注文データを消失させず、管理者に通知したうえで再送処理を行います。開発会社を選ぶ際は、画面デザインと同じくらいエラー時の処理についても詳しく確認しましょう。

チェコおよびEUにおけるBtoBポータルの実務要件

チェコおよびEU圏で運用するBtoBポータルでは、取引先の確認と付加価値税（VAT）の税区分判定を適切に行う必要があります。なお、本項は税務アドバイスに代わるものではありませんので、具体的な設定は税理士にご相談ください。

ARES。チェコ財務省のARESインターフェースは事前登録なしで無料利用できます。法人番号（IČO）をもとに社名や本店所在地を取得し、登録情報の変更も継続的にチェックできます。

VIES。EU加盟国のVAT登録事業者に対する物品供給は、取引先がVAT番号（DIČ）を提示し、物品が該当国へ輸送され、かつ総括申告書に記載することを条件に、付加価値税法（法律第235/2004号、2026年1月1日施行版）第64条に基づきVATが免除されます。ポータルは登録時に欧州委員会のVIESインターフェース経由でVAT番号を照会し、結果に応じて適切なVAT区分を自動設定します。なお、VIESが確認するのはVAT番号の有効性のみであり、税率は確認しません。

リバースチャージ方式（納税義務の転換）。同法第92a条以降に基づき、課税事業者として取引する買い手（VAT登録事業者）が納税義務を負う取引があります。金、廃棄物・スクラップ（別表第5）、建設・組立工事、政令で定める別表第6の対象物品などが該当します。ポータルとERPの双方で、法令に沿った正しい証憑を発行できる仕組みが必要です。

海外取引。多言語対応は初期設計から考慮し、ユーロ建ての価格表もチェココルナ建てと同様にERPから取得します。

価格表示と書類。画面上は税抜価格を基本とし、取引先の税区分に応じて税額を計算します。チェコの法制度に準拠した請求書は、採番体系を一本化するためERP側で発行します。

配送。自社便、店頭受取、外部配送業者といった選択肢を用意し、配送ステータスを自動連携します。

営業担当者の働き方はどう変わるか

注文の転記作業がなくなることで、営業担当者は発注量が減っている取引先へのフォロー電話や新商品の案内など、本来の顧客対応に時間を使えるようになります。

一方で、取引先が自分で発注するようになると「自分の仕事や歩合給が減るのではないか」と不安を抱く担当者もいます。取引先にポータルを使ってもらえるかどうかは営業担当者にかかっているため、公開前に次の4点を整えておきましょう。

1. 設計段階から巻き込む： 顧客からよく聞かれる質問や、発注時のつまずきポイントを最もよく把握しているのは現場の営業です。
2. 評価・歩合の仕組みを整える： ポータル経由の注文も担当者の実績・歩合に計上します。これがないと顧客にポータルを勧めなくなります。
3. 顧客データを可視化する： 担当顧客の注文状況や履歴、発注減少のアラートを営業画面で確認できるようにします。
4. 取引先への案内を任せる： マニュアルを送るだけよりも、初回発注時に営業担当者が電話でサポートするほうが定着率は高まります。

稼働から数か月後に、事務処理にかけていた時間と顧客フォローに使えるようになった時間を比較し、営業チームと結果を共有しましょう。ポータルは営業の仕事を奪うのではなく、定型作業を肩代わりするツールです。

既製プラットフォームか独自開発か：段階的な導入手順

価格体系がシンプルで取引先数もそれほど多くなく、一般的なERPを使っている場合は既製プラットフォームで十分対応できます。一方、複雑な価格計算、膨大な商品点数、承認ワークフロー、独自のERP連携が必要な場合は、オーダーメイドのBtoBポータル開発が適しています。判断基準はオーダーメイド開発か既製システムかで詳しく取り上げています。

導入は段階的に進めるのが確実です。

1. 要件定義。 初期バージョンの機能範囲、ERPとの連携方式、社内のプロジェクト責任者を決めます。
2. パイロット運用。 発注頻度の高い取引先を5〜10社選び、先行利用してもらいます。マスターデータの不備を早期に洗い出せます。
3. 効果測定。 ポータル経由の受注比率、ミス発生率、社内工数の削減時間を追跡します。削減効果を正しく比較できるよう、公開1か月前に現状の数値を記録しておきます。
4. 段階的な拡大。 対象となる取引先と機能を順次広げていきます。

取引先への案内は、営業担当者からの個別連絡とメール案内を併用します。操作ガイドを添え、初回注文を一緒に進めるサポートも提案しましょう。電話やメールなどの既存窓口をいきなり廃止するのではなく、書類の一覧性、在庫確認、履歴参照、手配の早さといったポータルの利点を丁寧に伝えて移行を促します。

私たちは卸売・流通分野において、GPD B2B（タイヤ卸売業者向けBtoBサイト）やTyreto（タイヤ専門ECサイト）などを開発してきました。その他の事例は制作実績でご覧いただけます。

私たちはBtoBポータルを、23万チェココルナ〜のオーダーメイドWebアプリとして構築しています。既存ECサイトの機能拡張で対応できる場合は、14万チェココルナ〜のネットショップ構築からご用意しています。

まずは私たちのプロジェクト・コンフィギュレーターをお試しください。いくつかの質問に答えるだけで、要件の概要と3つの構築プランを作成できます。

よくある質問