How it works
Extraction
The PDF is read with pdf.js, which returns every piece of text on the page along with its exact position. Those glyphs are clustered into rows by vertical position, then into columns by looking for a header row (Date / Description / Amount / Balance) or, if there isn't one, by looking at where text tends to line up — dates cluster on the left, amounts are right-aligned. A row only becomes a transaction if it has both a date in the date column and an amount in an amount column; everything else goes to the skipped-rows list rather than being silently dropped.
The four reconciliation checks
- Balance chain
- For every consecutive pair of rows with a printed running balance: previous balance + this row's signed amount must equal this row's balance. Any mismatch is flagged on the exact row. Skipped when the statement has no running-balance column — some banks and most card statements don't print one.
- Statement totals
- Opening balance plus every extracted transaction must equal the closing balance, both read directly off the statement. This is the check that catches missing or misparsed rows even when there's no per-row balance to chain against.
- Transaction count
- When a statement states how many transactions it contains, the extracted count is compared against it. Skipped when the statement doesn't print a count.
- Date sanity
- Every transaction date must fall inside the statement's period and dates must be in order — catches a misparsed month or a row pulled from the wrong section.
A statement is only marked Reconciled when every runnable check passes. If any check had to be skipped because the statement doesn't contain the data it needs, the result is Partially verified — never a false green badge.
Provenance
Every extracted field keeps a reference to the exact glyphs it came from. Click any row in the review table and the source PDF page renders beside it with those glyphs highlighted — so you can check the parser's work against the original document instead of trusting it blindly.
QBO, OFX, QFX, and the INTU.BID field
QuickBooks doesn't import a PDF directly — the standard route is a QBO file, which is Intuit's variant of the OFX format with a few extra header fields, most notably INTU.BID (an Intuit-assigned bank identifier). Intuit's own program expects a financial institution to register that ID; we don't fabricate one on your behalf. The export panel lets you enter it if your bank has told you what it is — otherwise leave it blank, or use plain OFX/QFX instead, which don't require it.