Why Bank Feeds Stop Working, and What On-Demand Imports Fix

- 7 min read

The most expensive bookkeeping problem is not an error. It is a feed you believed was running that quietly stopped weeks ago, discovered while preparing a VAT return with a hole in it.

Open Banking access is granted, not given

When you connect a bank account to accounting software, you are not handing over a password. You are granting a time-limited, read-only permission at your own bank, which the bank can end and which expires by design.

That expiry is a feature. An access grant that lasted forever and could not be seen or revoked would be a much worse arrangement for you. But it does mean every background bank feed has a clock running on it.

How it fails quietly

When a consent lapses, nothing dramatic happens. The software simply stops receiving new transactions. There is no gap where a gap should be visible, because a feed that has fetched nothing looks identical to a week where nothing happened.

The failure surfaces later, usually at a deadline, as a set of figures that are wrong in the same direction: costs missing, income missing, and a VAT return that does not match reality.

  • The last imported transaction is older than it should be, and nobody looked
  • A quiet trading period is indistinguishable from a broken connection
  • Reconnection notices go to an email address nobody reads
  • The figures still reconcile internally, because the missing rows were never there to contradict anything

Check the date of your most recent imported transaction before you trust a period's figures. It is the one number that tells you whether the feed is alive, and it takes five seconds to read.

The on-demand alternative, and its honest trade-off

An on-demand import inverts the arrangement. Instead of a standing consent working in the background, you authorise at your bank at the moment you want to import, and the transactions come across then.

The gain is that silent failure becomes structurally impossible: an import either happened while you were watching or it did not happen. The cost is real too, and worth stating plainly. You have to trigger it, and each import reaches back a recent window rather than your entire history, so it is the wrong tool for a catch-up covering closed periods.

This is how bank imports work in Taxmo for UK accounts. It is not the arrangement every product chooses, and for someone reconciling weekly a background feed genuinely is less work. For someone who touches their books once a quarter, an import they performed themselves is the more trustworthy of the two.

Why a CSV statement is still the reliable route

For any period older than a connection's window, a statement you export yourself has no such limit and no consent to expire. It is the least fashionable option and the most dependable one.

It also has a property worth valuing: what you uploaded is what you have. There is no question of whether a sync ran, because you can see the file. For a first-time catch-up across several quarters, this is the route to use.

Whichever route, imported is not counted

Both connections and uploads should land transactions in a review queue rather than straight into your figures, because an unreviewed import is a guess about what a payment was for.

The consequence is specific rather than philosophical. Transactions sitting unapproved are outside your VAT return, so filing while a batch is pending files an understated return. Software that reports a return as ready while imports are unreviewed is not saving you time, it is arranging a correction.