How to import bank statements into QuickBooks Online in 2026

Of every recurring task in a bookkeeping month, "import the bank statements" is the one that surprises people the most. The bank's PDF arrives, QuickBooks Online won't take it, the live bank feed broke again at 2 a.m. last Tuesday, and the CSV the bank emitted has a column layout that didn't exist last quarter. This is a practical, end-to-end guide to landing those statements in QBO cleanly in 2026 — what formats it actually accepts, the exact upload wizard, what to do when bank feeds fail, the per-bank quirks that catch people out, multi-currency rules, and the recipe for batching the work when you're running more than three or four clients.

What QuickBooks Online actually accepts in 2026

QBO has four ways to get a transaction into the For Review tab:

1. Live bank feed.QBO connects to your bank via Intuit's aggregator (a mix of MX, Plaid, and direct Open Banking rails depending on region) and pulls transactions automatically. Fast when it works. Brittle when it doesn't. Coverage is excellent in the US and Canada, partial in the UK and Ireland, and patchy elsewhere in Europe.
2. .qbo file (Web Connect / OFX 1.0.2). The format QuickBooks itself uses for bank-feed downloads. Plain text under the hood, with structured fields — BANKID, ACCTID, CURDEF, and per-transaction FITIDs — that QBO consumes without a column-mapping step.
3. .qfx file.Quicken's OFX dialect. QuickBooks Online accepts it for completeness; functionally interchangeable with .qbo for our purposes.
4. .csv file. The fallback when neither feed nor OFX works. Three or four columns, header row, and a column mapping step you have to redo each time the bank tweaks its export.

Conspicuously absent: PDF. QBO does not import PDF bank statements directly. Intuit's separate "Receipts" feature (under Bookkeeping → Transactions → Receipts) takes PDFs and JPGs — but it's designed for expense receipts, one transaction per file, not statements with hundreds of rows. Drop a monthly statement into Receipts and QBO will read the top line and ignore the table. For the actual monthly close on a current account, you need to convert the PDF into one of the three accepted formats first.

Anatomy of a .qbo file — what's actually inside

It helps to know what QBO is reading when it accepts (or silently rejects) your upload. A .qbofile is OFX 1.0.2 plain text with an SGML-style envelope. Open one in any text editor and you'll see something like this:

OFXHEADER:100
DATA:OFXSGML
VERSION:102
SECURITY:NONE
ENCODING:USASCII
CHARSET:1252
COMPRESSION:NONE
OLDFILEUID:NONE
NEWFILEUID:NONE

<OFX>
  <BANKMSGSRSV1><STMTTRNRS><STMTRS>
    <CURDEF>EUR
    <BANKACCTFROM>
      <BANKID>SOGEFRPP
      <ACCTID>30003-12345678901
      <ACCTTYPE>CHECKING
    </BANKACCTFROM>
    <BANKTRANLIST>
      <DTSTART>20260501
      <DTEND>20260531
      <STMTTRN>
        <TRNTYPE>DEBIT
        <DTPOSTED>20260503
        <TRNAMT>-42.30
        <FITID>20260503-4230-9F2C
        <NAME>SEPA DD Stripe Inc
      </STMTTRN>
      ...
    </BANKTRANLIST>
  </STMTRS></STMTTRNRS></BANKMSGSRSV1>
</OFX>

Five fields decide whether QBO accepts the file and routes it correctly:

• CURDEF— must match the QBO bank account's configured currency exactly. EUR ≠ EURO ≠ €. Three letters, ISO 4217.
• BANKID— a routing-style identifier. For US banks it's the 9-digit ABA routing number. For international banks it's the BIC/SWIFT code. QBO uses BANKID plus ACCTID as the unique key when matching the file to one of your linked accounts.
• ACCTID — your account number, often masked. QBO caches the (BANKID, ACCTID) → QBO account mapping so subsequent uploads skip the picker.
• FITID — the per-transaction stable ID. Re-uploads with the same FITID are silently deduped. Random FITIDs on every conversion = guaranteed duplicates on every re-import.
• DTPOSTED — always YYYYMMDD(no separators). Localised dates here will be rejected with a generic "invalid file" error and no line number.

If you have a .qbothat QBO won't accept, opening it in a text editor and scanning these five fields is the fastest debugging route. Most rejections trace to CURDEFmismatch, a stray Unicode character in NAME (the OFX encoding is Windows-1252 by default), or a malformed DTPOSTED.

The decision tree: which path for your file

Before you click anything, answer one question: what did the bank give you? The right import path follows directly:

• You have a live feed that works →let it run; reach for a manual import only for the months it skips or banks it doesn't cover.
• Bank offers .qbo / Quicken Web Connect download → use it directly; no conversion needed. Common at Chase business, Bank of America, US Bank, and most US credit unions.
• Bank only gives PDF → convert to .qbo via a converter, check the reconciliation badge, upload. This is the path for almost every non-US bank and most personal accounts.
• Bank only gives CSV → convert to .qbo via our free CSV → QBO tool if you want stable FITIDs and zero column mapping, or upload the CSV directly and live with the column-mapping wizard each time.
• Bank gives MT940, CAMT.053, or proprietary XML → convert to .qbo first. Common with Deutsche Bank, Commerzbank, ING, BNP Paribas, and SEPA Direct Debit reports.
• You're on QuickBooks Self-Employed →CSV only. The Self-Employed product doesn't accept OFX-family files. The conversion and locale rules below still apply.

The recommended workflow — PDF to QBO in five steps

This is the workflow we recommend for almost every client. It works for QuickBooks Online and Desktop, for any locale, and survives the common failure modes:

1. Get the PDF.Download it from the bank's online portal, or accept the email attachment. If the PDF is password-protected — common with HDFC, SBI, ICICI in India and with corporate accounts at HSBC, Lloyds, Deutsche Bank — unlock it first via our free PDF unlock tool. The detailed per-bank password formats are in how to unlock a password-protected bank statement PDF.
2. Convert to .qbo. Drop the PDF into StatementEdge. The converter parses the statement, runs reconciliation against the bank's printed opening and closing balances, and emits a QBO-ready .qbo file with stable FITIDs, correct CURDEF, and ISO dates. Takes about 30 seconds for a typical monthly statement.
3. Check the reconciliation badge.Green means opening balance plus the sum of every transaction equals the closing balance exactly. Amber means it matches within rounding (usually a sub-cent accumulated rounding gap — harmless). Red means a row didn't add up — open the flagged row, check it against the PDF, fix or accept. Don't skip this step.It's the only place in the chain that catches the silent-corruption failure mode.
4. Upload into QuickBooks Online. Open QBO. Go to Bookkeeping → Transactions → Bank transactions. Click Link account, then Upload from file(the second option in the dropdown — not "Find your bank"). Browse to your .qbo. On the next screen, pick the matching book account from the dropdown. QBO remembers this mapping for next time.
5. Review and categorise. Imported transactions land in the For Review tab. Apply rules, match to existing entries, add the rest. The categoriser side of this — assigning the right expense category to each row — is its own problem worth automating; see our expense categorizer if you're doing this for more than a handful of clients.

