現金管理（CM）：銀行マスタ・銀行明細・照合・キャッシュポジション

Cash Management（CM）は、自社の銀行口座と銀行明細を管理し、明細を AP の支払・AR の入金・GL の仕訳・外部取引と照合し、キャッシュ・ポジションと予測を見えるようにするモジュールです
銀行・支店・口座のマスタは AP・AR・Payments と共有します。口座は法的エンティティが所有し、Payables・Receivables の BU が利用します。口座は支払方法や入金方法より先に作ります
照合は「明細の取込 → 自動照合（照合ルールセット）→ 手動照合 → 外部取引の作成」の流れです。照合ルールのタイプは One to One・One to Many・Many to One・Many to Many・Zero Amount の 5 つです
決済時に会計する設定の支払では、決済の仕訳（Payment Cleared）は、銀行照合で支払が決済済（Cleared）になって初めて作られます。期間締めでは、銀行照合を AP・AR の締めより先に行います
日本向けは、全銀ファイルでの銀行・支店の一括更新と口座の検証ルールを公式ガイドで確認できました。全銀形式の入金は AR のロックボックスが担います。銀行明細の取込で公式に確認できた形式は BAI2・SWIFT MT940・EDIFACT FINSTA・ISO 20022 camt.052／camt.053 で、全銀形式は 26B の該当ガイドに記載がありません（要確認）

モジュールの役割と位置づけ

CM は、お金の出入りを「銀行側の事実（銀行明細）」と「システム側の取引」で突き合わせる役割です。

製品	管理する対象	CM との関係
Cash Management（CM）	内部銀行口座、銀行明細、照合、外部取引、キャッシュ・ポジション、予測	明細の取込、自動・手動の照合、外部取引の作成
Payments（Oracle Payments）	支払方法、支払ファイル、外部銀行口座	支払元の自社口座は CM の口座を使う
Payables（AP）	仕入先への支払	支払を銀行明細と照合して決済済にする
Receivables（AR）	顧客からの入金	入金を銀行明細と照合して消し込む（消込方法 By Matching）
補助元帳会計（SLA）・GL	仕訳、残高	照合に伴う仕訳を作り、GL へ転送する

銀行 → 銀行明細（ファイル）→ 取込・解析 → 自動照合 → 手動照合・外部取引の作成 → 会計（SLA）→ GL
        照合の相手：AP の支払／AR の入金／Payroll／GL の仕訳／外部取引

支払側の流れは P2P：購買依頼から支払・会計まで、入金側は O2C：受注から出荷・請求・入金まで、締めの順序は R2R：記帳から決算・連結・EPM までとあわせて確認してください。

使用する組織

組織	CM での役割	設定の考え方
法的エンティティ	内部銀行口座の所有者	口座は法的エンティティごとに作る
BU（Payables・Receivables）	口座を支払・入金に使える範囲	口座の用途（Payables、Receivables、Payroll など）と BU のアクセスで決める。支払方法は Payments の利用ルール（Usage Rules）でも BU 単位に制限できる
元帳	口座の GL 勘定の COA を決める	口座に現金・現金清算・実現為替差損益などの勘定を設定する。実現為替差損益は口座ごとに持つ
ユーザー・ロール	口座の操作権限	口座ごとに付与する（名称と手順は公式ガイドで確認）

銀行と支店は組織に紐づかず、AP・AR・Payments で共有されます。口座の作成時の考慮事項は、公式ガイドの Considerations When You Create Accounts を確認してください。

主要な業務プロセス

設定：銀行・支店・口座、取引コード、解析ルール、照合ルールセットを作ります
銀行明細の取込：ファイルを取り込み、解析ルール（Parse Rule Sets）で項目を読み取り、取引コードと取引タイプで意味づけします。UCM（コンテンツ管理）に置いたファイルをワイルドカードで取り込む設定もあります
自動照合：口座に割り当てた照合ルールセットで、明細行とシステム取引を突き合わせます（Autoreconciliation）
手動照合：自動で一致しなかった行を、画面で照合します
外部取引の作成：銀行手数料・利息など、システムにない取引を明細から作ります（取引作成ルール）
会計：決済・手数料などの仕訳を SLA で作り、GL へ転送します
キャッシュ・ポジションと予測：口座の残高と見込みを確認します
期間締め：支払・入金の照合を終えてから AP・AR を締めます

日本企業での典型的な運用例

総合振込・給与振込の翌営業日に銀行明細を取り込み、支払を決済済にします
振込入金は AR のロックボックス（全銀形式）で入金を作り、CM で銀行明細と照合します（AR の入金）
月末に銀行残高と帳簿残高（口座の現金勘定）の差異を確認します
振込手数料の銀行引落しは、取引作成ルールで自動計上できるかを検討します

マスタデータ

