Bank feeds in QuickBooks Online

The feed is intake, not accounting

A bank feed connects a bank or credit card account to QuickBooks Online and brings transactions in. That is the whole of what it does, and the distinction matters because of what people assume it does instead.

A downloaded transaction is evidence that money moved. It is not an accounting entry, and its presence in the review queue proves nothing about whether the correct entry exists in the register. QuickBooks will suggest what to do with it, and the suggestion is a guess made from a description string. The decision is still yours, every time.

Treating the feed as the source of truth is how a file ends up with a bank balance that is right and a profit and loss that is not.

Match versus add, which is the entire game

Everything that goes wrong with bank feeds traces back to this one choice.

Match is for a transaction that already exists in QuickBooks. You entered a $1,500 bill payment last week; the bank downloads a $1,500 payment today. There is one real-world event and there should be one accounting record. Matching links the downloaded line to the record already in the register, and the register total does not move.

Add is for a transaction that does not exist in QuickBooks yet. The bank downloads a $75 office supply purchase that nobody entered separately. Adding it creates the record.

The question in front of every line in the review queue is the same one: does this bank transaction already have an accounting record. If the register already shows Office Depot, $125, September 12, and the feed downloads OFFICE DEPOT, $125, September 12, there is one purchase and there should be one expense. Add creates a second.

QuickBooks is reasonably good at proposing the match when the amount and date line up closely. It gets worse as the gap widens, which is why a payment entered on the 1st and cleared on the 8th is a common source of an accidental Add.

The five ways duplicates arrive

Intuit’s own duplicate guidance names most of these, and they all share a shape: something changed about the intake path, and the same real-world transaction came in twice.

Reconnecting an account, which typically backfills a window of history that the file already contains. Uploading a file whose date range overlaps what the feed already downloaded. Adding a downloaded transaction instead of matching it to the record already there. Recording the same sale through two paths, such as a payment processor connected alongside the bank account that receives its deposits. And connecting the same account twice, so both connections deliver the same transactions.

None of those is a bank error. All of them are workflow choices, which is why duplicates cluster around onboarding, reconnections, and staffing changes rather than appearing at random. Once they have accumulated, removing duplicate transactions from a bank feed covers the mechanics, including the awkward case where a duplicate has already been reconciled.

The feed is not the statement

These are two different records and they will not agree on any given day.

The feed can carry transactions the statement has not closed on yet. It can lag the bank by a day or several. Connections break, and pending transactions are not downloaded at all. A feed that looks complete is not evidence that the period is complete.

The statement is the external record, and it is what a reconciliation tests against. The order that works is: bank, then feed, then review and match or categorize, then register, then reconciliation. The order that fails is: bank, then feed, then assume the books are correct.

When the connection breaks

A broken connection does not mean the books are wrong. It means new transactions have stopped arriving.

Update the connection manually from the Bank transactions screen first. If transactions are still missing after that, check the review queue, the excluded list, and the register itself before concluding they were never delivered, because a transaction that was already categorized has left the review queue and looks missing to anyone searching for it there. Intuit also notes that downloads can take time to appear and that pending bank transactions are never downloaded, so a same-day search will find gaps that resolve themselves.

When the connection genuinely cannot retrieve the history you need, QuickBooks supports uploading transactions from a file. That is where the overlap risk lives: if the register already contains transactions through September 20 and the upload starts September 1, three weeks of transactions arrive a second time. The import range should start after the latest transaction already recorded, and Intuit’s own guidance is to check the existing accounts and transactions before uploading rather than after.

Bank rules, and their limits

A bank rule watches for conditions and applies details automatically. QuickBooks Online allows up to 2,000 rules in a file, and a single rule can carry up to 5 conditions.

The conditions themselves are narrower than people expect: Description, Bank text, or Amount, each tested with contains, doesn’t contain, or is exactly. Whether the rule applies to money in or money out, and which account it applies to, are set separately from the conditions rather than being conditions themselves. What the rule then applies is the transaction type, category, tags, and payee.

The distinction between Description and Bank text is worth understanding, because it explains most rules that look correct and never fire. Bank text is the raw string the financial institution sends. Description is what QuickBooks displays after cleaning it up. A rule written against one will not match a string that only appears in the other.

Which transactions deserve a rule

A rule is worth writing when the underlying pattern is genuinely consistent. A monthly software subscription, same vendor, same amount, same category every time, is a good candidate. The rule saves a decision that was never in doubt.

A vendor whose charges are sometimes an expense and sometimes a transfer is a bad candidate, because the rule will be confidently wrong at a rate nobody is measuring. A broad rule keyed on a name that appears in more than one context is worse still: it produces a feed that clears quickly and a general ledger that needs untangling later.

The same reasoning applies to auto-post. It works where the posting carries no judgment. Where a transaction requires a decision, leaving it in the review queue costs a few seconds a month and preserves the decision.

Fixing a downloaded transaction that went in wrong

A transaction categorized incorrectly can be undone and returned to the review queue, or unmatched and recategorized, from the Bank transactions screen.

That gets meaningfully harder once the transaction has been reconciled. Changing a reconciled transaction moves the beginning balance of the following period, which is one of the standard causes of a reconciliation that suddenly refuses to tie. Before correcting a reconciled transaction, work out what the correction does to the periods after it: undoing a reconciliation in QuickBooks Online covers what that costs.

What a feed and a reconciliation each prove

The feed brings activity in, suggests matches, and can create duplicates when used carelessly. The reconciliation compares the register against the statement, tests completeness and timing, and is where duplicates and omissions surface. They are complementary, and neither substitutes for the other.

A clean feed makes reconciliation fast. A reconciliation is what makes the feed trustworthy. The failure mode of skipping the second is a file where every transaction was categorized and nobody ever checked whether the set was complete.

A workable sequence: update the connection, review what came in, match what already exists, categorize what genuinely does not, exclude what does not belong in the books, investigate anything that looks duplicated, review the rules that fired, and then reconcile against the statement. The order matters because reconciliation should not be where you first discover the feed has been adding duplicates for six months.

When it has already gone wrong

A file where transactions were added instead of matched for a year has duplicated expenses spread across reconciled periods, which cannot be deleted without moving balances somebody has already signed off. Sorting that out means walking back through the affected periods rather than patching the current one, which is cleanup work:

$99 per month of backlog

Standardizing how feeds get set up in the first place is the cheaper half of the problem, and duplicates across a client roster covers the setup choices that produce them. Pricing for cleanup and for a monthly close is on the pricing page.