伝票システム導入の要件定義：洗い出しから見積依頼書までの進め方

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

B2B EC-COLUMN

伝票の転記や様式違いに悩んだとき、要件定義で最初に決めるのは何か

取引先ごとに違う注文書を販売管理へ打ち直し、分納や返品のたびに納品書と請求書を手で直している。
システムで楽にしたいと思っても、何を決めれば導入に進めるのかが見えないまま、製品資料だけが増えていく。
この段階で最初に手を付けるのは、製品選びではなく伝票の流れの棚卸しです。
伝票システム導入の要件定義では、今ある伝票の種類・流れ・件数・例外を書き出し、機能、取引先とのやり取り、既存システム連携、運用ルールに振り分けます。
取引先の対応可否と電子取引データの保存条件を先に確かめ、必須と後回しを分ければ、見積依頼に渡せる要件になります。

要件定義は「何を実現したいか」を決める工程

要件定義は、製品を選ぶ前に、新しい仕組みで何を実現したいのかを言葉にして決める工程です。
IPA（情報処理推進機構）のガイドは、要件定義をビジネス要求定義、システム化要求定義、要件定義マネジメントに分けて整理しています¹。
ビジネス要求定義は、業務で何を変えたいかを集めて分析し、文書にする段階です。
システム化要求定義は、それをシステムに求める仕様として書き、確認し、評価する段階です¹。

伝票の仕事に置き換えると、この二つの違いが見えやすくなります。
たとえば「FAXで届く注文書を販売管理に打ち直す手間をなくしたい」は、業務で実現したいことなのでビジネス要求にあたります。
「受け取った注文の内容を、販売管理へ取り込める形で受け付けられること」は、そのためにシステムへ求めることなのでシステム化要求にあたります。
製品の機能一覧から読み始めると後者ばかりが並び、なぜそれが必要なのかという前者が抜けやすくなります。
前者が抜けた要件は、見積の段階で「この機能は本当に要るのか」と問われたときに、答えの拠り所がありません。

ですから最初に決めるのは、どの伝票のどの手間を減らしたいのか、という業務側の目的です。
転記を減らしたいのか、取引先ごとの様式違いへの対応を楽にしたいのか、紛失や照合の手間をなくしたいのかで、後で重視する要件が変わります。
目的が一つに絞れなくても構いませんが、どれを優先するかは決めておきます。
なお、IPAのガイドは情報システム全般の要件定義を扱う資料で、伝票や受発注に絞った内容ではありません。
同ガイドの第2版は要件定義の勘どころを128個にまとめていますが¹、ここではその考え方を伝票の業務に当てはめて整理しています。

現場担当と管理者のどちらが主体になるか

IPAのガイドは、業務部門のユーザが要件定義に主体的に関わるスタイルが求められると述べています¹。
伝票システムでいえば、業務部門には、伝票を受け取り、入力し、確認している現場担当と、その業務に責任を持ち導入を決める管理者の両方が含まれます。
どちらが主体かという問いは、実際には、それぞれが何を持ち寄るかという問いに置き換えると考えやすくなります。

現場担当が持っているのは事実です。
どの取引先がどの様式で注文書を送ってくるか、月末にどの伝票が集中するか、分納や返品のときに誰がどの書類を直しているか。
こうした例外の扱いは、マニュアルに書かれず担当者の手順として回っていることがあり、管理者が机上で整理すると抜け落ちます。

管理者が持っているのは判断です。
どの手間を優先して減らすか、費用をどこまでかけるか、取引先に様式や送り方の変更を頼むかどうか。
取引先への依頼は相手との関係に関わるため、現場担当だけでは決めにくい事柄です。

そこで、管理者が目的と優先順位を決めて最終判断を持ち、現場担当が伝票の実物と例外の事実を出して、書き上がった要件が実務と合っているかを確かめる、という分担を提案します。
どちらか一方に任せると、片方の情報が欠けた要件になりやすいからです。
導入を決める人と伝票を入力する人が同じ小さな会社なら、一人で両方の役を意識して進めることになります。

