QuickBooks Ledger Import: Convert Bank CSV to QBO Files for Year-End Catch-Up Clients

Yes. QuickBooks Ledger supports importing bank transactions either through a connected bank feed or by manually uploading a transaction file, and Intuit lists .qbo and .csv among the formats it accepts. Both the firm and the client can be given access to do it. The import screen behaves the same way it does in any QuickBooks Online company, because Ledger is a QuickBooks Online subscription with most of the client facing features removed.

The practical difference is what you are importing. In a full QuickBooks Online company the upload is usually a gap filler, a month the feed missed. In Ledger it is often the entire engagement, which changes how much care the file deserves before it goes in.

Yes. Automated bank feeds are one of Ledger's headline features, along with bank and credit card reconciliation, automated transaction coding, journal entries, 1099 contractor tracking and the core financial statements. Intuit lets you keep the client out of the file entirely or give them access specifically so they can connect their own bank feeds and upload documents.

Having the feed is not the same as the feed being sufficient. It is excellent for the current year going forward and close to useless for the year you were hired to clean up.

Ninety days is roughly what most institutions hand over when a connection is first established. It is a limit set on the bank's side, not something a QuickBooks setting can widen, and it applies to the initial pull rather than to the feed's ongoing operation. Once connected, the feed keeps up with new activity indefinitely. It simply will not reach backwards past the window the bank offers.

Some banks are more generous and a few are less. What matters for planning a catch-up is that you cannot count on more than a quarter, so the historical portion of the work needs a file based plan from the start rather than as a fallback.

Ledger accepts the same uploads as QuickBooks Online: .csv, .txt, .qbo and .ofx. A .qbo file is the Web Connect format banks issue for QuickBooks, and it is the format our converter produces from whatever CSV your client's bank hands you. There is no separate Ledger file type and no Ledger specific importer to learn.

One constraint catches firms out. The upload has to be in English, which matters when a client banks with an institution that localizes its download headers.

QBO is better, and the reason is duplicate protection. Every transaction inside an OFX or .qbo file carries a FITID, a unique identifier for that transaction within that account. QuickBooks records the FITIDs it has already seen and skips them on any later import, and it remembers them even after you delete the transaction. A CSV carries no transaction identifier at all, so nothing stops the same month going in twice.

On a catch-up engagement you are uploading many files in sequence, frequently with overlapping date ranges because bank download windows rarely line up neatly with month ends. That is exactly the situation where a CSV import quietly doubles a client's revenue and a .qbo import does not.

QuickBooks Online caps each upload at 1,000 transactions and about 350 KB, and Ledger inherits both limits. The size cap applies to .qbo, .qfx and .ofx files as well as to CSVs, so converting to QBO does not buy you a larger upload. A year of a moderately busy operating account will usually clear 1,000 rows on its own.

Split by date range rather than by row count, and never split in the middle of a day. Splitting mid-day is how a firm ends up with one day imported into two files and a reconciliation that is off by a handful of transactions with no obvious cause.

Ledger leaves out invoicing, estimates, receipt capture, bill payment, inventory, sales tax tracking and the accounts payable and receivable reports. Intuit also states that QuickBooks Payments, QuickBooks Bill Pay and certain third party app data are not serviceable in Ledger. What remains is bank activity, journal entries, reconciliation and the statements built on top of them.

Read that list as a design decision rather than a shortcoming. Ledger is meant to take raw bank data to a trial balance and then to a tax return. It is a poor fit for any client who needs to be billed, and an excellent fit for one who just needs a defensible set of numbers once a year.

Only accounting professionals with an active QuickBooks Online Accountant subscription. It is not sold to business owners and a client cannot sign up for it directly, though a firm can grant a client login access to the company file. Billing sits with the firm, per company file.

That makes the buyer for this page a firm rather than an owner, which is worth saying because it changes the arithmetic on tooling. A firm running catch-up work across a roster of Ledger clients is doing the same conversion many times a season.

