回収（Advanced Collections）と請求書管理（Bill Management）

Advanced Collections は「延滞の特定 → 督促（Dunning）または回収戦略 → 回収者の作業（支払約束・紛争・入金）」の流れです。公式ドキュメントでは、延滞の管理に督促と回収戦略はどちらか一方を使い、併用しないとされています（26C）
回収者は従業員（HCM の担当者）を Collectors に設定し、顧客プロファイルで割り当てます。作業領域には、自分（または自分のグループ）が担当する顧客だけが出ます
督促の方式は 2 つです。Aged は最も古い延滞取引のエイジング区分、Staged は前回の督促状からの日数で文面を進めます
戦略は「タスク → 戦略 → 回収方法名 → タスクの割当」の順に作り、スコアリングの結果で顧客・アカウント・請求先サイトに割り当てます
Bill Management は顧客自身が請求書の参照・支払・紛争の確認を行うポータルです。設定の中心は Manage Bill Management System Options と、外部ユーザーの登録です

全体像

請求・入金（AR）→ 期日超過 → 延滞の特定（Delinquency Identification）
        ├─ 督促（Dunning）：Aged または Staged → 督促状（メール・FAX・印刷）
        └─ 回収戦略（Strategy）：スコアリング → 戦略の割当 → タスク（手動・自動）
                    ↓
回収者の作業（Advanced Collections 作業領域）：電話・支払約束・紛争・修正・入金
                    ↓
解消（入金・クレジットメモ）／エスカレーション

顧客側：Bill Management（請求書の参照・ダウンロード、オンライン支払、紛争の確認）

Receivables 本体（請求・入金）との役割分担は次のとおりです。入金の消込やクレジットメモの作成は入金と請求の機能で、Collections は「延滞した債権を誰が・いつ・どう追うか」を管理します。

使用する組織と設定の持ち方

設定対象	持ち方	ポイント
回収者（Collectors）	従業員を回収者に設定。作業領域の前提として「必要なセットに対して回収者として設定する」と記載されている	回収者は HCM の従業員として登録されている必要がある
顧客プロファイル	顧客アカウントまたはサイトのプロファイル（Profile タブ）	回収者・督促の設定を持つ。担当の顧客がここで決まる
回収の設定（Preferences）	設定セット（Preference set）単位	回収の業務レベル（Collections business level）などを持つ
Bill Management の設定	システムオプション（全体）と BU ごとの Preferences	支払方法の許可を BU ごとに制御できる
内部ユーザーのデータアクセス	Manage Data Access for Users	BU のデータにアクセスするジョブロールの割当

回収を顧客・アカウント・請求先サイトなどのどの単位で行うかは、回収の設定の業務レベル（Collections business level）や督促の設定で決めます（選べる単位は公式ドキュメントで確認）。日本企業では「請求先（請求先サイト）単位で締め請求を行い、督促も同じ単位で行う」設計が分かりやすく、残高繰越請求（請求）と回収の単位をそろえると、督促状の金額と請求書の金額が食い違いにくくなります。

回収の設定の順序

公式ガイドの「Define Advanced Collections Configuration」は、次の順で構成されています（20B 版の目次で確認）。

順	設定	内容
1	Manage Collections Preferences	作業領域の表示、回収者の既定値、督促のメール、支払約束の規則
2	Manage Aging Methods	エイジングの区分（方法）の定義
3	Manage Collectors	回収者と回収者グループ
4	Manage Dunning Configuration	Aged／Staged の督促、レター、送付方法
5	Define Scoring	スコアリング式とデータポイント
6	Define Strategy	回収戦略とタスク
7	Manage Collections Scoring and Strategy Assignments	スコア・セグメントごとの戦略の割当

回収者を使う前に、従業員、Receivables、Payments、セキュリティ、メモ、タスク、BI Publisher の準備が必要です（同じ章の冒頭で挙げられている前提）。

設定（Manage Collections Preferences）の主な項目

