Are bank feeds accurate enough to skip reconciliation?

No. Bank feeds can duplicate transactions after a reconnect, silently drop ones the bank never pushed, or miscategorize transfers as income or expenses. Reconciling against the actual statement balance each month is still the only way to catch these errors, feed or no feed.

Why does a bank feed only show 90 days of history?

Most feed providers cap how far back they'll pull transactions when an account is first connected, often 90 days to a year depending on the bank and the aggregator. Anything older than that has to come from the PDF statement archive, which is one of the most common reasons bookkeepers end up working from PDFs during a catch-up or cleanup engagement.

What's the fastest way to get PDF statement data into a spreadsheet when the feed doesn't cover the period I need?

Use a PDF-to-spreadsheet converter rather than retyping the statement by hand. A tool like bankstatement.dev extracts every transaction from the PDF, checks the running balance against the statement's printed totals, and exports to CSV, Excel, or a direct QuickBooks or Xero import.

Bank Feeds vs. PDF Statements: When to Use Which

Bank feeds are the default for a reason, but they fail in predictable ways. Knowing when to fall back to the PDF statement — and how to do it fast — keeps your books accurate either way.

What bank feeds do well

Bank feeds earned their default status honestly. Once connected, transactions show up in your ledger within a day or two, categorization rules apply automatically, and you're not manually entering a single line. For a client with clean, consistent monthly activity in a well-supported bank, a feed is genuinely the least amount of work you'll ever do to keep books current. If you've never had a feed break on you, it's easy to assume that's just how bookkeeping works now.

Feeds also shine for day-to-day cash visibility. A client who wants to check their balance doesn't want to wait for a bookkeeper to import a statement; they want to look at a dashboard that updated itself overnight. For that use case, nothing beats a live connection.

Where bank feeds break down

The trouble starts the moment something in the connection isn't perfectly clean. A few patterns show up constantly if you've been doing this more than a year or two.

Missing history is the most common one. A new client connects their account today, and the feed pulls back 90 days, maybe a year if you're lucky. Anything older than that simply isn't there, and a catch-up or cleanup engagement almost always needs more than a year back.

Broken connections are the second. Banks change their authentication, aggregators lose the token, or a client changes their password and the feed silently stops pulling new transactions. You don't always find out right away, because nothing errors loudly. You just notice three weeks later that the register looks thin.

Duplicates after a reconnect are the third, and arguably the most dangerous because they're easy to miss. When a feed reconnects after an outage, it sometimes re-pulls transactions that were already imported, and now you've got the same expense booked twice unless you catch it during reconciliation.

And then there's the accounts a feed simply can't reach at all: closed accounts, some credit unions, certain business card products, and clients who won't grant read access to their banking credentials for a third-party connector. None of that is a bug to fix. It's a structural limit of how feeds work.

When the PDF is the more reliable source

A PDF statement has one property a feed doesn't: it's a closed, dated, bank-issued record that isn't going to change or drop a transaction after the fact. When you're rebuilding a full year of history, reconciling a period where the feed had an outage, or working with an account that never had a feed to begin with, the PDF isn't the fallback option. It's the more trustworthy one.

This is also why even bookkeepers who run mostly on feeds still pull the PDF statement at month-end. It's the tie-breaker. If the feed's running total doesn't match the statement's printed ending balance, the PDF wins, and you go find out what the feed missed.

A hybrid workflow that actually works

Treat the feed as your default and the PDF as your verification and gap-filler, not as competing systems you have to pick one of. In practice that looks like: let the feed handle month-to-month entry for accounts where it's reliable, but pull the PDF statement every month for reconciliation regardless of whether the feed looks fine. For any account with a broken connection, missing history, or no feed support at all, convert the PDF directly and treat that as the primary record for that account or period.

This is also the exact situation described in clients with only PDF statements — the same conversion step just becomes the whole workflow instead of a monthly check, rather than an occasional one.

Getting PDF data into your ledger without re-keying it

The reason PDFs get treated as the annoying option is that retyping a statement by hand is slow and invites errors, especially on a card statement with sixty transactions on it. That's a tooling problem, not a fundamental limitation of PDFs as a source.

A PDF-to-spreadsheet converter removes the retyping step entirely. Feed the statement in, get back a spreadsheet with every transaction parsed, and have the running balance checked against what the bank printed at the top and bottom of the statement. From there it imports into your ledger the same way a feed transaction would, just without the risk of a silent gap or a duplicate you didn't ask for. bankstatement.dev exports straight to CSV, Excel, or direct QuickBooks and Xero import files, which makes the PDF path close to as fast as the feed for a one-time pull.

Once you've built that into your process, the choice between feed and PDF stops being a fight and becomes a routine decision: use whichever one is actually reliable for this account, this period.