Why the Format Matters More Than Most Firms Realise
When a client sends through a bank statement, the format it arrives in determines how much work stands between that file and a clean reconciliation. Most firms treat this as a minor logistical detail. It is not. The format is where errors are introduced, hours are lost, and reconciliation problems that look complex turn out to trace back to a date field formatted the wrong way or a column that dropped during export.
CSV is the most common format clients send and the most likely to fail on import. Xero accepts CSV files but requires a very specific structure: either three columns (Date, Description, Amount) or four columns (Date, Description, Debit, Credit), with dates formatted as DD/MM/YYYY for Australian organisations. If the bank exports dates as YYYY-MM-DD or any other variation, Xero rejects the entire file. A single rogue comma in a transaction description can break the import completely because CSV uses commas as delimiters, so a description that contains one pushes every subsequent field into the wrong column. Banks do not format their exports with Xero in mind. The firm has to fix the file before the import will work, and finding the problem line in a 300-row statement takes time.
OFX is the cleanest option when it is available. It is a structured data format that Xero and MYOB both import without requiring column mapping, and it carries transaction data in a way that is far less likely to produce parsing errors. The problem is that not every Australian bank offers OFX exports. Smaller regional banks, credit unions, and some business accounts only provide CSV or PDF. For clients at those institutions, OFX is not an option regardless of how the firm would prefer to work.
Where PDF Creates the Biggest Risk
PDF is the format that causes the most downstream problems because it is not an importable format at all. Neither Xero nor MYOB can ingest a PDF bank statement natively. A PDF has to be converted to CSV or OFX before it can go anywhere near the accounting software, and that conversion step is where data quality problems are introduced. Conversion tools, whether manual or automated, misread transactions when the PDF layout is complex. Multi-column layouts, subtotal rows, page breaks mid-transaction, and merged cells in the source document all create parsing errors that appear in the converted file as missing transactions, incorrect amounts, or descriptions split across two rows.
The risk is not that the conversion obviously fails. It is that it partially fails in a way that looks correct on first glance. A statement with 180 transactions that converts to 177 rows does not throw an error. It just produces a reconciliation that will not balance, and tracking down three missing transactions in a completed import is slower than catching the problem at the conversion stage.
The practical reality for most Australian firms is that PDF statements are unavoidable for a portion of the client base. Some banks only issue PDFs. Some clients download PDFs because it is the easiest button to click on their banking portal. Building a firm policy that specifies OFX where available, CSV as a fallback with defined formatting requirements, and a consistent conversion process for PDFs reduces the number of import failures the team has to troubleshoot each quarter.
The Takeaway
The format a bank statement arrives in is not a preference issue, it is a data quality issue. OFX is the lowest-risk option and should be requested wherever the bank supports it. CSV works but requires formatting that matches the accounting software exactly, and that rarely happens without manual cleanup. PDF requires a conversion step that introduces its own errors and should be treated as a last resort rather than a default. Firms that document which banks their clients use, which formats those banks support, and what the internal process is for each one stop losing time to import failures and start treating statement handling as a solved problem.