現状の伝票の種類・発行者と受け手・件数・例外を洗い出す手順

伝票を集めて種類と流れを書き出す

要件に振り分ける前に、まず現状を書き出します。
業務を思い出しながら書くより、直近1か月分ほどの伝票の実物を、紙・FAX・PDF・Excelを問わず集めて並べるほうが、漏れを見つけやすくなります。
普段は意識していない取引先独自の様式や、手書きで訂正された伝票が出てくるからです。

集めた伝票ごとに、次の点を書き出すことを提案します。

• 種類：注文書、注文請書、納品書、受領書、請求書など
• 発行する側と受け取る側：自社が出すのか、取引先から届くのか
• 届け方：FAX、メール添付、郵送、取引先が用意したWeb画面など
• 様式：自社の様式か、取引先ごとの指定様式か
• 受け取った後の作業：どのシステムやExcelへ転記し、誰が確認するか
• 保管場所：紙のファイル、共有フォルダ、メールの受信箱など

IPAのガイドは、要件を文書にまとめる際の主要な項目として、ステークホルダ（業務に関わる人や組織）、データ、業務プロセスなどを挙げています¹。
伝票に当てはめると、発行する側と受け取る側はステークホルダ、伝票に書かれた品番・数量・単価・納期はデータ、届いてから転記・確認・保管するまでの流れは業務プロセスにあたります。
上の書き出し項目はこの対応を踏まえた提案で、ガイドが伝票向けに示している一覧ではありません。
自社の伝票を並べてみて、足りない項目があれば加えてください。

たとえば、資材を卸している会社で、取引先Aは自社指定の様式の注文書をFAXで送り、取引先Bは自社で作ったExcelの注文書をメールに添付してくるとします。
受け取った担当者は、どちらも販売管理システムへ手で入力し、出荷時に納品書を発行し、月末に請求書をまとめて送っています。
書き出してみると、同じ「注文書」でも届け方も様式も違い、転記の手間がどこで生じているかが取引先ごとに分かれて見えてきます。
以降も、この会社の伝票を例に話を続けます。

1件の取引で伝票がどう行き来するかを一巡で描くと、自社がどこで受け取り、どこで発行しているかがはっきりします。
受け取る伝票は転記と照合が、発行する伝票は作成と送付が、それぞれ要件の出発点になります。

件数と例外を数える

種類と流れが分かったら、件数を数えます。
伝票の種類ごと、取引先ごとに1か月に何件あるかを数え、月末や特定の曜日に集中するかも記録します。
件数は、どの取引先から電子化を頼むかの優先順位を決めるときや、見積で利用規模を伝えるときの土台になります。

件数と同じくらい大事なのが例外です。
ここでいう例外とは、注文から請求までが一度でまっすぐ進まない取引のことで、伝票の業務では次のようなものがあります。

• 注文の変更・取消
• 分納（1件の注文を複数回に分けて納品すること）
• 返品と返品伝票の発行
• 単価や数量の訂正
• 請求書の再発行
• 取引先ごとに異なる締め日

例外を書き出すのは、通常の流れより、例外のときに誰が何をしているかのほうが担当者の工夫で回っていて、文書に残っていないことがあるからです。
先の会社で、取引先Aの注文を在庫の都合で2回に分けて出荷しているなら、納品書を2回発行し、請求書では1件の注文としてまとめる、といった処理が担当者の手順として行われているはずです。
この処理が要件に書かれていないと、導入後に「分けて納品したときの伝票が出せない」と気づくことになります。

例外は、「月に何件、誰が、どの書類をどう直しているか」の形で書いておくと、後で必須かどうかを判断する材料になります。
件数が少ない例外でも、取引先との約束や請求額に関わるものは軽く扱えません。
逆に、件数は多くても社内の確認で済んでいるものは、後回しにできる候補になります。

