Reconciliation with AI assistance · AI for Accountants

Bank reconciliation is the place where most Nepali accountants first met AI seriously, because the problem is so obviously a pattern-matching problem and the relief, when the matches come back, is so immediate. A model pairs eighty percent of your statement against your ledger in seconds. You feel ten years lighter. The danger of that feeling is the subject of this section, because the eighty percent that matched was never the work — the work has always been the twenty percent that did not, and the temptation to treat AI-matched rows as “done” is precisely the way reconciliation goes quietly wrong.

What AI is genuinely good at, in 2026

Be honest about what the tool is for. Modern LLMs and the rules engines built on top of them are good at three things in reconciliation, and you should use them for exactly those three.

1. Pairing obvious matches by date and amount. A रू. ४,५०,००० debit in your ledger on Asar 12 and a रू. ४,५०,००० debit on your NIC Asia statement on the same date with a narration that mentions your supplier’s name is a match. The model will find it. It will also find the harder ones — same amount, one-day offset for cheque clearing, narration that uses your supplier’s PAN instead of name, FonePay payments where the merchant name in the narration is the aggregator rather than the actual payee. These are pattern-recognition problems and the model is genuinely faster than a human eye.

2. Generating candidate explanations for unmatched items. This is the more interesting capability and the more underused one. For each item the model could not match, it can offer a short list of likely reasons: timing difference (cheque issued but not presented), bank fee not yet posted to the ledger, FX rounding on a USD settlement, digit transposition (रू. ३४,५०० posted as रू. ४३,५००), duplicate posting on one side, or a genuine missing entry on the other. A good model, given the ledger and the statement together, can rank these by likelihood for each row.

3. Summarising the unmatched-items list into a memo. Once you have decided what each unmatched item is, the model is a perfectly good drafter. It will turn “the seven items below are timing differences clearing in the first week of next month; the three items below are bank fees pending posting; the one item below is a transposition error to be corrected by JV” into a clean memo for the file. This is real work, well done.

What AI is not for

Three jobs in reconciliation belong to the accountant, and they do not move.

Deciding what is an error versus what is intentional. A रू. १,२०० debit on your statement that the ledger does not show might be a missed bank charge — or it might be a fraudulent debit you need to dispute. The model can tell you which is more likely; it cannot make the call, because the call carries real consequence. A रू. ५०० rounding difference might be a typo to fix — or it might be a deliberate adjustment made by the partner-in-charge three weeks ago for reasons documented elsewhere. Only someone with the firm’s actual history can know.

Deciding what to post to suspense. “Suspense” is the account where unresolved items live until someone resolves them. Sending an item to suspense is itself a judgement: how long is it acceptable to leave this unresolved, what is the risk of leaving it, who follows up, when. The model has none of this context and should not be allowed to fake it.

Deciding which side to adjust. When the bank and the ledger disagree, one of them is right and the other needs adjusting. Which is which is rarely obvious from data alone. The bank is usually right about amounts and dates; the ledger is usually right about classification and intent. But “usually” is doing too much work in that sentence to let an LLM decide. The accountant decides, with the documents in front of them.

A concrete workflow

A practical end-to-end shape that works in a small or mid-sized Nepali practice, in 2026, looks like this.

Step 1 — Export. Pull the bank statement as CSV from your bank’s portal (NIC Asia, Nabil, Global IME, Siddhartha, Standard Chartered all offer this; for the few that still only offer PDF, run the PDF through the OCR step from the first section of this chapter). Pull the corresponding ledger from Tally or your accounting software as CSV. Both files should cover the same date range, with the same opening and closing balances exposed.

Step 2 — Structured prompt. Paste both CSVs into a single prompt to Claude, ChatGPT, or Gemini, with instructions that look roughly like this:

