Oracle Financials Import: Cloud vs E-Business Suite
Oracle has two primary enterprise finance platforms, and bank statement import works differently in each. Understanding which version your organization runs is the first step.
| Feature | Oracle Financials Cloud | Oracle EBS 12.x |
|---|---|---|
| Import Path | Cash Management > Bank Statements > Create | Cash Management > Bank Statements > Import |
| Accepted Formats | BAI2, SWIFT MT940, CSV | BAI2, SWIFT MT940, OFX, CSV, QIF |
| Date Format | YYYY-MM-DD | DD-MON-YYYY (e.g. 01-JAN-2025) |
| Currency | ISO 4217 code required | ISO 4217 code required |
| GL Integration | Auto-posts on reconcile | Requires separate journal import |
| PDF Support | None — convert first | None — convert first |
For most accounting teams, CSV is the practical choice because it works across both versions and is easy to prepare from any bank export or PDF conversion tool.
Required CSV Column Format
Oracle Cash Management has strict column requirements. Missing or misnamed columns will cause the import to reject the file entirely.
| Column Name | Required? | Format / Notes |
|---|---|---|
BANK_ACCOUNT_NUM | Yes | Must match account registered in Oracle |
STATEMENT_DATE | Yes | YYYY-MM-DD (Cloud) or DD-MON-YYYY (EBS) |
TRX_DATE | Yes | Transaction date in same format as above |
TRX_TYPE | Yes | CREDIT, DEBIT, or MISC |
AMOUNT | Yes | Positive number; sign determined by TRX_TYPE |
CURRENCY_CODE | Yes | ISO 4217 (USD, CAD, GBP, EUR, AUD) |
TRX_NUMBER | Yes | Unique reference per transaction |
DESCRIPTION | No | Memo/payee description for reconciliation |
VALUE_DATE | No | Bank value date if different from transaction date |
Converting PDF Bank Statements for Oracle Import
Most banks deliver statements as PDFs. Oracle cannot read these directly, so you need to extract the transaction data and format it as a valid Oracle CSV before import.
The challenge with PDFs is that the raw text extracted rarely matches Oracle's column structure. A bank PDF might have a freeform "Description" column, an unstructured date like "Jan 15, 2025", and combined debit/credit amounts. Each of these needs to be normalized.
Zera Books' Oracle import workflow handles this automatically — it reads PDFs, scanned images, and multi-page statements, extracts structured transaction data, and outputs a CSV formatted specifically for Oracle Cash Management with the correct column names, date formats, and sign conventions.
Any PDF Format
Digital PDFs, scanned statements, image-based PDFs — all processed without templates.
Date Normalization
Converts any date format (Jan 15, 01/15/25, 15-JAN) to Oracle's required YYYY-MM-DD.
Oracle CSV Headers
Exports with exact Oracle column names — no manual header renaming needed.
Sign Convention
Splits combined amounts into separate CREDIT/DEBIT rows with proper TRX_TYPE values.
Step-by-Step: Import into Oracle Financials Cloud
Once your CSV is correctly formatted, follow these steps in Oracle Financials Cloud:
Navigate to Cash Management
From the home page, go to Cash Management > Bank Statements and Reconciliation > Bank Statements.
Select Load Bank Statement File
Click Load Bank Statement File. Choose your file format — select CSV or the appropriate format (BAI2, SWIFT MT940) based on your file type.
Upload Your File
Browse to your prepared CSV file and upload it. Oracle will validate the header row and first few records before accepting the file.
Map Bank Account
If prompted, confirm the bank account mapping. The BANK_ACCOUNT_NUM in your CSV must exactly match an account already registered under Setup and Maintenance > Manage Bank Accounts.
Run Reconciliation
After import, go to Bank Statement Reconciliation and click Auto Reconcile. Oracle will match statement lines to GL entries using transaction amounts and reference numbers.
Skip the Manual CSV Formatting
Zera Books converts your bank PDFs directly to Oracle-ready CSV format — correct column names, dates, and sign conventions automatically.
Try Zera Books Free ›Common Import Errors and Fixes
These are the most common reasons Oracle rejects a bank statement import file:
| Error | Cause | Fix |
|---|---|---|
| Invalid date format | Date like "01/15/2025" instead of "2025-01-15" | Reformat all dates to YYYY-MM-DD (Cloud) or DD-MON-YYYY (EBS) |
| Bank account not found | BANK_ACCOUNT_NUM doesn't match Oracle setup | Check exact account number in Setup > Manage Bank Accounts |
| Invalid transaction type | TRX_TYPE contains "DR" or "CR" instead of full word | Use DEBIT / CREDIT / MISC exactly |
| Duplicate TRX_NUMBER | Same reference number in multiple rows | Ensure each transaction has a unique reference; append sequence if needed |
| Missing required column | Header typo or extra whitespace in column name | Compare headers exactly against Oracle's required column list |
| Currency code invalid | Using "US Dollar" instead of "USD" | Use ISO 4217 three-letter codes only |
Oracle EBS: GL Journal Import Alternative
In some Oracle EBS configurations, finance teams import bank statement transactions directly as GL journal entries rather than through Cash Management. This is common when the organization has custom reconciliation workflows.
For GL journal import in EBS, the required format differs from Cash Management CSV:
- Segment values must match your chart of accounts exactly
- Period name must correspond to an open GL period (e.g., "JAN-25")
- Journal category and source must be pre-defined in GL setup
- Each transaction becomes two journal lines (debit + credit) for double-entry
The GL journal route is more complex than Cash Management import and typically requires coordination with your Oracle administrator. For most teams, Cash Management import followed by reconciliation is the recommended approach.
See the full Oracle bank statement import guide on Zera Books for Oracle-specific export templates and GL journal format examples.