▼ 図の内容を文字で読む

1. 取引先が注文書を送る
2. 受注を入力し、注文請書を返す
3. 出荷して納品書を発行する
4. 取引先から受領書が返る
5. 請求書を発行し、入金を確認して次の注文へ

洗い出した内容を、機能・取引先との連携・既存システム連携・運用ルールに振り分ける

4つの要件の箱に分ける

洗い出した事実は、そのままでは要件になりません。
「取引先AはFAXで注文書を送る」という事実から、システムに何を求め、取引先に何を頼み、社内で何を決めるのかを分ける必要があります。
振り分け先として、次の4つの箱を提案します。

• 機能：伝票の作成、受け付け、照会、訂正など、新しい仕組みでできること
• 取引先とのやり取り：伝票を受け渡す形式、手段、様式
• 既存システム連携：販売管理、会計、在庫など、今使っている仕組みとのデータの受け渡し
• 運用ルール：承認、訂正、保存、権限など、社内で決める扱い方

IPAのガイドは、業務で実現したいことを扱うビジネス要求と、システムに求める仕様を扱うシステム化要求を分けて整理しています¹。
4つの箱はシステム化要求を書く側の整理ですが、各要件に「どの困り事を解くためか」を添えておくと、最初に決めた目的とのつながりが切れません。

1つの事実が、複数の箱にまたがることもあります。
先の会社の分納を例にすると、機能の箱には「1件の注文に対して、出荷ごとに納品書を発行できる」が入ります。
取引先とのやり取りの箱には「分けて納品するとき、納期の回答をどの形式で伝えるか」が入ります。
既存システム連携の箱には「分けた出荷を在庫と売上にどう反映するか」が、運用ルールの箱には「誰が分納を決め、承認するか」が入ります。
取引先AのFAX注文も同じように、受け付けの機能、電子への切り替えの相談、販売管理への受け渡し、登録と確認の担当へと分かれていきます。

箱を分けておくと、それぞれ答える相手が違うことが見えます。
機能は導入する製品の提案で、取引先とのやり取りは取引先の回答で、既存システム連携は今使っている販売管理や会計の仕様で、運用ルールは自社の判断で決まります。
すべてを一つの表にまとめて見積依頼に出すと、製品側では答えられない項目が混じり、回答がそろいません。

連携方式は製品ごとに確認する

既存システム連携の箱では、連携の方式まで要件で決めてしまわないことを勧めます。
データをファイルで受け渡すのか、システム同士を直接つなぐのかといった方式は、導入する製品や今使っている販売管理・会計の仕様、社内の環境によって変わり、一般論でどれがよいとは言えないからです。
方式は製品側の提案として答えてもらうほうが、比べやすくなります。

要件として書くのは、方式ではなく中身です。

• どのデータを渡すか（例：受注の明細、出荷の実績、請求額）
• どちら向きに渡すか（新しい仕組みから販売管理へ、など）
• いつ渡すか（受け付けた都度、1日1回、締めの後、など）
• 食い違ったときに、誰がどこで直すか

伝票の連携で見落としやすいのが、コードの対応です。
取引先が注文書に書く品番と自社の商品コードが違う場合、今は担当者が頭の中で読み替えて入力しているかもしれません。
連携すれば販売管理への打ち直しは減りますが、読み替えの対応表をどちらのシステムで持ち、誰が更新するかを決めておかないと、読み替えの作業が別の場所へ移るだけになります。

連携で減るのは転記の手間で、内容の確認がなくなるわけではありません。
単価が取り決めと合っているか、納期を受けられるかといった確認は残ります。
どの転記が減り、どの確認が残るかを要件の段階で書いておくと、導入後の業務の姿を製品の提案と照らし合わせやすくなります。

▼ 図の内容を文字で読む

