Extraction is only the first step
A clean-looking CSV can still omit a statement page, miss an account, or carry a balance that does not tie back to the printed document. Extraction creates candidate rows; it does not prove that those rows are complete.
bankstatements.us keeps that distinction visible by pairing normalized transaction rows with a separate reconciliation result. The rows remain useful for review even when the checks identify a problem.
Coverage checks look for missing evidence
Coverage compares the available statement evidence with the normalized result. It can surface gaps such as a missing requested page or an account named by the statement that is absent from the extracted accounts.
A coverage finding is a reason to review the source, not a reason to hide the rows. The result preserves both the available data and the specific finding so the next decision has context.
Balance checks test the transaction sequence
Where the statement provides balances, reconciliation checks whether transaction amounts progress through the printed checkpoints and whether the resulting account balance agrees with the stated ending balance.
These checks are deterministic and application-owned. Normalized values remain candidates until the coverage and balance rules establish whether the result passed reconciliation.
Read PASS and FAIL literally
PASS means the current coverage and balance checks reconciled for the result. FAIL means the result did not pass reconciliation; any available transaction rows and recorded findings remain available for review.
The job poll's report.status is the authority for overall reconciliation. Each CSV transaction row carries its account reconciliation status, so row-level export data does not replace or overstate the result-wide decision.