After-the-fact accounting: write-up work, tax-only clients and year-end clients. These are the engagements where a firm receives a year of activity in one delivery, codes it, reconciles it, produces a trial balance and hands it to a tax preparer. Ledger strips out everything that does not serve that path.

The phrase after-the-fact is the tell. Every one of those clients arrives with history, and history is the thing bank feeds are worst at.

It works well, provided you treat the file import as the primary way transactions get in and the bank feed as a convenience for the current period. Firms that plan it the other way round lose time. The reliable sequence is to gather every account's full history as CSV from online banking, convert each account's file to .qbo, upload oldest first, then connect the live feed to carry the client forward.

Connecting the feed first is the common mistake. It seeds the register with the most recent quarter, and every historical file you upload afterwards has to be checked against transactions that are already sitting there.

Most rejections come down to four things: the file has the wrong number of columns, the dates are ambiguous, the amounts use parentheses instead of a minus sign, or the file is over the size cap. QuickBooks wants either three columns, Date, Description and Amount, or four, Date, Description, Credit and Debit. Anything else needs remapping before it will load.

Rather than editing the bank's file by hand in Excel, which is where date corruption creeps in, run it through a converter that reads the bank's own layout and writes a clean .qbo. Our tool maps the columns automatically, carries opening and closing balances, and handles split debit and credit columns without you touching the spreadsheet.

A US company file needs US dates. This sounds obvious and it is the single most common silent failure in QuickBooks imports, because the CSV formatting help article Google surfaces most often is Intuit's global edition, which recommends DD/MM/YYYY. Follow it for a US client and every transaction dated the 1st through the 12th of a month posts to the wrong month without any error message.

Excel makes it worse. Opening a bank CSV in Excel can reinterpret two digit years, where 00 to 29 become 2000 to 2029 and 30 to 99 become 1930 to 1999, and a file moved between Windows and Mac can shift by four years and a day because the two platforms default to different date systems.

QuickBooks Online can accept PDF and image statements with a side by side review step, but it is not a dependable route for a full year of catch-up work and it does not handle multi account statements. For volume, the practical path is to get the data into a clean spreadsheet first and convert from there.

If the client only kept PDFs, extract them to CSV before conversion rather than retyping. Firms often find that the same client also kept part of the year in Quicken, in which case converting the QIF export into a QBO file is quicker than rekeying it.

Only if you upload .qbo. QuickBooks skips FITIDs it has already seen, which is what makes overlapping .qbo files safe. It also remembers those identifiers after you delete the transactions, so re-importing a range you deliberately removed can appear to do nothing at all. CSV uploads have no such protection and will happily post the same rows again.

Our Plus plan writes unique transaction IDs into every converted file so QuickBooks can block a re-import, which is the feature that matters most when several people at a firm are working the same client file.

No. Importing bank transactions directly into a subaccount is not supported in QuickBooks Online, and Ledger inherits that limit. Import to the parent account and reclassify, or restructure the chart of accounts so the accounts receiving bank activity are not subaccounts.

It is worth catching this before you build the chart of accounts for a new Ledger client rather than after the first upload fails.

The conversion itself is deterministic. Every row in your CSV becomes one transaction in the QBO file with the same date, description and amount, and the file carries opening and closing balances so you can confirm nothing was dropped before you import. There is no interpretation step and nothing is estimated.

The check that actually catches problems is arithmetic. If the converted file's closing balance matches the statement, the row count is right. If it is off, the classic diagnostics apply: a difference that divides evenly by nine is transposed digits, a difference equal to exactly twice a transaction is a sign flip, and a difference matching a single transaction is one row that did not convert or one that was accepted twice.

It depends on how many accounts each client has, not how many clients you have. A single client with a checking account, a savings account and two credit cards over a full prior year is four conversions, and each of those may need splitting to clear the 1,000 transaction cap. Ten such clients in a January is comfortably over a hundred files.

You can convert three files without an account to see whether the output loads cleanly into a Ledger company before deciding anything. Starter covers a solo bookkeeper's monthly volume, Plus adds the unique transaction IDs and conversion history that matter when a team shares client files, and Pro adds API access for firms that want conversion wired into their own onboarding process.