ExplainerSynthetic examples included

Why matching bank balances doesn’t prove extraction accuracy.

The closing balance matches, both totals match, and the row count matches. The file can still have two rows with their signs swapped, or one charge read twice in place of another. Sums cannot see an error that preserves them.

This page shows two such errors on an invented statement, beside a third error that the printed totals do catch. It explains why a converter’s own total cannot catch any of them, and how to decide which rows to read against the PDF.

cedar-yard-2026-04-flipped-transfers.csvSample
The two rows of the extraction that differ from the statement, with the printed amount and the extracted one.
DescriptionStatementFile
Transfer from savings500.00−500.00 (differs from the statement)
Transfer to payroll account−500.00500.00 (differs from the statement)
  • Closing balance Passes
  • Total credits Passes
  • Total debits Passes
  • Item count Passes
Two of twelve rows are wrong, and every figure the statement prints still agrees.

What a match rules out

A match is real evidence. It is not the whole of it.

If the opening balance plus every extracted amount equals a closing balance the statement printed independently, then the extraction carries no uncancelled net difference. That is all it shows: it says nothing on its own about whether each row was read correctly or is there at all. That is still worth having, and a file that fails it should not go any further.

What it cannot rule out is any set of errors that adds up to zero, however large each one is, or that leaves every sum and the count where they were. This statement is invented, and its figures are all the page uses.

Sample BankFictional statement
Account holder
Cedar Yard Landscaping
Period
Apr 1, 2026 – Apr 30, 2026
Opening balance
8,640.20
Total credits
7,250.00
Total debits
3,002.55
Closing balance
12,887.65
Items listed
12
The statement’s twelve transactions, as printed. It prints no balance beside each row.
DateDescriptionAmount
2026-04-01Client payment - Invoice 33013,200.00
2026-04-03Transfer from savings500.00
2026-04-03Fuel card−186.40
2026-04-07Cloud storage−85.00
2026-04-07Design software−85.00
2026-04-10Equipment rental−640.00
2026-04-15Transfer to payroll account−500.00
2026-04-16Client payment - Invoice 33041,450.00
2026-04-21Insurance premium−312.40
2026-04-24Truck lease−975.00
2026-04-28Client payment - Invoice 33082,100.00
2026-04-29Utilities−218.75

Every figure is invented. This statement prints its opening and closing balances, both totals and the number of items, and no balance beside each row. Credits are positive and debits negative in the download.

Download the faithful extractioncedar-yard-2026-04-faithful.csv

With the amounts in column C, rows 2 to 13, and the statement's own figures typed into F1 to F5 (opening, credits, debits, closing, then the item count), these are the checks a total allows. Each reads TRUE or FALSE; none has a tolerance.

Closing
=ROUND(F1+SUM(C2:C13),2)=F4
Credits
=ROUND(SUMIF(C2:C13,">0"),2)=F2
Debits
=ROUND(-SUMIF(C2:C13,"<0"),2)=F3
Count
=COUNT(C2:C13)=F5

The verification guide explains each, and why the typed figures must come from the PDF and not from the converter.

Two that match, one that does not

Wrong rows that every printed total accepts, and one it catches.

Each of these is a version of the statement above. The first two are wrong and still pass every printed total; the third fails them, for contrast. The tables show only the rows that differ from it; the downloads hold all twelve, so you can run the formulas on them.

Two transfers, directions flipped

Money in from savings is read as money out, and money out to payroll as money in. The two transfers are the same amount, so credits and debits trade 500.00 for 500.00.

Two transfers, directions flipped: the rows that differ from the statement. All twelve rows are in the download.
DateDescriptionStatementFile
2026-04-03Transfer from savings500.00−500.00 (differs from the statement)
2026-04-15Transfer to payroll account−500.00500.00 (differs from the statement)
  • Closing balance Passes
  • Total credits Passes
  • Total debits Passes
  • Item count Passes

Opening, closing, both totals and the count all agree with the statement. Only the two rows are wrong, and nothing on the page of totals says so.

Download this extractioncedar-yard-2026-04-flipped-transfers.csv

One row twice, its twin lost

Two charges of 85.00 sit on the same date. The extraction reads the first line twice and never reaches the second.

One row twice, its twin lost: the rows that differ from the statement. All twelve rows are in the download.
DateDescriptionStatementFile
2026-04-07Cloud storage−85.00−85.00 × 2 (differs from the statement)
2026-04-07Design software−85.00Not extracted
  • Closing balance Passes
  • Total credits Passes
  • Total debits Passes
  • Item count Passes

The amounts are the same, so every sum and the count are unchanged. What is missing is a description, and the one description that appears twice is wrong.

Download this extractioncedar-yard-2026-04-repeated-row.csv

