Fusion Cash Management-Real time Interview Questions

Based on real-world implementations and production scenarios I've handled across multiple Oracle Fusion Cash Management deployments, here are 20 interview questions and answers that reflect actual architect-level challenges:

Core Cash Management Architecture

1. Explain the end-to-end flow from payment creation in AP/AR to reconciliation in Cash Management.

Payments originate in AP (supplier payments) or AR (customer receipts) and flow through the payment process request. When a payment is created, it hits the Cash Clearing Account first, not the actual Cash Account. The payment status moves from "Created" → "Negotiable" → "Cleared" once the bank processes it. Bank statements are loaded via BAI2/MT940 formats into the open interface tables (CE_STATEMENT_HEADERS_INT/CE_STATEMENT_LINES_INT). The reconciliation process then matches bank statement lines against system transactions. Only after reconciliation does accounting transfer amounts from Cash Clearing to the actual Cash Account.

2. What's the difference between bank statement reconciliation and account reconciliation in Fusion?

Bank statement reconciliation happens in Cash Management and matches external bank transactions against internal payment/receipt transactions. It's transaction-level matching using rules (amount, date, reference, bank transaction code). Account reconciliation happens in General Accounting and reconciles GL account balances (like clearing accounts) by matching journal lines. Cash Management reconciliation drives the accounting that moves amounts from clearing to cash accounts; account reconciliation validates that those clearing accounts are properly balanced.

3. How does automatic reconciliation work, and what are the common failure scenarios?

Automatic reconciliation uses rule sets assigned to bank accounts. Rules match on: amount, transaction date, payment reference, document number, and bank transaction code. The system runs through the rule set sequentially and reconciles when all criteria in a rule are satisfied. Common failures: tolerance settings too tight (amount differences from bank fees), missing payment references on bank lines, multiple small payments lumped into one bank transaction, and bank transaction codes not mapped correctly. Tolerances only work properly in one-to-one matching scenarios.

4. Walk me through your bank statement loading architecture.

Production implementations typically use: bank SFTP → middleware (OIC/SFTP adapter) → Fusion open interface tables → "Load Bank Statement" scheduled process. The loading program validates mandatory fields: BANK_ACCOUNT_NUM, STATEMENT_NUMBER, STATEMENT_DATE, CURRENCY_CODE, and line-level amounts. Common issues: bank account number mismatches between bank file and Fusion setup, statement number duplicates, and currency code inconsistencies. For high-volume environments, we stage files in a custom schema first, validate, then push to interface tables to avoid loading failures.

Real-Time Production Issues

5. A client has 50,000 unreconciled transactions. How do you approach this?

First, run diagnostics: check if automatic reconciliation rules are assigned and if the scheduled process is running. Analyze the unreconciled population by age, amount, and bank account. Common root causes: missing bank statements for certain periods, bank transaction codes not mapped, or payments created outside the standard flow (manual journals to cash accounts). For cleanup, create targeted reconciliation rules for high-volume patterns (e.g., payroll batches, POS settlements). Use "Reconcile by Reference" for known matches. For old items, consider manual reconciliation or write-offs if immaterial. Never mass-reconcile without validation—it breaks audit trails.

6. Bank fees are causing reconciliation mismatches. How do you handle this architecturally?

Three approaches: (1) Tolerance-based: Set amount tolerances in reconciliation rules to auto-match transactions within a threshold (e.g., ±50 INR for bank charges). Post-reconciliation, manually book the fee difference. (2) Bank Transaction Code mapping: Map specific bank codes (e.g., "CHG" for charges) to a "Bank Fees" subledger account, then auto-create accounting entries. (3) Pre-reconciliation adjustment: Create a separate bank statement line for fees before reconciliation, then match the net amount. Best practice: use bank transaction codes with auto-accounting rules for scalability.

7. POS integration: bank shows one lump sum, but you have 500 individual receipts. How do you reconcile?

This is a classic POS settlement scenario. The bank receives a daily batch settlement (e.g., ₹5,00,000) while Fusion has 500 individual customer receipts. Solution: create a batch-level receipt in AR that matches the bank settlement amount, then link individual receipts to this batch. Alternatively, use a "POS Clearing Account" where individual receipts post, and a single journal entry transfers the batch total to cash. Reconciliation then matches the one bank line to the one batch receipt/journal. For automated flows, integrate the POS gateway to send batch settlement files that auto-create the batch receipt.

8. What happens when a payment is reconciled but the accounting hasn't transferred to the cash account?

Reconciliation updates the payment status to "Reconciled" but doesn't automatically create accounting. You must run the "Create Accounting" process for Cash Management. This generates the entry: Cash Clearing Account Dr → Cash Account Cr. Common issue: accounting periods are closed or the process hasn't been scheduled. Check the "Accounting Status" on the reconciled transaction. If it shows "Never Created," run Create Accounting. If it shows "Error," review the accounting events and fix validation issues (e.g., invalid account combinations, closed periods).

Integration Scenarios

9. How do you integrate real-time bank APIs vs. traditional BAI2/MT940 files?

Traditional: daily BAI2/MT940 files via SFTP, loaded once/day. Real-time: bank APIs (REST/SOAP) poll transaction endpoints every 15-30 minutes, push to Fusion interface tables via OIC. API benefits: near-real-time visibility, faster reconciliation, better cash positioning. Challenges: API rate limits, authentication token management, and handling partial settlements. Architecture: OIC integration → custom staging table → validation → interface tables → load process. For high-volume clients, we use event-driven triggers (webhooks) instead of polling

10. A client wants to reconcile payroll payments. What's special about this?

