Convert PDF bank statements to QBO for QuickBooks

Why PDF to QBO is harder than CSV to QBO

Wrapping a CSV in an OFX envelope is mechanical work. A PDF gives you none of that structure. A bank statement PDF is a page layout, not a table: the description sits at one x-offset, the amount at another, and the running balance at a third, with nothing in the file that says those three things belong to the same transaction. Multi-line descriptions wrap onto a second visual row that looks identical to a new transaction. Page headers and footers repeat mid-document. Credit card statements split debits and credits across separate columns without labeling them. Scanned statements have no text layer at all.

That extraction step is where generic PDF to QBO converters fail. Once you have accurate transactions, generating the QBO file itself is straightforward. So the accuracy of the reader is the whole product, and it is what Karchu is built around.

How the extraction works

Karchu reads the PDF at the glyph level and clusters glyphs by their x-position into column bands, then groups those bands into rows using a vertical tolerance derived from the document's own line height. That means a description that wraps onto a second line is merged into the transaction above it rather than becoming a phantom row with a blank amount, and a running balance column is never mistaken for the transaction amount because the two occupy different bands.

Repeated page furniture (headers, footers, column titles, page numbers) is detected by frequency across pages and dropped. Dates are normalized to ISO 8601 no matter whether the bank wrote DD/MM/YYYY, MM-DD-YY, or "12 Mar". Amounts are parsed with locale-aware separators, and parentheses or trailing CR/DR markers are converted into signs, so a debit written as (1,204.50) becomes -1204.50 rather than a positive figure that lands in the deposit column of your QuickBooks register.

Scanned statements and OCR

When a PDF has no extractable text, Karchu falls back to an OCR pass over the page images. The OCR output goes through the same column clustering, so a scan of a statement produces the same structured rows a digital PDF would. Before that runs, the file is validated for the conditions that break every OCR pipeline: password protection, truncated files with a missing end-of-file marker, and PDFs with no page tree. If one of those is the problem you get a plain explanation of what to fix instead of a failed conversion.

Every extracted field carries a confidence score. Low-confidence values are highlighted in the review table so you can correct the handful of rows the scan garbled instead of proofreading all three hundred. Corrections are saved, and the same statement re-run later keeps them.

Deterministic categorization before the export

A QBO import that lands three hundred uncategorized transactions into the QuickBooks For Review queue has not saved you anything. Karchu applies your rule set before the file is generated. Rules match on merchant name, keyword, amount range, or transaction direction, and they are deterministic: the same statement always produces the same categories, and every categorization is traceable to the rule that made it. That matters at audit time and it matters for month-over-month comparability.

The assigned payee and memo travel into the QBO file's NAME and MEMO fields, which are exactly the strings QuickBooks bank rules match on. So even the rows QuickBooks re-evaluates on its side arrive with the right information for its own rules to fire correctly.

What ends up in the QBO file

• BANKID / ACCTID. Routing and account identifiers so QuickBooks attaches the file to the right register.
• ACCTTYPE. CHECKING, SAVINGS, or CREDITLINE, matched to the account type in QuickBooks.
• DTSTART / DTEND. The statement period, in the YYYYMMDDHHMMSS format QuickBooks requires.
• FITID. A stable hash of date, amount, and normalized description. QuickBooks dedupes on it, so overlapping periods are safe.
• TRNTYPE. DEBIT or CREDIT derived from the sign, so nothing lands in the wrong column.
• DTPOSTED and TRNAMT. Posted date and signed amount at two-decimal precision, no currency symbols.
• NAME / MEMO. Payee and description from your categorization rules, truncated to the limits QuickBooks silently enforces.

Karchu vs per-file PDF to QBO converters

Most converters in this category charge per statement or per page, cap the number of transactions, and stop at the OFX envelope. They skip FITID generation, so a second import duplicates every row. They skip categorization, so the file is only as useful as an unsorted CSV. And they usually cannot read a scan at all. Karchu handles the scan, the extraction, the categorization, and the envelope in one pass, with no per-file fee. If you have been paying per QBO file, that is the practical difference.

Frequently asked questions

Convert a statement now

Sign in, upload the last PDF your bank sent you, review the highlighted fields, and export the QBO. Import it into QuickBooks Web Connect and check the register. If it is cleaner than what your current converter produces, keep going.