Bank feeds versus statement conversion: what a feed cannot prove

The feed has been running all month, transactions arrived every morning, and the reconciliation still does not agree. Nothing in the ledger told you that. There is no error, no gap marker, no warning banner: just a closing figure that is short by one transaction you now have to find by eye against a printed statement.

That is the structural problem with a bank feed, and it has nothing to do with which ledger you use. A feed hands you rows. It does not hand you a way to check whether those rows are all of them.

First, check what the bank will hand you directly

Before converting anything, look at what your own bank offers. Most online banking portals will export transactions as CSV, OFX or QBO, and when that download covers the exact period you are missing, it is the shortest path there is. No recognition step, no layout to interpret, nothing to proofread. Check it before you do anything else.

Then check what it actually gave you, because the gap it leaves is where the rest of this comes in. Download windows are commonly capped, 90 days on some portals and 18 months on many others, while the statement archive behind the same login goes back years. Raw exports frequently arrive with no running balance column, which removes the one field you would reconcile against. Descriptions are often truncated to a fixed width, so the reference that identifies a transfer is gone. A closed account exports nothing at all. And in every case the export covers the period the bank chooses to expose, which is not always the period you were asked to produce.

When the export reaches your period and carries a balance column, use it. When it does not, the statement documents are what remain, and they are also what the accountant, lender or auditor will be holding.

Start with the criterion that matters

Before comparing routes, fix the standard. For any period you will sign off, file, or hand to an accountant, the question is not how the transactions arrived. It is whether you can prove the period is complete.

The strongest check available on a bank account is arithmetic: take the opening balance, add every credit, subtract every debit, and land on the printed closing balance. When it lands, the rows are arithmetically consistent with the period the bank declared, and the error that does the most damage cannot hide, because a wrong digit in an amount breaks the chain. When it does not land, the difference is usually the exact value of what is missing.

Be precise about what that buys you, because it is worth more when stated honestly. The balance chain says nothing about whether a date or a description is right, and two errors that offset each other exactly will pass it. What it does is catch a misread or dropped amount, automatically, on every row, without anyone remembering to look. Nothing else in a bookkeeping workflow does that.

A feed does not carry the anchors that test needs. Some connections display a current bank balance in the ledger, which is useful, but what arrives as data is a stream of transactions without the statement's opening figure, closing figure or declared period. You can absolutely reconcile a ledger built from a feed, and firms do it every month, but only by fetching the statement and checking the feed's rows against it. The statement was the authority all along.

Where a feed stops

Four limits follow from how feeds are built, so reconnecting the account does not fix any of them.

• It starts at or near the connection date. Backfill depends on the bank, the aggregator and the ledger. Some connections reach back months, a few reach further, and some deliver nothing before the day you linked the account. You do not find out which until you look. Onboard a client in July, ask for January to June, and the feed may have no answer. This is the shape of the problem whenever the answer is to go back and convert a year of statements into one spreadsheet.
• It can break without announcing it. Credentials expire, banks change authentication flows, aggregators drop a day. Sometimes the ledger raises a reconnection prompt. Sometimes it raises nothing and simply holds fewer rows than the statement does, and you find that at reconciliation, which is the expensive place to find it. Repairing it means backfilling after a feed stops syncing from the statement covering those exact days.
• It cannot reach a closed account. There is no connection to make once the account is gone, and closed accounts turn up constantly: consolidated banking, wound up entities, a departing partner. Whatever was downloaded before it closed is what you have, and when that is nothing, the statement set is the surviving record.
• It does not cover every institution. Regional banks, credit unions, foreign accounts and newer providers frequently sit outside the aggregator's coverage, and coverage moves in both directions. An institution supported last year can drop off after an API change, with no notice to you.

There is a quieter cost too. Feeds normalise descriptions, and truncated payee text with merged references is common in feed data, though how much survives varies by bank. Where the statement carries the fuller description, that is often the difference between a categorisation rule that lasts a year and one you rewrite every quarter.

The statement is the record; the feed is a copy

This is what decides which one you trust when they disagree. The statement is what the bank asserts about the period, anchored at both ends. Everything downstream of it, including the feed, is a convenience copy that has lost those anchors.

Conversion keeps them. A converted statement arrives with its opening and closing balances attached, so every row can be checked against the one before it and the whole file checked against the statement's own figures. Anything that does not add up is flagged for review rather than handed over silently wrong. That is the difference worth paying attention to: the feed gives you rows, and conversion gives you rows plus an arithmetic verdict on the amounts.

Running both without creating duplicates

Most client files end up mixed, and the failure mode when you combine routes is duplication: the same transaction arriving once from the feed and once from a converted file. A boundary date prevents it.

1. 1

   Find the feed's true first date

   Locate the earliest transaction the feed actually delivered into the ledger, not the date the connection was created. They are often different.
2. 2

   Cover the earlier period

   Take the earlier history from the bank's own export if it reaches that far. Where it does not, or where it arrives without a balance column, convert the statement documents covering those months and nothing that overlaps the feed's range.
3. 3

   Cut the file at the boundary

   Remove any rows dated on or after the feed's first transaction date before you import. A day of overlap is a day of duplicate risk, and ledger duplicate detection is not something to lean on when a date filter settles it.
4. 4

   Import and review what is flagged

   Import the trimmed file and work through the ledger's duplicate warnings rather than accepting the batch outright.
5. 5

   Check the seam

   Compare the ledger balance at the boundary date against the statement balance on the same date. Agreement is strong evidence the join is clean, because a duplicated or dropped amount would push the two apart. It will not catch a duplicate and an omission that cancel, so scan the cleared transactions either side of the boundary as well.

The same procedure repairs an outage gap: identify the missing days, convert, trim to exactly those days, import. If duplicates do slip through, tracking down the row that throws the balance off is far easier when you know precisely which range was doubled, which is the reason to keep the boundary explicit rather than approximate.

Deciding for a specific account

Run the decision per account, not per firm. Does the period you need to produce start before the feed's first delivered transaction? Then the earlier part comes from the bank's export where it reaches, and from statement documents where it does not. Does the account still exist, and is the institution supported at all? If not, the archived statements are the route, permanently. And for any period that has to be defensible, what in your workflow checks the amounts against the bank's own opening and closing figures? If the honest answer is that you do it by hand at month end, that is the job worth automating, because it is the one that gets skipped when the week runs late.

A feed is a convenience for the days it happens to cover. The statement is the record you stand behind, and converting it is how the arithmetic that backs it gets run in minutes rather than over an afternoon of manual entry.