The last row, lost

The final line of the statement does not make it into the file.

The last row, lost: the rows that differ from the statement. All twelve rows are in the download.
DateDescriptionStatementFile
2026-04-29Utilities−218.75Not extracted
  • Closing balance Fails
  • Total credits Passes
  • Total debits Fails
  • Item count Fails

No error cancels this one, so a comparison with the statement's figures finds it. A comparison with the converter's own figures does not.

Download this extractioncedar-yard-2026-04-lost-row.csv
Each extraction against the statement’s printed figures. The last column is a check only a statement that prints a balance beside every row allows; this one does not.
ExtractionClosing balanceTotal creditsTotal debitsItem countBalance beside each row
A faithful extractionPassesPassesPassesPassesPasses
Two transfers, directions flippedPassesPassesPassesPassesFails
One row twice, its twin lostPassesPassesPassesPassesFails
The last row, lostFailsPassesFailsFailsPasses

The first two extractions pass the four checks the printed figures allow, and the third fails them. The last column is a different check, which a statement that prints a balance beside each row would allow: each row’s balance must follow from the row above. It finds the first two and passes the third. Which check helps depends on which error was made, and the error is the one thing you do not know.

Independence

A total worked out from the same rows cannot disagree with them.

Take the extraction that lost its last row. Compared with the closing balance the statement prints, it fails. Compared with a closing balance worked out from the rows it did extract, it passes, because the figure was built from them.

A check is only as good as the independence of what it compares against. A figure the converter computed from its own output is a statement about the converter’s arithmetic, not about the statement.

The last extraction's closing balance, compared with two different figures. The statement prints 12,887.65.
Compared withThat figureResult
The closing balance printed on the statement12,887.65Fails
A closing balance worked out from the extracted rows13,106.40Passes

Where to look instead

Decide which rows to read before you see the file.

Matching totals do not show that any row is right, and they put no limit on how large a single error can be, because errors that cancel can be any size. A rule that picks the rows to read, from the statement alone, gives the reading a shape.

  1. Run the checks first

    Opening plus amounts, both totals, and the count, against figures typed from the PDF. A failure is cheap to find and stops the work early.

  2. Choose rows to read before looking at the file

    Rows whose amounts equal another row's, in either direction, and the largest credit and the largest debit. Decide this from the statement alone, so the extraction cannot steer it.

  3. Read those rows against the PDF

    Date, description and sign, not only the amount. A match is silent about all three.

  4. Keep a sample of the rest

    A handful of other rows, picked from the PDF by position and not by how they look, so the reading is not only of rows you already suspect.

  5. Record what you read

    A row read and found right is as worth recording as one corrected. The next reader needs to know it was looked at.

6 of 12 rows, chosen by rule before any extraction is looked at.
RowAmountWhy read first
Apr 1 · Client payment - Invoice 33013,200.00Largest credit
Apr 3 · Transfer from savings500.00Amount matches another row
Apr 7 · Cloud storage−85.00Amount matches another row
Apr 7 · Design software−85.00Amount matches another row
Apr 15 · Transfer to payroll account−500.00Amount matches another row
Apr 24 · Truck lease−975.00Largest debit
What each kind of check finds in the three wrong extractions. Neither covers all three.
ExtractionWrong rowsAmong the rows read firstCaught by the printed totals
Two transfers, directions flippedTransfer from savings; Transfer to payroll accountAllNo
One row twice, its twin lostCloud storage; Design softwareAllNo
The last row, lostUtilitiesNot allYes

On this statement the rule finds both transfers and both charges of the same amount, which is where two of the three errors sat. It misses the lost last row, which the printed totals catch. Reading and totals cover different ground, which is why the procedure runs both. It is a way of ordering a reading, and it promises nothing about the rows it skips.

DocShape

What the beta’s checks say, and what they leave to you.

DocShape compares a statement’s extracted amounts with the balances and totals it reads from that same statement, not with figures worked out from its own rows. The five checks are listed on how it works.

The extracted amounts reconcile with balances or totals DocShape read from the statement. This does not confirm that every transaction, date or description was captured correctly.

What a Verified result supports

  • The amounts agree, exactly, with the figures the statement prints.
  • A mismatch is reported as Needs review, and the file is still there to read.

What it leaves to a person

  • That each row has the right date and description.
  • That each amount sits on the right row, and in the right direction.
  • That no row was repeated and its twin lost, when the repeated amounts are equal.

The public beta reads one text-based PDF statement at a time and returns an Excel workbook and a CSV, on a best-effort basis. Reading the rows that matter against the PDF is the step the beta does not do for you, and the reasons above are why. For a folder of statements, the catch-up procedure adds the checks that run from one statement to the next.