The way to verify an automated bank reconciliation match before trusting it on a real client is to stop asking whether the vendor's logic is trustworthy in the abstract and instead run a known file through it: take a bank statement and ledger you've already reconciled by hand, run it through the tool, and check three things — does every item you matched manually also match in the tool, does the tool leave as exceptions exactly the items you expect it to (not fewer, not silently resolved), and can you see the actual rule it used (amount plus date window) rather than just a pass/fail result. If those three hold on a file you already know the answer to, the objection has been tested, not just dismissed.
The objections are usually one of four things
| Stated objection | What it's really asking | What actually answers it |
|---|---|---|
| "What if it matches the wrong things?" | Can two unrelated transactions get paired just because the amount and rough timing line up? | Check the match rule itself — amount must be exact, date window is configured by the engagement team, matching is one-to-one. Ask to see a sample of matched pairs, not just the summary count. |
| "What if it hides a real discrepancy?" | Does an unexplained difference get quietly netted off or written to a balancing line? | Confirm every unmatched item appears on a named exception list with no automatic clearing or write-off. If the tool can produce a zero-variance reconciliation without a human resolving every exception, that's the actual red flag. |
| "What if staff just trust the output without checking it?" | Does automation remove the junior's incentive to actually look at exceptions? | This is a firm review-process risk, not a software risk — it exists with Excel templates too. The fix is a review step that specifically checks the exception list was worked, not a software feature. |
| "Is this actually AI, and can I trust an AI's judgement on cash?" | Is there a black-box model making calls that can't be explained to a regulator or reviewed partner? | No — matching by exact amount and a date window is deterministic logic, the same rule every time, not a model making a judgement call. There's nothing to "trust" in the AI sense because there's no inference involved in the match itself. |
The test to actually run, step by step
- 01Pick a file you've already closedUse a prior-period bank reconciliation your team has already finished and reviewed by hand — ideally one with a handful of known outstanding cheques and at least one tricky item (a batch deposit, a bank charge that was recorded late).
- 02Run it through the matching engine coldUpload the ledger extract and the statement exactly as they were at the time, without pre-cleaning anything you wouldn't normally clean on a live engagement.
- 03Compare the matched set against your own working paperEvery item your team matched manually should match in the tool too. Any mismatch here is worth understanding before you move further — it may be a data formatting issue, not a logic issue, but find out which.
- 04Compare the exception list against your known outstanding itemsThe tool's leftover list should be the same outstanding cheques, deposits in transit, or discrepancies your team already identified — no more disappearing, none quietly resolved.
- 05Ask what rule produced each matchFor a handful of matched pairs, confirm you can see the amount and the date window that was applied. If the explanation is just "it matched," with no visible rule, that's a legitimate reason to push back before using it on a live client.
A tool that returns a tidy zero-variance reconciliation on a file you know had outstanding items is not a good result — it's evidence the tool is hiding or auto-clearing something. Treat an unexpectedly clean result as a reason to investigate, not a reason to relax.
What a reasonable verification does not require
It doesn't require reading source code, and it doesn't require taking a vendor's word for how the matching works. A deterministic rule — exact amount, a configured date window, one-to-one pairing — is simple enough to verify by behaviour: run known inputs, check known outputs. That's a different (and lower) bar than verifying a machine-learning model's judgement, precisely because there's no learned judgement in the matching step to verify.
How we think about this
Lekhya's matching logic is deterministic — the same amount-and-date-window rule applied the same way every time, with every unmatched item left visible rather than resolved automatically. That's a design choice specifically so a partner can verify it by running a known file through it, rather than having to trust a black box.
Common practice, not a requirement
Run the verification once per firm, not once per engagement — the point is to establish trust in the rule itself, not to re-litigate it on every client file.
This is practical guidance written for audit teams, not an authoritative statement of any standard or statute. Standards, forms and timelines change. Check the current text issued by the ICAI and the relevant authority before relying on anything here in an audit file.
Related resources
- Audit workflow & automationMulti-partner firm technology decisions: who needs to be in the roomA managing partner, an audit partner, and a quality-control partner are evaluating three different things when they look at the same software. Here's what each one actually cares about.
- Bank, cash & treasuryBank reconciliation audit procedure for statutory auditWhat a BRS must reconcile, the red flags that separate a timing difference from a cover-up, and how many months you actually need to review.
- Bank, cash & treasuryA bank reconciliation workflow for audit firms, not just a procedureMatching the ledger against the bank statement is mechanical. Doing it the same way across every client file, with every unmatched item actually explained, is the part firms get wrong.
- Technology, data & AI in auditMeasuring ROI of audit automation for a mid-size firm (10-30 staff)At 10-30 staff, the real ROI isn't hours saved on one file — it's whether a partner can review five engagements at once without five different working styles slowing every one of them down.
Free tools, no signup
Each one reads a file entirely in your browser — or, for two of them, just answers a few questions — and nothing is ever uploaded.
- Purchase register checkDuplicate payments, round-sum amounts, weekend-dated invoices, incomplete records.
- GSTR-2B reconcilerMatches your purchase register against GSTR-2B — missing invoices either side, amount mismatches.
- Bank reconciliation checkerMatches your cash book against a bank statement — what's outstanding on each side.
- Fixed asset register checkDuplicate asset codes, missing location or useful life, negative net book value.
- Payroll red-flag scannerBank accounts shared across employees, and records missing an ID, PAN or salary.
- CARO applicability checkerAnswer a few questions about the company and see which CARO 2020 clauses likely apply.
- MSME payment delay checkerMSME-flagged invoices paid — or still unpaid — beyond the 45-day Section 22 limit.
- Related-party transaction screenerTransactions above a threshold you set with no approval reference, grouped by counterparty.
- Depreciation useful life checkerCompares a useful life in use against the Schedule II, Part C indicative figure.
- Materiality calculatorOverall and performance materiality against PBT, revenue, assets or equity, with reasoning shown.
- Sample size calculatorStatistical sample size for a test of controls or a substantive test of detail.