Drop in a PDF bank statement and get structured rows you can paste into the Oracle Fusion Create Bank Statements spreadsheet: date, description, amount, transaction type, and balance. Built for the accounts your bank never sends a BAI2 file for. Start free, no credit card.
Upload your bank statement
Drop file here or click to upload
PDF, JPG, PNG, BMP, HEIC, TIFF, MT940
Uploading...
Oracle Fusion Cash Management parses BAI2, SWIFT MT940, EDIFACT FINSTA, and ISO 20022 camt.052 and camt.053 files, and it accepts .txt, .dat, .csv, .xml, and .ack extensions. It does not read a PDF. When a bank will not deliver a structured statement file, Oracle expects you to use the Create Bank Statements in Spreadsheet template for the non standard format. Upload the statement PDF here, get every transaction as a dated row with description, amount, and running balance, then map those columns into the spreadsheet template and load it. Last updated July 2026.
The Fusion side of this is well documented and works. The problem is upstream, in the accounts that never produce a file Oracle can parse.
The Load and Import Bank Statement process expects BAI2, MT940, FINSTA, or a camt XML file. A PDF e-statement has no parser behind it, no matter which extension you rename it to.
Balance reporting files are a cash management product. Regional banks, credit unions, and many non US banks holding subsidiary accounts simply do not offer one, or want a monthly fee for it.
After an acquisition the target company brings months of history in PDF form, long before anyone sets up a transmission with its bank. The opening reconciliation still has to happen.
Once an account is closed the bank stops transmitting. If a period was missed, the saved statement PDF is the only remaining source for those entries.
Create Bank Statements in Spreadsheet solves the format problem, but somebody still has to key several hundred lines into it, and every keystroke is a reconciliation break waiting to happen.
Submit Autoreconciliation matches on amount and date. One transposed figure does not just sit there, it fails to match and lands in an exception queue somebody has to work.
The output is column data, not a text dump, so mapping it into the Create Bank Statements template is copy and paste rather than reformatting.
Booking date, value date where the statement shows one, description, reference, debit, credit, and balance each get their own column.
Fusion validates statement lines against opening and closing balances. The converter keeps the balance column from the PDF so those totals tie before you load anything.
Amount and direction come out separately, which is what you need before mapping to a CE_TRX_TYPE transaction type value.
Load twelve monthly PDFs together and get one continuous sheet in date order, then split it by period as you load each statement.
Take the .xlsx for review or the CSV for a downstream script that builds the FBDI or spreadsheet upload for you.
Nothing connects to your Fusion instance, your WebCenter repository, or your bank. You upload a document and download a spreadsheet.
This is the path for the accounts that have no electronic feed behind them.
Upload the PDF above. Every transaction line comes back as a row with date, description, amount, and balance.
Tip: Upload a full quarter at once if you are catching up.
Open the Create Bank Statements in Spreadsheet template from the File-Based Data Import guide, then paste your columns into the matching template columns. Keep the template column order intact and hide the ones you do not use rather than deleting them.
Tip: Transaction Type values come from lookup type CE_TRX_TYPE, and balance codes from CE_INTERNAL_BALANCE_CODES.
Upload the completed spreadsheet, then check the Bank Statements and Reconciliation Overview page and run autoreconciliation once the statement lines and balances look right.
Tip: Tie the closing balance to the PDF before you submit reconciliation, not after.
Usually the person who owns the reconciliation and has been handed a stack of PDFs instead of a file.
Bring subsidiary, foreign, and low volume accounts into Cash Management without waiting on a bank to build a transmission.
Close the month when one account never delivered its BAI2 file and the bank cannot resend it in time.
Load conversion period statements during a Fusion implementation, before any bank interface has gone live.
Get an acquired entity onto the corporate chart of accounts using the statement history it actually has, which is PDFs.
Oracle Fusion Cash Management ships with parsers for BAI2, SWIFT MT940, EDIFACT FINSTA, and the ISO 20022 camt family: camt.052.001.01 for intraday, and camt.053.001.01, .02, and .03 for prior day statements. The import process accepts files with .txt, .dat, .csv, .xml, and .ack extensions. Anything outside that list, including a PDF e-statement, has to be brought in through the Create Bank Statements in Spreadsheet template instead.
| What the bank gives you | Oracle Fusion path | Effort |
|---|---|---|
| BAI2 file | Load and Import Bank Statement, standard parser | Automated, nothing to do |
| camt.053 XML | Load and Import Bank Statement, ISO 20022 parser | Automated, nothing to do |
| SWIFT MT940 | Load and Import Bank Statement, MT940 parser | Automated, nothing to do |
| Bank specific CSV | Custom parser configuration, or spreadsheet template | Setup project |
| PDF e-statement only | Convert to rows, then Create Bank Statements in Spreadsheet | Minutes per statement |
For a supported format, the manual route runs through Oracle WebCenter Content. You take the file from the bank, compress it into a .zip, transfer it into the fin/cashManagement/import account using File Import and Export, then run the Load and Import Bank Statement process, choosing the format and pointing at the zip. Optional parameters let you flag the file as intraday and submit autoreconciliation straight after the load. Results show up on the Bank Statements and Reconciliation Overview page.
For anything Oracle cannot parse, the manual route is the spreadsheet template. You get it from the File-Based Data Import for Oracle Financials Cloud guide, under File-Based Data Imports, then Import Bank Statements. The tooltips on each column header spell out what belongs in the field. Two things trip people up: the column order must stay as shipped, and the Transaction Type and Balance Code values are lookup driven, so they have to match the meanings defined under CE_TRX_TYPE and CE_INTERNAL_BALANCE_CODES rather than whatever the bank called them.
Ask, always. A real transmission is better than any conversion. It fails in three common situations. The bank does not offer balance reporting for that account tier, which is normal for smaller institutions and for accounts held abroad. The setup takes weeks of paperwork and testing while the close is next Friday. Or the account is already closed, so there is nothing left to transmit and the PDFs you archived are the only record of those entries.
No, and it is worth being precise about that. The output is a spreadsheet of transaction rows, meant for the Create Bank Statements in Spreadsheet path or for your own loader. If you already have a BAI2 or camt file, Oracle should parse it directly and this tool has nothing to add. This is for the gap where no such file exists. If you need to read a BAI2 file you already hold, the BAI to Excel converter turns those record types into readable columns, and the camt.053 to Excel converter does the same for the XML.
Autoreconciliation gets you most of the way and leaves a queue. The usual residue is timing differences, deposits in transit, and bank charges nobody had booked yet. Because the converted sheet keeps the description and reference text, you can sort by description and clear whole categories at once instead of chasing single lines. If the entity also needs its transactions coded before they hit the general ledger, you can categorize the transactions from the same sheet, and if a subsidiary keeps its books outside the ERP a CSV to QBO converter gets the same rows into QuickBooks without a second extraction. Other borrower and vendor documents that arrive as PDFs in the same close can be handled with document data extraction.
Out of the box Oracle Fusion Cash Management supports BAI2, SWIFT MT940, EDIFACT FINSTA, ISO 20022 camt.052.001.01, and camt.053.001.01, .02, and .03. The import process accepts .txt, .dat, .csv, .xml, and .ack file extensions. Formats outside that list go through the Create Bank Statements in Spreadsheet template instead.
No. There is no PDF parser in Cash Management, and renaming the file does not help. The supported route for a non standard source is to get the transactions into rows first, then load them with the Create Bank Statements in Spreadsheet template. Converting the PDF here produces exactly those rows.
Zip the bank file, transfer it into the fin/cashManagement/import account in WebCenter Content using File Import and Export, then run Load and Import Bank Statement with the format and data file parameters set. You can also tick intraday and submit autoreconciliation. Check results on the Bank Statements and Reconciliation Overview page.
It is Oracle's supported way to load statements for any non standard format. You download it from the File-Based Data Import for Oracle Financials Cloud guide under Import Bank Statements, fill the columns, and upload. Do not reorder columns, and make sure Transaction Type and Balance Code match the CE_TRX_TYPE and CE_INTERNAL_BALANCE_CODES lookups.
No. It outputs Excel and CSV rows for the spreadsheet load path. If your bank already sends a BAI2 or camt.053 file, load that directly through the standard parser, which is always the better option. This exists for accounts where no structured file is available at all.
Convert the PDF history into a single sheet, split it by statement period, and load each period through the spreadsheet template so the opening and closing balances match the statement. That gives Cash Management a clean starting point before the new bank transmission is set up.
Yes, when the statement prints one. Keeping the balance column matters because Fusion validates statement lines against the control totals, so being able to tie the last converted row to the closing balance on the PDF catches an extraction problem before it becomes a reconciliation exception.
Yes. Intraday statements load through the same process but with the intraday parameter selected, and they are informational rather than the prior day statement you reconcile against. Most PDF conversion work sits on the prior day side, since intraday reporting is only ever delivered as a file.
The same problem in an SAP shop.
Read a BAI2 file you already have.
Turn camt.053 XML into readable columns.
Volume conversion for finance teams.
From the same family of tools
Get started converting bank statements to spreadsheets.
USD
per month
billed as
$288 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale statement conversion across your team with automation.
USD
per month
billed as
$888 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise-grade bank statement conversion and controls.
USD
per month
billed as
$ yearly
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
