Why Half Your CAS Clients Have a Broken Bank Feed

TL;DR. At any given Tuesday, roughly half the bank feeds in a 60-client CAS book are broken, mid-reconnect, or returning stale data. This is not an outage. It is the steady state. The cause is structural: OAuth migrations roll through banks on bank-by-bank schedules, credit unions still run on screen scraping, and aggregator reconnection rates run 15-25% per year (Plaid 2025). Most CAS firms absorb the cost as silent bookkeeper overhead, usually 8-12 hours per 100 client connections per month. The firms that price it correctly are the ones that track which clients break, who, and how often.

Open your QuickBooks Online Accountant dashboard. Pull up your monthly-close client list. If you have 60 active clients, roughly 30 of them have at least one bank feed that is currently broken, stuck in OAuth re-auth, or returning stale data more than 48 hours old. You will find this out on Tuesday morning when a senior bookkeeper messages you that the Bank of America connection on the medical practice client stopped pulling four days ago, and the local credit union feed on the construction client has been silent since last Thursday. This is not an outage. This is the steady state.

The math is brutal. According to the AICPA's 2025 Practice Economics Survey, bank reconciliation is the single largest consumer of non-advisory staff hours at firms offering bookkeeping services, averaging 11.3 hours per client per month. For a 60-client book that is 678 hours per month on reconciliation alone, four full-time bookkeepers matching transactions. Bank-feed maintenance eats roughly 10-15% of that. You are spending one full bookkeeper-equivalent every month on a problem that did not exist when you sold the engagement.

The shape of the problem

The 60-client number is not arbitrary. It is the band where most $4M-$8M CAS firms sit: enough clients to need three to five dedicated bookkeepers, not so many that you have a dedicated technology operations role.

