Wells Fargo statement to Excel. The balances re-added row by row, and the page each figure came from.
You are holding a PDF someone else downloaded. It has to become a ledger you can post, and the person who checks your work will ask where a number came from. Both questions are answered by the same pass: the register is rebuilt, the balance chain is re-added, and every cell keeps a pointer to the page it was printed on.
Drop a Wells Fargo statement here
Or click to pick the file. It opens in the same page you would have used anyway — the balance chain starts re-adding on the next screen.
Three files free, 60 pages in total, no card needed. Paid plans are priced by the page — one page of the original is one page, up to 500 pages in a single file.
The problem is not extraction, it is sequence
When a statement prints a running balance beside the activity, that column is the whole audit trail — and it only works if the rows are in the order the bank printed them and no row was dropped at a page edge. A ledger that is missing two rows in the middle still looks perfectly ordinary; the balance column is what exposes it, which is why it is the first thing re-added rather than the last.
What gets checked before you download
Every line below is arithmetic on the paper you sent — not a supplier's claim about how good its reading is. Where the arithmetic fails, you get the row and the exact difference, and the statement is not called balanced.
Nothing dropped at a page edge
Rows seen on the page are counted against rows exported. A shortfall is reported, not absorbed into a shorter ledger.
Running balance re-added
Previous balance ± this amount = printed balance, for every row. Failures are named with page, line and the exact difference.
Opening and closing agree with the summary
The two figures in the header are compared with the first and last rows of the register, not with a recomputed guess.
The exported workbook carries the trail
Alongside the table there is a Review sheet: which cells a person confirmed, which they corrected, and what the printed value was before the correction.
Where a Wells Fargo statement goes wrong quietly
None of these announce themselves. Each one produces a file that looks correct.
Debit and credit columns reversed in a scan
On a rotated or skewed scan the two money columns can be swapped. The balance check catches it immediately — a swap breaks the chain on the very next row — and the row is flagged instead of being corrected.
Description columns that wrap
A merchant name that wraps to a second line is part of the row above, not a new transaction. Only a continuation with no date and no amount is joined.
A balance that is repeated
Two identical consecutive balances mean a zero-amount row or a duplicated line. Both are flagged; neither is deleted on your behalf.
What we will not claim
We are not claiming we know the Wells Fargo template. We claim something narrower and checkable: the arithmetic on the page you sent us was walked end to end, and every place it did not hold was listed.
The same goes for the arithmetic: a clean run means the checks we ran found nothing to flag. It does not mean the document is correct — it means nothing in it failed the checks listed above.
How it runs
Upload the statement
A native PDF, a scan, or a phone photo of the Wells Fargo statement. No bank connection, no credentials, nothing to authorise.
The ledger is rebuilt and walked
Rows are put back in the order the statement prints them, page furniture is removed, and the balance chain is re-added line by line.
Check the flags, then export
Anything that did not add up is listed first, with its page and exact difference. Then take the Excel file, the other export shapes, and the review sheet.
What lands on your disk
- The .XLSX register — one row per transaction, no merged cells, amounts as numbers
- A Review sheet: who confirmed or corrected which cell, and what it said before
- Plain CSV, Xero-shaped CSV, and QuickBooks .QBO with unique transaction IDs
- A check report stating the rows printed, the rows exported, and every difference found
- Every cell still clickable back to the page and region it was read from
- Files are read, then destroyed — a second upload is a second read
Questions
Can I trust the numbers without re-adding them myself?+
You can see exactly which ones were checked and which were not. The honest position is not 'trust it', it is 'the checks are on the page, and the cells that failed them are listed first'.
What about a statement that is partly scanned and partly digital?+
It is handled as one file. Scanned pages are the ones most likely to produce a doubtful figure, so their cells are flagged more readily — which is the point of the yellow marks.
Which export do I want for QuickBooks?+
The .QBO file — it carries a unique transaction ID per row and an opening and closing balance, which is what the import needs in order to be idempotent.
What does it cost?+
Three files are free, 60 pages in total, with no card and no account needed to try. Paid plans are sold by the page — $19 a month buys 1,000 pages — and a page is one page of the original document.
For the file that has to import cleanly somewhere else.
For the import where QuickBooks decides whether a row is already there.
The same checks, without naming a bank — including the ones whose layouts we do not recognise.
A .QBO with the institution, the account and a transaction ID per row, so a re-import is refused.