Loan reconciliation in an LMS
Every receipt needs one identity, one allocation, and one ledger result.
Loan reconciliation proves that money received through NACH, UPI, a bank transfer, a virtual account, or another collection route reaches the correct loan account once. The proof has to connect source evidence, matching, allocation, the loan ledger, accounting, statements, and every unresolved exception.
- Payment evidence arrivesA rail event, bank reference, settlement file, virtual account credit, or mandate result.
- Identity and rules resolve itThe system finds the intended account, rejects duplicates, and applies the lender's allocation order.
- The loan and ledger agreeOne accepted transaction updates the account, accounting entries, statement, and exception record.
The standard
A payment is reconciled only when its identity, match, allocation, posting, accounting effect, statement effect, and exception status agree.
The boundary
This guide defines a buyer test. It does not announce a standalone Lokta reconciliation product or expand Lokta beyond the live loan book after approval.
Loan reconciliation connects the payment event to the money of record
The payment rail and the LMS answer different questions. The rail reports what happened to a payment instruction. The LMS decides what that event means for a live loan account. NPCI describes NACH as a centralised system for high-volume, repetitive interbank transactions, including loan-instalment collections, while UPI supports immediate bank-to-bank transfers. Neither description replaces the lender's account-level posting and exception controls.
For digital lending, RBI's 8 May 2025 directions say loan servicing and repayment should move directly between the borrower and the regulated entity's bank account, without a third-party pass-through or pool account. Reconciliation evidence should therefore make the destination account and any exception around it visible.
Seven controls turn a payment feed into a reconciled loan transaction
Ask the vendor to demonstrate each control with your identifiers, repayment waterfall, business-date rules, and accounting map. A slide or API list is not acceptance evidence.
Loan reconciliation controls and the evidence a lender should request
| Control | Required design | Acceptance evidence |
|---|---|---|
| Payment identity | Unique rail and bank references, mandate or virtual-account identity, amount, value date, payer, and destination account. | Prove that the same event can be traced from source evidence to one loan transaction without relying on free-text narration. |
| Idempotency | A stable key and duplicate rule for retries, repeated files, delayed webhooks, and operator re-upload. | Submit the same event twice. The second attempt should be rejected or resolve to the first posting, never create another receipt. |
| Account matching | Deterministic matching against loan ID, borrower, virtual account, mandate, and product context, with confidence-free fallbacks. | Remove the strongest identifier. The system should route the payment to an exception, not guess which borrower owns the money. |
| Allocation | Effective-dated rules for principal, interest, fees, penal charges, arrears, advance amounts, and overpayments. | Run one difficult receipt through the lender's actual waterfall and reconcile the schedule, balances, and journal entries. |
| Reversal and return | A linked compensating event that preserves the original posting, reason, authority, and downstream effect. | Reverse a backdated receipt after later transactions exist. Require replay evidence instead of deleting or editing history. |
| Exception ownership | Named queues for unmatched, short, excess, duplicate, reversed, disputed, or destination-mismatched events. | Age every open exception, assign an owner, record the decision, and prove that closing it changes all affected records once. |
| Control totals | Counts and values from the source file or account against accepted, rejected, pending, reversed, and posted events. | Reconcile both count and value. A balanced amount can still hide a missing receipt and an equal duplicate. |
The exception queue is part of the ledger control
Straight-through matching is useful, but the buyer learns more from the events that do not fit. Every exception needs an explicit state, owner, clock, evidence trail, resolution rule, and downstream correction.
Common reconciliation exceptions and the required system behaviour
| Exception | Required behaviour |
|---|---|
| An unmatched payment | Keep the money visible in a suspense or exception state, preserve every candidate identifier, and prevent loan allocation until a governed decision resolves it. |
| A partial payment | Apply the configured appropriation order, update the schedule and arrears once, and retain the remaining due amount rather than treating the instalment as simply paid or unpaid. |
| An excess payment | Apply the lender's policy for advance payment, prepayment, overpayment liability, or refund. Do not invent a future allocation outside that policy. |
| A return or reversal | Post a linked compensating event, restore the affected balances and classifications, and retain the original transaction and reason in the audit record. |
| A duplicate file or callback | Resolve it through the idempotency key and record the rejection. Operators should be able to explain why the second event did not post. |
| A destination-account mismatch | Stop automatic allocation, verify whether the receipt reached the regulated lender's permitted account, and escalate under the lender's payment and compliance policy. |
Six acceptance tests expose the difference between a connector and a control
Run these tests in a product demonstration or controlled pilot. Capture the starting state, source payload, expected result, actual result, exceptions, approvals, and final ledger and accounting output.
Loan reconciliation acceptance tests for an LMS evaluation
| Test | Pass condition |
|---|---|
| Traceability test | Start with a bank or rail reference and retrieve the source payload, match decision, loan transaction, allocation, journal entries, statement effect, operator actions, and current status. |
| Replay test | Reprocess the same evidence after an interruption. Balances and counts should converge to the same result without a second posting. |
| Cut-off test | Send events before, at, and after the business-date cut-off. Confirm value dates, DPD, allocation, accounting period, and customer communication remain consistent. |
| Backdated reversal test | Reverse an earlier receipt after later charges or payments exist. Require a deterministic rebuild and a record of every affected state. |
| Control-total test | Prove source count and value against accepted, pending, rejected, and reversed events. Test a missing event and an equal-value duplicate together. |
| Access-control test | Show which roles may match, override, reverse, waive, approve, or close an exception, including maker-checker thresholds and exportable audit evidence. |
The durable rule
A balanced amount is not enough. The identities and states must balance too.
The evidence pack should contain
- Source files, callbacks, references, counts, values, and destination accounts.
- Match and allocation rules with their effective dates.
- Accepted, rejected, pending, duplicate, reversed, and closed exception states.
- Loan transactions, schedule changes, journal entries, statements, and audit events.
- Roles, approvals, overrides, service clocks, and exportable control totals.
The product claim stays narrower than the buyer guide
Loan Management is available now. Lokta publishes current detail about its post-disbursement ledger and servicing scope on the Loan Management page, and about supported interface categories on the integrations page. Buyers should test those published capabilities against the controls above. This page does not present reconciliation as a separately available Lokta solution.
Frequently asked questions
What is loan reconciliation in an LMS?
Loan reconciliation is the process of proving that money received through a payment rail or bank account has been identified, matched to the correct borrower and loan, allocated under the lender's rules, posted once to the loan ledger, and reflected consistently in accounting and customer records. Unmatched, duplicate, partial, excess, returned, or reversed events stay visible until resolved.
Is a successful payment status enough to reconcile a loan repayment?
No. A successful rail event proves movement at the payment layer. The lender still has to prove which account owns the money, whether the event is new, how it was allocated, what posted to the ledger, and whether statements, schedules, accounting, delinquency, and downstream reporting now agree.
What should happen to an unmatched loan payment?
It should remain visible in an exception or suspense state with its source evidence intact. The system should not guess a borrower or silently discard the event. A named operator or governed rule resolves the identity, and the record should preserve the reason, approval, posting, and closure.
How can a lender test duplicate-payment protection?
Submit the same source event, settlement row, or callback more than once, including after an interruption. The platform should use a stable idempotency key to reject the repeat or resolve it to the original transaction. Loan balances, accounting entries, control totals, and statements must remain unchanged.
Does this page mean Lokta offers a standalone reconciliation product?
No. This is a vendor-neutral buyer guide, not a standalone product announcement. Loan Management is available now. Buyers can inspect Lokta's current published Loan Management and integration scope, then test it against the acceptance criteria on this page.
Continue the evaluation
Source notes
Sources were reviewed on 2 September 2026. The acceptance criteria and control model are Lokta's editorial synthesis for buyers; the sources below establish the payment-rail and regulated-account context.
- NPCI, NACH product overview.
- NPCI, Unified Payments Interface product overview.
- Reserve Bank of India (Digital Lending) Directions, 8 May 2025.
- Apache Fineract, platform documentation, for open-source examples of transactions, allocation, reversals, schedules, and accounting mappings.
Test reconciliation on one difficult payment path.
Bring the source event, the expected allocation, and the ledger and accounting result you need to prove.
Talk to us