How to Import a Bank Statement Into Google Sheets

Why can't I just paste my statement into Google Sheets?

A statement PDF stores positioned print text, not a table. Paste it into Sheets and everything lands in one column: dates, descriptions and amounts run together, wrapped descriptions split across rows, and page headers appear mid-data. Sheets' built-in File → Import understands spreadsheet formats — CSV, TSV, XLSX — not PDFs.

So the job has two steps: turn the PDF into a real table once, then import that table. The first step is where correctness is decided — if a number is wrong in the CSV, it will be wrong in Sheets, in every chart, and in every report built on it.

A purpose-built converter does the first step with a check a generic tool doesn't have: it reconciles the extracted transactions against the statement's own opening and closing balances, so extraction errors surface immediately instead of in next month's books. BankStatementWise exports both CSV and Excel from the same conversion, so either import route below works from one upload.

How do I import the converted file into Google Sheets?

Route 1 — CSV (the most portable):

• Step 1: Convert the statement and download the CSV export.
• Step 2: In Sheets, open File → Import → Upload and choose the file.
• Step 3: In the import dialog, set Separator type to Comma if it isn't auto-detected.
• Step 4: Turn OFF “Convert text to numbers, dates and formulas” only if your locale writes decimals with a comma (see the locale note below); otherwise leave it on so amounts arrive numeric.

Route 2 — Excel (.xlsx): upload the file to Drive and open it with Sheets, or use File → Import exactly as above. The .xlsx route preserves numeric amount and balance cells without any dialog choices, which makes it the safer default if you don't want to think about separators.

Either way, the shape you want after import is one row per transaction, a real date column, and amount/balance cells that Sheets treats as numbers — select the amount column and check that the SUM in the bottom-right status area shows a total, not just a count.

What about dates and decimal commas (non-US locales)?

Two settings interact with imported statements more than anything else.

• Spreadsheet locale. File → Settings → Locale controls how Sheets reads dates and decimals. If your statement uses day-first dates (31/01/2026) or decimal commas (1.234,56), set the locale to match BEFORE importing — a US-locale sheet will read 05/01 as May 1st when the bank meant January 5th, silently.
• Ambiguous dates. A converter that normalises dates during conversion removes this whole class of problem: the export carries full, unambiguous dates (year included, even where the PDF omitted it), so Sheets has nothing to guess about.

If amounts imported as text (SUM shows nothing), the usual cause is a separator/locale mismatch: re-import with the locale set correctly rather than patching cells one by one.

How do I verify the imported numbers in Sheets?

Two formulas prove the import, the same way an auditor would.

• Totals tie: opening balance + SUM(credits) − SUM(debits) must equal the printed closing balance, exactly. One cell: =opening + SUM(credit_range) - SUM(debit_range), compared against the closing balance.
• Chain check: each row's running balance equals the previous balance plus or minus that row's amount. Put the comparison in the first data row and fill down — one column verifies every line.

BankStatementWise runs both checks before you export — every statement is reconciled to the cent against its own balances, and unverifiable rows are flagged instead of guessed — so the Sheets-side formulas become a re-confirmation rather than your only line of defence. You can try it free with no sign-up and import the result straight into Sheets.