# Bank reconciliation > Bank reconciliation: Which ledger entry a bank line is; why a line is unmatched Checked: proven by code. Produces reconciled account, proposed entries, open items. Source: https://www.sumarity.ai/library/bank-reconciliation/ Finance and accounting # Bank reconciliation Reads bank statements (MT940, camt.053, CSV), the ledger's cash account. Produces reconciled account, proposed entries, open items. Code works out every figure, the Judgement Engine answers the narrow questions, and whatever stays uncertain goes to a person. Proven by codeTestedReconciliation and matching Start from this workflowMore for finance What it decides ## Narrow questions, each with a check behind it. Which ledger entry a bank line is; why a line is unmatched Proven by code: balances walk, amounts tie. Code proves the answer from the data itself: totals tie, a match is exact, the quote is on the document. Most of these judgements settle without a person. | Reads | Bank statements (MT940, camt.053, CSV), the ledger's cash account | Produces | Reconciled account, proposed entries, open items | Who signs | A person on your team, with every figure traced to its document and every call on record | Process | Reconciliation and matching | Industry | Finance and accounting See it run ## Every line, decided where it's safest. An example run. Each stage lights up as a line is decided there; pick a stage to see its lines. ReadsBank statements (MT940, camt.053, CSV), the ledger's cash accountCodeReads, matches, ties out and works out every figure.JudgementWhich ledger entry a bank line is; why a line is unmatched. Settles only when it clears the cutoff and code proves it.A personGets whatever stays uncertain, with the evidence. Their ruling tunes the next run.ProducesReconciled account, proposed entries, open items Bank reconciliation · run 2026-09 · v7 Example run | Date | Line | Amount | Decided by | 02.09 | STRIPE PAYOUT 0902Ties to 14 card sales, less fees | 1,284.50 | Code · tied | 03.09 | RUECKLASTSCHRIFTReturned payment · 0.97 · reverses receipt R-1182 | −320.00 | Engine · proven | 04.09 | GUTSCHRIFT M KELLER AGTiming match to INV-2207 · 0.91 · payer named | 450.00 | Engine · proven | 05.09 | CHQ 004417Cheque number matches ledger, one to one | −2,150.00 | Code · matched | 08.09 | VIREMENT REF 88213Two customers paid 1,200.00 · no proof which | 1,200.00 | To a person | 09.09 | INV-2214 ledger 1,540.00Keying error? · 0.73 · below the cutoff | 1,450.00 | To a person | Settled 4 To a person 2 Settled wrong 0 Illustrative lines in the style of our test months. Amber rows are the Judgement Engine's calls; each settles only above its cutoff and when its code check agrees. Tested ## Measured, not promised. 0settled wrong 108 of 108exceptions surfaced 176 → 7judgement calls sent to a person How we test · All results What it could save ## Your volumes in. Your hours out. In our tests, between 24% and 42% of items still went to a person after tuning. Set your own share; a pilot measures it on your data. Items per run Runs per month Minutes per item by hand Cost per hour Share of items that still need a person: 30% By hand today80 ha month With Sumarity24 ha month, for the items people decide Saved56 hCHF 53,760 a year Related ## Start from what's closest. ### Reconciliation and matching in other work Finance ### Card and payment-processor settlement reconciliation Which sales a payout covers; fee and chargeback lines Proven by codeFinance ### Intercompany reconciliation Which entries are the two sides of one transaction Proven by codeFinance ### Payroll reconciliation Which payroll totals tie to GL and bank; why not Proven by code ### More for finance ### Card and payment-processor settlement reconciliation Which sales a payout covers; fee and chargeback lines Proven by code ### Cash application Which open invoices a receipt pays; short-pays and deductions Proven by code ### AP invoice processing with two- and three-way match Which PO and receipt an invoice is for; price and quantity differences Proven by code Questions ## What buyers ask What happens when Sumarity isn't sure? Nothing settles below the cutoff, or when the check disagrees. The item goes to a person in the inbox with what the engine saw, its best answer and the runner-up. The person's ruling is kept and tunes the next run. How are its judgements checked? Code proves the answer from the data itself: totals tie, a match is exact, the quote is on the document. Most of these judgements settle without a person. Can we change it to fit how we work? Yes. Start from this workflow and describe your differences in plain words. The design assistant revises it, the validator checks it, your expert reviews it on the canvas, and your admin publishes it. Does it read our files as they are? Yes: spreadsheets and CSV in any layout, PDFs, bank formats and e-mail attachments. Sumarity suggests how each column maps, proves the mapping on a sample and remembers it once a person confirms it. Where does our data go? Sumarity runs in Zurich. Your data, backups and logs are stored in Switzerland. How does it get better? Your team's rulings become an answer key. Better questions and cutoffs are proposed, tested on data they haven't seen, and published only when your admin approves. It improves itself, with permission. ## Start from this workflow. Run it on your data. A pilot runs alongside your own process for a few weeks, at our cost, and ends in a line-by-line comparison. Talk to usBack to the library