Exporting a CSV during a bank feed outage feels like control. The file downloads, the numbers look complete, the ledger accepts the upload, and from the outside nothing appears to have been lost. That is exactly why it is the most common fallback when a feed fails, and also why it is so easy to underestimate. What the export hides is how much the data has quietly changed on the way out of the bank, and those small changes are what turn one visible problem, the outage, into several invisible ones that only surface at BAS.
Why a CSV changes the shape of your transactions
A bank CSV is not a neutral copy of the feed data. It is a simplified snapshot taken at a single moment, and simplification always loses something. Descriptions truncate or reformat. Dates shift depending on the export settings. Grouped transactions split or merge depending on the range you select. None of it triggers an error on import, so the data passes through looking valid, but it is no longer identical to what the live feed would have delivered.
The problem compounds when the export gets repeated, which it almost always does during an outage as balances update through the day. Each new CSV overlaps with the last, and without a clean way to compare them, it becomes genuinely hard to tell which transactions are new and which were already processed. Duplicates are rarely obvious. Missing rows do not announce themselves. The reconciliation still balances, but often only because an error in one place is quietly offset by an error somewhere else in the file. That is how a silent inconsistency gets embedded in data that looks, by every surface measure, completely fine.
Why the real problems appear weeks later
CSV risk almost never shows up at import. It shows up at review, long after the outage is forgotten. By BAS preparation, the accountant notices that GST takes longer to confirm than it should, that merchant patterns feel slightly inconsistent, that certain transactions need checking twice even though they were reviewed once already. The hesitation is real, but the cause feels disconnected from the feed outage weeks earlier, because the outage is no longer visible in the file. Only its effects are.
This risk is made worse by the fact that most software guidance is no help here. The articles explain how to import a CSV successfully, step by step, but not what happens afterwards. They do not address how repeated exports, partial date ranges, and manual fixes interact over time, because the underlying assumption is that once the data loads, the problem is solved. In a real workflow that assumption breaks down almost immediately, and the gap between "the file imported" and "the file is trustworthy" is precisely where the risk lives.
How experienced firms handle CSVs during outages
Firms that consistently avoid this treat a CSV as temporary material, not a final input. Before anything reaches the ledger, the export goes through a separate step where descriptions are normalised, duplicates are removed, and transaction completeness is actually confirmed rather than assumed. That draws a clear line between the workaround and the record, so the messy interim data never quietly becomes the official history.
The point is not to avoid CSVs. They are unavoidable, and there is nothing wrong with using one to keep a file moving through an outage. The point is to contain them, so a simplified snapshot taken under pressure does not silently reshape the file you lodge from. The safest firms are not the ones who never reach for a workaround. They are the ones who put a boundary around it before a temporary fix hardens into permanent risk.
