QuickBooks Online users fill feed gaps with manual uploads and strict file rules

QuickBooks Online downloads bank and card transactions on its own once an account is connected, but the feed only reaches back so far. When the history runs deeper, or a bank will not connect at all, the manual upload is the remaining route. A community thread on the problem carried a marked solution from Intuit, and we walked it end to end. The interesting part is not the upload button; it is the narrow set of file rules wrapped around it.

The gap the feed cannot fill

A connected account downloads transactions only up to a certain date, and everything earlier has to arrive some other way. Three situations push users toward a manual upload. The history is older than the download reaches, the bank does not appear when searched for, or the account will not link. The guidance applies to Simple Start, Essentials, Plus, Advanced, and Sole Trader plans.

One piece of preparation sits above the rest. Decide whether the incoming transactions belong in one account or in several, and set up parent accounts and subaccounts on the chart of accounts before the first upload. That early decision is what keeps a mixed import from landing in the wrong place.

How far back does the account already go?

Duplicates are the main hazard when history is added by hand, and the first safeguard is a date. From the accounting menu, open the chart of accounts, find the target account, and open its history. The oldest entry on record, usually the opening balance, sets the boundary. A ledger started partway through the year shows the pattern: months before the feed begins still need importing, and the boundary is easy to miss. Note the date before you export anything.

Export from the bank with overlap built in

The next step happens on the bank’s own website. Sign in there and export the statement period you need; every institution places its export controls differently. If the bank offers a QuickBooks Online data format, take it, since those files are built for this import. A standard CSV works too, along with the other supported types.

Set the export range to begin at least one day before the oldest transaction already in the account, as the guidance directs. Then save the file somewhere easy to find, such as your desktop.

The file rules that decide whether an upload lands

This is where rejected files and garbled rows come from, and the guidance is unusually precise. The file must be in English and no larger than 350 KB. It needs three columns, Date, Description, and Amount, or four, Date, Description, Credit, and Debit.

The header row carries its own requirements. If the credit and debit columns include the word amount in their titles, delete that word. Cells that hold only a zero should be left blank. Strip stray numbers out of the Description column. Keep every date in one consistent format; the guidance recommends dd/mm/yyyy. Some banks stamp the weekday beside each date, and that label belongs in a column of its own.

Large histories go up in batches

Old accounts rarely fit inside the size cap in a single file. The guidance shortens the date range and downloads the transactions in smaller batches, uploading each one in turn. The cap applies per file, so a long history simply arrives in pieces. It is slower, and every file stays inside the limits the importer accepts.

Bank rules sort the entries on arrival

Categorising a long import by hand is its own project, and the guidance offers a shortcut. Set up bank rules before you upload, and incoming transactions are assigned as they arrive instead of reviewed line by line afterwards. The import then finishes with most of the sorting already done.

The steps themselves are short, and the upload route works when they run in order. What separates a clean import from a rejected file is preparation: the boundary date, the account structure, and a tidy file of three or four columns inside the cap. That is the substance of the fix the thread settled on.