区分	主な項目
グローバル設定	既定の取引クラス、未決済・クローズ済み取引の表示、表示する日数、既定のエイジング方法、取引属性の更新可否、メール送付、督促状 1 通あたりの最大取引数、支払約束が破綻するまでの猶予日数の上限、支払約束の期日の最大日数、指標計算の共通通貨、破産（Enable bankruptcy）の有効化、並列処理数、バッチサイズ
設定セット	回収の業務レベル、貸方の要約またはエイジング、既定の換算レート、督促の送付方法、宛先が不明な督促の既定の連絡先
通知（Correspondence）	紛争・入金・支払約束の通知の送付可否とテンプレート

グローバル設定は、回収者が使う顧客作業領域とダッシュボードの見え方に効きます。

回収者（Collectors）

回収者は従業員として登録された人を設定します。回収者のグループは Manage Resources で作ります（20B 版の目次）
顧客プロファイルの回収者に割り当てると、その顧客が担当者の作業領域に出ます。ダッシュボードの数値が出ないときは、従業員の登録と、Profile タブの回収者の割当を最初に確認します
回収者の分類などを増やしたい場合は、Collectors の付加フレックスフィールド（DFF）を使います

督促（Dunning）

できること

事前定義またはカスタムの督促状を、メール・FAX・印刷で自動送付する
顧客プロファイルの設定で、督促の対象から外す
督促後の電話や通知のフォローを、回収者に割り当てる
督促の履歴と、再送した督促状を記録・参照する

督促状の送付に必要な情報

情報	内容
Dunning Contact	宛先の担当者。不明な顧客には既定の連絡先を使う
Dunning Address	メールアドレス、FAX 番号、住所
Dunning Template	催促の強さに合わせた文面
Dunning Method	印刷・FAX・メールの送付方法
BI Publisher	督促状の生成（テンプレートとデータモデル）

Aged と Staged の違い

観点	Aged（エイジング方式）	Staged（段階方式）
起点	最も古い延滞取引が入っているエイジング区分	前回の督促状を送ってからの日数
文面の進み方	古い取引が次の区分に進むと文面が変わる。テンプレートはエイジング区分に関連付ける	督促の設定（Dunning Configuration）で決めた間隔で次の段階に進む
共通	延滞取引は Delinquency Identification の処理で自動的に特定される。顧客・アカウント・請求先サイトの単位で設定できる。複数の延滞取引を 1 通にまとめて送れる	同左

メール本文は、設定のメール本文（Email Body）にテンプレートを選んで作ります。書式付きの本文を使う場合、カスタムのデータモデルを使っているなら、事前定義の Collections Send Dunning Letters データモデルに置き換える必要があります
督促がエラーで終わったときは、BI Publisher サーバーの設定、顧客の Profile タブの情報、Validate Customer Dunning Setup Report（顧客の督促設定の不備を一覧する）を確認します

回収戦略（Collections Strategy）とスコアリング

戦略の考え方

戦略は、手動または自動のタスクを実行順に並べたものです。タスクの例は、顧客への電話、レター・FAX・メールの送付、上長へのエスカレーション（エスカレーションすると、マネージャーに通知が自動で届く）です。タスクは再利用できます。

タスク（Collections Strategy Tasks）を作る
戦略（Collections Strategies）を作る
回収方法名（collections method name）を割り当てる
戦略にタスクを割り当てる

戦略は、顧客・アカウント・請求先サイトのうち、取引の単位に合わせたレベルで関連付けられます。割当はスコアリングエンジンの結果で決まります。スコアリングエンジンは延滞取引を特定し、延滞の対象をスコア付けします。

スコアリングと戦略の割当

スコアリング式（Scoring Formulas）とデータポイントを定義し、スコアの範囲やセグメントごとに戦略を割り当てます
延滞後の戦略（Delinquent）と、延滞前の戦略（Predelinquent）は、別々にセグメントごとの割当を定義します
割当は、スケジュール済プロセスの Collections Scoring and Strategy Assignment で実行します
戦略のタスクは Oracle SOA（BPEL）が開始・管理して担当者に通知し、通信文書は BI Publisher が送付します

