PDF to QBO Converter

A .QBO file is a Web Connect file: the format banks hand out when you choose "download for QuickBooks". It is OFX underneath, plus a bank code (the INTU.BID tag) that QuickBooks checks before it accepts anything. QuickBooks Desktop's bank imports are built around it, and its CSV options are limited. QuickBooks Online accepts QBO, QFX and CSV uploads, and suggests QBO.

When the bank's download window has closed, the account is shut, or a client sent PDFs, there is no Web Connect file to download. This page makes one from the PDF: every transaction with its date, signed amount, description and a transaction ID, plus the statement's closing balance.

A file made from a PDF has no bank code of its own, and QuickBooks refuses a file without one ("Missing bid data"). Sonomir writes 3000, the code in Wells Fargo's own Web Connect files, which QuickBooks accepts for checking, savings and credit card accounts. So QuickBooks may show the bank as Wells Fargo during the import. That is only a label on the file: you choose which of your QuickBooks accounts the transactions go into, and nothing is sent to or from Wells Fargo.

Card and loan statements are written as credit card accounts; everything else as a checking account. If a statement mixes accounts, convert each one separately.

QuickBooks Desktop (Windows):

1. Convert the statement, check the summary says it reconciles, and download the QBO file.
2. In QuickBooks, choose File → Utilities → Import → Web Connect Files, select the .qbo file and choose Open.
3. Choose "Use an existing QuickBooks account" and pick the account, or create a new one, then Continue.
4. Review and add the transactions in the Bank Feeds Center.

QuickBooks Online:

1. Go to Bank transactions, open the Link account menu and choose Upload from file.
2. Select the .qbo file, choose the QuickBooks account it belongs to, and continue.
3. Pick the transactions to import and confirm.

Intuit's limits for uploads to QuickBooks Online are 350 KB and 1,000 transactions per file. A year of statements can pass that, so convert and upload a few months at a time.

• "Missing bid data": the file has no INTU.BID tag. Sonomir's files always carry one, so this usually means the file was opened and re-saved in another program. Download it again and import it unopened.
• "QuickBooks is unable to verify the Financial Institution information for this download.": the bank code was not accepted for this account. Import through File → Utilities → Import rather than double-clicking the file, and make sure QuickBooks is up to date. Intuit also suggests switching Bank Feeds to Classic mode. If it still fails, upload the CSV in QuickBooks Online instead.
• "QuickBooks found an error. We can't read the file…": the file was changed after download, often by Excel or a text editor converting it. Download it again.
• Duplicates: QuickBooks skips transactions whose ID it has already seen, and each transaction's ID stays the same however often you download the same converted result. Transactions that came in through a live bank feed have different IDs, so remove the overlap by date before importing.

In QuickBooks Online, the CSV works just as well and you can see every column before importing; use QBO when you want the import to feel like a bank download, or on Desktop, where it is the only route.

A typical 3-page statement costs 7 credits on a day when your 2 free pages are unused (one paid page at 5 credits, plus 2 for the QBO file), or 17 credits otherwise: about $0.35 or $0.85 at the $5-pack rate. The smallest purchase is $3 for 50 credits. If you convert dozens of statements every month, a subscription converter such as ProperSoft or MoneyThumb costs less per page, and ProperSoft runs on your own computer, so files never leave it.

The QBO file's layout has been compared with banks' own Web Connect files. Imports into QuickBooks itself have not yet been tested and recorded, so try the free pages on your own statement first.

Upload a bank statement — the PDF your bank emailed, a scan, or phone photos of the pages — and every transaction comes back as a row: date, description, money out, money in, a signed amount and the running balance. Transactions from every page land in one table, so a twelve-page statement is one list, not twelve fragments to stitch together.

Then comes the part that matters: the tool checks its own work. It adds up what it read and compares the result with the balances printed on the statement. When they agree to the cent, the extracted amounts are consistent with those balances. Offsetting errors can still cancel out, so a passing check is a useful review aid, not proof of accuracy. When they do not, it tells you by how much and flags the rows where the running balance breaks, so you check three lines instead of three hundred.

Two independent checks run on every statement.

1. Opening + money in − money out = closing. The opening and closing balances are read from the statement's summary or its first and last lines. If the transactions read in between do not produce the closing balance exactly, something is missing or wrong, and the difference is shown.
2. Row by row. Where the statement prints a running balance, each one must equal the previous balance plus that line's money in minus its money out. A break points straight at the problem: the flagged row, or the one just above it.

The arithmetic is done in whole cents, never in floating point, so a check cannot pass by rounding. Statements listed newest-first are recognised, and so are card and loan statements, where the balance is money owed and runs the other way.

A passing check shows that the extracted amounts agree with the balances that were read. It cannot rule out offsetting errors, omitted pairs of transactions, or incorrectly read balances. Check dates and descriptions, compare the row count with the source, and review important amounts before importing.

The Excel workbook has three sheets:

• Transactions — one row per transaction, in the order printed, with the page it came from and a Check column that says why a row was flagged.
• Balance checks — each check, whether it passed, and the numbers behind it.
• Statement summary — bank, the last four digits of the account, period, currency, opening and closing balances, totals, and whether it reconciles.

Amounts are stored as numbers, not text, so SUM works straight away. Dates are written as year-month-day when the statement makes the year clear, which sorts correctly everywhere. The CSV holds only the Transactions table, one rectangular sheet, because that is what accounting software expects to import.

Upload several PDFs at once — twelve monthly statements, say — and they come back in one workbook with a Statement column, plus a summary row for each.

A PDF downloaded from online banking already contains its text. That text is read in place, with each amount kept in the column it was printed in, which is why this path is the most accurate: the tool never has to guess whether 42.35 was money in or money out.

A scanned statement, or photos of printed pages, is read from the image. That works well on a flat, straight, well-lit page. It struggles with faint thermal-style printing, pages shot at an angle, and folds across the amount columns. The balance check is your safety net here: if a digit was misread, the running balance breaks at that row.

Photos uploaded together are treated as the pages of one statement, in the order you chose them. Each PDF is its own statement.

It is built for current, checking and savings account statements, and reads card and loan statements too. It is not built for investment or brokerage statements, where a row is a holding rather than a movement of cash. If your bank locks its statements with a password, enter it when the page asks: the PDF is unlocked in your browser, the password never leaves your device, and only the unlocked copy is uploaded. Without the password the tool cannot open it and will not try to get around it.

It has not been tested against a named list of banks, and this page will not pretend otherwise. Statement layouts vary enormously; what the tool offers instead is a result you can verify. If the checks pass, the extracted numbers agree with the balances read from the source. If they fail on your bank's layout, the job tells you so plainly.

Statements are sensitive, so here is exactly what happens. The uploaded file is sent to the reading model and deleted from storage when the job ends, whether it succeeded or not. Only the last four digits of an account number are kept. The transactions you see are stored with your job so the download still works if you come back later; use Delete this result to remove it sooner. Nothing you upload is ever published.

The first 2 pages a day are free, with the balance checks, and you can copy every row you see. That is enough to see whether the tool reads your bank's layout correctly before you pay anything.

Past that, pages are 5 credits each, and the Excel download is 4 credits once per job. With the two free pages still available, a six-page statement uses 20 credits for processing plus 4 for the workbook. If you have no credits, the smallest purchase is $3 for 50 credits, before any applicable tax; 26 credits remain after that job. Credits never expire, there is no subscription, and a job that fails is not charged.