StatementToExcel

I built StatementToExcel because I kept wasting time copying bank-statement and invoice PDFs into spreadsheets by hand. The existing tools were either paid, required uploading sensitive files, or missed the exact rows I needed. So I made a browser-based converter that keeps files local, exports clean Excel/CSV, and uses a tiny AI vision model only when the PDF is a scan.

Works well for freelancers sorting invoices, small businesses importing into spreadsheets or accounting tools, and anyone dealing with mixed US/UK/EU layouts. The free tier covers everyday use without forcing a signup. I love that!

Parsing text-based PDFs locally and only falling back to AI for scans is a sensible privacy split for bank data. Statements often wrap long merchant descriptions onto a second line and print running balances. Does the parser merge those wrapped lines into a single row, and can it validate the extracted rows against the running balance to flag missed transactions?

When AI mode kicks in for a scanned statement, does that file leave the browser? It'd help to show a clear notice at that moment, since local-only processing is the main reason I'd trust this with bank PDFs.

Parsing text PDFs locally in the browser with no upload removes the first objection accountants raise. Do accountants or small businesses end up as the heavier users so far?

Ambiguous dates are the classic trap here: a UK statement with 03/04 can silently become 4 March instead of 3 April. Do you detect the locale per statement, and do you validate extracted rows against the opening/closing balance so users get a warning when a transaction was missed? An OFX or QBO export option would also save accountants a conversion step.

When you export to QuickBooks or Excel, keeping the raw statement description in its own column next to the cleaned merchant name makes categorization rules much easier to write. Keeping debit and credit as separate columns in the export also makes sign errors easy to spot during reconciliation.