• 機能
  • 分納：出荷ごとに納品書を発行できる
  • FAX注文：受け付けに登録できる
• 取引先とのやり取り
  • 分納：納期の回答をどの形式で伝えるか
  • FAX注文：電子での送付に切り替えられるか
• 既存システム連携
  • 分納：分けた出荷を在庫と売上にどう反映するか
  • FAX注文：受注の明細を販売管理へ渡す
• 運用ルール
  • 分納：誰が分納を決め、承認するか
  • FAX注文：届いた注文を誰が登録し確認するか

取引先の対応と電子取引データの保存条件が、要件をどう左右するか

取引先が電子対応できるかを先に確かめる

4つの箱のうち、取引先とのやり取りの箱は自社だけでは決まりません。
新しい仕組みで注文を電子で受け付けられるようにしても、取引先Aがこれまでどおり注文書をFAXで送ってくれば、販売管理への打ち直しは残ります。
自社が受け取る側でも発行する側でも、相手が同じ形式で応じられるかどうかで、導入して減る手間の量が変わります。

そこで、見積依頼の前に、取引量の多い取引先から順に、次の点を問い合わせておくことを提案します。

• 電子で受け取れる・送れる形式（メールのPDF、Web画面からの入力、データの受け渡しなど）
• 取引先側で使っている受発注の仕組みや、指定の様式があるか
• 切り替えに応じられる時期と、相手側の社内手続き
• 紙の伝票の控えが引き続き必要かどうか

回答によって、要件は変わります。
主な取引先の多くが電子での受け渡しに応じられるなら、注文を電子で受け付ける機能や、取引先が入力する画面が必須側に入ります。
一部の取引先だけが応じられるなら、電子で届く注文とFAXで届く注文を同じ流れで扱えることが要件になります。
ほとんどの取引先が当面は紙やFAXのままなら、受け取る側の転記は残るため、まず自社内の伝票の発行・照合・保管の電子化から始めるという範囲の取り方もあります。
取引先側に指定の仕組みや様式がある場合は、自社の仕組みから相手の形式に合わせて出力できるかが問われます。

取引先への問い合わせは相手との関係にも関わるため、管理者が判断して進める事柄です。
回答が出そろう前に製品を決めると、取引先が使わない機能に費用をかけることになりかねません。

電子取引データの保存は国税庁の資料と窓口で確認する

もう一つの外部条件が、電子で受け取ったり送ったりした伝票データの保存です。
注文書や請求書を電子でやり取りするようになると、その保存は電子帳簿保存法の制度に関わります。
国税庁の電子帳簿等保存制度特設サイトは、同法に基づく保存制度を、電子帳簿等保存、電子取引データ保存、スキャナ保存の3つの区分で案内し、区分ごとのページ、Q&A、電話相談窓口へのリンクを置いています²。

要件定義で気にかけるのは、自社の伝票がどの区分に関わるかです。
区分の名前から、おおよその入り口は見当がつきます。
メールやWeb画面で受け取った注文書や請求書のデータは電子取引データ保存、紙で受け取った伝票をスキャンして残すならスキャナ保存、自社がシステムで作成する帳簿は電子帳簿等保存の案内が手掛かりになります。
ただし、どの保存方法が求められるのか、事業の規模などによって扱いが変わるのかといった具体的な条件は、特設サイトの各区分のページやQ&Aで確かめるか、窓口で自社の状況を伝えて確認してください。
条件を読み違えると保存の設計そのものがずれるため、一般的な解説で決めずに原典に当たることが大切です。

確認した結果は、運用ルールの箱と必須要件の側に書きます。
要件は「電子で授受した注文書・請求書のデータを、自社で確認した保存条件を満たす形で保存できること」のように、確かめた条件を添えて書きます。
そうすると、製品側はどの機能でどう応えるかを具体的に回答できます。