回収者の作業：Advanced Collections 作業領域

作業領域（Collections）には、回収者向けのインフォタイルが並びます（26A）。

インフォタイル	できること
Delinquent Customers	担当の延滞顧客を回収レベル順などで確認し、顧客情報を開く。Transaction タブで紛争・修正・支払約束の作成や、入金の処理を行う
Promises	破綻した約束・未履行の約束を、ステータス・日付・金額で確認する
Strategy Tasks	手動または割り当てられたタスクの件数と期日を確認する
Activities	至急対応が必要な活動を作成・参照・編集する

ダッシュボードの数値を更新するジョブ

ダッシュボードの指標を最新にするには、次のスケジュール済プロセスを実行します（26A）。

Refresh Receivables Transactions for Customer Account Summaries
Collections Delinquency Management
Collections Scoring and Strategy Assignment
Update Collections Summary Data
Initialize and Load Collections Metrics
Incremental Load Collections Metrics

5 と 6 は、名称から指標の初期ロードと差分ロードと読み取れます。使い分けと実行順は、対象リリースの公式ドキュメントで確認してください。

支払約束・紛争・破産

支払約束（Promise to Pay）：顧客が約束した支払日と金額を記録します。回収の設定で、約束が破綻とみなされるまでの猶予日数の上限や、約束の期日の最大日数を決められます。REST では collectionPromises で扱います
紛争（Dispute）：請求内容に異議がある取引を、回収者が登録します。減額が必要な場合は、承認ワークフローを経てクレジットメモになります（請求）
破産：回収の設定の Enable bankruptcy で有効にします

請求書管理（Bill Management）

Bill Management は、顧客（外部ユーザー）が自分の未決済取引の確認、クレジットメモの確認、紛争の確認、オンライン支払を行うための機能です。取引の分析・ダウンロードもできます（26B）。問い合わせの電話や請求書の再送依頼を減らす狙いで導入します。

設定手順（26B）

内部ユーザーのデータアクセス：設定および保守で、オファリング Financials、機能領域 Users and Security の Manage Data Access for Users を使い、ユーザー・ロール・セキュリティコンテキスト（BU など）を割り当てる
Manage Bill Management System Options（機能領域 Bill Management）で次を設定する
外部ユーザー（顧客の担当者）を登録する（公式ドキュメントの Register External Users）。REST では billManagementUsers があります

セクション	主な項目
Registration	外部ユーザーに割り当てるロール（Customer Accounts Payable Specialist を選択）
Transaction and Payment Processing	取引履歴を表示する月数、エイジング方法、支払可能な将来日数の上限、Default Receipt Method from Transaction
Preferences（BU ごと）	Bank Payment、Credit Card Payment、Credit Card Payment Limit、Ledger Currency Only、Print Invoice の許可・制限
Notifications	ユーザー登録の通知メール（BU と宛先）

Default Receipt Method from Transaction を Yes にすると、外部の顧客の支払に、取引に関連付けた入金方法の銀行口座またはクレジットカードが使われます
クレジットカードの処理は、26B のドキュメントでは Oracle Payments が PCI DSS v3.2.1 の認証を受けた Oracle のデータセンターに限られると記載されています。利用可否はリリースとデータセンターにより異なるため、導入前に確認してください
Bill Management からの減額要求も、承認ワークフローを経てクレジットメモになります（請求）

標準機能とアドオン

要件	標準機能	よくあるアドオン（実現手段）
督促状の様式	事前定義のテンプレートと、Collections Send Dunning Letters データモデル	自社様式のテンプレート（BIP）
督促の方針（誰に・いつ・どの強さで）	Aged／Staged、戦略とスコアリング	業界固有の判定が必要なら、外部で判定して支払約束などを REST で登録（OIC）
回収の指標・分析	作業領域のダッシュボード、OTBI、エイジングのレポート	独自の KPI 帳票（BIP・OTBI）、FDI での分析
顧客への請求書提供	Bill Management、メール・XML・ポータル送付（請求）	顧客独自のポータルとの連携（REST、OIC）
督促の例外（係争中・分割払い）	督促の除外、支払約束、紛争	例外の判定ルールを運用ルールとして整理し、標準の除外設定に落とす