What changed in QBO bank imports in 2026

If you last did this two years ago and are noticing the menu has moved, you're not imagining it. A few things to know:

• The menu moved. The upload entry point now lives at Bookkeeping → Transactions → Bank transactions. The old Bankingsidebar item still exists for some account types but redirects most users to the new location. If you're looking at a tutorial that says "Banking → File Upload" the screenshots are pre-2024 and the menu names have rotated.
• ISO dates are finally a first-class option. The CSV wizard now offers a fifth date format — YYYY-MM-DD — without you having to set the browser locale. Use it. ISO dates eliminate the DD/MM vs MM/DD trap entirely and have no regional ambiguity to fight.
• Open Banking is the default aggregator path in the EU and UK.The aggregator side has migrated more European banks onto Open Banking (PSD2) rails. That's good for stability but means the 90-day SCA re-auth prompt is now strictly enforced; the old screen-scraping workarounds are gone. If your feed worked flawlessly for two years and broke last quarter, this is the most likely reason — and the fix is to reconnect in QBO, not to call your bank.
• Multi-currency is more forgiving on Advanced. QuickBooks Advanced now allows assigning a separate CURDEFper uploaded file even on home-currency accounts. If the upload silently rejects with "account currency mismatch", you're on a regular (non-Advanced) tier and will need to emit the .qboin the account's configured currency.
• The 350 KB CSV size limit is now enforced server-side. Previously the limit was advisory; the wizard would warn you and let you proceed. In 2026 the upload endpoint hard-rejects above ~350 KB. For wide-column CSVs (some HSBC and Santander exports run 12+ columns wide) this trips at as few as 600 rows. Trim unmapped columns before upload or split the file by month.
• The QBO mobile app finally accepts file uploads. iOS 18 and Android 15 versions now expose "Upload from file" under the same Bank Transactions menu. Useful for one-handed month-end work on the train; the upload still routes through the same parser as desktop, so the same gotchas apply.
• "Find your bank" covers more EU institutions. The aggregator list added 80+ EU and UK banks in 2025 via PSD2/PSD3 — Bunq, N26, Wise Business, Qonto, Holvi, Tide, Starling, and most German Sparkasse and Volksbank branches now connect natively. Worth re-checking if you assumed a year ago that your bank wasn't supported.

A worked example: PDF → QBO end-to-end

Concrete is clearer than abstract. Here's what the recommended path looks like for a specific, realistic case: a German Mittelstand client with a Deutsche Bank EUR current account, a monthly statement averaging 90–120 transactions, multi-currency disabled on the QBO side (the book is set to EUR-only), and a live feed that broke when SCA re-auth lapsed.

Starting state: a 14-page PDF statement, Kontoauszug_2026-05.pdf, 280 KB, opening balance €48,217.32, closing balance €52,904.18, 104 transactions across the month. Amounts in the PDF use comma-decimal ( 1.234,56) and dates as DD.MM.YYYY. The QBO bank account is configured with CURDEF=EUR and an ACCTIDof the IBAN's last 10 digits.

The five-step workflow plays out:

