請求書のリマインダーを英語で送りたいが失礼にならないか不安になる場面は多いです。入金遅延の督促はキツすぎると関係に響きます。
そんな悩みは購買・経理で頻繁に起きるテーマです。
契約〜請求〜入金は「信頼残高の法的証拠化」のフェーズです。各段階で書き方が決まっていて、外すと法的トラブルにつながります。
本記事ではRFI〜請求〜入金までの全フローを段階別に整理します。
B2B取引の全フロー
B2B取引には決まったフローがあります。各ステップでメールの種類と書き方が変わります。
RFI → RFP → Quote → PO → Invoice → Payment
B2B取引の標準フローは6段階です。RFI（情報依頼）、RFP（提案依頼書）、Quote（見積もり）、PO（発注書）、Invoice（請求書）、Payment（入金）の順です。
各段階の所要期間は業界によって変動します。SaaS系は2-4週間、製造業は2-6ヶ月が目安です。
段階を飛ばすと後で法的トラブルになります。特にPOなしの発注は紛争の温床です。
各ステップのメール種別
RFIは情報収集、RFPは比較評価、Quoteは価格確定、POは発注確定、Invoiceは支払要求、Paymentは決済です。
各ステップで件名のフォーマットも変わります。「RFI – [項目]」「RFP Response Required」「Invoice #12345」。
件名で段階が一目で分かる形にすると相手の処理が速くなります。
承認プロセス（Procurement/Finance）
大企業ではProcurement（購買部）とFinance（経理部）の承認が別プロセスです。
Procurementはベンダー選定、Financeは支払い承認を担当します。
どちらかが滞ると全体が止まります。両部署への並行コミュニケーションが必要です。
情報依頼（RFI）メール
RFIは取引前の情報収集段階です。複数ベンダーへの同時依頼が前提です。
開放型質問と選択肢型質問
RFIには2種類の質問形式があります。開放型は自由記述、選択肢型はチェックボックスです。
開放型は「Please describe your approach to [topic]」で広く聞きます。回答の幅が大きくなります。
選択肢型は「Do you offer [feature]? Yes/No」で定量比較しやすくします。
複数ベンダー同時依頼の明示
RFIでは複数ベンダーへの同時依頼を明示します。「We are evaluating multiple vendors for this initiative」。
隠さないのがビジネスマナーです。相手も競争を知った上で回答します。
「This RFI will inform our shortlist of 3 vendors for the RFP stage」のように次のステップも明示します。
回答期限と評価基準
回答期限は2-4週間が標準です。「Please submit responses by 2026/04/28」で明記します。
評価基準も事前に共有します。「Key evaluation criteria: [list]」。
透明性の高いRFIのほうが良質な回答が集まります。
提案依頼書（RFP）メール
RFPはRFI後の具体提案依頼です。要件が明確化した段階で発出します。
要件サマリの添付
RFPには要件サマリをPDFで添付します。本文は概要と期限のみです。
要件は機能要件、非機能要件、運用要件の3分類で整理します。
曖昧な要件は提案の質を下げます。「Vague requirements get vague proposals」は業界の格言です。
提案フォーマット指定
提案フォーマットを指定すると比較が容易になります。「Please submit your response using the attached template」。
自由フォーマットだと各社の形式がバラバラで評価不能になります。
ページ数制限も有効です。「Maximum 20 pages」で無駄な膨らみを防ぎます。
Q&A期間の設計
RFP発出後1-2週間はQ&A期間です。ベンダーからの質問を受け付けます。
質問は全ベンダーに共有します。「All questions and answers will be shared with all participating vendors」。
一社だけに回答すると不公平です。Fair Processの原則を守ります。
見積もり依頼（Quote Request）
ベンダー選定後、具体案件の見積もり依頼です。金額・納期・条件の3点が核です。
数量・納期・仕様の明示
見積もり依頼では数量・納期・仕様を必ず明示します。3つのうち1つでも欠けると正確な見積もりは出ません。
「Quantity: 500 units. Delivery: by end of Q2. Specifications: attached document」。
曖昧な依頼は安く見えても後で追加請求が発生します。
オプションの出し方依頼
オプションを依頼するとベンダーの提案力が見えます。「Please propose 3 options: basic, standard, premium」。
オプション比較で価値と価格のバランスが可視化されます。
ベンダーも得意な構成を提案しやすくなり、双方にメリットがあります。
有効期限の確認
見積もりには有効期限があります。「Quote valid until 2026/04/28」を必ず確認します。
期限後に発注すると再見積もりになり、価格が変わることがあります。
「Can we extend the validity by 2 weeks?」で延長依頼も可能です。
発注書（Purchase Order）発行メール
POは正式な発注の書面です。POなしの発注は無効とする企業が多数です。
PO番号の整合
PO番号は全書類で整合させます。PO・Invoice・Delivery Noteで同じ番号を使います。
「Please reference PO# [number] on all related documentation」。
番号不整合は経理処理で弾かれます。入金遅延の原因になります。
納品先・請求先の分離
納品先（Ship To）と請求先（Bill To）は分離することが多いです。大企業の購買では別住所です。
「Ship To: [warehouse address]. Bill To: [finance department address]」で明示します。
混同すると納品後の請求で混乱します。
支払条件（Net 30/60）
支払条件はNet 30が国際標準です。Invoice発行から30日以内の支払いを意味します。
Net 60は60日、Net 90は90日です。大企業ほど長い条件を要求する傾向があります。
2% 10 Net 30は「10日以内支払いで2%割引、そうでなければ30日以内」の意味です。
契約書ドラフト送付メール
契約書は法的拘束力を持つ重要書面です。送付時のメールも慎重に書きます。
Redline対応のお願い
契約書ドラフト送付時は修正履歴（Redline）対応を依頼します。「Please share any redlines using track changes」。
Word形式のtrack changesが標準です。PDFでのコメントは避けます。
修正箇所が明確になり、双方の弁護士が確認しやすくなります。
レビュー期限の設定
契約書レビューには期限を設定します。「Kindly return your review within 10 business days」。
法務レビューは通常5-10営業日かかります。緊急でも最短3営業日は必要です。
期限なしのレビュー依頼は永遠に戻ってこないことがあります。
法務レビューを待つ時の応答
相手側の法務レビュー待ちの時の応答もパターン化できます。「Thanks for the update. I will follow up on 2026/04/28 if I haven’t heard back」。
催促は1週間ごとにします。「Gentle check-in on the contract status」。
2週間以上待っても返答なければエスカレーションです。
NDA（守秘義務契約）関連メール
NDAは商談前の必須書類です。種類と対応の違いを理解します。
相互NDA・一方NDAの判別
NDAには相互NDA（Mutual NDA）と一方NDA（One-way NDA）があります。
相互NDAは双方が情報保護義務を負います。一方NDAは片方のみです。
ほとんどのB2Bシーンでは相互NDAが適切です。「We prefer a mutual NDA given the nature of discussions」。
Jurisdiction（準拠法）の主張
NDAにはJurisdiction（準拠法）の条項があります。「この契約はどの国の法律に従うか」の指定です。
日本企業は日本法、米国企業はニューヨーク州法やデラウェア州法を主張するのが一般的です。
第三国（シンガポールなど）を中立地として選ぶこともあります。
NDA締結後のKick-off流れ
NDA締結後は本格的な商談キックオフです。「NDA executed. Scheduling our first working session for 2026/04/28」。
NDA下で共有される情報は明示します。「The following information is shared under NDA terms」。
秘密情報の範囲が曖昧だと後で紛争になります。
契約修正（Amendment）メール
契約後にスコープや条件が変わる場合、Amendment（修正契約書）を作ります。
修正範囲の明確化
修正範囲を冒頭で明確にします。「This amendment modifies Sections 3.1 and 5.2 of the original agreement dated 2026/04/28」。
原契約書への参照を必ず含めます。スタンドアロン文書として扱うとトラブルになります。
変更前と変更後を並記します。透明性が法的保護の基盤です。
影響する条文の列挙
影響する条文を列挙します。主条項だけでなく、参照関係にある条項も確認します。
「Amendment affects: Section 3.1 (pricing), Section 5.2 (payment terms), and related clauses in Annex A」。
漏れがあると修正後の契約書に矛盾が生じます。
署名スケジュール
Amendmentも署名が必要です。「Signature target: 2026/04/28. DocuSign will be sent upon final review」。
署名なしのamendmentは無効です。口頭合意だけで運用するのは危険です。
電子署名が国際的に普及しています。DocuSign、Adobe Sign、HelloSignが主要です。
請求書送付メール
請求書送付メールは簡潔が美徳です。本文は短く、PDFに詳細が入ります。
Invoice番号・PO番号の対応表
Invoice番号とPO番号を対応させます。「Invoice #12345 (PO# 67890)」で件名に含めます。
経理部はこの番号で処理します。番号なしの請求書は処理が遅れます。
月次まとめ請求の場合は複数POを対応表で示します。
支払方法（Wire Transfer/ACH/Card）
支払方法を明示します。Wire Transfer（電信送金）、ACH（米国内送金）、Credit Cardの3つが主要です。
国際送金はWire Transferが標準です。SWIFTコード、IBANを記載します。
「Payment instructions attached」で銀行情報を別紙に分離することも多いです。
VAT・TAXの処理
VAT（付加価値税）やその他税金の処理を明示します。「VAT: 10% included」または「Excluding VAT」。
国際取引では源泉徴収税（Withholding Tax）も関係します。租税条約の確認が必要です。
不明瞭な税金処理は後で経理部から問い合わせが来ます。最初から明示するのが効率的です。
入金確認メール
入金確認と入金遅延の対応はパターン化できます。トーン設計が重要です。
入金遅延時の最初の催促
入金遅延の最初の催促は柔らかいトーンで送ります。「Just a friendly reminder: Invoice #12345 was due on 2026/04/28」。
「Just checking if the invoice might have been overlooked」で相手の面子を立てます。
即座に厳しくすると関係が悪化します。最初は必ずソフトタッチです。
3段階の督促エスカレーション
督促は3段階でエスカレートします。1回目は柔らか、2回目は正式、3回目は法的警告です。
2回目は「Formal reminder: payment overdue by [days]. Please advise when we can expect settlement」。
3回目は「Final notice: further delay may result in interest charges and potential legal action」。
法的措置予告の書き方
法的措置予告は最終段階です。「If payment is not received by 2026/04/28, we will proceed with legal collection through our counsel」。
法的措置は本気の決意を示すメールです。勢いで書くと信用を失います。
送る前に上司・法務への相談が必須です。
支払遅延への謝罪メール（受取側）
自社が支払遅延する側の場合もあります。誠実な対応で信頼を保ちます。
遅延の理由開示範囲
遅延理由の開示範囲は慎重に決めます。内部事情の詳細は不要です。
「Due to internal processing delays, the payment will be made on [new date]」で十分です。
「資金繰りが悪い」のような弱さの開示は信用リスクになります。
新支払日のコミット
新支払日を明確にコミットします。「Payment confirmed for [specific date]」。
曖昧な「next week」「soon」は信頼をさらに失います。
コミット後に再遅延すると関係が終わります。確実に払える日付を設定します。
再発防止策の提示
再発防止策を提示すると信頼回復が早まります。「We have implemented new approval workflow to prevent recurrence」。
組織としての対応を示すことで「個人のミス」以上の対策感が出ます。
プロセス改善の具体内容を1-2文で補足します。
契約更新・終了メール
契約は終わりがあります。更新と終了の手続きメールを押さえます。
Auto-renewal通知
Auto-renewal（自動更新）付き契約は通知期限に注意します。「This contract will auto-renew on 2026/04/28 unless terminated 30 days prior」。
通知期限を過ぎると自動的に1年延長されます。
更新しない場合は期限内にTermination Noticeを送ります。
解約通知期限の管理
解約通知期限はカレンダー管理が必須です。90日前通知、60日前通知、30日前通知と契約によって違います。
「Pursuant to Section X, we hereby provide notice of termination effective 2026/04/28」。
フォーマルな書面が求められます。メール+PDFの両方送付が確実です。
データ返却・削除の要請
契約終了時にデータ返却・削除を要請します。「Please return or destroy all confidential data upon termination」。
GDPRやCCPA下では削除証明書（Certificate of Destruction）が求められる場合もあります。
90日の返却猶予期間が一般的です。期限内に対応されないとコンプライアンス違反です。
契約文書のAI翻訳禁忌
契約文書はAI翻訳で処理してはいけない領域です。法的意味が変わるリスクがあります。
法的意味が変わる語（shall vs will）
契約用語では類似単語でも法的意味が違います。「shall」「will」「may」「must」は全て意味が異なります。
「shall」は義務、「will」は意志、「may」は許可、「must」は強制です。
AI翻訳は文脈で使い分けません。契約意図を誤って翻訳するリスクがあります。
固有名詞の自動翻訳回避
会社名・人名・住所などの固有名詞をAIに翻訳させると誤訳が発生します。
「Apple Inc.」が「アップル社」になったり、住所が意味不明になったりします。
契約書の固有名詞は原文のまま保持するのが原則です。
弁護士チェックが必要な場面
法的リスクが高い条項は弁護士チェックが必須です。損害賠償、知的財産権、準拠法、紛争解決条項が代表です。
AIで下訳を作ることは可能ですが、最終版は必ず弁護士が確認します。
10万円の弁護士費用で100万円のリスクを防げるなら安い投資です。
