Bank Reconciliation

Bank statements arrive in any of four formats: CAMT.053 (ISO 20022), CSV (generic and bank-specific), OFX or SIE4. Format detection is automatic and deduplication uses a SHA-256 hash of the file contents so the same statement re-uploaded never creates duplicate rows. Auto-matching runs in two passes.

First, the club treasurer's own rules (counterparty-name regex, amount range, OCR prefix) execute in priority order; supported actions are book_to_account (post directly to a configured account), match_to_invoice_by_ocr (look up the invoice by OCR reference) and ignore. Second, heuristic matching applies: an exact reference or OCR match against an existing Payment scores 1.0 confidence, while fuzzy name plus amount plus date within 3 days uses Jaro-Winkler with threshold 0.85; anything below 0.6 is left unmatched. Unmatched lines feed the manual inbox, colour-coded green (high confidence), yellow (medium) and red (low or no match) with three actions per row: match against invoice, post as new entry or ignore.

Split matching is supported for one bank line that should clear several invoices. On every match the engine writes a balanced AccountingEntry voucher: incoming lines book debit bank, credit accounts receivable; outgoing lines book debit accounts payable, credit bank; new revenue posts as debit bank, credit revenue account. Balance reconciliation is the gate to locking: closing_balance must equal opening_balance plus the sum of all lines AND every line must be matched before status flips to locked.

The balance-check endpoint returns expected, actual and diff so the operator can spot a missing line before attempting to lock. The implementation under PL-T076 covers parser, matcher, admin inbox, AccountingEntry generation and the lock flow.