Your bank feed stopped syncing and you need to backfill by hand

A broken bank connection does not just stop delivering transactions, it leaves a hole in the register that reconnecting often will not close on its own. How much history a restored connection pulls back varies by bank, by account type and by the data provider sitting behind the feed, and it is commonly shorter than the outage. If the feed went down in April and you noticed in July, do not assume the reconnection covers the whole period. Reconnect, look at the earliest date that actually arrives, and plan on filling everything before it from the statements yourself.

That is the situation this page addresses: the register has a start date, an end date, and nothing in between, and the books cannot close until the middle is filled with transactions you can prove are complete.

Reconnect first, then measure what is actually missing

Reconnect the feed before anything else, because the answer changes what you have to do. When it resumes, look at the earliest transaction that arrived, not at the date the connection was restored. Those are rarely the same, and the earliest arriving transaction is the real boundary of your gap.

Then measure the gap against the statements rather than against the feed. Take the last transaction sitting in the register before the outage and the first transaction the reconnected feed delivered. Everything between those two dates is what you need, and the statements covering that period are the authority on what it contains. A feed is a delivery mechanism; a statement is the bank's own periodic record of the account, and it is the document that states how many transactions there were and what the balance was at each end. Other records from the bank can carry the same information, but the statement is the one that presents it as a closed period with opening and closing figures, which is exactly the shape a backfill needs to be checked against.

Write down three numbers before you go further: the balance in the register at the last good date, the closing balance on the final statement in the gap, and the total number of transactions the statements list across the period. Those three numbers are how you will know when the backfill is done.

Completeness is the standard, not convenience

The temptation at this point is to grab whatever transaction data is easiest to obtain and push it in. That is how gaps get half filled.

A raw transaction export is data without evidence. Most of them omit the running balance entirely, and many truncate the description text partway through the payee name. Without a running balance there is no way to demonstrate that the opening balance plus every movement in the file equals the closing balance printed on the statement, which means there is no way to show that nothing was dropped. You end up asserting the backfill is complete rather than proving it, and the first sign that it was not is a reconciliation that will not clear three weeks later.

Converted statements close exactly that gap. The statement carries the opening and closing balance for the period, and most layouts carry a running balance on every line as well, so a conversion that verifies each row against the one before turns those figures into evidence rather than decoration. That is the strongest automatic check a backfill can be given: a wrong amount anywhere in the file breaks the chain arithmetically and cannot be absorbed. It does not certify dates or descriptions, and it would survive a dropped row paired with a duplicated row of the same value, which is why the transaction count belongs in the check alongside it. That is the standard worth holding a backfill to, because a backfill is the one import nobody double checks.

Handling the overlap so nothing imports twice

Duplicates are the reason careful people dread backfilling, and they come almost entirely from the boundaries: the day the feed stopped and the day it resumed.

Why matching on date and amount is not safe

The obvious approach is to import everything and then delete whatever looks like a repeat. This fails on real data more often than people expect. A pair of identical direct debits on the same day, two card payments to the same merchant for the same amount, a transfer split into equal parts: all of these are legitimate distinct transactions that a date plus amount comparison flags as duplicates. Delete them and the account is now short, which is a harder error to find than a duplicate because nothing looks wrong until the balance disagrees.

Cut on a boundary date instead

The reliable method is to decide the boundary before importing rather than clean up afterwards.

1. 1

   Identify the last complete day the register already holds

   Not the last transaction, the last full day. A day that is partially present is the most dangerous case, because it looks covered.
2. 2

   Identify the first complete day the reconnected feed delivered

   Apply the same rule at the other end of the gap.
3. 3

   Trim the backfill file to the days strictly between them

   Delete every row outside that range from the file before you upload it. This is the step that prevents duplicates, and it happens in the file, not in the software.
4. 4

   Handle the two boundary days by hand

   Compare the statement's entries for those two days against what the register holds and add only what is missing. There are rarely more than a few.
5. 5

   Import the trimmed file

   Map the columns explicitly and confirm the date format before accepting the mapping defaults.
6. 6

   Reconcile each month in the gap separately

   One month at a time, against that month's printed closing balance. Do not reconcile the whole gap in one pass.

What the file format contributes

Format choice changes how much help you get, not how careful you have to be.

The OFX family, which includes QBO and QFX, has a field for a per-transaction identifier, and files produced by banks and by converters generally populate it. That gives accounting software something to match against when a range is imported twice, which is the practical argument for the format over CSV. Do not treat it as a guarantee. The identifiers are only as unique as whatever generated them, and whether your software checks them at all, and on which import path, varies by product and by version. Check your own import screen rather than assuming the file defends itself.

CSV has no equivalent field. Your accounting software may still offer its own review step, where imported rows sit in a holding area and can be excluded before they post, and it is worth learning where that step lives in the product you use. But nothing in the file itself stops a second copy of an overlapping range, so trimming the range before upload is the defence you control. The same comma handling that makes statement conversion to CSV reliable also determines whether the rows you trim are the rows you think you trimmed.

Whatever the format, look for duplicates after the import rather than assuming they were prevented. The transaction count check below is what finds them.

Confirm the gap is closed

Three checks, in this order, and each one catches a different failure.

In prose: the register balance at the end of the backfilled period must equal the closing balance printed on the last statement in the gap, the number of transactions you added must equal the number the statements list, and every month in the range must reconcile on its own. Matching the end balance while the transaction count is wrong means you have both a duplicate and a missing row cancelling each other out, which is the worst outcome and the one that only per-month reconciliation exposes.

After the books are square

Once the gap is closed, the import mechanics for your specific software are a separate matter. If the upload itself is being refused, the accepted formats and column shapes are covered in the guides to QuickBooks Online rejecting a statement upload and Web Connect QBO file errors in QuickBooks Desktop.

Feeds break for ordinary reasons: a changed password, a new security prompt, a bank migrating its online platform. They will break again. What makes the next outage a short job rather than a long one is having a repeatable way to turn the statements for any period into transactions whose totals you can prove, on demand, without waiting for a connection to come back.