| 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
- Hash each source statement and compare it with the candidate
source_file_sha256.
- Independently parse the source statement. Do not rely on the identifier agent's parsed rows.
- 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.
- Mark rows as
verified, rejected, or unresolved.
- 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.
