NAB feed outages are a normal part of working with Australian clients, and when one hits, the outage itself is rarely what causes the damage. What causes it is the manual CSV export that keeps the file moving afterwards, because NAB's exports carry small formatting quirks that slip into the ledger unnoticed and only surface weeks later at BAS time. The firms that come through a NAB outage cleanly are the ones that treat that exported data as something to review before trusting, not something to push straight through.
Why NAB feed outages force risky workarounds
Bank feeds exist to hide complexity. When a NAB feed drops, that complexity lands straight back on the accountant, usually at the worst possible point in the quarter. The obvious fix is to export a CSV from NAB and keep going, and that is what most firms do. The catch is that NAB exports are not consistent. The format can shift depending on the account type, the export method, and the date range you pull, so two files that look identical can behave differently once they are in the ledger. Under a deadline that inconsistency is easy to underestimate. The data looks usable, the work continues, and nobody stops to ask what the export quietly changed.
This is why activity around NAB bank feed problems and manual CSV reconciliation climbs whenever a feed goes down. Accountants are not looking for an explanation of the outage. They are trying to keep a file accurate while still moving at the pace the deadline demands.
What quietly breaks after the CSV goes in
The problems a NAB export introduces almost never show up at import. They show up later, when someone finally looks at the file closely for BAS, and by then the errors are weeks old and harder to trace.
The recurring ones are consistent:
- Duplicate transactions where an export overlaps with a partially restored feed
- Date formatting that shifts transactions into the wrong period
- Descriptions shortened or altered, which quietly breaks the categorisation you rely on
- GST context missing, so the treatment has to be worked out again by hand
None of these throws an obvious error. The reconciliation still looks close to balanced, the totals still look reasonable, and that is exactly what makes them dangerous. The file feels fine while its accuracy is slowly eroding. So when BAS preparation begins and the numbers have to hold up, GST takes longer to confirm, reconciliations need a second and third look, and the totals need more explaining than they should. In most of these cases the BAS is not where the problem started. It started weeks earlier, the moment NAB data was imported without a proper review stage.
How experienced firms protect themselves during NAB outages
Firms that ride out NAB disruptions without downstream damage tend to do one thing consistently. They keep data repair separate from lodgement. Rather than adjusting transactions directly inside the ledger, they isolate the exported data first, clean and normalise it, and review it in bulk before any of it goes back into the system. That gives them a clear record of what changed and stops a rushed fix from turning into a permanent blind spot. It also takes the pressure off the person doing the work, which matters more than it sounds, because fatigue is one of the biggest sources of reconciliation error during a busy period.
NAB outages are going to happen, and manual CSV workarounds are a normal part of real accounting work. The risk was never the outage itself. It is letting a temporary fix flow into the ledger without a single clear moment to check it. The firms that avoid the downstream BAS mess are not the ones moving fastest through the disruption. They are the ones that give themselves room to review, confirm, and actually trust the data before they lodge.
