Bank reconciliation that explains itself

• Small firms that send invoices and chase payments.
• Bookkeeping assistants who reconcile bank statements every month.

Matching a month of bank transfers against open invoices is slow by hand. Payers leave out the invoice number, pay two invoices in one transfer, pay in instalments or lose a bank fee on the way. A simple lookup by invoice number and amount finds only the easy cases; a tool that guesses the rest can mark an invoice as paid when it is not.

1. Reads a bank-statement CSV and a list of invoices: a CSV of your sales invoices, and/or the supplier-invoice file that our doc2data demo extracts from PDFs. English and Italian column names are recognised (for example Data contabile, Dare/Avere, Descrizione operazioni), and amounts in 1.234,56 or 1,234.56.
2. Matches each bank line to its invoice or invoices: exact invoice number and amount, one transfer paying several invoices, instalments, a reference one character off or a deducted bank fee, and equal amount within the invoice's date window.
3. Explains every match with a confidence score and a plain-language reason. The score is a fixed value for each matching rule (for example 0.80 for amount and date only), not a percentage of certainty that the invoice is paid.
4. Does not guess. Nothing below a confidence of 0.80 is matched automatically. Two invoices that fit equally well, partial payments, weak guesses, bank lines with no invoice, invoices with no payment and unreadable rows all go to a review list, each with its reason.

Local processing runs on your own computer, with owner access.

All bank lines and invoices are invented by our own generator, with an answer key. Measured 5 October 2026; figures from the project's evaluation summary.

The baseline is the same engine restricted to exact matches (invoice number in the bank text and amount equal), roughly what a simple spreadsheet lookup does. Per the developer's record, consistent with the commit history, the "final" sets were generated once, after the last rule change, and never used to change anything.

• Match recall is the share of payments that should have been matched and were.
• On the normal sets every bank line got the right outcome; on the final hold-out set, 90 of 90.
• 0 wrong automatic matches is a measured count on synthetic sets, not a guarantee.
• On the stress sets, built from harder cases to find the limits, the tool made no wrong automatic match but sent about half of the payments that should have matched to the review list. On the final stress set, 23 of 40 bank lines got the right outcome.
• The generator and the rules were written by the same developer. These results show the rules do what they are meant to do; they do not show how the tool performs on your bank's exports.

Python, pandas, openpyxl, Streamlit; tests with pytest and Playwright; packaged with Docker.

• Left for a person, by design: payments with no reference that are also early, late or short by a fee; payers written as an acronym; truncated bank text.
• Not handled: discounts, currency conversion, and netting credit notes against invoices. Credit notes (negative amounts) are reported as unreadable rows.
• Dates must be ISO or day-first; US month-first dates are rejected. One currency per match.
• Supplier invoices from doc2data carry no due date, so a 60-day term is assumed for the date window.
• Not tested on real bank exports. Bank CSV layouts differ from bank to bank.
• Not accounting advice.

Source: snello-reconcile README and reports/summary.json, measured 5 October 2026 (final-set line counts from reports/final_holdout and reports/final_stress). Code is private, so it is not linked.