ベストプラクティス

督促か戦略かを最初に決める：併用できないため、運用設計とテストの前提にします
回収の単位を請求の単位にそろえる：締め請求（請求先サイト単位など）と督促の単位が違うと、督促状の金額が請求書と合いません
誤督促を防ぐ：未確認入金・未消込の入金・係争中の取引が残ったまま督促すると、顧客対応の負担が増えます。督促の前に、入金消込（入金）と紛争の状況を確認する運用にします
ジョブの順序を決める：督促・スコアリング・ダッシュボード更新のジョブは、日次の夜間バッチとして順序と依存を設計します（ESS）
テンプレートは複製して使う：事前定義のテンプレートやデータモデルは直接変えず、コピーして修正し、四半期アップデート後に回帰テストします
アンチパターン：督促状のテンプレートや戦略を、顧客ごとに大量に作る。保守とテストが重くなります

日本での導入の考慮点

機能の有無ではなく、運用面の設計ポイントです（日本固有の回収機能は、公式ドキュメントで確認できた範囲では見つかっていません）。

締め請求との関係：残高繰越請求（締め請求）の支払期日と督促の起点が一致するように、支払条件とエイジング方法を設計します
振込入金の消込の遅れ：銀行振込の入金データの取込（入金の全銀形式）が遅れると、入金済みの顧客に督促が出ます。督促の実行前に入金の取込と消込を完了させる順序にします
督促状の文面：初回は「行き違いの場合はご容赦ください」といった文面にするなど、日本の商習慣に合わせた段階的な文面をテンプレートで用意します（Aged ならエイジング区分ごと、Staged なら段階ごと）

AI・自動化機能

自動化の中心は、スコアリングと戦略の割当（ルールに基づく自動割当）、督促状の自動送付、ダッシュボード更新のジョブです。戦略のタスクは Oracle SOA が開始・管理して担当者に通知し、通信文書は BI Publisher が送付します
AI 機能は四半期アップデートで追加・変更されます。公式の「AI Features for ERP」には、Receivables 関連として次の機能が載っています（名称・種別・リリースのみで、説明は載っていません。動作と必要なロールは対象リリースの What’s New で確認してください）

機能名（公式の表記）	種別	リリース
Collector Workspace Agent for Prioritized Work Queue and Guided Resolution	Agentic app	26C
Collector Workspace Agentic Application for enhanced collections actions	Fusion Claw	26D
Cash Processing Agent for Receipt Processing and Cash Application	AI agent	26C、26D
Customer Billing Agent	AI agent	26C
Billing Operations Workspace for billing readiness and dispute resolution	Agentic app	26D
Reversal and Rebilling Assistant	AI agent	26D

名称からは、回収者の優先順位付きの作業キューと対応の支援（Collector Workspace）、入金処理と消込の自動化（Cash Processing Agent）、請求の準備と請求の紛争の解決（Billing Operations Workspace）を扱う機能と読み取れます。採用するときは、利用に必要なロール・データアクセス・人が確認する手順を決めます（Redwood UX と AI・自動化機能）

実装リファレンス

スケジュール済プロセス

プロセス	用途
Delinquency Identification	延滞取引の自動特定（Aged／Staged の公式説明での名称）
Collections Delinquency Management	延滞の管理。ダッシュボード更新の手順に含まれる
Collections Scoring and Strategy Assignment	スコアリングと戦略の割当
Strategy Management	戦略の割当とタスクの開始（公式ドキュメントでは同時実行プログラム（concurrent program）として記載）
Update Collections Summary Data	回収のサマリーデータの更新
Initialize and Load Collections Metrics / Incremental Load Collections Metrics	回収の指標のロード（名称から初期ロードと差分ロードと読み取れる）
Refresh Receivables Transactions for Customer Account Summaries	顧客アカウントのサマリーの更新
Validate Customer Dunning Setup Report	督促設定の不備の確認

