statement-reconciliation

name	statement-reconciliation
description	Use this skill whenever candidate transaction rows must be verified against original bank or card statements before export, especially for messy PDF, CSV, XLS, or XLSX statements where deterministic checks and careful fuzzy matching are both needed.

Statement Reconciliation

Verification protects the accountant CSV from invented, duplicated, or miscopied transactions.

Inputs

• Original statement files from statements/inbox/ or the path named by the user.
• Candidate rows from work/candidates/.

Verification Workflow

1. Hash each source statement and compare it with the candidate source_file_sha256.
2. Independently parse the source statement. Do not rely on the identifier agent's parsed rows.
3. Reconcile each candidate against the parsed source:
   • Amount must match exactly after normalizing sign, currency, and decimal formatting.
   • Date must match the statement date, posted date, or a documented date-window rule from the statement.
   • Description must match exactly or have a clearly explainable fuzzy match.
   • A source row may verify only one candidate unless duplicate transactions exist in the statement.
4. Mark rows as verified, rejected, or unresolved.
5. Export only verified rows.

Handling Messy Statements

• For PDFs, try table extraction and text extraction before visual or OCR-based reasoning.
• For spreadsheets, inspect workbook sheets and headers before selecting rows.
• For CSVs, preserve the original row number where available.
• For scanned or irregular statements, use probabilistic judgement only to locate candidate descriptions after amount and date checks narrow the search.
• Record any parser limitation in verification_notes.

Outputs

Write verification reports to work/verification/ and final verified rows to the export step. These files are gitignored because they contain transaction data.