製品が保存制度への対応をうたっていても、それだけで自社の保存が整うとは限りません。
どの伝票をどこに保存し、誰が訂正や削除を扱うのかは自社の運用として決める事柄で、製品の機能とは別に要件に書いておく必要があります。
取引先によって紙と電子が混在する期間の保管方法も、このときあわせて決めておくと、保管場所がばらばらになりません。

▼ 図の内容を文字で読む

• 多くが電子で対応できる
  • 受け付け：電子での受け付けが中心
  • 残る転記：少なくなる
  • 重視：電子受け付けの機能と取引先が入力する画面
• 一部だけ対応できる
  • 受け付け：電子とFAXが混在
  • 残る転記：対応できない取引先の分が残る
  • 重視：電子とFAXの注文を同じ流れで扱えること
• ほとんど対応できない
  • 受け付け：紙・FAXが中心
  • 残る転記：受け取る側の転記は残る
  • 重視：自社内の発行・照合・保管の電子化

必須要件と後回しにする要件の線引き

線引きの4つの基準

取引先の対応と保存条件が分かると、要件の候補はかなり出そろいます。
ただ、洗い出した要件をすべて最初の導入で満たそうとすると、費用も準備の期間も膨らみ、取引先への切り替えの依頼も一度に重なります。
そこで、最初に入れる必須の要件と、後回しにする要件を分けます。
線引きには、次の4つの基準を上から順に当てることを提案します。

1. 取引や法令の遵守に必要か
2. 取引先が受け入れる条件か
3. 現場の負担がどれだけ減るか
4. 追加の費用や運用の負担はどれほどか

1つ目に当てはまるものは、ほかの基準にかかわらず必須です。
確認した保存条件や、取引先との約束どおりに伝票を出せること、たとえば分納時の納品書や納期の回答がここに入ります。
2つ目は、取引先の回答次第で決まります。
取引先が応じない形式の機能は、作っても使われないため後回しになります。
3つ目と4つ目は、比べ合わせて判断する基準です。
毎日の注文の転記がなくなる要件と、たまに起きる例外を少し楽にする要件では、同じ費用でも重みが違います。

後回しにした要件も、見積依頼書から消さずに「後の段階で入れたい要件」として残しておくことを勧めます。
製品側に、後から追加できるのか、追加するとどの程度の作業になるのかを答えてもらえるからです。
例外の扱いは件数が少ないために後回しにされやすいのですが、1つ目の基準に当たるもの、つまり取引先へ出す伝票や請求額に関わるものは、件数が少なくても必須側に置きます。

要件の漏れが後から重くなった例

要件の漏れが導入の途中でどんな形で表れるかの例として、法人向け受発注サイトの構築事例があります。
粘着テープの製造販売を手がけ、業務用の通販サイトを運営する日東電工CSシステムは、2013年にECサイトの構築に着手し、当初は消費者向け（BtoC）のECパッケージで検討を進めました³。
ところが詳細設計の段階になって、分納時の納期回答など、企業間取引に必要な機能の多くがカスタマイズを前提とすることが分かり、追加の費用がかかる見込みになりました³。

この事例で目を留めたいのは、問題になった機能の例が分納という例外の扱いだったことです。
注文から納品までがまっすぐ進む取引だけを思い描いていると、分けて納品するときに取引先へ何を返すかは要件から抜けやすく、製品が決まって設計に入ってから差が見つかります。
洗い出しの段階で例外を数え、1つ目の基準に照らして必須側に置いていれば、パッケージを比べる時点で、標準でできるのか、カスタマイズが要るのかを問うことができます。

ただし、これはEC-Rider B2Bを導入した一社の、受発注サイト構築の事例です。
伝票の電子化全般の事例ではなく、詳細設計でカスタマイズが必要と分かったのも同社の当時の状況なので、ほかの会社で同じことが起きるとは言えません。
読み取れるのは、例外の扱いを早く要件として言葉にしておくと、製品選びの段階で確かめられる項目が増える、という点までです。