Each client averages 2.5 bank and credit card accounts feeding into QuickBooks Online or Xero. That puts a 60-client firm at 150 active feed connections, give or take. At a 20% annual reconnection rate (the midpoint of Plaid's published 15-25% range for forced reauths), that is 30 events per year that are not a real problem, just QuickBooks asking the client to re-authenticate because the data token expired or the bank rotated something on its side.

But forced reauths are only one source of broken feeds. The bigger sources are OAuth migrations, credit union breakage, and the long tail of bank-side changes that Intuit lumps under errors 155, 192, 324, 390, and 1000. Once you add those in, the steady-state broken count climbs to 8-12 feeds out of 150 at any given moment. About one in 15 connections.

That is the "half your clients" framing. Most clients have 2-3 connections. If 8% of connections are broken, the probability that at least one of a client's 2-3 connections is broken is closer to 20-25%, not 50%. The "half" comes in when you include feeds that are technically working but returning stale data, feeds that pulled this morning but are missing transactions from the prior 72 hours, and feeds that look healthy until you actually try to reconcile.

The Rutter team has written about this gap: "A bank feed can stay technically up and still be operationally untrustworthy." That is the version of broken your bookkeeper finds at month-end, not on the dashboard.

Three reasons it keeps happening, all structural

Bank feeds do not break because aggregators are incompetent. They break because the underlying system has three structural problems that no single party owns.

OAuth migration is bank-by-bank, on the bank's schedule

Intuit's OAuth rollout has been running for years and is still not finished. Banks switch when they switch. Each migration is a 30-day window per institution. Your client receives an email and an in-product banner. If they ignore both, the feed goes silent on day 31.

The error code that fires is 390: "Your bank is making a change. Until you upgrade your bank connection, your transactions will automatically stop flowing into QuickBooks." The official fix is for your client to log in and re-authorize. The actual fix is your bookkeeper noticing at month-end, calling the client, walking them through the OAuth screen on a Zoom call, and backfilling three weeks of missing transactions via CSV. Intuit's help docs note that the QuickBooks Online mobile app will not complete OAuth correctly; it redirects to a browser, which most non-accountant clients abandon halfway through.

A 60-client firm sees four to eight OAuth migration windows per quarter, mostly clustered around regional bank waves. You cannot batch them. You can only watch for them.

Credit unions still run on screen scraping

This is the one nobody talks about. Most national banks have moved to OAuth. Most credit unions have not. The independent reporting on this frames it well: credit union feeds usually run on screen scraping. The aggregator logs in as the member, fetches transactions from the member portal, and parses the resulting HTML.

That model breaks whenever the credit union updates its member portal, changes its login flow, adds a new security question, or rolls out a new multi-factor provider. The aggregator detects the break, updates the scraping logic, and ships the fix, usually within days. In the meantime, the feed silently stops returning new transactions.

Worse, most credit unions do not offer an accountant access channel. The bookkeeper either gets the client's primary credentials, which violates the engagement letter and the aggregator's terms of service, or works without direct access at all. The second option means the client emails PDF statements every month, until the client forgets, and then the bookkeeper finds out at quarter-end that the construction client's primary credit union account has been missing 11 weeks of transactions.

If you have three or more credit union clients on your book, you can probably name which credit union always breaks in the third week of the month. That recognition is the tell that it is a structural problem, not bad luck.

Aggregator reconnection rates are 15-25% per year

Plaid covers most of QuickBooks Online's US bank feeds. Plaid's own published economics put forced reconnection at 15-25% of links per year. For a 150-connection book, that is 23-38 forced reauths per year, on top of OAuth migrations and credit union breakage.

A forced reauth is not the same as a broken feed. The aggregator is doing what it should: requiring a periodic re-authentication for security. But the burden of completing the re-auth falls on the client, who does not know what Plaid is and is not watching their QuickBooks Online inbox. So the practical effect is the same: the feed goes silent, your bookkeeper finds out at month-end, and you absorb the rework.

Plaid's connection success rate is roughly 85%; Yodlee's is closer to 80%. The 2026 Fintegration benchmarks put Plaid's uptime at 99.95%. Those are good numbers for an aggregator. They are still terrible numbers for a CAS firm trying to close 60 books in five days. At 99.95% uptime, you are still looking at four hours of feed unavailability per month, and that unavailability is not evenly distributed.

The errors, ranked by how much time they cost you

Field experience with CAS books, ranked by per-incident bookkeeper time:

• Error 1000 ("Fix your bank connection"). Standard reconnect flow, 15-25 minutes including the client call. The most common code. Most QuickBooks Online help threads about bank feed problems eventually point at this error.
• Error 390 (OAuth migration). 30-45 minutes including the OAuth walkthrough, plus 1-2 hours of CSV backfill if the client missed the 30-day window.
• Error 324 (account not found). 45-60 minutes. Triggers when the bank renames an account, issues a new account number, or moves the account to a different server. The fix is a full disconnect and reconnect, plus a manual review of pending transactions to prevent duplicates.
• Error 155 (bank no longer supports connection). 2-4 hours over multiple touches. Often resolves on its own when Intuit and the bank work it out, but until it does, you are running on manual CSV imports.
• Error 192 (additional sign-in required). 30-60 minutes. Usually a new MFA requirement at the bank. Fix is to disable MFA for one day, refresh the feed, then re-enable. The 2021 QuickBooks Community thread on this issue is still active in 2026; the problem has not gone away.
• Error 103 (credentials invalid). 10-20 minutes if the client knows their current bank login. Longer if they do not.

The pattern: the codes that look most alarming are not the most expensive. Error 1000 is the highest-volume code, accounts for the largest share of bookkeeper time per month, and is the one your bookkeeper sees five times per week and treats as background noise.

What it actually costs

Run the numbers on a 60-client book:

• 150 active feed connections
• 25-35 forced Plaid reauths per year
• 15-25 OAuth migration events per year (more if you have a regional-bank-heavy book)
• 10-20 credit union breakages per year per credit union client, so call it 30-60 events depending on book composition
• Total: 70-120 reconnection events per year
• Average bookkeeper time per event: 45-90 minutes including detection, client outreach, the reauth itself, and the CSV backfill when transactions are missing

Roughly 60-120 hours per year on bank-feed maintenance alone, or 5-10 hours per month, on top of the 132 reconciliation hours (60 clients × 2.2 hours) the AICPA benchmark predicts. About 4-8% of total bookkeeping capacity goes to keeping feeds alive.

Sage's 2025 Accounting Technology Report put automated bank matching accuracy at 99.6% versus 94.2% for manual matching. The accuracy gap is real, but it understates the picture because both numbers assume the feed is actually running. The matching engine cannot match what the feed did not pull.

What firms actually do about it

Almost nothing systematic. Most CAS firms swallow the cost as bookkeeper overhead. The bookkeepers run a tribal-knowledge process: scan QuickBooks Online Accountant every morning for the red "Action needed" tags, work through whichever look urgent, leave the rest for next week. The cost is real but invisible because it is distributed across staff time, not a line item.

A few firms have moved past that pattern. They typically do three things:

1. Track which clients break, and how often. A spreadsheet is enough to start. The firms that do this find that 20% of their clients account for 60-70% of feed-maintenance time. Usually the credit-union-heavy ones, the small medical practice with three vendor accounts that nobody can find the password for, and the construction client with the personal-and-business co-mingled account at the regional bank that just got acquired.

2. Price the maintenance. Add bank-feed health to the engagement letter. Most clients will not push back. They do not know what a normal cost structure is. Charging an extra $50-$100 per month per client for a "bank-feed health" line item recovers most of the cost and changes the bookkeeper's incentives, because now the work is billed instead of absorbed.

3. Centralize who owns it. Stop distributing bank-feed maintenance across bookkeepers. Pick one senior associate or manager whose Monday morning job is to triage the firm-wide bank-feed status, contact clients pre-emptively for OAuth migration windows, and own the credit-union backup process (usually monthly PDF statement uploads on a defined cadence). The same hours, concentrated on one person, accomplish more than the same hours spread across five.

The firms doing this do not eliminate the broken-feed problem. They make it a known cost instead of an invisible one.

Where we come in

We have built bank-feed health monitors for two CAS firms in the last six months. A dashboard that pings QuickBooks Online and Xero APIs every six hours, flags feeds that have not pulled in 48+ hours, and surfaces them to a firm-wide queue before the month-end bookkeeper finds the gap. The first version took four weeks. The second version, which adds pre-emptive OAuth-migration alerts when Intuit pushes the 30-day banner to a client, took another three.

If your firm is running 60+ monthly-close clients and you can name the three credit unions that always break in the third week of the month, you already know the shape of the problem we solve. Book 30 minutes here and we'll show you what the dashboard looks like.

---

Keep Reading

• How $40M CAS Firms Cut Monthly Close From 12 to 5 Days. The full close-cycle workflow that handles bank-feed breakage as part of a predictable monthly process instead of a fire drill.
• How $40M CPA Firms Cut 1040 Cycle Time From 8 Days to 3. The tax-season analog: where the bottleneck actually lives in mid-market CPA firms, and how to move it.