The problem with most bank recs
Bank reconciliations are the first thing auditors test and the last thing anyone wants to redo. In most teams they're still built in spreadsheets: export, paste, VLOOKUP, eyeball the leftovers, type a plug. Software helps with matching, but often leaves reviewers with the same question: why did these two lines match?
The reviewer ends up re-checking the work. The auditor does it again.
How Yoraito reconciles a bank account
1. Connect, don't paste
Yoraito pulls bank activity and GL cash detail from the systems you already use: 22 named systems, 11 of them direct. Each import is profiled first: row counts and totals on both sides, so you know nothing was dropped.
2. Match with written rules
Matching runs in passes, and every pass is a rule a person can read:
| Pass | Rule | Why it exists |
|---|---|---|
| 1 | Same amount, same date | The clean majority |
| 2 | Same amount, dates within 3 days | Clearing delays |
| 3 | Same amount, same check number | Checks that clear late |
| 4 | One bank line = sum of several ledger lines on the same date | Batched deposits |
Amounts must match exactly. Dates and references can flex within written limits; amounts never do. Every match records the pass that made it.
3. Explain what's left
Unmatched lines are sorted, not dumped:
- Bank only: fees, interest, unrecorded debits and deposits.
- Ledger only: outstanding checks, deposits in transit.
- Possible duplicates: the same check posted twice in the ledger.
AI drafts a note for each, labelled by how well it's supported, and proposes entries for a person to approve. Nothing posts by itself.
4. Prove the tie-out
The reconciliation shows the difference before adjustments, each reconciling item, and the final difference of $0.00. Each line carries the ID of the query that produced it. If it doesn't tie, Yoraito shows the remaining difference as an open item. It never forces a zero.
5. Review and sign
The reviewer sees the evidence (rules, items, queries) and signs. Preparer and reviewer are recorded separately with dates.
What a reviewer sees
Reconciliation card (illustrative):
| Field | Value |
|---|---|
| Account | Operating cash · 1010 |
| Period | October 2026 |
| Bank ending balance | $191,035.40 |
| Ledger ending balance | $180,932.80 |
| Outstanding checks | -$3,640.00 (1 item) |
| Bank-only items to record | -$1,337.40 (2 items) |
| Ledger duplicate to reverse | $7,800.00 (1 item) |
| Difference after items | $0.00 · balanced |
| Evidence | View SQL (Q01–Q12) |
Illustrative example; figures from the Yoraito sample dataset.
Why SQL matters for a bank rec
A match made by a model with a confidence score is hard to test: an auditor can't rerun a confidence score. A match made by a written rule, with the query saved, can be reproduced by anyone with the same data. That's the difference between a reconciliation someone reviewed and one someone can reperform.
Built for
- Controllers who want cash reconciled weekly, not just at month-end.
- PE-backed finance teams with several bank accounts across entities and a sponsor deadline → /solutions/pe-backed-companies
- CPA and CAS firms reconciling dozens of client accounts on different GLs → /solutions/accounting-firms
Try the method free first
Not ready for a call? Our free Bank Rec Tie-Out skill for Claude runs the same four-pass method on exported files and writes a Trace sheet with every query → /claude-skills/bank-rec-tie-out. Prefer a spreadsheet? Download the free bank reconciliation template → /resources/bank-reconciliation-excel-template.
Weekly, not just monthly
Because matching is rule-based, you can reconcile cash every week instead of waiting for month-end. By BD1, only the last few days of activity are left to match, and reconciling items have already been chased. Teams that move cash to a weekly cycle usually find it's the single biggest change in how the close feels.
Common bank rec problems, and how Yoraito handles them
| Problem | What usually happens | In Yoraito |
|---|---|---|
| Bank exports withdrawals as positive numbers | Matches fail silently | Sign convention checked and shown before matching |
| A deposit covers five invoices | Manual splitting | Pass 4: one bank line to several ledger lines |
| A check clears two months late | Ages on the rec, forgotten | Flagged at 60 days with its owner |
| The same check is posted twice in the ledger | Found at audit | Classified as a possible duplicate with both postings shown |
| The rec "ties" with a plug | Hidden error | No plug line; any remaining difference stays open |
| Statement imported twice | Duplicate bank lines | Input profile shows row counts and totals at every import |
Your first month
| Week | What happens |
|---|---|
| 1 | Connect bank accounts and GL; check last month's input profiles |
| 2 | Reconcile last month as a test; compare with your existing reconciliation |
| 3 | Live: reconcile the current month weekly |
| 4 | Month-end tie-out; reviewer sign-off in Yoraito |
Controls built in
- Preparer and reviewer recorded separately; nobody approves their own work.
- Proposed entries wait for approval; nothing posts automatically.
- Text in bank descriptions is treated as data, never as an instruction.
- Every figure reproducible from its saved query.