How to Import a Bank Statement into Oracle Fusion Cash Management

Last updated July 2026.

Oracle Fusion Cash Management imports a bank statement through the Load and Import Bank Statement process, which reads BAI2, SWIFT MT940, EDIFACT FINSTA, and the ISO 20022 formats camt.053 for the end of day statement and camt.052 for intraday reporting. The process runs in three phases, validates the data against your setup before it lands, and supports an intraday option for mid-day files. Most import failures come down to an unmapped code or a file the parser cannot read cleanly, both of which are easier to fix once you can see the raw data as rows.

The three phases of the electronic bank statement process

Oracle splits the import into retrieve, load, and import so a problem in one stage does not corrupt the next.

1. Retrieve. The file is collected from the bank or an external source and stored in the database. Many teams upload it manually to the document repository instead of using an automated transmission.
2. Load. Oracle parses the retrieved file and populates the bank statement interface, the staging area, according to the selected format.
3. Import. The staged data is checked against functional validations, then written into the bank statement tables where it becomes available for reconciliation and the cash position.

The formats Oracle Fusion accepts

The format you pick in the process has to match the file the bank sent, and each format carries its own code mapping.

The import accepts files with .txt, .dat, .csv, .xml, and .ack extensions, which matters when a bank hands you a camt file without the .xml extension you expected.

How do I import an intraday bank statement into Oracle Fusion?

Run the Load and Import Bank Statement process, select the format such as camt.052 or BAI2, choose the file from the document repository, and set the Intraday parameter. Then pick the intraday type: Cumulative means each file restates the entire day so far and supersedes the last, while Incremental means each file adds only the entries since the previous one. Choosing wrong is a classic double counting trap. If your bank sends cumulative snapshots and you load them as incremental, you understate the day, and if you stack incremental files as if each were the full picture, you overstate it. Confirm with the bank how their intraday feed is configured before you schedule it.

What is a code map group, and why it matters

A code map group maps the transaction and balance codes in the bank file to the internal codes Oracle uses, and each group is assigned to one format. Oracle ships mappings for the common BAI and EDIFACT balance codes, but bank specific transaction codes usually need to be added. When a statement imports yet lines come through uncategorized, or an opening or closing balance is missing, an incomplete code map group is the first place to look. Building these maps well during implementation is what makes reconciliation clean later.

Why did my bank statement fail to import into Oracle Fusion Cash Management?

Because the import validates before it writes, one bad line can stop the whole file, and the error message rarely points at the exact entry. The quickest diagnosis is to open the raw file as a spreadsheet and read it. A BAI to Excel converter turns a BAI2 file into dated rows with type codes and amounts, a camt.053 to Excel converter flattens the ISO 20022 statement XML, a camt.052 to Excel converter does the same for the intraday report and flags booked versus pending entries, and a MT940 to Excel converter reads the SWIFT statement. With the data in columns you can spot the unmapped transaction code, the unexpected format version, or the malformed entry in seconds, then fix the code map group or ask the bank to resend a clean file.

Uploading the file when there is no automated feed

Many teams do not run an automated transmission from the bank and instead upload the statement by hand. In that case you place the file in the document repository, often as a compressed .zip, and point the Load and Import process at it. A few practical rules save time here. Keep one bank account per file where you can, since a mixed file is harder to trace when a single line fails. Confirm the character encoding is what Oracle expects, because a camt file saved in the wrong encoding can load with garbled descriptions even when the numbers are right. And keep a copy of the original file, not just the imported result, so that if a balance looks wrong later you can compare what the bank sent against what Oracle stored. When you want that comparison in a form a person can actually read, converting the raw file to a spreadsheet gives you the same rows Oracle parsed, side by side with the reconciliation.

Reconciliation and the cash position after import

Once the statement lands in the bank statement tables, it drives two things: reconciliation against your system transactions and the cash position that treasury watches. Automatic reconciliation matches statement lines to payments, receipts, and journal entries using the rules you set up, and anything unmatched drops to manual review. This is where clean code mapping pays off, because a well mapped transaction code lets the matching rules fire instead of leaving lines stranded. Intraday files feed the position without posting, exactly as they should, so the end of day camt.053 or BAI2 statement remains the source you reconcile and account from.

When the statement only comes as a PDF

Sometimes there is no data file at all, only a PDF statement from a bank that is not on the automated feed or an account added after go live. Oracle cannot import a PDF, so convert it to structured rows first. The main bank statement converter reads a PDF statement into the same dated columns you would get from a BAI2 or camt file, which you can then load through a CSV-friendly path or key against the reconciliation. If you are unsure which format a bank actually sent, the bank file format converter compares BAI2, MT940, camt.053, and camt.052 side by side so you select the right one before you run the process.

After the statement is in

Once the file is imported and reconciled, the data feeds the cash position and the downstream close. Teams that also code card spend and receipts alongside the bank feed often pair the statement flow with automated expense capture so nothing is keyed twice. And for the intraday side specifically, remember the distinction that trips most people up: camt.052 and MT942 are provisional views for positioning cash, while camt.053 and MT940 are the final statements you reconcile and post from.