Below are two CSVs. The first is our company’s NIC Asia bank statement for [date range]. The second is the corresponding ledger from our books for the same period and account. Produce two tables. Table A: matched pairs — for each pair, show the bank row, the ledger row, and the matching basis (exact amount + same date / amount + one-day offset / amount + narration match / etc.). Table B: unmatched items — list every row from either side that did not match, mark which side it came from, and for each row provide a short ranked list of likely reasons it is unmatched (timing, fee, transposition, missing entry, fraud, FX, duplicate). Do not invent matches. Do not propose journal entries.

Step 3 — Triage the unmatched list. Take Table B into Excel — or better, into the working paper template your firm uses for reconciliation. For each unmatched row, decide what it is, what evidence supports that, what (if anything) gets posted, and what (if anything) goes to suspense or follow-up. The model’s candidate explanations are useful here as a starting point, not as conclusions.

Step 4 — Post in the accounting software, not the chat. Any actual journal entry — a missed bank charge to be booked, a transposition to be corrected, a fee to be capitalised — gets posted by a human in Tally or your accounting software, with the working paper as supporting documentation. The chat transcript is not your audit trail; the working paper is.

Why “AI matched 95%, looks fine” is the danger

It is worth lingering on the specific shape of the error this section is warning against, because it is so seductive.

A junior runs the reconciliation. The model returns a clean Table A with ninety-five percent matched, and a Table B with five unmatched items. The totals nearly tie out. The junior, tired and on deadline, looks at Table A, confirms the totals match, treats Table B as “small stuff” and posts a small balancing JV to suspense to make the books tie. The reconciliation is “done.” It looks like real reconciliation. The working paper even looks impressive.

But the value of the work that was done — matching the easy ninety-five percent — was always essentially zero. Those rows were never going to be the problem; they were going to match. The work that was not done — actually understanding each of the five unmatched items, deciding what it implies, posting or escalating as appropriate — was the entire point of the reconciliation. The junior has, with the help of a very expensive model, executed the form of reconciliation while skipping its substance.

This is not a hypothetical. It is the dominant failure mode of AI-assisted reconciliation, in firms I have seen, in 2026. The countermeasure is structural, not motivational: a reconciliation is not closed until every row in Table B has a documented decision attached to it. The matched table is informational; the unmatched table is the work.

When the model disagrees with itself

A useful final habit. Run the same reconciliation twice, with slightly different prompts — once asking the model to be liberal in proposing matches (accept narration-similarity matches, accept date offsets up to three days), once asking it to be strict (exact-amount-and-date matches only, everything else unmatched). Compare the two unmatched lists.

Items unmatched in both runs are almost certainly real exceptions and deserve full attention. Items that were matched in the liberal run and unmatched in the strict run are the borderline cases — they deserve a quick human glance to confirm the model’s call. Items matched in both runs are very likely safe. This dual-run pattern costs you a few extra rupees of tokens and saves you the false confidence of a single confident-but-wrong run. It is the closest thing to a free safety check this workflow has.

Check your understanding

Quick check

—

Your junior runs a bank reconciliation with an LLM. It reports 95% of items matched and 5% unmatched. The junior wants to post a small balancing entry to suspense so the books tie, and close the reconciliation. Why is this the wrong move?

It is the right move; modern models match accurately enough that the unmatched items can be safely closed to suspense.
The matched 95% is informational — those items were always going to match. The unmatched 5% is where every reconciliation's actual value lives: it contains the errors, fraud, timing differences, and missed entries that a reconciliation exists to surface. Closing them to suspense without investigation defeats the purpose of the exercise.
The bank may reject the suspense entry.
The accounting software does not allow suspense postings.

What comes next

You have now closed the loop on the data-in side of accounting: source documents are captured, transactions are categorised against your firm’s actual chart, and the books agree with the outside world. The next chapter shifts from data-in to data-out: how AI changes the way you build, explain, and use the reports that come out of all this clean data — management accounts, variance analysis, board narratives, and the questions clients actually ask of their numbers.