Why won't a bank feed connect for some clients?

The most common reasons are closed or dormant accounts still needed for history, older statement periods that predate the feed's lookback window, credit unions and small community banks with weak or unsupported connections, and clients who simply refuse to link accounts for privacy or security reasons. None of these are fixable by retrying the connection.

Is working from PDF statements less accurate than a bank feed?

Not if you verify it properly. A bank feed can silently miss transactions or duplicate them during a reconnect. A PDF statement is a closed, dated record from the bank, and if your converted spreadsheet's totals match the statement's beginning and ending balances, you have strong proof the data is complete.

How do I get PDF statements into QuickBooks or Xero without retyping everything?

Convert the PDF into a spreadsheet or a direct import file first, then bring that into your ledger. A tool like bankstatement.dev turns a PDF into CSV, Excel, or a QuickBooks/Xero-ready file with the running balance checked against the statement, so you're importing verified data instead of retyping line items by hand.

When Your Client Only Has PDF Statements (No Bank Feed)

Some clients will never give you a live bank feed. Here's how to build a clean, reliable workflow around PDF statements instead of fighting for a connection that isn't coming.

Why some clients never get a bank feed

At some point, almost every bookkeeper hits the same wall: a client hands you a folder of PDFs and says "this is what I have." No live connection, no bank feed, just statements. Before you push back and ask them to link the account, it helps to know that the refusal often isn't laziness. It's usually one of a few real, unfixable reasons.

The account might be closed. You still need six months of history from a business checking account the client shut down last year, but a dead account can't feed anything. The statement period might predate what the feed can reach; most bank connections only pull back 90 days to a year, and a catch-up job or an audit request often needs three or four years back. The bank itself might be the problem. Plenty of credit unions and small community banks have thin or unreliable data connections, and feeds from them drop transactions or disconnect randomly. And sometimes it's simply a client who doesn't want to hand over banking credentials to a third-party connector, full stop. That's a reasonable stance, not an obstacle to argue away.

The cost of forcing a bank feed that won't work

It's tempting to spend an hour troubleshooting a connection that keeps failing, or to ask the client three more times to "just try reconnecting it." That hour is a sunk cost you don't get back, and it delays the actual work. Meanwhile the statements have been sitting in your inbox the whole time, fully capable of getting the books current today.

There's also a quieter cost: clients notice when you seem stuck. A client who already feels behind on their books doesn't want to hear that their bookkeeper is blocked because a bank won't cooperate. Pivoting to "no problem, send me the PDFs" is often the more professional move, not the fallback one.

Working efficiently from PDFs instead

Once you accept that PDFs are the source of truth for this client, the workflow looks different, but it doesn't have to be slower. The old-school approach was retyping every line from the statement into a spreadsheet or manually keying transactions into QuickBooks. That's the part worth eliminating, not the PDF itself.

A statement converter takes the PDF and produces a structured spreadsheet with dates, descriptions, and amounts already parsed out. The best ones also check the running balance against the statement's printed beginning and ending balance, so you know before you import anything whether a transaction got dropped or misread. That balance check matters more for PDF work than for bank feed work, because there's no live connection quietly reconciling itself in the background. You have to verify it yourself, once, and then trust it.

From there, importing into your ledger is the same as any other import: map the columns, run your categorization rules, and reconcile against the statement total. The converter at bankstatement.dev handles the PDF-to-spreadsheet step and outputs formats built for this, including QuickBooks-ready files and Xero imports, so the manual data entry disappears from the process entirely.

Handling clients with a mix of feeds and PDFs

Most PDF-only situations aren't actually all-or-nothing. A client might have three accounts with live feeds and one closed account you need for history, or a checking account that connects fine and a credit card that doesn't. Treat these as two parallel processes rather than trying to force everything through one pipeline.

Keep the feed accounts on autopilot the way you normally would, and build a short, repeatable PDF process for the rest: convert, verify the balance, import, reconcile. Once you've done it for one client, the steps don't change from client to client, only the bank templates do. Standardizing this now saves you from reinventing it every time a new client shows up with "just PDFs."

Building it into your standard process

The clients who only have PDFs aren't going away, and honestly, they shouldn't be treated as an exception you tolerate. Some of your steadiest, longest-tenured clients are the ones who prefer paper-trail control over automatic feeds. Build a process that assumes PDFs will show up, rather than one that assumes they won't.

That means having a converter workflow ready before the next client hands you a folder of statements, agreeing on a naming convention for how they send files, and knowing which output format your ledger prefers. Once that's set up, a PDF-only client isn't harder to onboard than a bank-feed client. It just uses a different first step.