Keep a correction log for a bank extraction: before, after and why

Correct a working copy and keep a separate before-and-after log. The purpose is to explain each change, not merely to announce that the table was reviewed. A note such as ‘fixed totals’ cannot justify an altered transaction.

Record evidence before changing a field

Record extraction ID, field, old value, new value, source location and reason. Add correction date and review status.
Require visible source evidence for amount or date changes. Mark proposed corrections separately from approved ones.
Keep the raw extraction and current working version. Link the log to the exact versions so later edits do not overwrite history.

Fictional example

For fictional row E-0042, log amount: 18.80 → 18.30; DOC-01 page 3 row 7; digit confirmed in PDF; reviewed. If the image is blurred, record a proposal with unresolved status instead. Do not label the guessed value as confirmed because it improves the balance.

Separate a decision from its application

For a small statement, use a manually maintained log alongside the working table. The following workflow is a proposed control, not a BankStatementScan feature: give each change its own correction ID and distinguish proposed, approved, applied and reversed. Include the input and output version. Approval alone must not imply that the exported file contains the new value.

Extend the fictional E-0042 entry with C-001; work-v1 → work-v2; debit EUR 18.80 → 18.30. Before applying it, check that work-v1 still contains 18.80 for that same row and field. If it now contains 18.60, stop and investigate the intervening edit rather than recording a false “before” value. With outflows treated as negative, the signed amount changes from −18.80 to −18.30, an increase of +0.50. Recompute the affected total for verification, but keep the visible PDF digit as the reason for the change.

If C-001 is later rejected, add C-002; reverses C-001; 18.30 → 18.80 and identify the resulting version. Do not erase C-001 or restore the entire old workbook if that would discard unrelated approved edits. Re-read the delivered row and verify that its last applied change agrees with the log. A positional index alone establishes neither a source mapping nor a history of approved corrections.

Keep row identity when the workbook changes

Freeze the raw extraction before sorting or filtering. Give a source row a key such as DOC-01:p3:r7:extract-v1 and retain it in the working table. A worksheet row number is a position: row 42 can hold a different transaction after a sort. If a new extraction splits one row into two, map the old key to both new keys and review the relationship; do not apply the old correction automatically to whichever row now occupies that position.

Use this handover record for the fictional C-001. One record describes one field change; several field changes can share a review batch without losing their individual before values.

Record element	Fictional value	What it lets the next reviewer check
Correction and source key	C-001; DOC-01:p3:r7:extract-v1	The same source transaction is being edited
Field and unit	Debit; EUR	A debit magnitude is not confused with a signed amount
Before → after	18.80 → 18.30	The working value still satisfies the precondition
Evidence and decision	Visible PDF digit; approved	A proposal is distinguished from an accepted reading
Application receipt	work-v2; delivered row checked	The approved change reached the actual file

An applied correction must survive a refresh. Test this on a copy: refresh the import, then look up the source key and compare with the last applied entry. If 18.80 returns, the refresh has regenerated the raw value; reapply only approved corrections whose source key and before value still match. Keep failures pending. Never silently replay a correction onto changed source data.

Two corrections can cancel in a total. In a separate fictional batch, changing signed −18.80 to −18.30 adds 0.50, while +40.00 to +39.50 subtracts 0.50. Net change is zero although two cells changed. Check both delivered values and two application receipts, rather than accepting an unchanged total. This log supports a reproducible review; it does not establish the authenticity of the bank document.

Checks and limits

Sample a correction and reproduce it from the PDF and old value. Check that reversing a logged change restores the previous working value. A stable index helps identify rows but does not provide an audit certification. Keep reviewer names or source files private where appropriate; public examples should use neutral fictional identifiers.

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

Connect each correction to its source location and extraction version. Trace a bank spreadsheet row back to its PDF page · Compare two bank extraction results: find changed and missing rows · 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.