CRMの複数通貨・為替レート管理｜商談金額と予測をずらさない運用
海外拠点や外貨建て商談をCRMで扱い始めると、同じ案件でも担当者の画面、営業会議の予測、経営ダッシュボード、会計システムで金額が一致しないことがあります。原因は単純な計算ミスだけではありません。レコード通貨、基準通貨、利用者の表示通貨、為替レートの有効日、丸め方、連携先の換算責任が混ざると、正しい数字が画面ごとに変わってしまいます。
結論から言うと、CRMの複数通貨は、通貨を追加する前に「原通貨」「基準通貨」「換算レート」「有効日」「換算後金額」の責任を分けて設計します。 現在レートを使う売上予測と、特定日のレートを残す確定実績を同じ列で扱わず、レートの出所、更新頻度、承認者、適用開始日時、再計算範囲、丸め規則を台帳化します。更新後はCRMだけでなく、予測、BI、見積、ERPの代表金額まで同じ案件IDで照合してください。
本記事のポイント
- 商談の原通貨と金額は履歴として残し、基準通貨への換算値や表示通貨と分けて管理します。
- 売上予測には現在レート、確定実績には日付付きレートなど、用途ごとにレート種別と有効日を固定します。
- レート変更は、経理方針の承認、影響試算、検証環境、段階反映、CRM・BI・ERP照合、変更証跡まで一つの作業として閉じます。
CRMの金額を4つの役割に分ける
複数通貨の設計で最初に行うのは、換算式を作ることではなく、各金額が何を表すかを分けることです。たとえば「100,000」という値だけでは、米ドルなのか円なのか、入力時の金額なのか現在レートで換算された集計値なのかを説明できません。通貨コードを金額と常に組にし、原通貨の記録と換算後の分析値を別の役割として扱います。
| 役割 | 意味 | 主な利用先 | 変更時の注意 |
|---|---|---|---|
| 取引・レコード通貨 | 顧客との見積や商談で使う原通貨 | 商談、見積、受注、請求連携 | 金額とISO通貨コードを履歴として残す |
| 企業・基準通貨 | 複数通貨を比較・集計する共通軸 | 経営レポート、パイプライン、予実 | 導入後の変更は広い再計算と移行を伴う |
| 表示通貨 | 利用者や会議で見やすく表示する通貨 | 担当者画面、地域別ダッシュボード | 表示が変わっても原通貨を書き換えない |
| 会計・契約上の換算値 | 会計方針や契約条件で確定する金額 | ERP、請求、決算、収益認識 | CRMの参考換算を会計正本にしない |
Salesforceの複数通貨に関する公式資料では、企業通貨を換算の基準とし、レコードごとに通貨を持ち、利用者には個人通貨で換算表示できる仕組みが説明されています。Microsoft DataverseのTransaction Currency公式資料も、各レコードの取引通貨と組織の基準通貨を分け、金額項目ごとに基準通貨換算の読み取り専用列を自動生成します。製品名は違っても、原通貨と共通集計軸を分ける点は共通しています。
ただし、換算レートの定義方向は製品や連携先で異なります。あるシステムは「外貨1単位が基準通貨でいくらか」を掛け、別のシステムは「基準通貨1単位が外貨でいくらか」を保持して割ります。列名だけで判断せず、既知の少額サンプルを使って、原通貨金額、レート、基準通貨金額の3点を実測してください。通貨の表示記号だけでは米ドル、カナダドル、豪ドルなどを区別できないため、API・CSV・レポートではISO 4217の通貨コードを使います。
複数通貨の有効化前には、対象通貨、企業・基準通貨、各利用者の既定通貨、レコード作成時の通貨継承、商品価格表、見積・受注・請求への連携、少数桁、端数処理を決めます。Salesforceでは複数通貨の有効化が組織へ恒久的な変更を加えると案内されており、Dataverseでも基準通貨は環境の集計基盤になります。設定画面で試す前に、テスト環境で既存レポート、数式、承認条件、API、CSV出力まで確認してください。
現在レートと日付付きレートを用途別に使い分ける
為替レートは一つの最新値だけでは足りません。営業会議で来月のパイプラインを現在の相場感で見たい場合と、3か月前に成約した商談を当時のレートで再現したい場合では、正しいレートが違います。さらに、見積で顧客へ約束した固定レートや、会計システムで使う月末レートが別に存在することもあります。
| 用途 | 候補となるレート | 有効日の基準 | 主な確認先 |
|---|---|---|---|
| 進行中商談・売上予測 | 現在レートまたは社内予算レート | 予測更新日・会議基準日 | CRM予測、営業会議、経営ダッシュボード |
| 確定商談の再現 | 日付付きレート | 成約日、クローズ日、社内確定日 | 実績レポート、差異分析 |
| 見積・契約 | 顧客へ提示した固定レート | 見積有効期間・契約条件 | 見積書、受注、請求条件 |
| 会計・決算 | 経理方針で承認したレート | 取引日、月末、決算日など | ERP、会計帳簿、監査証跡 |
SalesforceのAdvanced Currency Managementは、開始日を持つ日付付きレートを商談や関連オブジェクトへ適用し、商談のClose Dateに応じて換算値を変えます。一方、公式資料は、日付付きレートが予測、他オブジェクトの通貨項目、対象外レポートには使われないことも明記しています。Salesforce Forecastingの複数通貨に関する注意事項では、予測は日付付きレートを使わず、レート変更が過去・現在・将来の予測期間へ影響すると説明されています。日付付きレートを有効にしただけで、すべての画面が過去レートへ統一されるわけではありません。
Microsoft Dataverseはレコードに取引通貨と交換レートを持ち、各Money列に対応する基準通貨列を計算します。ここでも、CRM内の基準通貨換算が請求や会計の確定値と同じとは限りません。会計上の換算は対象取引、認識日、会社の会計方針に従う必要があるため、CRMでは「営業判断に使う換算」と「ERPから戻る確定換算」を別項目・別ステータスで保持すると安全です。
レートの出所も用途とセットで決めます。日本銀行は外国為替市況を営業日ごとに公表していますが、公式ページには訂正の可能性があることも記載されています。公的な参考値であっても、自社の見積、予測、会計へそのまま使えるとは限りません。銀行、ERP、レート配信サービス、公的統計のどれを採用するか、時点、bid・ask・仲値、休業日の扱い、訂正時の再処理を経理方針として承認します。
為替レートを7段階で安全に更新する
更新頻度に万能な正解はありません。日次で意思決定するグローバル営業なら毎営業日、月次管理が中心なら月初・月末、予算管理なら四半期の固定レートなど、数字を使う会議と許容差から決めます。重要なのは、頻度より「いつの値を、誰が、何に適用したか」を再現できることです。
- 方針を固定する：対象通貨、レート種別、情報源、取得時刻、休業日、訂正、丸め、許容差、適用対象を経理・Sales Ops・CRM管理者で合意します。
- 現行値を退避する：通貨コード、レート、開始日、取得元、登録者、登録時刻をエクスポートし、更新前の代表商談と集計結果を保存します。
- 入力を検証する：同一通貨の重複、ゼロ・負値、桁数、レート方向、前回比、欠損通貨を自動チェックし、閾値超過は人が確認します。
- 影響を試算する：未決商談、確定商談、今期予測、地域別レポート、見積、BI、ERP連携について、変更前後の差額と差率を算出します。
- 検証環境で反映する：少額・高額、正負、複数通貨、異なるClose Date、端数が出る金額を使い、画面・API・CSV・レポートを同じ案件IDで照合します。
- 承認後に本番へ反映する：作業者と承認者を分け、適用開始日時を記録し、連携バッチや予測再計算が完了するまで変更を重ねません。
- 差分を監視して閉じる：CRM、予測、BI、ERPの合計と代表案件を照合し、許容差、エラー件数、未処理連携が基準内になった時点で完了とします。
大きなレート変動だけを承認対象にすると、通貨の追加、開始日の誤り、方向の逆転、桁違いを見逃します。通常更新は自動検証し、前回比が閾値を超える、過去日へ遡る、対象通貨が増減する、予測総額への影響が一定額を超える、といった例外だけを承認へ回すと運用を止めにくくなります。例外承認の設計はCRM承認フローの作り方で扱っている「通常は流し、例外だけ止める」考え方と同じです。
大量のレートをAPIやCSVで更新する場合も、上書きだけで終わらせません。Salesforceは日付付きレートをDatedConversionRateとしてData Loaderから一括更新できる公式手順を提供していますが、成功・失敗ファイルの確認や開始日の扱いが必要です。入力ファイルのハッシュ、実行ID、成功件数、失敗件数、再実行対象を残し、同じ開始日の二重登録や一部通貨だけ古い状態を防ぎます。
商談金額・売上予測・BIのずれを検知する
レート更新が成功したかは、管理画面に新しい数字が見えるだけでは判断できません。複数通貨運用の完了は、CRMの商談合計、売上予測、BI、ERP連携の代表金額を同じ案件IDと基準日で説明できた時です。
| 検知項目 | 比較方法 | 主な原因 | 対応 |
|---|---|---|---|
| 原通貨金額の変化 | 更新前後で金額・通貨コードを完全一致 | 換算値で原通貨を上書き | 原通貨を復元し、換算列を分離 |
| 基準通貨合計の急変 | 通貨別・ステージ別に差額と差率を算出 | レート方向、桁、開始日の誤り | 該当レートを停止し影響範囲を再計算 |
| 確定商談の再評価 | Close Date別に前回値と比較 | 現在レートと日付付きレートの混在 | 実績用と予測用のレートを分ける |
| CRMとBIの差 | 案件ID・基準日・通貨コードで突合 | 抽出時刻、キャッシュ、独自換算 | 換算責任を一方へ寄せ再取込 |
| CRMとERPの差 | 見積・受注・請求IDで照合 | 会計レートと営業レートの違い | 差異を仕様として分離し確定値を戻す |
監視指標には、通貨別未決商談額、基準通貨換算額、前回更新からの差率、レート未設定レコード数、更新日が古い通貨数、BIとの差額、ERPとの差額、丸め差の最大値を置きます。全体合計だけでは、大きな通貨の増減が小さな通貨の異常を相殺するため、通貨コード、地域、ステージ、Close Dateの期間で分解します。
売上予測の精度はレートだけで決まりません。案件金額、ステージ、Close Date、次アクションが更新されていないと、換算だけ正しくても予測は外れます。案件衛生の確認はパイプライン管理AIと案件衛生、活動・案件・受注後データをつないだ判断はRevenue Intelligenceのデータ設計とあわせて行うと、為替差と案件更新漏れを分けて調べられます。
BI側で独自にレートを当てる場合は、CRMと同じレートテーブルを同期するか、換算済み基準通貨金額とレートIDを受け取ります。CRMから原通貨だけを渡し、BIが別の情報源・別時点で換算すると、両方が仕様どおりでも金額は一致しません。データ契約には、原通貨、基準通貨、レート値、レートID、レート種別、有効日、換算日時、丸め後金額を含めます。
既存データ移行と切り戻しを先に設計する
単一通貨のCRMへ複数通貨を追加するときは、既存レコードがどの通貨で入力されていたかを確定します。過去に海外案件も円換算で入力していたなら、後から通貨コードだけ米ドルへ変えることはできません。元の契約・見積・請求、当時のレート、入力ルールを確認し、復元できない値は推定値として別フラグを持たせます。
移行前に、既存商談、商品価格表、見積、受注、ワークフロー、承認条件、数式、API、CSV、BI、ERPの依存先を棚卸しします。移行の全体手順はCRM乗り換え前の失敗チェックリストも使えます。通貨変更では特に、金額項目だけでなく、しきい値条件、割引承認、スコアリング、目標、予算、重複する換算ロジックを確認してください。
切り戻しでは、画面上のレートだけを戻しても、すでに再計算された予測、BI抽出、見積出力、ERP連携が元へ戻らないことがあります。変更前レートと開始日を保存し、停止する連携、再計算する対象、再出力が必要な帳票、顧客連絡が必要な見積を一覧化します。問題発生時は新規更新を止め、影響案件を固定し、CRM、BI、ERPを同じ基準時刻へ戻してから連携を再開します。
MicrosoftのDataverse基準通貨変更ガイドも、変更前のバックアップ、過去データ期間を覆う履歴レート、変換ジョブの監視を求めています。基準通貨の変更は通常のレート更新より影響が大きいため、別プロジェクトとして扱い、CRM管理者だけで実行しないでください。
よくある質問
CRMで複数通貨を有効にする前に何を決めますか？
対象通貨、企業・基準通貨、レコード通貨の既定値、利用者の表示通貨、商品価格表、換算レートの出所と方向、有効日、少数桁、丸め、見積・BI・ERP連携を決めます。既存レポート、数式、承認、APIへの影響もテスト環境で確認します。
為替レートは誰がどの頻度で更新しますか？
経理・財務が情報源、用途、頻度、許容差を承認し、CRM管理者または連携ジョブが反映し、Sales Opsとデータ担当が予測・BIを照合する分担が基本です。頻度は日次、月次、四半期固定など、意思決定の周期と重要性に合わせます。
レートを変えると過去の商談金額も変わりますか？
製品と機能によります。Salesforceの通常レートは閉じた商談を含む換算表示へ影響しますが、Advanced Currency Managementの日付付きレートはClose Dateに応じて対象商談を換算します。一方、予測では日付付きレートを使わないなど対象差があります。自社環境の代表レコードで必ず実測してください。
過去レートと現在レートはどう使い分けますか？
進行中パイプラインや現在の経営判断には現在レートまたは予算レート、確定実績の再現には成約日などにひも付く日付付きレートを使います。見積固定レートや会計レートは別の目的なので、同じ列へ上書きしません。
CRMの換算金額を会計にも使えますか？
そのまま会計正本にするのは避けます。CRMの換算は営業予測や比較のための参考値であることが多く、会計では取引日、月末、決算日など会社の方針に沿ったレートが必要です。ERPで確定した金額と使用レートをCRMへ戻し、差異を説明できるようにします。
丸め差はどこまで許容しますか？
通貨の小数桁、単価・明細・合計のどこで丸めるか、四捨五入・切り捨てなどの方式を先に決めます。CRM、見積、BI、ERPで同じ順序にできない場合は、明細差と合計差の許容値を定義し、超過だけを例外として調査します。
関連ページと関連記事
複数通貨の換算だけでなく、案件データ、承認、移行、予測レビューを同じ運用へつなげると、レート変更後の数字を説明しやすくなります。
- CRM承認フローの作り方：通常更新と例外承認を分ける考え方を確認できます。
- パイプライン管理AIとは：予測を崩す更新漏れや停滞案件を見つける方法を整理しています。
- Revenue Intelligenceとは：案件、活動、実績をつないで売上判断へ使うデータ層を確認できます。
- CRM乗り換え前の失敗チェックリスト：既存金額・連携・レポートの移行範囲を整理できます。
CRM・売上予測の数字をそろえたい場合
複数通貨、売上予測、BI、ERPの換算責任が分かれている場合は、画面設定だけでなく、データ項目、承認、連携、照合指標を一つの運用として整理する必要があります。ファネルAiでは、CRM/SFAの要件整理、データ設計、Sales Opsの運用設計、連携ルールの見直しを支援しています。
参照した公式情報
- Salesforce Help：Manage Multiple Currencies
- Salesforce Help：Considerations for Enabling Multiple Currencies
- Salesforce Help：About Advanced Currency Management
- Salesforce Help：Considerations for Multiple Currencies in Salesforce Forecasting
- Microsoft Learn：Transaction Currency table
- Microsoft Learn：Using currency columns
- 日本銀行：外国為替市況（日次）
