Lending Pain Map

Running an NBFC loan book on Excel and Tally: when to move

The test is whether someone else can explain a loan when the person who keeps the workbook is away. Follow one repayment from the bank entry to the accounts.

Running an NBFC loan book on Excel and Tally: when to move: cover art
Contents 8 sections

Imagine you own a small NBFC. The person who maintains your Excel loan book and posts the accounts in Tally is away on Monday. A borrower asks why the account still shows an overdue amount after a payment. You can open the files. Can another person explain the answer?

This is a hypothetical handover exercise, not a customer case. It tests our position: a spreadsheet loan book reaches its practical limit when the record depends on one person’s memory. A row count cannot tell you whether that has happened.

Lenders we have spoken to since July have repeatedly described the same setup: Excel, Tally and one person joining the two. Lokta’s starting point is the account that person has to explain. A loan management system (LMS) earns its place when the team can carry on from recorded history and rules.

Monday: the person who keeps the book is away

In this exercise, the substitute needs the agreed repayment schedule, the receipts already posted and the changes made to the account. Today’s outstanding amount is only the end of that explanation.

Suppose the workbook contains a revised instalment date, while the borrower has the earlier schedule. The substitute must establish which schedule took effect, who authorised the change and what happened to the amounts already due. An overwritten cell cannot explain its previous value unless that history has been preserved elsewhere.

The useful handover is therefore a record another person can follow: loan identifier, dated schedule, receipts, adjustments and supporting approvals. A note saying “ask the accounts person” identifies the dependency without resolving it. The EMI dispute guide follows the evidence needed to answer a borrower from that history.

The test applies to software too. A new system with incomplete opening data can leave the substitute facing the same question.

Tuesday: a repayment arrives

Continue the scenario with a bank entry that appears to be the borrower’s payment. The substitute first establishes which loan it belongs to. The team then needs to know when the receipt became effective, how it was allocated and whether the account’s overdue position changed.

A receipt entered twice and a receipt left unmatched create different problems. Keep an unresolved payment visible for investigation instead of guessing the loan or treating every bank credit as cleared demand. The loan reconciliation guide covers receipt matching and control totals in detail.

This is where the deterministic core matters: recorded inputs and approved rules determine the account movement. A borrower balance should not depend on which colleague happened to copy the formula that morning.

The owner still sets the policy, authorises exceptions and resolves ambiguous evidence. Software changes where the work is recorded. The lender remains accountable for the decision.

Month-end: Excel and Tally have to agree

At month-end in the exercise, finance must connect the loan movement to the accounting entry. A total that balances is useful, but finance also needs to explain what produced it and how a correction would flow through both records.

Tally itself should not be the straw man. Its Edit Log documentation describes tracking creation, alteration and deletion of masters and transactions, with version, user and time details. Once enabled, the log captures subsequent changes. The question is whether your loan schedule, receipt allocation and accounting voucher remain connected across the setup you actually use.

For NBFC reporting, paragraphs 14 and 15 of the RBI’s Supervisory Returns Directions, dated 31 July 2026, require reconciliation to the NBFC’s own sources, including accounting data where appropriate, and records of sources and aggregation rules. That is a concrete reason to preserve the path from the reported figure back to the book.

Define the handoff in writing: which events create entries, which accounts they use, when they post, which reference joins them, and who investigates a difference. A Tally interface must be confirmed and tested for the proposed implementation. Naming the accounting product does not establish an available connector.

Management may also want bucket-wise and branch views in one place. Keep that reporting requirement distinct from the operating handover. The existing portfolio analysis article explains the measures and their history requirements. The SMA and NPA guide covers classification rules.

The next review: decide what needs to move

The exercise has produced a scope: one account’s schedule, receipt, correction and accounting trace. Compare the current process against that scope before expanding the purchase into every lending workflow.

PathWhen it fitsWork you retain
Keep the controlled workbookAnother authorised person can reproduce the account and complete the handoverAccess control, history, reconciliation and backup procedures still need owners
Add a loan system beside accountingLoan operations need a shared record while the accounting arrangement remains usefulMapping, interfaces and reconciliation across the two records
Replace a wider stackThe broader operating requirements justify a wider implementationMore dependencies, acceptance work and a carefully defined cutover

Lokta’s Loan Management for NBFCs is the post-approval option to assess. Your LOS, or your partner lender’s, hands the loan over through an API. Loan Origination is on the roadmap, with no date. If one available origination-and-servicing package is essential to your purchase, include that constraint in the comparison.

For setup terms, use Next 100. The programme explainer provides context. Keep the commercial discussion tied to your actual data and implementation scope.

Before cutover: prove the history survives

Finish the hypothetical exercise by asking the substitute to explain the same loan in the proposed setup. The borrower statement, overdue position and accounting entry should reconcile to the accepted source records. Differences need explanations and agreed treatment before the new record becomes authoritative.

Use the migration cutover sequence to plan the parallel run and sign-offs. A system cannot recover history that no surviving record contains. Source cleanup and reconciliation remain real work.

A leaner team is a goal to evaluate after that work. Start by measuring re-entry, unresolved exceptions and the time needed to answer an account question. The first-workflow guide helps choose a bounded automation task once the records are dependable.

Talk to us about the loan your second person cannot explain. That is a useful starting point for the move off Excel.

Frequently asked questions

When should an NBFC move its loan book from Excel to an LMS?

Start assessing the move when another authorised person cannot reproduce a loan balance, explain a change or continue the day's work from the records alone. There is no account-count threshold established by this article. A controlled workbook can remain useful, but dependence on its author's memory is a weak operating arrangement. Test a repayment, a correction and a past-date account history before choosing software. The result should tell you which controls and records the replacement must preserve.

Can an NBFC keep Tally after introducing a loan management system?

Keeping Tally for accounting can be an option if the lender defines and tests the connection between loan events and accounting entries. Agree the account mapping, posting frequency, references, corrections and reconciliation owner before implementation. TallyPrime has documented Edit Log features, so the decision should not assume it has no change history. A particular LMS-to-Tally integration still needs confirmation. Lokta's scope in this article does not establish that a Tally connector is available for your setup.

Does Lokta provide both origination and loan management?

Lokta's available scope starts after approval, with Loan Management, AI Loan Servicing and RBI Model Risk Management. Loan Origination remains on the roadmap without a delivery date. Your LOS, or your partner lender's, hands the loan over through an API. Define the handover fields, accepted schedule and exception owner during scoping. A lender that needs an available origination product as part of the same purchase should treat that requirement explicitly when comparing options.

What should a small NBFC budget for moving off spreadsheets?

Define the scope before asking for a price: source files, loan history, accounting treatment, interfaces, acceptance checks and the people needed for reconciliation. Subscription price alone does not describe the work of moving the book. For Lokta's current programme terms, use the Next 100 page. Keep implementation assumptions in the proposal and test them with a sample of your own records. This article does not promise a fixed setup price or migration duration.

Sources

Lokta editorial analysis by Chandramouli, co-founder and CEO.

Bring us your live book

See what agents can do after approval.

Talk to us
Founder-led adoption

Adopt the agentic loan servicing platform.

Lokta is built for enterprise deployment, VPC or single-tenant cloud, with an audit trail in every state change. We work with a select group of institutions through a founder-led model: deep adoption, deliberate scope, a delivery window the team commits to in writing.