Payroll payments are batch payments with one bank transaction per employee, but the bank statement may show a single lump-sum debit. Reconciliation approach: load the bank statement with the total amount, then use "Reconcile by Batch" to match the bank line against the payroll payment batch. Alternatively, if the bank provides detail lines (employee-level), load those and match individually. Key setup: ensure payroll payment batches are created with a consistent reference (e.g., payroll run ID) that appears on the bank statement. Discrepancies often arise from bank fees deducted from the net amount.

11. How do you handle multi-currency bank accounts?

Each bank account in Fusion has a primary currency. If the bank statement contains transactions in a different currency (e.g., USD account with EUR transaction), the loading process converts using the exchange rate on the statement date. Reconciliation matches the converted amount against system transactions. Issues arise when: exchange rates differ between Fusion and bank, or when the bank uses a different rate source. Solution: load the bank statement in the original currency, let Fusion handle conversion, and set tolerance rules for minor rate differences. For treasury reporting, use Cash Management's currency exposure analytics

12. Explain how you'd design a Cash Management integration for a client with 10 banks across 5 countries.

Centralized architecture: one Fusion instance, multiple bank accounts. Use OIC as the integration hub with bank-specific adapters (SFTP for BAI2/MT940, REST for APIs). Standardize file formats where possible (push banks toward ISO 20022 camt.053). Create a staging layer to validate and transform files before loading into Fusion. Assign bank accounts to legal entities based on jurisdiction. Use automatic reconciliation rule sets per bank (different banks have different transaction code conventions). For reporting, build a consolidated cash position dashboard using OTBI or BI Publisher, pulling from CE_STATEMENT_LINES and CE_BALANCES

Advanced Configuration

13. What are bank transaction codes, and how do you configure them?

Bank transaction codes (BTCs) are codes on bank statement lines that indicate transaction type (e.g., "INT" for interest, "CHG" for charges, "TRF" for transfer). Configuration: define BTCs in Cash Management, map each to a subledger account (e.g., Bank Charges Account), and optionally assign to reconciliation rules. When a statement line with a BTC is reconciled, Fusion auto-creates accounting entries using the mapped account. Critical for automating fee accounting and reducing manual adjustments.

14. How do you configure cash clearing accounts, and what's the accounting flow?

Cash clearing accounts are defined at the bank account level (internal accounts). Accounting flow: (1) Payment created: AP/AR Dr → Cash Clearing Cr. (2) Payment reconciled: no accounting yet. (3) Create Accounting run: Cash Clearing Dr → Cash Account Cr. The clearing account acts as a suspense account between payment creation and bank reconciliation. Best practice: enable reconciliation for clearing accounts in General Accounting to monitor unreconciled balances.

15. What's the difference between "Cleared" and "Reconciled" status?

"Cleared" means the payment has been processed by the bank (funds have moved). "Reconciled" means the bank statement line has been matched against the payment in Fusion. A payment can be cleared but not reconciled (e.g., bank processed it, but statement not loaded yet). Reconciliation is the final step that triggers accounting to move amounts from clearing to cash accounts.

16. How do you handle partial reconciliations (one bank line, multiple payments)?

Use "Many-to-One" reconciliation rules. Configure rules to match on amount range (sum of payments ≈ bank line amount) and reference (e.g., same customer code). The system will reconcile multiple payment lines against one bank line. Alternatively, manually select multiple payments and reconcile against the bank line. For automation, create a batch receipt that aggregates individual payments, then reconcile the batch against the bank line.

Troubleshooting & Performance

17. Bank statement loading fails with "BANK_ACCOUNT_NUM not found." What's wrong?

The bank account number in the interface file doesn't match the account number in Fusion's "Manage Bank Accounts" setup. Common causes: leading/trailing spaces, different formatting (e.g., "12345" vs "12345-01"), or the account was inactivated. Fix: validate the interface file against the CE_BANK_ACCOUNTS table, ensure exact match including branch codes. For ongoing prevention, create a validation report that compares incoming file account numbers against Fusion setup before loading.

18. Automatic reconciliation is taking 6+ hours. How do you optimize?

Root causes: too many unreconciled transactions, overly broad rules, or missing indexes. Optimization: (1) narrow rule criteria (add date ranges, amount thresholds), (2) run reconciliation more frequently (daily vs. weekly) to reduce backlog, (3) archive old unreconciled transactions, (4) create separate rule sets per bank account to avoid cross-account matching, (5) check for customizations or triggers on interface tables. For large volumes, consider partitioning the CE_STATEMENT_LINES table.

19. How do you troubleshoot a reconciliation that matched the wrong transaction?

Check the reconciliation rule that fired—often it's too broad (e.g., match by amount only, no date/reference). Review the "Reconciliation Reference" field on both the bank line and payment. If it's a systemic issue, adjust the rule set priority (rules are evaluated in order). For one-off fixes, unreconcile the transaction and manually reconcile with the correct match. Preventive measure: add more specific rules (e.g., match by payment reference + amount) and reduce reliance on amount-only matching

20. A client wants real-time cash positioning. How do you architect this?

Traditional cash positioning uses daily bank statement loads, giving T+1 visibility. For real-time: integrate bank APIs to pull transaction data every 15-30 minutes into Fusion. Use the "Cash Positioning" feature to aggregate balances across bank accounts, including pending transactions. Build a custom dashboard (OTBI/BI Publisher) showing: current bank balances, pending payments, expected receipts, and net cash position. For treasury clients, add currency exposure and investment tracking. Key challenge: API rate limits and data consistency across multiple banks

These questions reflect actual production scenarios I've architected across Oracle Fusion implementations. The key differentiator for senior roles is understanding not just the "how" but the "why" behind configuration choices and the ability to troubleshoot complex reconciliation failures.

Hope this Helps . Happy Learning