Compare two bank extraction results: find changed and missing rows

Compare two extractions against the same source PDF, not just against each other. A higher row count or matching final total does not prove improvement. Keep both versions and classify missing rows, added rows and changed fields.

Separate formatting changes from source disagreements

Keep original values from A and B before normalising anything. A tidy file is not necessarily the more faithful file. Use a comparison log such as this proposed matrix.

Difference	First check	Classification after source review
`18.00` versus `18,00`	Numeric interpretation under each file’s convention	Same amount or parsing error
Description wraps in A, one line in B	Same printed transaction and complete wording	Presentation change or lost text
Debit in A, credit in B	Printed column and sign	Direction disagreement
One row in A, two in B	Whether B split a multiline description	Row-boundary disagreement
Same count and total	Dates, descriptions and source coverage	Still requires row and field review

Normalisation belongs in derived fields. Removing line breaks or spaces from the only copy of a description can erase the very difference you intended to inspect. Agree which differences are irrelevant to the task before declaring rows unchanged.

Practical method

Confirm identical PDF version, page range, account and currency. Label outputs A and B with extraction dates.
Pair rows using confirmed source locations or reliable identifiers. Separate ambiguous matches before comparing date, text, direction and amount.
Review each disagreement in the PDF. Record which value is supported; neither output is automatically the reference truth.

Fictional example

The following source locations and debit amounts in EUR are entirely fictional. The PDF column is the stipulated source reference for this example, not a result measured with BankStatementScan.

Source location	A	B	PDF
page 2, row 5	19.80	19.30	19.80
page 2, row 6	10.20	10.70	10.20
Total	30.00	30.00	30.00

A and B both total 30.00, matching the PDF, yet B contains two errors: −0.50 on the first debit and +0.50 on the second. The PDF confirms A for these two transactions. Equal totals therefore do not validate individual amounts or establish an overall accuracy rate.

Account for every row before choosing a version

Build a comparison sheet with one entry per confirmed source transaction: source locator, A value, B value, classification and PDF decision. Use four classes: present only in A, present only in B, present in both with changes, and present in both unchanged. Keep ambiguous pairings in a separate queue. Do not use the amount being evaluated as the only matching key: a changed amount would then appear as a missing row instead of a field difference.

For a fictional extension of the table, add one unchanged transaction, one found only in A and another found only in B. Each output now contains four rows, yet their union covers five source candidates: one unchanged, two changed, one A-only and one B-only. Check A: 1+2+1=4 and B: 1+2+1=4. Equal row counts conceal an omission just as equal totals conceal the two amount errors. The PDF must decide whether either unmatched candidate is a genuine transaction; “B-only” does not automatically mean “new correct row”.

For a small statement, manually aligning source locators is a usable alternative. Use a comparison that retains matched and unmatched rows from both outputs; check types and the uniqueness of each matching key. An inner-only comparison would hide the very unmatched rows you need to review. Before accepting an output, resolve or explicitly list each open candidate and recheck the original field values without overwriting A or B.

Prevent a many-to-many match from creating false pairs

Suppose two invented payments on the same date are both 25.00 in A and also both 25.00 in B. Matching on date and amount alone gives each A row two possible B matches. Expanding all matches produces four pairings from two transactions, not four transactions. Inspect the number of matches per key before expanding a merge. Use a confirmed source locator or a genuinely distinct reference to resolve the two pairs; do not manufacture an identity from the current row number after sorting.

When A and B split the source differently, page number alone will not solve the match. Return to the printed transaction boundaries and map each version’s component lines to the same reviewed transaction. Keep the ambiguous group visible until that work is done. Use compatible field types and the same field order on both sides of the comparison; these conditions do not make a repeated key unique.

Define what the comparison can conclude

For a complete review, list the confirmed source transactions and decide, for each version, whether every required field is correct. Check omissions and invented rows separately. If you review only a subset, state its size and selection: for example, “six invented source rows reviewed, including both page boundaries” is a scope description, not a general accuracy claim. Reviewing only disagreements is insufficient when both outputs can share the same mistake.

Keep a decision record with source locator, A value, B value, supported value, reason and unresolved status. Then produce a corrected third working file rather than overwriting the evidence. Recount its transactions and recompute its arithmetic controls after the corrections; a fix to one cell can change another check. Choose a version only when its remaining exceptions and your review scope are explicit. This procedure evaluates exported data; it does not measure the future BankStatementScan service.

Checks and limits

Record exact field differences and unmatched rows separately. A join on nonunique date and amount can multiply rows; inspect match counts before treating pairs as one-to-one. Keep unresolved disagreements visible. This protocol compares outputs and does not establish an overall accuracy rate without a defined, verified reference set.

Keep the original file unchanged and record any unresolved item before using the table.

Compare matching source locations and isolate differences between extraction versions. Trace a bank spreadsheet row back to its PDF page · Bank statement OCR mistakes: check 0/O and 1/I without guessing · Diagnose a bank PDF before choosing a table extraction tool.

BankStatementScan is in preparation. The site offers an access request and a fictional example; it does not currently convert your bank files. See the planned service.

Sources consulted on 16 October 2026

W3C — Model for Tabular Data and Metadata on the Web.