1. Open the PDF.Not password-protected (Deutsche Bank PDFs aren't, for corporate accounts). Check the printed opening balance — €48,217.32 — matches the previous month's QBO closing balance. (If they don't match, stop here: the discrepancy is in April, not May, and importing May now will paper over the real issue.)
2. Convert. Drop the PDF into the converter. 38 seconds later we have a 47 KB .qbo file with CURDEF=EUR, BANKID=DEUTDEFFXXX, ACCTID matching the QBO account, 104 transactions in YYYYMMDD format, deterministic FITIDs, and comma-decimal amounts converted to -1234.56 / 1234.56.
3. Read the reconciliation badge.Green. Opening €48,217.32 + sum of credits €81,402.10 − sum of debits €76,715.24 = closing €52,904.18. Exact match. No row needs investigation. If this were amber by, say, €0.02, that's an accumulated rounding gap and safe to ignore. Red means a specific row is off and the converter flags which one.
4. Upload. In QBO: Bookkeeping → Transactions → Bank transactions → Link account → Upload from file. Drop the .qbo. QBO matches the (BANKID, ACCTID) tuple to the existing linked account and skips the picker. Two seconds later, the For Review tab shows 104 new transactions.
5. Review and reconcile. Apply previously-saved bank rules (Stripe → Sales, Deutsche Telekom → Telecoms, etc). Match the customer payments against open invoices. Categorise the rest. Run Bookkeeping → Reconcile, enter ending balance €52,904.18 and date 2026-05-31. Difference: €0.00. Sign off.

End-to-end elapsed time, with rules already configured from prior months: 6–8 minutes. The conversion + upload portion is under 90 seconds; the rest is the review work that has to happen regardless of how the data arrived.

The CSV import path — when you have to

Sometimes you don't have a choice. The bank gives you CSV and nothing else, the client already cleaned a CSV by hand, or you're importing into QuickBooks Self-Employed (which is CSV-only). QBO's CSV import wizard expects three or four columns:

Date, Description, Amount
2026-05-03, "SEPA DD Stripe Inc", -42.30
2026-05-04, "Salary May", 3200.00
2026-05-07, "Tesco Express", -28.14

Or the four-column variant with separate credit and debit columns:

Date, Description, Credit, Debit
2026-05-03, "SEPA DD Stripe Inc", , 42.30
2026-05-04, "Salary May", 3200.00,
2026-05-07, "Tesco Express", , 28.14

Either works. The wizard asks four questions on first upload:

• Does the file have a header row? Almost always yes — the column titles row at the top.
• Three columns or four? Three = signed Amount; four = separate Credit and Debit.
• Which column is which? Map Date, Description, Amount.
• What date format? Pick the format that matches your file. The trap: many UK and EU CSVs use DD/MM/YYYY; the QBO default offered on US-locale browsers is MM/DD/YYYY. Pick wrong here and every transaction lands in the wrong month.

If you do go the CSV route, the seven failure modes covered in why your QuickBooks bank statement import keeps failing are the things to watch for: locale mismatches on amounts (1.234,56 vs 1,234.56), wrong delimiter, ambiguous dates, Money-In/Money-Out columns that need merging, and zero-amount rows. Each has a deterministic fix. None of them happen if you take the .qbo route instead.

What about bank feeds?

Live bank feeds are great when they work. Intuit's aggregator pulls transactions overnight, you wake up to a populated For Review tab, no upload involved. In practice, feeds fail in five reliable ways:

• Authentication breaks every 90 days.European banks have to re-authenticate under PSD2 SCA rules at most every 180 days and typically every 90. The feed silently stops. QBO doesn't warn you until you notice the gap on the next reconciliation. QuickBooks added an email warning in late 2025 ("Action needed: your bank connection needs to be refreshed") but it lands in the QBO admin's inbox, not the bookkeeper's — and gets buried in routine notifications.
• Coverage gaps.Smaller European banks, Indian banks, and many credit unions aren't in Intuit's aggregator at all. You can search the "Find your bank" list — if your institution isn't there, you're on the upload path. Coverage is excellent for US, Canada, UK, and the big four Irish banks; mixed for Germany, France, and the Netherlands; patchy in Italy, Spain, and Eastern Europe; near-zero for India and Southeast Asia.
• Feeds skip historical data.Most aggregator feeds only pull the last 90 days. For year-end clean-up of an account that's been live for two years, you still need to upload the earlier statements as .qbo.
• Feeds misclassify pending transactions.Some banks (notably Chase business and HSBC UK) expose pending transactions through the feed before they post. QBO imports them. When the bank later finalises the transaction with a different amount or merchant name, the feed often imports it as a separate row instead of updating the original — and you end up with a duplicate plus a missed reconciliation. Manual import from a finalised statement doesn't have this problem.
• Feeds truncate descriptions.The aggregator normalises merchant strings — "SQ *COFFEE SHOP MAIN ST" becomes "Coffee Shop". Helpful for rules, but you lose the disambiguating detail. If a client has three accounts at competing Starbucks branches, you can't tell them apart in the feed view; you can on a manual statement upload.

The right pattern is hybrid: leave the feed connected for day-to-day, and keep a converter in your toolkit for the months the feed misses, the historical back-fill, the banks the aggregator doesn't cover, and the periodic reconciliation against the bank's actual PDF statement (which is the only source of truth that survives a feed-side bug). That's also the structure recommended in our QuickBooks converter guide.

Receipts vs Bank Transactions — the routing trap

QuickBooks Online has two separate features that both accept a PDF upload, and they behave nothing alike. The mix-up is one of the most common ways a perfectly clean statement still ends up landing wrong.

• Bookkeeping → Transactions → Bank transactions is the path for monthly bank statements. It expects .qbo, .qfx, or .csv; PDF isn't in the accepted list. Imports go to the For Review queue, get FITID-deduped, and end up reconciled against the linked bank account.
• Bookkeeping → Transactions → Receiptsis the path for expense receipts — one PDF or photo per expense. It runs Intuit's receipt-OCR pipeline (now built on the Intuit Document AI model rebranded in mid-2025), reads the merchant, total, tax, and date, and posts a single For Review expense suggestion.

The trap: drop a monthly bank statement PDF into Receipts and QBO doesn't refuse it. The OCR happily reads somethingoff the first page — usually the statement's closing balance or the bank's phone number — and creates an expense for that amount, payable to "Account Number 30003-12345678901" or similar nonsense. Then the AI rules engine sees it's an outgoing payment and queues it for review like any other expense. Two weeks later somebody approves it without looking, and a wholly fabricated £6,247 expense is in your books with no source transaction to match it to.

Two more places this surfaces:

• Drag-and-drop into the QBO sidebar. Dropping any file onto the left rail routes it to Receipts. The Bank Transactions upload requires the explicit menu path (or the file picker on the Bank transactions page itself). Train the muscle memory.
• Gmail / Outlook plugins.The "Send to QuickBooks" buttons in the Gmail and Outlook add-ins send attachments straight to Receipts. If your bank emails statements as attachments — common with HSBC UK and most German banks — don't forward via the plugin. Save the PDF, convert it, and upload the .qbo through Bank Transactions.

If you do realise you've dropped a statement into Receipts, undo it before the suggested expense gets approved: Bookkeeping → Transactions → Receipts → Reviewed (or For Review, depending on timing), find the rogue row, click the trash icon. Receipts retention is 30 days after deletion before the file is purged; the underlying PDF is recoverable from the archive within that window.

How FITID dedupe actually works (and why it matters on re-imports)

QuickBooks deduplicates incoming OFX transactions by FITID (Financial Institution Transaction ID) within the same ACCTID. The rule is simple: if QBO has already seen FITID=ABC123on this account, the second copy is skipped silently. That's how a re-upload of January when your feed already grabbed half the month doesn't produce duplicates.

The catch: FITIDs only dedupe if they're stable across re-conversions. If your converter regenerates random IDs every run, re-uploading the same PDF produces a full duplicate set. QBO has no "dedupe by description+amount+date" fallback for OFX imports. We use deterministic FITIDs derived from the transaction's date, amount, and a hash of the description — so the same row in the same PDF produces the same FITID every time, whether you convert it once or twenty times.

For CSV imports, QBO does dedupe by date + amount + description within a small window, but it's lossier — long memos or amounts that differ by sign convention can slip through. Yet another reason the .qbo path is the one to choose when you have a choice.

Back-filling a year (or more) of statements

New client onboarding, late VAT registration, a Self-Assessment catch-up, a forensic review — the back-fill is the use case the live-feed pattern doesn't cover. Aggregators typically only pull the last 90 days of history; everything older has to come from PDFs the client digs out of their portal. The mechanics are the same as a normal monthly import, with a few extra rules that matter when the scope is twelve or twenty-four months instead of one.

1. Collect every statement first, then start importing. Don't import January as soon as you have it. Get all 12 (or 24, or 36) PDFs from the bank portal in one batch. The reason: missing months in the middle of an imported sequence will show as a reconciliation discrepancy that's harder to diagnose than a gap at the front. A simple folder named acme-current-2025/ with twelve files acme-current-2025-01.pdf through acme-current-2025-12.pdf is the right starting state.
2. Chain the opening balances before you upload anything. Open each PDF in order, write down the printed opening and closing balances. The closing of each month must equal the opening of the next. If one pair doesn't match, the bank's portal has a gap or a duplicated month — fix that before importing, not after.
3. Convert in order, oldest first. Run each PDF through the converter. Save each .qboto the same folder with the same date-stamped naming. The reconciliation badge on each one is your check that the conversion didn't silently lose a row.
4. Upload oldest first.QBO doesn't care about order — FITID dedupe means you can upload June before January without producing duplicates — but the bank-reconciliation screen works month by month from the earliest open period, and reconciling in order is faster than out of order. The first upload also creates the (BANKID, ACCTID) → QBO-account mapping; subsequent uploads skip the account picker.
5. Reconcile after each month, not at the end.Open Bookkeeping → Reconcile, pick the bank account, enter the printed ending balance and statement date for the month you just uploaded. Difference should be £0.00. Sign off, move to the next month. Doing this monthly is materially faster than doing it for twelve months at once at the end — the categorisation work shrinks as your bank rules accumulate, and any discrepancy is isolated to a single month's worth of rows.

A few back-fill-specific traps worth knowing:

• QBO's "closed period" lock.If a previous accountant has closed the books up to, say, 2024-12-31 with a password, you can't back-fill into 2024 without the password. Get it before you start; the alternative is posting catch-up entries dated 2025-01-01, which loses the period-accurate audit trail.
• The 90-day Desktop window.If you're back-filling QuickBooks Desktop (not Online), Web Connect can refuse a .qbo whose newest transaction is older than ~90 days. The workaround is to bump DTASOF in the OFX header to today, or import via a fresh temporary bank account and merge after.
• Bank rules need warming up.The first three months you back-fill will have the most manual categorisation; by month six the rules cover the long tail and the work compresses dramatically. Don't judge the time-per-month from the first month — it's not representative.
• FX revaluation accumulates. For multi-currency back-fills, every month-end produces a small FX gain or loss journal as QBO revalues open balances. Back-filling a year produces twelve of these; review them as a batch at the end of the back-fill, not month by month.
• Bank statement gaps are real.Some banks (notably older HSBC personal accounts and some Spanish banks) have gaps in their downloadable PDF history past ~13 months. If the portal can't produce a month, you have to either request it from the bank in writing (1–3 week turnaround) or accept the gap and post a journal for the net movement.

Edition differences: Simple Start, Essentials, Plus, Advanced

Most of the upload mechanics are identical across QBO editions, but a few behaviours differ in ways that catch people out:

• Simple Start supports CSV and .qbo upload with a single connected bank feed. No multi-currency. No bank-rule sharing across accounts. The 350 KB CSV limit applies.
• Essentialsadds multi-currency (off by default — and once turned on, can't be turned off). Bank rules are per-account. Up to three users.
• Plus adds class and location tracking, which the import respects if your .qbofile's NAME field matches a configured rule. Project tracking is plus-and-up only.
• Advanced adds the per-file CURDEF override mentioned earlier (lets you upload a non-home-currency .qbointo an account configured as the home currency, useful for some FX-hedged setups). It also adds the bulk "Import bank transactions" batch endpoint usable via the API.
• Self-Employed is a separate product. CSV only, no .qboat all, no bank-reconciliation screen, no rules engine. The reconciliation discipline still applies — the tool just doesn't enforce it.

Multi-currency accounts

If your QBO account has multi-currency turned on, every bank account has a fixed currency. The .qbo file you upload must declare a matching CURDEF— "USD", "EUR", "GBP", "INR", whatever the account is. Upload an EUR .qbointo a USD QBO account and QBO rejects with a generic "Currency mismatch" error without telling you which side is wrong.

Five specific traps worth knowing:

• The bank statement is in EUR but your QBO account was set up as USD. Easy to do when you opened the book before adding the EUR account. You have to either change the account currency (only possible if no transactions have posted yet) or create a new EUR account and re-import.
• The .qbo declares the wrong currency. A converter that hard-codes USD regardless of input will produce files that upload silently into the wrong account. Check CURDEF in the OFX header if imports start landing in the wrong place.
• Sub-currencies and tokens.Some neobanks (Wise Business in particular) emit statements covering balances in jurisdictions where the currency code isn't in ISO 4217 — USDC-on-Polygon, GBPx, internal "jar" balances. QBO rejects these outright. Convert the underlying movement into the fiat code first, or set up the account as USD and accept the loss of precision on the token side.
• Mixed-currency PDFs. Revolut, Wise, and some private bank statements list transactions in multiple currencies on the same statement with an FX column. Split the file by currency before conversion — emit one .qboper currency, upload each into its matching QBO account. Trying to fit a multi-currency PDF into a single-currency QBO account loses the FX context that's essential to year-end revaluation.
• Home-currency rounding. When QBO converts an EUR transaction to your home GBP for reporting, it applies the exchange rate from the statement date. If your .qboomits DTPOSTEDon a row (some MT940-to-QBO converters forget), QBO falls back to today's rate and the rate diverges silently. Always verify DTPOSTED is present on every<STMTTRN> block.

Per-bank quirks that bite in the QBO import flow

The generic CSV-upload tutorial works for clean US banks. It breaks on almost everyone else. Some of the specifics worth knowing:

• Chase offers .qbodirect download for business accounts (look for the "Quicken/QuickBooks" option in the Activity → Download dropdown). Personal accounts only emit CSV or PDF. The CSV uses MM/DD/YYYY dates and a single signed Amount column.
• Bank of America offers .qbovia the "Download" button on the Activity page. The header carries a BANKID of 121000358 — QBO matches on this plus ACCTID, so if you rename the linked account, the mapping needs re-establishing.
• Wells FargoCSV exports use a four-column shape with Date, Amount, "*" (a blank placeholder), and Description. The unlabelled column trips up the QBO mapper — you have to map the third column to Memo or leave it unmapped.
• Capital One only emits CSV. Amounts come as positive numbers with a separate Debit/Credit column — exactly the Dr/Cr suffix trap that produces $0.00 rows after import if you map columns naively. Convert to .qbo first.
• HSBC UK, Barclays, Lloyds, NatWest, Santander UK all emit CSV with DD/MM/YYYY dates and Money-In/Money-Out columns. The combination kills QBO imports unless the date format and column merge are handled before upload.
• AIB and Bank of Ireland mix English and Irish columns on PDF statements, comma-decimal on amounts ( 1.234,56), and dates as DD/MM/YYYY. None of that survives a naive CSV-to-QBO conversion. The pattern is documented in AIB, Lloyds, Barclays → Xero — Xero-focused but the locale traps are identical for QuickBooks.
• Deutsche Bank, Commerzbank, ING-DiBa emit MT940 (a SWIFT format) and CAMT.053 (XML) in addition to PDF. Neither imports into QBO directly — you need to convert the source format to .qbo first.
• HDFC, SBI, ICICI, Axis, Kotak in India send password-protected PDFs with the password derived from your customer ID and date of birth. Unlock first, then convert. Indian bank statements also use comma-lakh formatting ( 1,23,456.78), which the default CSV import in QBO mis-parses unless converted to plain decimal first.
• DBS, OCBC, UOB in Singapore and the major Australian banks emit PDF and a proprietary CSV; the CSV column order changes every couple of years, which is the canonical case for keeping a converter in the loop rather than rebuilding mappings each year.
• US Bank, PNC, Truist all offer Web Connect .qbodownloads behind a slightly hidden "Download Activity" menu. PNC's emits BANKID as the routing number and ACCTIDas the full account number rather than the last four — note this if you're sharing files with a client.
• Revolut Business, Wise, Mercuryemit clean CSVs with ISO dates and decimal points, but include a Reference / Tag column ahead of Description that the QBO mapper offers to map by default. Map it to Memo or skip it — mapping it to Description produces uninformative entries like "R-21F4B-93".
• Bunq, N26, Qonto (EU neobanks) emit CSV with comma-decimal and ISO dates. The combination breaks the QBO US locale parser; either set the wizard to YYYY-MM-DDand pre-convert amounts, or route through .qbo.

What QuickBooks can't catch — and why reconciliation matters

QuickBooks Online sees a list of transactions. It does not see the bank's printed opening or closing balance on the statement PDF. It has no way to verify that the import was complete and correct — only that the file was parseable. If a converter misreads a digit (a 7 as a 1, a decimal misplaced) or drops a row, QBO imports the wrong version without complaint. Three weeks later your bank-reconciliation screen shows a discrepancy and you spend an hour reverse-engineering which row caused it.

Reconciliation has to happen beforethe file reaches QuickBooks. That's the converter's job: verify opening + sum(credits) − sum(debits) = closing, flag the row that breaks the chain if it doesn't. We cover what that actually means in what "auto-reconciled" actually means. If you want to spot-check a CSV you already have, our free reconciliation checker runs the same arithmetic without re-converting.

Batch imports for multi-client practices

If you're closing more than five clients a month, the one-PDF-at-a-time path becomes the bottleneck. Three patterns scale better:

1. Web-app batch upload. Drop a folder of PDFs into the converter on any paid plan. We process them in parallel and return a ZIP of .qbofiles named by client and month. The conversion of 30 statements takes about as long as one — the QuickBooks import remains sequential, but the conversion isn't the bottleneck anymore.
2. API automation. The StatementEdge REST API exposes the same converter. A practice management system or a Trigger.dev task can pick up new PDFs from a shared inbox, convert each one, and drop the .qboback in the client's folder. From there someone runs the QBO upload (still manual — QBO doesn't accept server-to-server .qbo push) or you use the QuickBooks Online API to attach the file directly.
3. MCP server.The same conversion endpoint is exposed as an MCP tool, so an accountant in Claude Desktop or Cursor can say "convert these PDFs and email me the QBO files" and have the work done without opening a browser.

Symptom-to-fix mapping table

If something looks off after the import, this table covers ~95% of cases:

Exact QBO error messages and what they actually mean

QBO's import errors are written for the aggregator team, not for you. Here's the translation table for the strings that come up most often in 2026:

Diagnosing a reconciliation discrepancy: a worked walkthrough

The most common "the import worked, but…" pattern is the bank-reconciliation screen refusing to clear with a small non-zero difference. Here's a realistic case worked end-to-end so the diagnostic shape is concrete, not abstract.

Setup: Lloyds Business current account, GBP. April 2026 statement imported as a .qbo, 167 transactions. The Bookkeeping → Reconcile screen shows ending balance £18,924.06 (matches the printed statement), QBO calculated balance £18,909.42, and a Difference of −£14.64. Nothing is obviously wrong.

The diagnostic playbook, in order — stop at the step that fixes it:

1. Is the difference an exact transaction amount? Sort the transactions list in the reconciliation screen by amount descending, scan for £14.64. If you find it, either you double-cleared a row (uncheck it) or you cleared one that's on this period's statement but the import dropped it (find it on the PDF, post it manually, clear it). In our case: no £14.64 row exists.
2. Is the difference 2× an exact transaction amount? Half of £14.64 is £7.32. Scan for £7.32. If a row exists and is cleared once, it's likely a sign-flip duplicate — the same transaction imported once as a debit and once as a credit. Common with the Money-In/Money-Out merge bug on Lloyds CSVs that get re-converted manually. In our case: no £7.32 row either.
3. Is it a transposition?A two-digit transposition produces a difference divisible by 9 (the famous accountant's trick). £14.64 ÷ 9 = 1.62 — not an integer, so this is not a transposition error. Skip.
4. Is the difference a familiar fee?£14.64 is suspiciously close to a Lloyds quarterly account-maintenance charge (currently £15.00 less interest). Filter the period for transactions containing "CHARGE", "FEE", "MAINTENANCE". Find one: 30 Apr 2026 — Account Service Charge — £14.64, present on the PDF, present in the imported list, unmatched and unchecked. Tick it. Difference drops to £0.00. Sign off.

The diagnostic took under two minutes once you know the order. The same order works for every "small unexplained difference" case — and the four checks cover the vast majority of them. If steps 1–4 all fail, escalate to:

• The opening-balance check.Compare QBO's beginning balance for the period to the PDF's printed opening balance. If they differ, your discrepancy actually predates this month and the fix is in an earlier period. Stop reconciling April and go back to March.
• The reconciliation checker. Run the source PDF through the checker independently of the converter; it computes opening + Σ(rows) = closing without going through QBO. If the PDF itself doesn't balance, the bank has a typo or a hidden adjustment that needs a journal entry; if it does balance and QBO doesn't, the converter dropped a row and you need to re-run.
• The CSV export from QBO. On the reconciliation screen, click the gear icon → Export to Excel. Side-by-side the export against the PDF in Excel; the offending row will leap out. This is the slowest diagnostic but the most reliable when nothing else explains the gap.

Refunds, reversals, and the same-day net-zero pair

A specific edge case that catches people on otherwise clean imports: the bank emits two transactions on the same day that cancel each other out. A failed direct debit reverses; a card pre-authorisation drops; Stripe issues a same-day refund; an ATM rejects a withdrawal after the debit posts. Net cash movement is £0.00, but two rows hit the statement.

How QBO handles this depends entirely on how the bank — and your converter — emit the FITIDs:

• If each leg has a distinct FITID(the correct behaviour, used by every major bank), QBO imports both. The For Review tab shows one debit and one credit. They reconcile fine; the matched-pair shows up as two rows for £0.00 net. Don't delete either one. The bank reconciliation screen requires both rows because the bank's closing balance was computed from both legs.
• If the two legs share a FITID (some homegrown CSVs and badly-designed converters do this), QBO accepts the first and silently drops the second as a duplicate. The reconciliation difference shows up the next morning equal to the missing amount. Re-emit the .qbo with distinct FITIDs and re-upload.
• If your converter helpfully "merges" the pair into a single £0.00 row, QBO accepts the £0.00 row and the reconciliation passes, but you've lost the audit trail showing the failed transaction. For HMRC and IRS audits the bank statement and the books need to agree row-for-row; a missing row provokes uncomfortable questions even when the net is correct. Don't merge — emit both legs.

Three common patterns and how to handle them:

• Stripe same-day refund.Stripe issues the refund before the original charge has settled. The bank sees a debit on T+1 and a credit on T+1 (or T+2). Both legs need to be in the books with the refund matched to the customer's original invoice via a Credit Note, not deleted.
• ATM declined withdrawal.Some banks (notably HSBC and First Direct) post the debit at the moment of the request and reverse it within an hour when the cash dispenser fails. The two rows have the same amount and same merchant string but distinct FITIDs and distinct timestamps. Import both; categorise the pair to a clearing account or to "Bank reversals", not to "ATM withdrawals".
• Card pre-authorisation (hotels, car rental). A pre-auth holds funds without posting; when the final charge settles, the pre-auth is released and a new debit posts. Some banks (Chase, Capital One) show both as transactions; others (Lloyds, Monzo) only show the final settled amount. If your client uses a card for hotels frequently and the bank shows pre-auths, set up a Bank Rule to auto-match the release credit to the pre-auth debit — otherwise the pair clutters the For Review tab every business trip.

Monthly close: a seven-minute checklist for one client

Once you've done the upload dance a few times for the same client, it compresses to a routine. This is the shape of a typical month-end bank-statement import for one client with one current account, assuming the live feed is off or unreliable:

1. Minute 0–1: Get the PDF. Download from the bank portal, or grab the email attachment. Unlock if password-protected. Check the printed opening balance matches your previous close.
2. Minute 1–2: Convert and verify. Drop the PDF into StatementEdge. Watch the reconciliation badge land green. If amber or red, open the flagged row, eyeball the PDF, decide.
3. Minute 2–3: Download the .qbo.Save it to the client's folder with a date-stamped filename like acme-current-2026-05.qbo. This filename becomes your audit trail later.
4. Minute 3–4: Upload to QBO. Bookkeeping → Transactions → Bank transactions → Link account → Upload from file. Pick the .qbo. Confirm the account picker (it remembers from last month).
5. Minute 4–6: Review the For Review tab. Apply rules, match to invoices, categorise the rest. Most months this is the longest step; rules accumulate as you go and the work shrinks each month.
6. Minute 6–7: Run the bank-reconciliation screen.Bookkeeping → Reconcile. Enter the statement's printed ending balance and date. The difference should be £0.00. If it isn't, you have a row that didn't make it across — go back and find it before signing off.

QuickBooks Desktop — the differences worth knowing

If you're on QuickBooks Desktop (Pro, Premier, or Enterprise), the file format is the same — .qbo — but the import path and the gotchas differ:

1. File → Utilities → Import → Web Connect Files
2. Browse to the .qbo file.
3. Pick "Use an existing QuickBooks account" and select the right one. QuickBooks Desktop caches this against the file's BANKID + ACCTID and asks once.

A few Desktop-specific things to watch for:

• The Bank Feeds wizard pops up.If the account hasn't had bank-feed downloads activated before, Desktop offers to enrol you in live bank feeds with Intuit. Most users want to skip this — right-click the account in the chart of accounts, Edit Account → Bank Feed Settings → Deactivate all online services, then re-run the Web Connect import. Once that's done it imports the same way every time.
• .IIF is a different beast. Desktop also accepts .IIFimports, which write straight to the register without the bank-feed dedupe layer. Don't use IIF for routine bank-statement imports — it bypasses FITID dedupe and will produce duplicates the moment you re-run a month. IIF is for one-off list imports (chart of accounts, customers, vendors), not transactional flow. See QuickBooks Desktop bank statement import: the .QBO and .IIF workflow for the full picture.
• The 90-day window.Desktop's Web Connect rejects a .qbowhose newest transaction is older than ~90 days from today on some bank profiles. Year-end back-fill of older months sometimes needs a workaround — bump the file's DTASOF field forward, or import via a fresh account temporarily.

Credit card statements: the CCSTMTRS envelope and the sign-flip

Almost every guide to QBO imports assumes a bank account. Credit card statements look identical on the surface — they're still .qbo files, still uploaded through Bank transactions, still deduped by FITID— but the differences underneath are the source of an outsized share of "the numbers landed weird" tickets, and they trip up every converter the first time you try one.

Four things change when the source is a credit card rather than a current account:

• The OFX envelope. A credit card .qbo wraps its transactions in <CREDITCARDMSGSRSV1><CCSTMTTRNRS><CCSTMTRS> rather than the bank-account chain <BANKMSGSRSV1><STMTTRNRS><STMTRS>. Inside, BANKACCTFROM is replaced by CCACCTFROM — same idea, different tag name. QBO uses the envelope to decide which list of accounts to offer in the picker; emit STMTRSfor a credit card and QBO will only let you map it to a bank account (and then complain about the sign convention forever). Most off-the-shelf converters get this wrong on first run because the PDF doesn't announce whether it's a card or a checking statement — they default to STMTRS and you have to override.
• The sign convention reverses. On a bank account, money leaving is negative. On a credit card, a purchase increases what you owe the card issuer— depending on the issuer's OFX dialect, that posts as a positive (debit on your liability) or as a negative (matching the bank-account convention where money-out is negative). Amex emits purchases as positive; Chase Visa and Capital One emit them as negative; Barclaycard UK splits the difference and uses positive for purchases on personal cards and negative on business. Map this once per issuer and stick with it — flipping mid-year produces a statement where every transaction is in the wrong sign and the reconciliation difference is exactly twice the total spend.
• Payments to the card aren't expenses.Every statement has at least one credit row labelled "PAYMENT THANK YOU" or "PAYMENT RECEIVED — THANKS". This is you paying the card off, not income. It needs to categorise to a transfer from the bank account that funded it — and if both the card and the funding bank account are in QBO, the right route is the transfer-match workflow in the next section, not a category. Categorising it to "Other income" or "Suspense" inflates both sides of your P&L by the same number every month and is one of the more common bookkeeping smells.
• Rewards, cashback, and fee waivers post as their own rows. A Chase Ink statement will have a row like CASH BACK REDEMPTION — $84.20that increases your balance (decreases what you owe). Don't skip it. The right home is usually "Other income — credit card rewards" for personal-mixed-with-business cards, or a reduction to the original expense category for purely-business cards (depending on your tax jurisdiction's treatment of rewards). The number is small per statement but ignoring it loses the reconciliation match against the bank's closing balance.

The credit-card-specific failure modes worth knowing:

• Statement period ≠ calendar month.Most cards close mid-month — the 12th, the 18th, whatever the activation date was. Reconciling the card "for April" means reconciling 13 March–12 April or similar, not 1–30 April. The statement's printed cycle dates are the period that has to match in QBO's Reconcile screen.
• Foreign-currency purchases get a separate FX-fee row. A Visa or Mastercard transaction made in EUR on a USD card comes through as the converted USD amount plus a separate "FOREIGN TRANSACTION FEE" row, usually 1–3% of the original. Both need to import. Some converters helpfully roll the fee into the main row — don't use those, because the bank statement and your books then disagree row-for-row and any audit hits the FX-fee total first.
• Disputed charges and chargebacks.When a dispute resolves in your favour, the original charge stays and a credit appears later, often on a different statement. The two rows have distinct FITIDs and have to import as a pair; don't delete the original. The Bookkeeping → Reconcile screen needs both to arrive at the right balance.
• Authorised users and joint cards.American Express family-share and joint-cardholder statements emit one file with the primary's ACCTID and a per-row <EXTDNAME> field naming the cardholder. QBO ignores EXTDNAME by default but if your rules read the description string they can split categorisation by cardholder name — useful for accountable plans and partner reimbursements.

Transfer matching: when both sides of a payment are in QBO

The standard For Review tab assumes every imported transaction has an outside-the-business counterparty — a customer, a supplier, a fee. The moment you have two QBO-tracked accounts at the same organisation (a current account and a credit card, two currencies of the same bank, an operating account and a savings account, a holding company and a trading subsidiary), some of the rows have a counterparty inside QBO. Categorise them as if they didn't, and you double-count: the outflow becomes an expense and the inflow becomes income, both fictional, both reportable as taxable.

QBO has three ways to handle the transfer-match case. The right one depends on what arrived first.

1. "Record as transfer" — when only the first leg is in For Review.You imported the card statement, the payment row is sitting in For Review, the matching bank statement hasn't been imported yet. Click the row, switch the dropdown from "Categorise" to "Record as transfer", pick the destination account. QBO creates the transfer entry now; when you later import the bank statement, the matching outflow lands in its For Review tab with a "Match" suggestion pointing at the transfer you just recorded. Accept the match. Both rows are now cleared and the books show a single transfer, not two transactions.
2. "Match" — when both legs are already in For Review.Both statements imported before you did the categorisation pass. Open either row, scroll the suggested matches panel (QBO suggests the opposite-sign row in the other account if the amount and date are within tolerance). Click Match. The two For Review rows clear together; the books show one Transfer transaction. If QBO doesn't suggest a match, click "Find match" and search by amount and date range across all your bank and card accounts. This is the most common case in practice.
3. Bank Rule with "Auto-add as transfer" — when the same transfer happens every month.Salary sweeps, monthly credit card payments, intercompany top-ups. Build a rule that recognises the description string and amount range, set the action to "Add as Transfer" with the destination account fixed. Now both sides of next month's transfer pre-match before you even open the For Review tab.

Three transfer-shaped patterns that get this wrong by default:

• Owner draws from a sole-trader business account to a personal account.If both are in QBO (which they shouldn't be — but some single-member LLCs and UK sole traders end up with both for compliance reasons), match them as a transfer to the Owner's Equity → Draws account, not to two separate transactions.
• FX-conversion transfers between same-bank accounts.Moving GBP from your sterling account to your EUR account at the same UK bank emits one debit (GBP) and one credit (EUR) plus an implicit FX margin. The Transfer entry in QBO needs a manual currency-conversion step — the "Record as transfer" flow assumes a 1:1 amount match, which a cross-currency transfer never is. The Advanced edition handles this natively; on lower tiers you post the GBP outflow and EUR inflow as separate transactions to a Currency Clearing account and journal the difference at month-end.
• Credit card auto-pay split across statements. A 1 May card statement closes with a balance of £4,212.84 and auto-pay debits the bank account on 12 May. The bank statement for May contains the payment; the card statement for May contains the payment received; the next card statement (1 June) contains the same payment row again as a brought-forward credit. The third one is informational only and doesn't import as a separate transaction in a correctly-built .qbo— but some converters that read every line on every page emit it as a duplicate. If your card "is off by exactly one auto-pay", this is the place to look.

Switching a broken bank feed to monthly file uploads (without creating duplicates)

There's a specific failure mode the official docs don't cover well: the bank feed has been silently dropping or duplicating transactions for weeks, you've only just noticed, and you need to switch this account to monthly PDF-derived .qbo uploads going forward — without contaminating the books you already have. Done in the wrong order, you end up with three flavours of the same transaction sitting in the For Review tab and no clean way to tell which one to keep.

The reason this is fiddly is that QBO assigns FITIDs in two incompatible ways depending on the source. A live bank feed's FITIDs come from the aggregator (Plaid, MX, or Open Banking) — usually derived from the bank's internal transaction ID and stable across re-syncs. A converter-produced .qbo derives FITIDs from the visible PDF fields (date + amount + description hash + position). The two namespaces never collide cleanly. QBO sees them as different transactions and shows you both.

The migration that actually works:

1. Freeze the broken feed at a hard cutoff date. Pick the last day of a completed reconciliation — typically the last month-end you signed off on. Call this D. Everything up to and including D stays in QBO untouched. Everything after D comes from converted PDFs.
2. Disconnect the feed first, then clean up the For Review tab. Banking → Bank transactions → click the pencil icon on the connected account → Edit account info → Disconnect this account on save. This stops new feed transactions arriving. Now go to the For Review tab and Exclude every row dated after D. Don't accept them, don't match them — Exclude. This is the step people skip; without it, the next file upload will land alongside the feed's versions of the same transactions.
3. Empty the Excluded tab.Go to the Excluded tab, select every row, click Delete. This is what frees the bank-feed FITIDs from QBO's dedupe index so the converter-produced FITIDs for the same period don't look like duplicates of something QBO is still tracking. Until Excluded is empty, you have ghosts.
4. Convert the first PDF for the period starting D + 1.Use a converter that emits stable FITIDs from PDF fields (so the nextmonth's upload also dedupes cleanly against this one). Upload via Bank transactions → Link account → Upload from file. Pick the same QBO bank account you just disconnected — don't create a new one, the chart of accounts and any prior journal entries reference the original.
5. Reconcile that first month before importing the next one.Banking → Reconcile, enter the closing balance and closing date from the PDF, work through to a zero difference. This step is non-negotiable: it surfaces FITID collisions and opening-balance drift while there's only one month of new data to scan, instead of compounding the problem across three months.
6. Establish the standing process for the new monthly cadence.Same QBO account, same converter, same upload path, same reconciliation step. The first three months feel slow; by month four it's a seven-minute job.

The same workflow applies in three adjacent scenarios:

• Bank-feed shows the wrong account.Aggregator re-mappings during bank mergers (Credit Suisse → UBS, First Republic → JPMC, several US regional bank consolidations through 2024–25) sometimes start delivering the wrong account's transactions to your QBO bank account. Disconnect, reconnect to the correct underlying account, and bridge the gap with a converted .qbo for whatever period the wrong-account feed contaminated.
• SCA-driven feed dropouts in the UK/EU. Open Banking consent expires every 90 days under PSD2. If the client missed the re-consent prompt, you have a 90-day gap to bridge with converted statements before the feed catches up. Treat the gap period like a short back-fill (see the back-fill guide) and reconcile month-by-month before reconnecting the feed.
• Aggregator change of provider.Intuit periodically moves bank connections between Plaid and MX. The new connection re-issues FITIDs and you see a one-day duplicate flood. Exclude the duplicates from the new provider (since the old provider's rows are already accepted into your books), don't delete the originals.

Post-import surgery: fixing a row after the period closes

The clean import is the easy case. The hard case is finding a wrong row weeks later — wrong amount, wrong category, wrong account, wrong date — in a period that's now closed, locked, VAT-filed, or shipped to an auditor. The instinct is to open the transaction and edit it. Sometimes that's right. Often it's the most expensive option in the room. Here's the decision tree we use, ordered from least disruptive to most.

1. Is the period still open in QBO?Bookkeeping → Reconcile → History by account, and check the latest signed-off date. If the bad row sits after the most recent reconciliation, you're still in the live period. Open the transaction, fix it, re-reconcile if the change affects a cleared row. Total time: two minutes. The rest of this section is irrelevant.
2. Is the period reconciled but the books aren't locked?QBO supports edits to reconciled transactions — they unflag the reconciliation status (the R becomes a C or blank) and force a re-reconcile of that period. Cost: the reconciliation report on file becomes stale; the new reconciliation needs the same closing balance. Acceptable for single-row fixes. Not acceptable if you have ten of them in the same period — at that point the closing balance will be off and you're re-reconciling against numbers that no longer agree.
3. Is the period closed with a password but pre-VAT/pre-tax filing?Get the close-period password from whoever holds it. Edit the transaction. Re-close. The audit trail records the temporary unlock — that's the point of the password. For UK MTD-VAT, the VAT return is the harder lock; see step 5.
4. Is it post-VAT-filing, pre-final-accounts?The VAT return is filed but the year-end accounts aren't signed. Editing the original row would change the VAT box totals you already filed with HMRC, which means you owe a VAT correction (current return adjustment under £10,000 net, separate VAT652 disclosure above). Cleaner pattern: leave the original row alone, post a correcting journal entry dated in the current open VAT period, document the cross-reference in both transaction memos. The audit trail then shows: original mistake on its date, correction on its date, paper trail intact. Same shape applies to US sales tax filings, Australian BAS, Irish ROS, and EU VAT OSS — the rule is "don't mutate filed rows, offset them in the current open period."
5. Is the year closed and accounts signed?Don't touch the row. A signed set of accounts is a legal document; the underlying ledger is now a snapshot of what supported it. Any correction is a prior-period adjustment posted to the current year — usually to Retained Earnings if it's a balance-sheet item, or via a current-year P&L line with a memo explaining the prior-period origin. Tag it. Your auditor will look for these.
6. Is the row in an audited period?Stop, ring the auditor first. Modifying a row in a period whose ledger has been tied to an issued audit opinion isn't a bookkeeping decision — it's the audit firm's call, and the materiality threshold determines whether they need to re-issue. For everything below materiality it's a prior-period adjustment as in step 5.

The three specific surgery patterns that come up most:

• Wrong category, right everything else.The easiest case. If the period is still open: change the category on the transaction directly. If closed: leave it; post a reclassification journal in the current period that moves the balance from the wrong category to the right one, with the original transaction ID in the memo. The bank reconciliation is untouched (categories don't affect the bank-side balance).
• Wrong amount. Hardest case. The reconciliation almost certainly passed at the time, which means either the statement was wrong (rare, but happens with manual mid-month adjustments by the bank) or the converter dropped a digit and nobody caught it. Re-open the source PDF, find the row, confirm the right amount. If the period is open: edit the row, re-run reconciliation, verify the new closing balance matches. If the period is closed: post two correcting entries — one to back out the wrong amount, one to post the right amount — both dated in the current open period, both pointing at the original transaction ID. Your reconciliation reports for the wrong period stay valid as historic artefacts; the books for the current period reflect the net correction.
• Wrong account (imported to the wrong QBO bank account). Surprisingly common when (BANKID, ACCTID) collisions happen — two different clients at the same bank with similar account numbers. Use the batch action on the Banking → Bank transactions list: select the misrouted rows, click Update, pick the right account. QBO moves the rows including their FITIDs, preserving dedupe behaviour on future re-imports. If the period is closed on either the source or destination account, the same prior-period adjustment rules from step 5 apply — and on both ledgers.

FAQ

Does QBO accept PDF directly in 2026? No. The Bookkeeping → Transactions → Bank transactions upload accepts .csv, .qbo, and .qfxonly. The Receipts feature accepts PDFs but treats each one as a single expense, not a statement.

What's the maximum file size? 350 KB for CSV. The .qboformat doesn't hit that limit in practice until you're past several thousand transactions. If you do, split the statement period — .qbo imports dedupe by FITID across uploads, so half-month + half-month produces the same result as a single full-month upload.

Can I import multiple months at once? Yes — a single .qbo can span any date range. QBO dedupes on FITID, so partial overlap with an existing feed import is handled cleanly (assuming the FITIDs are stable across conversions).

Does QuickBooks Self-Employed support .qbo? No — Self-Employed is CSV-only. The reconciliation, locale, and date gotchas above all apply. Convert PDF to a clean CSV via our free CSV → QBO tool (it also produces a clean CSV output you can use for Self-Employed).

What if I already have a clean CSV? Use our free CSV → QBO tool to convert it to a proper .qbo with stable FITIDs before upload — you skip the column-mapping step and get duplicate-detection on re-imports.

How do I undo a bad import? Go to Banking → Bank transactions, find the offending batch under the "Imported Transactions" section, and use the "Exclude" or "Undo last upload" option. The excluded rows aren't deleted permanently — they sit in the Excluded tab so you can re-include them later if you uploaded correctly.

Why does the same PDF produce a different file size each run?If the file size varies by more than a few bytes, your converter is regenerating FITIDs randomly. That's a flag — re-uploads will produce duplicates. Stable converters produce byte-identical output for the same input.

Can I attach the .qbo via the QuickBooks Online API?Intuit's public API exposes individual transaction creation (BankTransaction, Purchase, Deposit) but not the bulk bank-statement upload endpoint that the web UI uses. Server-to-server statement import has to go through individual transaction posts; you give up the FITID dedupe and currency-mismatch validation. For practice automation, the realistic pattern is: convert via API, drop the .qboto a shared location, have a human do the 30-second upload in QBO. Full server-side imports are technically possible but you're rebuilding QBO's dedupe logic yourself.

Does "Undo last upload" actually delete the rows? No — it moves them to the Excluded tab. If you actually want them gone, select them in Excluded and click Delete. This distinction matters when you uploaded the wrong period and want to be sure the FITIDs are freed before re-uploading the right one.

What if I need to import statements from a closed bank account? Closed accounts work the same as live ones — download the historical PDFs from the bank portal while you still can (most banks restrict access 90–180 days after closure), convert them, and upload into a QBO bank account that you can mark inactive afterwards. The (BANKID, ACCTID) mapping still works; QBO doesn't require the account to be currently connected to a feed.

Does QBO accept a .qbo with mixed credit-card and bank-account transactions? No — credit-card lines need a CCSTMTRS envelope, bank lines need a STMTRSenvelope. Most converters emit the right one based on the source statement, but if you're hand-editing, don't mix the two in one file. Split by account.

I imported the wrong month — what's the cleanest undo?Banking → Bank transactions → click the gear icon above the transactions list → "Undo last upload". This moves the affected rows to the Excluded tab. To free the FITIDs for a re-upload of the correct period, select the rows in Excluded and click Delete. Until you delete them, re-uploading the same file will be silently deduped.

What if my client's statement has the opening balance on a different page?Multi-page PDFs are fine — the converter reads continuation pages and uses the first page's opening balance and the last page's closing balance for the reconciliation check. The only common breakage is a statement where every page restates the running balance; some converters double-count those rows. We don't, but spot-check the reconciliation badge on the first conversion from a new bank.

Further reading

• The complete guide to bank statement converters in 2026 — the pillar piece.
• Bank statement converter for QuickBooks — the deeper dive on QBO file internals.
• QuickBooks Desktop: .QBO and .IIF workflow — the Desktop-specific deep dive.
• Why your QuickBooks bank statement import keeps failing — the named failure modes in detail.
• What "auto-reconciled" actually means — the silent-corruption case nobody warns you about.
• Unlock password-protected bank statement PDFs — per-bank password formats.
• For accountants and bookkeepers — multi-client workflow patterns.
• Free CSV → QBO tool · Reconciliation checker · PDF unlock.
• REST API + MCP server — automate the conversion step.
• Pricing · Security & data residency.