Why most NBFC reconciliation breaks at the same five places and why throwing analysts at it never converges.
Look at the reconciliation backlog at any NBFC ops desk. Five problems are doing 90% of the damage. They aren't reasons to hire more ops people, they're reasons to build a reconciliation engine that thinks about all five upfront.
Reconciliation is treated as a process problem in most NBFCs. It isn't. It's a data graph problem. The pain is structural, it lives in the gaps between MIS, accounting, multiple bank statements, and payment aggregator data. Until those gaps are closed at the engineering layer, no amount of operational discipline will move the auto-match rate above 60%.
Problem 1: There is no common identifier
Loan ID exists in MIS and accounting. It is missing from bank statements. PhonePe settlements come through with their own transaction IDs and merchant references. The fundamental matching key is absent in 50% of your data sources, which forces fuzzy matching from day one.
The fix is identifier engineering: extract UTRs from bank narration, enrich with loan ID via amount-and-date triangulation, and propagate the enriched ID downstream so subsequent matching has a stable key. Without this, every reconciliation run starts from scratch.
Problem 2: Customer names don't match
"Mr. Ravi Kumar" in MIS becomes "R KUMAR" in bank narration. Or "RAVIKUMAR S/O Mahesh". Or "Ravi K (NEFT)". Bank narration formats are the wild west, and humans patch over the mess by visual inspection.
Engineering this away requires a normalization pipeline: strip honorifics (Mr/Mrs/Dr), expand initials, handle phonetic variants, score fuzzy matches with a numeric distance, and threshold by use case. The normalization is reusable, same logic across NBFC loan reco, cash collection reco, and 3-way AP reco.
Problem 3: T+1 posting and batch uploads create date mismatches
Bank settlements post T+1. Payment aggregators batch by day. MIS records in real time. A collection that reaches MIS on day T appears in the bank statement on T+1, in the aggregator file on T+1 midnight batch, and possibly in your next-day operations report on T+2.
Date-window-aware matching is mandatory. The matching engine must be configurable for T to T+N tolerance per source. Otherwise, every cycle ends with an inflated unmatched pile that ops chases for two weeks.
Problem 4: The same UTR appears twice
PhonePe settlement file shows UTR 4729384738. Bank statement on the next day shows the same UTR as a credit. If you sum both into your reconciled total, you've double-counted the collection, and your daily reconciliation will close on inflated numbers.
UTR-based dedup at the matching engine is a non-negotiable. Every transaction is keyed by its earliest-arriving UTR, and subsequent appearances of the same UTR are treated as observability events, not as new transactions.
Problem 5: Internal adjustments live only in MIS
Top-up adjustments, write-offs, internal transfers, and renewal accounting never touch the bank. They exist as MIS-only transactions. If your reconciliation engine treats "unmatched" as "problem," the unmatched pile grows even when nothing is wrong, driving false-positive ops fire-fighting.
The engineering fix is classification: every transaction is classified into one of (at least) five classes, Collection, Disbursement, Top-Up, Renewal, Adjustment. Internal adjustments go to a class that doesn't expect bank-side counterparts. The engine knows the difference between "unmatched and broken" and "unmatched and expected."
Reference architecture for the matching engine
- Ingestion: MIS / Day Book / Bank / PhonePe / GRN / Invoices, normalized into a common schema at the boundary
- Standardization: name normalization, date format, amount sign, UTR extraction from narration
- Matching engine: weighted scoring 0–100; configurable per use case (Loan ID 40 / Name fuzzy 20 / Amount 20 / Date 10 / UTR 10)
- Classification engine: rule-based plus AI for fuzzy / edge cases; emits transaction class
- Exception management: auto-flagging, audit trail per match, source row references
- Reports: daily, monthly, exception, tag, all Excel-exportable, all replayable
When to engineer this vs hire ops
If your team is spending 4+ days a month on reconciliation, the math has already broken in your favor. Three additional ops analysts cost more in 18 months than the entire reconciliation engineering engagement. And those analysts will plateau, additional headcount drives diminishing returns past a certain volume.
Engineering, by contrast, is one-time investment with compounding returns. The 90–95% auto-match scales with your AUM. The 80% manual effort reduction is permanent.