▼ 図の内容を文字で読む

1. 取引や法令の遵守に必要か
2. 取引先が受け入れる条件か
3. 現場の負担がどれだけ減るか
4. 追加の費用や運用の負担はどれほどか

要件を、製品選定や見積依頼に使える形にまとめる

見積依頼書に入れる項目

線引きを終えた要件は、製品の比較や見積依頼に使える文書にまとめます。
見積依頼書は、導入を検討している事業者が、自社の状況と求めることを製品の提供会社に伝え、見積を求めるための文書です。
提案もあわせて求める場合は提案依頼書（RFP）と呼ばれることもあります。

IPAのガイドは、要件定義の主要ドキュメントとして、データ、業務プロセス、非機能要求、運用・移行・総合テストの要求などを挙げ、その記述方法を扱っています¹。
非機能要求とは、機能そのものではなく、処理の速さ、使える時間帯、障害時の扱いなど、使い勝手や安定性に関わる要求のことです。
ガイドは見積依頼書の書式を示す資料ではありませんが、この項目の並びは、伝票システムの見積依頼書で何を書き漏らしやすいかを点検する目安になります。
なお、ガイドの掲載ページは2024年4月時点のもので、書籍の販売は2024年1月に終了しています。

ここまでの作業を踏まえ、見積依頼書には次の項目を入れることを提案します。

• 導入の目的と、減らしたい手間
• 現状の伝票：種類、発行する側と受け取る側、届け方、件数、例外
• 要件の一覧：4つの箱ごとに、必須と後回しの区分、どの困り事を解くためか
• 取引先との条件：問い合わせて分かった対応の可否と時期
• 既存システムとの連携：相手のシステム、渡すデータ、向き、時期
• 保存と運用の条件：確認した保存条件、承認や訂正の扱い
• 非機能と移行：月末などの件数の集中、取引先や商品の情報の移し替え
• 回答してほしい形式

現状の伝票の件数と例外は、具体的に書くほど、製品側が見積の前提を取り違えにくくなります。
伝票の見本を添える場合は、取引先名や金額など外に出せない情報を伏せたうえで、様式の違いが分かるものを選びます。

文書化するときの注意点

要件は、機能の名前ではなく、伝票と行為で書きます。
「分納対応」とだけ書くと、受け取った側はそれぞれの解釈で「対応できます」と答えます。
「1件の注文を2回以上に分けて出荷し、出荷ごとに納品書を発行し、請求は締め日に1件の注文としてまとめる。分ける際は取引先に納期を回答する」のように書くと、標準の機能で足りるかどうかを判断しやすくなります。

回答の形式もそろえておきます。
要件ごとに「標準機能で対応」「設定で対応」「カスタマイズで対応」「対応しない」のどれかで答えてもらい、カスタマイズの場合は費用を分けて示してもらうと、複数の提案を並べたときに差がどこにあるかが見えます。
前の節の事例のように、カスタマイズが要る項目が設計に入ってから分かる事態を、比較の段階で拾いやすくするための工夫です。

まだ決まっていない事柄は、決まっていないと書きます。
取引先の一部から回答がない、保存条件の確認が途中である、といった状態を伏せて完成した文書のように見せると、提案の前提がずれます。
未確定の項目と、いつまでに決める予定かを書いておけば、提案側もその前提を置いて答えられます。

文書ができたら、現場担当に読んでもらい、自分の業務が書かれているか、例外が抜けていないかを確かめます。
管理者が優先順位を、現場担当が事実を持つという最初の分担は、文書の最後の点検でも同じように役立ちます。

分納や取引先ごとの様式違いといった例外を、受発注の仕組みの標準でどこまで扱えるかは、伝票を洗い出しただけでは見極めにくいところです。

洗い出した伝票の流れと例外をもとに、どの要件が標準の範囲に収まり、どれが追加の検討になりそうかを一緒に確かめられます。無料相談で要件を整理する