マスタ	内容	作成場所（UI）	移行手段
銀行・支店	AP・AR・Payments で共有。日本は銀行コード 4 桁、支店番号 3 桁	Manage Banks、Manage Bank Branches	全銀ファイル（Upload Banks, Branches, and Accounts）
内部銀行口座	自社口座。所有者、用途、BU、GL 勘定、アクセス権	Manage Bank Accounts	スプレッドシート（Create Banks, Branches, and Accounts in Spreadsheet）
取引コード・取引タイプのマッピング	銀行の取引コード（BAI2 など）を CM の取引タイプへ対応づける	公式ガイドの Overview of Bank Statement Transaction Codes ほか	手入力
解析ルールセット	明細ファイルの項目を読み取るルール	Parse Rule Sets の設定	手入力
許容範囲ルール	日付・金額の許容。超えたときに阻止または警告	Tolerance Rules の設定	手入力
照合ルール・ルールセット	突合の条件とルールの束。口座に割り当てる	Create Reconciliation Matching Rule ページ	手入力
取引作成ルール	明細から外部取引などを自動で作る	Bank Statement Transaction Creation Rules の設定	手入力

作成順序（依存関係）

企業構造：法的エンティティ・元帳・BU（口座の所有者と GL 勘定に必要）
銀行・支店（日本は全銀ファイルで一括）
内部銀行口座：所有者・用途・BU・GL 勘定・アクセス権（Payments の支払方法と AR の入金方法は口座を参照するため後）
取引コードと取引タイプのマッピング、解析ルールセット
許容範囲ルール → 照合ルール → 照合ルールセット（ルールと許容範囲を含む）→ 口座へ割当
取引作成ルール
CM のプロファイル・オプション、キャッシュ・ポジションと予測の設定

他モジュールとの連携

連携	タイミング	流れるデータ	仕組み
Payables・Payments → CM	支払の確定後	支払（Payables ソース）	明細行と照合し、決済済にする
Receivables → CM	入金・送金後	入金（Receivables ソース）	照合で消し込む（By Matching の入金）
Payroll → CM	給与支払後	給与の支払（Payroll ソース）	明細行と照合
GL → CM	仕訳の転記後	仕訳行（Journals ソース）	照合参照（Reconciliation Reference）を仕訳行に持ち、FBDI・ADFdi で取り込める
CM → SLA → GL	照合・外部取引の後	会計イベント	Create Accounting

照合の相手（ソース）は、Payables、Receivables、Payroll、Journals、External から複数選べます。

会計連携

決済時に会計する設定の支払は、銀行照合で決済済になると Payment Cleared のイベントが作られます。公式ガイドの設定（At payment issue and clearing）での典型的な仕訳は次のとおりです（AP の全体像）。

支払の発行     Dr 買掛金     / Cr 現金清算（Cash Clearing）
銀行での決済   Dr 現金清算   / Cr 現金（Cash）        ← 銀行照合で決済済になった時点

外部取引（銀行手数料・利息など）の仕訳の勘定は、口座に設定した勘定や取引の定義で決まります。詳細は公式ガイドの会計の章で確認してください。

標準機能とアドオン

標準でできることは、明細の取込と解析、5 タイプの照合ルールによる自動照合、手動照合、取引作成ルールによる外部取引の作成、キャッシュ・ポジションと予測です。

種類	例	実現手段
インターフェース	銀行からの明細取得の自動化	OIC（SFTP・API）で UCM へ配置、または FBDI
データ変換	銀行独自の固定長形式を取込形式へ変換	解析ルールセット、OIC
帳票	未照合一覧、銀行勘定調整表	BI Publisher、OTBI
拡張	照合参照などの独自項目	照合参照の取込（FBDI・ADFdi）、DFF

Fit to Standard では、次を検討します。

手動照合の多い取引は、One to Many・Many to One・Many to Many・Zero Amount のルールで自動化できないか
銀行手数料の計上は、GL の手入力仕訳ではなく取引作成ルールで足りないか
銀行独自形式は、解析ルールセットで読めるなら OIC の変換を作らない

ベストプラクティス

照合ルールは One to One（標準の既定）から始め、残りを他のタイプで補います。One to One の既定は、照合参照・日付・取引タイプが条件です
グループ型（One to Many・Many to One・Many to Many）はグルーピング属性が必須です。グループを 1 つのソースに限るときは、Transaction Source をグルーピング属性に加えます
グループ型で日付・取引タイプ・照合参照を条件にするには、先にグルーピング属性として選びます
高度な条件（Create Condition ページ）は、両辺のデータ型を合わせ、リテラル値はデータベース上の値と一致させます（例：Statement.Transaction Type equals ACH）
取引コードのマッピングを先に整えてから、照合ルールを設計します
口座は法的エンティティごとに作り、GL 勘定を口座に設定します。決済時に会計する支払は、銀行照合を月次締めの最初に行います
アンチパターン：口座ごとに個別のルールを増やす、手動照合を前提にする、銀行手数料を手入力仕訳で処理する

日本での導入の考慮点

公式ドキュメントで確認できた日本向け機能（26D 時点）

