How it works
How a PDF statement becomes a verified spreadsheet
The interesting part of this product is not the conversion — plenty of tools produce a spreadsheet. It is the check that runs afterwards, and this page explains exactly what that check does.
- 1
Your browser opens the PDF
The file is read locally with pdf.js. Only the positioned text runs are sent onward; the PDF itself never leaves your device.
- 2
Lines and columns are reconstructed
Text items are grouped into visual lines by vertical position, then clustered into columns by horizontal position and width.
- 3
The layout is identified
Candidate interpretations are generated — separate debit and credit columns, a single signed amount, section-grouped amounts — and each is tested.
- 4
The arithmetic is checked
Every extracted row is re-added with exact decimals and compared against the balances and subtotals printed on the statement.
- 5
You review, then decide
The equation, both numbers, the difference, and a ten-row sample are shown. The $19 payment step appears only if the check passed.
Why a PDF statement is hard to read
A PDF does not contain a table. It contains instructions to draw glyphs at coordinates. When your bank generated the statement, the table structure was thrown away — the columns you see are an artefact of where the text happens to sit on the page.
Recovering the table means inferring it back. Which vertical positions constitute one row. Which horizontal band is the description and which is the balance. Whether a short line is a wrapped continuation of the row above or a transaction of its own. Whether the two right-hand columns are debit and credit, or amount and running balance.
Each of those inferences can be wrong in a way that produces a perfectly plausible spreadsheet. That is the actual problem: not that conversion is difficult, but that incorrect conversion is invisible.
The four mistakes that matter
- A wrapped description read as an extra transaction, inflating the row count
- Debit and credit columns transposed, flipping the sign of every amount
- A date like 03/04 read in the wrong day-month order, scrambling the ordering
- A misread decimal separator turning 1.234,56 into 1.23 or 123,456
Reconciliation
The four ways a statement can be balanced
Whichever your statement supports is the one used, and the panel names it so you know which claim is being made. Statements that support more than one are checked against all of them.
Opening and closing balance
Opening balance + credits − debits = closing balance
The strongest check available on a current or savings account. Every extracted row contributes, so any dropped, duplicated, or misread transaction changes the result.
Running balance chain
Each row's balance − previous row's balance = that row's amount
When the statement prints a balance beside every transaction, each row can be checked individually. This does not just detect an error, it localises it to a specific row.
Credit card category totals
Previous balance + purchases + fees + interest − payments − credits = new balance
Card statements print subtotals per category. Each extracted transaction is attributed to a category and the subtotals are reproduced independently.
Stated totals
Sum of debits = stated total debits; sum of credits = stated total credits
Some statements print total debits and total credits without usable balances. Reproducing both totals exactly is weaker than a balance chain but still catches every arithmetic error.
Reconciliation also breaks the tie on layout
When a page could plausibly be read two ways — say, the last two numeric columns are either “debit, credit” or “amount, balance” — both readings are built and both are checked. A reading that balances against the statement’s own figures is almost certainly the right one; a reading that does not is discarded. If no reading balances, none is offered for sale.
Checks that are not about arithmetic
A statement can add up and still be wrong. These run alongside the balance check, and some of them can fail a statement on their own.
- Duplicate detection: identical date, description, and amount appearing more than once where the statement shows it once
- Sign coherence: a row that is both a debit and a credit, or an amount whose direction cannot be established
- Date continuity: transaction dates falling outside the statement period, or ordering that contradicts the running balance
- Impossible dates: 31 February and similar, which indicate a misread rather than an unusual statement
- Multiple accounts: more than one account number in the document, which makes a single balance check meaningless
What happens when a statement fails
You are shown what we read, which check was applied, the two numbers that did not agree, and the difference between them. Then the process stops. The payment step is not rendered, and the server will refuse to create a checkout session for a result that failed verification even if the request is made directly.
We show you the failed extraction on purpose. It is your statement, you are entitled to see what a tool made of it, and the discrepancy is often informative — a difference exactly equal to one transaction usually means a row was missed, and a difference of a round amount often means a fee line was read as a heading.
Nothing is charged, so there is nothing to refund. If you think the statement should have been readable, tell us about the layout — the bank and the shape of the table, never the statement itself.
Finding out whether your statement can be verified costs nothing.