要点の整理

軸	基準
最初に決めること	どの伝票のどの手間を減らしたいか
洗い出し	伝票の実物から、種類・発行する側と受け取る側・届け方・件数・例外を書き出す
振り分け	機能／取引先とのやり取り／既存システム連携／運用ルール
外部条件	取引先の対応可否と、国税庁の資料・窓口で確かめた保存条件
線引き	法令・取引に必要か→取引先が受け入れるか→負担の減り方→費用と運用の負担
見積依頼	伝票と行為で書き、回答形式をそろえ、未確定の項目を明記する

見積依頼書を出す前に、要件の書き方で提案側の回答がそろうかを、受発注の実務を知る相手に見てもらうと、比較の段階での食い違いを減らしやすくなります。 必須と後回しの区分や取引先との条件を踏まえて、法人向けの受発注の仕組みで実現する場合に何を確かめておくべきかを相談できます。

よくある質問

伝票の要件定義は、現場担当者と管理者のどちらが主導すべきですか。

どちらか一方ではなく、役割を分けて両方が関わる形を勧めます。
管理者は目的と優先順位、費用、取引先への依頼を判断し、現場担当は伝票の実物と例外の処理を示して、書いた要件が実務と合うかを確かめます。
導入を決める人と入力する人が同じなら、一人で両方の視点を意識して進めます。

取引先が電子でのやり取りに対応しない場合、要件はどう変わりますか。

一部の取引先だけが対応しない場合は、電子で届く注文とFAXや紙で届く注文を同じ流れで扱えることが要件になります。
ほとんどの取引先が当面対応しない場合は、受け取る側の転記は残るため、自社内の伝票の発行・照合・保管の電子化から始める範囲の取り方もあります。
取引先に頼んでも応じてもらえない形式の機能は、後回しの側に置きます。

電子で受け取った注文書や請求書のデータは、どこで保存条件を確認すればよいですか。

国税庁の電子帳簿等保存制度特設サイトが入り口になります。
同サイトは、電子帳簿等保存、電子取引データ保存、スキャナ保存の3つの区分で制度を案内し、区分ごとのページ、Q&A、電話相談窓口へのリンクを置いています²。
自社の伝票や事業の状況にどの条件が当てはまるかは、これらの資料や窓口で確かめてから要件に書いてください。

既存の基幹・会計システムがある場合、連携は要件のどこに書けばよいですか。

機能や運用ルールとは分けて、既存システム連携の項目にまとめます。
書くのは連携の方式ではなく、どのデータを、どちら向きに、いつ渡し、食い違ったときに誰がどこで直すかです。
品番と商品コードの読み替えをどちらのシステムで持つかも、ここに含めておきます。

必須要件が多すぎる場合、どの順で絞ればよいですか。

取引や法令の遵守に必要か、取引先が受け入れる条件か、現場の負担がどれだけ減るか、追加の費用や運用の負担はどれほどか、の順に当てていく方法を提案します。
1つ目に当たるものは件数が少なくても必須に残します。
後回しにした要件は消さずに見積依頼書へ残し、後から追加できるかを答えてもらいます。

見積依頼書には、現状の伝票の件数や例外をどこまで書くべきですか。

伝票の種類ごと・取引先ごとの月間件数と、月末などに集中するかどうかは書いておきます。
例外は、月に何件、誰が、どの書類をどう直しているかが分かる程度に書くと、製品側が標準で足りるかを判断しやすくなります。
取引先名や金額を伏せた伝票の見本を添えると、様式の違いも伝わります。

1. 1　出典：独立行政法人情報処理推進機構(IPA)「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年）
2. 2　出典：国税庁「電子帳簿等保存制度特設サイト」（2026年）
3. 3　出典：株式会社フライトソリューションズ「EC-Rider B2B 導入事例（日東電工CSシステム株式会社様）」