How to Import Bank Statements into Odoo (PDF & Formats)

To import bank statements into Odoo, you first need the transactions in a structured file format that Odoo can read. Odoo does not accept a PDF bank statement natively. It imports bank transactions only from structured formats: CAMT.053 (recommended for SEPA), OFX, QIF, CSV, and CODA (Belgium). A PDF has to be converted to one of these before Odoo will touch it, and CSV should be treated as a last resort, because its column mapping and date-format handling cause errors that fail silently rather than warning you.

That single fact is where most people get stuck. The bank often hands you a PDF, and historical statements are almost always PDF-only, so you hit a wall before Odoo's importer is even in the picture. The Odoo bank statement import wizard is happy to load a clean OFX or CAMT.053 file in seconds, but it has nothing to do with a PDF.

So the job has two parts, and the rest of this guide follows that shape. First, get the statement into a clean structured file that Odoo accepts. Second, run it through Odoo's bank statement importer and move into reconciliation. The sections below cover which format to use, the exact import path and the test step that catches mistakes before they reach your books, how to avoid the silent CSV failures, and how to convert a PDF or scanned statement reliably when that is the only file you have.

Odoo's Supported Statement Formats and When to Use Each

Odoo's supported bank statement formats are not interchangeable, and choosing the wrong one is the most common reason an import goes badly. Two of them are purpose-built banking formats, two are fallbacks, and one is regional.

OFX and CAMT.053 are the formats to reach for first. Both were designed to carry bank transaction data, so they encode dates, amounts, signs, and balances unambiguously. When you import one, there is almost nothing to configure, because the file already describes its own structure. CAMT.053 is the ISO 20022 Bank to Customer Statement (camt.053) message that banks use to deliver electronic account statements, and that standardization is precisely why an importer can read it and cannot read a PDF: the PDF is a document for human eyes, while CAMT.053 is a defined data structure a machine can parse field by field.

QIF is an older interchange format. It works as a fallback when your bank offers it and you cannot get OFX or CAMT.053, though it carries less detail than the two banking formats.

CSV Odoo will accept, but it is a generic spreadsheet format with no banking schema of its own. That means you are responsible for getting the columns and the value formatting right, and when something is off, the import can load wrong data or nothing at all without an obvious warning. Treat CSV as the last resort, behind OFX, CAMT.053, and QIF.

CODA is the Belgian banking format. If you bank in Belgium, your bank likely offers CODA files, and Odoo imports them directly.

There is a clear order of preference here: an Odoo OFX import or an Odoo CAMT.053 import first, QIF if neither is available, and CSV only when you have no other option. Which formats you can actually get depends on your bank and your region. CAMT.053 is the recommended format across SEPA, the European payments area, while CODA is specific to Belgium. Before you resort to CSV or to converting a PDF, check whether your bank offers a direct OFX or CAMT.053 export from its online portal, because a native banking-format export sidesteps the column-mapping and date-format problems entirely.

How to Import a Bank Statement in Odoo, Step by Step

Once you hold a supported file, the import itself is short. From the Accounting dashboard, find the card for the relevant Bank journal, then choose Import Statements. You can also reach it from the journal's options menu (the three-dot icon) as Import Statement. Select your file, and Odoo opens the import widget.

The widget does the work that matters. It sets the formatting options for the file, maps the file's columns to Odoo's fields, and gives you a chance to check the result before anything is committed. For a CSV you will confirm which column is the transaction date, which is the label or memo, which is the amount, and which is the running balance. For an OFX or CAMT.053 file most of this is already determined by the format.

Use the Test step. Before you import, Odoo can preview how the file will land, and that preview is where you confirm the dates read correctly, the amounts are right, and the signs are pointing the way you expect, with money out as negative and money in as positive. Catching a reversed sign or a misread date here takes a moment; catching it after the lines are in your books and partly reconciled does not.

After the import, the statement lines sit ready for reconciliation against your invoices, bills, and payments, which is the whole reason for bringing the statement in. Clean intake at this step is what makes reconciliation fast rather than a manual hunt.

This disciplined intake mindset is not unique to bank statements. It is the same principle on the payables side of Odoo, where supplier documents are digitized and routed before they hit the ledger. If you are setting up Accounting end to end, it is worth seeing how Odoo's vendor bill OCR handles digitization and PO matching and how to set up vendor bill approval workflows in Odoo, since bank intake and vendor bill intake are the two halves of keeping the books current. And when you are back-loading payables in volume rather than one document at a time, the same structured-file discipline applies to bulk importing vendor bills into Odoo from an Excel or CSV file.

Avoiding the Silent CSV Import Error

CSV is the format most likely to waste an afternoon. It carries no banking schema, so Odoo relies entirely on you to map the columns and format the values correctly, and when something does not line up, the import can bring in wrong data, or nothing, without an obvious error.

The most common version of this is the date. Odoo expects dates in YYYY-MM-DD form, and when the date column is in any other layout you get the error time data does not match format '%Y-%m-%d'. The fix is to format the date column as YYYY-MM-DD before you import and to confirm in the import wizard that the date column is mapped to Odoo's date field. A statement that lists dates as 31/01/2026 or Jan 31 2026 will not parse until it reads 2026-01-31.

A CSV that imports cleanly needs a few things to be right:

