When a bank feed fails, the fallback is a manual import, and the first decision is which format to pull: CSV, OFX, or PDF. Most people grab whatever the bank offers by default and think no more about it, but the format is not a neutral choice. Each one carries the data differently, preserves different information, and fails in a different way, and that choice quietly determines how much cleanup you are signing up for and how much BAS risk you are importing along with the transactions. The short version is that the three are not equally safe, and the one most people reach for first is usually the riskiest.
How the three formats actually differ
CSV is the most common and the most treacherous, precisely because it looks the most usable. It is a plain spreadsheet, so it opens cleanly and feels transparent, but it has no fixed standard. Every bank exports a different column layout, dates arrive in inconsistent formats, debit and credit values are sometimes collapsed into one column, descriptions get truncated, and nothing in the file enforces any of this. It imports without complaint and carries its errors silently, which is the worst combination. OFX sits at the other end. It is a structured financial exchange format built specifically for accounting data, so it preserves transaction dates, amounts, and unique transaction identifiers in a defined structure that software can read consistently. Because it carries those unique identifiers, it is also far better at preventing duplicates, since the system can recognise a transaction it has already seen. Where a bank offers OFX (sometimes labelled QIF or QFX), it is almost always the cleaner import. PDF is the odd one out, because it is not really transaction data at all, it is a picture of a statement. It has to be extracted or converted before it can be used, and every conversion is a chance for a number to be misread, a column to be misaligned, or a row to be dropped. A PDF is the most human-readable and the least machine-reliable of the three.
Where each format breaks the BAS
The failure modes follow directly from how each format is built. CSV breaks through silent inconsistency: a date format that shifts transactions into the wrong period, a merged debit-credit column that reverses a value, a truncated description that defeats categorisation, none of which throws an error, all of which move the BAS. It is also the format most prone to duplicates, because without unique identifiers the system cannot tell a re-imported transaction from a new one, so a CSV that overlaps a recovering feed doubles up transactions that still reconcile. OFX fails far less often, but it is not immune: some banks generate slightly non-standard OFX, and it can still overlap a feed if the date ranges are not controlled, though its transaction identifiers usually catch the duplicate that a CSV would miss. PDF fails at the point of extraction, and its errors are the hardest to spot afterwards, because a misread figure looks exactly like a correct one. A "9" read as a "4", a row silently dropped during conversion, a total that no longer matches the underlying lines: none of it announces itself, and by BAS time the source PDF is rarely reopened to check. In every case the pattern is the same. The format determined how the error entered, and reconciliation, which only checks the ledger against the bank, will not catch any of them.
How to choose and control the import
If the bank offers a choice, prefer OFX, because a structured format with unique transaction identifiers removes the two biggest manual-import risks, inconsistent structure and duplicates, before they start. Use CSV when it is the only structured option, but treat it as material to be reviewed rather than trusted: confirm the date format, check how debits and credits are represented, and control the date range so it cannot overlap a feed. Treat PDF as a last resort, and when it is unavoidable, verify the extracted totals back to the statement rather than assuming the conversion was clean, because that is the one check that catches a misread number. Across all three the discipline is the same, define exactly what date range you are importing and check it against existing feed activity so you never cover the same days twice. The format sets the baseline risk, but the boundary you put around the import is what keeps a fallback from turning into a BAS problem weeks later.