プロセスの名称・パラメータは、対象リリースのスケジュール済プロセス一覧で確認してください。

テーブル・REST

種類	名前	用途
テーブル	IEX_DUNNINGS（IEX_ で始まる表が Advanced Collections 用）	督促のデータ（表の一覧と列は Tables and Views で確認）
テーブル	AR_COLLECTORS	回収者（列は Tables and Views で確認）
テーブル	AR_PAYMENT_SCHEDULES_ALL	延滞判定の元になる債権の残高と期日
REST	collectionPromises、collectionStrategies	支払約束・回収戦略（Manage Collections の REST リファレンスで確認）
REST	billManagementUsers	Bill Management の外部ユーザー

SELECT hca.account_number,
       hp.party_name,
       COUNT(*)                     AS overdue_items,
       SUM(ps.amount_due_remaining) AS overdue_amount,
       MIN(ps.due_date)             AS oldest_due_date
FROM   ar_payment_schedules_all ps
JOIN   hz_cust_accounts hca ON hca.cust_account_id = ps.customer_id
JOIN   hz_parties hp        ON hp.party_id = hca.party_id
WHERE  ps.status = 'OP'
AND    ps.class IN ('INV', 'DM', 'CB')
AND    ps.due_date < TRUNC(SYSDATE)
AND    ps.org_id = :P_ORG_ID
GROUP  BY hca.account_number, hp.party_name
ORDER  BY oldest_due_date

この SQL は延滞候補の目安です。実際の延滞判定は Collections の処理（延滞の特定とスコアリング）に従います。督促の対象件数と突き合わせるなど、照合や調査に使います。

export FA_URL="https://<your-pod>.fa.<region>.oraclecloud.com"
curl -s -u "$FA_USER:$FA_PASSWORD" \
  "$FA_URL/fscmRestApi/resources/11.13.18.05/collectionPromises?limit=5&onlyData=true"

実務では、limit・offset のページングを入れ、400 系の応答本文をログに残します（REST API の基本）。

落とし穴とベストプラクティス

回収者の設定漏れ：従業員として登録されていない、顧客プロファイルに回収者がない、のいずれかで、作業領域に顧客が出ません
ダッシュボード更新のジョブを動かしていない：指標が古いままになります。更新ジョブを夜間バッチに組み込みます
督促と戦略を併用する前提で設計する：公式ドキュメントでは、どちらか一方とされています
メール送付の準備不足：BI Publisher のメールサーバー、宛先の連絡先、送付方法の設定のいずれかが欠けると、督促がエラーで終わります
Bill Management の外部ユーザーのロールを付けない：登録時に割り当てるロールを、システムオプションの Registration で決めておきます

試験対策ポイント

対応する試験：AR 模擬テストの「Implementing and using Bill Management」「Implementing and using Advanced Collections」。「Leveraging AI/ML, Mobile and Automation Features」でも、回収の自動化が出ることがあります
覚えるポイント
- 督促と戦略は、延滞の管理にどちらか一方を使う（併用しない）
- Aged は最も古い延滞取引のエイジング区分、Staged は前回の督促状からの日数
- 戦略は「タスク → 戦略 → 回収方法名 → タスクの割当」。割当はスコアリング、延滞後と延滞前（Predelinquent）は別に定義
- 回収者は従業員。顧客プロファイルの割当が作業領域の表示を決める
- ダッシュボード更新のジョブ（Collections Delinquency Management、Collections Scoring and Strategy Assignment、Update Collections Summary Data、指標のロード）
- Bill Management の設定は Manage Bill Management System Options と Manage Data Access for Users。外部ユーザーの登録ロールは Customer Accounts Payable Specialist
- 紛争は承認を経てクレジットメモ要求になる
- AI 機能の名称（26C・26D）：Collector Workspace、Cash Processing Agent、Customer Billing Agent など。種別は Agentic app、AI agent、Fusion Claw