銀行・支店の一括メンテナンス：全銀ファイルを Upload Banks, Branches, and Accounts（File Type に Japan Zengin File）で取り込みます。詳細は AP の全体像を参照してください（公式ガイドの Bulk Maintenance of Banks and Bank Branches in Japan）
銀行口座の検証ルール：銀行コードは数字 4 桁、支店番号は数字 3 桁で必須、預金種目も必須です
全銀形式の入金：AR のロックボックスの伝送フォーマット ORA_ZENGIN_LOCKBOX で、入金を作ります（AR の入金）。CM の銀行明細の取込とは別の機能です

汎用機能で対応する事項

銀行明細の取込形式：26B の How You Process Electronic Bank Statements で確認できた形式は、BAI2、SWIFT MT940、EDIFACT FINSTA、ISO 20022 の CAMT052 V1、CAMT053 V1〜V3 です（ファイル拡張子は .txt、.dat、.csv、.xml、*.ack）。日本の銀行の明細形式は、これらへの変換（OIC など）で取り込めるかを検証します
振込入金の照合：振込依頼人名は半角カナのことが多く、AR の入金や明細の参照項目と表記が揃わない場合があります。照合ルールの条件に使う前に、表記を正規化する方法を決めます
振込手数料：取引作成ルールで外部取引として計上できるかを検証します。AP の銀行手数料（Bank Charges）は支払時の差引で、別の機能です

確認できなかった事項（要確認）

全銀形式・電子記録債権などの銀行明細を、事前定義の形式で取り込めるか。26B の電子銀行明細のガイドには全銀形式の記載がないため、公式のローカライゼーション文書（Using Financials for Asia/Pacific の Japan の章）で確認してください
日本の銀行 API・総合振込の結果ファイルとの連携は、標準機能の範囲を確認できていません

実装リファレンス

主要テーブル

テーブル	内容	確認状況
CE_BANK_ACCOUNTS	内部銀行口座	要確認（未検証）
CE_STATEMENT_HEADERS、CE_STATEMENT_LINES	銀行明細のヘッダーと明細	要確認（未検証）
IBY_EXT_BANK_ACCOUNTS	外部銀行口座（仕入先・顧客など）	要確認

名称は一般的な命名で記載しています。列は Tables and Views for Financials で確認してください。

設定ページ・プロセス・取込手段

種類	名前	用途
ページ	Create Reconciliation Matching Rule、Create Condition	照合ルールと高度な条件の定義
スプレッドシート	Create Banks, Branches, and Accounts in Spreadsheet	銀行・支店・口座の一括作成
ESS	Upload Banks, Branches, and Accounts	全銀ファイルによる銀行・支店の更新
ESS	Load and Import Bank Statement	銀行明細ファイルの手動取込。パラメータに Format、Data File、Intraday、Submit Autoreconciliation（取込成功後に自動照合を続けて実行。Intraday 明細には使えない）
ESS	Process Electronic Bank Statement Request	自動取込。銀行からファイルを取得（SFTP_GET または HTTP(S) GET）して処理・取込する
ESS	Create Accounting	仕訳の作成と GL への転送
取込	FBDI、ADFdi	仕訳行の照合参照の取込

明細取込は Retrieve（ファイル取得）→ Load（インターフェース表へ）→ Import（検証・解析ルール適用して明細表へ）の 3 段階です。Load で失敗したらエラーデータをパージして再実行し、Import で失敗したら修正して Import だけを再実行できます（銀行明細と照合の概要ページの処理警告・エラー表から）。手動取込のファイルは zip にして WebCenter Content のアカウント fin/cashManagement/import へ置き、File Import and Export で転送します。

自動照合の単独実行ジョブ名は、26B の該当ガイドでは確認できませんでした（取込時の Submit Autoreconciliation オプションは確認済み）。REST は、cashBankAccounts（子に bankAccountTransactionCreationRules など）、cashBanks、cashBankBranches、cashBankAccountTransfers、cashPools を REST API for Oracle Fusion Cloud Financials（26A）の一覧で確認しました。銀行明細の取込・照合を直接扱う REST リソースは、確認した範囲では見つかっていません。

試験対策ポイント

CM を専用に扱う認定試験はありません。銀行・支店・口座は AP・AR の前提設定なので、AP 模擬テストの「Setting up Common Configurations in the Supplier Invoice to Payments Process」や「Implementing Payments」、AR 模擬テストの「Implementing and managing customer payments」で口座の設定に触れる可能性があります
覚えるポイント：照合ルールの 5 タイプ／グループ型はグルーピング属性が必須／ソースは Payables・Receivables・Payroll・Journals・External／ルールセットは口座に割り当てる／決済時会計は銀行照合が前提

公式ドキュメント

Implementing Payables Invoice to Pay（26D）（Cash Management and Banking Configuration の章）
Reconciliation Matching Rules（26D）
Using Payables Invoice to Pay（26D）
Using Financials for Asia/Pacific（26D）
Zengin Format for Japan Lockbox Processing（26C）
Tables and Views for Financials（26D）