• Date column in YYYY-MM-DD.
• Amount handling with a consistent sign convention, debits negative and credits positive, or two clean columns that separate debits from credits.
• Description or memo column so each line is identifiable during reconciliation.
• Balance column where the statement provides a running balance, which helps Odoo confirm the import is complete.

The single-amount-column versus separate-debit-and-credit-column decision matters because each is mapped differently in the wizard. If your file uses one signed amount column, map that one column and make sure the signs are correct. If it splits debits and credits into two columns, map both, and check that the wizard reads a debit as a reduction and a credit as an addition. Mixing the two conventions, or leaving the signs ambiguous, is a frequent cause of a statement that imports but reconciles to nonsense.

When CSV is unavoidable, never skip the test step.

The Odoo 18 Enterprise PDF and OCR Option, and Its Limits

Odoo 18 Enterprise added a built-in PDF and OCR bank statement import that attempts to read a PDF statement directly, extracting the transactions without you converting the file first. The same release also relaxed an older constraint: Odoo 18 now tolerates transactions that are not sorted by date, which previously could trip up an import.

This is genuinely useful in narrow cases, but it is not the answer for most workflows, and it is worth being clear about why. By practitioner accounts the Odoo 18 bank statement OCR is not yet reliable for high-volume use. It can misread amounts, dates, or descriptions on real statements, and at volume those misreads become a reconciliation problem rather than a convenience. Reserve it for the occasional statement where no structured format is available, and always verify its output against the source PDF before you reconcile.

There is also an edition and version boundary to keep in mind. The built-in PDF OCR is an Odoo 18 Enterprise capability. If you are on Odoo Community, or on Odoo 17 or earlier, you do not have it at all and will need to convert your PDF to a structured format regardless.

Placed in the decision tree, the OCR option sits in the middle. Try a native banking-format export from your bank first. If only a PDF exists and you are on Odoo 18 Enterprise, the built-in OCR may handle a low volume with careful checking. For anything you need to be reliable, or for more than a handful of statements, a dedicated conversion step is the stronger path, and that is what the next section covers.

Converting a PDF or Scanned Statement into an Odoo-Ready File

Everything in the format hierarchy assumes you already hold a structured file. For a large share of real statements, you do not, and the conversion is the actual work. Before Odoo's import wizard ever opens, the PDF or scan has to become a file with the right columns, the right date format, and the right sign convention. Get that file right and the import is trivial; get it wrong and you are back to the silent CSV failures.

A conversion fit for Odoo has to produce the same things a clean CSV needs: dates in YYYY-MM-DD, a consistent amount sign convention or cleanly separated debit and credit columns, a description or memo column, and a balance where the statement provides one. The goal is not just "a spreadsheet" but a spreadsheet that maps to Odoo's fields on the first try.

The hard inputs are the ones no bank export and no Odoo import module addresses, because they assume a digital file to begin with. Scanned statements, photographs of a statement taken on a phone, and several accounts batched into one PDF all fall outside what a clean export covers, yet they are exactly what bookkeepers are handed in practice. This is the gap that sits in front of Odoo's importer.

This is where extraction software earns its place in the workflow. A tool built to read financial documents lets you convert a PDF or scanned bank statement into an Odoo-ready CSV by uploading the statement and describing the output you need. With this product you upload the PDF, JPG, or PNG, write a short prompt for the structure you want, and download a structured CSV (or Excel or JSON). For an Odoo import you would prompt for the columns and formatting the wizard expects, for example dates formatted as YYYY-MM-DD, one row per transaction, and a single signed amount column. Because it reads both native and scanned PDFs and handles lower-quality scans and phone photos, the messy inputs that defeat a bank export become workable, and a single batch can carry many statements or pages at once.

When you control the output structure at conversion time, the file maps cleanly in Odoo's import wizard without a second pass. If you want the broader picture beyond Odoo, our guide to methods to convert a bank statement PDF to Excel or CSV walks through the general approaches and their trade-offs.

Handling Historical, Multi-Account, and Multi-Currency Statements

The basic import path covers the routine case. Three situations need more care, and they are common enough that most Odoo users hit at least one.

Historical statements. Banks rarely re-issue OFX or CAMT.053 files for past periods. Online portals typically expose structured exports only for recent months, while older statements are available as PDF and nothing else. When you are back-loading history into Odoo, whether opening a new database, migrating from another system, or catching up months of neglected reconciliation, a reliable conversion step is usually the only practical route, because the structured file you would prefer simply no longer exists.

Multi-account statements. In Odoo each bank account maps to its own bank journal, and a statement import targets a single journal. When several accounts arrive together, in one combined PDF or one export, the transactions have to be separated by account and imported into the correct journal rather than merged. Pulling the accounts apart at the conversion stage, into one clean file per account, keeps each journal accurate and avoids transactions landing against the wrong bank.

Multi-currency statements. Foreign-currency lines need the correct currency carried through on import so that reconciliation and currency valuation stay accurate in Odoo. The source file has to state the currency and the amounts clearly, and the journal and import need to be set up to handle the foreign currency rather than treating the figures as your company currency. A statement that mixes currencies without labeling them is a common source of valuation errors after import.

Across all three, the shape of the work is the same one this guide opened with: get the data into a clean structured file, then import it. That shape is not specific to Odoo. If you also run other systems, the same logic applies to the same bank-statement import workflow in QuickBooks and to importing bank statements into Xero across formats, where the platform changes but the convert-first-then-import discipline does not.